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
Nov 23, 2022
The current challenge in custom/mixed-signal design is to have a fast and silicon-accurate methodology. In this blog series, we are exploring the Custom IC Design Flow and Methodology stages. This methodology directly addresses the primary challenge of predictability in creat...
Nov 22, 2022
Learn how analog and mixed-signal (AMS) verification technology, which we developed as part of DARPA's POSH and ERI programs, emulates analog designs. The post What's Driving the World's First Analog and Mixed-Signal Emulation Technology? appeared first on From Silicon To So...
Nov 21, 2022
By Hossam Sarhan With the growing complexity of system-on-chip designs and technology scaling, multiple power domains are needed to optimize… ...
Nov 18, 2022
This bodacious beauty is better equipped than my car, with 360-degree collision avoidance sensors, party lights, and a backup camera, to name but a few....

featured video

Unique AMS Emulation Technology

Sponsored by Synopsys

Learn about Synopsys' collaboration with DARPA and other partners to develop a one-of-a-kind, high-performance AMS silicon verification capability. Please watch the video interview or read it online.

Read the interview online:

featured paper

How SHP in plastic packaging addresses 3 key space application design challenges

Sponsored by Texas Instruments

TI’s SHP space-qualification level provides higher thermal efficiency, a smaller footprint and increased bandwidth compared to traditional ceramic packaging. The common package and pinout between the industrial- and space-grade versions enable you to get the newest technologies into your space hardware designs as soon as the commercial-grade device is sampling, because all prototyping work on the commercial product translates directly to a drop-in space-qualified SHP product.

Click to read more

featured chalk talk

Gate Driving Your Problems Away

Sponsored by Mouser Electronics and Infineon

Isolated gate drivers are a crucial design element that can protect our designs from over-voltage and short circuits. But how can we fine tune these isolated gate drivers to match the design requirements we need? In this episode of Chalk Talk, Amelia Dalton and Perry Rothenbaum from Infineon explore the programmable features included in the EiceDRIVER™ X3 single-channel highly flexible isolated gate drivers from Infineon. They also examine why their reliable and accurate protection, precise and fast on and off switching and DESAT protection can make them a great fit for your next design.

Click here for more information about Infineon Technologies EiceDRIVER™ Isolated & Non-Isolated Gate Drivers