OCF OverviewIncluding Summary of New Features in OCF 1.0

Candidate Draft

Michael McCoolIntel

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 4OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA

OCF & IoTivity

Specification

Open Source Coordination

Business (Marketing, Strategy, Membership)

Open Source ProjectReference 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

6APRIL 2017

Core Framework

ProfilesConsumer Enterprise Industrial Auto Education Health

Security, Identity & Permissions

DiscoveryData

Transmission

Data

ManagementDevice

Management

Transports(Smart)

RemoteAccess Cloud

Resource Model

Interaction / Data Model

OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA

OCF – Resource Model

7APRIL 2017

Resource URI

rt: Resource Type

if: Resource Interface

prop: Policy

n: Resource Name

…

…

CommonProperties

ResourceSpecific

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

other resources

OPEN CONNECTIVITY FOUNDATION PUBLIC INFORMATION – NON NDA

Resource Model - examples

8APRIL 2017

14

Resource URI :/a/light1

rt: oic.ex.light

if: oic.if.rw

prop: discoverable,

observable

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 9OPEN 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

oic.r.switch.binary

oic.wk.d

oic.wk.p

false100

/switch true

/dimming oic.r.light.brightness

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

There can be more Properties …

11

/oic/pmnml

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 ParametersLink Target

“Room” collection – room has lights and fan

/my/room/1

Interfaces

18

“Room” collection – room has lights and fanInterface views

oic.if.ll

oic.if.r

oic.if.rwoic.if.s

oic.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

oic.if.a

19/37

OCF ERModel

No

te: No

t from

officia

l OC

F sp

ecificatio

n!

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 offboarding 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