1. How does Generic Interworking work? (R01 based on SAREF discussion)
TP R01
How does Generic Interworking work? (R01 based on SAREF discussion)
Group Name: TP
Source: Joerg Swetina (NEC)
Meeting Date:
Agenda Item:

2. Overview This presentation tells you:TP
Overview
This presentation tells you:
What do we call „Interworking“ and what is the specifics of „Generic Interworking“
That „Generic Interworking“ uses an ontology to configure the IPE.

3. Fundamentals of InterworkingTP
Fundamentals of Interworking
oneM2M compliant Solution
Area Network (e.g. KNX)
(real) Interworked Devices in Area Network
Proxied Devices in the oneM2M System technology
Communicating oneM2M entity (AE, CSE)
REST-ful Resource access
Inter- working
Proxy Application Entity (IPE)
A resource (<AE>, <container> ..)
The (physical) Interworked Device
The technology of the Area Network uses its own data model for communication with Interworked Devices
Knows the data model of KNX and creates/reads oneM2M resources that contain data according to that data model (integer, binary, real …)

4. Problems solved by standardized InterworkingTP
Problems solved by standardized Interworking
Area Network (e.g. KNX)
oneM2M compliant Solution
A resource (<AE>, <container> ..)
Inter- working
Proxy Application Entity (IPE)
The (physical) Interworked Device
IPE
by a different vendor
oneM2M entity (AE, CSE)

5. Problems solved by “Generic” InterworkingTP
Problems solved by “Generic” Interworking
Gen-IWK should work even when a new interworking is applied to a running system
without prior knowledge of- and without the need to compile <flexContainer> specializations.
Gen-IWK introduces an “Operation” (in the Base ontology and as a oneM2M resource type) to correlate output with the related input

6. Specifics of “Generic” InterworkingTP
Specifics of “Generic” Interworking
Uses the external data model that is described in the form of an ontology
Specifies the instantiation of the external data model as oneM2M resources for the purpose of communicating with the IPE
Can be applied to any type of Area Network
As long as the devices, services, data models ... are described through an ontology that is compatible with the oneM2M Base Ontology

7. Specifics of “Generic” Interw...TP
Specifics of “Generic” Interw...
Does not require that the interworked Devices expose/transmit semantic information
Does not require that the oneM2M resources that represent proxied Devices have semantic annotations (RDF data contained in <semanticDescriptor>)
Not needed for communication with the IPE
But useful to contain additional semantic data (like “manufacturer”, relations to other Things …)

8. Limitations of “Generic” Interw...TP
Limitations of “Generic” Interw...
Gen-IWK Rel-2 is not capable of abstraction
The Gen-IWK Rel-2 does not describe data serialization by the IPE for transmission over the Area Network

9. Gen-IWK is not necessarily limited to “interwork” purposes
Can be applied to communication with “native” oneM2M AEs as long as they follow the specified information flow
Since Gen-IWK specifies
oneM2M instantiation of a data model
and communication with the IPE (which is an application!!)
it does not really matter if there is an area network attached to it

10. oneM2M compliant Solution REST-ful Resource access
“native” AE in the oneM2M System
<AE> resource
REST-ful Resource access
“native” oneM2M AE
oneM2M entity (AE, CSE)

