From Prototype to Production: Time

Following on with the Four Critical Design Factors to consider when building an IoT project for the enterprise, this article addresses the second pillar of Time. The first pillar of Identity was explored in a previous post, and the third pillar, Chain of Custody, is discussed next. As a reminder, these three pillars must be built atop a solid Foundation of Trust for the project to succeed.

Devices operating in the connected world generate huge volumes of time-series data. To take appropriate action or gain insights from this data, consumers (both human and machine) must understand both the correct sequence and what specific time period each bit of data refers to. Because data comes from myriad devices through a variety of networks with different timing mechanisms, assembling this unified global timeline – a prerequisite for an accurate view of the system – is a daunting endeavor often overlooked by system engineers new to IoT and a leading cause of deployment failures.

If a unified timeline is not achieved, or is assembled incorrectly – if each event did not occur exactly when the system believes it did – then all the analytics engines and visualization tools in the world will produce little more than very expensive and colorful works of fiction. If these insights are taken as truth and used to trigger actions, whether at a technical unit or corporate business level, the outcomes can be disastrous.

Let’s look a few of the obstacles to the assembly of properly ordered data.

It’s the little things

An important difference between Enterprise IoT and many distributed systems projects is that the Internet of Things relies on, well, things. These hardware devices are often designed and developed in coordination with the main software development effort.

The problem is that they are often not coordinated enough.

Because device makers don’t usually see how their device integrates on the far side of the enterprise, they can fail to anticipate the variety of environments their device will find itself operating in – and how the data it is sending will eventually be put to use. As a result, they frequently do not account for the impact Time has on data reliability and the overall trustworthiness of the system.

Time, time, time – See what’s become of me

Computers use Network Time Protocol (NTP) to synchronize all participating machines to within a few milliseconds of Coordinated Universal Time (UTC). In many environments, however, devices may not have access to a reliably synchronized time source. Time values from these devices may be inconsistent with others on the network, potentially rendering the data worthless for downstream analytics. Even worse, misinterpreted time readings can cause real damage to equipment and personnel.

Some devices are designed to capture time from the cellular network or GPS satellite. But whenever the device can’t get a signal, it will continue to record events, and may even deliver them in the correct order once connectivity is restored, but the time of each will be unknown. Some devices lose power periodically by design, as in rail systems where yard workers literally “pull the mains” and physically remove the power source used by onboard sensors as a theft-deterrent mechanism. It is critical that the hardware design match the behavioral designs of the humans who will be interacting with the various parts. By planning ahead, the system can be made to account for these scenarios, and determine and reinstate accurate timestamps for these events after the fact.

Some makers build components that require manual daylight savings time (DST) changes. Device administrators can forget to reset the time, or they won’t do it right away. When there is a delay, all data from such sources will be off by an hour. Correct DST can’t always be automated either, since the machines may not know where they are located. Some devices receive time from a cellular network which may provide only local time without timezone information at all. Unless each device knows the exact latitude and longitude, they can’t be sure they have adjusted to the time standard expected by the receiving system.

Eventually all of this data will be reported to a system that does have access to a reliably synchronized time source. The receiving system knows when the data was received, but may not be able to trust the timestamps for the events themselves. In some cases, using “relative time” can allow for effective after the fact reconciliation. If a device can at least report “I don’t know what time it is now, but the last event in this series occurred exactly four hours ago,” then the receiving system can go ahead and correctly re-set the timestamps for all events in the series – if the device makers have coordinated effectively upfront with the rest of the system team to account for this. In some cases, sensors lack clock-time altogether, and are only able to provide information such as boot count and number of 100-nanosecond ticks since last boot. How are you going to put that back together?

Unless you have identified and properly accommodated each scenario upfront, the sequence of causes and effects will be lost. You can’t just simply pretend you can build them again.

Think of the End From the Beginning

The challenge of devices and networks accounting for time differently 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 errors upfront you avoid taking a revenue hit in terms of rework and higher support costs down the road.

Looking Forward

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.

Related posts