feature article
Subscribe Now

Who Owns the IoT Gateway?

The Ups and Downs of Sharing

We spend a lot of effort talking about Internet of Things (IoT) edge nodes. Not only do they do the real work of the IoT, they must do so within tight power and cost constraints. But Mentor Graphics recently moved the spotlight a bit to shine it on the gateway. You might think of a gateway as just another piece of hardware that does aggregation and routing, but there are some high-level policy questions that warrant consideration.

The gateway is the local box that stands between the edge nodes and the Cloud. By acting as a hub, it can manage multiple data streams from its edge nodes, perhaps performing some intelligent filtering on that data and sending some subset up to the Cloud. In the reverse direction, it receives instructions from the Cloud and implements them locally.

That’s a pretty broad, vague set of marching orders, but that’s because the specifics will depend on the application. Whoever designs the network will need to implement some business logic within the gateway.

The utility of the gateway has been picked up by Mentor Graphics in their new end-to-end IoT platform. While it covers the entire scope of an IoT network, the focus areas appear to be three: a customizable gateway reference design (hardware and software), Cloud connectivity and management software, and a security setup from the edge nodes through to the Cloud.

The Cloud functionality is really just for providing access to the network by phone for the purposes of configuring and monitoring the network, similar to what we saw with Golgi. It doesn’t attempt to compete with the Amazons of the world for custom application functionality, although it can allow connection to other cloud-based services beyond what Mentor has put in place.

The security aspect moves our gaze to the gateway, since the gateway bears the most responsibility for ensuring that only authorized Things get attached to the network. But it also means that only authorized gateways should be able to attach to the Cloud network – everything should be performing mutual authentication on everything.

But their primary focus is clearly on the customizability of their gateway. As arbiter of who gets onto the network locally, it leverages ARM’s TrustZone to interface a management layer to the inner secure core, which itself leverages a hardware security device to keep the crypto-calculations far from prying eyes.

 IoT_Gateway_SysDK-11Jan2015_red.jpg

Image courtesy Mentor Graphics

The gateway can also act as the glue for what may be a mixed bunch of nodes – some legacy, some new – particularly in industrial settings. Exactly how the gateway is to handle and transform data or transport traffic will largely be custom for each project – especially with industrial installations. That means that the gateway must have some application space that developers can use to customize the gateway for their use.

The gateway that Mentor announced is a reference design and a dev kit, saving design work that doesn’t need repeating while making space for custom applications, where value and differentiation can be added. It really does put the gateway in the center of the spotlight.

But one aspect of the conversation I had with them got me thinking. The model proposed seems pretty straightforward for walled-garden networks or custom industrial installations. In both of those cases, you have a clear owner of the entire network, from the edge nodes through the gateway into the Cloud. That owner puts in place the custom gateway application code appropriate to the job at hand. Thorough testing will provide confidence that the various parts of the network will work together smoothly.

 Figure_2.png

At the other scenario extreme, you could imagine going to Fry’s, picking up various components, and building your own home IoT – a prospect that seems a long way off. But there’s an intermediate scenario that’s not quite as idealistic, but that creates some potential challenges for the gateway: implementing more than one network.

Let’s take a home example. The consumer IoT has to work for users with no technical proclivities, which sets a high bar as compared to the industrial IoT. There are lots of PowerPoint presentations depicting unified home networks where everything talks to everything. That means you buy the entire thing from one company and enter a walled garden. If you do get everything from one place, then you’ve got clear end-to-end ownership of the network by… someone. Might be a Google or Apple; might be your cable company.

But let’s say that you do your home IoT shopping and find that one system works really well for tying appliances together. The washer and dryer can talk to each other, and they can coordinate timing with the dishwasher to get the most out of the hot water. Or something. Meanwhile, another company is looking good for home environment management: lights, locks, heating and air conditioning, and the like.

So you decide that it’s not so important that the appliance network interact with the environment network; instead, you’re going to go with two parallel networks. With the model we’re seeing so far, that means two separate gateways – one for each network. Which means it could be even more gateways if you needed more networks.

Figure_3.png 

So now, instead of having multiple remotes lying about the house, we’ve got multiple gateways. From a technical standpoint, it would be really efficient to consolidate gateways into one master gateway box. Assuming mutually isolated networks, you would then have a gateway with mutually isolated applications sharing the same hardware.

 Figure_4.png

But this raises all kinds of questions that don’t exist with separate gateways. And it reinforces the point that, really, you’re not buying a gateway; you’re buying services that operate through the gateway. So, in this example, you’ve got some appliance services and you’ve got some home heating services. If they go through their own gateways, then each has a clear owner. But if they share a gateway, who owns this gateway?

