Information technology -- Home Electronic System -- Guidelines for product interoperability

ISO/IEC 18012-2:2012(E) specifies a taxonomy and application interoperability model for the interoperability of products in the area of home systems. It also specifies an interoperability framework to allow products from multiple manufacturers to work together in order to provide a specific application. It describes a application process that exists above the OSI reference model (ISO/IEC 7498-1) stack, with sufficient detail needed to establish interoperable applications in this domain. It is applicable to: single implementation home electronic system networks, connected devices and applications, multiple implementation home electronic system networks, connected devices and applications, automatically configured devices, manually configured devices and manually configured groups/clusters of devices.

Technologies de l'information -- Systèmes électroniques domestiques (HES) -- Lignes directrices pour l'interopérabilité de produits

General Information

Status
Published
Publication Date
12-Jul-2012
Current Stage
6060 - International Standard published
Start Date
06-Jul-2012
Completion Date
13-Jul-2012
Ref Project

Buy Standard

Standard
ISO/IEC 18012-2:2012 - Information technology -- Home Electronic System -- Guidelines for product interoperability
English language
50 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

ISO/IEC 18012-2
Edition 1.0 2012-07
INTERNATIONAL
STANDARD
colour
inside
Information technology – Home electronic system (HES) – Guidelines for
product interoperability –
Part 2: Taxonomy and application interoperability model
ISO/IEC 18012-2:2012(E)
---------------------- Page: 1 ----------------------
THIS PUBLICATION IS COPYRIGHT PROTECTED
Copyright © 2012 ISO/IEC, Geneva, Switzerland

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form

or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from

either IEC or IEC's member National Committee in the country of the requester.

If you have any questions about ISO/IEC copyright or have an enquiry about obtaining additional rights to this

publication, please contact the address below or your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC

The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes

International Standards for all electrical, electronic and related technologies.
About IEC publications

The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the

latest edition, a corrigenda or an amendment might have been published.
Useful links:

IEC publications search - www.iec.ch/searchpub Electropedia - www.electropedia.org

The advanced search enables you to find IEC publications The world's leading online dictionary of electronic and

by a variety of criteria (reference number, text, technical electrical terms containing more than 30 000 terms and

committee,…). definitions in English and French, with equivalent terms in

It also gives information on projects, replaced and additional languages. Also known as the International

withdrawn publications. Electrotechnical Vocabulary (IEV) on-line.

IEC Just Published - webstore.iec.ch/justpublished Customer Service Centre - webstore.iec.ch/csc

Stay up to date on all new IEC publications. Just Published If you wish to give us your feedback on this publication

details all new publications released. Available on-line and or need further assistance, please contact the

also once a month by email. Customer Service Centre: csc@iec.ch.
---------------------- Page: 2 ----------------------
ISO/IEC 18012-2
Edition 1.0 2012-07
INTERNATIONAL
STANDARD
colour
inside
Information technology – Home electronic system (HES) – Guidelines for
product interoperability –
Part 2: Taxonomy and application interoperability model
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
ICS 35.200 ISBN 978-2-83220-192-3

Warning! Make sure that you obtained this publication from an authorized distributor.

---------------------- Page: 3 ----------------------
– 2 – 18012-2  ISO/IEC:2012(E)
CONTENTS

FOREWORD ........................................................................................................................... 4

INTRODUCTION ..................................................................................................................... 6

1 Scope ............................................................................................................................. 11

2 Normative references ..................................................................................................... 11

3 Terms, definitions, abbreviations and conventions .......................................................... 12

3.1 Terms and definitions ............................................................................................ 12

3.2 Abbreviations ........................................................................................................ 15

3.3 Conventions .......................................................................................................... 15

4 Conformance requirements ............................................................................................. 15

5 Application interoperability model ................................................................................... 16

5.1 Overview ............................................................................................................... 16

5.2 Application objects and interworking functions ....................................................... 16

6 Interaction model ............................................................................................................ 19

6.1 Overview ............................................................................................................... 19

