Building a system to get value from the Internet of Things (IoT) or Industrial Internet of Things (IIoT) is a complex process involving a number of very distinct components. We need an Architecture for IoT to define the components which are necessary and sufficient for the system  to deliver value. As I have laid out in earlier papers on the Information Value Chain, an information system only delivers value if it causes real-world action to take place in response to the data it collects. This is what the 5D Architecture does.

Luckily, every IoT or IIoT system needs to perform the same 5 core functions in order to deliver value, and therefore the architecture of all these systems is -- pleasingly -- the same!

A clear, complete architecture matters because without it there is a high risk of developing IoT systems that miss critical requirements and therefore will not deliver the value expected of them. There is a lot of promise of what IoT and IIoT will accomplish, and a lot of talk of different technologies to achieve that promise. Excitement has moved on from 18 months ago when people were delighted at simply being able to collect large volumes of data, sometimes over distances, to lots of talk of Digital Twins, Predictive Analytics and Artificial Intelligence (AI). What all these conversations have in common is that they happen at a very abstract level, and invoke nebulous concepts -- like for instance AI -- as the way to extract value from data. Given the range of meanings these terms can have -- AI has been applied to everything from Siri voice recognition to neural networks -- they are not useful ways to understand what an IoT system must do or what components it requires to be successful. In fact, they are dangerous, because they allow us to think that we understand things that we really do not.

The Information Value Chain shows how to get from events in the real world to delivering value.

The Information Value Chain

Data only creates value if it goes through a series of steps, steps which eventually result in action back in the real world. To do this we need to execute four steps:

1. Collect relevant data about what is going on;
2. Extract the information that is needed for decision making;
3. Make a decision on the right action to take;
4. Take that action.

And in a parallel cycle, we need to continuously improve how we are delivering value in the Information Value Chain and in the underlying process itself.

How does that look when we apply it to IoT and IIoT?

The 5D Architecture achieves the Information Value Chain transformation from data to value through 5 core connected architectural components, and 4 supporting services. Interestingly, I arrived at the initial ideas for this architecture through our work with Clients on IoT solutions and then found  that it exactly corresponds with the Information Value Chain. Great validation -- for both the 5D Architecture and the Information Value Chain!

At a high level, the 5D Architecture:

1. Monitors sensors to collect Data;
2. Analyses these data to Detect or perceive events which we care about;
3. Decides on the appropriate response to these events and Dispatches the action to be taken;
4. Creates value by Delivering the action;
5. Develops greater value by identifying and delivering on systematic improvement opportunities.

Four horizontal services support these core components:

1. In between the core components, data must be Communicated over greater or lesser distances and under a range of constraints;
2. To the extent that human input or action is required, the system needs the ability to Present information in different ways;
3. Data and information from each component must be Stored so that it can be used to audit the actions of the system and to Improve performance of the system;
4. Finally, all of these components must be Managed to provision them, to ensure they continue to perform correctly, and to detect when they do not.

Let's look at the function and key characteristics of these core components, the 5 D's.

Data

Naturally our value chain starts with a component - or more typically multiple components - which collect data from sensors, people and other systems in the real world. Naturally data must be named and time-stamped, but there are 2 critical considerations in Data, overlooking which can cause solution failure:

• Heterogeneity: most reasonably complex IoT solutions will require data from multiple sources, and frequently from people as well. While some of this data can be provisioned by installing new sensor networks, much of it will come from already existing infrastructure, who's primary function is not to provide data to IoT. This will be the case for many years, if not decades into the future: critical equipment, especially in manufacturing, can have a useful life of 20 to 30 years in some cases. To meet this challenge, it requires that the 5D Architecture deploys a variety of data collection components which can collect the data as it currently is, from where it is available and in a fashion that accommodates to the data source rather than the IoT system. Think legacy PLCs, log files, data historians, sometimes even serial communications.
• Latency: a key measure of quality for data collection is the latency between when an event occurs and when the data collector reports it. The longer the gap, the longer a problem will continue before the system responds to it, so less is obviously better. Where there is a choice, this means that direct connections to PLCs, equipment and sensors is always the best solution, followed by log files, polled databases and historians, and human input always a last resort. Pragmatism is the name of the game in the Data component.

