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?]

Option Value of BACnet and Webservices on Xport.

Blogged before about how to make a Modbus device be BACnet. Question came regarding B6131 embedded Modbus to BACnet gateway module in a way only thought about for Analytika legacy metering projects: The B6131 (and its developer kit B6130 boxed version) have a Modbus RTU to Modbus TCP MBAP router embedded inside. One simply has to turn on Modbus TCP in the web GUI. So...
Use the B613x as only a Modbus TCP router? At least as a starting position? That is to say: Use the B613x exactly like any Modbus TCP routers on the market. Notably exactly like Modbus TCP routers from Lantronix and Gridconnect on their XPorts and xPicos (DSTini platform).

Except the B613x has the option to later install BACnet templates under the existing BACnet device, and use the web for data access. The B613x unit comes with excellent defaults preset and is re-configurable via the HTTP web GUI. Further there are OEM optional "add-ins" for REST webservices, advanced auto-setup and discovery, buffered data, and so on. Where the OEM or end-user has already designed in an XPort/XPico this is exceptionally straightforward.

Make a Modbus Device be BACnet.

Suppose a mature Modbus device which one wants to be BACnet. The device has a clear and static Modbus register map and uses standard Modbus throughout. One mostly wants the device to make its data available via BACnet and other web services to clients and participate in the Internet of Things wave.
The device is not completely static. Future revisions are expected and these want to easily integrate into new systems. The device is not solitary. It must function and thrive withing a system of its peers or devices from other vendors.

• Cimetrics B6130 Modbus to BACnet IP can be added to mature project and works great. Exactly where most start.
• Cimetrics B6131 module for a new unit works great. Exactly where most end up. Think of the B6130 as the development kit for B6131.

B613x has all the following concurrently and transparently at run time - probably have to see this to completely absorb the implications:

• BACnet/IP (we also have a BACnet MSTP RS485 version if you use a Lantronix/Gridconnect xPico).
• Modbus TCP.
• Web GUI.

Features of existing B613x base:

• Excellent long track record Cimetrics BACnet stack.
• Defaults designed to make installs and device additions or reconfigurations easy and painless for first time or advanced users, of 1-100 units,  as system, or within other systems.
• Quick time to market, with levels of effort tailored to OEM and end-user needs.
• JIT supply chain with Ethernet firmware load.

Wrote and blogged before about making a small device BACnet via Modbus.

And got some questions about how to test BACnet... There are a couple of generic templates in the B613x kit (even before the template creator) which would allow one to "peek" around a generic Modbus device.

For testing the BACnet side externally, usually Cimetrics' clients use BACnet Explorer or BACnet OPC server. Demo versions in each case can be found by going to the Documentation tab (roughly mid page) (usually 20-40 MB).

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

IQ Power Xpert meters - Westinghouse, Cutler-Hammer, Eaton, INCOM - brought to TCPIP.

Have a bunch of IQ meters and/or switchgear? - maybe branded Westinghouse, Cutler-Hammer or Eaton?... Know the meters? - They are the ubiquitous first generation digital meters in practically every facility. Either one has never networked these meters (though one might have a blue INCOM line running between them one barely even recognizes), or one has soldiered through the ups and downs of the Power Xpert software gateway architecture running on PCs.

Have in mind that the only way out to the future is to upgrade the meters, but that would be a major project with shutdowns and swap outs. So one just sits and does nothing and waits for the meters to "inlast" the building; though that is rife with danger from normal maintenance failures.

Eaton has a little known solution/pathway for these meters.
It is called the Eaton Power Xpert Gateway PXG600.

How does it work:
- Upgrade set of meters to INCOM (sometimes with a PONI/IPONI = INCOM product operated network interface - often these are already in place).
- Run blue cable bus for INCOM between local sets of meters (up to about ten (best) to forty (pushing limits)) in a group. Often "blue hose" is already in place.
- Attach meter group(s) to the INCOM port(s) of PXG600.
- Attach PXG600 to a TCPIP Ethernet network system (attach like any common IP device).
- Setup PXG600(s). The PXG600 has internal template maps for the long history of IQ meters. It supports a variety of protocols like Modbus TCP and in some cases BACnet IP and SNMP.
- Get "middleware" together. One probably has systems that can consume and log meter data (HVAC, SCADA and such). One wants to convert the Modbus TCP data into such,  whilst also leaving openings for others to attach to Modbus TCP in parallel. Something like a Cimetrics B6035 does the intermediation job nicely. But it is also the case that many management systems will read the interfaces directly (especially if you have BACnet/IP in your building management system
or Modbus TCP in your SCADA system).
- Enjoy.

