interoperability update
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Ron Ambrosio2
Agenda
Scope and Definition of Interoperability Approaches to Interoperability Assumptions & Requirements Product-level Interoperability Application-level Interoperability Open Questions
Ron Ambrosio3
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
Ron Ambrosio4
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
Ron Ambrosio5
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
Ron Ambrosio6
Product-level Interoperability
Kaleshi will review example(s) of possible data and protocol translation processes in detail
Ron Ambrosio7
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
Ron Ambrosio8
Application (7)
Network (3)
Data Link (2)
Physical (1)
Presentation (6)
Session (5)
Transport (4)
Application
Network
Data Link
Physical
La ye r M g mt
Sys. Mgmt.
Interop Application
Application
Network
Data Link
Physical
La ye r M g mt
Syst. Mgmt.
Interop Application
Application
Presentation
RGIP
Application
Presentation
RGIP
RGIB
System A connection(CEBus, Konnex, EchoNet, Echelon …)
System B connection(CEBus, Konnex, EchoNet, Echelon …)
IW F
unct
ion
IW F
unct
ion
Interop Residential Gateway
Interoperability specification domain
Manufacturer-provided interworking Function
HomeGate specification
domain
Interoperability Framework
Ron Ambrosio9
IWF-A IWF-B
Network A Network B
Interoperability Domain
Event Bus
Object 1-ALightSwtich
Object 2-BLightLamp
Object 1event/data logical bus
Object 2
Standardized event passing interface for “Interworking functions”
Application-level Interoperability
Ron Ambrosio10
Interoperability Domain
Object 1
Object 2
Application-level Interoperability
<<Event Bus>>
<<Application Object>>
Object A
o1
Ou
tpu
t D
ata
Var
Set
o2 o3 o4
<<Application Object>>
Object B
o1 o2 o3
Object C
<<Application Object>>
i1 i2 i3 i4
12
3
4
A
12
3
B
Object D
<<Application Object>>
i1 i2 i3
Ron Ambrosio11
Open Questions
Completion of lexicon Management (of binding and other processes) Support and proofs of concept
• University of Bristol• IBM Research• Others?
Ron Ambrosio14
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
Ron Ambrosio15
XML Schema: Data Point, Type and Physical Unit
DataPoint
AnalogPointDigitalPoint
Length
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.xsdPhysicalPointLogicalPoint
DataVector
DataUncertainty
...
...
CustomerSat
$/BTU
Ron Ambrosio16
<<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
XML Schema: Control Model Object example
Ron Ambrosio17
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
Models.xml
actuatormodel
sensormodel
controlmodel
BindingMap.xml
XML-ObjectMappingService
EventBus Service
IO BindingService
Naming Service
RemoteComm Service
NetMap.xml
XSD Schema
3.1 Loading, Parsing and Validation
2.1 Register
2. Create
3.1 Register OptVS as Topics
3.3 Subscribe IptVS with OptVS Topics
3. query / iterationmodel objects
3.2 Setup
Models.xmlModels.xml
Node.properties
Transport Adapters
RemoteService Interfaces
Event/Msg Interfaces
Ron Ambrosio18
Runtime control model object
4. Vildate Trigger Conditionfor AlgorithmEvent()
0. queueInputEvent()
<<Control Model>>
1. queueInputEvent()via Callback
Input Data/Event Queue
Appl. or DriverLogic
CommonRuntime
i1
i2
i3
i4
o1
o2
Event Bus Agent
3. unpackage data() / update()
4. Validate Trigger Rules
2. de-queueInputEvent()
5.2 updatevariables
7. read() / package data()
8. pub()
6. Validate DataPublish Rules
workThreadCallback
Input DescriptionTable
Output DescriptionTable
Inp
ut
Dat
aVar
Set
Ou
tpu
t D
ataV
arS
et
DataSubscribeMap DataPublishMap
InputDataNameMap
5. execute / callback
Event Correlation
Event Bus
9. publish Event/Data to Event bus
0. Data/Event from Event bus