Detect

Detection is what is called perception in cognitive science. Perception (from the Latin perceptio) is the organization, identification, and interpretation of sensory information in order to represent and understand the environment. The  Detect component filters the torrents of data coming into the system to find the events that affect outcomes we care about, and then determines how those events and outcomes are linked so that we can act on this information with confidence.

Detection is Fraysen Systems' particular area of focus, and the one most often missing from IoT solutions before the 5D Architecture. There is a hope abroad in many circles that dumping large volumes of raw data into data stores and then invoking magic, such as AI  will compensate for the omission. As I explain in the papers below, they don't.

Our key measures of quality for the Detect component are:

• Determinism: As I explained in my paper "Data Engineering – Only Some Data Matters," data only matters in an IoT system if it indicates an outcome that itself has value. In a complex environment where many agents are interacting in non-linear ways to shape those outcomes, separating the data that does matter from the rest -- often the overwhelming majority -- is challenging. The better our Detector can do this, the more it can be said to be deterministic - i.e. the same outcome is explained in the same way every time it occurs.
• Observability: Determinism, however, is critical but not sufficient. The Detector must also clearly show the mechanism that connects the data to the outcome so that the explanation can be verified. Without the ability to verify an explanation, it is very difficult to justify taking action, and often dangerous to do so. As I explained in this paper on Digital Twins, to be verifiable, the mechanism connecting our data to the outcome must be observable. To be observable, you must have a model of the mechanism connecting the data to the outcome, and know the state of that model. Think of it like trying to explain why sometimes a car goes 30 mph when you floor the accelerator, and sometimes 70: you need to know that there is a gearbox in the drive train (know the model) and that in the first case the car was in 2nd gear, in the second in 5th (the state).

Dispatch

Dispatch is the process of selecting the right response to an event, and then arranging for that response to happen. This is the 5D Architecture component in which machine learning can deliver great value by mapping an event identified by the Detect component to the historically most successful response to that event. The Dispatch component then typically uses a business system, such as an ERP or Preventative Maintenance system to create the response to the event. This response may be a work-order, instructions and parts kit for required repairs, or a delivery of supplies, or rerouting traffic around a congestion. The key concepts for the Dispatch component are:

• Decision: what is the right thing to do? We want the Dispatch component to make the right decision as often as possible. To do that the component needs feedback -- what was the ultimately correct response to a given event; and learning -- the ability to evolve its choices in the right way as new data about good and less good choices comes in.
  
  • Human input may be required: presenting the human with a set of weighted possibilities takes advantage of the best attributes of human judgement and computerized number crunching.
  • For feedback to occur, we need all actions taken by the Delivery component to be unambiguously linked to the event they are responding to. This is challenging because this feedback loop spans 3 architectural components: Detect, Dispatch and Delivery, and often includes 'off-the-shelf' business systems within those components.
  • Responses need to be coded consistently, so that when the IoT system recommends A, but B was ultimately found to be the better response, the system can actually learn from it.
  • The way in which the system learns in response to new circumstances is as critical as its ability to learn in the first place. If B is found to be the right response to event X after 100 occurrences where A was the right response, then does the right response now become B, or does the Dispatch component continue to recommend A? This is very much dependent on the domain and the type of decisions being made: anyone who suggests that a generic machine learning engine can just ingest large volumes of historical data and spit out the right answer in every circumstance or application is just kidding themselves.
  • A weakness of many machine learning technologies is their inability to deal with parametric data as inputs to their decisions -- they can decide what to do if a test is passed or failed, but not if the result is 98.6, 100.7 or 102.5. This is important, because in the real-world, systems do not transition abruptly - one moment good, the next moment bad - but gradually. A good rule of thumb is that parametric data is 10 times more valuable than categorical data. Not being able to use it throws that value away. This puts an onus back on the Detect component to categorise what it perceives into much richer categories than just good or bad, capturing shades of gray, just as Shewart Control Rules do, and on the Dispatch component to asses degrees of importance and urgency. Again this is an ideal application of human-machine symbiotic decision making and machine learning.

