Following on with the Four Critical Design Factors to consider when building an IoT project for the enterprise, this article addresses the first pillar of Identity. The other pillars, Time and Chain of Custody, are discussed in future posts and lay atop an all-important Foundation of Trust, We can define Identity in a few ways: a sameness in all that constitutes the objective reality of a thing, the distinguishing character or personality, or the fact of being who or what a person or thing is. In reality, Identity is often a matter of perception, depending on one’s point of view or sense of belonging. This perception of identity is also relevant when it comes to device identity in an IoT connected world.
One Device, Three Points of View
There are three groups that have a stake in device identity, and each may have a different perception of what it means:
The Maker – The maker needs to know how to identify the device so that the customer can send commands to it. They need to know how to integrate the device into the IT enterprise. The maker must also know how to identify the various components that make up that device in order to perform activities such as predictive diagnostics and product recalls.
The Customer – The end-user or customer sees identity more in terms of what the device is attached to. An example here is a refrigerated trailer. The customer identifies the trailer by the six-digit number painted on its side, not the MAC ID of a Wi-Fi device or the network ID of a cellular-connected device.
The Third Party – The California Air Resource Board (CARB) is a good example of this third group. The CARB enforces clean air regulations for operating refrigerated diesel trailers, and require owners to register a unique number (CARB ID) that is then tied to the vehicle identification number (VIN) number of the trailer. Certain CARB regulations require access to telemetry data of the trailers (by CARB ID) to prove compliance.
The maker identifies the trailer by the serial number assigned to the device. The customer maintains an internal database table that says this trailer’s VIN number is actually the six-digit number that’s painted on its side. And the regulator may recognize the trailer by yet another number aligned with the VIN.
Why does it matter if these groups perceive identity differently? It’s the difference between clean data and dirty data – the difference between data that can be used within the system, and data that cannot be trusted.
Identity is Fluid
Our refrigerated trailer already has three personas. But now let’s say that this trailer is in an accident. While the physical trailer might be totaled and taken off the road, the telematics device, the “thing”, may survive. To save costs, the old device is often installed inside a new trailer (either fresh off the line or one whose own device has recently failed).
Now, our device is associated with a new 6-digit trailer number. To the end user, Trailer A was destroyed in a wreck and Trailer B replaces it. To the seller/maker, the device, let’s call it 1-2-3, was associated with Trailer A, but now it’s associated with Trailer B. The history of those sensors coming in for Device 1-2-3 are now reporting data on Trailer B, a completely different entity from the customer’s point of view. The challenge is to ensure that the data flows correctly and that Trailer B doesn’t query into the old data. So, if the user is querying the last 30 days of Trailer B, and device 1-2-3 has only been installed in Trailer B for two days, the customer should not see any Trailer A data.
The shift in identity can also happen in reverse, where Device 1-2-3 is damaged and replaced with Device 4-5-6. Now, Device 4-5-6 sits on Trailer B, but the trailer history is now the merged history of two different devices, 1-2-3 and 4-5-6.
This fluidity also comes into play when a fleet operator sells a trailer. These trailers typically have a lifespan of about 15-20 years and may have upwards of three owners during their lifespan. When the first owner sells the trailer, and the new owner wants to maintain the service record, the history of the device must move along with the trailer and even the access control of that device must change. All along the way, if everyone doesn’t recognize the same identity, the data collected cannot be trusted.
Errors Over Time
If all this sounds like the proverbial big ball of mud, it can be. Keeping identity intact is critical, with opportunities for errors only increasing over time. This is especially true in cases of already-deployed legacy systems, which make it extremely difficult to sync data back to an enterprise system to make it clean. At Bright Wolf, we’ve observed and learned to address a number of common identity errors:
Duplicate serial numbers – If a device has a programmable serial number, support staff can inadvertently assign the same number to two devices so that they are in indistinguishable.
Inadequate maintenance – a maintenance person might neglect to program a trailer number into the refrigeration unit, so the device doesn’t recognize its own trailer and reports a default value for its identity (all zeros).
Off by a digit – When the sticker number on the outside of the box is entered into the system with just one digit off, it may create a batch of 1,000 devices that are all off by a single digit. Now, when a customer support call comes in for one of these 1,000 devices, the device you’re looking for in the system is off by one digit. This requires an exception case in the support system, creating a permanent technical debt to deal with this identity.
Boxes inside boxes: The Challenge of Subcomponents
Think about what occurs to hardware components over time. A primary device, such as a pumping mechanism, is made of serialized subcomponents (servos, pumps, etc). As these subcomponents are replaced over time, due to breakage and upgrades, the “identity” of the primary device – in this case it’s physical parts – is altered. Now imagine there is a recall on pumps installed in a medical device. Is your system designed to provide reliable query data enabling swift location and replacement of these pumps throughout your inventory of primary devices?
The reality of how devices are used in the field presents challenges as well. Often, service people will cannibalize machines, harvesting a workable component from one broken device and using it to get a second broken device up and running. This makes perfect sense in terms of customer care, particularly in more remote areas where service calls may be rare. However, from the enterprise system point of view, you’ve just created a Frankenstein machine. This goes back to our broom analogy and the impact on device identity when you switch out serialized components.
You Can’t Ignore the Corner Case
When talking about the importance of addressing identity issues, we hear two objections from makers. The first sometimes comes from their development team, “You are describing a requirement that I have absolutely no way to reference in my system.” The second comes from IT decision makers, who may contend that these issues of device identity are simply corner cases that will never happen, or so unlikely that they do not warrant any investment to address them.
We help them understand why device identity isn’t a statistics problem or just another risk to be mitigated, it’s a dirty data problem that can jeopardize the value of the entire system. And it is precisely because most enterprise systems are not particularly flexible that sending clean data from the start is a must.
Integration: Retrofit Versus Greenfield
Many external systems believe they have uniqueness constraints on some aspect of the device identity, but they’ve never had to roundtrip the data before. In a case where the device was previously unable to communicate live data, reconciliation becomes a huge deal, as the device can’t possibly integrate with the enterprise data until identity issues (for example duplicate serial numbers) are sorted out. To enable your data to integrate into the enterprise system, you have to clean it before it arrives at the enterprise. This is especially true in legacy rollouts, where there will be known classes of issues.
Think IoT Platform in Pre-Production Phase
The fact that different groups refer to a given device differently is intrinsic in the space, which is why it is critical to build a sound IoT platform right from the start. Our experience at Bright Wolf spans the entire development and deployment lifecycle. When we are able to engage Pre-production and work with you to overcome issues during the initial the rollout phase, we can help you establish cost effective exception procedures. By preventing the introduction of errors from the start you avoid taking a revenue hit in terms of higher support costs.
Stay tuned for more about techniques, design styles, and the reasons we do what we do, or contact us to learn more.