This gets complicated because the gateway is no longer encapsulated within a closed environment delivering services from a single provider, where that provider can take full ownership. In a consolidated scenario, different service providers have to agree to share the same piece of hardware without really knowing anything about whom they’re sharing it with.

In theory, given rock-solid authentication and application isolation, the two services can run side-by-side, and, if one screws up, it won’t affect the other. It’s just not clear that reality matches theory yet. Will this mean that each service will have to vet and certify any gateways that host their application? What happens when two services you want don’t share any gateways on their “approved” list?

And it wouldn’t be a true conundrum without getting the lawyers involved. With a shared gateway, where is the liability for failure? Each service provider can no longer control every aspect of their hardware and software, so will they find themselves defending against failures caused by some other service? Or will a service-agnostic shareable gateway manufacturer now suddenly have liability for any failures occurring within the box?

These questions get messier yet if multiple services want to share edge nodes as well as the gateway. Which is likely to be the case in reality. So it bears restating that this isn’t a question of whether you can have multiple services – of course you can. The question is whether they must all come from the same provider or a closed ecosystem of providers.

You could argue that this is no different from the PC market, where people can readily assemble their own home computing environments. No one has locked up on liability or ownership questions there. Why does that have to be an issue here?

What seems different is that, in the end, you’re not buying a gateway; you’re buying services that happen to need a gateway to work. And the last thing a consumer needs is to have services interfering with each other.

Does this mean that some kind of “plays-nicely-with-others” certification is required? You could see gateway makers wanting to certify the services that run on their boxes. Likewise, you could see service providers wanting to certify the hardware they’re running on.

Or does this mean that, in reality, we’ll be sticking with multiple gateways, just like we live with multiple remotes?

Or is this further evidence that home installations will remain single-provider walled gardens because the alternatives are just too much of a hassle?

 

More info:

Mentor Graphics IoT Gateway SysDK

 

11 thoughts on “Who Owns the IoT Gateway?”

  1. Pingback: DMPK Services
  2. Pingback: Kindertrampolin
  3. Pingback: orospu
  4. Pingback: jocuri friv
  5. Pingback: agen judi bola
  6. Pingback: chimney repair
  7. Pingback: click
  8. Pingback: iraqi coehuman

Leave a Reply

featured blogs
Dec 5, 2023
Generative AI has become a buzzword in 2023 with the explosive proliferation of ChatGPT and large language models (LLMs). This brought about a debate about which is trained on the largest number of parameters. It also expanded awareness of the broader training of models for s...
Nov 27, 2023
See how we're harnessing generative AI throughout our suite of EDA tools with Synopsys.AI Copilot, the world's first GenAI capability for chip design.The post Meet Synopsys.ai Copilot, Industry's First GenAI Capability for Chip Design appeared first on Chip Design....
Nov 6, 2023
Suffice it to say that everyone and everything in these images was shot in-camera underwater, and that the results truly are haunting....

featured video

Dramatically Improve PPA and Productivity with Generative AI

Sponsored by Cadence Design Systems

Discover how you can quickly optimize flows for many blocks concurrently and use that knowledge for your next design. The Cadence Cerebrus Intelligent Chip Explorer is a revolutionary, AI-driven, automated approach to chip design flow optimization. Block engineers specify the design goals, and generative AI features within Cadence Cerebrus Explorer will intelligently optimize the design to meet the power, performance, and area (PPA) goals in a completely automated way.

Click here for more information

featured paper

Power and Performance Analysis of FIR Filters and FFTs on Intel Agilex® 7 FPGAs

Sponsored by Intel

Learn about the Future of Intel Programmable Solutions Group at intel.com/leap. The power and performance efficiency of digital signal processing (DSP) workloads play a significant role in the evolution of modern-day technology. Compare benchmarks of finite impulse response (FIR) filters and fast Fourier transform (FFT) designs on Intel Agilex® 7 FPGAs to publicly available results from AMD’s Versal* FPGAs and artificial intelligence engines.

Read more

featured chalk talk

AI/ML System Architecture Connectivity Solutions
Sponsored by Mouser Electronics and Samtec
In this episode of Chalk Talk, Amelia Dalton and Matthew Burns from Samtec investigate a variety of crucial design considerations for AI and ML designs, the role that AI chipsets play in the development of these systems, and why the right connectivity solution can make all the difference when it comes to your machine learning or artificial intelligence design.
Oct 23, 2023
5,318 views