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).

BACnet and Internet of Things for Systems Managers.

How are BAcnet, Internet of Things, and their requirements, features and users, related? Apologies to Toby Considine. Just cannot get over Internet of Things.

In building automation who does one try to serve? When one goes through the list - owners, operators, and occupiers - it usually comes to the facilities managers - and being a bit more general about what automation we might be talking about - systems managers. System managers are beset by fear. Fear of disruption from all sorts of directions. System managers crave stability and reliability foremost. Efficiency and optimization comes after that. Systems managers are faced with monumental tasks.

In the Internet of Things wave, almost every facet of how a systems platform goes together are up for consideration... security, manageabilty and interoperation are current hot topics. Alan Messer of Samsung showed a great list at a recent MIT IoT event.

Turns out BACnet, as a lingua franca for building automation, has many of the facets well under control.
Especially well covered: clear semantics, great model and defaults, topology definition, simplicity with extensibility, system setup strategies part of architecture (like discoverability).

And there are things BACnet can be served well by from watching and following IoT. Especially techniques in:

• Location awareness.
• Wireless communications.
• Energy harvesting.
• Social information input.
• Raw simplicity (dumb things, simple networks).

BACnet and IoT presentation at Cimetrics.

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.

 

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.

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