MAS-2014-0369-HGI_Device_Templates HGI SmartHome Appliance Modelling Issues Group Name: Technical Plenary and also MAS group Source: HomeGatewayInitiative

MAS-2014-0369-HGI_Device_Templates

HGI SmartHomeAppliance Modelling Issues

Group Name: Technical Plenary and also MAS groupSource: HomeGatewayInitiative ([email protected])Meeting Date: 2014-03-07Agenda Item: MAS-2014-0369-HGI_Device_Templates


Contents• 1.0 Introduction– 1.1 Device Abstraction– 1.2 Phases of Modeling Process

• 2.0 Issues for the Modelling– 2.1 Different types of Sensors– 2.2 Different Types of Actuators– 2.3 Different Types of Appliances – 2.4 Different Types of Data– 2.5 Different Types of Info

• 3.0 Strawman Proposal

2


1.0 Introduction

• The purpose of this presentation is to 1. explain the types of information HGI considers

useful for Software Developers and End-Users to be able to access, for all kinds of SmartHome Use Cases, appliances and devices

2. Explain the world-wide process of collecting and modelling information which HGI believes would greatly facilitate SmartHome deployments

3. Begin discussion of specific formats („templates“) to facilitate the collection process

3


BBF and HGI collaboration• BBF and HGI are working together on these topics• Both are key stakeholders in developing proposals for

the representation of devices (device or information models)

• BBF endorses the goals and means of working outlined in this presentation (but has not reviewed and endorsed the specifics)

• The specifics are presented as HGI strawman proposals but are not final within HGI or between HGI and BBF

4


1.1 Device Abstraction

• HGI’s work programme on device abstraction was introduced in TP-2013-0304 at Toronto

• Enable 5 main goals for SmartHome Apps:1. Provide unified APIs for application developers to command, control

and query home appliances2. Provide independence from specific home area network (HAN)

technologies so that an application developer does not need to know anything about Zigbee, Z-Wave, wireless M-Bus etc.

3. Enable applications to be portable for similar devices/appliances4. Enable extendibility of the system to additional HAN technology

support without service interruption5. Allow applications to pass-through technology-specific functions

5


PUBLICATIONPUBLICATION

COLLECTIONCOLLECTION

CLEARINGCLEARING

1.2 Phases of Modeling Process( createcollectclearpublishuse )

Domain specific org instantiates template, creating a set of device type models

Send initial template to domain specific organization(s)

Merge different device type models into a single unified model and circulate for approval

Agreed ?

Publish agreed domain specific and unified device type templates

YESYES

Define mapping rules between different domain specific device type models

NONO

Only 1 model ?

(for this device type)

NONO

YESYESIdentify the device type model

Vendors can createcongruentp

roduct models !

Develop initial template after initial talks with stakeholders

WE ARE HERE


PUBLICATIONPUBLICATION

COLLECTIONCOLLECTION

CLEARINGCLEARING

1.2 Phases of Modeling Process( createcollectclearpublishuse )

Domain specific org instantiates template, creating a set of device type models

Send initial template to domain specific organization(s)

Merge different device type models into a single unified model and circulate for approval

Agreed ?

Publish agreed domain specific and unified device type templates

YESYES

Define mapping rules between different domain specific device type models

NONO

Only 1 model ?

(for this device type)

NONO

YESYESIdentify the device type model

Vendors can createcongruentp

roduct models !

Develop initial template after initial talks with stakeholders

WE ARE HERE

Re-usable fragments Washing

Machine

DimmableLamp

Air Conditioner

Air Conditioner

Air Conditioner(from Org-A)

Air Conditioner(from Org-B)

Air Conditioner

Vendor-X Air Conditioner

Product ABC

Template did not work ??

WITH EXAMPLE


2.0 Issues for the Modelling

• Different types of Sensors, Actuators, Appliances• Different Types of Data• Different types of Information– Useful to programmers ...– Useful to end-users ...

• Agreeing on a structure containing re-usable fragments (“template“) to collect/import data on devices and appliances from the widest possible range of sources

8


2.1 Different types of Sensors- Examples -

9


2.2 Different Types of Actuators - Examples -

10


2.3 Different Types of Appliances - Examples -

11


2.4 Different Types of Data- Lists of types and examples. Not complete -

Sensors Actuators

binary

%

Motion xyz

Accel x'y'z'

real

Door Open

Battery level

timestamp logged time

binary Electronic Lock

ON / OFF

Msg-string Product code

Temperature

Record / Pause

Ffwd/Fwd/Stop/...

enum Switch posn. 1,2,3..

enum

Power level%

Speedreal

timestamp Wakeup

Msg-string error code

Keyboard char.

Toggle up/down

Counter 0,1,2, ....

Real world examples Real world examples

12

Need Re-usable

fragments to

describe these !


2.5 Different Types of Info- Desirable for Users or Developers ? -

USER likes ? SW-Dev likes ?

Information

Manufacturer NameHuman-readable ASCII string ? GS1 ID? IANA Enterprise Code?

Product Type / Class / FamilyHuman-readable ASCII string ? ENUM-list

