hes interoperability

HES InteroperabilityHES Interoperability

Ron Ambrosio & Dritan KaleshiRon Ambrosio & Dritan Kaleshi

19/02/200319/02/2003 SC25WG1/N1058 - Presentation on HES InteroperabilitySC25WG1/N1058 - Presentation on HES Interoperability Kaleshi, Ambrosio Kaleshi, Ambrosio 22

OverviewOverview

ProblemProblem

Reading Interoperability GuidelinesReading Interoperability Guidelines

Issues & SuggestionsIssues & Suggestions

Phase II - Taxonomy & LexiconPhase II - Taxonomy & Lexicon

TimelineTimeline

DiscussionDiscussion


So….So….The aimThe aim::

Making two Making two productsproducts built from different manufacturers built from different manufacturers connected overconnected over possibly different communicationpossibly different communication systems systems toto interworkinterwork together safely, correctly, and securely. together safely, correctly, and securely.

and and the problemthe problem:: Too manyToo many systems already in advanced stages of systems already in advanced stages of

standardisation and/or industry adoption (CAL/CEBus, standardisation and/or industry adoption (CAL/CEBus, ECHONET, Konnex, LonWorks, ….)ECHONET, Konnex, LonWorks, ….)

Models are very control oriented; furthermore application models Models are very control oriented; furthermore application models emphasise emphasise syntax at very low levelsyntax at very low level. .

Unifying them requires further abstraction in a model framework Unifying them requires further abstraction in a model framework (which has been done prior to interop project)(which has been done prior to interop project)

Further abstraction brings higher risk for adoption.Further abstraction brings higher risk for adoption.


Reading the Interoperability GuidelinesReading the Interoperability GuidelinesQuite complete set of requirementsQuite complete set of requirementsIn particular the document In particular the document (SC25 N748 and the FDIS version)(SC25 N748 and the FDIS version):: Confines the search for solution to Presentation and Confines the search for solution to Presentation and

Application Layers only (OSI RM Layer 6 and 7)Application Layers only (OSI RM Layer 6 and 7)Effectively Application Layer only; management functions withinEffectively Application Layer only; management functions within

Requires interoperability to be specified for:Requires interoperability to be specified for:ConfigurationConfigurationManagementManagementOperationOperationIn all possible combination of particular subsystems.In all possible combination of particular subsystems.

With very comprehensively defined safety requirements.With very comprehensively defined safety requirements.


Interop Guidelines: addressing (naming), data Interop Guidelines: addressing (naming), data representation/encapsulation…representation/encapsulation…

AddressingAddressing Application layer addressing should be independent from the Application layer addressing should be independent from the

underlying transport mechanism.underlying transport mechanism.Effectively this means that object namespace should be complete Effectively this means that object namespace should be complete and independent of the transport layer. Fits the OSI xSAP model and independent of the transport layer. Fits the OSI xSAP model nicely.nicely.

Information EncapsulationInformation Encapsulation Common Value Type Primitives Common Value Type Primitives Good role for DCTP, but it needs expanding.Good role for DCTP, but it needs expanding.

Agree how to represent elements at the object interface in terms of Agree how to represent elements at the object interface in terms of datatypes; it does not matter how the object process represents it datatypes; it does not matter how the object process represents it internally and how this is transported at protocol/wire level#internally and how this is transported at protocol/wire level#

E.g. Temperature::= float E.g. Temperature::= float DCTP float DCTP float LonWorks IWF:: LonWorks IWF:: LonFloatLonFloat


Interop Guidelines Interop Guidelines App Models and Lexicon App Models and Lexicon

Lexicon of Lexicon of common actionscommon actions covering { covering { name, action, name, action, input(s), output(s)input(s), output(s) }}

Maybe it means Maybe it means common objects.common objects.

The common lexicon The common lexicon shall includeshall include configuration actions configuration actions in addition to actions required for implementing in addition to actions required for implementing application models.application models.An application model An application model is requiredis required to be implemented in to be implemented in such a way that it can be translated to and from the such a way that it can be translated to and from the common lexicon.common lexicon.

This requires a complete application framework specification.This requires a complete application framework specification.


Common Interoperability System (CIS)Common Interoperability System (CIS)

System 1

GIWF1A

S

System 4

GIWF AS

4

Abstract HES

HES Home Electronic SystemGIWF Generic Interworking Function

System 2

GIWF 2A

S

System 3

GIWF3A

S


TaxonomyTaxonomyA taxonomy implies a hierarchical relationship of terms which are used for A taxonomy implies a hierarchical relationship of terms which are used for classifying items in a particular domain.classifying items in a particular domain.What relationships are common in existing specifications? Everything under the What relationships are common in existing specifications? Everything under the Sun, actually.Sun, actually.

Configuration Process : Configuration Process : Professional, Easy, Automatic.Professional, Easy, Automatic.

