What Makes a Gateway ‘Fully Functional’?

Last month I wrote about the unfortunate lack of clear terminology for describing the components of an IoT edge device. I compared some of the things that are described in marketing materials as “IoT gateways”.  They range from simple embedded computers running a basic operating system to fully functional gateways that provide all of the services needed to quickly and easily build and deploy working solutions.  Several people have responded by asking me to explain what I mean when I describe a network gateway as being “fully functional”.

The gateway is a key architectural element in many IoT deployments.  That is especially true in the Industrial IoT, where we are much more concerned with the interfaces to legacy devices, sensors and systems. It’s estimated that 85% of the assets that will be part of the Industrial Internet of Things already exist.  Rather than being replaced by new IoT devices, these existing devices must be integrated into the IoT architecture.  This is the issue that is solved by the IoT Gateway.

To do so, the IoT Gateway must address several common requirements.  These features must be implemented as services within a platform before it can qualify as a fully functional gateway:

Communications Management: The device should automatically maintain any configured connection, and the user should not have to intervene.  The gateway must be able to detect a lost connection, automatically re-establish that connection, either on the original interface or via a backup route, and it must be able to queue data during any comms outage for later transmission. This should include some level of session awareness.  The gateway must define the failed connection as the inability for an application to communicate with its intended destination applications, rather than a failure in the whole communications device or channel.

Security and Authentication: In many legacy industrial systems, security was based on physical access.  “My PLCs talk to my SCADA host over an RS-485 link entirely located within my boundary fence, so without physical access there is no way to get into the system.”  When these devices are integrated into IoT systems this strategy doesn’t work anymore.  The  gateway therefore needs to wrap layers of security around any data that will be transmitted onwards. This should include features like data encryption, authentication of the gateway onto the system and vice versa.  It should also include more complex elements, such as role based access to features and datasets.

Data Enrichment:  Many legacy devices provide data in a very raw state.  Examples include PLC 31, register 4005, and value 1275. In a legacy system it is impossible to interpret this data without detailed knowledge of the individual device producing the data.

One of the fundamental principles of the IoT is that data needs to be semantically searchable.  Users need to be able to request information about, for example, the temperature in each room in a building.  They need to be able to do this without needing to know any of the details regarding the devices and sensors producing that data. This is where data enrichment comes into play.  Data enrichment translates raw machine data obtained locally into semantically searchable information provided in engineering units or plain text.  A door status should be reported as “open” or “closed”, not “1” or “0”.

Data Aggregation: The more data we gather, the more important it becomes to filter out the chaff.  We don’t want to waste money on unnecessary transmission and we don’t want to flood our enterprise systems with a massive quantities of data that has no value. In the example mentioned above, we may be monitoring the status of a door every second. But it may only be opened once a week. This is the role of data aggregation. Instead of reporting the door status every second, we can choose to report the status only when it changes.  Instead of reporting a temperature every time we read it, we might choose to report the maximum, minimum and mean values that have occurred over a period of time.

Event Detection: This goes hand in hand with data aggregation. Reporting the max, min and mean temperature once an hour is fine, but if the changes starts moving too quickly it may indicate that a door has been left open, wasting energy. If a temperature goes beyond a threshold level it may indicate a potentially hazardous condition. We wouldn’t want to wait until the end of the aggregation period to know about these events. So as well as providing data aggregation to filter out the valueless data, event detection provides a mechanism to report significant events as they occur.  That allows us to build massive systems which nonetheless remain responsive. Ideally, the event detection should allow the definition of complex events involving the concurrent status of multiple variables, mathematical operations such as averaging, and time awareness for data analysis over a period.

Protocol Translation: Many legacy systems use protocols which are not compatible with modern packet switched communications networks.  An individual asset may have a number of separate legacy systems and devices associated with it, all of which use different communication protocols. While there is no getting away from the need to implement specific protocol drivers for these legacy protocols, what happens immediately thereafter can be standardized and offered in a service based model. This would include the features of data enrichment, aggregation and event detection as outlined above, as well as the publishing of the resulting data payload over standard mechanisms, including IoT protocols such as MQTT and social messaging tools like email, SMS or tweets.

User Applications: One of the real benefits of edge intelligence is the ability to make decisions locally and act upon them automatically. This allows for tighter control of local processes and can further reduce network traffic. Rather than give users completely unfettered access to the edge device, however, the gateway platform should provide protected workspaces, where an error in user programming can’t disrupt the other operations of the gateway.  The device remains online and the situation can be recovered remotely. Ideally, the gateway should accept user programs written in a variety of languages, so that the user can choose the language which best fits the operation being performed, or the skill set of their software team.

Device Management: Having all of these capabilities is highly desirable, but things could become a nightmare as the system scales and more devices are deployed.  There must be a mechanism to remotely manage them. Device management functions include the ability to provide diagnostics and performance data about the device and its communications status, as well as the ability to actively change things within the device from a remote location. Changes would include device firmware upgrades, user applications downloads, device configuration and user application configuration.

Conclusion  A device software framework that provides extensible service libraries for all of the above elements represents a much richer environment in which to start implementing the desired edge functionality. It leverages the core knowledge and skills of the supplier and packages them in a user-friendly manner.  It often makes deploying the required features a matter of service binding and configuration, rather than creating a need for significant software development effort. Further, as the platform is deployed by more users in diverse applications, the lessons learned are fed back into the core services.  This results in a significantly more robust and proven operation, and is superior to systems coded from a base operating system. If you are looking at deploying edge intelligence, be sure to understand exactly what functionality and support frameworks the devices you are considering can offer “out of the box”.  There are big differences out there, and the selection you make can directly impact the success or failure of a project.

Tim Taberner
Global Product Manager, Advanced IoT Cellular Gateways