Searching for the Edge
Author : Tim Taberner, Advantech Europe
27 January 2022
(Shutterstock image)
‘The edge’ is a hugely overused term in the Industrial Internet of Things (IIoT), but exactly what is it, and more importantly where is it in a system?
Historical confusion
The IIoT is made up of a number of technologies. Sensors, interfaces, convertors, communications and compute elements combine with software applications to make up a complete solution. Each of these disparate hardware elements has evolved from its own industry paradigm and background, and unfortunately for the IIoT architect, each of these technology sectors already had its own definition of what ‘the edge’ meant.
In the most general of definitions, it described where each of their individual worlds ended and interfaced to lower order systems. When cloud or enterprise computer companies talk about moving ‘the edge’ out, they are describing the process of introducing remote, distributed, on-premises servers which provide faster local services to their immediate environment whilst maintaining backhaul links to the main datacentre where the complete picture of the system exists.
For communication companies, ‘the edge’ is the point of presence to which consumers and devices connect. It manages the local connections before passing content to and from the core network.
In automation, ‘the edge’ has been viewed as the point where the real physical world is transformed into the virtual – typically the devices which contain the sensor interfaces from which data is gathered.
Similar situations exist in other technology spaces that merge into the IIoT – everyone talks about ‘the edge’ but often mean very different things. This in turn means each version of ‘the edge’ provides different functionality, has different characteristics and is subject to different conditions and constraints than the others. No wonder then, that things can be confusing.
A more precise definition
Gartner address this confusion by defining multiple levels of edge device:
Whilst omitting to include the edge elements which are part of the communications system interconnecting the layers, this still provides some insights into how the various edge device classes fit into a system and provides some clues into the likely characteristics each demonstrates, especially in terms of compute power, storage capacity and environmental considerations.
Precise but inaccurate
Still however, this is not a clear and definitive picture. In any given system, it is possible, even likely, that one or more levels in the Gartner classification will be omitted or combined within a single physical device. We then also need to factor in the communications system edges, which may also contribute to the processing of data as it migrates through the system.
Let us consider the operations that data is subject to within an IIoT system:
| Operation | Description |
| Raw data collection | Readings from sensors are digitised on a regular basis |
| Data conditioning | Raw data from disparate sources is rationalized into a series of coherent data formats. This may include processing to remove certain artefacts, for example contact bounce on a digital input, or jitter on an analog signal. |
| Data transformation | Raw data (1’s and 0’s) is scaled and converted into engineering units |
| Data storage | Data (raw or transformed) is stored for later retrieval/manipulation |
| Data enrichment | Further semantic data is added to the transformed values to provide self-describing information. For example, a raw value of 101100111010 might be transformed to an engineering unit value of 20.1 and enriched to become the information ‘conference room temperature 20.1 deg C’. Enriching data to become self-defining information is one of the key principles of the IIoT, as it means that any connected system can consume and use the information without needing any further information about where and how it was collected |
| Data filtering | Triggers actions are applied if data (raw/transformed/enriched) meets specific criteria |
| Information Transfer | Data, information, or collections of data/information are packaged and transferred into the wider IIoT environment |
| Business logic | Actions are performed on the recovered information that leads to further insight, derived data based upon multiple input conditions, or control actions |
It is clear that one element, the raw data collection, has to occur at a defined physical location i.e., where the actual base measurement is made. The decision where to perform each of the remaining actions however is completely at the discretion of the system architect. In a very large, geographically diverse system, it may well make sense for there to be physical devices corresponding to every layer within the Gartner classification. At the other extreme, if a system has only to monitor a handful of points and provide a local or remote indication of alarm conditions, it is possible that all the functionality is achieved within the Device Edge layer.
Things become even less clear when one considers that one of the key characteristics of IIoT systems compared to more traditional architectures, is that they do not readily map onto a hierarchical, layered model such as the one proposed by Gartner. Instead systems are defined in terms of a series of nodes, of process elements each with varying assets, capabilities and interfaces. It is the flexible and often unstructured interaction of these nodes which provides much of the potential power of the IIoT proposition.
The role of the architectNavigating this space, either in terms of a hierarchical or multi-nodal model can be difficult, and it is here that the role of the architect becomes paramount. Decisions are made about which elements to implement at which node and how the nodes will interact with each other (which may be in a hierarchical manner in many cases due to constraints imposed by geographical or communications considerations). This, in turn, defines the characteristics and locations of the physical devices deployed to create the system. Of course, in some cases the opposite is true – the physical characteristics of the system and application place constraints on the devices which can be deployed, and this, in turn, guides the architects design decisions around where functionality can be placed.
Understanding the above, it becomes obvious that having access to a wide range of communication and compute platforms from which to select the optimum combination for any individual system implementation provides a significant advantage to the architect and system integrator supplying the system. Put simply, it enables the deployment of the physical devices to be optimised for the requirements of the system, rather than trying to impose a specific architecture or set of devices to address a requirement and thereby compromising the solution.
By carefully considering the distribution of functionality between the various system platforms, it becomes possible to provide solutions that are optimized for cost, performance and reliability, rather than the usual case of having to pick two of these three characteristics and compromise on the third. Partnering with a hardware supplier providing comprehensive and diverse ranges of sensor interface, compute and communication platforms can therefore be the key difference between winning and losing an opportunity, and the subsequent success or failure of the outcome. This is especially true where system integrators are involved in many projects across different industries, applications or environments where having fewer options, or having to source devices from multiple vendors, may limit the reuse of investment already made in providing similar solutions in other systems subject to different physical constraints.
So where is ‘the edge’? I guess the real answer is nowhere and everywhere, it just depends on the specific focus of the conversation at the time. The real trick is to ensure there are enough options available in the architect’s toolbox to draw upon when designing a system that any desired edge processing scenario can be accommodated.
Contact Details and Archive...