6.2 Application objects ................................................................................................ 19

6.3 Binding map .......................................................................................................... 20

6.4 Events ................................................................................................................... 21

6.5 Event bus .............................................................................................................. 21

7 Home electronic system application interoperability taxonomy ........................................ 22

7.1 Classification ......................................................................................................... 22

7.2 Application domain ................................................................................................ 24

7.2.1 Definition ................................................................................................... 24

7.2.2 Application domain list ............................................................................... 24

7.3 Functional object ................................................................................................... 25

7.3.1 Definition ................................................................................................... 25

7.3.2 Functional object structure ........................................................................ 25

7.3.3 Functional action ....................................................................................... 25

7.3.4 Functional object list .................................................................................. 25

7.4 Application object .................................................................................................. 25

7.4.1 Definition ................................................................................................... 25

7.4.2 Application object structure ....................................................................... 26

7.4.3 Property .................................................................................................... 26

7.4.4 Property data type primitives ..................................................................... 26

7.4.5 Property unit type primitives ...................................................................... 27

7.4.6 Property action primitives .......................................................................... 27

7.4.7 Object types .............................................................................................. 27

8 Object schema ............................................................................................................... 27

8.1 Descriptive methodology ....................................................................................... 27

8.2 Overview ............................................................................................................... 28

8.3 Base objects ......................................................................................................... 28

8.3.1 General ..................................................................................................... 28

8.3.2 Control objects .......................................................................................... 29

8.3.3 Sensor objects........................................................................................... 30

8.3.4 Actuator objects ........................................................................................ 30

8.4 Data type primitives ............................................................................................... 30

---------------------- Page: 4 ----------------------
18012-2  ISO/IEC:2012(E) – 3 –

9 Overview of application object binding map schema ....................................................... 31

Annex A (informative) Example of a lighting application interoperability specification ........... 32

Annex B (normative) Base object schema definitions ........................................................... 42

Annex C (informative) Base object schema extension examples .......................................... 53

Annex D (informative) Notes on interoperability ................................................................... 57

Bibliography .......................................................................................................................... 59

Figure 1 – Lighting application in (a) a shared memory system, (b) a

command/response system and (c) an interoperating system .................................................. 8

Figure 2 – Application interoperability model ......................................................................... 18

Figure 3 – Binding map example ........................................................................................... 20

Figure 4 – Event bus example ............................................................................................... 22

Figure 5 – Interoperable system taxonomy ............................................................................ 23

Figure 6 – Object schema structure ...................................................................................... 29

Figure A.1 – Lighting application ........................................................................................... 32

Figure A.2 – LightSwitch object ............................................................................................. 33

Figure A.3 – LightLamp object .............................................................................................. 34

Figure A.4 – System A lighting example diagram .................................................................. 35

Figure A.5 – Functional block diagram for FB switching sensor basic .................................... 35

Figure A.6 – Functional block diagram for FB light switching actuator basic .......................... 36

Figure A.7 – System B UPnP LightLamp device .................................................................... 37

Figure A.8 – UPnP InterWorking function system .................................................................. 38

Figure A.9 – Functional mapping of SwitchPower service to the LightLamp ........................... 39

Figure A.10 – System B function mapping table .................................................................... 40

Figure A.11 – Interoperability domain (ID) work flow ............................................................. 41

Table 1 – Application domain list .......................................................................................... 24

Table 2 – Property structure ................................................................................................. 26

Table 3 – Property unit type primitives .................................................................................. 27

Table D.1 – Terminology mapping table ................................................................................ 57

---------------------- Page: 5 ----------------------
– 4 – 18012-2  ISO/IEC:2012(E)
INFORMATION TECHNOLOGY –
HOME ELECTRONIC SYSTEM (HES) –
GUIDELINES FOR PRODUCT INTEROPERABILITY –
Part 2: Taxonomy and application interoperability model
FOREWORD

1) ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) form the

specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in

the development of International Standards. Their preparation is entrusted to technical committees; any ISO and

