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 30, 2021
Have you ever wondered why Bill is a common nickname for William and Dick is a common nickname for Richard?...
Nov 30, 2021
Explore the history of the chip design process, from the days of Integrated Device Manufacturers (IDMs) to EDA tools and today's era of democratized design. The post Just What Is Democratized Design Anyway? appeared first on From Silicon To Software....
Nov 30, 2021
The demand for smaller electronics devices can be achieved by high-density layers in multi-layer build-up substrates or multi-layered printed circuit boards (PCB). Vias are essential in the design... [[ Click on the title to access the full blog on the Cadence Community site...
Nov 8, 2021
Intel® FPGA Technology Day (IFTD) is a free four-day event that will be hosted virtually across the globe in North America, China, Japan, EMEA, and Asia Pacific from December 6-9, 2021. The theme of IFTD 2021 is 'Accelerating a Smart and Connected World.' This virtual event ...

featured video

See 400 GbE Running on a Speedster®7t FPGA from Achronix

Sponsored by Achronix

400GbE is required for next-generation, high-performance networking applications. In this video, Achronix demonstrates 400GbE connectivity on a Speedster7t FPGA integrated into a VectorPath™ PCIe accelerator card. The demonstration shows 400GbE traffic generated within the FPGA and transmitted across the FPGA’s 2D network on chip or NoC to the Ethernet subsystem. The 400GbE traffic is then looped back and checked within the FPGA fabric to compare to the original data stream.

Contact Achronix for a Demonstration of Speedster7t FPGA

featured paper

3D-IC Design Challenges and Requirements

Sponsored by Cadence Design Systems

3D-ICs are expected to have a broad impact on networking, graphics, AI/ML, and high-performance computing. While there’s interest in 3D-ICs, it’s still in its early phases. Standard definitions are lacking, the supply chain ecosystem is in flux, and design, analysis, verification, and test challenges need to be resolved. Read this white paper to learn about 3D integration and packaging of multiple stacked dies, design challenges, ecosystem requirements, and needed solutions.

Click here to read more

featured chalk talk

Accelerating Innovation at the Edge with Xilinx Adaptive System on Modules

Sponsored by Xilinx

The combination of system-on-module technology with advanced SoCs with programmable logic offer the ultimate in functionality, performance, flexibility, power efficiency, and ease of use. In this episode of Chalk Talk, Amelia Dalton chats with Karan Kantharia of Xilinx about the new Kira SOM, and how it enables faster time-to-deployment versus conventional component-based design.

Click here for more information about Kria Adaptive System-on-Modules