interoperability update

19
ISO/IEC SC 25 WG 1 Ron Ambrosio http://w3.ibm.com/ibm/presentations Interoperability Update Ron Ambrosio Dritan Kaleshi

Upload: chandra-vaikunth

Post on 30-Dec-2015

95 views

Category:

Documents


0 download

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 Presentation

TRANSCRIPT

ISO/IEC SC 25 WG 1

Ron Ambrosio

Interoperability Update

Ron Ambrosio

Dritan Kaleshi

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?

ISO/IEC SC 25 WG 1

Ron Ambrosio

Backup

ISO/IEC SC 25 WG 1

Ron Ambrosio

Interoperability Design

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

Ron Ambrosio19

Mapping to a distributed environmentOne example could be a distributed gateway

Gateway device A

Gateway device B

Gateway device C

Interoperability Domain