IEC member body interested in the subject dealt with may participate in this preparatory work. International

governmental and non-governmental organizations liaising with ISO and IEC also participate in this preparation.

2) In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.

Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.

Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.

3) The formal decisions or agreements of IEC and ISO on technical matters express, as nearly as possible, an

international consensus of opinion on the relevant subjects since each technical committee has representation

from all interested IEC and ISO member bodies.

4) IEC, ISO and ISO/IEC publications have the form of recommendations for international use and are accepted

by IEC and ISO member bodies in that sense. While all reasonable efforts are made to ensure that the

technical content of IEC, ISO and ISO/IEC publications is accurate, IEC or ISO cannot be held responsible for

the way in which they are used or for any misinterpretation by any end user.

5) In order to promote international uniformity, IEC and ISO member bodies undertake to apply IEC, ISO and

ISO/IEC publications transparently to the maximum extent possible in their national and regional publications.

Any divergence between any ISO/IEC publication and the corresponding national or regional publication

should be clearly indicated in the latter.

6) ISO and IEC provide no marking procedure to indicate their approval and cannot be rendered responsible for

any equipment declared to be in conformity with an ISO/IEC publication.

7) All users should ensure that they have the latest edition of this publication.

8) No liability shall attach to IEC or ISO or its directors, employees, servants or agents including individual experts

and members of their technical committees and IEC or ISO member bodies for any personal injury, property

damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees)

and expenses arising out of the publication of, use of, or reliance upon, this ISO/IEC publication or any other IEC,

ISO or ISO/IEC publications.

9) Attention is drawn to the normative references cited in this publication. Use of the referenced publications is

indispensable for the correct application of this publication.

10) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of

patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

International Standard ISO/IEC 18012-2 was prepared by subcommittee 25: Interconnection

of information technology equipment, of ISO/IEC joint technical committee 1: Information

technology.

The list of all currently available parts of the ISO/IEC 18012 series, under the general title

Home electronic system (HES) – Guidelines for product interoperability, can be found on the

IEC web site.

This International Standard has been approved by vote of the member bodies, and the voting

results may be obtained from the address given on the second title page.
---------------------- Page: 6 ----------------------
18012-2  ISO/IEC:2012(E) – 5 –

This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates

that it contains colours which are considered to be useful for the correct

understanding of its contents. Users should therefore print this document using a

colour printer.
---------------------- Page: 7 ----------------------
– 6 – 18012-2  ISO/IEC:2012(E)
INTRODUCTION

The widespread development of many national and regional home automation specifications,

some standard and some proprietary, necessitates a mechanism for interoperability.

Interoperability ensures that products from multiple manufacturers (potentially implemented

using different automation systems) can interwork. It is desirable that devices needing to

interwork do so seamlessly to provide users with a variety of integrated applications without

modification of their protocols used within their specific system cluster. Examples of such

applications include lighting control, environmental control, energy management, audio/video

equipment control, and home security.

There are two fundamental methods to enable interoperability among applications developed

for different communications protocols that use different application layers. These application

layers may include different syntax and semantics for command, control, eventing and data.

• Method 1: Multiple gateways

A communications gateway is intended to interconnect two different communications

protocols. Therefore, to provide interoperability among three applications (A, B and C) that

each use different protocols, gateways might be specified for:
a) A ↔ B
b) A ↔ C
c) B ↔ C
• Method 2: A generic gateway
Each application developer adds an interworking function (IWF) specified in this

International Standard so that the application can communicate with other applications,

regardless of the underlying communications protocol.
d) A ↔ IWF
e) B ↔ IWF
f) C ↔ IWF

Interoperability is achieved via the IWF. For example, for application A and C to communicate:

A ↔ IWF ↔ C. The IWF is a software-based generic gateway. This is a much less complex

solution than Method 1. Application developers seeking interoperability using Method 1

develop translators (gateways) to each target applications. Developers using Method 2

implement only one IWF translator.

This International Standard provides a common classification and descriptive mechanism so

that there is a common way of describing applications in any individual system, and an