11. Ingredient 1: the Base OntologyTP
Ingredient 1: the Base Ontology
A Functionality represents the function necessary to accomplish the task for which a Device is designed.
A Command represents an action that can be performed to support the Functionality
A Service is a representation of a Functionality to a network that makes the Functionality discoverable, registerable, remotely controllable in the network
Input- and OutputDataPoints are Variables of a Service for RESTful Devices. An Operation (is the means of a Service to communicate in a procedure-type manner over the network.
Input- OutputDataPoints and Operations are representation of a Command to a network
Input- and OutputDataPoints are Variables of a Service for RESTful Devices. An Operation (is the means of a Service to communicate in a procedure-type manner over the network.
Input- OutputDataPoints and Operations are representation of a Command to a network
The left side describes machine/technology dependent concepts (Service, Input- OutputDataPoints, Operations)
The right side describes human-understandable concepts (Functionality, Commands) of a Device

12. Example: washing machineTP
Example: washing machine
Service: MotorControl
exposesFunctionality: Set Washing Preferences
InputDataPoint: SetBinary
exposesCommand: Start / Pause
hasDataType: xsd:binary
Device: washing machine Functionality: Set Washing Preferences Service#1: MotorControl has 2 I/O DataPoints and 1 Operation
Service: MotorControl
exposesFunctionality: Set Washing Preferences
Operation: Toggle
exposesCommand: Switch Spin Speed
(no additional data)
Service#2: HeaterControl has 1 InputDataPoint
Service: MotorControl
exposesFunctionality: Set Washing Preferences
OutputDataPoint: textOutput
exposesCommand: Spin_speed_display
hasDataType: xsd:string hasDataRestriction_Pattern (range“OFF”, “MED”, “MAX”)
Service: HeaterControl
exposesFunctionality: Set Washing Preferences
InputDataPoint: SetInteger
exposesCommand: Set_Washing_Temperature_Celsius
hasDataType: xsd:integer
hasDataRestriction_minInclusive: 30 hasDataRestriction_maxInclusive: 90

13. Using the Base OntologyTP
Using the Base Ontology
The oneM2M Base ontology
is extremely simple and flexible
is usually not used ‘as is’ but only provides a blue-print (using sub-classing of concepts) for other ontologies that are describing real-world systems

14. Example: a simplified ontology for KNX devices
KNX (by KNX Association) provides control technology for home and building applications
Devices implement KNX_Functional_Blocks (FB) ≈ Services
One or more functional blocks form a device
Based on Datapoints that are grouped into a Functional Block
KNX_Data_Point_Types (DPT) ≈ Operations
Contain individual data fields for input- or output.
DataFields are of simple type (bool, 3bit Integer, char..) that form a byte array
KNX_Data_Fields ≈ [SimpleType]Variables

15. Example: a KNX dimmer
(Service level): Functional Block Dimming Actuator Basic, standardized by KNX. It contains three DataPoints (Operation level):
Switch, DPT 1.001
Relative dimming, DPT 3.007
Absolute dimming, DPT 5.001
DPT 1.001: 1 Bit DPT for On / Off switching on/off

16. DPT 3.007: 3 Bit DPT dimming with Control (lighter, darker, stop)
DPT 5.001: 8 Bit DPT setting an absolute value (0 – 100 %)

17. Part of the Base Ontology needed for the KNX example
is-a
Area Network
Interworked Device
Device
isPartOf
hasService
hasFunctionality
is-a
exposes Functionality
Service
Functionality
KNXDevice
hasOperation
hasCommand
exposes Command
Operation
Command
hasInput
Input
Variable
is-a
SimpleType Variable
hasValueOf SomeDataType AndRange
rdfs:Literal

18. The KNX System (simplified) KNX classes are sub-classes of the Base Ontology classes
KNX_Area_ Network
KNXDevice
isPartOf
KNX_has FunctionalBlock
KNX_has Functionality
KNX_FunctionalBlock _exposes Functionality
KNXFunctionalBlock
Functionality
KNX_has DataPoint
hasCommand
KNX_DataPoint_ exposes Command
KNX_ DataPoint
Command
KNX_ hasData
hasInput
Field Name
Variable
is-a
SimpleType Variable
hasValueOf SomeDataType AndRange
rdfs:Literal

19. KNX Device type containing KNX standardized Dimming Functionality
KNX_Area_ Network
KNXDevice
isPartOf
KNX_has FunctionalBlock
KNX_has Functionality
KNX_FunctionalBlock _exposes Functionality
KNX_FB_ Dimming_ Actuator_Basic
KNX_ Standardized_ Dimming_Functionality
KNX_has DataPoint
hasCommand
KNX_DPT_ 5.001
KNX_DPT_ Scaling_Command
KNX_DPT_ 3.007
KNX_DPT_ ContolDimming_ Command
KNX_DPT_ 1.001
KNX_DPT_ Switch_Command
KNX_ hasData
KNX_ hasData
KNX_0_ to_100_ Percent
KNX_ StepCode
KNX_ hasData
KNX_ On_Off
KNX_ Increase_ Decrease
KNX_ u8
KNX_ B1
KNX_ U3
KNX_ B1
hasValueOf SomeDataType AndRange
hasValueOf SomeDataType AndRange
hasValueOf SomeDataType AndRange
hasValueOf SomeDataType AndRange
xsd:integer >=0, <=255
xsd:boolean
xsd:integer >=0, <=7
xsd:boolean

20. One joint ontology that imports the Base- and KNX ontology
<rdf:RDF xmlns=" xml:base=" xmlns:KNX=" ... xmlns:Base=" <owl:Ontology rdf:about=" <owl:imports rdf:resource=" <owl:imports rdf:resource=" </owl:Ontology> <!-- // Object Properties --> <rdf:Description rdf:about="&KNX;KNX_hasDataPoint"> <rdfs:subPropertyOf rdf:resource="&Base;hasOperation"/> </rdf:Description> //Classes <rdf:Description rdf:about="&KNX;KNXDataPoint"> <rdfs:subClassOf rdf:resource="&Base;Operation"/>

21. Ingredient 2: InstancesTP
Ingredient 2: Instances
Instantiation of the Base Ontology in oneM2M
<AE> (created by IPE),
or child-<container>,
or child- <flexCont>
of the IPE’s <AE>
is-a
<AE> (oneM2M ADN, ASN)
Interworked Device
Device
consistsOf
hasService
<genericInterworkingService>
Service
hasSub Service
<genericInterworkingOperationInstance>
hasOutput DataPoint
hasInput DataPoint
hasOperation
Output DataPoint
Input DataPoint
Operation
<container> or
<flexContainer>
hasOutput
hasInput
<container> or
<flexContainer>
OperationOutput
Operation Input

22. <genericInterworkingService> and <genericInterworkingOperationInstance>TP
IDP-Link triplet 1 ,
IDP-Link triplet 2 ,
IDP-Link triplet 1 …
inputDataPoint Name
inputDataPoint URI
name of [customAttribute] or « latest » or left empty

23. Ingredient 3: IPE FunctionalityTP
Ingredient 3: IPE Functionality
Initialization
IPE discovers Interworked Devices in the Area Network
For each discovered device it creates a oneM2M resource (<AE> or <container> or <flexContainer>) for a Proxied Device that represents the Interworked Device in the oneM2M System)
For each Proxied Device the IPE shall create child resources: Input- and OutputDataPoints (resource types <container> and/or <flexContainer>) and Services (resource <genericInterworkingService>) according to the description of the device in the ontology.
Input- and outputDataPointLinks of the Services are populated
IPE subscribes to all created resources
Data flow: a oneM2M entity (e.g. an AE) invokes a Service in the Interworked Device writing into a DataPoint (RESTful way).
The AE checks the inputDataPointLinks of the Service to find out to which resource the new data need to be written
The AE UPDATEs (if <flexContainer>) or CREATEs new contentInstance (if <container>) the resource
The IPE gets NOTIFYed about the UPDATE/CREATE of the resource
The IPE serializes the received data and sends it to the Interworked Device

24. Ingredient 3: IPE Functionality (II)TP
Ingredient 3: IPE Functionality (II)
Data flow: a oneM2M entity (e.g. an AE) invokes a Service in the Interworked Device by invoking an Operation (non-RESTful way).
The AE CREATEs new <container> or <flexContainer> resources for operationInput
The AE CREATEs a new <genericInterworkingOperationInstance> under the appropriate Service (resource <genericInterworkingService>) and populates the inputLinks attribute.
The AE subscribes to the new <genericInterworkingOperationInstance>
The IPE gets NOTIFYed about the new <genericInterworkingOperationInstance>
It checks the operationInput attribute of the <genericInterworkingOperationInstance> to find out to which resources contain the input data of the Operation
The IPE UPDATEs the operationState attribute as "data received by application"
The IPE serializes the input data and sends them as parameterized operation to the Interworked Device
The IPE UPDATEs the operationState attribute as "data transmitted to device"
If the operation provides output data the IPE waits until the Interworked Device has finished the operation, CREATEs new <container> or <flexContainer> resources for operationOutput and populates the inputLinks attribute of the <genericInterworkingOperationInstance>
The subscribed AE gets NOTIFYed about the output of the operation and can RETRIEVE the output data
At periodic, implementation specific, times the IPE shall check the expirationTime attribute of all Operation resources of all Proxied Devices and DELETE expired Operations and their OperationInputs and -Outputs

25. <semanticDescriptor> resourcesTP
<semanticDescriptor> resources
For Gen-IWK no <semanticDescriptor> resources are needed
<semanticDescriptor> resources are useful to contain data about the resource to which the <semanticDescriptor> resource is a child
E.g. if the resource describes a device: manufacturer of a device, Energy class, a reference to the Thing that is observed by the device …
These kind of parameters are defined by e.g. SAREF
<semanticDescriptor> resources contain RDF data in their descriptor attribute
The RDF contains data that are usually not part of the payload of the device, such as Context Information
<rdf:RDF <rdf:Description rdf:about="WASH_XYZ_123"> <rdf:type rdf:resource=" <saref:hasManufacturer>XYZ</saref:hasManufacturer> <saref:hasDescription>Very cool Washing Machine</saref:hasDescription> <saref:hasState rdf:resource="WASH_XYZ_123*WashingMachineStatus"/> <saref:hasFunction rdf:resource="WASH_XYZ_123*WashingFunction"/>
<saref:hasService rdf:resource="WASH_XYZ_123*SwitchOnService"/> <saref:hasService rdf:resource="WASH_XYZ_123*MonitorService"/> <saref:isLocatedIn rdf:resource="My_Bathroom"/>
</rdf:Description> … </rdf:RDF>

26. Relation: Base Ontology  SDTTP
Relation: Base Ontology  SDT
In oneM2M the Smart Device Template (SDT) tool is available to describe device types of a system (e.g. Home Appliance Information Model - HAIM)
SDT complements the ontology description of device types as it allows to gather machine / technology dependent concepts of the device. The components of SDT can be mapped as sub-classes of the Base Ontology
Any system whose device types can be described with SDT can also be described by a – Base Ontology compatible - ontology
BO:Service
BO:Operation
BO:Operation Input
BO:Device
BO:Service
BO:Input DataPoint
BO:Output DataPoint
BO:Device
BO:Thing Property
BO:Operation

27. Issues with SAREF
SAREF (Smart Appliances REFerence Ontology) is an ontology that allows to describe Devices, Buildings … on a high level. E.g.
What task is perfomed
Device category
Energyclass ..
It does not specify the parameters for communicating with the device

28. Issues with SAREF (II)
Since SAREF does not specify the “Service” parameters to communicate with the device it cannot be used for Generic Interworking.
OneM2M Base Ontology has no knowledge about Device category, Energyclass
But since the “Device” class is a subclass of “Thing” we can use a subclass of “Thing Property” for these concepts
if a vendor specifies the “Service” part and creates a SAREF compliant ontology it can be used for Genericric Interworking

29. Thanks for your attention!TP
Thanks for your attention!
Q & A
… I am pretty sure you still have questions