EECS194 – Internet of Everyday Things

Spring 2008

Prof. David E. Culler

There has been a long standing need to standardized information representation for instrumentation.  This page provides some starting points in the background material. The department has an electronic subscription to the IEEE, so you can get to the standards documents from on-campus using IEEE explore.  They are very long and wordy, but they are the reference when you past the tutorial material.

In the 1950s industrial monitoring was revolutionized by the introduction of a "standard" 4-20 mA current loop.  Centralized ADC units connected out to field devices supplying a constant current over copper twisted pairs.  Also sorts of different sensors could be attached as long as they had electronics in place to convert their transducer behavior to modulating the current in the loop: 4 mA representing the smallest value and 20 mA the largest.  This choice made open circuits easy to detect and provided a small amount of power to each device.  The modulated current was put through a precision resistor with the ADC across it.  Sound familiar?

Of course, have an ADC count does not mean that you can intepret the result.  You need to know what that count represents.  What is the sensor modality and what is the transfer function.  How do you map the count to meaninful engineering units.  From the point that instrumentation went digital, it became imperative to define what in modern terms we would call the object and data model for the physical information.  In the industrial world, these are called Application Profiles.  You would call them APIs.  They define the set of operations that devices suport over the network, the arguments and results.  Yes, today you would say - that sounds like its should be an XML schema.

This is the big daddy of the instrumentation standards.  It is huge.  Too huge.    The key element here is Transducer Electronic Data Sheets (TEDS) which are a memory data structure that describes information about the sensor or actuator used in making sense out of the readings, such as calibration coefficients.   It goes on to define networking and object models and a lot more.  It has a tremendous amount of careful thought, and offers a great conceptual framework.  Unfortunately, it seems to have been too complex to become adopted in practice.

HART, 1980, is probably the simpelst of the instrumentation standards.  It was essentially Rosemont's proprietary protocol "opened up" to broaden market penetration.  It is a a sequence of sensor application protocols that grew out of doing primitive comms over the 4-20mA current loops that were place in manufacturing plants since about the dawn of time.  Like many industrial standards it is a 1-2-7 model with the application data representation defined for a particular link and phy.  With the introduction of Wireless HART over IEEE 802.15.4 some of the intermeduiate layers have begun to form. From the viewpoint of the class, the most useful part is the operational model described in the link above.   You can think of each device as a little server, which you issues commands to get/set various attributes.  The key concept is a "Process Variable", which you can think of as the collection of registers associated with a sensor or actuator.  You can set various properties, such as the reporting ranges and calibration coefficient.  And you can get the readings.  There is a fixed set of host->device commands with a fixed binary packet format.  It supports status and device alerts, device ID, calibration and limit setting.  There is also a device description language (DDL) which is their variant of electronic data sheets.  The white papers are pretty light and the specs are pretty expensive.

Bacnet, 1987, is widely used in building automation.  It was orginally developed to run over RS232, RS485 (multidrop serial bus), and ARCnet (a precursor to ethernet).  Ethernet was fold in as part of BACnet/IP, since a transport model allowed some separation from the physical link.  A device is represented as a collection of objects, representing physical inputs, outputs and software processes.  There are 23 standard objects.  Associated with each are particular data structures (i.e., fields or variables) and messages (i.e., methods).  The Object Access Servcies read and write "properties" - essentially get/set of attributes.  Data types, packet formats, and objects are defined ASN.1 - the representation used is SNMP mibs - which provides formal clarity and machien independence.  Unfortunately, it is pretty painful to parse.

Common Industrial Protocol
CIP, 1994, was created in the days of networks, rather than serial links.  Initially it targeted DeviceNet (related to CAN which is in all your cars) and ControlNet  but it recognized early the value of link independent networking.  EtherNert/IP is defined over IP so that it runs on a whole family of links.  It is a mouch more complete object model, where devices are physical instances of classes.  Communication is between objects and is independent of the physical links providing transport.  Oddly, it defines fixed binary encodings of the data tyepes, object types and classes.  It is rather ADA / Corba-esque.  

Industrial Standards Association
The ISA is a broad standards organization addressing alls sorts of different aspects of isntrumentation.  The ISA-SP50 is the analog of the IEEE 1451.  ISA-SP100 is analogous to Wireless HART.

Well if it seems that every 7 years and new industrial monitoring standard is board, Zigbee was right on schedule.  It focuses on 802.15.4 and serves as a marketing organization and defining network protocol.  Probably its most useful contribution is the Zigbee application profiles, now called the Zigbee Cluster Library, which defines a set of binary application data units for various kinds of devices.  Collections of such interfaces are a profile.  The ZCL spec can be obtained here, but you have to fill out their form.

Open Geospatial Consortium
The OGC embodies the view that all of this should be a natural extension of Web Services and XML.  That have indeed defined sensorML, ad markup language for sensor systems.  It is heavily landsat influenced and very complex, but an interesting starting point.