Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1 
NEW OPEN SOURCE PROJECT AT HGI FOR SMART HOME DEVICE ABSTRACTION TEMPLATES 
WWW.HOMEGATEWAY.ORG 
ANDREAS SAYEGH (DEUTSC...
2 
TOPICS 
•Introduction to HGI (www.homegateway.org) 
•Smart Home Abstraction Layer: Goals and architecture 
•A tool to u...
3 
HGI’S MANDATE 
•Publish operator requirements for broadband home 
•Establish global ecosystem of companies addressing “...
4 
HGI‘S GOALS FOR SMART HOME ARCHITECTURE & ABSTRACTION LAYER 
1.Provide unified APIs for application developers to comma...
5 
SMART HOME ARCHITECTURE REFERENCE POINTS 
•RP1 – Device Abstraction Layer 
–The local interface that applications on th...
6 
RELATION TO OTHER SMART HOME AND IOT ACTIVITIES 
•Every device automation solution and HAN technology makes use of assu...
7 
GUIDING PRINCIPLES FOR THE SMART HOME DEVICE TEMPLATE 
–Device description is in XML 
–Try to avoid becoming too comple...
8 
EXAMPLE MODULE CLASS 
<ModuleClass name="BooleanState"> 
<Doc>…</Doc> 
<Actions> 
<Action name="get" type="boolean"> <D...
9 
EXAMPLE DEVICE MODULES 
<Modules> 
<Module name="proprietaryPower"> 
<Actions> 
<Action name="on"/> 
<Action name="off"...
10 
EXAMPLE DEVICE 
<?xml version="1.0" encoding="iso-8859-1"?> 
<Domain xmlns="http://hgi.org/xml/dal/1.0" xmlns:xi="http...
11 
STILL SOME OPEN POINTS 
<ModuleClass name="power"> 
<extends domain="hgi.dal.core" class="BooleanState"/> </ModuleClas...
12 
CONCLUSIONS ON THE SDT 
•To be approved by participating organizations (e.g. Broadband Forum, HGI, OneM2M, OSGi-A, Ecl...
13 
SDT WILL BE PUBLISHED UNDER APACHE 2.0 LICENSE 
•The SDT is a tool to model device characteristic. It does not contain...
14 
WORKING TOGETHER ON THE SDT… 
Joint work on SDT 
Map SDT to BBF TRs (if needed) 
Jointly approaching domain specific o...
15 
FROM SMART HOME DEVICE TEMPLATE TO APIS 
•The SDT is a tool to formally specify device type characteristics 
–Current ...
16 
PROCESS STEPS AND STAKEHOLDERS 
HGI RWD050, in a joint effort with OSGi Alliance, OneM2M, Broadband Forum etc. 
Device...
17 
ENVISIONED JOINT WORK W/ ECLIPSE IOT VORTO PROJECT 
•First informal information exchange took place 
•HGI strongly sup...
18 
THANK YOU VERY MUCH A.KRAFT@TELEKOM.DE
19 
BACKUP
20 
WHO ELSE CURRENTLY WORKING? (NOT COMPLETE) 
•AllSeen Alliance 
–Device/service discovery using RPCs over IP, See docu....
21 
HOW APPLICATIONS CAN „KNOW“ HOW TO ACT ON REAL APPLIANCES 
XML 
XML instance 
Model real world appliances as descripti...
22 
HOW APPLICATIONS CAN „KNOW“ HOW TO ACT ON REAL APPLIANCES 
XML 
XML instance 
Washing Machine 
Appliance 
XSD „module_...
Upcoming SlideShare
Loading in …5
×

New Open Source project at HGI for SmartHome Device Abstraction Templates - A Kraft

1,251 views

Published on

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.

Published in: Technology

New Open Source project at HGI for SmartHome Device Abstraction Templates - A Kraft

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 18 THANK YOU VERY MUCH A.KRAFT@TELEKOM.DE
  19. 19. 19 BACKUP
  20. 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. 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. 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

×