The thing about IOT (Internet of Things) gateways is when you do a google search for them, you get pages and pages of results. The important thing to understand is a lot of that is marketing hype, but not all of them are the same.
When it’s not a true cellular IOT gateway
In a lot of cases when you encounter something is advertised as an IOT gateway, what gets delivered is just an embedded, rugged computer with a base Linux installation or a base Windows installation. So, when you take it out of the box it doesn’t do anything except come up to a Linux prompt or Windows desktop. Turning that into a true IOT gateway requires massive amounts of code, testing and verification, and finally certification to be accepted on carrier networks, etc.
In summary: It’s described as an IOT Gateway but is actually an embedded PC with a cellular card.
Second, you might encounter an embedded PC and cellular card (like we’ve just described) but with an IOT Gateway toolkit containing a whole selection of software components.
In this case, you can take components and stitch them together to produce an IOT Gateway that is tailored to your needs only if you’re prepared to burn some man-hours of software effort. You still must go through all that programming to make it happen.
A true, out-of-the-box cellular IOT Gateway
A true, out-of-the-box cellular IOT Gateway shouldn’t need anything other than at most user configuration to make it happen. It should be able to:
- understand how to get a connection back to a management platform
- do that via a cellular or via LAN connection that is connected through to the internet
- switch between those two depending on which is available so you get active standby routes in case of primary failure.
That is no trivial task when you look at cellular communications. Everyone thinks that cellular communications are so very easy because we are so used to having phones in our pockets and making calls on them. But, if you’re a machine and you have to legislate for how all the failure modes and recovery strategy is codified, that gets to quite complex.
Cellular modems will get knocked off the cell tower randomly. There are some failure modes where it’s not obvious to the remote equipment that you’re no longer connected through to your own application. It’s not a just a case of “are you connected to the tower still?”, rather, it’s “have you still got an open communications path that gets all the way back to your target applications so you can move data instead of just dumping it into a black hole?”
Immediately available, always on, always secure
A cellular IOT Gateway should understand all that stuff and it should be able to present a user, from their perspective, an “always on” connection that they only need set up once. Irrespective of the fact that underneath the hood the cellular IOT Gateway is making sure that connection is still up, its automatically switching to a backup route if it’s not still up. Its handling what happens to the data while it comes in and out. Of course, it should also do that in a secure way.
For example: When we go into customer demonstrations we might have a sensor talking to a gateway and then that information coming up in our management software. We walk in, switch on the sensor and after a minute, its online with the gateway and visible in the management software. We can see it all, actively manage it, actively change things, almost immediately.
Local calculation/processing/enrichment of data
The next thing a true gateway should do is it should have some mechanism again through user configuration whereby it can do something useful with data, like pass it up to the enterprise in a way that is compatible with IOT systems.
That means it must be able to enrich data. It needs to be able to take data from something like a PLC that’ll tell you register 2087 out of has a value of 4003, which is meaningless unless you know absolutely what it means. The gateway should be able to take that data and convert it into something meaningful.
For example: it should be able to say that the temperature in Tim’s office at 4:05pm is 23 degrees Celsius.
The user configures what the understandable value is in engineering units, but they don’t have to go through all the coding exercise of:
“How do you make the transformation?”
“How do you do that in a scalable way?”
“How do you do that across multiple points or multiple slave devices that you are pulling information in from?”
Having enriched the information, the next thing that it should do just through user configuration is to be able to apply event triggers to that information.
Locally we may be looking at the data in a PLC once every second, maybe even quicker. But most of that data doesn’t change significantly over a period of time. We don’t want to be firing all of that information over our expensive uplink that’s maybe on a cellular network, or via satellite space. What we want to do is take that raw data and turn it into actionable information. We want to be able to say I’m interested in the temperature in the room at a summary once an hour, but I don’t want to know about it unless something interesting happens. If it goes out of a predefined range, or it has a rate of change that is quicker than we expect.
A true IOT gateway should be able to achieve this through configuration, not through coding to say “I want take raw data, and I want to enrich it so that it has context.”
System behavior modification
The other thing a true IOT gateway should do is provide a mechanism where users can modify the behavior of the system i.e. Start to combine information from multiple sources, start to move back out to a variety of destinations. But again, this should through a configuration process rather than a coding process.
How it handles user applications
When it comes to additional user applications/modules, is it running at a root level on the box so if you louse up your code you can completely trash the unit? That means you would need to go out to site to recover the situation.
True IOT gateways should run in a protected sandbox space. A container, where if you make a mistake with your code, you can crash your code and there is framework still around it that remains working. That way you can still recover that situation remotely.
What is true out-of-the-box IOT gateway functionality? Here is a summary of the key differences to look for.
A true, out-of-the-box IOT gateway handles:
- communication management
- data enrichment
- event filtering, and
- user piping output to different destinations.
It’s integrated with a management system that can sit above a whole population devices so you can remotely do firmware upgrades, application upgrades and configuration.