OCF Overview Including Summary of New Features in OCF 1.0 Candidate - - PowerPoint PPT Presentation

OCF Overview

Including Summary of New Features in OCF 1.0 Candidate Draft

Michael McCool Intel Osaka, W3C Web of Things F2F, 16 May 2017

Outline

 OCF History, Background, and Markets  OCF Architecture and Principles

 CRUD-N Interaction Mechanisms  Resources  Interfaces  Links and collections  Draft Entity-Relationship model (NEW! But not from OCF…)

 Changes between OIC 1.1 and OCF 1.0 Draft Candidate (Summary)

 Introspection (via Swagger/OpenAPI)  Enhanced Security Model

2

2014 2015 2016 2017

OCF – Result of Consolidation

APRIL 2017 OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA 3

• Make it easy for developers to deal with the complexity of IoT comms
• Provide a common data model that developers can use to interface

with all IoT devices and their underlying data

• Establish an architectural foundation that can achieve the necessary

scalability

• Focus the architecture around interoperability
• Supports the needs of multiple vertical markets (since many use cases

span multiple vertical markets)

• Provide a path towards future consolidation of standards

OCF – High Level Goals

APRIL 2017 4 OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA

OCF & IoTivity

Specification Open Source Coordination Business (Marketing, Strategy, Membership) Open Source Project

Reference Implementation of OCF (and Non-Spec Related Code)

Sponsored (funded) by OCF Separate Governance

Coordination APRIL 2017 OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA 5

Certification Data Modelling

Specs & Open Source ready simultaneously

OCF – Conceptual Framework

6 APRIL 2017

Core Framework Profiles

Consumer Enterprise Industrial Auto Education Health

Security, Identity & Permissions

Discovery Data Transmission Data

Management

Device Management

Transports

(Smart)

Remote Access

Cloud

Resource Model Interaction / Data Model

OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA

OCF – Resource Model

7 APRIL 2017

Resource URI

rt: Resource Type if: Resource Interface prop: Policy n: Resource Name

… …

Common Properties Resource Specific

Identifies the type of resource List of interfaces associated with the resource Policy associated with resource: discoverable, observable, secure, etc Friendly name § The resource model, coupled with the common data model, provides the base interoperability of OCF § Any physical or software artifact on a device that needs to be manipulated or made visible across the network can be described via the resource model § A resource has a URI and a collection of Properties

links: Other Resource URI

Resources can include links to

• ther resources

OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA

Resource Model - examples

8 APRIL 2017

14

Resource URI :/a/light1 rt: oic.ex.light if: oic.if.rw prop: discoverable,

• bservable

n: myHallWayLight State: 0 (OFF) Dim Level: 0 Resource URI :/a/fan1 rt: oic.ex.fan if: oic.if.rw prop: discoverable n: myKitchenFan State: 1 (ON) Speed: 10

OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA

• CREATE
• Create a new Resource on the Server
• RETRIEVE
• Get the current State or representation of a Resource from a Server
• UPDATE
• Request a partial or complete update to the information stored in a Resource
• DELETE
• Remove a Resource from the Server
• NOTIFY
• Request asynchronous notification of state changes in a Resource
• Special-cased to support OBSERVE for publish/subscribe support

Common Interaction Model – Transport Agnostic

APRIL 2017 9 OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA

Let’s look deeper at a Resource …

10

Server - DevA

/dimming /oic/d /oic/res Main Living Room Light /switch /oic/d /oic/p

• ic.r.switch.binary
• ic.wk.d
• ic.wk.p

false 100 /switch true /dimming

• ic.r.light.brightness

/oic/p LED-Light-Co, 40W Equivalent Bulb

There can be more Properties …

11

/oic/p mnml mnmn pi http://ledlight.com/gg3-40 Led-Light-Co GoGlow III - 40W mnmo GG3-40

Resource Type - Data Modeling

12

JSON Schema*

• Describes the Properties and

Representation ReSTful API Modelling Language (RAML)*

