The Standardization of IoT Cloud Communications
By Bryan Mann, David Kaufman and Mark Trayer
Increasing 'connectedness' represents a huge innovation and business opportunity for IoT manufacturers’ devices
By Bryan Mann, David Kaufman and Mark Trayer
Industry of Things (IoT) analysts predict that more than 25 billion IoT devices will be connected and participating in the global internet by 2025 (Gartner) and the global smart home market is expected to reach $1.5 trillion by 2025 (IOT Analytics). This represents a huge innovation and business opportunity for IoT manufacturers’ devices and related services in the IoT landscape of the future.
Part of this growth is dependent on device interoperability. A consumer expects to buy an IoT device and have it work with another IoT device. Unfortunately, that isn’t always possible.
We live in a world of fragmented, “walled garden” solutions, where a single manufacturer’s device speaks a proprietary protocol connected to a proprietary cloud environment with a connection to a vendor-centric mobile application used to configure and control that device. Standards do not apply – mostly.
However, there have been successful industry attempts to make things talk to each other using cloud-to-cloud application programming interfaces (APIs). But each vendor’s device cloud has an API that differs in technical approach and level of complexity. To connect, each vendor must develop and maintain a purpose-built, single API-to-API connection. For example, a device from Vendor A wanting to be controlled by Vendor B’s app requires a uniquely developed and maintained API-to-API connection. And given all the IoT devices connecting to all the IoT apps, this creates a “n to n” problem that is just not scalable for the industry. This lack of API standardization forces IoT vendors, businesses, and consumers to pay the high price of non-standard integrations.
The OCF Universal Cloud Interface is the Cloud API Standard
Recognizing that the IoT requires seamless communication both from a device-to-device as well as a device-to-cloud-to-cloud-to-device perspective, Open Connectivity Foundation (OCF) has leveraged its existing secure proximal framework technology and associated data modeling to publish the OCF Universal Cloud Interface (UCI). This provides an open, secure, standardized solution, enabling a complete end-end ecosystem without proprietary fragmentation.
The OCF UCI is an API that helps the IoT industry avoid implementing and maintaining numerous proprietary programming interfaces at once. The OCF UCI is built using secure, industry standardized underlying technologies, with OAuth2.0 providing necessary authentication and HTTPS providing secure connectivity. Well-defined APIs exist for device information retrieval (and update) and event subscription. The APIs are designed to be agnostic of the data models; hence all existing and future data models published by OCF can be used. The data models describe payloads for the RESTful verbs and when originating from outside of a cloud (for example, when retrieving an end device’s information), are passed through unaltered. The media-type used for the payload can be negotiated using existing HTTP mechanisms via use of the Accept header, at a minimum both JSON and CBOR are supported.
UCI provides an open, secure, standardized cloud-to-cloud API. This, coupled with the existing “OCF Device to Cloud Services” specification that makes use of the same underlying data models, means that cloud-capable devices need only provide a single interface to the cloud using the same cloud native protocols that are already leveraged for proximal connectivity, as OCF device-to-cloud leverages secure CoAP and the same data models. The UCI ensures that the device does not need to support any variant, proprietary behaviors that may be driven by different cloud service providers.
To ensure consistency of experience and consistency of capability, OCF already provides a full certification program for devices themselves to assert conformance to the OCF specifications from the perspective of the device. For the UCI, automated test cases and test tools will enable the conformance of a cloud to be validated from both the origination (of API requests) and target (receipt of API requests) perspectives.
Enabling advanced future cloud services
Looking at the future, the UCI will act as the basis for creation of cloud services. Cloud services are important since they can expose data stored in a cloud as a service, without the need to have a proximal device.
Cloud services open up new integrations (based on standards) that were previously not possible. An example of a possible integration is a weather forecasting service to an in-home thermostat where the thermostat can use the predictions to optimize the heating profile of the house. Other integrations like talking to the infrastructure of a smart city will also be possible (for example, if a leak is detected in a home, the water company automatically turns off the water supply to the house). A further optimization can be that when the demand of electricity is high, devices with Demand Response Load Control (DRLC) can receive DR signaling from the electricity services provider and respond as defined by applicable service contracts or standards (for example Energy Star). New use cases will no doubt emerge when more cloud services and cloud data is made available.
OCF’s UCI enables a device to be part of an end-to-end, secure, open, and standardized Internet of Things ecosystem. The use of UCI avoids proprietary fragmentation and support costs associated with the maintenance of multiple different interfaces for the same functionality. As technology progresses, the use of UCI will enable devices to be part of more advanced use cases across both the smart home and the smart city.
Bryan Mann, Lead Architect, IoT Platform at Resideo Technologies
David Kaufman, Business Development Director at Resideo Technologies and Vice-Chair of the Certification Work Group of the Open Connectivity Foundation
Mark Trayer, Senior Principal Engineer at Samsung and Chair of Core Technology Work Group of the Open Connectivity Foundation
This article originally appeared in Electronic Products & Technology (EP&T).