HES Interoperability Ron Ambrosio & Dritan Kaleshi

Kaleshi, Ambrosio 2 19/02/2003SC25WG1/N Presentation on HES Interoperability Overview Problem Reading Interoperability Guidelines Issues & Suggestions Phase II - Taxonomy & Lexicon TimelineDiscussion

Kaleshi, Ambrosio 3 19/02/2003SC25WG1/N Presentation on HES Interoperability So…. The aim: Making two products built from different manufacturers connected over possibly different communication systems to interwork together safely, correctly, and securely. Making two products built from different manufacturers connected over possibly different communication systems to interwork together safely, correctly, and securely. and the problem: Too many systems already in advanced stages of standardisation and/or industry adoption (CAL/CEBus, ECHONET, Konnex, LonWorks, ….) Too many systems already in advanced stages of standardisation and/or industry adoption (CAL/CEBus, ECHONET, Konnex, LonWorks, ….) Models are very control oriented; furthermore application models emphasise syntax at very low level. Models are very control oriented; furthermore application models emphasise syntax at very low level. Unifying them requires further abstraction in a model framework (which has been done prior to interop project) Unifying them requires further abstraction in a model framework (which has been done prior to interop project) Further abstraction brings higher risk for adoption.

Kaleshi, Ambrosio 4 19/02/2003SC25WG1/N Presentation on HES Interoperability Reading the Interoperability Guidelines Quite complete set of requirements In particular the document (SC25 N748 and the FDIS version) : Confines the search for solution to Presentation and Application Layers only (OSI RM Layer 6 and 7) Confines the search for solution to Presentation and Application Layers only (OSI RM Layer 6 and 7) Effectively Application Layer only; management functions within Requires interoperability to be specified for: Requires interoperability to be specified for:ConfigurationManagementOperation In all possible combination of particular subsystems. With very comprehensively defined safety requirements. With very comprehensively defined safety requirements.

Kaleshi, Ambrosio 5 19/02/2003SC25WG1/N Presentation on HES Interoperability Interop Guidelines: addressing (naming), data representation/encapsulation… Addressing Application layer addressing should be independent from the underlying transport mechanism. Application layer addressing should be independent from the underlying transport mechanism. Effectively this means that object namespace should be complete and independent of the transport layer. Fits the OSI xSAP model nicely. Information 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 datatypes; it does not matter how the object process represents it internally and how this is transported at protocol/wire level# E.g. Temperature::= float  DCTP float  LonWorks IWF:: LonFloat

Kaleshi, Ambrosio 6 19/02/2003SC25WG1/N Presentation on HES Interoperability Interop Guidelines  App Models and Lexicon Lexicon of common actions covering { name, action, input(s), output(s) } Maybe it means common objects. The common lexicon shall include configuration actions in addition to actions required for implementing application models. An application model is required to be implemented in such a way that it can be translated to and from the common lexicon. This requires a complete application framework specification. This requires a complete application framework specification.

Kaleshi, Ambrosio 7 19/02/2003SC25WG1/N Presentation on HES Interoperability Common Interoperability System (CIS) System 1 GIWF 1  AS System 4 GIWF AS  4 Abstract HES HESHome Electronic System GIWFGeneric Interworking Function System 2 GIWF 2  AS System 3 GIWF 3  AS

Kaleshi, Ambrosio 8 19/02/2003SC25WG1/N Presentation on HES Interoperability Taxonomy A taxonomy implies a hierarchical relationship of terms which are used for classifying items in a particular domain. What relationships are common in existing specifications? Everything under the Sun, actually. Configuration Process : Configuration Process : Professional, Easy, Automatic. Application Domains Application Domains Contexts, Areas, Applications (see CEBus CAL) Application Objects Application ObjectsGeneric Node Information, System Information, Device Information, Product Information … Node Information, System Information, Device Information, Product Information …Management Configuration, Service Discovery, …. Configuration, Service Discovery, …. Specific Objects Temperature Sensor, Actuator, Meter {Electricity, Water, Gas, …}, Applications {Heating, Energy Management, …} Temperature Sensor, Actuator, Meter {Electricity, Water, Gas, …}, Applications {Heating, Energy Management, …} Service / Method Service / Method Get, Set, Put, Post, Read, Write, Run, Cancel, End, Start, A_Read_ADC, EventNotify, InformationReport, …. Data Types  two levels Data Types  two levels Semantic units (temperature units, etc.) Encoding datatypes: Boolean, Integer or float (what format? ISO/IEC 748???), Character, Byte string, … Interaction Mode Interaction Mode Message passing, procedure call, asynchronous eventing, shared memory, …