• Describes the Request and Response

*JSON Schema and RAML are normative and also can be used for code generation "oic.r.switch.binary": { "type": "object", "properties": { "value": { "type": "boolean", "description": "Status of the switch" } } } get: responses : 200: body: application/json: schema: | { }

Defined by: (see OIC_Resource_Type_Specification)

13

OCF Specification defines “oic.wk.p” Resource Type for platform and its list of Properties

14

And … Additional core resources CR: conditionally required (i.e. if capability is supported)

Link

{ “href”: “/switch”, “rel”: “contains”, “anchor”: “/a/room”, “rt”: “oic.r.switch.binary”, “if”: “oic.if.a”, “bif”: “oic.if.baseline” }

15

/a/room /switch

Room contains a device with binary switch

Target Relation Context

Parameters

How to define the connection between two resources?

Collections

16

DevD

/room “name” “href”: “oic://<DevA>/oic/d”, “rel”: “contains”, “rt”: “oic.d.light” “href”: “oic://<DevB>/oic/d”, “rel”: “contains”, “rt”: “oic.d.light” “links” “Living Room”

• A Resource that also has Links
• Links declared in value of the “links” Property

Collections … example

17

{ “rt”: “acme.room”, “if”: [“oic.if.r”, “oic.if.rw”], “color”: “blue”, “dimension”: “15bx15wx10h”, “links”: [ {“href”:“/the/light/1”, “rel”:”contains”, “rt”:“acme.light”, “if”:[“oic.if.a”, “oic.if.baseline”]}, {“href”:”/the/light/2”, “rel”:”contains”, “rt”=“mycorp.light”, “if”:[“oic.if.s” , “oic.if.baseline”]}, {“href”:“/the/fan/1”, “rel”:”contains”, “rt”:“hiscorp.fan”, “if”:[“oic.if.baseline”]} ] } Common Properties Link Read-Write Property Read-only Property Link Parameters Link Target

“Room” collection – room has lights and fan

/my/room/1

Interfaces

18

“Room” collection – room has lights and fan Interface views

• ic.if.ll
• ic.if.r
• ic.if.rw
• ic.if.s
• ic.if.baseline

/my/room/1

{ “rt”: “acme.room”, “if”: [“oic.if.r”, “oic.if.rw”], “color”: “blue”, “dimension”: “15bx15wx10h”, “links”: [ {“href”:“/the/light/1”, “rt”:“acme.light”, “if”:[“oic.if.a”, “oic.if.baseline”]}, {“href”:“/the/light/2”, “rt”:“mycorp.light”, “if”:[“oic.if.s” , “oic.if.baseline”]}, {“href”:“/the/fan/1”, “rt”:“hiscorp.fan”, “if”:[“oic.if.baseline”]} ] }

• Interface provides a “view” into a Resource or Collection
• Interface defines allowed methods and semantics on that “view”
• OCF has a set of predefined Interfaces
• Resources can have multiple Interfaces
• ic.if.a

19/37

OCF ER Model

Note: Not from official OCF specification!

Major Changes in OCF 1.0 (Draft) CR from OIC 1.1

 Swagger/OpenAPI for

 Data modeling  Introspection (new)  RAML is still used in main spec definition

20/37

 Enhanced security

 Alignment with IETF ACE model and

AllJoyn

 Better specification of uses of certificates  Better management of onboarding and

• ffboarding processes

 Mandatory access control  System management (eg update)

Summary

 Resource-Oriented Architecture

 “Devices” based on sets of “Resources” accessed through set of abstract CRUD-N “Interaction Mechanisms”  CRUD-N mechanisms are mapped down to specific operations on particular protocols (eg CoAP, HTTPS)  Interface abstraction allows for “Views” into resources  Collection and Link abstractions allow for aggregation of Devices, even if not co-located

 IoTivity

 Open-source implementation of OCF model

 New features in OCF 1.0

 Introspection  Enhanced security 21/37