OCF Overview Overview Including Summary of New Features in OCF 1.0 Candidate Draft Michael McCool...
Transcript of OCF Overview Overview Including Summary of New Features in OCF 1.0 Candidate Draft Michael McCool...
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)
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
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