APIStrat 2016 Boston November 2-4.

First week of November 2016 was API week in Boston. Still trying to absorb APIStrat 2016. Presentations the same week with similar API themes from IBM, SmartBear and GE Predix.

API?  Had in mind the API definition from Wikipedia. But the core is now more what is defined above as "Web API". API is about REST, SOAP - MQTT, CoAP - etc.

Presentations in past months and years on IoT from Axeda, Thingworx, PTC and IBM Bluemix and AT&T M2M and Amazon Alexa/Lambda were in retrospect more about APIs than anything else. The APIs for endpoints and platforms for IoT have been building. BACnet Web Services is but one example.

API is more than a "definition". API is about the rising ecosystem of business use cases and tools for APIs. Swagger, RAML, OpenAPI , Stoplight, even Postman, CURL and choices regarding REST, SOAP, XML, JSON and so forth.

Gartner analyst APIStrat keynote: Mark O'Neill : Business use cases gelling. Rich ecosystem of tools and cases for API creation. But also cases for API consumption... and there is a business opportinity therein. [Also *grin* Why are digital voice assistants like Alexa and Siri always depicted or embodied round? Are polygons too edgy? ]

Great easy venue for APIstrat at Marriott Long Wharf on Blue Line MBTA.

MassTLC IoT at PTC - Smart Connected Products Transforming Competition - HBR.

IoT has had much discussion lately. Went to a great MassTLC sponsored seminar at PTC on November 4. How Smart, Connected Products are Transforming Competition. Went hand in hand with article in Harvard Business Review. Lay of land for Smart Connected Products. Ten questions businesses should ask themselves. Very appropriate.  Looking at steps

1. 1. Monitoring.
2. 2. Control.
3. 3. Optimization.
4. 4. Autonomy.

Could not help but think about the roots of IoT in tracking/viewing things. The order should perhaps still be

1. 1. Monitoring.
2. 2. Optimization (based purely on what is monitored and outside of any actual IoT programme).
3. 3. Autonomy.
4. 4. Control - Control is last because one should understand the situation before taking action.

And in many cases there are limits (safety, regulatory, privacy, moral, etc.) on what can be controlled. Most of the value is in monitoring and optimization. Some situations never get to control.

 

There were questions during discussions about..

When will industries standardize? What are we waiting for?

1. Leadership from Apple, Amazon, Google and so forth were cited for consumer.
2. Leadership by the main players are often cited in commercial industry. But there is a commercial incentive for non-standard approaches (differentiators) in many situations.
3. Cooperation and collaborative openness. There are examples of collaborative standardization. There are ecosystems which makes it easy to exchange, normalize, coordinate, aggregate and analyze data.

Examples of collaborative standardization:

• BACnet in buildings.
• Sunspec in renewables.
• MTConnect in factory systems.
• OPC (XML DA) in automation.

And the following too - if an ONLY if the mapping/schema is well known... the universally accepted schema is the heart of the matter

• Modbus in industrial. The depth and of Modbus (all the way to sensors), and the breadth of its install base, should not be ignored.
• SNMP in IT.
• RESTful exchange in commerce.
• Any XML in any domain.
• MQ (message queuing) in any domain.

SQL is often hauled out as an exchange method. There is no universal public schema for any database system. Such a schema would be orthogonal to the performance needs of a database.
 
And as a final word. Smart connected things without goals and analytics are fruitless. And goals need not be set in stone, as they are generally informed by analytics. Tactical drives the strategic and vice versa. They are two sides of the same coin. Planning is essential but plans are useless.

 

Serial Bridges... Preparing for the Internet of Things (IoT).

Many embedded applications come down to I/O with "lesser" serial bus on one side (sensors via I2C or SPI or something straightforward like Modbus) via an intelligent agent which then interacts with a "greater" serial bus on the other side (like to a stateful serial protocol like BACnet MSTP, Profibus, ARCNET or even Modbus or USB). This is the essence of a serial bridge.

Most embedded developers pick a micro controller they are familiar with and go directly to work building their bridge.

What if one instead envisioned first how such a bridge could communicate via the Internet of Things?
That is to say - What if one envisioned a TCPIP and web interface from the start?
The web interface would be used for
- startup and configuration (minimizing dip switches and other UI hardware)
- ongoing status (minimizing indicators and hardware UI)
- "dip in" protocols to watch data flow - like RESTful interfaces (MTConnect, Sunspec and others), Modbus TCP and various XML schemas, or even simple .CSV data log files.

Basically one minimally needs two serial interfaces and a TCPIP (Ethernet or Wifi) interface.
[Wifi is a tiny bit harder to auto-configure - but not impossible].

The big problem was always price for TCPIP. And this was usually made worse by the fact that the TCPIP part was an after-thought or add-on - which had to be engineered /into/ the bridge. So what about taking a (cheap) TCPIP intrinsic part and using it "incidentally" as a serial bridge?

The Lantronix xPico is an embodiment of such a bridge, and a particularly "right sized" and economical version. Small ARMs and some recent x86 (Vortex86, Intel and VIA) are getting close,
but none have the sharp focus of the xPico... it being a child of a programme for TCPIP to serial bridging, which just recently branched into multiple serial. There are other small TCPIP UI systems with possible multiple serial... like Moxa and Digi. It is just that the price, tools and possibilities seem uniquely congruent with the xPico.

Only issue with xPico is actually humanly getting access to the two serials via the Hirose. The DKs have this... but also a bunch of excess. Ended up making a breakout DIP40 for prototype work... and working to a policy of keeping all useful pins exposed in viae or test points. See previous blog on breakout pins and APIs.
 
http://albertputnam.blogspot.com/2013/12/new-devices-just-give-us-pins-and-apis.html