First introduced in January 2020, OCF is proud to announce the official completion of the OCF Universal Cloud Interface (UCI), now included in the recently published OCF 2.2.0 specification release. The OCF UCI will simplify collaboration between IoT device manufacturers by providing a programming interface for standardizing connectivity between different manufacturers’ cloud servers, as well as devices and the cloud. Using the OCF UCI, manufacturers can produce secure, interoperable IoT devices with confidence in their seamless operation.
Search Results for: upnp+/wp-content/uploads/2016/03/OCF-UPnP-Certification-Testing-and-Licensing-Agreement.pdf
OCF Completes Universal Cloud Interface Specification and Launches the Industry’s First Cloud-to-Cloud Certification Program
Technology
Bringing Remarkable Things to Life.
OCF brings together a wide ecosystem of developers and resources to help create and deliver products that continue to make IoT a reality. Here you will find the resources necessary to design, build and achieve OCF certification, reducing total time to market costs, all while ensuring secure interoperability across market sectors.
How do you want to connect?
OCF allows you to connect IoT devices and systems using three distinct methods, namely Device-to-Device, Device-to-Cloud and Cloud-to-Cloud. In this page, we outline each of these methods, and provide the necessary flow and options required for each, along with links to the required resources and documentation.
Device-to-Device
Device2Device communication is establishes communication in the same network, meaning all devices are on the same network. The communication addressed is IPV6.
Using OCF Models
The OCF models can be found in the specifications.
The function that each device should contain is expressed via resources. The following kinds of resources exist:
- Infrastructure, e.g. the resources that are mandatory and make up the OCF Secure IP Device Framework
- Optional Core resources, resources that are generic for all devices
- Mandatory resources for the device type
- Any other optional resource
OCF models are specified in Open API Specification 2.0, and is governed by OPENAPI initiative. This is API definition format is widely used to describe restful interfaces.
Each resource is denoted with the resource type value, “rt”. This is a string and all OCF definitions start with “oic.r”. All OCF standardized resource types are registered with IANA. What is typically descibed in OAS2.0 for a URL are the GET and POST actions, with schema definition of the payload.
This is what OCF uses to describe which HTTP methods must be implemented per resource type and which payloads are used for the methods. The payloads are described in JSON and the JSON schema is using draft-04 format. The actual implementation of OCF is not using HTTP but CoAP. This is a direct translation of HTTP into CoAP, for example: HTTP-GET into CoAP-GET. Also, JSON is not on the wire, CBOR is on the wire, JSON can be directly translated into CBOR. However, all resource definitions are using HTTP & JSON for readability. Also, the URL is not important, the URL is place holder for the real URL to be used in the implementation.
Use OCF GitHub
If no appropriate model is found, then follow the flow to create new model in OCF.
The function that the device should contain is expressed via resources. The following kinds of resources exist:
- Mandatory resources for the device type
- Resources that are mandated for the device type.
- Easy to figure out by device type:
- https://openconnectivityfoundation.github.io/devicemodels/docs/index.html
- Any other optional resource
- Recommendation can also be found at
- https://openconnectivityfoundation.github.io/devicemodels/docs/index.html
- However every resource can be used:
- Infrastructure, e.g. the resources that are mandatory and make up the OCF Secure IP Device Framework
- Don’t worry about these, these will come with the framework
- https://github.com/openconnectivityfoundation/core
- Optional Core resources, resources that are generic for all devices
- https://github.com/openconnectivityfoundation/core-extensions/tree/master/swagger2.0
- Example: network monitoring
If no appropriate model is found, then follow the flow to “Create OAS2.0 models”.
IoTivity Getting Started
When all resources are identified, then follow the instructions of getting started with device simulation.
This getting started guide will create a device on a Linux PC and will create the communication infrastructure that is required for the implemented resources. Here one will learn:
- How to generate the server code
- How to interact with the server code
- How to update the example, so that the generated code will have the resources that you want.
- Note that the environment that has been set up contains all OCF resources.
Device-to-Cloud
Device2Cloud communication involves communication between OCF devices on one or more proximal networks communicating with devices outside the local network. This is accomplished via connection through a secure account in a secure cloud environment. All communications are secured using auth-crypt ACE credentials. Authorization is done using auth0 with a unique ID and an authorization code from the cloud. Communication addressing is done through secure COAP and TCP at a URL using a specific port. Clients logged into a specific account on the cloud can discover and onboard servers logged into the same account as if they were local.
Setup cloud infrastructure
Vendors using device-to-cloud communications can use any OCF compliant cloud where they have accounts, or they can create their own OCF cloud. The cloud communications interface is defined in OCF specifications here. There is no limit to the number of OCF clouds that can be created. One OCF compliant open-source cloud, PLGD, is here. Instructions for building your own OCF cloud are here. OCF compliant as well as non-OCF clouds can be securely linked using the OCF-defined Universal Cloud Interface (UCI) cloud-to-cloud interface described below in the C2C section.
PLGD
As mentioned in the previous paragraph, the PLGD cloud is an open-source OCF cloud implementation that is available for general use and has been certified to comply with the OCF D2C specifications. You can find it here. Instructions for using the PLGD cloud are on the on the PLGD site. As with all OCF clouds, they are used with the CoapCloudConfResURI described below.
Create client talking to cloud
All OCF clouds are used with the CoapCloudConfResURI resource defined here. This resource must be included and any device intending to use an OCF cloud directly. An OCF proxy device can be used to connect D2D devices to an OCF cloud even if the D2D device does not include the CoapCloudConfResURI resource directly. Instructions for using the CoapCloudConfResURI resource are documented the D2C sample. This example illustrates connecting to both the existing PLGD open-source cloud as well as a local private cloud running in a Docker container.
OTGC
Onboarding Tool and Generic Client (OTGC) is an OCF-provided tool that can securely onboard and control any OCF server using an automatically generated user interface. The interface is derived from the resources advertised by the device itself. No programming or device configuration is necessary. OTGC is open-source and versions are maintained by OCF on the Android and Linux platforms. Instructions for installing these versions are here (Android) and here (Linux). Open source code is available here. OTGC will work with D2D devices with no setup. For D2C connections, configuration must be set up to indicate the cloud to use. Once configured, OTGC can discover, securely onboard and control OCF devices.
Create device talking to cloud
Of course, server devices must be connected to and registered in a common OCF cloud account in order to be used by OTGC or any other client. More complex servers that can implement any OCF resources can be created using DeviceBuilder. This script automatically generates fully functional code for any device described in a simple device description file. There are convenient tools that will also compile the code, set security and run the code. This process is described in the examples here.
Iotivity
All of the examples are built using the IoTivity open-source implementation of OCF. Twice a year, updated versions of the OCF specifications are released (latest version here). Each release also includes an updated automatic certification tool and a version of IoTivity that complies with the latest version of the specifications and passes the certification tool.
Cloud-to-Cloud (Universal Cloud Interface)
The Cloud-to-Cloud communication establishes communication between two clouds: Client-side Cloud and Device-side Cloud. It specifies a set of APIs on the cloud with the design concepts:
- OAuth 2.0 based cloud account linking
- HTTPS request and response
- JSON payload of OCF models or external models
The clients and devices communicating through Cloud-to-Cloud APIs (UCI) may not be OCF compliant.
Setup a Client-side Cloud
Client-side Cloud is called Origin Cloud in the OCF specification. It’s the cloud to which the user’s clients are connected.
Through Cloud-to-Cloud APIs, the Client-side Cloud can:
- Get access token and refresh token from the Device-side Cloud
- Retrieve the information of all devices or a single device of the user
- Retrieve a specific resource (e.g. get the on/off status of a binary switch)
- Update a specific resource (e.g. change the binary switch from on to off)
- Subscribe/Unsubscribe to multiple event types at all devices, a single device, or a single resource level
Setup a Device-side Cloud
Device-side Cloud is called Target Cloud in the OCF specification. It’s the cloud to which the user’s devices (servers) are connected.
Through Cloud-to-Cloud APIs, the Device-side Cloud can:
- Grant access token and refresh token to the Client-side Cloud
- Expose APIs to devices and resources according to the scopes contained in access token.
- Send notifications to the Client-side Cloud according to the established subscription.
plugged.in
plgd, an open source project, delivers an open source reference implementation which presents best practices for Cloud deployment of the OCF specifications.
plgd contains all components to create the OCF Cloud infrastructure, including the Cloud component of the Device to Cloud Services and OCF Cloud API for Cloud Services specifications.
Open Source Project
There is also an Open Source implementation of the OCF specification called the IoTivity Project. The project brings together the open source community to accelerate the development of a single framework and the services required to securely connect devices.
Collateral
White Papers
BACnet & OCF Core Framework White Paper
BACnet Gateway & OCF White Paper
Cloud Native IoT White Paper
IoT Standards and Implementation White Paper
Informational Flyers
Open Connectivity Foundation Informational Flyer
Open Connectivity Foundation Informational Flyer (Simplified Chinese: 现代汉语通)
Open Connectivity Foundation Informational Flyer (Traditional Chinese: 正體字)
Open Connectivity Foundation Informational Flyer (Japanese 日本語)
IoTivity Informational Flyer
IoTivity Informational Flyer (Japanese 日本語)
IncisorTV Article
OCF YouTube Channel
Presentations
OCF at ELC/OpenIoT Conference | October 11-13, 2016 | Berlin, Germany
IoTivity Introduction (Thiago Macieira , Intel)
OCF For Resource Constrained Environments (Kishen Maloor, Intel)
IoTivity Tutorial: Prototyping IoT Devices on GNU/Linux (Phillippe Coval, Samsung)
* Link to video presentation here.
Automotive Session | June 30, 2016 | OCF Members Meeting, Hillsboro, Oregon
Introduction to OCF (Moonki Hong, Samsung)
Remote Vehicle Interaction (RVI) & OCF-RVI bridge (Magnus Feuer, JLR)
Data Model Mapping (Michael Koster, SmartThings)
W3C Automotive (Paul Boyes, W3C)
OM Auto Incubator (Joel Hoffmann, OMA)
Perspectives on vehicle developer community (Shayne O'Sullivan, Vinli)
JLR Automotive Incubator (Darren Buckner, WorkFrom)
Computex OCF Seminar | May 31, 2016 | Computex - Taipei, Taiwan
On May 31, 2016, the Open Connectivity Foundation hosted a seminar series at Computex Taipei. Linked below are the presentations. You can view videos of the presentations here. More information about the event can be found here.
Goals, Activities and Accomplishments (Matt Perry, Microsoft)
Architecture and Features (Martin Hsu, Intel)
Programming Models and OneIota Tool (Shao-wen Yang, Intel)
Industry Cooperation, Liaisons and Other IoT Ecosystems (Richard Brown – VIA Technologies)
Certification Program (Felix Kao - Allion)
Membership Information and live demo(s) (Dave Brenner, MC)
IoTivity Developer Day | April 6, 2016 | Port Pavilion on Broadway Pier, San Diego
On April 6, 2016, the Open Connectivity Foundation hosted the IoTivity Developer Day. Linked below are the presentations. More information about the event can be found here.
Opening Welcome and Keynote (Mark Skarpness, Intel)
Open Connectivity Foundation (OCF) Fundamentals (Ravi Subramaniam, Intel)
IoTivity’s Architecture (Ashok Subash, Samsung Electronics)
Hands-on 101 (Vijay Kesaven & Joseph Morrow, Intel)
Security (Habib Virji , Samsung Electronics)
IoTivity and Further Capabilities - Sakari Poussa & Otavio Pontes, Intel
Closing Remarks - Thiago Macieira, Intel & Clarke Stevens
The Open Connectivity Foundation Introduces World’s First International Standard for Smart Home; Will Demonstrate New OCF Universal Cloud Interface-based Smart Home Solutions at CES 2020
BSC Computer GmbH, COMMAX, Haier, LG Electronics, Resideo, Samsung Electronics and SURE Universal to demonstrate a fully capable smart home experience, innovating toward secure IoT interoperability today
Beaverton, OR – January 2, 2020 – The Open Connectivity Foundation (OCF), a leading Internet of Things (IoT) standards body, today announced that products from BSC Computer GmbH, COMMAX, Haier, LG Electronics, Resideo, Samsung Electronics and SURE Universal will be showcased in completely interoperable smart home demonstrations at the OCF IoT Breakthrough press event at the Barrymore Restaurant in Las Vegas on January 6, 2020, from 3–6 p.m. PST. These devices will complete OCF 2.1 certification in 2020, ensuring robust and secure connectivity between devices. Many of these and other industry-leading OCF member companies will be commercially launching products based on the OCF specification in 2020…. [Read More]
OCF Secure IP Device Framework
OCF Secure IP Device Framework
The OCF Secure IP Device Framework is an infrastructure that enables secure IP communication for vertical defined applications.
The OCF Secure IP Device Framework enables device discovery, onboarding and application-layer security, for Device-to-Device and Device-to-Cloud IoT device connectivity. As an ISO/IEC adopted standard, this framework is internationally agreed upon by experts and is compliant with most of the known IoT security requirement baselines.
The Secure IP Device Framework utilizes the majority of the OCF standard used in the smart home, however, it strips away the data models, allowing it to be vertical-agnostic. The open source implementation is easily accessible and can be accessed on the OCF GitHub.
What are the benefits of the Secure IP Device Framework?
Because the OCF Secure IP Device Framework is vertical-agnostic, it allows for secure IP-based communication. You can carry the data that you require in the format that you require, making the framework ideal for applying to a variety of verticals with particular use cases.
With the open API implementation, IoTivity, developers can easily build their application, take existing bus protocol applications and map their data models on top of the device framework. This open API is compliant to the OCF standards and implementations can be verified using the OCF Certification Program.
Discovery and Security
The Secure IP Device Framework provides device discovery and security on the network, meaning it can interrogate a network, discover devices, discover the resources that those devices may have, and securely onboard them. For example, the Secure IP Device Framework can onboard a light bulb with an off facility, dimming facility and certain type of RGB capability, and control it using the most secure methods available for internet protocol (IP) connectivity.
Utilizing the onboarding tool, the Secure IP Device Framework enables devices to communicate with each other in the secure domain, and only devices onboarded in the secure domain are allowed to talk to each other. Defined Access Control Lists give granular control of who is allowed to interact with which part of the functionality on the device. The access control mechanisms are based per resource (URL) and Methods that are allowed on the resource. For example, a guest would be allowed to read the current temperature of the thermostat but not allowed to change the set point of the thermostat.
Compile Your Compliance
Using the Secure IP Device Framework ensures that your IoT products and solutions will be secure by design. OCF has done the legwork to map the OCF specifications to key industry and government IoT security baselines around the world. This means you can “compile your compliance” to IoT security baselines, as the OCF specifications have already met all or most of the security requirements in standards such as NIST 8529, CAC2 Conveners, ENISA IoTSec, UK IoT Requirements and ETSI IoT Baseline Requirements.
To learn more about OCF security, visit our security webpage.
Communication Mechanisms Covered by the Secure IP Device Framework
The three device connectivity methods the Secure IP Device Framework supports are:
- Device-to-Device communication
- Device-to-Cloud communication
- Cloud-to-Cloud communication (OCF Universal Cloud Interface)
Through Device-to-Device connectivity, the Secure IP Device framework enables secure communication between OCF devices across a protocol network such as Wi-Fi, Ethernet or Thread. This method also allows for bridges and proxies so you can connect an OCF device via a bridge to a non-IP-based protocol such as Zigbee or Bluetooth, or even via a proxy to a non-OCF transport such as MQTT.
With Device-to-Cloud communication, you can connect through a cloud between two OCF devices, which allows you to control a device in a different building or even in a different part of the world.
Finally, the Secure IP Device Framework enables Cloud-to-Cloud communication using the OCF Universal Cloud Interface (UCI), which standardizes connectivity between different manufacturers’ cloud servers. This helps facilitate cloud partnerships for manufacturers, reduces the need for manufacturers to develop custom APIs and improves the end-user experience.
OCF Secure IP Device Framework on the (Embedded) device
The Secure IP Device Framework has:
- A small footprint of code, for embedded devices and RTOS's
- Small payloads, e.g. communication packages
- Best in class security (including PKI), by using the latest technologies
- A base of widely accepted internet technologies, based on IETF RFCs
- A minimal required set of features
- A huge set of optional features that are already available for a vendor to use
- A design that allows vendors to concentrate on device function, not on the communication and security aspects
- An ISO/IEC content format, hence it is upgradable
- Payloads that can be defined using any (existing) content type:
- For example: CBOR, JSON, XML
- CoAP, allowing the same communication paradigms as used on top of HTTP, but then with smaller communication packages
- The OCF Secure IP Framework architecture is RESTful, but the application is not limited to that paradigm
OCF Specifications included in the OCF Secure IP Device Framework
The following OCF specifications are agnostic of the function of the device (e.g. vertical-agnostic). The Secure IP Device Framework includes all of the following:
- Secure IP Device Framework
- Core Optional Framework (optional, depends on deployment scenario)
- Easy Setup (optional, depends on deployment scenario)
- Security
- Bridging (optional, the architecture only, depends on deployment scenario)
- Onboarding Tool
- Device to Cloud Services (optional, depending on deployment scenario)
- Cloud Security (optional, of course required when doing cloud)
- OCF Cloud API for Cloud Services (optional, depending on deployment scenario)