OSGi Community Event 2014 Abstract: HGI has defined a new project, under Apache 2.0 open source licensing, to create a framework and set of examples describing SmartHome appliance functionality (control and read-out of devices) using XML and with XSD to ensure proper conformance. Individuals/companies/fora are invited to comment and contribute. The goal of the project is to have a basis for technologies such as OSGi to provide appliance interface APIs to software application developers, independent of the home area network technology (ZigBee, EnOcean, Z-Wave, EchonetLite etc). Use of the SmartHome Device Templates (SDTs) is proposed as part of the extended API for the OSGi Device Abstraction Layer (DAL, RFC196), an element within SmartHome gateway implementations. The SDT is explicitly aimed to be applicable within multiple execution environments however. HGI has long been in discussions with OSGi Alliance, Broadband Forum, oneM2M, EnOcean Alliance, EchonetLite Consortium and other bodies regarding the necessity of SDTs to enable a mass market in Smart Home services. HGI also is in close collaboration with the European Commission’s "Smart Appliances" project, which complements the new HGI project. HGI plans to later hold a proof of concept event that allows HGI companies to integrate and demonstrate their SDT and DAL technologies (applications, abstraction layer, device drivers, end devices, possibly cloud platforms). The 25-minute presentation will cover the above points, reference a number of relevant projects with similar goals, outline the initial approach of HGI, and invite comments. A close collaboration with OSGi activities on DAL and API design is crucial for a successful application of the SDT to the OSGi framework. Speaker Bio: Andreas Kraft studied Computer Science at the Technical University of Berlin, Germany. Since 2000 he works for Deutsche Telekom AG as a Senior Systems Architect in the field of Connected Home Services. His current activities include strategies for and design of OSGi based service architectures for connected homes and Ambient Assisted Living. Before that he was involved in the design and development of platforms for remote access and control of devices and services in residential homes. Andreas Kraft also represents Deutsche Telekom in standardization groups, such as VDE/DKE, ISO/IEC, CENELEC, and the UPnP Forum. His current involvements with the OSGi Alliance include co-chairing the Residential Expert Group as well as to be a board member of the OSGi Users.

1. 1
NEW OPEN SOURCE PROJECT AT HGI FOR SMART HOME DEVICE ABSTRACTION TEMPLATES
WWW.HOMEGATEWAY.ORG
ANDREAS SAYEGH (DEUTSCHE TELEKOM)
ANDREAS KRAFT (DEUTSCHE TELEKOM)
LINDSAY FROST (NEC)
DUNCAN BEES (HGI, CTO)
EclipseCon 2014, Paper 1162, Ludwigsburg,
Wednesday, October 29, 2014 - 17:00 to 17:35

2. 2
TOPICS
•Introduction to HGI (www.homegateway.org)
•Smart Home Abstraction Layer: Goals and architecture
•A tool to unify device modeling: The Smart Home Device Template (SDT)
•Working together on the SDT within the standards eco-system
•Moving from modeling to implementation

3. 3
HGI’S MANDATE
•Publish operator requirements for broadband home
•Establish global ecosystem of companies addressing “the networked home” market
•Operational Goals
•Focus on a few strategic topics (like smart home)
•Promote interoperability
•Represent all HGI members and influence standards for broadband

4. 4
HGI‘S GOALS FOR SMART HOME ARCHITECTURE & ABSTRACTION LAYER
1.Provide unified APIs for application developers to command, control and query home appliances
2.Independence of underlying HAN technologies so that an application developer doesn’t need to know anything about Zigbee, Z-Wave, wireless m-bus etc.
3.Enable applications to be portable across different HGI compliant devices
4.Enable extendibility of the system to support additional HAN technology without service interruption
5.Applications should be able to use a pass-through mechanism to use technology-specific functions

5. 5
SMART HOME ARCHITECTURE REFERENCE POINTS
•RP1 – Device Abstraction Layer
–The local interface that applications on the gateway use
•RP2 – Device Driver Interface
–The interface to integrate HAN technologies
•RP4 – Remote Interface
–The interface between an operator cloud platform and the gateway
•RP7 – Cloud API
–The interface provided to third parties from the operator cloud platform
HOME GATEWAY
D1
D2
D3
Dx
Abstraction Layer
RP2
Remote Access Agent
App 1
App N
…
RP4
Remote Access Middleware
RP7
RP1
RP1 requires a generic model of Smart Home devices. The SDT will provide such models in a platform independent way.
Cloud and Local Applications need to reference Device Information Models