• Planning: making sure that the selected response is going to happen. This is a common function of many business systems, whether ERP, Preventative Maintenance, or Customer Support. The critical issue which is not always addressed by these systems is that the same response must be consistently identified in the same way, so that over time the Dispatch  component can learn which response best addresses a particular event. The concept of a portfolio of formally identified response plans is useful here.

Deliver

The mechanics of the Deliver component is very much domain dependent, ranging from a technician picking up a spare kit and repair plan on his or her way out to the production floor, to a truck replenishing feed at a farm to a server pushing new settings to a remote filtration system, wind farm or solar array. From an IoT perspective, though, there are two key requirements for the 5D Architecture, as already noted above:

• The action taken must be consistently named, so that the same response always gets the same name; and
• The action must be linked to the -- also consistently named -- event that triggered it, so that a learning feedback look can be established by the Dispatch component.

Develop

The 5D Architecture must support the Development and improvement of both the IoT system itself, and of the business process it manages. What are we looking for here?

• Opportunities to improve IoT system:
  
  • Timeliness of Data collection;
  • Detection of issues and events;
  • Delivery of actions: shorter time to closure, lower cost. Notice that we do not have to look for improvements to Dispatch here if our Dispatch component's decision making is machine learning based.
• Opportunities to improve the performance of the underlying process:
  
  • Highest value impacting losses;
  • Differences in performance between similar machines, processes or groups of people;
  • Wasted time;
  • Process capability.

Notice that these opportunities are not simply the presentation of a set of Key Process Indicators (KPIs) -- although picking and consistently using the right set of KPIs to generate alignment and highlight opportunities is fundamental to business success; nor is it simply providing Engineers, Operations Analysts or Data Scientists with a pool of data and access to ad-hoc statistical analysis tools. Development is not merely about access to or presentation of data, no more than that is the cases for 5D Architecture as a whole. Rather it is about the routine, systematic harvesting of historical data to identify consistent and predictable opportunities for improvement which can then be turned into action to deliver value. It is a sister to the Detect component, focussed on a model of the process at a much higher level, which then feeds into the Dispatch and Delivery of improvement projects, just as previously discussed.

The four horizontal supporting services in the 5D Architecture are familiar, and up to now, some of them -- storage, communication, presentation --  have been thought of as core components rather than subsidiary services of IoT systems, or even the end goals of IoT systems in their own right. Why are they supporting services, not core components? In a nutshell, delivering data into a data store, or putting a chart on a screen does not directly create value. In both cases, it presumes that a human, some where, some time, will "do something" with the data. It abdicates the responsibility to create a mechanism to get from data to value, and hopes that someone else will pick up the burden from there. In that way it is not unlike architectures that invoke vague concepts like Artificial Intelligence or Predictive Analytics to bridge gaps in the Information Value Chain -- it is just throwing the responsibility onto people instead of magical technologies. As a production manager memorably once said to me , "So if I don't look at the charts this system presents, the system doesn't deliver any value, does it?"

What are their key attributes?

Present

The 5D Architecture advocates presenting information to humans to support specific human inputs into the Information Value Chain, and in ways appropriate to the context in which the humans are operating and the actions required of them.

What this means:

