When is a ‘Gateway’ not a gateway?
I’ve been having a number of conversations about IoT gateways with colleagues, partners, suppliers analysts, potential customers and sales channels. The thing that strikes me – and not for the first time — is how many of us in the IoT space use identical language to describe wildly different things. Small wonder that there is so much confusion in the industry about device functionality, and about which partners are needed to bring together a complete solution.
Even the term “device” can be confusing. What, exactly, is the “device” in a discussion about device management? Is it the gateway, the modern module inside it, the SIM card associated with it, or something else?
- If it’s the gateway, are we talking about basic management of hardware, or more complex elements such as cellular routing/security, user application program download/ life cycle management/configuration and device firmware upgrades?
- If it’s the modern module, or just the SIM, how are we going to handle all of the other stuff that is needed to deploy a truly manageable end-to-end system?
There are similar problems with the use of the term “gateway”. When you browse data sheets and web content for devices described as “IoT gateways”, you’ll find that there’s no industry standard usage for the term. An embedded computer running Linux may be called a “gateway” although it leaves the end user to do everything needed to transform it into an operational device. Other so-called “gateways” are really just media converters with some basic routing capabilities. Others are serial protocol converters or devices that offer some core connectivity and device management services, but little else. At B+B SmartWorx we use the term “gateway” to describe a full-featured device that provides full frameworks and services for security, data aggregation and enrichment, protocol conversion, and event triggering. A B+B SmartWorx “gateway” also supports user business logic and allows additional applications to be added, written in a variety of languages.
Why is this use of language a problem? Well, multiple interpretations of the term “gateway” make it difficult for users to describe or research potential solutions. It’s just one more thing that makes investing in an IoT system more difficult than sticking with a traditional M2M architecture. Suppose I want a fully functional gateway device, but my searches keep turning up embedded computers, routers or other devices? Worse yet, it’s not immediately clear what the limitations of these devices are, and so I waste time in discussions about products which will never meet my requirements. Ultimately I’m likely to give up and think about deploying another SCADA system with remote PLCs or similar “old” technology. It may not be exactly what I wanted, but at least I’ll understand what I’ll be getting and the compromises that I’ll be making.
There’s a lot of good work going on around the lexicography for data in the IoT, pointing the way to the utopia of easily shared, semantically consistent content. Perhaps we need a similar discussion about the terminology used for the basic architectural components of a system in order that potential end users can more easily understand the range of functionality they offer, and where they fit into an overall system design?
January 25, 2018