Delivering services across the IoT became the focal point of the OpenFog Reference Architecture, a baseline to developing an open architecture fog computing environment. The OpenFog Consortium, a group of more than 50 organisations, has discussed IoT architecture encompassing a broad spectrum.

The year-old group defines “fog” broadly to cover everything from IoT end nodes to cloud services. It aims to define ways to minimise backhaul while providing reliable communications and deterministic latencies. Ultimately its recommendations will touch everything from the design of end node SoCs to gateways and applications.

The OpenFog Consortium does not expect all IoT nodes will be compliant with its requirements. But it does aim to enable every IoT deployment with its vision of interoperable services that span eight technical areas and many vertical markets. Along the way it will create test beds and certify products for compliance with its requirements.

Not surprisingly, security got special attention in the baseline document published this week. “It has a 30-page appendix with many detailed calls for action, mainly for security where we did a deep dive…that every silicon and security stack vendor should review,” said Chuck Byers, co-chair of the consortium’s architecture group and a principal engineer at Cisco Systems.

 
IoT EETimes fig 1 (cr) Figure 1: The OpenFog Reference Architecture covers a broad waterfront from end-node SoCs to cloud services.  

Specifically, the Trusted Computing Group’s standards for a hardware root of trust and how chip designers implement them may need to be modified for IoT, said Rob Swanson, chair of the consortium’s technical group and a principal engineer at Intel.

In addition, rivals such as ARM and Intel need to align the security primitives in their competing architectures “to serve app developers in a consistent way, [for example in] common crypto mechanisms for hardware acceleration,” Swanson said. Incidentally, ARM is a member of the consortium which so far includes few chip vendors.

Security is just one of eight tech areas the framework addresses, but it’s currently “the biggest source of heartburn,” said Byers, noting the group also will define APIs and processes for orchestrating IoT services.

“The calls to action will come in the next phase,” said Swanson. “We first needed to set the baseline with the reference architecture so we can show how systems are comprised for a given scenario,” he said.

Now the group has turned its attention to defining specific low-level functions, minimal viable interfaces and methods for testing them. “There’s quite a bit to do here,” Swanson said.

For example, two unannounced open source projects are already in the works that may become part of the consortium’s recommendations in the future. Meanwhile the group is setting up liaisons to collaborate with standards organisations and other IoT efforts including the Industrial Internet Consortium that has its own general and security frameworks.

First published by EE Times.