Industry analysts have called IoT (the Internet of Things) the third wave of the Internet and estimated that its impact on the global economy will reach as high as $11 trillion by 2025. Yet, this wave has been slow to materialize. In our previous post, we wrote about some of the business reasons that IoT solutions are hard and parallels with past industry transformations.
In this article, we will start to dive down into some of the key design challenges that make IoT hard. This is the first in a series of articles that will take us all the way from exploring IoT design concepts and strategies, to understanding how to overcome common implementation gotchas.
IoT Design:The Four Factors
When designing any IoT system, there are four key factors required to produce high quality data: Trust, Identity, Time and Chain of Custody. In Bright Wolf’s experience with helping customers save or reboot IoT initiatives, these four issues are the most frequent reasons that customer projects didn’t operate as intended. One needs to take each of these factors into account in terms of your system design and overall integration architecture. Considering the four factors upfront will set the stage for a viable IoT system.
Trust: The Fundamental Foundation
The first Design Factor is trust. Trust is the fundamental foundation of any IoT system. Trust in this context means that you know you are talking to the right device and that the device knows it is talking to the correct end system. This might sound simple, but seemingly trivial mistakes can erode the ability for consumers to trust data from your IoT system. This foundation of trust is critical to avoiding issues such as spoofing devices, or thinking you’re sending a command to one device when you actually change a set point on the wrong device, causing an undesirable action.
Nothing in the entire system can work unless you can set up and maintain a trusted communication capability. Once established, and we’ll talk more about this in future articles, you can start to build on your Trust Foundation with the three pillars of Identity, Time and Chain of Custody.
Identity: Recognizing the Right Device
The first pillar is identity. Identity is used for associating incoming data with the correct time series history as well as for addressing messages to the correct device. Additionally, identity is critical for integration with enterprise systems.
Think about a device you have in the field. If this device has a serial number, you probably associate that serial number as the device’s identity. However, this device may be attached to a larger device that has its own identifier, such as a piece of heavy equipment or a tractor trailer. The device will often have a number of subcomponents that are also serialized and may be subject to recalls or critical firmware update notices.
You’ve assigned an identity to this device that represents the device as it was built. When the device has a long life, some components get replaced. Now, the “as built” identity and the “as is” identity start to differ. The assigned identity of that device is no longer correct and therefore the identity is questionable in term of delivering accurate information.
Perhaps you’ve heard the classic broom analogy. If the head of the broom wears out and you replace it, you still have a broom. When you break the handle and replace it, it’s still a broom. After you do this several times, it’s still a broom, but none of the pieces are the same. The same sort of thing can happen with devices, particularly large pieces of equipment. Over the lifespan of a device, identity ends up being a complex, ever changing tree.
An example of this is a refrigerated trailer running devices that deliver data on temperature control to the system. The trailer has a number painted on its side, so that’s where end users of the system think all the commands are being sent, and they consider history to be associated with the trailer number. To the customer, that number is the trailer’s identity. The actual refrigeration unit on the front of the trailer may not change, but the serial number of that device collecting and offboarding the data may change. The antenna and radio module that communicates back to the cloud may break and be replaced, much like replacing a broom handle. These changes don’t impact the end customer’s concept of the trailer’s identity (it is still their broom). However, they do impact the datasources that need to feed that trailer’s data streams (a new handle).
The concept of identity is very fluid, and is critical to ensuring that when you’re sending commands and receiving data that it be associated with the right device and location.
Timing: Synchronization is Crucial
The second pillar based on the Foundation of Trust is time. An accurate time stamp for each event and datapoint is crucial to data quality in IoT systems. When you have remote devices that change locations, or devices where the user can set a clock and may not adjust it regularly, for example daylight savings time changes, the event time for each datapoint can become suspect. Getting your reported data into correct order, and knowing what time zone that device was in when it performed a particular operation is essential to collecting accurate data.
The issue of time is especially significant when dealing with datasources that may be cached and reported in well after the recorded events. In these cases, you need a way to insert the data received into each time stream of data. Typically, not all devices have the ability to use NTP (network time protocol) or use a synchronized time source such as GPS. In many topologies, IoT devices collecting the data have no true source of time. This data is often communicated over many hops (such as a mesh network) before eventually landing at a gateway that has access to a synchronized clock.
The ability to sort out the critical data and understand when an relevant event or incident happened in the overall time stream is crucial to the trustworthiness of the system.
Chain of Custody
The third pillar is chain of custody. If you happen to watch any crime dramas on TV or Netflix, you are likely familiar with the term “chain of custody.” In legal contexts, chain of custody is defined as “the chronological documentation or paper trail, showing the seizure, custody, control, transfer, analysis, and disposition of physical or electronic evidence.”
The same concept applies to IoT devices—you need to understand the complete history of each datapoint, including details about the device and the software that processed the data. As an example, let’s say that you have a garbage dumpster equipped with a sensor that provides an alert when the dumpster is full.
The sensor on the dumpster is connected to a sensor board powered with a 9-volt battery that communicates once a day and has no clock. There is software running on that sensor board that communicates over a mesh network to a concentrator gateway box. That box has software running on it that caches data from many nearby dumpsters and sends the collected data over a network to a backend server.
The data flows through multiple levels of processing, at which point a program on the server receives the raw bytes and tries to parse them with a version of software to figure out what they mean. After parsing, those values get stored in a database and get interpreted by an algorithm, which may send an email, or call an enterprise system and say, “Hey, dispatch a garbage truck because that dumpster is full.”
If there is an error anywhere in this process, a garbage truck may be dispatched to the wrong, still empty, dumpster. Now, the chain of custody is critical to not only finding the error, but also assessing the scope of impact in the population of fielded sensors. An example of an error source might be a bug in the mesh network code base, which triggers an interaction between the sensor board running a specific version of firmware and a gateway board running a specific version of firmware. Another example, might be a bug in the server software processing the incoming payloads.
Maintaining the chain of custody for every device will allow you to:
- track the data, keep it in order to know which device it came from
- understand the exact software versions along the chain that had the ability to manipulate the data
- know what software version are running in the field so you know how to filter the data (both newly incoming data and previously received data)
- understand the scope and impact of required field service actions, such as Over the Air (OTA) firmware updates
Any break along the chain of custody will hinder your ability to collect, analyze or debug the data leading to a less robust, unstable system in the long run.
The IoT Bottom Line: Accurate, Actionable Data
Building a trusted foundation for communication and doing the upfront work to ensure the system’s data integrity in terms of identity, time, and chain of custody should be core to all IoT systems. It’s this upfront work that many without true connected systems experience don’t fully appreciate after completion of a prototype, but is absolutely critical to building a robust production system.
Think of the End From the Beginning
These challenges make it critical to build an end to end, well-integrated IoT system right from the start. Our experience at Bright Wolf spans the entire design, development, and deployment lifecycle. By preventing the introduction of problems upfront you avoid taking a revenue hit in terms of rework and higher support costs down the road.
Stay tuned for more about techniques, design styles, and lessons learned. If you’ve got any questions or a particular challenge in mind, contact us and let us know how we can help.