It’s not in the dreaming, it’s in the doing.

—Mark Cuban

Internet Protocol Smart Objects (ISPO) have the potential to provide much better interoperability for Internet connected devices, by standardizing the data (and the meta-data) exchanged between those devices. While the market has seen an explosion of new IoT devices, the vast majority can not "talk" to each other in any meaningful way, since they don't know each others data formats and device capabilities. Internet Protocol Smart Objects (ISPO) outlines several "Smart Object" classes for sensors and actuators with well known data formats. For the past several articles, I've been discussing Device Trees and their application in describing the hardware capabilities of various embedded platforms, which seems to be exactly what we need to automatically generate the directory of Internet Protocol Smart Objects (ISPO) for IoT devices. I think it's time for Smart Objects to meet Smart Device Trees...

The development (and deployment) of new technologies usually occurs in phases, often as applicable standards begin to become mainstream. The HTML standard spawned the first phase of the Internet, followed by the "Browser Wars" of the late 1990's. As the Internet matured to "Internet 2.0" and beyond, much of those early proprietary HTML enhancements were replaced as the HTML 5.0 standard was adopted, and we began to have much better web browser interoperability and usability. Unfortunately, the "Internet of Things" as it stands today, is about where we were back in "Internet 1.0", but that is beginning to change as new standards like Internet Protocol Smart Objects (ISPO) are becoming adopted.

Beyond Simple Protocol Compatibility

Much of the effort around creating the "Internet of Things" to date, has been focused on developing standards to carry data to and from "the Cloud" to "edge Devices", using various connectivity protocols. Both CoAP (RFC-7252) and MQTT have emerged as useful IoT connectivity protocols. Unfortunately, these are only connectivity standards and they do not specify the format of the data or meta-data tranferred using them. It's like asking for the temperature in the English language in Fahrenheit, but getting a response in the French language in Celsius. Unless you speak French, you received the information, but can't comprehend it. This illustrates the heart of the problem for IoT designers today.

Internet Protocol Smart Objects (ISPO) were designed to facilitate data exchange and interoperability by providing a common object model, consisting of a URI template and known data types. Internet Protocol Smart Objects (ISPO) can be likened to web pages for devices, employing consistant data types for RESTful web objects. Some of these IPSO objects are quite specific, like :

• Temperature sensor
• Humidity sensor
• Illuminance sensor
• Accelerometer
• Magnetometer
• Barometer
• Presence sensor

While others are more generic :

• Digital input
• Digital output
• Analog input
• Analog output
• Power measurement
• Actuation
• Set point

The Internet Protocol Smart Objects (ISPO) "Starter Pack 1.0" includes both the object definition and data format, allowing for a meaningful exchange of information.

The Internet Protocol Smart Objects (ISPO) is fairly new, with the release of "Starter Pack 1.0" in September 2014, so it is just beginning to be adopted. While reviewing the code for several of the first implementations, I was struck at how much of the same functionality was already present in the work I have been doing on Device Tree and Smart Device Trees. So, I think it's time that we introduced the Internet Protocol Smart Objects (ISPO) to Device Trees, because I have a feeling they are going to get along really well with each other.

Why employ the Device Tree?

Because the information that an embedded system needs to create a Internet Protocol Smart Objects (ISPO) directory of "Smart Objects" is already contained within the Device Tree, and can be retrieved using the existing Device Tree parsers. Unfortunately, most of the (early) IPSO examples that I have seen to date, duplicate this meta-data, and so the developer would need to maintain it within two (2) separate areas of code for an IoT device.

In some of the next articles, I'll describe some methods to leverage the meta-data contained within the Device Tree, and to use that data to automatically generate the Internet Protocol Smart Objects (ISPO) directory of "Smart Objects". Stay tuned...

References, Footnotes, and more...

1. Device Tree for Dummies - Thomas Petroni
2. BeagleBlack Device Tree Tutorial - Adafruit
3. Xilinx Device Tree Tutorial - Xillybus
4. Altera Device Tree Tutorial - Xillybus
5. ARM Device Tree Support - Ubuntu
6. Altera Device Tree Support - Altera
7. Index of Device Tree Bindings - kernal.org
8. Device Tree Graphing - kernal.org
9. libfdt - manipulating FDT Blobs - David Gibson
10. Linux Bootloaders - informit.com
11. Device Tree PnP - Eli Billauer
12. Device Tree Overlay Manager - Pantelis Antoniou
13. Device Tree Overlay Proposal - Grant Likely
14. BeagleBlack Univeral I/O - cdsteinkuehler
15. BeagleBlack Device Tree Overlay Generator - Kilobaser
16. GPIOs on the Beaglebone Black using the Device Tree Overlays- derek molloy
17. Supporting 200 Different Expansion Boards - elinux.org
18. DT, The Disaster so Far - Mark Rutland
19. Board File to Device Tree Migration - Pantelis Antoniou
20. Device Tree Overlays - Jonathon Corbet