ISO/IEC 18012-2:2012
(Main)Information technology — Home Electronic System — Guidelines for product interoperability — Part 2: Taxonomy and application interoperability model
Information technology — Home Electronic System — Guidelines for product interoperability — Part 2: Taxonomy and application interoperability model
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 — Partie 2: Taxinomie et modèle d'interopérabilité d'application
General Information
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
T
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
ON
– 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
ON
(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.