IoT at Scale: Data Context & Access Controls

While the very essence of edge computing and IoT is decentralization, one almost universal purpose across this space is to ensure that apps in the centralized data center have access to the decentralized devices and data, both for the purposes of system administration and analytics. It is common for centralized access to be one of the main drivers for return on investment (ROI). Equally important is the ability to update, reconfigure and monitor the network remotely from a centralized operations center to control administrative costs and reduce the number of truck rolls per location. For these reasons, it is important to keep centralized access top of mind at the beginning of an Edge/IoT project.

The data context challenge

Consider the scenario depicted in Figure 1 below. In this example, a company wants to remotely monitor the health of oil pumps working in oil fields from a centralized analytics system in their operations center.

The team has identified a set of business outcomes that require an IoT solution, and a primary use-case to drive it forward. They have narrowed down the tech stack options, consulted with suppliers, and drafted a lifecycle management strategy. Initial due diligence has been completed, and it's time to build out a roadmap for that first proof of concept!

This is often the moment someone on the team asks: How do we know what the incoming data means? At first this can be a confusing question. The root of the problem this insightful team member is trying to understand is this: How do we ensure that we can provide the context that gives data value? An excellent question, and to add to it for the purposes of this article: how do we do this in a way that can scale up?

Consider an example depicted in Figure 2 below where a temperature sensor is telling the operations center that it's currently reading 150 degrees.

The fact that temperature "Sensor A" is 150 degrees doesn't mean anything by itself. The operations team doesn't have the context that makes that information valuable. With a hierarchy system in place they can instead be made aware of what this indicates: The pump at site B is overheating. That is the essence of data context. The operations team intrinsically knows what to do about that. They know where it's located, what the problem is, and they can easily create a work order to roll a truck to service it.

Context at scale

Every system starts with 1 device. When there is only one device in the system it's easy to provide the data context through simple labeling techniques. For example, labelling a device as "Temperature monitor on pump 3 at site B" will tell an operator everything they need to know to interpret the data coming from the device and physically locate it when it needs maintenance.  

Fast forward into a future where the system has 10,000 devices of all different types, in all manner of sites/factories/ships with large, complicated footprints spread out across multiple geographic locations. Imagine how you might make sense of the data coming from your distributed network with a flat ad hoc tag & label system. It conjures visions of endless SharePoint directories controlled by naming conventions that have been passed down from team to team, survived reorgs, and are generally unable to be navigated by anyone except that one guy who has an electronic countdown calendar sitting at his workstation labeled "days till retirement."

Better solutions exist! But before we get to that let's talk a little bit about what IoT and edge computing devices are to a business.

The asset hierarchy

IoT and edge computing devices are business assets or components of business assets, and often they monitor or control other business assets. While the idea of edge computing and IoT is rather new, the idea of an asset is a well-established concept within most businesses.  

Businesses put a lot of time and money into managing their assets. They have operations teams to plan how to use them and maintain them. They have ERP systems and various other tools that assist in their lifecycle management. With all this activity around assets it will probably not surprise you to find out that there are common frameworks for describing them, often referred to as the "asset hierarchy." Asset hierarchies are how Operations & Maintenance teams keep track of their assets under management. Figure 3 below gives a good example of what an Asset Hierarchy model (also sometimes referred to as a Digital Twin) looks like.

There are many different sets of international standards created around the proper way to classify assets. For example, ISO 14224 is the Asset hierarchy standard for the petrochemical industry. This standard defines a hierarchal pyramid 9 layers deep. The top 5 layers determine physical location, and the bottom 4 define the subdivision of unique assets into components and parts. Not all standards are so rigorous, but regardless of how detailed the standard is, correctly classifying thousands of assets and their relationships to the company infrastructure is a monumental task. Achieving this is often a major differentiator in the effort to derive value from the system.  

Advantages of the asset hierarchy

Data Context: What the data from the device means to the teams using it.

• What kind of device or asset does the data belong to? Edge systems are often a platform for many different types of devices and/or assets. Devices can be generating data about themselves, or they can be generating data about a different asset or processes. In the example in Figure 4 the temperature sensors are generating data about pumps they are monitoring, but this could just as easily be a camera feed monitoring a point-of-sale system.
• Physical location matters. The ability to physically locate the device/asset within the hierarchy is important since all types of edge deployments will eventually require a person to interact in some way. Knowing physical location is also useful in cases where analytics systems need to be able to show data by location. Example: filtering a User Interface to only show data from a certain sales territory or country.

Access Control: Defining who has access to the data/control functionality provided by individual edge resources.

• Multi-tenancy requires that a hierarchy system be in place to separate system tenants and identify which tenant(s) a user belongs to. This is often necessary even within a single company to properly implement the longstanding IT security principle of least privilege. In the example in figure 5 Rick has access to the company-wide data because that is necessary for his role. Paola only works at site A so her access is restricted to site A data only.
• Traditional access control approaches become cumbersome when trying to use them to control access for hundreds of different users across multiple organizational verticals to data from thousands of different edge/IoT resources. At scale it becomes necessary to control access by logically grouping the data/controls from these edge resources and providing users access to the groups instead of individual resources. Asset hierarchies provide a useful structure for such grouping and are often the best corollary method for access associations because of how well they align with traditional organizational structures.

Summary

Having a hierarchal mapping of physical infrastructure allows software teams to build out digital twins of the world that distributed computing infrastructure is deployed into, and gives the data coming back from those systems the context the business users need to act on it. It also allows us to logically segment the system tenants and thus relieve information overload and alarm fatigue, improving the usability of the system.

In the system state presented in figure 6, only workers at site B need to get an alert about the temperature alarm. To the workers at site A this is just noise. Likewise, site B will want to deploy updates and configuration changes to their system during planned maintenance periods which will likely not align with the maintenance period for site A. The ability to target updates to these individual groups is a major scaling factor.

These are the kind of controls and transformations that a well-designed asset hierarchy system can enable.

It's beyond the scope of this article to dive into the pros and cons of individual tools that exist to assist with this type of management. The goal of this article is simply to highlight the impact this important scaling factor has on future system usability and ROI. If you take some time at the beginning of an edge or IoT project to consider how scalable data access and context are important for the user experiences your application needs, you will likely create a more flexible system that is easier to use and requires less modification in the future.

WWT provides a full suite of Product Ownership and User Experience services that can help get these kinds of projects started on the right path, as well as COTS software products and custom software services that can bring these solutions to life. Feel free to reach out with any questions. We are happy to help.