A Giant Sensor Standard

[Editor’s note: update appears at end.]

What if I were to tell you that there was a standard in place – in fact, a relatively old one – that establishes plug-and-play sensor capabilities, low-level sensor module subsystem interconnect formats, communication protocols, and even a sensor web services component? Sounds crazy, doesn’t it? Maybe even crazy good?

Well, if you’re in the mil/aero world, or maybe automotive, using conventional (not so much MEMS*) sensors, you might say, “Yeah, well, what of it?” If not, your response might more likely be, “Wait, whaaaat?”

Today we talk about IEEE 1451 – probably the biggest standard you’ve never heard of. It’s an aggressive and expansive attempt to capture a large number of aspects of how sensors interoperate and interact with the world. Work started in 1993; much of it was complete in the early 2000s. And yet work continues, with updates underway on some components and new capabilities being defined or planned.

I have to say that researching this has been challenging. There’s no single page on the IEEE site that deals with the overall 1451 standard. The standard has many sub-parts, and each of those has a page, but if you want to get the big picture, it’s the classic case of making Google your best friend. All of the useful information I found was places other than IEEE (much of it courtesy of NIST, where the committee chair, Kang Lee, works). And much of it is quite old – and, as I learned, out of date. In fact, as I further learned, even much of what’s on IEEE is no longer accurate. So even though Google is normally a relatively reliable reference, in this case it’s not.

The standard itself, in the way of IEEE, is not available free. And it consists of a number of documents that you have to purchase separately. I didn’t do that**. Then again, there’s so much contained in those docs that there’s no way I could address that level of detail in the space we have here. So I’m going to stay high-level and you can purchase and dig into the docs if you are so moved.

I’ve done the best I could to cobble information together, with lots of last-minute adjustments. I will freely confess that some things may still be inaccurate. I submitted questions for clarification with no response for a month until I was already in the process of writing, at which point there was little time for back-and-forth clarifications. As you’ll see, we’re entering a world that has not put a premium on clarity.

Sensor/Actuator Subsystem Architecture and Acronyms and Standards

One of the challenges in getting oriented in the 1451 world is the rampant use of acronyms. So let’s start with a small subset of them as we define their worldview. At the highest level, a sensor/actuator (or transducer) subsystem can be divided into Transducer Interface Modules (TIMs) – or Smart versions*** (STIMs) – and Network-Capable Application Processors (NCAPs). TIMs talk to NCAPs; NCAPs talk to the network.

On the TIM or on individual transducers is a Transducer Electronic Data Sheet, or TEDS. The TEDS is an important component for providing sensor discovery and a high degree of introspection. Each transducer can have its own enclosed TEDS, or you can use a single TEDS that covers multiple transducers on a module. The information in the TEDS includes “…transducer identification, calibration, correction data, and manufacture-related information.” It’s typically implemented as a small memory on the sensor subsystem board or co-packaged with a sensor.

The way all of this hooks up is covered by the family of 1451.X standards. At least that’s how it’s presented in the working group parts of the IEEE site. If you end up there, here’s what you’ll find (don’t study too hard):

1451.0 covers high-level common operations and a general TEDS format
1451.1 provides a “…common object model and programming paradigm for smart transducer systems.”
Both 1451.0 and .1 communicate with the actual sensors and actuators through a number of communications alternatives that I’ll summarize here. Each of these has a TEDS specification.
- 1451.2 provides a point-to-point TIM-to-NCAP connection.
- 1451.3 provides a multi-drop TIM-to-NCAP connection based on HPNA – the home phone protocol.
- 1451.4 provides a special mixed-mode interface for analog sensors that have analog and digital modes.
- 1451.5 deals with wireless interfaces between TIM and NCAP.
- 1451.6 provides a TIM-to-NCAP interface via the CANopen protocol for safety-critical applications.

Well, turns out this is out of date. If you go to where you can buy the standards, things look different (although you have to search and examine each one to figure this out – I had an advantage in that I was clued in to some of the changes by Mr. Lee.) All of the communication protocols have been adopted (or are being adopted) as a separate set of ISO/IEC standards. Two have been dropped outright. And others have been or are being added.

Why did I bother going through all the historical old stuff? Because if you Google, that’s mostly what you’re going to find. So I wanted to make explicit what the changes have been and why there’s a discrepancy between Internet information and reality. I’ve summarized it all in the following table. Dropped components are included, but grayed out, just so that you don’t feel like you’re going crazy if you see those items in a web search.

For the record, anything in the 1451 family is officially IEEE 1451.x. Anything in the 21450(1) sequence is ISO/IEC/IEEE 21450(1-x). I’ll continue to use 1451 nomenclature in the rest of the discussion.

Getting the (S)TIM and NCAP to talk

The communications formats are low-level and detailed. They may include numerous connection alternatives as well as protocols. To give you a sense of the scale, the 1451.4 standard, by itself, is 439 pages long.

