Part of IEEE 1451 is TEDS – the transducer electronic data sheet, data held in embedded memory or a virtual file so a sensor can be queried over a network to get identification, calibration, and other information. As it turns out, the idea behind TEDS is one of the most crucial concepts for IoT interoperability, even if the TEDS definition itself fell short of broad applicability. Several more IEEE standards were spawned, most notably the recent efforts of IEEE 2700, and numerous other industry-sponsored specifications and more open technology for data interchange such as JSON have entered the IoT fray.
Creating a truly smart sensor in a large IIoT implementation means more than adding a microcontroller and a wireless sensor network interface to a basic sensor. That approach works in small implementations, but according to Chonggang Wang, editor of the IEEE Internet of Things Journal quoted in a March 2014 article by Kathy Pretz, bigger sensor network implementations need to be SMART:
• Scalable and robust and provide custom information at appropriate periods and in suitable data forms, as required by different applications and services.
• Monitored and managed easily; if software on remote sensors must be updated, the sensors need to be discoverable no matter where they are.
• Adaptable to the sensors’ changing conditions or context while being able to talk automatically to other sensors.
• Reliable. Data uploaded wirelessly to a cloud must be dependably transmitted and reported.
• Trustworthy. A mechanism is needed to ensure data are not being manipulated while in transit and that only trusted parties can access sensitive data.
In this “Smart Connected Universe” diagram from Sidense, we see the concept of SMART extending across all three tiers of the IoT – edge, gateway or hub, and infrastructure or cloud.
We also see OTP memory on every node. Why OTP instead of using EEPROM or flash memory? It’s a question of the most efficient, robust, yet cost-effective implementation in customized IoT chips with OTP IP added at critical points.
At the edge, the identification and calibration information for analog sensors can be loaded into tamper-proof OTP memory, reducing the risk of a glitch “bricking” a flash-based device or worse yet leading to corrupted data being propagated. Edge devices also usually require some type of key for secure communications, and OTP memory can be used to emulate a multi-programmable space for keys that are tamper-proof yet modifiable if they ever need to be changed due to a breach or a protocol upgrade.
Gateways are the point of provisioning and must deal with both networking configuration and security. OTP again offers tamper-proof storage for network tables and keys, and additional configurability for sensor fusion tasks. For example, a gateway might hold support for several different sensor types, allowing their data formats and operating curves to be blended accurately. By keeping these elements out of general-purpose flash, the possibilities for hacking an unauthorized sensor onto the network or corrupting authorized sensor data streams are reduced.
Security looms large in the infrastructure. A popular IoT configuration is the hybrid cloud, where public cloud elements manage presentation while private cloud elements deal with analytics and storage of data. Establishing trusted compute nodes relies on tamper-proof keys that can be reconfigured if the network is compromised.
A purpose-built SoC with OTP memory provides unique capability in security, networking, and data integrity – customizable to the needs of IoT implementations. OTP can differentiate an IoT chip at lower cost and less power than a comparable EEPROM solution, and with high temperature capability OTP can go where embedded flash has difficulty in long-term data retention. OTP naturally fits in edge devices, but also can help IoT gateways and infrastructure in ensuring the end-to-end integrity of implementations, particularly over a long IIoT lifecycle as standards and devices continue to evolve.