6. 6
RELATION TO OTHER SMART HOME AND IOT ACTIVITIES
•Every device automation solution and HAN technology makes use of assumed/defined models (known properties) for the connected devices, e.g. .
–UPnP, EchonetLite, EnOcean, DECT ULE, KNX, ZigBee
•Instead of creating a „superset“ of those HAN models, can a modular extensible modeling template be defined to describe almost every device type?
•Unification is also required among other organizations working on device abstraction (e.g. AllSeen Alliance, CENELEC, Eclipse IoT, ETSI SmartM2M, IEEE P2413 IoT Architecture, OpenIoT, Open Interconnect Consortium)

7. 7
GUIDING PRINCIPLES FOR THE SMART HOME DEVICE TEMPLATE
–Device description is in XML
–Try to avoid becoming too complex
–Mechanism for referencing other definitions required
–Rely on standard XML semantics
•Description should be a valid XML document
•Do not introduce additional semantics (e.g. <import-device id="…"/>)
•Use of standard XML tools (parser, XSLT) should be possible
–Identify unit of re-use and abstraction

8. 8
EXAMPLE MODULE CLASS
<ModuleClass name="BooleanState">
<Doc>…</Doc>
<Actions>
<Action name="get" type="boolean"> <Doc> Obtain the current associated state. </Doc>
</Action>
<Action name="setTarget">
<Doc> Obtain the current associated state. </Doc>
<Arg name="value" type="boolean"> <Doc> Desired value of the associated state. </Doc> </Arg>
</Action>
</Actions>
</ModuleClass>
Document
BooleanState for modelling underlying binary state
–Provides operations for reading and setting the state

9. 9
EXAMPLE DEVICE MODULES
<Modules>
<Module name="proprietaryPower">
<Actions>
<Action name="on"/>
<Action name="off"/>
<Action name="state" type="string"/>
</Actions> </Module>
<Module name="power">
<extends domain="hgi.dal.core" class="BooleanState"/> </Module>
</Modules>
Document
Power – candidate for BooleanState
Vendor can define „inline“ proprietary modules
–Simpler – reduces definition effort
–But little abstraction
•Use ModuleClasses to abstract within the domain
•Use standard ModuleClasses to abstract across domains

10. 10
EXAMPLE DEVICE
<?xml version="1.0" encoding="iso-8859-1"?>
<Domain xmlns="http://hgi.org/xml/dal/1.0" xmlns:xi="http://www.w3.org/2001/XInclude" id="com.telekom"> <Imports>
<xi:include parse="xml" href="http://hgi.org/dal-core.xml"/>
</Imports>
<Devices>
<Device id="switch.power">
<DeviceInfo>
<Name>PowerSwitch</Name>
<Vendor>Deutsche Telekom</Vendor>
</DeviceInfo>
<Modules>
… see previous slide …
</Modules>
</Device>
</Devices>
</Domain>
Document
A device with a power switch defined by DTAG ...
Details of device discovery to be determined, but device can be used by applications understanding:
–power
–BooleanState

11. 11
STILL SOME OPEN POINTS
<ModuleClass name="power">
<extends domain="hgi.dal.core" class="BooleanState"/> </ModuleClass>
Document
E.g. how to include semantics
Vs.
<Module name="power">
<extends domain="hgi.dal.core" class="BooleanState"/> </Module>
An application needs to not only know about a device’ interface, but also about its semantics, as e.g. a BooleanState could be used for switches, door openers, blinds etc.
Semantics may either introduced on class level, or on concrete device level – to be decided (ModuleClass or Module).

12. 12
CONCLUSIONS ON THE SDT
•To be approved by participating organizations (e.g. Broadband Forum, HGI, OneM2M, OSGi-A, Eclipse?)
•Template has an informal (text) and a formal section (machine-readable, probably XML based)
•Template is intended to be filled in / instantiated for specific Appliances by domain specific organizations and vendors
HGI defines the XSD template under Apache 2 rules.

13. 13
SDT WILL BE PUBLISHED UNDER APACHE 2.0 LICENSE
•The SDT is a tool to model device characteristic. It does not contain any technology- specific information.
•HGI publishes only the SDT itself under Apache 2.0 license, no derivatives.
•Anyone who uses the SDT has all commercial flexibility of the Apache 2.0 license.
•SDT contributions must be made using Github
–Traceability and authenticity of contributions and modifications
–Similar model to OSGi Alliance
•HGI will publish intermediate results as needed (and approved)
•Any interested party may comment and propose changes
The royalty-free open source license model of the SDT is required to encourage contribution and commenting, and of course usage of the SDT.

