HES Interoperability

1. HES Interoperability Ron Ambrosio & Dritan Kaleshi

2. Overview • Problem • Reading Interoperability Guidelines • Issues & Suggestions • Phase II - Taxonomy & Lexicon • Timeline • Discussion SC25WG1/N1058 - Presentation on HES Interoperability

3. So…. • The aim: • Making two products built from different manufacturers connected overpossibly different communication systems tointerwork 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, ….) • 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) • Further abstraction brings higher risk for adoption. SC25WG1/N1058 - Presentation on HES Interoperability

4. 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) • Effectively Application Layer only; management functions within • Requires interoperability to be specified for: • Configuration • Management • Operation • In all possible combination of particular subsystems. • With very comprehensively defined safety requirements. SC25WG1/N1058 - Presentation on HES Interoperability

5. Interop Guidelines: addressing (naming), data representation/encapsulation… • Addressing • 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 • 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 SC25WG1/N1058 - Presentation on HES Interoperability

6. Interop Guidelines  App Models and Lexicon • Lexicon of common actionscovering { 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. SC25WG1/N1058 - Presentation on HES Interoperability

7. Common Interoperability System (CIS) • HES Home Electronic System • GIWF Generic Interworking Function Abstract HES GIWF AS4 GIWF 1AS GIWF 2AS GIWF 3AS System4 System 1 System 2 System 3 SC25WG1/N1058 - Presentation on HES Interoperability

8. 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 : • Professional, Easy, Automatic. • Application Domains • Contexts, Areas, Applications (see CEBus CAL) • Application Objects • Generic • Node Information, System Information, Device Information, Product Information … • Management • Configuration, Service Discovery, …. • Specific Objects • Temperature Sensor, Actuator, Meter {Electricity, Water, Gas, …}, Applications {Heating, Energy Management, …} • Service / Method • Get, Set, Put, Post, Read, Write, Run, Cancel, End, Start, A_Read_ADC, EventNotify, InformationReport, …. • 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 • Message passing, procedure call, asynchronous eventing, shared memory, … SC25WG1/N1058 - Presentation on HES Interoperability

9. 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; • 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 SC25WG1/N1058 - Presentation on HES Interoperability

10. 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, …. • 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 • Trying to reconcile architecture approaches: • 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. ... • A very large body of work • Good for referencing; very difficult to reconcile, and it gets harder. SC25WG1/N1058 - Presentation on HES Interoperability

11. HGI (IWF-A) Application Interop Model Interoperability Platform (Gateway) Object 2 Object 1 IGIP HGI (IWF-B) Object 2-B Object 1-A Network B Network A SC25WG1/N1058 - Presentation on HES Interoperability

12. Home Electronic System Application Domain Functional Class Object Class Functional Action Property Primitive Action Taxonomy Framework 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) SC25WG1/N1058 - Presentation on HES Interoperability

13. Overview of Interoperability Architecture SC25WG1/N1058 - Presentation on HES Interoperability

14. NODE01 CM01 CM02 NODE03 CM06 <<actuator>> <<sensor>> AM01 NODE02 SM02 CM05 CM04 CM03 <<sensor>> SM01 Logical Graph of a Control Application SC25WG1/N1058 - Presentation on HES Interoperability

15. Framework Terminology • 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 SC25WG1/N1058 - Presentation on HES Interoperability

16. Logical Services • 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 SC25WG1/N1058 - Presentation on HES Interoperability

17. XML Schema - Datatypes (primitive and composite) SC25WG1/N1058 - Presentation on HES Interoperability

18. XML Schema – Control Model SC25WG1/N1058 - Presentation on HES Interoperability

19. 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. SC25WG1/N1058 - Presentation on HES Interoperability

20. Questions / Comments / Suggestions /help ? SC25WG1/N1058 - Presentation on HES Interoperability