Too hard? Talk to Eaton. Eaton can set this up for you.
Too expensive? The PXG600 is "open channel" and supportable by third parties. Talk to someone like PWA - Physical World Analytics in their troubleshooting capacity or Cimetrics in their network-architecture design capacity. They too can set this up for you.

Articles in Automated Buildings

Recent articles up at Automated Buildings - December, January and February. http://www.automatedbuildings.com/

• Servers Which Serve - touches on the need for multiple client access for embedded devices.
• Making a Small BACnet device - talks about how we approach the question of making a small BACnet device.
• PoE for BAS retrofits - if your application has Ethernet/TCP/IP needed anyway - why not get your power from it?

Power Over Ethernet for Building Automation Systems Retrofits

http://www.automatedbuildings.com/news/feb13/articles/cimetrics/130118031505cimetrics.html

Servers Which Serve - Multiple Client Use Cases
http://www.automatedbuildings.com/news/jan13/articles/cimetrics/121219031505cimetrics.html

Making a Small BACnet Device - How does one make a small BACnet device?
http://www.automatedbuildings.com/news/dec12/articles/cimetrics/121122110404cimetrics.html

Some of my favorite sites and blogs are in the nearby frames allied herein... like Greentech and Make.

Modbus Base Camp for Devices

If I were to make an appliance/device/meter/controller today, I would make it speak Modbus. You will note I have not defined my domain, market, breadth, nor whether wireless is needed, nor whether it is a consumer or end user application or for the enterprise.

The Modbus assertion is the aggregation of the nuances across the board… all the way from the level of hacking together a small Arduino http://en.wikipedia.org/wiki/Arduino based controller for sensing the kitchen window open - through medium sized embedded Ethernet controllers based on something like Lantronix Xports http://www.lantronix.com/device-networking/embedded-device-servers/xport.html - to the level of large equipment controlling real world industrial and mechanical processes for large enterprises (like entire agencies of sovereign entities).

Note that I have not specified Modbus over RS485 or RS232 or TCP/IP; nor have I specified layered ways of transporting the protocol (like Ethernet, Wireless and Fiber).

One can poke at Modbus saying – no security, no object model, and little structure. Modbus’ beauty is in its simplicity, and in that one's needed features can be overlaid. Two of my favorite overlays are BACnet and XML, but even these can be said to incompletely address concerns about security and standardized device model representations. But again, one can overlay, and for those who do not even understand what a “standard device model representation” might get them, they can have Modbus now, and deal with that issue later, once their understanding deepens.

Dealing with Modbus “now” is what it is all about. One way or another, with a public Modbus profile of implemented functions, and register map, for a device, one can get connected and talk to it. Systematic functional understanding can be overlaid as one learns.

Some have taken up the Modbus banner. Temco controls has done so in fine fashion http://www.temcocontrols.com/ .

Most meters have Modbus interfaces. Here are a few (in no particular order and without effort to be complete):
http://www.electroind.com/shark.html
http://www.eaton.com/meters
http://www.powerlogic.com/productcategory.cfm/c_id/1

Appliances that consume electric/gas/water (washer/dryer) and all things renewable (solar, inverters, wind, nano-hydro) should take up this banner. Appliances do not appear to be going towards HANs fast in any case. But the Sunspec Alliance http://www.sunspec.org/ is notable for placing at least some basis on Modbus (as well as more forward looking XML).

See my recent article in the December issue of Automated Buildings on making a small BACnet device where Modbus as a stepping stone is alluded to http://www.automatedbuildings.com/news/dec12/articles/cimetrics/121122110404cimetrics.html .

RS485 Rule of Thumb: N x L x kB x P < 485

RS485 rule of thumb: N x L x kB x P < 485
This is for RS485 bus architectures like those for Modbus RTU, BACnet MSTP, Johnson Controls N2 and so forth.

N x L x kB x P < 485

Where

N = the number of quarter (or less) load devices. If using older full load devices then consider each device as four devices. For example three quarter load devices plus three full load devices and two sixteenth load devices would mean N = 3 + 12 + 2.

L = the length of the line in 100m multiples. For example 1000m (1000yards) means L=10.

kB = the speed in kBaud. For example 9600 baud would be kB=10

P = The problem factor. P is a number which is usually unity when all the line characteristics are well conditioned. Double it for poor biasing. Double it for poor termination. Double it again if runs are close to motors or transformers. Double it for improper capacitance. Double it for poor twisting. Double it for ground faults like poor/weak or multiple grounding.

So a 100m line with four quarter loads running at 20kB with a couple of problems P=4 (320) is probably okay. But a 1000m line with ten quarter loads running at 10kB with P=1 (1000) is likely problematic.

[Updated 2012.09.19 by rescaling L to make the arbitrary number '485' easier to remember.]