unambiguous mapping to key implementation items (e.g., data type primitives) to allow for

transparent interoperability. Application-level interoperability cannot be achieved without

being able to describe applications in a common form. The term “product interoperability”

should be considered synonymous with application-level interoperability, since products are

developed to implement and/or participate in (distributed) applications. The value of products

to the end user derives from the applications which they support or provide.

The taxonomy specified here is based on application domain classification criteria for

applications in home systems, as well as a lexicon of objects, events, properties, and

primitive actions to effect or otherwise propagate change in the objects (their properties). This

International Standard enables the specification and implementation of distributed application

functions and services within the context of home electronic systems.

Work on this International Standard began with an in-depth review of the following existing

systems, to understand the various application, interaction, and implementation models in

use: ISO/IEC 14543-3-x [network based control of HES Class 1), ISO/IEC 14543-4-x [network

enhanced control devices of HES Class 1], ISO/IEC 29341 [UPnP Device Architecture

UPnP)], ANSI/CEA-600 and ANSI/CEA-709 (also known as EN-14908). From that analysis,

key similarities were identified among the various approaches and implementations. Those

---------------------- Page: 8 ----------------------
18012-2  ISO/IEC:2012(E) – 7 –

similarities are primarily in the high-level application functions that are being implemented,

with differences appearing in the details of how the functions are represented. In short, there

is a great deal of semantic similarity among various automation system application functions,

but significant differences at the syntactic level.

That observation is the premise for the approach used in this International Standard. In order

to facilitate interoperability, it is necessary to define an application interoperability model with

the following characteristics.

• It allows a rich set of application functions, properties and interactions amongst distributed

components contributing to the application to be clearly described in a common format.

• It incorporates a simple but flexible interaction model abstraction to represent all

interaction models adopted by various system implementations (command/response,
shared variable, message-oriented, etc.).

• It establishes the minimal set of common data type primitives to support unambiguous

mapping of logical application data descriptions into implementation-specific binary

representations within the interoperability domain.

Interoperability in distributed application systems is defined as the ability of two or more

distributed components to communicate and to co-operate in predictable ways despite

differences in implementation language, execution environment, or model abstractions. Three

main levels of interoperability between components in a distributed application can be

distinguished, as follows:

• protocol level, where the order of message exchanges and the constraints placed on

either participant in the exchange (e.g. synchronous or sequential communications), are

defined, alongside the resulting behaviour and possible blocking conditions.

Interoperability at the protocol level provides the foundation to support the syntactic layer;

• syntactic level, where the names, interfaces and operation of the components are defined.

Interoperation at this level is a necessary condition to support interoperability at the

semanctic level;

• semantic level, where the meaning of the possible interactions between the components in

the distributed application system is defined, in the sense of a defined/desired effect or

output being generated.

Assuming that interoperability exists at protocol and syntactic levels, semantic level

interoperability clashes between two application objects belonging to two different

specifications but installed in the same premises and expected to co-operate are caused by

differences in the HES-lexicon (conceptual schemas) that describe the components. Simply

put, they may use different units for physical variable values and different names for objects,

their properties and their functions, albeit they may be addressing the same application.

Therefore, a mistranslation may occur between the two systems because of incomplete

shared information. The possible clashes can be classified into two main groups, described

below.

• Lossless clashes are those that can be resolved with no loss of information. Some

examples in this category include component naming clashes, where the same

component/information is represented by different labels; structural clashes, where

information elements are grouped in different ways in different systems and unit clashes,

where some scalar value (e.g. distance or temperature) is represented with different units

of measure.

• Lossy clashes, which include interoperability clashes for which any transformation

available, in either direction, causes loss in the information being communicated between

the two application objects. These clashes are associated with differing levels of

granularity, refinement or precision of the representation of the information. Note that a

lossy translation between the two application objects may be an acceptable solution,

provided that it achieves the desired application behaviour and does not affect the

functional safety of the application or the system as a whole. One example of a lossy

clash would be a light controller with a dimmer function. This controls a light actuator

