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