Internet of Things. Webservices. Modbus, BACnet, MQTT, AMQP, MTConnect, Sunspec.

Discussion of Internet of Things often brings up protocols and APIs. Will there be universal ones? Many go down a line of reasoning that major users of transaction systems will define the APIs (like Google, Amazon and Apple). Others simply say - RESTful, AMQP, MQTT and CoAP. The former means waiting for everything to settle. The latter are more "Platonic ideals" than things one can actually use or learn from by example. And if one is thinking about actual object and property definitions for actual modeled things or systems, then all above are really at a different level of consideration.

Where is the center? Are there any modeled constructs (for want of a better name) actually in deployment? Such things would have properties of objects like units, types/casts, locations, enumerations, language, etc.
Concept of objects with properties and univeral meta-data related to an interesting piece at Data Central recently about "codes".

Will submit the following for consideration as potentially having modeled constructs:

Modbus (general automation).  Not self describing - properties of objects must be discerned from documentation.

BACnet (building automation).  Watch for new BACnet/IT and related meetings and discussion.

Sunspec (renewables). Note Sunspec has a Modbus and XML form. Both are at least somewhat self describing.

MTConnect (machine tools).

OPC (general automation)  and OPC UA. Somewhat self describing, but overtly general.

NMEA-2000 (and 0183). Imagine Modbus, but with all the interpretation problems for "registers" recast as "strings" problems.

CAN and ODBII (auto). There are standard profiles and methods... and not so.

Then again one can say that structure plus documentation has context with almost all field buses. (Especially in factory/manufacturing, building/structure and energy/flow automation)

Profinet, EthernetIP, EtherCat,...

And then there is protocol and API at other end... IoT platform: ThingWorx, Xively, BlueMix, AT&T.... And the extent to which they provide actual object and property definitions for actual modeled things or systems.

[Why is my location pin at Iskilip, Turkey?]

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

Solar PV Renewables

Lately thinking about PV solar. Wikipedia is always a great start for background.
http://en.wikipedia.org/wiki/Photovoltaic_system
http://en.wikipedia.org/wiki/Solar_power_in_Massachusetts

And then Greentech's coverage.
http://www.greentechmedia.com/channel/solar

Recently was forwarded this NYTimes refernce to McKinsey report on disruptive technolgies.
http://bits.blogs.nytimes.com/2013/05/22/mckinsey-the-33-trillion-technology-payoff/?emc=eta1
http://www.mckinsey.com/insights/business_technology/disruptive_technologies
All the chapters are interesting (and inter-related) but if you want to go right for solar related material then look at renewables and energy storage.

Was pleased to attend the Sunspec City of Boston demonstration event in mid 2012.
http://www.sunspec.org/wp-content/uploads/2012/07/SunSpec-City-Of-Boston-News-Release.pdf
and get a direct view of how municipals and campuses are looking at solar.

On a more direct residential level there are lots of programmes for PV solar like
http://www.solarizemass.com/index.cfm/page/About-Solarize/pid/12858