In May, we reported on an Embedded Linux Conference talk by Open Connectivity Foundation (OCF) Executive Director Mike Richmond on the potential for interoperability between the OCF’s IoTivity IoT framework and the AllSeen Alliance’s AllJoyn spec. We also looked at how the OCF has evolved from the earlier Open Interconnect Consortium (OIC) and acquired the assets of the Universal Plug and Play (UPnP) Forum. Here, we examine another ELC 2016 talk about the specifics of those integrations, as well as other changes planned for the IoTivity 2.0 release due later this year.

The Iotivity 2.0 talk (see full video below) was presented by Vijay Kesavan, a Senior Member of Technical Staff in the Communication and Devices Group at Intel Corp. Kesavan is a seed contributor to the core IoTivity library, and currently serves as the Business Development Task Group chair for OCF.

Speaking shortly after the release of IoTivity 1.1, Kesavan told the ELC audience about plans to support new platforms and IoT ecosystems in v2.0. He also explained how the OCF is exploring usage profiles beyond home automation in domains like automotive and industrial.

Joining the IoTivity Party: iOS, Windows, UPnP, and Arduino 101

IoTivity currently supports Linux, including specific Ubuntu and Android support, as well as Arduino. Version 2.0 will expand that to Windows and iOS. For iOS, the OCF is essentially doing what it did for Android: adding support in the “upper stack built on C++” rather than the lower C-based stack, in order to expose IoTivity to the iOS API, said Kesavan. The Windows integration will be more substantial. “We’re porting IoTivity to Windows so it can build upon Visual Studio 2013,” he said.

New hardware targets will include Intel’s Arduino 101 board. Arduino 101 runs the Arduino IDE on the Intel-developed, open source Zephyr OS, which itself runs on an Intel Curie module based on an Intel Quark SE chip. “Zephyr and IoTivity have the same data model, but the APIs are not yet compatible,” said Kesavan. IoTivity 2.0 will also support Samsung’s Linux-ready Artik embedded modules.

Integrating IoT ecosystems is a more challenging problem. Much of v2.0 is about supporting legacy UPnP devices. “We’re doing a lot of work in protocol translations, exposing UPnP devices using a plugin mechanism,” said Kesavan. “A UPnP device will essentially be discovered and seen as an OCF device.”

In the future, the OCF will translate IoTivity’s REST APIs to UPnP’s SOAP/XML representations, he added. There are also plans to integrate the UPnP AV data model directly to IoTivity to support audio and video.

IoTivity 2.0 will also include “some work” in interoperability with AllJoyn, although in v2.0, this work will not be as comprehensive as the UPnP integration. “There will be an AllJoyn plugin that maps AllJoyn into the OCF model and talks to AllJoyn routers, and maybe talk to some of the thinner devices like lightbulbs,” said Kesavan.

Additionally, IoTivity 2.0 will include the beginnings of interoperability with EEBus, a European IoT spec for energy management in homes and smart buildings. Specific device integration will also be provided for IoT device families like Nest, LIFX, and Hue. Presumably, the Nest support would include some integration with Nest’s Weave IoT protocol, but Kesavan did not go into specifics.

NodeJS and Group Management

The big news for developers in v2.0 is the support for NodeJS at the API level. There will also be better group management features, making it easier to create and manage conceptual groups of IoT devices, and detailing “how you add and remove devices and add security,” said Kesavan.

Other new developer-focused features will include Pub/Sub integration, more cloud extensions, and better tools and documentation. When asked whether IoTivity would expand to different transport protocols beyond its Constrained Application Protocol (CoAP) to support HTTP, Kesavan said there were “no plans for 2.0 but we’re looking into it.”

Finally, IotTvity 2.0 will feature end user improvements including better support for “network onboarding” of tools. “This will make it easier for end users to add a device to a WiFi or BLE network,” said Kesavan.

New Industrial Domains: Supply Chain, Automotive, and More

For future release, the OCF is beginning to look beyond the smart home to new industrial domains with very specific usage requirements. In the shipping business, for example, there are considerable questions about how IoTivity could be modified to support asset tracking and smart logistics in the supply chain. “The industry wants to move beyond bar codes to add smart sensors that continuously monitor shipments,” said Kesavan.

Sensors are being implemented first for high value goods and perishables like vaccines and food that need to maintain consistent temperature and other conditions. “Today, you don’t know about the quality of the goods until you open the box,” said Kesavan. “But if you knew the temperature threshold was being breached closer to the time it happened, you could take action earlier. We’ll see coin-cell driven sensors attached to boxes and pallets to measure things like temperature, shock, and humidity. At each step, that data can be read and aggregated through a gateway to the cloud.”

Industrial supply chains present challenges like scale, density, and quality of service that are less common in the home. “If you have all these boxes all transmitting status over BLE or ZigBee, how do manage interference?” said Kesavan. “We can have gateways coordinate with each other on load balancing, handoffs, and channel allocations.”

The OCF is looking into how to integrate DDS for quality of service, and how to operate on highly constrained devices. “We’ll also need to look at better security at both the device and hierarchical level,” he added.

Other domains under evaluation include medical and automotive. In automotive, the OCF is working with both the Automotive Grade Linux (AGL) and GENIVI standards organizations. “The next step will be creating an automotive profile for IoTivity,” said Kesavan. “We’ll look at how you integrate wearables, and communicate between the car and a home gateway, including scheduling smart charging. We’ll look at how we talk to various automotive buses, as well as other cars or infrastructure using V2V or V2I.”

As the OCF’s industrial workgroups pull together requirements for these and other domains, they need more participants with domain experience. “Please join the OCF,” said Kesavan. “We need your expertise.”