Application DomainsApplication DomainsContexts, Areas, Applications (see CEBus CAL)Contexts, Areas, Applications (see CEBus CAL)

Application ObjectsApplication ObjectsGenericGeneric

Node Information, System Information, Device Information, Product Information …Node Information, System Information, Device Information, Product Information …

ManagementManagement Configuration, Service Discovery, ….Configuration, Service Discovery, ….

Specific Objects Specific Objects Temperature Sensor, Actuator, Meter {Electricity, Water, Gas, …}, Applications {Heating, Energy Temperature Sensor, Actuator, Meter {Electricity, Water, Gas, …}, Applications {Heating, Energy

Management, …}Management, …} Service / MethodService / Method

Get, Set, Put, Post, Read, Write, Run, Cancel, End, Start, A_Read_ADC, EventNotify, Get, Set, Put, Post, Read, Write, Run, Cancel, End, Start, A_Read_ADC, EventNotify, InformationReport, ….InformationReport, ….

Data Types Data Types two levels two levelsSemantic units (temperature units, etc.)Semantic units (temperature units, etc.)Encoding datatypes: Boolean, Integer or float (what format? ISO/IEC 748???), Character, Encoding datatypes: Boolean, Integer or float (what format? ISO/IEC 748???), Character, Byte string, …Byte string, …

Interaction ModeInteraction ModeMessage passing, procedure call, asynchronous eventing, shared memory, …Message passing, procedure call, asynchronous eventing, shared memory, …


LexiconLexiconA A lexiconlexicon is a collection of definitions of objects, their is a collection of definitions of objects, their structure and their components: a dictionary of HES structure and their components: a dictionary of HES objects and devices, and possibly of interaction objects and devices, and possibly of interaction primitives. primitives. Should not reinvent the wheel, but difficult to reconcile a Should not reinvent the wheel, but difficult to reconcile a very large body of work.very large body of work.What metadata language to use?What metadata language to use?

XML is a descriptive language; parsers for it are available; XML is a descriptive language; parsers for it are available; Need to check expressiveness of XML Schemas for machine-to-Need to check expressiveness of XML Schemas for machine-to-

machine non-Web based systems.machine non-Web based systems.Done by Ron.Done by Ron.

Normally there are multiple levels and ways of system Normally there are multiple levels and ways of system descriptiondescription


Comparing Existing SpecificationsComparing Existing SpecificationsComparing along the (draft) taxonomy headings defined before.Comparing along the (draft) taxonomy headings defined before.HPnP 1.0, ECHONET 1.0, Konnex 1.0 (EHS 1.3a + EIB 3.0).HPnP 1.0, ECHONET 1.0, Konnex 1.0 (EHS 1.3a + EIB 3.0).Trying to reconcile terminology with the interoperability guidelines:Trying to reconcile terminology with the interoperability guidelines:

Application Service Objects, Contexts, Instance Variable, Object, Class, Application Service Objects, Contexts, Instance Variable, Object, Class, Instance, Identifiers, ….Instance, Identifiers, ….

SC25 WG1 SC25 WG1 N 868 (right number?)N 868 (right number?) defines the HES architecture and defines the HES architecture and terminology at the application layer – assumed still valid.terminology at the application layer – assumed still valid.

Trying to reconcile data types …Trying to reconcile data types … The The bytebyte data type is the least trouble data type is the least trouble but DCTP (or any similar thing but DCTP (or any similar thing

…) will sort it out…) will sort it outTrying to reconcile architecture approaches:Trying to reconcile architecture approaches:

What concept matches the HPnP What concept matches the HPnP subsystemsubsystem? What matches EIB ? What matches EIB A_Read_ADC primitive? A_Read_ADC primitive?

Not tryingNot trying to reconcile “wire format”: to reconcile “wire format”: 1 byte Class Identifier or 2 byte EHS Object Code, engineering units, 1 byte Class Identifier or 2 byte EHS Object Code, engineering units,

etc. ...etc. ...A very large body of workA very large body of work

Good for referencing; very difficult to reconcile, and it gets harder.Good for referencing; very difficult to reconcile, and it gets harder.


Application Interop ModelApplication Interop Model

HGI(IWF-B)

HGI(IWF-A)

Network A Network B

Interoperability Platform (Gateway)

IGIP

Object 1-AObject 2-B

Object 1 Object 2


Taxonomy FrameworkTaxonomy Framework

Home Electronic System

Application Domain

Functional Class

Object Class

Functional Action

PropertyPrimitive Action

Context [CAL]Functional Profile [LonWorks]Application Group [Konnex ?!]? [ECHONET]

Object [group of IVs in CAL]Object (grp. of SNVT in LonWorks]Application Object [Konnex ?!]? [ECHONET]E.g. Get, Set, Read, Write,

Run, …..