• Integrated, immersive presentation is the way forward. Humans, especially in complex environments where IoT is expected to deliver value are already overwhelmed with input. They are physically torn between their 'real jobs' in the 'real world' and attending to screens, tablets, phones and terminals. Augmented reality and technologies like Google Glass -- now re-purposed for industrial use -- should be used to integrate information into the natural work process, rather than imposing it on top of, or shoehorning it in along-side a human being's already overloaded environment.
• Minimize latency: information is no good after the fact. Real-time push of information to humans is a must to allow them to act while there is still time to affect the outcome.
• Point people to the action they should take, with recommendations of their best choices. In: alerts, traffic lights, option lists integrated to automated action. Out: charts and graphs which require humans to identify trends and excursions. That's what the Detect component is for.
• Different tools for different jobs: the right Presentation technology depends on the 5D Architecture component it is supporting, the context it is used in, and the interaction required from the human partner. This is why Presentation is shown as a discontinuous rather than a uniform layer.
• Simplicity: unburden the human partner, don't add to their cognitive load.

Communicate

Data must be communicated between each 5D Architecture component. The right Communications technology will depend on the data to be communicated, the physical constraints involved and the source and sink on either side. Sometimes the right technology is as simple as a web service API call, sometimes it involves sophisticated telecommunications technologies to overcome power, distance and bandwidth issues. Since this is very much domain and context dependent, the 5D Architecture will not attempt to prescribe Communications technologies in this paper, but simply set out some principals:

• Resilience:  communications systems should be designed to detect and recover from failure gracefully, rather than on the assumption that failure can be prevented;
• Latency: again, latency is the enemy of timely action. Communications technologies should be selected that ensure that the communications latency between components is much, much shorter that the decision time required of the IoT system.
• Simplicity: communications is merely one part of the 5D Architecture. Configuring, provisioning and managing of the communications technologies should as much as possible be automatic, and implicit in the provisioning of the rest of the IoT system.
• Structure: especially as data progresses through the 5D Architecture, it acquires structure and relationships between previously discrete data items. The communications systems chosen must be able to preserve and transmit this structure.

Manage

Managing IoT systems can be broken down into 3 activities:

• Provisioning: configuring the components to do what is required;
• Monitoring: detecting excursions from correct operation; and
• Repair: causing action to be taken to correct excursions;

In the 5D Architecture, the Management layer is shown as potentially discontinuous. The optimal situation is to have a single, integrated management layer for the entire system. While this may not always be possible, a single management layer is worth striving for. A single, integrated management layer will:

• Minimize support Staff education, since all components and services are managed in the same way;
• Accelerate issue detection and root cause.

Store

Like Presentation and Communication, Storing of data has long been thought of as an IoT system goal in itself. The Information Value Chain shows why this is not so. That said, storing data collected and information created in the 5D Architecture is critical to its success, especially for the continuous improvement function of the Develop component. The Storage service is shown as potentially discontinuous in recognition of the reality that while the ideal is that all data in the 5D Architecture would be integrated, in practice there are sometimes unavoidable discontinuities, especially where existing business systems are integrated into the 5D Architecture, such as to provide planning and delivery management functionality in the Dispatch and Deliver components.

Some key principals:

• Integration: Integrate the data store as much as possible.
• Latency: Minimize IoT system and data store latency by ensuring it is not used as an intermediate communication mechanism between components or services. Put another way: data storage is at the edge rather than in the center of the 5D Architecture.
• Flexibility: Expect that the data to be stored with change over time, often radically. Choose storage technologies and schemas which are data and domain agnostic to as great an extent as possible and which minimize the complexity and effort required to change them.

IoT systems are complex, very large scale and present many pitfalls for the system architect. Thinking about these systems in terms of the problem to be solved: turning data into value; rather than the technologies they encompass: communications, sensors, presentation, storage, analytics simplifies this architectural problem by focusing on achieving a single, valuable purpose. Once this purpose is in front of us, we can break it down into more easily understood steps, and then figure out how to realized them as components of an overall architecture. The 5D Architecture.