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.

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.

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.

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.

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