1451.1, 2, and 4 involve partitioning the different functions necessary for a sensor to interconnect to a larger system. These include:

The raw sensor
Signal conditioning (at the analog level)
Analog-to-digital conversion
Application algorithms – the local intelligence and decision-making. These work together with:
- A local user interface
- Local storage
- Finally, a connection to the network.

On the sensor side of things, a certain amount of this is defined as “network independent.” Then, at some point, you hit the “network-dependent” stuff. The partitioning depends on which of the interconnect alternatives is being used. With 1451.1, everything up to the network communication block is considered “network independent.” With 1451.2, the transition between network-independent and -dependent comes after A/D conversion. And with 1451.4, the transition happens after the raw sensor (since the analog nature of this protocol affects the low-level raw data).

At the wireless level, the original intent was to define a specific wireless protocol, but the working group got feedback that the existing standards were adequate. So 1451.5 defines adaptation layers between 1451.0 and WiFi, Zigbee, Bluetooth, and 6LowPAN.

At a high level, it is expected that interaction with the sensor subsystem would happen over protocols like HTTP. Other high-level services are under consideration. NIST has even put together a specific application called Smart Transducer Web Services (STWS) based on 1451.0 and .1. It can be downloaded from SourceForge (the latest version appears to be 2009; a link is provided below). It’s positioned as an implementation of 1451.

The following graphic is adapted from one provided to me by Mr. Lee, and it illustrates the relationships between the different 1451 components. Even though I’ve been using the IEEE nomenclature throughout this piece, it would appear that the ISO/IEC/IEEE nomenclature is becoming more “official,” so I’ve deferred to that format in the drawing.

And this is the level at which I’m going to stop. I know we’ve only scratched the surface, if that, but if this does nothing other than let folks know that this exists and resolve the contradictory bits floating about, then I’m happy.

So where is this going?

My takeaway on this is… mixed. People have clearly done – and are continuing to do – a ton of work on these, and there’s lots of detail available by purchase. But it also feels fractured. That said, the biggest issue in my mind is that there is little industry awareness of this standard – and everyone working on this has a day job, so it’s not like they can individually go market the standard. I was lucky enough to be able to get ahold of accurate materials, but only through ad-hoc personal contact. As far as I know, the up-to-date overview information I have is not freely available to the public anywhere (except here).

I find no greater testament to the lack of visibility of this standard than the independent development of the IEEE 2700 sensor datasheet standard. While that topic might have been a natural component of the broader 1451 agenda, it remains completely disconnected. I asked about that: within the 2700 group, they were initially unaware of 1451.

The 1451 leadership is hoping that the Internet of Things (IoT) will help to drive activity, but I don’t think they’re going to simply be swept along – because of the awareness problem. In addition, I don’t know that they’ve addressed whether this will work for cheap consumer goods. It wasn’t conceived with that as a primary goal. I may be fretting unnecessarily; it could be just fine, but I haven’t seen anything that shows that this can work for consumers. It’s likely to get more traction in the industrial sector (which many feel will be the bigger IoT anyway). But not unless there’s awareness.

So much of the authoritative information is available only by purchase. You have to buy things to see if you want to buy them. Very late, I happened to notice a paper dated March of this year on the IEEE site summarizing the current status of 1451. You’d think that it’s a perfect tool for educating folks that want to know what’s up, but it’s behind a paywall.

If current information can be presented on some open website where engineers and planners can go to learn whether it’s the right solution for them, it has a chance. Then the industry can establish its true value in terms of cost, complexity, and benefits. If the majority of available information continues to be hard to find and either mostly inaccurate or for sale, I don’t see how this can easily join the mainstream.

[Editor’s udate: As of the date this article went live, I heard from Mr. Lee that the NIST website coverage of IEEE 1451 will be updated, including the addition of a current status overview. So it looks like the primary source of open background information for this IEEE standard will be NIST (where Mr. Lee works), not IEEE. The URL will be http://www.nist.gov/el/isd/ieee/1451intro.cfm. (That URL is live already, but the update, per Mr. Lee, may take a few weeks.) Meanwhile, Mr. Lee will ask IEEE to resolve the issue where the 21451-4 description is incorrect. These should be helpful steps.]

[Further update, for anyone that saw this early on, the first figure had some elements that I decided were confusing, so I simplified it. The info I deleted was already covered more accurately in the second image, so nothing was lost.]

Notes:

*Apparently some MEMS microphones have used IEEE 1451.4

**A copy was offered up to me as I was writing, but I didn’t have time to process it. Even so, it would have been more detail than we could cover here.

*** I’m still not sure the difference between a TIM and a STIM. My general sense is that a STIM becomes smart by virtue of having a TEDS. But you’ll also see drawings that include a TEDS, but are labeled TIM, not STIM.

More info (mostly behind paywalls):

1451.4 Manufacturer ID registration

21451-4 (note: title is correct, description is wrong)

1451.5

21451-7