OCF Fundamentals
Ravi Subramaniam
Principal Engineer, Intel Corporation
1
Fundamental Fundamentals
OCF Resource Model
Mapping onto Comms Transports
2
Many kinds of devices …
Controller
OIC Scope
OIC Scope
(anticipated)
(current)
Controller App
Cloud Servers
service #1
domain
Cloud Servers
service #2
domain
Controller
Things
Local
Remote
Server to Server
3
3
Many vertical/domains …
• Legacy vertical services usually designed as silos
Home Health Domain
 No common way to communicate among them
Insulin level low!
Need Help!
Health
Home
Industrial
Health
Home
Industrial
Common Platform
Health
Smart Home Domain
4
Home
Industrial
…
OIC Scope
…
Discovery
Addressing
Messaging
Security
…
• A common platform provides a foundation
for vertical services to collaborate and interwork
by providing common services and data models
Interoperability …
•
•
Full interoperability from the connectivity layer up to the service layer
is the only way to truly guarantee a satisfactory UX
Interoperability at the Connectivity and/or Platform layer only
provides partial interoperability which can ultimately lead to
fragmentation
① Connectivity Level
Interoperability
② Platform Level
Interoperability
③ Service Level
Interoperability
Vertical
Services
Vertical
Services
Vertical
Services
Vertical
Services
Vertical
Services
Vertical
Services
Platform
Platform
Platform
Platform
Platform
Platform
Connectivity
Connectivity
Connectivity
Connectivity
Connectivity
Connectivity
OIC Scope
5
Today … Transport Oriented …
4/7/2016
Applications & Services
Data & Control Points
Transports
Transports
6
Protocol Abstraction
4/7/2016
Applications & Services
Data & Control Points
Protocols
Protocols
Transports
Transports
7
OCF Framework
Application
Data & Control Points
OCF Resource Model
OCF Framework
• Interoperability
at protocol,
data model and
information
model levels
• P2P
Data & Control Points
OCF Resource Model
OCF Protocols
OCF Protocols
Transports*
Transports*
*Transports not defined by OCF
Apps &
Services
OCF
Framework
Apps &
Services
Resources
Context
Behaviours
Ah … a light bulb !!
11
“Client”
“Need light”
“Server”
Device
12
Manufacturer Description
LED-Light-Co, 40W Equivalent Bulb
My Description
Main Living Room Light
Power
Off
“Client”
Done
“Server”
Device
13
Manufacturer Description
LED-Light-Co, 40W Equivalent Bulb
My Description
Main Living Room Light
Power
Off
On
OIC Scope
• Declarative: By declaring
expected outcomes and intent
on state i.e. what
- Power(in)
- true(on), false(off)
- properties
Dimming
SetDimmingLevel
- dimmingSetting (int)
- step (int)
- range [0-100]
- step(in), range(in)
Brightness
- brightness (int)
of and operations on things i.e. how
SetSwitch
BinarySwitch
Resources
• Imperative: By defining functions
Functions
- Input & Output Parameters
SetBrightness
e.g., Light bulb
- State + Objects
*Fixed set of verbs (CRUDN)
- Resource oriented in RESTful Architecture
- brightness (in)
- (Verbs + Objects)
- RPC model
14
14
Resource &
Uniform Resource Identifier (URI)
Device
15
/oic/p
Manufacturer
Description
LED-Light-Co, 40W Equivalent Bulb
/oic/d
My Description
Main Living Room Light
/switch
Power
false
Off
Property Name
Property Value
Property
DevA
16
/oic/p
“mnmn”: “LED-Light-Co”,
LED-Light-Co,
LED-Light-Co, 40W
40W Equivalent
Equivalent Bulb
Bulb
“mnmo”: “40W-EB”
/oic/d
Main
LivingLiving
Room
LightLight”
“name”:
“Main
Room
/switch
false
Off false
“value”:
Device A
Client
Device B
Server
Client and
Server as
Roles
Device A
Client
Server
Device B
Server
Client
“Discovery”
Client
RETRIEVE oic://<DevA>/oic/res
Light
/oic/p
“mnmn”: “LED-Light-Co”,
“mnmo”: “40W-EB”
/oic/d
“name”: “Main Living Room Light”
/oic/res
/switch
19
/oic/p
/oic/d
/light
oic.wk.p
oic.wk.d
oic.r.switch.binary
“value”:
falsefalse
Resource Type
• Resource Template
Client
response
Light
/oic/p
“mnmn”: “LED-Light-Co”,
“mnmo”: “40W-EB”
/oic/d
“name”: “Main Living Room Light”
/oic/res
/switch
20
/oic/p
/oic/d
/light
oic.wk.p
oic.wk.d
oic.r.switch.binary
“value”:
falsefalse
“Control”
Client
UPDATE oic://<DevA>/switch
{ “value”: true }
Light
/oic/p
“mnmn”: “LED-Light-Co”,
“mnmo”: “40W-EB”
/oic/d
“name”: “Main Living Room Light”
/oic/res
/switch
21
/oic/p
/oic/d
/light
oic.wk.p
oic.wk.d
oic.r.switch.binary
“value”: false
Client
200
{ “value”: true }
Light
/oic/p
“mnmn”: “LED-Light-Co”,
“mnmo”: “40W-EB”
/oic/d
“name”: “Main Living Room Light”
/oic/res
/switch
22
/oic/p
/oic/d
/light
oic.wk.p
oic.wk.d
oic.r.switch.binary
“value”:
false true
Light
/oic/p
“mnmn”: “LED-Light-Co”,
“mnmo”: “40W-EB”
/oic/d
“name”: “Main Living Room Light”
/oic/res
23
/oic/p
/oic/d
/light
/dimming
oic.wk.p
oic.wk.d
oic.r.switch.binary
oic.r.light.brightness
/light
“value”: true
/dimming
“value”:
false 100
R
e
t
r
i
e
v
e
24
U
p
d
a
t
e
Client
CRUDN
Entity
Handler
25
Client
Entity
Handler
Protocols
Transport
26
Protocols
Mapped
Transport
Client
Entity
Handler
CoAP
DTLS
UDP
IP
27
Transport
Specific
CoAP
DTLS
UDP
IP
Putting it all together …
OIC
Roles
RESTful
Resource
Model
Layer
OIC
Client
OIC
Server
OIC
Resource
Implementation
Specific
Protocol
Layer
28
OIC
Device
OIC
Device
Connectivity
Connectivity
Entity
(sensor /
actuator
interface)
OIC
Abstraction
Interfaces
• Information Model
• Resource oriented
• RESTful architecture
• Semantics
• Physical abstraction
• Data Model
• For vertical and device
• Data connectivity abstraction
• Protocol and layer agnostic
• Dynamic and late binding
Expanding on the preliminary examples ….
29
Uniform Resource Identifier (URI)
Relative Reference
Form: /<path>?<query>
Example: /oic/p
URI
Form: oic://<reg-name>/<path>?<query>
Example: oic://<UUID>/oic/p
• “oic” is the scheme for constructing and parsing the main parts
• Path: is a segmented name (used opaquely by recipient); not to be
interpreted as hierarchy; case sensitive
• Query: Separator is ‘;’, order of query is significant (when URI is used
as index in proxy, caches etc), ‘filter’ is a reserved key
30
C
r
e
a
t
e
R
e
t
r
i
e
v
e
U
p
d
a
t
e
D
e
l
e
t
e
Five Methods
31
N
o
t
i
f
y
Let’s look deeper at a Resource …
Server - DevA
/oic/p
LED-Light-Co, 40W Equivalent Bulb
/oic/d
Main Living Room Light
/oic/res
32
/oic/p
/oic/d
/switch
/dimming
oic.wk.p
oic.wk.d
oic.r.switch.binary
oic.r.light.brightness
/switch
true
/dimming
false
100
There can be more Properties …
/oic/p
33
pi
GoGlow III - 40W
mnmn
Led-Light-Co
mnml
http://ledlight.com/gg3-40
mnmo
GG3-40
Resource Type
"oic.r.switch.binary": {
"type": "object",
"properties": {
"value": {
"type": "boolean",
"description": "Status of the switch"
}
}
}
get:
responses :
200:
body:
application/json:
schema: |
{
}
34
Defined by:
(see OIC_Resource_Type_Specification)
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
OCF
Specification
defines
“oic.wk.p”
Resource
Type for
platform and
its list of
Properties
35
And …
Additional
core
resources
CR:
conditionally
required (i.e.
if capability is
supported)
36
Structure
Complexity
Context
Behaviours
37
How to represent …
•
•
•
•
Lights in a room
All the devices in a room
Rooms on a floor
All floors in a building
• Devices in a group
• Members in a family
• A star topology
38
Living Room
Main Light
Table Light
Link
How to define the
connection
between two
resources?
/a/room
Room contains a device
with binary switch
/switch
{
“href”: “/switch”,
Target
“rel”: “contains”,
Relation
“anchor”: “/a/room”,
Context
“rt”: “oic.r.switch.binary”,
“if”: “oic.if.a”,
“bif”: “oic.if.baseline”
}
39
Parameters
Collections
• A Resource that also has Links
• Links declared in value of the “links” Property
DevD
“name”
/room
40
“links”
“Living Room”
“href”: “oic://<DevA>/oic/d”,
“rel”: “contains”,
“rt”: “oic.d.light”
“href”: “oic://<DevB>/oic/d”,
“rel”: “contains”,
“rt”: “oic.d.light”
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
41
Link Parameters
Interfaces
• Interface provides a “view” into a Resource or Collection
• Interface defines allowed methods and semantics on that “view”
• OCF has predefined Interfaces
Interface views
“Room” collection – room has lights and fan
/my/room/1
{
oic.if.baseline”
“oic.if.rw”
“oic.if.s”
“oic.if.r”
“oic.if.ll”
}
42
“rt”: “acme.room”,
“if”: [“oic.if.r”, “oic.if.rw”],
“oic.if.a”
“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.baseli
{“href”:“/the/fan/1”, “rt”:“hiscorp.fan”, “if”:[“oic.if.baseline”]}
]
Other Interfaces
Batch – “oic.if.b”
• Request forwarded to Link targets
• Single Response with aggregated “target” responses
Link Modify – “oic.if.lm” (under review)
Factory – “oic.if.lf” (under review)
Parameter – “oic.if.p” and “oic.if.rp” (under review)
43
Complexity, Context & Behaviours
• Also have
• Scenes – Pre-defined settings for a number of resources
(more details in subsequent presentation)
• Rules – If This Then That
• Scripts – A piece of code
44
Navigating the Specs
• Covered in this presentation
• Core
• Resource Type Specification (SmartHome)
• SmartHome Device Specification
• Not covered in this presentation
• Security
• Remote Access
45
Thank You
46