Product Identifier (Hardware)Human-readable ASCII string ? GTIN (14-digit number)?

Product production pointHuman-readable ASCII string ? GLN ID?

Physical attributes (see schema.org or GoodRelationsweight, depth, length, width, color, etc ...

Product environmental characteristics URI efficiency rating, pollution rating, total footprint rating, etc ?

Product online user manual URI Product online tech manual URI (may require authentication) Product network technology (Zigbee 2.0, Zwave 1.1, etc )

ENUM-list? Or maybe SCSV string list? Product Power Supply Voltage Product Power Supply Max. Power

( + all the previous sensor/actuator data/control info! ) 13


3.0 Strawman Proposal

• The following pages are provided to trigger discussion, not as a specific solution

• It is requested that oneM2M discuss the basic structures needed for the modelling, using the following examples as indications of basic ideas

• The goal is to provide a “ container“ for all the different kinds of information/data described in the previous pages, built up from relatively few “ re-usable modules“

14


Some Guiding Principles– Device description is in XML; templates in XSD– Try to avoid becoming too complex– Need mechanism for referencing other definitions– 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

15

Not addressed:

Standard dictionary for

terms such as power,

light, etc.

Not addressed:

Standard dictionary for

terms such as power,

light, etc.


Namespace Declarations

– An XML Schema– Using some standard XML elements

• Needed for imports

<xs:schema targetNamespace="http://hgi.org/xml/dal/1.0" xmlns="http://hgi.org/xml/dal/1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>

Schema

16


Imports

– Schema provides Imports tag for importing one or more Domain definitions

– Imported Domain is part of document – not merely a reference

<xs:group name="Imports"> <xs:sequence> <xs:element minOccurs="0" ref="Imports"/> </xs:sequence> </xs:group> <xs:element name="Imports"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" ref="Domain"/> </xs:sequence> </xs:complexType> </xs:element>

Schema

Ideally the descriptions build on standard definitions

17


DomainsSchema

Multiple device descriptions are collected in a Domain

Domain has a uniqueid and consists of:–Imports section –Modules sectioncontainingModuleClasses–Devices section

xml:base tag needed for compatibility with xincludes

18


Example Domain Declaration

– The default namespace is bound to the HGI-DAL Schema– The Domain defines a unique id– Imports are realised using standard XML includes

• Namespace for XML Includes must also be declared• Domain documents can be included in the Imports section• Modern standard XML tools are xinclude aware

<?xml version="1.0" encoding="iso-8859-1"?><Domain xmlns:xi="http://www.w3.org/2001/XInclude"

xmlns="http://hgi.org/xml/dal/1.0" id="com.kom”>

<Imports> <xi:include href=”http://hgi.org/dal-core.xml" parse="xml" /> </Imports> ...

Document

Device Descriptions are XML Domain Documents

19


DocumentationSchema

Small HTML-style tag-set for documenting the defintion

Consists of paragraphsand images–DocText groupprovides mark-upfor emphasis etc.–If there is only oneparagraph the tagcan be omitted

20


Domain ModulesSchema

Reusable elements are declared in the Modules section

ModuleClass consists of:–Name – unique in theDomain–Actions section –Events sectionCan extend anothermodule referenced by–Domain id (must beincluded)–ModuleClass name

Do not use globally

unique identifiers for

module classes – Domain should act as a

scope.

Do not use globally

unique identifiers for

module classes – Domain should act as a

scope.

21


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 operationsfor reading and setting the state

22


Domain DevicesSchema

Now have all the elements to define a device

Consists of– Some meta-info

• Vendor• Model• etc

– Modules section• Contains Modules• Not ModuleClasses

23


Devices Modules

<xs:element name="Modules"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" ref="Module"/> </xs:sequence> </xs:complexType></xs:element><xs:element name="Module" type="ModuleDef"/>

Schema

Device Modules essentially the same a ModuleClasses

– Can extend aModuleClasse

– Cannot be extended

• The ModuleClass is the unit of re-use• Hence the basis of abstraction

• Device Modules can extend standard ModuleClasses• ModuleClasses can be imported from other domains• Modules cannot

24


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 – reducesdefinition effort–But little abstraction

Only need hgi-core

domain to use power

module

Only need hgi-core

domain to use power

module

25


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.kom"> <Imports> <xi:include parse="xml" href="http://hgi.org/dal-core.xml"/> </Imports> <Devices> <Device id="switch.power"> <DeviceInfo>

<Name>PowerSwitch</Name><Vendor>KOM Laboratories</Vendor>

</DeviceInfo> <Modules> see previous slide </Modules> </Device> </Devices></Domain>

Document

A device with a power switch defined by KOM Lab Ltd....

Details of device discovery to be determined, but device can be used by applications understanding:–power–BooleanState

26


4.0 Moving forward

• The development of a template/container does not in itself provide the needed abstraction but provides the necessary language to model the devices

• HGI is committed, along with key partners OSGi Alliance, BBF and SmartM2M to bring proposals in near future on these steps to OneM2M as details are decided

27