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
OCF – Result of Consolidation 2014 2015 2016 2017 O PEN C ONNECTIVITY F OUNDATION P UBLIC I NFORMATION – N ON NDA A PRIL 2017 3
OCF – High Level Goals • 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 O PEN C ONNECTIVITY F OUNDATION P UBLIC I NFORMATION – N ON NDA A PRIL 2017 4
OCF & IoTivity Specification Open Source Project Data Modelling Reference Implementation of OCF (and Non-Spec Related Code) Open Source Coordination Coordination Certification Sponsored (funded) by OCF Separate Governance Business (Marketing, Strategy, Membership) Specs & Open Source ready simultaneously O PEN C ONNECTIVITY F OUNDATION P UBLIC I NFORMATION – N ON NDA A PRIL 2017 5
OCF – Conceptual Framework Consumer Enterprise Industrial Auto Education Health Profiles Interaction / Data Model Resource Model Core Data Data Device Discovery Framework Management Transmission Management Security, Identity & Permissions Remote Transports Cloud Access (Smart) O PEN C ONNECTIVITY F OUNDATION P UBLIC I NFORMATION – N ON NDA A PRIL 2017 6
OCF – Resource Model Identifies the type of resource Resource URI rt: Resource Type List of interfaces associated with the resource if: Resource Interface Common Policy associated with resource: prop: Policy Properties discoverable, observable, secure, etc n: Resource Name Friendly name links: Other Resource URI Resources can include links to … Resource other resources Specific … 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 § O PEN C ONNECTIVITY F OUNDATION P UBLIC I NFORMATION – N ON NDA A PRIL 2017 7
Resource Model - examples Resource URI :/a/light1 Resource URI :/a/fan1 rt: oic.ex.light rt: oic.ex.fan if: oic.if.rw if: oic.if.rw prop: discoverable, prop: discoverable 14 observable n: myKitchenFan n: myHallWayLight State: 1 (ON) State: 0 (OFF) Speed: 10 Dim Level: 0 O PEN C ONNECTIVITY F OUNDATION P UBLIC I NFORMATION – N ON NDA A PRIL 2017 8
Common Interaction Model – Transport Agnostic • C REATE Create a new Resource on the Server • • R ETRIEVE Get the current State or representation of a Resource from a Server • • U PDATE Request a partial or complete update to the information stored in a Resource • • D ELETE Remove a Resource from the Server • • N OTIFY Request asynchronous notification of state changes in a Resource • Special-cased to support OBSERVE for publish/subscribe support • O PEN C ONNECTIVITY F OUNDATION P UBLIC I NFORMATION – N ON NDA A PRIL 2017 9
Let’s look deeper at a Resource … Server - DevA /oic/p LED-Light-Co, 40W Equivalent Bulb /oic/d Main Living Room Light /oic/p oic.wk.p /oic/d oic.wk.d /oic/res /switch oic.r.switch.binary /dimming oic.r.light.brightness /switch true /dimming false 100 10
There can be more Properties … pi GoGlow III - 40W mnmn Led-Light-Co /oic/p mnml http://ledlight.com/gg3-40 mnmo GG3-40 11
Resource Type - Data Modeling Defined by: ( see OIC_Resource_Type_Specification ) "oic.r.switch.binary": { "type": "object", "properties": { JSON Schema* "value": { "type": "boolean", • Describes the Properties and "description": "Status of the switch" Representation } } } get: responses : ReSTful API Modelling Language 200: body: (RAML)* application/json: schema: | • Describes the Request and Response { } 12 *JSON Schema and RAML are normative and also can be used for code generation
OCF Specification defines “ oic.wk.p ” Resource Type for platform and its list of Properties 13
And … Additional core resources CR: conditionally required (i.e. if capability is supported) 14
Link How to define the Room contains a device connection /switch with binary switch /a/room between two resources? { “ href ”: “/switch”, Target “ rel ”: “contains”, Relation “anchor”: “/a/room”, Context “ rt ”: “ oic.r.switch.binary ”, “if”: “ oic.if.a ”, Parameters “ bif ”: “ oic.if.baseline ” } 15
Collections • A Resource that also has Links • Links declared in value of the “links” Property DevD “name” “Living Room” “ href ”: “ oic://<DevA>/oic /d”, “ rel ”: “contains”, /room “ rt ”: “ oic.d.light ” “links” “ href ”: “ oic://<DevB>/oic /d”, “ rel ”: “contains”, “ rt ”: “ oic.d.light ” 16
Collections … example “Room” collection – room has lights and fan /my/room/1 { Common Properties “ rt ”: “ acme.room ”, “if”: [“ oic.if.r ”, “oic.if.rw”], Read-Write Property “color”: “blue” , “dimension”: “15bx15wx10h” , Read-only Property Link “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 ”] } ] } Link Target Link Parameters 17
Interfaces • 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 “Room” collection – room has lights and fan Interface views /my/room/1 { “ rt ”: “ acme.room ”, “if”: [“ oic.if.r ”, “oic.if.rw”], oic.if.a oic.if.rw “color”: “blue” , oic.if.s “dimension”: “15bx15wx10h” , oic.if.r oic.if.baseline “links”: [ {“ href ”:“/the/light/1”, “ rt ”:“ acme.light ”, “if”:[“ oic.if.a ”, “ oic.if.baseline ”] }, oic.if.ll {“ 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 ”]} ] } 18
19/37 Note: Not from official OCF specification! OCF ER Model
Major Changes in OCF 1.0 (Draft) CR from OIC 1.1 Swagger/OpenAPI for Enhanced security Data modeling Alignment with IETF ACE model and AllJoyn Introspection (new) Better specification of uses of certificates RAML is still used in main spec definition Better management of onboarding and offboarding processes Mandatory access control System management (eg update) 20/37
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
Recommend
More recommend