---------------------- Page: 9 ----------------------
MA : Sw L g
COM ND itch i ht#3
– 8 – 18012-2  ISO/IEC:2012(E)

(lamp); the light actuator understands only three levels of dimming, whilst the light

controller supports up to 8 different levels. Any interoperability mapping between these

two devices would require the mapping of the three levels recognised by the light

installation to three out of the eight levels of dimming supported by the light controller.

Shared memory Command/response
nvLightSwitch #2 nvLightSwitch #2 LightSwitch #2 LightController #3
Switch Light Switch Light
COMMAND: Switch Light #3
(b)
(a)
Interoperability Domain
Interoperability Event Bus
Interop LightSw itch Interop LampControl
SIWFwitch IWF
Manufacturer Supplied C ode Manufacturer Supplied Code
Shared memory
Command/response
nvLightSwitch #2 LightController #3
Switch Light
(c)
Figure 1 – Lighting application in (a) a shared memory system,
(b) a command/response system and (c) an interoperating system
For example, one automation system might implement a shared variable space for

communication between devices. In a simple lighting control example shown in Figure 1 (a), a

user might turn a wall switch on, causing a shared variable in the switch device connected to

the home system network to change from “0” (off) to “1” (on). A lighting controller component

in the system might be subscribed to that shared variable, causing the automation system to

notify the lighting controller of the change in the variable’s value (state). The controller could

then take actions as defined by the configuration and programming of the lighting control

application (in this case, switch the connected light on or off as requested).

In a complementary example, based on a command and control-based automation system,

the wall switch might cause an “ON” command to be sent across the network in a message to

the lighting controller component, which would then react appropriately (as per the description

above).
---------------------- Page: 10 ----------------------
18012-2  ISO/IEC:2012(E) – 9 –

In both examples, the behaviour of the lighting control application is the same, but the method

used to implement it was quite different. This is an example of two systems having the same

semantics (meaning and behaviour), but different syntax (implementation and codification or

form).

This International Standard is based on the separation of the concept of action primitives from

their actual implementation. An action primitive is a basic application action or device function

that cannot be executed in part; it is either executed completely or not at all. A distributed

application, or home electronic system aggregate function, is then thought as being provided

through the execution of a sequence of such action primitives step by step, across the

system. An example of an action primitive will be “Set temperature to 21 °C in Thermostat#21”

(Thermostat#21 is the name of an object.). To clarify the separation between action primitives

and their implementation, let consider an example HES System-A, where devices/objects use

/ functions to implement local or remote reading and writing of variable values.

This will not constitute “action primitives” in the context of this International Standard, but

rather a programming mechanism used to invoke the application action primitives. These

application actions are caused by -ing (setting) the same variable to different values,

which means that it is the variable and the value that it contains at a given time that define the

application action, not specifically how the value is set (which, in this example, is through the

use of a “PUT” message in System-A. This is captured later on in this International Standard

by the introduction of eventing; objects (devices) notify each other with the values of their

parameters, and each device (object) makes its decisions and takes actions (which

contribute/constitute application actions) based on these values. During this processing each

device may change these values; changes should be notified to all the interested parties.

These same actions can be invoked in System-B by performing a (different) remote or local

function call (i.e. not using , but some form of a remote procedure call interaction). In

this case it is possible for both systems to implement the same lexicon, and have the same

application actions, but maintain (i.e. do not need to change) their own interaction mechanism

and the corresponding protocols and syntax.

Typically, HES use different interaction modes, such as (distributed) shared memory/variable

mode, command/response mode, remote procedure call mode, publish/subscribe mode

(eventing) and variations of these. Using each of these gives the resulting home system

certain characteristics, such as the ability to acknowledge correct execution of a remote

operation (such as update of a state variable value, or the activation of a particular control).

How to support a different set of operations using a common interaction model is well known

in distributed control system design and implementation. However, it is beyond the scope of

this International Standard to provide a detailed proof of the equivalence of such methods

when translating between different interaction models, as sh
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.