Application-context action (higher semantics, possibly composed of several atomic actions on Object properties)


Model/Object

controlmodel

<<transducer>>

actuator

<<transducer>>

sensor

controlmodel

controlmodel

XML DOCUMENT(I/O Binding)

XML-OBJECTMAPPING

DISTRIBUTEDCOMMUNICATION

I/O BINDING

DISTRIBUTEDNAMING /

DISCOVERY

SECURITY/INTEGRITY

XML DOCUMENT(Control Models, Transducer Models)

XML SCHEMA

Models &Objects

Creation,Initialization

I/O Binding / Wiring

Loading, Parsing andValidation

Runtime Service

Action, Event,Data Flow

Loading, Parsing andValidation

Overview of Interoperability ArchitectureOverview of Interoperability Architecture


Logical Graph of a Control ApplicationLogical Graph of a Control Application

NODE02

NODE01

NODE03

CM01

CM02

CM03

CM04CM05

CM06

<<sensor>>

SM02

<<actuator>>

AM01

<<sensor>>

SM01


-XML Schema-Defines the “language” that will be used to describe control applications and their I/O

-XML Document-Implements descriptions of control applications and their I/O, using the appropriate schema

-Control Models-Represented as XML Documents-Primary component used to describe specific control applications, in terms of:

-Control algorithms (e.g., state-transitions, operations, …)-Inputs and Outputs (e.g., sensors and actuators, other control models, other network-accessible I/O paths)

-A control application may be composed of multiple Control Models

-Transducer Models-Represented as XML Documents-Used for describing specific input and output devices (i.e., sensors and actuators), in terms of:

-Input or output data characteristics-Device configuration

Framework TerminologyFramework Terminology


-XML Object Mapping-Unmarshall XML file/stream into in-memory objects -Marshall in-memory objects into XML file/stream-Validate XML Schema and type information during Unmarshalling and Marshalling

when it is required.

-I/O Binding-Binding together the I/O of in-memory objects such as Control Models and Transducer Models-Validate I/O types and other constraints during the binding process (e.g., safety issues)-Management and Error Handling for the life cycle of the bindings

-Distributed Naming and Discovery-Manages naming and discovery for

-Control Models, Transducer Models, other network-accessible I/O paths

-Distributed Communication-Provides inter-object communication-Implemented through adaptation to different Home Networking Technologies (LON, EIB, EchoNet, Konnex, CeBUS, …)

-HAN Gateway Interface (HGI) translations-Residential Gateway Internal Protocol (RGIP)

-Security/Integrity-Architecture Placeholder for security work in WG 1

Logical ServicesLogical Services


XML Schema - Datatypes (primitive and composite)XML Schema - Datatypes (primitive and composite)

DataPoint

AnalogPointDigitalPointLength

MassSIMultiple

OnOff-State

Occupancy SIUnit

UnitMultipleTime

Temperature

ElectricCurrent

SubstanceAmount

LuminousIntensity

Motor-Speed

RelativeHumidity

TranslationalSpeed

AngularSpeed

ElectricVoltage

Frequency

Force

Pressure

Energy

EnergyPower

HeatCapacity

baseTypes.xsd

derivedTypes.xsd

industryTypes.xsd

PhysicalPointLogicPoint

DataVector

DataUncertainty

...

...


XML Schema – Control ModelXML Schema – Control Model

<<complexType>>

controlModel

<<complexType>>

inputs

<<complexType>>

input

<<complexType>>

outputs

<<DataPoint>>

dataPoint

<<complexType>>

QoIRequirement

<<DataPoint>>

dataPoint

<<complexType>>

output

<<complexType>>

codeBase

<<string>>

description

<<enumeration>>

codeType

<<string>>

codeLocation

<<string>>

idlLocation

<<complexType>>

properties

<<simpleType>>

properties

controlModelTypes.xsd

commons.xsd

<<complexType>>

QoI


Project timelineProject timeline

Current draft (SC25 WG1 N1050) is an attempt to show Current draft (SC25 WG1 N1050) is an attempt to show the frameworkthe framework

Adding taxonomy and lexicon components and circulate Adding taxonomy and lexicon components and circulate a second draft by mid Marcha second draft by mid March

Components for further work as placeholdersComponents for further work as placeholders

Comments on framework are welcomed; any offered Comments on framework are welcomed; any offered assistance will be greatly appreciated.assistance will be greatly appreciated.

Note that DCTP is trying to address some / the same Note that DCTP is trying to address some / the same issues.issues.

SC25 WG1 should clarify and agree on the scope of each SC25 WG1 should clarify and agree on the scope of each project work.project work.


Questions / Questions / Comments / Comments / Suggestions /Suggestions /

help ?help ?

hes interoperability

Documents

application models

application domainscontexts

application layers

common objects

common lexicon

system information

device information

transport layer