Kaleshi, Ambrosio 9 19/02/2003SC25WG1/N Presentation on HES Interoperability Lexicon A lexicon is a collection of definitions of objects, their structure and their components: a dictionary of HES objects and devices, and possibly of interaction primitives. Should not reinvent the wheel, but difficult to reconcile a very large body of work. 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- machine non-Web based systems. Need to check expressiveness of XML Schemas for machine-to- machine non-Web based systems. Done by Ron. Normally there are multiple levels and ways of system description Normally there are multiple levels and ways of system description

Kaleshi, Ambrosio 10 19/02/2003SC25WG1/N Presentation on HES Interoperability Comparing Existing Specifications Comparing along the (draft) taxonomy headings defined before. HPnP 1.0, ECHONET 1.0, Konnex 1.0 (EHS 1.3a + EIB 3.0). Trying to reconcile terminology with the interoperability guidelines: Application Service Objects, Contexts, Instance Variable, Object, Class, Instance, Identifiers, …. Application Service Objects, Contexts, Instance Variable, Object, Class, Instance, Identifiers, …. SC25 WG1 N 868 (right number?) defines the HES architecture and terminology at the application layer – assumed still valid. SC25 WG1 N 868 (right number?) defines the HES architecture and terminology at the application layer – assumed still valid. Trying to reconcile data types … The byte data type is the least trouble but DCTP (or any similar thing …) will sort it out The byte data type is the least trouble but DCTP (or any similar thing …) will sort it out Trying to reconcile architecture approaches: What concept matches the HPnP subsystem? What matches EIB A_Read_ADC primitive? What concept matches the HPnP subsystem? What matches EIB A_Read_ADC primitive? Not trying to reconcile “wire format”: 1 byte Class Identifier or 2 byte EHS Object Code, engineering units, etc byte Class Identifier or 2 byte EHS Object Code, engineering units, etc.... A 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.

Kaleshi, Ambrosio 11 19/02/2003SC25WG1/N Presentation on HES Interoperability Application Interop Model HGI (IWF-B) HGI (IWF-A) Network A Network B Interoperability Platform (Gateway) IGIP Object 1-A Object 2-B Object 1 Object 2

Kaleshi, Ambrosio 12 19/02/2003SC25WG1/N Presentation on HES Interoperability Taxonomy Framework Home Electronic System Application Domain Functional Class Object Class Functional Action Property Primitive 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)

Kaleshi, Ambrosio 13 19/02/2003SC25WG1/N Presentation on HES Interoperability Overview of Interoperability Architecture

Kaleshi, Ambrosio 14 19/02/2003SC25WG1/N Presentation on HES Interoperability Logical Graph of a Control Application

Kaleshi, Ambrosio 15 19/02/2003SC25WG1/N Presentation on HES Interoperability -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 Terminology

Kaleshi, Ambrosio 16 19/02/2003SC25WG1/N Presentation on HES Interoperability -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 Services

Kaleshi, Ambrosio 17 19/02/2003SC25WG1/N Presentation on HES Interoperability XML Schema - Datatypes (primitive and composite)

Kaleshi, Ambrosio 18 19/02/2003SC25WG1/N Presentation on HES Interoperability XML Schema – Control Model

Kaleshi, Ambrosio 19 19/02/2003SC25WG1/N Presentation on HES Interoperability Project timeline Current draft (SC25 WG1 N1050) is an attempt to show the framework Adding taxonomy and lexicon components and circulate a second draft by mid March Components for further work as placeholders Comments on framework are welcomed; any offered assistance will be greatly appreciated. Note that DCTP is trying to address some / the same issues. SC25 WG1 should clarify and agree on the scope of each project work. SC25 WG1 should clarify and agree on the scope of each project work.

Kaleshi, Ambrosio 20 19/02/2003SC25WG1/N Presentation on HES Interoperability Questions / Comments / Suggestions / help ?