1 / 19

Interoperability Update

Interoperability Update. Ron Ambrosio Dritan Kaleshi. Agenda. Scope and Definition of Interoperability Approaches to Interoperability Assumptions & Requirements Product-level Interoperability Application-level Interoperability Open Questions. Scope and Definition of Interoperability.

chandra-vaikunth
Download Presentation

Interoperability Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interoperability Update Ron Ambrosio Dritan Kaleshi

  2. Agenda • Scope and Definition of Interoperability • Approaches to Interoperability • Assumptions & Requirements • Product-level Interoperability • Application-level Interoperability • Open Questions

  3. Scope and Definition of Interoperability • Addresses the requirements of two communities: • Product developers • System integrators • Product-level interoperability • Focuses on syntactic issues – data and protocol interfacing to specific products in a multi-system installation • Application-level interoperability • Focuses on semantic issues – describing the application interactions between products in a multi-system installation

  4. Approaches to Interoperability • Adopt a single system as the agreed-upon universal standard • Minimizes ability for product differentiation between manufacturers • May not adequately address specific regional differences/requirements OR • Develop system-to-system translations between all target systems • Could easily degenerate into an n2 translation situation • Dependence on protocol translation can make the interoperability framework “brittle” – very sensitive to minor changes in underlying systems OR • Define a meta-framework to facilitate multi-system solutions without requiring specific system-to-system protocol translations • Address unambiguous data mapping/translation • Adopt an approach that is independent of the underlying protocols

  5. Assumptions & Requirements • Goal is to support multi-system installations • Must address product-level interoperability between specific products/systems and the Interoperability Framework • Requirement for the interoperability framework to establish unambiguous data translation/mapping • Must address application-level interoperability so that multi-system applications can be described • Example: support an installation in a home that contains products from a mixture of systems such as KNX and IGRS, or EchoNet and LonTalk, etc. • Requirement for the interoperability framework to be protocol-independent

  6. Product-level Interoperability • Kaleshi will review example(s) of possible data and protocol translation processes in detail

  7. Application-level Interoperability • Our basic approach is to describe the interaction between products in a multi-system installation • Must capture enough information to enable an implementation of the interoperability framework to automatically determine which product parameters need to be transported across the interoperability event bus as a single unit – i.e., to assemble the event message payloads dynamically • This effectively breaks the tight association between individual product APIs and their associated protocol definitions for various product functions

  8. Application (7) Application Application Presentation (6) Presentation Presentation Session (5) RGIP RGIP Transport (4) Network (3) Data Link (2) Physical (1) Application Application Network Network Data Link Data Link Physical Physical Interoperability specification domain Interoperability Framework Interop Application Syst. Mgmt. Sys. Mgmt. Interop Application RGIB IW Function IW Function Layer Mgmt Layer Mgmt Interop Residential Gateway System B connection (CEBus, Konnex, EchoNet, Echelon …) System A connection (CEBus, Konnex, EchoNet, Echelon …) HomeGate specification domain Manufacturer-provided interworking Function

  9. Standardized event passing interface for “Interworking functions” Application-level Interoperability Interoperability Domain Event Bus Object 2 Object 1 event/data logical bus IWF-A IWF-B Object 2-B LightLamp Object 1-A LightSwtich Network B Network A

  10. Application-level Interoperability Interoperability Domain Object 1 Object 2

  11. Open Questions • Completion of lexicon • Management (of binding and other processes) • Support and proofs of concept • University of Bristol • IBM Research • Others?

  12. Backup

  13. Interoperability Design

  14. Software representations of abstract control system objects (control loops, sensors, actuators) Provide a necessary level of homogeneity across disparate control environments Allow identification and capture of meta-information (such as latency requirements, data freshness requirements, etc.) Establish data-typing framework <?xml version="1.0" encoding="UTF-8"?> <controlModel id="cm01" name="cm01" xmlns="http://www.ibm.com/idacs/xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/idacs/xml controlModel.xsd"> <inputs> <input> <dataPoint id="i1" name="i1" xsi:type="Boolean"/> </input> <input> <dataPoint id="i2" name="i2" xsi:type="Integer"/> </input> </inputs> <outputs> <output> <dataPoint id="o1" name="o1name" xsi:type="String"/> </output> </outputs> <properties> <property name="cm01_prt1" value="value of prt1"/> <property name="cm01_prt2" value="vlaue of prt2"/> </properties> <codeBase> <codeType>JAVA</codeType> <codeLocation>com.ibm.idacs.algorithm.NullControlAlgorithm</codeLocation> <idlLocation>PIDTemperatureControl.wsdl</idlLocation> </codeBase> </controlModel> Object Schemas

  15. baseTypes . xsd DataPoint LogicalPoint PhysicalPoint industryTypes . xsd $ / BTU DigitalPoint AnalogPoint CustomerSat Length SIMultiple Mass OnOff - State UnitMultiple Time SIUnit Occupancy ElectricCurrent DataVector Motor - Speed Temperature DataUncertainty RelativeHumidity SubstanceAmount ... LuminousIntensity derivedTypes . xsd TranslationalSpeed Energy AngularSpeed EnergyPower Frequency HeatCapacity Force ... Pressure ElectricVoltage XML Schema: Data Point, Type and Physical Unit

  16. XML Schema: Control Model Object example

  17. Programming Framework and Runtime • Establishes the conceptual framework for instantiating and binding together systems of control objects • Performs type-consistency and other types of validation on binding operations • Manages the multinode distributed nature of the system

  18. Runtime control model object

  19. Gateway device A Gateway device B Gateway device C Mapping to a distributed environmentOne example could be a distributed gateway Interoperability Domain

More Related