Sponsored Article
Is ‘edge intelligence’ the right name?
26 August 2021
In IoT, we talk a lot about ‘edge intelligence’ and the benefits it brings. What is less clear in the context of an IoT architecture, is exactly where the ‘edge intelligence’ actually resides.
Many of the benefits are easy to understand and quantify such as:
• Protocol translation and data aggregation to interface and acquire information from a variety of new and legacy subsystems and convert this to more IT friendly formats
• Local event detection and filtering to rapidly respond to key events, reduce the costs of data transmission and start the transformation of raw data into actionable information
• Local applications and business logic to provide rapid local decision making and autonomy in the case of communications failure
• Key management, authentication and encryption to increase overall system security
What is less clear in the context of an IoT architecture, is exactly where the ‘edge intelligence’ actually resides. This is largely due to the differences between classical automation system architectures and those of the IoT.
In a classical automation system, the ‘edge’ is normally defined as the place where the real world meets the virtual one. It is the point where sensors and appliances interface to the main SCADA (or whichever other acronym suits the application being considered). Once data is in the edge, the whole system works within a traditional ‘command and control’ hierarchical structure. Normally, all data is passed up the stack to a point where a decision is made, and the resulting controls passed back down to the edge. The advent of PLCs and intelligent RTUs allowed for local processes to be managed in the edge with only summary information being passed up the chain, and supervisory commands being returned (for example to change the setpoint of a local flow algorithm), but the architectures, and the corresponding flows of data remained essentially unchanged.
Crucially, the actual data passed around remains in its raw state, leaving the central system to interpret what a binary number coming from a sensor actually translates to in terms of a physical measurement, and the edge to interpret what a change to a binary point value means in terms of its local operation.
The simplicity of this architecture is not replicated in the IoT world. The flexibility and interconnectivity which provides much of the power and benefit of an IoT system results in a much less clear allocation of function to physical device. So, to answer the question of where the edge intelligence resides, we first need to know some of the principal characteristics of an IoT system:
• Data should be able to be consumed by any authorised system. This means that data cannot be passed as simple binary values which require knowledge of the source environment to interpret. In an IoT environment, it is not good enough to send ‘register 123 has a value of 456’. We need to instead send self-defining data, effectively ‘the temperature in the conference room at Advantech’s Eindhoven building at 10:05 on the 17th February 2020 is 21.5ºC’, although, of course, we do this in a less verbose way. This means that any current or future system consuming the data can use it without any paradigm knowledge of how it was created.
• Data should be able to be pushed from the producer to the consumer(s), rather than relying on poll-response regimes from some central system. The producer of data should also have control over when data is pushed, either on a cyclic basis, or in response to some local event, or more normally both. Note that this does not preclude the notion that data may also be requested asynchronously ‘on-demand’ by applications within the architecture, but the fundamental precept is that no resource is 100% ‘owned’ by any other.
• There is no concept of master system and slave (or owned) devices. Systems are thought of in terms of producers and consumers of data, with any individual device being either, or both.
• Devices and systems collaborate to create a defined outcome, rather than being under the direction of an overarching central system. For example, consider a room with a thermostat and a heater. In a classic architecture, a central system would recover information from the thermostat on a regular basis, determine how this compared to a set point and issue a command to the heater to turn on or off accordingly. In an IoT world, the thermostat publishes the temperature without any knowledge of where it will be consumed, or how it will be used. The heater is one of the consumers of this data and uses it (potentially with data from other sources, such as time of day, or room occupancy) to determine for itself whether to turn on or off. It in turn might publish its status, and information on run times or similar metrics for consumption elsewhere. The information published by the thermostat may well be consumed by other devices and systems with an interest in the room temperature, but this is independent of the relationship established between the thermostat and the heater.
• The idea of a ‘device’ as a single entity is also a grey area. In the above example, it would be perfectly possible that the code acquiring the raw thermostat value and creating the resulting published data could reside within the same physical device as the code consuming it and physically controlling the heater via physical outputs, connected internally by the service bus of a microservices architecture. It could equally reside in two separate devices, connected via the IoT architecture. The processes remain independent, but connected, and the question of whether they reside in the same (or different) physical devices becomes irrelevant.
This latter point is key to understanding both the difference between IoT and classical automation architectures, and the reason why IoT systems are so flexible and transformative. There is still a place for appliances, i.e., devices with a fixed function such as a smart thermostat, but higher order devices are transformed away from the model of appliances with a fixed function (or type of function) into frameworks upon which one or more applications run. Some of these applications may be very small, for example to switch something on or off using a physical output as a consequence of some subscribed information, whilst others could be very large, for example providing legacy protocol conversion or AI inference engines. We refer to the physical units which host these applications as ‘intelligent edge devices’, but in reality, they may be deployed at any point within an IoT architecture implementation where data processing or transformation is required, not just at the locations where there is a real-world interface, our classical definition of an edge device.
Currently we overcome this conceptual duality by talking about a secondary type of ‘edge intelligence’ device within an IoT architecture, the ‘IoT Gateway’. An IoT gateway provides the same type of functionality in terms of providing a framework for applications but differs from the edge in terms of the type of interfaces it predominantly uses. IoT gateways tend to focus on communications connectivity, whilst IoT edge devices tend to focus on sensor connectivity. However, even this this can be a very blurred distinction.
• If sensors are connected to a ‘dumb’ serial or network interface, and the first point where the recovered data is processed sits above this, then is this device the IoT edge, or an IoT gateway?
• What if this device also has some sensors connected directly to it – does this change what we should call it?
• What if the ‘dumb’ sensor interface is not dumb and can perform some signal pre-conditioning or local logic, but still presents its data as raw binary register values – it’s not part of the IoT system because it’s data can’t be independently consumed, but it has ‘edge intelligence’.
The bottom line is that the key to successful IoT system design lies in the correct distribution of intelligence throughout the architecture to provide the necessary processing and data manipulation at the most effective place for the specific use case being addressed. If we were to consider an overarching generic architecture model for an IoT system, then in any real implementation, several of the layers may effectively be nullified, as it makes sense in a specific case to apply the intelligence either above or below them within other layers. In fact, as can be seen from the diagram earlier in this article, the whole notion that an IoT architecture has layers in the first place is fundamentally flawed, as it is comprised of a network of interconnected applications which form and break connections to each other as needed.
There is then a disjoint between the logical architecture of an IoT system as a collection of dynamically connected applications, and the physical architecture upon which it is deployed, which necessarily is related to the location and characteristics of user’s assets and the communication links between them. The increasing convergence of hardware and communication technologies, coupled to the flexibility in the placement of intelligence within an IoT system means that the distinction in hardware terms between what is an edge device or intermediate gateway will become increasingly blurred. Over time it is likely that these terms will disappear, to be replaced with the notion of processing hubs, nodes or something similar. Such nodes will have their physical interface and compute resource characteristics determined only by the local environment and their use case, rather than some nomenclature adapted from the architectures of the past.
For now, however, the industry continues to talk about edge intelligence, just remember that this doesn’t always refer to devices ‘at the edge’.
Contact Details and Archive...