14. 14
WORKING TOGETHER ON THE SDT…
Joint work on SDT
Map SDT to BBF TRs (if needed)
Jointly approaching domain specific organizations (verticals)
Joint work on SDT
Map ontology template to OSGi technology
Jointly approaching domain specific organizations (verticals)
Instantiates SDT with their respective device characteristics
Joint work on SDT Map SDT to specific technologies:
•ETSI M2M REST APIs
•EEBus APIs Jointly approaching domain specific organizations (verticals)
Edit and align a SDT
Liaise SDT to domain specific organizations
Instantiates SDT with their respective device characteristics
Any unification effort needs to accommodate the end to end value chain of Smart Home services to gain maximum impact
Application and platform
developers
Operators
OEMs and vendors
Semiconductors
Operators
OEMs and vendors
Semiconductors
HAN technology owners and vendors
Application and platform Developers OEMs and vendors
Application and platform
Developers
OEMs and vendors

15. 15
FROM SMART HOME DEVICE TEMPLATE TO APIS
•The SDT is a tool to formally specify device type characteristics
–Current status: SDT is an XML schema
•The SDT then is used to create device models
•The device model XML documents then are used to create platform specific APIs (e.g. OSGi service platform)
–Means and process are out of scope for HGI
•These APIs must then be implemented for the platform
–API implementation’s main purpose is to map API invocations to HAN technology specific operations
SDT
(XML schema)
Device Model (XML document)
Translation to platform specific API (PSA)
Implementation of the PSA

16. 16
PROCESS STEPS AND STAKEHOLDERS
HGI RWD050, in a joint effort with OSGi Alliance, OneM2M, Broadband Forum etc.
Device Model
(XML document)
Translation to Platform Specific API (PSA)
Implementation of the PSA
To be created by HAN appliance vendors / manufacturers, HAN technology owning organizations like Zigbee Alliance, ULE Alliance, EnOcean Alliance, Z-Wave Alliance
To be specified by platform technology owners like OSGi Alliance, OneM2M
To be implemented by vendors of platform products.
For open source platforms (e.g. Eclipse Smart Home, Alljoyn), translation can be specified and implemented by other entities too.
To be implemented by vendors of platform products
For open platforms like OSGi service platform, anyone can implement the API incl. device manufacturers, free programmers
SDT
(XML schema)
1
2
3
4

17. 17
ENVISIONED JOINT WORK W/ ECLIPSE IOT VORTO PROJECT
•First informal information exchange took place
•HGI strongly supports the IoT Vorto project, and would appreciate the use of the SDT as IoT Vorto information model basis to avoid yet another modeling method
•HGI also intends to have a formal liaison with Eclipse Foundation regarding IoT topics
•Joint work on the SDT to ensure applicability for IoT Vorto
–Apache 2.0 license of SDT allows for almost arbitrary use, and also enables anyone to contribute

18. 18
THANK YOU VERY MUCH A.KRAFT@TELEKOM.DE

19. 19
BACKUP

20. 20
WHO ELSE CURRENTLY WORKING? (NOT COMPLETE)
•AllSeen Alliance
–Device/service discovery using RPCs over IP, See docu. Wiki, Bylaws , IPR Policy
–Code and IPR under ISC license (like BSD) which is free for non- commercial use
•CENELEC ‘Technical Report IEC 62746-2’, Draft version, ‘ Technical Standard of CLC TC205 WG18’
•Eclipse IoT Information Model Repository
•ETSI SmartM2M – Smart appliances ontology project
•IEEE P2413 “IoT Architecture”
–Define: descriptions various IoT domains and abstractions and device models
•OpenIoT
–based on the W3C Semantic Sensor Networks ontology (ssn), the SPITFIRE ontology (spt) and the LSM vocabulary
•Open Interconnect Consortium
–Certified systems use FRAND, code available under Apache 2.0, v1.0 Nov2014
•... and more

21. 21
HOW APPLICATIONS CAN „KNOW“ HOW TO ACT ON REAL APPLIANCES
XML
XML instance
Model real world appliances as descriptive structures
Washing Machine
Appliance

22. 22
HOW APPLICATIONS CAN „KNOW“ HOW TO ACT ON REAL APPLIANCES
XML
XML instance
Washing Machine
Appliance
XSD „module_1“
XSD „module_2“
Option A
Option n
XSD Template (Collection)
binary
real
timestamp
Msg-string
enum
…
Model real world appliances as descriptive structures