ISO/IEC JTC 1/SC 25/WG 1
N 1360
Date: 2008-12-17
ISO/IEC JTC 1/SC 25
INTERCONNECTION OF INFORMATION TECHNOLOGY EQUIPMENT
Secretariat: Germany (DIN)
DOC TYPE:
Final Committee Draft (FCD)
TITLE:
ISO/IEC 18012-2 Information technology —Home
electronic system (HES) — Guidelines for product
interoperability — Part 2: Taxonomy and Lexicon
SOURCE:
SC 25/WG 1 N 1360
PROJECT:
25.01.07.01-02
STATUS:
The NWIP had been distributed with JTC 1 N 5520.
It has been approved as recorded in JTC 1 N 5652
This document is being provided as a Final Committee
Draft (FCD) candidate.
ACTION ID:
Review and ballot
DUE DATE:
2009-04-20
REQUESTED:
ACTION
Review and ballot
MEDIUM:
Def
DISTRIBUTION: ITTF, JTC 1 Secretariat
P-, L-, O-Members of SC 25
No of Pages:
54 (including cover)
Secretary - ISO/IEC JTC 1 / SC 25 - Dr.-Ing. Walter P. von Pattay
Member of ZVEI FV 7 & FV 8, Gotthelfstr. 34, D-81677 München, Germany
Tel.: +49 89-923 967 57, Tfx.: +49 89-923 967 59
EM: [email protected]
Ftp address: "ftp.iec.ch", login: "sc25mem", password: see SC 25 N 449
Home page: ”http://www.iec.ch/sc25”
1
ISO/IEC
2
18012-2
3
4
Information technology –
Home electronic system (HES)
5
6
7
Guidelines for product interoperability –
Part 2: Taxonomy and Lexicon
8
9
81894646
1
ISO/IEC CD 18012-2  IEC:2008
2
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
10
CONTENTS
11
12
13
List of table ............................................................................................................................. 3
14
FOREWORD ........................................................................................................................... 5
15
INTRODUCTION ..................................................................................................................... 6
16
1
Scope ............................................................................................................................... 9
17
2
Normative references ..................................................................................................... 10
18
3
Terms, definitions and abbreviations .............................................................................. 10
4
3.1 Terms and definitions ............................................................................................ 10
3.2 Abbreviated terms ................................................................................................. 12
Conformance requirements ............................................................................................. 13
22
23
24
25
26
27
28
29
30
31
32
33
5
4.1 Management ......................................................................................................... 13
4.2 Application interoperability model .......................................................................... 13
4.3 Software logic encapsulation ................................................................................. 13
4.4 Interaction with interworking functions (IWFs) ....................................................... 13
4.5 Multiple bindings for application object event inputs and outputs ........................... 13
4.6 Multiple binding maps per application object ......................................................... 13
4.7 Event timestamps .................................................................................................. 13
4.8 Temporal association of events ............................................................................. 13
4.9 Home electronic system application interoperability taxonomy ............................... 14
4.10 Object schema ...................................................................................................... 14
4.11 Application binding map schema ........................................................................... 14
Application interoperability model ................................................................................... 14
34
6
Interaction model ............................................................................................................ 15
7
6.1 Overview ............................................................................................................... 15
6.2 Application objects ................................................................................................ 16
6.3 Binding map .......................................................................................................... 16
6.4 Events ................................................................................................................... 17
6.5 Event bus .............................................................................................................. 17
Home electronic system application interoperability taxonomy ........................................ 18
19
20
21
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
7.1
7.2
7.3
7.4
81894646
Classification ......................................................................................................... 18
Application domain ................................................................................................ 20
7.2.1 Definition ................................................................................................... 20
7.2.2 Application domain list ............................................................................... 20
Functional object ................................................................................................... 20
7.3.1 Definition ................................................................................................... 20
7.3.2 Functional object structure ........................................................................ 20
7.3.3 Functional action ....................................................................................... 21
7.3.4 Functional object list .................................................................................. 21
Application Object ................................................................................................. 21
7.4.1 Definition ................................................................................................... 21
7.4.2 Application Object Structure ...................................................................... 21
7.4.3 Property .................................................................................................... 21
7.4.4 Property data type primitives ..................................................................... 22
2
ISO/IEC CD 18012-2  IEC:2008
55
56
57
58
8
3
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
7.4.5 Property unit type primitives ...................................................................... 22
7.4.6 Property action primitives .......................................................................... 22
7.4.7 Object types .............................................................................................. 23
Object schema ............................................................................................................... 23
59
60
61
62
63
64
65
66
8.1
8.2
Overview ............................................................................................................... 23
Base objects ......................................................................................................... 23
8.2.1 General ..................................................................................................... 23
8.2.2 Control objects .......................................................................................... 24
8.2.3 Sensor objects........................................................................................... 25
8.2.4 Actuator objects ........................................................................................ 25
8.3 Data type primitives ............................................................................................... 25
Application binding map schema .................................................................................... 26
9
67
68
9.1 Overview ............................................................................................................... 26
Annex A (informative) An interoperability application specification example ......................... 27
69
70
71
72
73
74
75
76
77
78
79
80
A.1
A.2
A.3
A.6
Annex B
Lighting application ............................................................................................... 27
Procedure ............................................................................................................. 27
Generic lighting subsystem application model ....................................................... 27
A.3.1 Functional classes ..................................................................................... 27
LonWorks .............................................................................................................. 30
A.4.1 LonWorks: LightSwitch functional profile .................................................... 30
A.4.2 LonWorks  LonWorks-IOP interworking function .................................. 30
UPnP .................................................................................................................... 32
A.5.1 UPnP: LightLamp functional profile ............................................................ 32
A.5.2 UPnP  UPnP-IOP interworking function ............................................... 33
Interoperable System – Functional Model .............................................................. 35
(normative) Base Object Schema Definitions ......................................................... 37
81
82
83
84
85
86
87
88
B.1
B.2
B.3
B.4
B.5
B.6
B.7
Annex C
Commons .............................................................................................................. 37
Base Types ........................................................................................................... 38
Base Definitions .................................................................................................... 39
Control Objects ..................................................................................................... 45
Sensor Objects ...................................................................................................... 45
Actuator Objects .................................................................................................... 45
Application Binding Map ........................................................................................ 46
(informative) Base Object Schema Extension Examples ........................................ 48
89
90
91
C.1 Derived Types (examples) ..................................................................................... 48
C.2 Industry-specific Types (examples) ....................................................................... 50
Annex D (informative) Notes on interoperability ................................................................... 52
92
93
94
95
D.1 General comments on the interoperability framework specification ........................ 52
D.2 Taxonomy definitions ............................................................................................ 52
D.3 Taxonomy of the existing systems ......................................................................... 52
Bibliography .......................................................................................................................... 53
96
97
List of table
98
Table 1 – Application domain list .......................................................................................... 20
99
Table 2 – Property structure ................................................................................................. 22
100
Table 3 – Property unit type primitives .................................................................................. 22
101
Table D.1 – Terminology mapping table ................................................................................ 52
A.4
A.5
81894646
3
ISO/IEC CD 18012-2  IEC:2008
4
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
102
103
List of figures
104
Figure 1 – Two Interoperating Networks ................................................................................ 10
105
Figure 2 – Application interoperability model ......................................................................... 15
106
Figure 3 – Binding map example ........................................................................................... 17
107
Figure 4 – Event bus example ............................................................................................... 18
108
Figure 5 – Interoperable system taxonomy ............................................................................ 19
109
Figure 6 – Object schema structure ...................................................................................... 24
110
Figure A.1 – Lighting application ........................................................................................... 27
111
Figure A.2 – LightSwitch Object ............................................................................................ 28
112
Figure A.3 – LightLamp Object .............................................................................................. 30
113
Figure A.4 – LonWorks LightSwitch Device (Switch Object 32 00) .......................................... 30
114
Figure A.5 – LonWorks InterWorking Function System .......................................................... 31
115
116
Figure A.6 – Functional Mapping LonWorks LightSwitch Device to the Generic
LightSwitch ........................................................................................................................... 31
117
Figure A.7 – LonWorks Function Mapping Table ................................................................... 32
118
Figure A.8 – UPnP LightLamp Device ................................................................................... 33
119
Figure A.9 – UPnP InterWorking Function System ................................................................ 34
120
Figure A.10 – Functional Mapping UPnP LightLamp Device to the Generic LightLamp .......... 34
121
Figure A.11 – UPnP Function Mapping Table ........................................................................ 35
122
Figure A.12 – Interoperable System Working Flow ................................................................ 36
123
124
81894646
4
ISO/IEC CD 18012-2  IEC:2008
5
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
125
FOREWORD
126
127
128
129
130
131
132
ISO (the International Organisation for Standardisation) and IEC (the International
Electrotechnical Commission) form the specialised system for world -wide standardisation.
National bodies that are members of ISO or IEC participate in the development of
International Standards through technical committees established by the respective
organisation to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organisations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
133
134
135
136
In the field of information technology, ISO and IEC have established a joint technical
committee, ISO/IEC JTC 1. International Standards adopted by the joint technic al 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.
137
138
139
This part of ISO/IEC 18012 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 25, Interconnection of Information Technology
Equipment.
140
141
142
ISO/IEC 18012 consists of the following parts, under the general title Information technology
— Interconnection of information technology equipment — Home electronic system —
Guidelines for product interoperability:
143

Part 1: Introduction
144

Part 2: Taxonomy and Lexicon
145

Part 3: Application models
146
81894646
5
ISO/IEC CD 18012-2  IEC:2008
6
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
147
INTRODUCTION
148
149
150
151
152
153
154
155
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 underlying protocols. Examples of such applications include lighting
control, environmental control, energy management, audio/video equipment contr ol, and home
security.
156
157
158
159
160
161
162
This International Standard provides a descriptive mechanism at the application level, so that
there is a common way of describing applications in any underlying system, and an
unambiguous mapping to key implementation items (e.g., d ata type primitives) to allow for
transparent interoperability. Application-level interoperability can not be achieved without
being able to describe applications. The term “product interoperability” should be considered
synonymous with application-level interoperability, since products are developed to implement
applications - the value of products derives from their applications.
163
164
165
166
167
168
169
170
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: CEBus, LonTalk, KNX, EHS, UPnP, and EchoNet. From that analysis, key similarities
were identified between the various approaches and implementations. Those 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 between various automation system application functions, but signi ficant
differences at the syntactic level.
171
172
173
That observation establishes the approach followed in this International Standard: to facilitate
interoperability, it is necessary to define an application model framework with the following
characteristics:
174

Allows a rich set of application semantics to be clearly described in a common format
175
176
177

Incorporates a simple but flexible interaction model abstraction that can represent all the
potential interactions of the various system implementations ( command/response, shared
variable, message-oriented, etc.).
178
179
180

Establishes the minimal set of common data type primitives to support unambiguous
mapping of logical application data descriptions into implementation -specific binary
representations.
181
182
183
184
185
Interoperability in distributed application systems is defined as the ability of two or more
distributed components to communicate and cooperate 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:
186
187

Protocol level, where the blocking conditions (synchronous or sequential constraints) are
defined.
188
189

Syntactic level, where the ordering between the exchanged messages and where th e
names, interfaces, and operation of the components are defined.
190
191

Semantic level, where the meaning of the possible interactions between the components
in the distributed application system is defined.
192
193
194
195
With semantic level interoperability, clashes between two application components attempting
to cooperate are caused by differences in the lexicon (conceptual schemas) that describe the
components. Simply put, a mistranslation may occur between the two systems because of
incomplete shared information. The poss ible clashes can be classified into two main groups:
196
197
198
Lossless clashes, 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
81894646
6
ISO/IEC CD 18012-2  IEC:2008
199
200
7
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
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.
201
202
203
204
205
206
207
208
209
210
211
212
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 components. 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 components 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
(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.
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
This International Standard is based on understanding the difference in the primitiveness of
actions at different levels of object definition (i.e., different levels of abstraction). Furthermore,
it is based on separation of the concept of action primitives from the actual implementation of
these primitives. For example, if objects (devices) in System -A use <get>/<put> functions to
implement local or remote reading and writing of variable values, these are not considered
“action primitives” in the context of this International Standard, but rather a programming
mechanism used to invoke the application actions. The different actions are caused by <put> 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. This is captured later
on in this International Standard by eventing – objects (devices) notify each-other with the
values of their parameters, and each device (object) makes its decisions and t akes 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 cal l. In this case it is possible for
both systems to implement the same lexicon, but with their own invocation mechanism.
228
229
230
231
232
233
234
For example, one automation system might implement a shared variable space for
communication between devices and components. In a simple lighting control example, a user
might turn a wall switch on, causing a shared variable in the switch device on the 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 state. The controller could then take actions as
defined by the configuration and programming of the lighting control application.
235
236
237
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.
238
239
240
241
In both examples, the behaviour of the light ing 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).
242
243
244
245
246
The interoperable system is generic, and as such it should cater to different interactivity
models (as described in the example above). It is assumed that any adaptation necessary
from a system-specific interaction model to the eventing interaction adopted by the
interoperability model is included in the implementation of the interworking functions provided
by the manufacturers (or third party providers) interfacing into the interoperability model.
247
248
249
250
251
252
253
254
The interoperability model in this International Standard addresses the requirements of two
developer communities: the component developers (e.g., manufacturers), who develop
individual devices and systems, and the solution developers (e.g., integrators or field
installers), who provide one (or more) applications that use serv ices provided by the
components. The two communities overlap at least partially. For example, a company that
develops automation devices would typically provide software routines that link their products
to specific application objects, which could be a standardized objects published as part of an
application model, or could be something the company defined and published. In the latter
81894646
7
ISO/IEC CD 18012-2  IEC:2008
8
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
255
256
case the object definitions are considered to be standard only upon publication in a registry of
interoperable objects.
257
This document comprises the following sections:
258
259

Clauses 1 through 4 are the scope, normative references, terms, definitions and
abbreviations, and conformance clauses respectively.
260

Clause 5 describes the application interoperability model.
261

Clause 6 describes the interaction model in terms of an asynchronous event -bus model.
262

Clause 7 describes the taxonomy used for inter-system and intra-system interoperability.
263

Clause 8 describes the object schema framework.
264

Clause 9 describes the application binding map schema framework.
265

Annex A describes an example of an interoperable application specification .
266

Annex B contains the base object schemas.
267

Annex C contains base object schema extension examples.
268

Annex D contains miscellaneous notes on interoperability and related taxonomy terms.
269
81894646
8
ISO/IEC CD 18012-2  IEC:2008
9
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Information technology — Home electronic System (HES) — Guidelines
for product interoperability — Part 2: Taxonomy and Lexicon
270
271
272
1
Scope
273
274
275
276
277
278
279
280
281
282
This part of ISO/IEC 18012 specifies a taxonomy and lexicon for the interoperability of
products in the area of home electronic systems. It also specifies an interoperability
framework to allow products from multiple manufacturers can work together to provide a
specific application. This standard is concerned with layers six (Presentation) and seven
(Application) of the OSI Reference Model (ISO 7498), with sufficient detail needed to
establish interoperable applications in this domain. Layers one through five are not specified
here. The interoperability framework defined here is independent of all layer 1 to layer 5
communication protocol stacks used in a home electronic system (for an example of layers
one through five see ISO/IEC 14543). A minimal set of transport layer requirements is
specified in ISO/IEC 18012-1.
283
This International Standard is applicable to:
284
285

Single implementation
applications.
286
287

Multiple implementation home electronic system networks, connected devices and
applications.
288

Automatically configured devices.
289

Installer configured devices.
290

Installer configured groups/clusters of devices.
291
292
293
294
295
This part of ISO/IEC 18012 addresses interoperability for system operation and management
of products connected to a single home electronic system or to different home electronic
systems. Although a single uniform home system would simplify operations, this International
Standard recognises that multiple different networks may co -exist in the same distributed
home electronic system.
296
297
298
299
300
301
302
The taxonomy specified here is based on application domain classification criteri a for
applications in home electronic systems, as well as a lexicon of objects, events, properties,
and primitive actions to effect or otherwise propagate change in the objects (their properties).
The full lexicon for the interoperability of home electroni c systems will be defined in Part 3 of
this standard, as part of the Application Model specifications. This International Standard
enables the specification and implementation of distributed application functions and services
within the context of home electronic systems.
303
304
305
306
307
308
This International Standard does not specify how two home electronic systems simultaneously
share (i.e. resolve possible contention for) a common resource or how to ensure that two
home electronic systems used within the same premises do not interfere with each other.
However, note that it is required by Part 1 of this International Standard that two home
electronic systems may share a common resource, and that they shall not interfere with one
another.
81894646
home electronic system
networks, connected devices and
9
ISO/IEC CD 18012-2  IEC:2008
10
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Gateway Link
HGI A
Objects on
Network A
Network A
HGI B
Network B
Objects on
Network B
309
Figure 1 – Two Interoperating Networks
310
311
312
313
314
This International Standard applies to application components in operation within networks,
between networks, and to components located at the junction of dissimilar networks. Two (or
more) dissimilar networks (referring to Figure 1 as an example) that conform to this
International Standard, when linked by some communication system, are expected to behave
as if both networks were logically the same network from an application per spective.
315
2
316
317
ISO/IEC 646 Information technology — ISO 7-bit coded character set for information
interchange
318
319
ISO 7498:1984, Information processing systems – Open Systems Interconnection – Basic
Reference Model
320
321
ISO/IEC 18012-1, Information technology — Home electronic system (HES) — Guidelines for
product interoperability — Part 1: Introduction
322
323
IEC 60050-714:1992, International Electrotechnical Vocabulary - Chapter 714: Switching and
signalling in telecommunications
324
IEC 60559, Binary floating-point arithmetic for microprocessor systems
325
3
326
3.1
327
For the purposes of this International Standard, the following terms and definitions apply.
328
329
330
331
332
3.1.1
application programming interface
API
collection of invocation methods and associated parameters used by one piece of software to
request actions from another piece of software
333
334
335
3.1.2
co-existence
two or more networks within a premise that do not interfere with one another
Normative references
Terms, definitions and abbreviations
Terms and definitions
81894646
10
ISO/IEC CD 18012-2  IEC:2008
11
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
336
337
338
3.1.3
component
logical subunit of a larger, encom passing concept
339
340
341
342
NOTE The concept of interoperability is broken down into constituent components such as safety, management
and operation. These constituent components are further broken down within their respective sections. The term
component is also used to refer to logical subunits of system architecture concepts, such as the components of a
networking implementation (for example, addressing) .
343
344
345
3.1.4
device
distinct physical unit on a network
346
347
NOTE It can either be an end node on the network, or an intermediate node (as in the cas e of a network gateway
device connecting two distinct physical networks).
348
349
350
351
3.1.5
event
individual output of an application object, typically corresponding to a simple or complex state
variable used in the application object
352
NOTE See 6.4: Events.
353
354
355
3.1.6
functional action
modelling of functionally composite behaviour within a functional class
356
357
358
359
3.1.7
functional class
a collection of objects and actions on objects that models a particular application function
within an application domain
360
361
362
3.1.8
intermediate implementation
mixed collection of two or more network implementations
363
364
365
NOTE To establish connectivity, an intermediate implementation provides for a common intermediate translation
between any two networks, assuring a worst-case translation path of two hops (from any network to the common
translation, and then from the common translation to the destination network).
366
367
368
3.1.9
interoperability
(1) logical entities functioning together for applications on a network
369
370
371
(2) the ability of two or more distributed components to communicate and cooperate in
predictable ways despite differences in implementation language, execution
environment, or model abstraction
372
373
374
375
376
3.1.10
interoperability domain
ID
logical space where interoperable objects seamlessly interact with one-another using an event
bus
377
378
379
380
381
3.1.11
interoperability domain interface
IDI
software object that provides the translation between a generic interoperable object instance
and a corresponding system-specific counterpart by using an interworking function
382
383
384
385
3.1.12
interworking
ability of two or more devices to support exchange of data and actions between them, having
the same communication interface and application data types
81894646
11
ISO/IEC CD 18012-2  IEC:2008
12
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
386
387
388
389
390
391
3.1.13
interworking function
IWF
software module that provides syntactic and semantic translation service s between a device
and its standardised interoperable representation; it resides in an intermediary unit that
connects two, possibly different, communication systems
392
393
394
3.1.14
multiple implementation
mixed collection of two or more network implementations
395
396
NOTE To establish interoperability, each network has a routing path to every other network in the system. This
path may involve one or more hops through multiple intermediate networks.
397
398
399
3.1.15
network
distinct interconnection of devices that share a singl e physical layer implementation
400
401
402
3.1.16
object
unit of software functionality
403
NOTE This definition is similar to that traditionally used in object-oriented programming.
404
405
406
3.1.17
product
device or network that may be purchased to make up a home electronic s ystem
407
3.2
408
For the purposes of this International Standard, the following abbreviated terms apply.
409
410
411
3.2.1
API
application programming interface
412
413
414
3.2.2
GL
gateway link
415
416
417
3.2.3
HAN
home area network
418
419
420
3.2.4
HES
home electronic system
421
422
423
3.2.5
HGI
home gateway interface
424
425
426
3.2.6
ID
interoperability domain
427
428
429
3.2.7
IDI
interoperability domain interface
430
431
432
3.2.8
IWF
interworking function
Abbreviated terms
81894646
12
ISO/IEC CD 18012-2  IEC:2008
13
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
433
4
Conformance requirements
434
4.1
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
Interoperability considerations regarding general management processes in HES are
described in ISO/IEC 18012-1. This part addresses only the management aspects related to
the operation mode of interoperable HES and does not cover the management processes of
individual constituent networks. Examples of these are the device address acquisition and
maintenance or resource management processes (contention for gaining exclusive access to
some object). Different systems define different management protocols and procedures for
realising these. This part only covers, for example, the device management functions
pertaining to application configuration. In this context it is assumed that the propagation of the
necessary actions to support the operational application object binding further down the
protocol stack (for example, device address or network variable number), as well as the
provisioning of the necessary conditions are fulfilled by separate management services not
described in this part. These functions are standardised or specified in the domain of t he
individual networks. As the IWFs are used as the device interface proxy to the interoperability
system and are normally provided by the manufacturer of the device (or an intere sted third
party provider), these management functions are carried out within the IWF code and are not
part of this International Standard.
451
452
453
454
455
456
Further examples of management issues outside the scope of this International Standard
include establishing and maintaining connectivity between devices hosting the distributed
application objects independently of the fact that the devices belong to the same or different
systems. Interoperability management allows for transparency to the native application
management support services provided by separate, though interoperable, systems
independently of the fact that these services are automatic or installer -based.
457
4.2
458
459
460
An implementation shall conform to the application interoperability model described in Clause
5: Application interoperability model, including the use of an ID and IDIs with appropriate
IWFs to achieve interoperability.
461
4.3
462
463
An implementation shall support encapsulating software logic within application objects, as
described in subclause 6.2: Application objects.
464
4.4
465
466
An implementation shall support interaction between IWFs and application objects, as
described in subclause 6.2: Application objects.
467
4.5
468
469
An implementation shall support the definition of multiple bindings per application object event
input or output, as described in subclause 6.3: Binding map.
470
4.6
471
472
An implementation shall support application objects belonging to more than one binding map,
as described in subclause 6.3: Binding map.
473
4.7
474
An implementation shall support event timestamps as described in subclause 6.4: Events.
475
4.8
476
477
478
479
An implementation shall support the requirement for multiple events generated concurrently
from a single application object to be delivered at the same time to any app lication object that
has a binding to two or more of those concurrent events, as described in subclause 6.4:
Events.
Management
Application interoperability model
Software logic encapsulation
Interaction with interworking functions (IWFs)
Multiple bindings for application object event inputs and outputs
Multiple binding maps per application object
Event timestamps
Temporal association of events
81894646
13
ISO/IEC CD 18012-2  IEC:2008
14
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
480
4.9
Home electronic system application interoperability taxonomy
481
482
483
An implementation shall use the taxonomy defined in Clause 7: Home electronic system
application interoperability taxonomy when defining interoperable application objects and
events.
484
4.10
485
486
An implementation shall use the schema defined in Clause 8: Object schema when defining
interoperable application objects, including:
487
488

Conforming to the use of the base objects defined in 8.2 as the foundation for deriving
specific application objects.
489
490

Assuring that all events either match a data type primitive defined in 8.3, or are derived
from a combination of those primitives that defines a more complex data type.
491
4.11
492
493
494
An implementation shall support a binding map mechanism that conforms to the requirements
defined in Clause 9, such that any interoperable application may be fully specified to the
interoperability framework implementation.
495
5
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
The application interoperability m odel is based on the definition of one or more application
domains, where each domain is identified explicitly in the HES object taxonomy. Each domain
is populated with application objects representing sensor, actuator and control devices. These
application objects interact with one another by posting and receiving events across a logical
event communication bus (the event bus); the event bus provides the communication services
to the application objects. An application is formed as a collection of one or more application
objects with specified bindings, and with verifiable behaviour. A generic application example
is a controller application object instance which collects sensor information from sensor
application objects of a pre-defined type, and requests action from actuator application
objects, again from a list of pre-defined types. Note that this view does not assume that a
physical device (product) will be modelled as only one of these three classes (i.e. a product
may be realised as a combined sensor/actuator/controller entity if the particular application
requires it to be designed in that way); however, for the purposes of the interoperability
framework each of the three functionalities will be presented by different objects when and if
they are required to interoperate across system s belonging to different specifications and/or
standards.
512
513
514
515
516
517
518
The application objects are programs running on individual devices, for example a
temperature sensor device has a corresponding application object that is called
TemperatureSensor. The association of interoperable application objects with actual devices
is performed through configuration processes which are part of the IWF provided by the
device manufacturer or an interested third party. These configuration processes are outside
the scope of this International Standard.The interoperable application objects connect to the
actual devices they represent via the IWFs.
Object schema
Application binding map schema
Application interoperability model
81894646
14
ISO/IEC CD 18012-2  IEC:2008
15
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Interoperability Domain
Interoperabi
lity Object 1
IDI
(IWF-A)
Device 1-A
Network A
Interoperabi
lity Object 2
IDI
(IWF-B)
Network B
Device 2-B
519
Figure 2 – Application interoperability model
520
521
522
523
524
525
526
527
528
529
530
531
532
533
Figure 2 shows an instantiation of the application interoperability model. Two devices
(Device 1-A and Device 2-B) are installed in two different network systems, respecti vely
Network A and Network B, and need to interact with each other to provide an interoperable
application. The networks are linked together through a logical entity called the
interoperability domain (ID). The ID connects with different network systems via a set of
interoperability domain interfaces (IDIs). The IDIs are software entities containing software
functions that provide any necessary translation between the generic interoperable object
instance (e.g. Interoperability Object 1 within the interoperability domain) defined in this
International Standard and the corresponding system-specific counterpart (Device 1-A in
Network A). These translation services are called Interworking Functions (IWFs). The IDIs
maintain the logical connection between the interoperable object instance within the
interoperability domain and the corresponding device (or the system-specific counterpart).
This includes maintaining object-state consistency between the interoperable object instance
and the system-specific counterpart, as necessary; this is performed by the IWF.
534
535
536
Note that both Networks A and B may contain other devices. They will not be represented in
the interoperability domain if these devices are not required to interwork in the context of this
specification with devices on other different systems and/or networks.
537
538
539
The interoperability domain is a logical entity. It can be implemented on a single physical
device/platform, distributed over several devices, or its functionality may be integrated with
other functional entities such as a HES Gateway.
540
541
542
Specific network systems shall specify the IWFs to be used for the interoperable object
instantiation and running on an interoperability domain for devices that are intended to be
interoperable.
543
6
544
6.1
545
546
547
548
An interaction model between the application objects in the interoperability domain is
described here for passing application events across a logical event communication path or
bus defined within the interoperability domain, known here as the event bus. Event passing is
asynchronous, occurring at any time that the application objects require.
Interaction model
Overview
81894646
15
ISO/IEC CD 18012-2  IEC:2008
16
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
549
550
Events are originated by application objects. It should be noted that an application object is
not required to produce outputs: some application objects might only be r eceivers of events.
551
552
553
554
555
556
557
558
559
560
Each application object can have multiple event inputs and event outputs, which correspond
to the input and output parameters (as defined in IEC 60050-714:1992, Definition 714-21-08)
of that application object’s function or functions. T herefore, the individual function parameters
of an application object are being passed across the event bus as separate events. This
effectively breaks any tight association between the application object function interfaces
(application programming interfaces) and the communication protocol used to move the
parameters across the network: the event bus simply moves individual events from a source
application object to a destination application object or objects, and is not dependent on
future changes to the application object function interfaces. In other words, the event bus
communication protocol is completely independent of the applications that it is supporting.
561
562
563
564
565
Event destinations are specified by a binding map that is part of the application
interoperability framework definition. The binding map is used to define event connections
(bindings) between application objects at the individual event level. These bindings are simply
the declaration of a connection from an event output of an application object to one or more
event inputs of an application object or objects.
566
567
568
569
570
571
572
573
574
575
It would not be efficient, from a communication channel perspective, to send every individual
application object function parameter as a discrete transaction on the event bus. Therefore, it
is expected that implementations of this International Standard will make use of both the
application object schemas and the binding map information to enable efficient automated
aggregations of multiple concurrent events. This means that during execution
implementations should group together concurrent events (e.g., event outputs that were
generated concurrently by an application object) that have the same destination, and move
them across the event bus as a single communication transaction (e.g., a single me ssage
payload, a single memory transfer, etc.). See 6.5: Event bus for a further discussion of this
concept.
576
577
578
579
580
581
This aggregation of events is independent of the application object function interfaces, and
could even allow for the outputs of multiple application objects to be moved across the event
bus as a single unit. Upon arriving at the destination, the grouping should be disaggregated
into their individual events for posting to the appropriate applicat ion object inputs. This
approach enables global system-level optimization of communication bandwidth, rather than
individual application-level optimization.
582
6.2
583
584
585
Application objects represent the operational components of an interoperable ap plication.
They are software representations of the sensors, actuators, control devices, and higher -level
functions in a HES system that must interoperate.
586
587
588
589
590
Depending on their function, application objects can have zero or more event inputs and
event outputs. An application object with only event outputs is considered a sensor
application object; one with only inputs is considered an actuator application object. Control
application objects have one or more event input(s) and one or more event output(s). See
Clause 8: Object schema for a complete description.
591
592
593
594
595
596
597
598
Application objects encapsulate software logic appropriate to the component they represent in
the system. For example, a temperature sensor application object for a temperature sensor
device would receive temperature readings from the device via an IDI using an appropriate
IWF that performs any necessary reformatting or translation on the readings to put them in the
form of the interoperable properties defined in 7.4.2: Application Object Structure. The
temperature sensor application object can then perform any additional application processing
desired (if any) before generating an output event on the event bus containing the
temperature reading.
599
6.3
600
601
A binding map corresponds to a single application in the interoperability domain. There will
typically be many binding maps active, one for each application that is running.
Application objects
Binding map
81894646
16
ISO/IEC CD 18012-2  IEC:2008
17
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
602
603
604
The binding map defines the connections between the application objects that make up a
complete application. A binding identifies the source -end and the destination-end of an event
connection. See Figure 4 – Event bus example for a graphical depiction of this concept.
605
606
607
608
There can be multiple bindings from each application object event output, and there can be
multiple bindings to each application object event input. In other words, an application object
event output can be used as an input by more than o ne application object, and conversely an
application object event input can receive events from more than one application object.
609
610
611
612
Also, application objects might be part of more than one application, and as such they might
be included in more than one active binding map as shown in Figure 3 – Binding map
example. In this simple example Lighting Controller B is part of both the manual lighting
switch application and the motion-activated lighting security application.
D
Security
Controller
Lamp Control Application
Binding Map
(A, B, C)
B
E
Lighting
Controller
Motion
Sensor
A
C
Switch
Lamp
Security Application
Binding Map
(B, D, E)
613
Figure 3 – Binding map example
614
615
6.4
Events
616
617
618
619
Events correspond to the individual outputs of application objects, and as such the structure
of their application-specific content are defined using the application object schema described
in Clause 8: Object schema. Events shall also contain a timestamp, as defined by the
application object schema.
620
621
622
623
624
At a minimum, there should be a timestamp that corresponds to the time at whi ch an event is
placed on the event bus by an application object. In addition, depending on the capabilities of
the underlying system implementation, there could be a second timestamp that represents the
time when a physical event actually occ urred (e.g., the time that a temperature sensor reading
occurred).
625
6.5
626
627
628
The event bus provides the delivery mechanism for events to pass from an application that
produces the event to any number of application objects that consume the event and
potentially take some action. Events are asynchronous, occurring at any time.
629
630
631
632
633
634
635
636
637
638
The intent is that the event bus model be as simple as possible, allowing it to be implemented
on the broadest possible set of underlying communication mechanisms. One implementation
might be based on a shared memory for an IG domain that is completely contained in a single
processing device such as a simple embedded gateway. A more comprehensive
implementation could be a distributed event bus on top of a publish/subscribe transport
spanning multiple processing devices (such as a collection of HES-Links or GLs, as defined in
ISO/IEC 15045-2, connected over a network), or any combination of such implementations –
the event bus does not have to be implemented on a uniform underlying communication
mechanism, and in fact is likely to span multiple underlying communication mechanisms as
part of building an interoperable HES.
639
640
An important characteristic of the event bus is that multiple events generated at the same
time from a single application object must be delivered at the same time to any application
Event bus
81894646
17
ISO/IEC CD 18012-2  IEC:2008
641
642
643
644
645
646
647
18
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
object that has a binding to two or more of those concurrent events. The following diagram
depicts an application described by a binding map between four application objects (A
through D). For this example, assume that the events generated by Object A outputs o2 and
o3 were produced at the same time (for example, concurrent sensor outputs in reaction to a
change in the physical world). Object D inputs i1 and i3 are bound to those outputs from
Object A, and must be delivered to Object D concurrently to maintain correct behaviour of the
application.
<<Application Object>>
<<Application Object>>
Object A
Object B
o1
o2
o3
o4
o1
o2
o3
<<Event Bus>>
A
1
4
2
B
3
i1
i2
Object D
i3
Output
DataVarSet
1
<<Application Object>>
i1
i2
i3
3
2
i4
Object C
<<Application Object>>
648
Figure 4 – Event bus example
649
650
651
7
Home electronic system application interoperability taxonomy
652
7.1
653
654
655
The HES application interoperability taxonomy is shown in Figure 5Error! Reference source
not found.. For purposes of the interoperability specification the HES domain is classified
into the following categories:
Classification
656
1. Application Domain
657
2. Functional Object
658
3. Application Object
659
4. Functional Actions
660
5. Property
661
6. Property Primitive Actions
81894646
18
ISO/IEC CD 18012-2  IEC:2008
19
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Application Domain
Functional Object
Application Object


Property
Primitive Action
Functional Action
662
663
Figure 5 – Interoperable system taxonomy
664
665
666
667
668
669
670
Application Domains are specified in terms of Functional Objects, which repr esent logical
grouping of some device functionality. Each Functional Object is specified as a collection of
Application Objects (as well as, possibly, objects related to its configuration) that represent
application atomic state and functions. This specifi es the semantics of the applications and
the components of the Functional Object. Objects in turn are specified as collection of
properties, which define the content representation for storage, transport (syntax), and
interaction purposes.
671
672
673
674
675
676
677
678
The classification of the HES components into Functional Objects, Application Objects and
Properties, as logical entities in the taxonomy, is designed to allow for separation of the
syntactic and semantic aspects of the interoperability. Functional Objects model controller
entities (hardware or logical devices) in a home electronic system. Application Objects model
sensor and actuator entities. Properties are used to specify the syntax, i.e. the data
representation of the object information components. This allows for a direct mapping (data
type translation and matching) between properties as specified in this International Standard
and those specified in other specifications through the use of IWFs.
679
680
681
682
683
684
685
686
687
Objects, in general, represent the semantics of the application, i.e. they represent behaviour,
which is exhibited through the interaction with other objects by invoking primitive actions on
the properties. The use of both Functional Objects and Operational Objects allows the
interoperability, through translation in the IWF, to cater for both variable-oriented and deviceoriented HES specifications. The separation between the semantics (object level) and the
syntactic representation of the data (property) allows for flexibility in the definition of the
interoperability IWFs. In the simplest case, Application Objects can be used to present a
single network variable, and allow the modification of the processing of its value for
representation into the Interoperability Framework space.
688
689
690
691
692
As an example, a Functional Object named TemperatureSensor may have an Application
Object called RoomTemperature of <Temperature> data type, which is measured in degree
celsius (semantic). The Appplication Object in the interoperability specif ication is defined as
having a Property called "TempValue", which is of type "Float" that follows the IEC 60559
specification (syntax).
693
Detailed definitions of the framework components are given in the following subclauses.
81894646
19
ISO/IEC CD 18012-2  IEC:2008
20
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
694
7.2
Application domain
695
7.2.1
696
697
698
An application domain serves as context-setting description. It groups together functions that
interact in semantically related applications. A non-exhaustive list of application domains is
given in 7.2.2.
699
700
701
Application domains are enumerated entities. As part of the taxonomy they can be us ed in
word form or represented by the corresponding enumerated value, to form part of the object
name for application binding.
702
7.2.2
703
The application domain list provided in Table 1 . The list is not exhaustive..
Definition
Application domain list
Table 1 – Application domain list
704
Application Domain
Name
Description
1
General
This domain groups together functions that provide generic services to other
entities in a home electronic system. Examples include Time/Date, Location,
User Interface, etc.
2
Audio/Video
This domain groups together functions related to the control of the distribution
and consumption of audio and/or visual content in a home elect ronic system.
Examples include Audio Amplifier, Tuner, Video-display, Speaker, etc.
3
Lighting
This domain groups together functions related to the lighting environment
control in a home electronic system. Examples include Light, Light -sensor,
Light-switch. etc.
4
Communications
This domain groups together functions related to the control of the
communication session set up and distribution/transfer around a home
electronic system. Examples include an Intercom, DataPoint, etc.
5
Heating
This domain groups together functions related to the control of heating sub system, or parts thereof, of a home electronic system. Examples of functions
include RoomController or ZoneController, TemperatureSensor, etc.
6
Ventilation
This domain groups together functions related to the control of environmental
sub-systems (air-conditioning and ventilation). Examples include
TemperatureSensor, HumiditySensor, VentilationZoneController, etc.
7
Utility
This domain groups together functions related to the management and/or
monitoring of utilities such as electricity, water, gas, heating. Examples include
UtilityMeter, LoadController, etc.
8
Security
This domain groups together functions related to the management and/or
monitoring of the security sub-system. Examples include SecuritySensor,
WindowSensor, SecurityZoneController, etc.
9
Appliance
This domain groups together functions related to the management and/or
monitoring of domestic appliances. Examples include Washer, TumbleDryer,
Cooker, Oven, …
705
706
7.3
Functional object
707
7.3.1
708
709
710
711
712
713
A functional object is a collection of objects and actions on objects that models a particular
application function within the application domain. An instantiation of a functional o bject is a
logical device, i.e. a software entity that provides some specific standardised control and/or
information functionality in the HES in which it is installed. Functional objects model controller
entities (hardware or logical devices) in a home electronic system. Functional objects form the
basis of the classification in this International Standard.
714
7.3.2
715
716
717
A functional object has its properties and functional actions. Functional actions are specified
as (possibly aggregate) actions on individual objects that lead to a functional operation of the
logical device in the system. For example, scene setting requires a series of (inter)actions
Definition
Functional object structure
81894646
20
ISO/IEC CD 18012-2  IEC:2008
21
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
718
719
720
721
722
723
724
with several sensor and actuator objects (lighting, communication, AV, etc.); a scene setting
controller can be modelled as a functional object that has a functional action composed of
actions on individual operational objects modelling devices as described abov e. A functional
action has contextual meaning, and is specified together with the functional object. The
invocation of a functional action leads to a specified series of invocation of component
(operative) objects, and results in moving the operational obj ects into a specified, and
verified, end state, where applicable.
725
726
727
728
A functional object describes the application layer interface, including input and output
operation objects, configuration properties, default and power -up behaviour required on
devices for specific commonly used control functions. An instance of a functional o bject is
implemented in a physical device as (part of) the application.
729
730
731
732
733
An instance of a functional object is a logical device locally addressed via a functional object
identifier. The functional object identifier (FOID) value can be a result of local enumeration, or
a global FOID can be used. In any case the mapping between the FOID and the service
access point serving this instance of the functional o bject is maintained by the application
support layer.
734
7.3.3
735
736
737
738
Functional action allows for modelling of functionally complex behaviour within a functional
object (i.e. in a specific context). Functional actions are enumerated entities within a
functional object, and have meaning only within that object. An example of a functional action
is <SwitchOn> within a LightController functional o bject.
739
740
741
Invoking a functional action means to invoke at least one primitive action on at least one of
the properties in at least one operational object within the same functional profile, local or
remote.
742
7.3.4
743
744
The functional object list consists of all defined functional classes for each application
domain..
745
7.4
746
7.4.1
747
748
749
750
751
Application objects are self-describing actionable, locally addressable, entities that contain
one or more properties. An application object models, through its properties and primitive
actions, the most generic behaviour of sensors and actuators in a home electronic system. An
object contains basic descriptive properties, configuration properties, and operational
properties.
752
7.4.2
753
754
755
Application Objects are collections of one or more properties. Each p roperty is an internally
structured self-describing entity that encapsulates some information source (in sensors) or
control (in actuators) variable.
756
757
Every application object has a self-description property and an object instance identifier
property.
758
759
The object instance identifier can be instantiated dynamically, or seeded with a (defa ult) value
specified in the published generic application model.
760
7.4.3
761
762
763
A Property is an atomic actionable structured data entit y that contains a single variable. The
structure of a property is given in Table 2 below. They are presented in a simple data format,
and are characterised by a data type, methods, and information flow direction (in, out, in/out).
764
The property methods defined implicitly are given in 7.4.6.
Functional action
Functional object list
Application Object
Definition
Application Object Structure
Property
81894646
21
ISO/IEC CD 18012-2  IEC:2008
22
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Table 2 – Property structure
765
Descrip
tion
Notation
Property_Name
Character String
Property_Action_List
Array of String
Coding
Property
Property Data Type
[Array of] Primitives from clause 7.4.4
Number of elements
Unsigned Integer
Value
Value
Default Value
Application
Semantics
Value Range
Property Unit Type
Support (Mandatory / Optional / Conditional)
Access (In / Out / IO ),
766
7.4.4
Property data type primitives
767

Character string (ISO/IEC 646)
768

Boolean
769

Integer (Integer8, Integer16, Integer32)
770

Unsigned integer (UInt8, Uint16, Uint32,Uint64)
771

Float (IEC 60559)
772

Date
773

Time (and Date/Time)
774
775
7.4.5
Property unit type primitives
776
These are semantic data units, for example degree Kelvin for temperature semantic data type.
777
These are grouped into basic data units and derived data units.
778
779
780
The basic data units are given in Table 3 below, and outlined in the XML schema file in Annex B.2:
Base Types. Using this set of unit type primitives, any physical unit type can be derived. Derived data
units will be listed and maintained in the same way the lexicon registry is maintained.
Table 3 – Property unit type primitives
781
Property unit type
Unit
Length
Meter
Time
Second
Temperature
Kelvin
Mass
Kilogram
ElectricCurrent
Ampere
SubstanceAmount
Mole
LuminousIntensity
Candela
782
783
7.4.6
Property action primitives
784
The actions allowed on the properties are:
785

GET: the value of the property being queried is returned.
786

SET: the value of the property being accessed is set to the given value.
787

EVENT_REPORT: the value of the property is reported to the subscribed entities.
81894646
22
ISO/IEC CD 18012-2  IEC:2008
23
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
788
789

790
7.4.7
791
792
793
Objects can be classified into two groups: application objects and application management
objects (configuration). Only the application objects are addressed by this In ternational
Standard.
794
The Object Schema specifies the type of object.
795
8
796
8.1
797
798
799
800
801
802
The object schema design reflects the interaction model described in Clause 6: Interaction
model, and emphasises describing the input and output events of objects. This includes the
names, the data types, and optionally other characteristics about the inputs and outputs.
These other characteristics are an open-ended set that will take the form of metadata
elements that extend the input and output elements in the schema, an example of which might
be maximum latency requirements on inputs.
803
804
805
806
807
The object schema must also reference the executable logic that implements the object’s
functions. This reference is implementation-independent, and needs to be able to support any
execution platform and language. The purpose is to enable an interoperability framework
implementation to invoke any executable logic for an object, and present the input events that
are pending (i.e., that have arrived for the object from the event bus).
808
809
810
There can also be additional, global metadata associated with an object. This might be for
configuration parameters affecting the behaviour of the object (versus the individual input or
output metadata described above).
811
8.2
812
8.2.1
813
814
815
816
817
There are three types of primitive object types in the schema: sensors, actuators, and control
objects. Although these names imply very different types of objects from a conceptual
perspective, the functional difference between the three object types in this schema is simply
that sensors only have event outputs, actuators only have event inputs, and control objects
have both event inputs and outputs.
818
819
820
821
There can be other input and output settings for any of these objects , such as the ability to set
or change metadata characteristics to adjust the object configuration, but these would be
separate from the asynchronous application event flows. For example, object settings could
be managed through a synchronous call interfac e to the object.
822
823
824
Using these three basic building blocks of sensors, actuators, and control objects with
asynchronous input and output events, connected together across an event bus, it is possible
to construct a description of any automation application o r function.
825
826
827
828
829
830
831
Events do not contain any explicit identification of the type of object that generated the event.
This means that any object with an output can be bound to any object with an input.
Importantly, it means that control objects can provide inputs to other control objects (i.e.,
inputs do not have to come from sensor objects). This provides the basis for creating subautomation components in an application description, allowing groups of sensors, actuators,
and control objects to appear conceptually as sensor inputs or actuator outputs to higher level
control objects in a complex application.
832
833
834
835
836
The intention is that specific types of sensor, actuator, and control object schemas will be
derived from the base object schemas, and those specific types can then be further derived
into vendor-specific variations if needed. For example, a temperature sensor object schema
can be derived from the base sensor schema, defining a single output of type Fahrenheit
degrees. A vendor might then further refine the tempe rature sensor schema with vendor-
SUBSCRIBE: the operational object updates the list of subscribed entities (objects) for the
given/required property. If the list is empty the property changes are not reported.
Object types
Object schema
Overview
Base objects
General
81894646
23
ISO/IEC CD 18012-2  IEC:2008
24
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
837
838
specific characteristics such as additional features. These can be described by defining global
configuration properties or perhaps additional outputs.
839
The Base Object XML schema definitions are shown in Annex B.
840
8.2.2
841
842
843
844
Control objects have any number of inputs and outputs. Conceptually, they are the objects
that will contain the core functions of an application: the decision logic, the control loops, etc.
This subclause will describe the content of the base control schema. The following subclauses
discuss the sensor and actuator schemas.
845
846
847
The block diagram below shows the basic structure of the control object schema. The
commons section is shared between the sensor, actuator, and control object
schemas.
Control objects
controlModelTypes
controlModel
commons
inputs
outputs
codeBase
properties
description
input
output
property
codeType
dataPoint
QoIRequirement
<<complexType>>
<<complexType>>
eventProperties
eventProperties
dataPoint
QoI
<<complexType>>
<<complexType>>
eventProperties
eventProperties
codeLocation
idlLocation
848
849
Figure 6 – Object schema structure
850
851
852
853
The commons section describes the basic structure of all the objects: inputs, outputs, global
object properties (such as configuration settings, etc.), and a reference to the executable
code that implements the logic of the control object. The commons section schema is listed in
Annex B.1: Commons.
854
The inputs section of the schema is comprised of one or more input elements:
855
856
857
858
859
860
861
862
<xsd:element name="input">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="dataPoint"/>
<xsd:element ref="QoIRequirement" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
863
864
865
866
867
It consists of a dataPoint element, which decribes the data type of an input event, and a
QoIRequirement or Quality of Information Requirement element, which is used to define other
characteristics of the input events, examples of which might be precision, frequency, etc.
These are considered metadata that describe things about the input event, rather than
describing the event itself.
868
869
870
871
The outputs section is similar in structure and content, with the exception that ins tead of
having QoIRequirement metadata, it refers to QoI or Quality of Information metadata, which
define other characteristics of the output events, and are suitable for matching or validation
against input QoIRequirements.
872
873
Both the QoIRequirement and the QoI metadata are open-ended sets of information, and will
be expanded as needed to support different application requirements.
81894646
24
ISO/IEC CD 18012-2  IEC:2008
874
875
876
877
878
879
880
881
882
883
25
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
The codeBase section of the schema is :
<xsd:complexType name="codeBase">
<xsd:sequence>
<xsd:element name="description" type="xsd:string" minOccurs="0"/>
<xsd:element name="codeType" type="codebaseTypes" default="JAVA"/>
<xsd:element name="codeLocation" type="xsd:string" minOccurs="1"/>
<xsd:element name="codeProperties" type="properties" minOccurs="0"/>
<xsd:element name="idlLocation" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
884
885
886
887
888
889
890
891
It provides the elements needed to define an unambiguous reference to the executable
software that implements the control object’s application logic, such that the interoperability
framework runtime system can invoke the executable software . The intention is that any type
of executable environment can be referenced, such as C runtime code , Java code, rules
engines, etc. The interoperability framework implementation would need to include
appropriate language bindings for whatever runtime environments are supported (for example,
the implementation might need to use the correct stack structures for invoking C executable
modules in memory).
892
893
894
The codeLocation element would typically be a Uniform Resource Locator (URL) reference to
the executable logic. This could be a dynamically referenced library routine or other type of
runtime code reference.
895
896
897
898
The idlLocation element can be used to reference an optional Interface Description Language
(IDL) description if needed as part of the implementation. This would typically be used to
provide additional details required by the implementation to support language binding
mismatches.
899
The properties section of the schema is comprised of one or more property elements:
900
901
902
903
904
905
<xsd:element name="property">
<xsd:complexType>
<xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="value" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
906
907
908
It can be used to to define properties that apply to the control object in general, rather than to
individual input or output events. A property element consists of a name/value pair. This could
include configuration parameters, calibration information, version tags, etc.
909
8.2.3
910
911
Sensor objects are based on the commons section, but only have definitions of the outputs,
codeBase, and properties components of the commons.
912
8.2.4
913
914
Actuator objects are based on the commons section, but only have definitions of the inputs,
codeBase, and properties components of the commons.
915
8.3
916
917
918
919
920
The purpose of the data type primitives in this International Standard is to support
implementation-level interoperability across dissimilar automation systems that are compatible
at a semantic level. In other words, to support interoperability of systems that perform the
same application functions, but which are implemented differently in ter ms of communication
mechanisms, data description methods, and other syntactic details.
921
922
923
924
925
926
The key requirement is that each property unit type listed in 7.4.5: Property unit type
primitives must map unambiguously to a single data type primitive in 7.4.4: Property data type
primitives. This provides an unambiguous mapping to the underlying execution environment
(for example, a C language environment), and allows unambiguous conversion between
property unit types in different automation systems (for example, one system may have a
temperature sensor that outputs Fahrenheit degrees in floating point representation in C, but
81894646
25
Sensor objects
Actuator objects
Data type primitives
ISO/IEC CD 18012-2  IEC:2008
26
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
927
928
it may need to interoperate with a control object that expects a Celsius degree input in integer
representation in Java).
929
930
931
932
933
934
935
936
The baseTypes schema in Annex B.2: Base Types defines the property unit type primitives.
Using these physical property unit type primitives, any physical unit can be derived (Annex
C.1: Derived Types (examples) contains examples of such derivative definitions). Because an
implementation of this International Standard must have an unambiguous mapping from each
unit type primitive (i.e., Base Type) to a single data type primitive in the underlying
implementation programming language (e.g., integer32), the runtime representation for all unit
types (base or derived) is well-defined, and can therefore support automatic conversion
between unit type variations (such as between Fahrenheit and Celsius).
937
9
938
9.1
939
940
941
942
The binding map defines the event input/output connections between the sensor, ac tuator,
and control object input and output events of an application. A binding between two
application objects will name the two objects involved, and also the specific input and output
events that are being connected.
943
An example of a portion of a Binding Map is
944
945
946
947
948
949
950
951
952
953
954
955
956
957
…
958
959
960
961
In this example, output o1 from control object cm02 is bound to input i1 of control object cm01
in the first clause. The next clause binds output o1 of control object cm05 to input i1 of
actuator object am01, and finally the last clause binds outputs o1 and o2 of sensor object
sm02 to inputs i1 and i2 of control object cm06, repectively.
962
963
964
965
966
967
968
969
970
971
972
973
As shown in this example section, it is the individual input and output events that are being
bound together over the event bus, and not the sensor, actuator, and control objects. In other
words, the binding is at the individual input/output event granularity, and not at the object
granularity. This provides a great deal of detail to the interoperability runtime implementation,
allowing such optimisations as dynamic message payload construction on the event bus
communication links between interoperability domain interfaces (IDIs). Depending on the
specific subset of events that need to move from one IDI to another across the event bus, the
interoperability framework runtime implementation can assemble message payloads that
include all the events that must be transported across the event b us to another device
implementing the interoperability domain at a specific point in time (rather than transporting
all output events from a sensor, actuator, or control object across the event bus
communication links).
Application binding map schema
Overview
<binding source="cm02" target="cm01">
<iomapping from="o1" to="i1"/>
</binding>
<binding source="cm05" target="am01">
<iomapping from="o1" to="i1"/>
</binding>
<binding source="sm02" target="cm06">
<iomapping from="o1" to="i1"/>
<iomapping from="o2" to="i2"/>
</binding>
…
81894646
26
ISO/IEC CD 18012-2  IEC:2008
27
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Annex A
(informative)
974
975
976
977
An interoperability application specification example
978
A.1
Lighting application
979
980
NOTE: This example has been prepared by Dr. Young-Sung Son of Korea, and will be
inserted when complete.
981
982
This example is taken from ISO/IEC/TR 15067-2 Information technology - Home Electronic
Systems (HES) application model - Part 2: Lighting model for HES.
983
A.2
984
985
986
987
988
The procedure followed in this example consists in the definition of a generic lighting
subsystem application model (simple case). The components of the system are installed on
two different network systems (LonWorks) and System B (UPnP). The components of the
framework are exemplified in (a) logical interoperable system, (b) respective functional/device
profiles in each system, and (c) examples of the IWFs for each case.
Procedure
Interoperability Domain
Lighting Application
Object
1
Object
2
event/data logical bus
Standardized event passing
interface for “Interworking
functions”
LonWorks IWF
UPnP IWF
Object 1
LightSwtich
LonWorks
LightSwtich
Object 2
LightLamp
UPnP Light
LonWorks Network
UPnP Network
989
Figure A.1 – Lighting application
990
991
992
A.3
Generic lighting subsystem application model
993
A.3.1
994
995
The examples will include partial XML schemas for the individual components, and exemplify
the interoperability lexicon as outlined in this document.
996
A.3.1.1
997
998
LightSwitch object represents a switch device that includes a functional object, BinarySwitch.
BinarySwitch object has two operational objects, SetSwitchValue and GetSwitchValue.
Functional classes
LightSwitch
<function>
81894646
27
ISO/IEC CD 18012-2  IEC:2008
28
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
<functionType>BinarySwitch</functionType>
<actionList>
<action>
<actionId>SetSwitchValue</actionId>
<parameterList>
<parameter>
<parameterId>SwitchValue</parameterId>
<dataType>boolean</dataType>
<direction>in</direction>
</parameter>
</parameterList>
</action>
<action>
<actionId>GetSwitchValue</actionId>
<parameterList>
<parameter>
<parameterId>SwitchValue</parameterId>
<dataType>boolean</dataType>
<direction>out</direction>
</parameter>
</parameterList>
</action>
<actionList>
<eventList>
<event>
<eventId>SwitchValue</eventId>
<dataType>boolean</dataType>
</event>
</eventList>
</function>
Figure A.2 – LightSwitch Object
999
1000
81894646
28
ISO/IEC CD 18012-2  IEC:2008
29
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
1001
A.3.1.2
LightLamp
1002
1003
LightLamp object represents a lamp device that includes a functional object, PowerSwitch.
PowerSwitch object has two operational objects, SetSwitchValue and GetSwitchValue.
<function>
<functionType>PowerSwitch</functionType>
<actionList>
<action>
<actionId>SetSwitchValue</actionId>
<parameterList>
<parameter>
<parameterId>SwitchValue</parameterId>
<dataType>boolean</dataType>
<direction>in</direction>
</parameter>
</parameterList>
</action>
<action>
<actionId>GetSwitchValue</actionId>
<parameterList>
<parameter>
<parameterId>SwitchValue</parameterId>
<dataType>boolean</dataType>
<direction>out</direction>
</parameter>
</parameterList>
</action>
<actionList>
<eventList>
<event>
<eventId>SwitchValue</eventId>
<dataType>boolean</dataType>
</event>
</eventList>
81894646
29
ISO/IEC CD 18012-2  IEC:2008
30
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
</function>
Figure A.3 – LightLamp Object
1004
1005
1006
A.4
LonWorks
1007
A.4.1
1008
1009
1010
1011
LonWorks LightSwitch device has Switch Object type 3200 that include 4 SNVT (Standard
Network Variable Type). Especially, nviLampValue and nvoLampValueFb are SNVT_switch as
Mandatory Network Variables. nvoRunHours and nvoEnergyCnt are Optional Network
Variables and not used for interoperable application.
LonWorks: LightSwitch functional profile
S witch Object
ty pe 3200
n viLampValue
S NVT_switch
M a ndatory
Ne twork Variables
Optional
Ne twork Variables
n voLampValueFb
S NVT_switch
n voR unHours
S NVT_elapsed_tm
n voEnergyCnt
S NVT_elec_kwh
Con figuration
P r operties
1012
Figure A.4 – LonWorks LightSwitch Device (Switch Object 3200)
1013
1014
LonWorks  LonWorks-IOP interworking function
1015
A.4.2
1016
1017
1018
1019
1020
1021
The interworking function system has several functions. IOP system also translates control
messages because a device in a middleware network understands only its middleware dependent message. The IOP system translates the control message to an standard lighting
application model event flow between two different middleware networks from the point of
view of the message translation. The message translation between the LonWorks application
interface and the standard lighting applicatio n model interface is done in the IWF.
1022
1023
1024
1025
1026
LonWorks IOP system has two middleware stacks as LonWorks PLC middleware and IOP
middleware. LonWorks PLC middleware built on LonTalk manages network variables. In order
to control LonWorks Devices, LonWorks PLC middle ware generate network variables
dynamically. IOP middleware communicates the interoperable system with standard lighting
application model event passing on the event bus .
81894646
30
ISO/IEC CD 18012-2  IEC:2008
31
binding
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
IWF
Interoperable System
IWF
Dynamic NV
ge nerator
Global Dispatcher
Device
Manager
Application
Func tion
Ma pper
Event
Handler
Interoperable System
Event DB
Local Dispatcher
Local Middle ware Ne twork Manage me nt
NM layer
NM layer
TCP/IP
LonTalk
Ethernet
Lig hting Application
or
LonTalk
Lo n
Switch
De vice
1027
NM
transaction
PLC
Interoperable
Protocol
System A - Lo nWorks
IP ne twork
Figure A.5 – LonWorks InterWorking Function System
1028
1029
1030
1031
1032
1033
The following picture describes how to map LonWorks device function to the generic device
object. Switch object type 3200’s mandatory network variables are mapped to the generic
device objects. nviLampValue SNVT_switch is translated to SetSwitchValue and
nvoLampValueFb SNVT_switch is mapped to GetSwitchValue.
S witch Object
ty pe 3200
n viLampValue
S NVT_switch
M a ndatory
Ne twork Variables
Optional
Ne twork Variables
n voLampValueFb
S NVT_switch
n voR unHours
S NVT_elapsed_tm
n voEnergyCnt
S NVT_elec_kwh
Con figuration
P r operties
<function>
<functionType>BinarySwitch</functionType>
<actionList>
<action>
<actionId>SetSwitchValue</actionId>
<parameterList>
<parameter>
<parameterId>SwitchValue</parameterId>
<dataType>boolean</dataType>
<direction>in</direction>
</parameter>
</parameterList>
</action>
<action>
<actionId>GetSwitchValue</actionId>
<parameterList>
<parameter>
<parameterId>SwitchValue</parameterId>
<dataType>boolean</dataType>
<direction>out</direction>
</parameter>
</parameterList>
</action>
<actionList>
<eventList>
<event>
<eventId>SwitchValue</eventId>
<dataType>boolean</dataType>
</event>
</eventList>
</function>
1034
1035
Figure A.6 – Functional Mapping LonWorks LightSwitch Device to the Generic LightSwitch
1036
1037
1038
1039
1040
1041
1042
For these mapping, the predefined function mapping table is used. LonWorks function
mapping table consists of Device Mapping Table, Function Mapping Table, Action/Event
Mapping Table, Parameter Mapping Table. Each Table has two columns, global valu e for
generic object and local value for LonWork device information. Whenever LonWorks devices
are configured by LonTalk, LonWorks InterWorking Function System searches this function
mapping table and recompose the generic object.
81894646
31
ISO/IEC CD 18012-2  IEC:2008
32
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Property
Field Semantic
Example
Index
Generic Device index
0
Virtual/Physical
GD or Local Physical Device
Local
GID
Global Generic Device ID
LonWorks, NID
NID
Local (Middleware) ID
0x112233445566
GDType
Device Type of GD
LIGHTSWITCH
LDType
Device Type of Local
0x05 0x01
Local address
LonWare DB index
1
Function List
Available Function List
Action List
Available Action List
De vice Map. Tbl.
Function Map. Tbl.
Device Mapping
Data Structure
Action
List
F1
F2,…
…
Action/Event Map. Tbl.
Global
Local
Global
Local
Global
LIGHTSW
0x05 0x01
LIGHTSW
1
Update_NV, NV_idx
Router
0x01 0x01
DIMMING
2
SetSwitch
Value
…
…
…
…
Dimming
Update_NV, NV_idx
…
…
Local
Parameter Map. Tbl.
Global
Local
SWITCH_ON
200,1
SWITCH_OFF
0,0
…
…
Function Mapper
1043
Figure A.7 – LonWorks Function Mapping Table
1044
1045
1046
1047
A.5
UPnP
1048
A.5.1
1049
1050
This is a description of UPnP LightLamp device. UPnP LightLamp is described as a
BinaryLight service that includes a DimmingService and SwitchPower.
UPnP: LightLamp functional profile
<?xml version="1.0" encoding="utf-8" ?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:schemas-upnp-org:device:BinaryLight:1</deviceType>
<friendlyName>Light (UPnP)</friendlyName>
<manufacturer>Intel Corporation</manufacturer>
<manufacturerURL>http://www.intel.com</manufacturerURL>
81894646
32
ISO/IEC CD 18012-2  IEC:2008
33
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
<modelDescription>Software Emulated Light Bulb</modelDescription>
<modelName>Intel CLR Emulated Light Bulb</modelName>
<modelNumber>XPC-L1</modelNumber>
<modelURL>http://www.intel.com/xpc</modelURL>
<UDN>uuid:55f52e1b-62a7-4e23-841b-283bca65a3fb</UDN>
<serviceList>
<service>
<serviceType>urn:schemas-upnporg:service:DimmingService:1</serviceType>
<serviceId>urn:upnp-org:serviceId:DimmingService.0001</serviceId>
<SCPDURL>_DimmingService.0001_scpd.xml</SCPDURL>
<controlURL>_DimmingService.0001_control</controlURL>
<eventSubURL>_DimmingService.0001_event</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:SwitchPower:1</serviceType>
<serviceId>urn:upnp-org:serviceId:SwitchPower.0001</serviceId>
<SCPDURL>_SwitchPower.0001_scpd.xml</SCPDURL>
<controlURL>_SwitchPower.0001_control</controlURL>
<eventSubURL>_SwitchPower.0001_event</eventSubURL>
</service>
</serviceList>
</device>
</root>
Figure A.8 – UPnP LightLamp Device
1051
1052
UPnP  UPnP-IOP interworking function
1053
A.5.2
1054
1055
1056
1057
UPnP IOP system has two middleware stacks, UPnP middleware and IOP middleware, on top
of TCP/IP. UPnP middleware built on SSDP/GENA/SOAP manages generic control point.
Through generic control point, UPnP middleware can control UPnP device. IOP middleware
communicates the interoperable system with interoperable protocols.
1058
81894646
33
ISO/IEC CD 18012-2  IEC:2008
34
Ge neric
Co ntrol Point
Application
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
IWF
Interoperable System
IWF
Global Dispatcher
Device
Manager
Function
Mapper
Event
Handler
Event DB
SSDP/GENA/SOAP
SSDP/GENA/SOAP
Interoperable System
Local Dispatcher
Local Middleware Network Management
TCP/IP
TCP/IP
SSDP
GENA
SOAP
Ethernet
UPnP
Light
De vice
1059
Ethernet
UPnP
Protocol
IP ne twork
Lig hting Application
Interoperable
Protocol
System B - UPnP
IP ne twork
Figure A.9 – UPnP InterWorking Function System
1060
1061
1062
1063
1064
1065
The following picture describes how to map a UPnP device description to the generic device
object. Light(UPnP) device has two services, DimmingServic:1 and Switc hPower:1. But,
SwitchPower is mapped to SetSwitchValue and GetSwitchValue of the generic LightLamp
object.
<?xml version="1.0" encoding="utf-8" ?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:schemas-upnp-org:device:BinaryLight:1</deviceType>
<friendlyName>Light (UPnP)</friendlyName>
<manufacturer>Intel Corporation</manufacturer>
<manufacturerURL>http://www.intel.com</manufacturerURL>
<modelDescription>Software Emulated Light Bulb</modelDescription>
<modelName>Intel CLR Emulated Light Bulb</modelName>
<modelNumber>XPC-L1</modelNumber>
<modelURL>http://www.intel.com/xpc</modelURL>
<UDN>uuid:55f52e1b-62a7-4e23-841b-283bca65a3fb </UDN>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:DimmingService:1</serviceType>
<serviceId>urn:upnp-org:serviceId:DimmingService.0001</serviceId>
<SCPDURL>_DimmingService.0001_scpd.xml</SCPDURL>
<controlURL>_DimmingService.0001_control</controlURL>
<eventSubURL>_DimmingService.0001_event</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:SwitchPower:1</serviceType>
<serviceId>urn:upnp-org:serviceId:SwitchPower.0001</serviceId>
<SCPDURL>_SwitchPower.0001_scpd.xml</SCPDURL>
<controlURL>_SwitchPower.0001_control</controlURL>
<eventSubURL>_SwitchPower.0001_event</eventSubURL>
</service>
</serviceList>
</device>
</root>
<function>
<functionType>PowerSwitch</functionType>
<actionList>
<action>
<actionId>SetSwitchValue</actionId>
<parameterList>
<parameter>
<parameterId>SwitchValue</parameterId>
<dataType>boolean</dataType>
<direction>in</direction>
</parameter>
</parameterList>
</action>
<action>
<actionId>GetSwitchValue</actionId>
<parameterList>
<parameter>
<parameterId>SwitchValue</parameterId>
<dataType>boolean</dataType>
<direction>out</direction>
</parameter>
</parameterList>
</action>
<actionList>
<eventList>
<event>
<eventId>SwitchValue</eventId>
<dataType>boolean</dataType>
</event>
</eventList>
</function>
1066
1067
Figure A.10 – Functional Mapping UPnP LightLamp Device to the Generic LightLamp
1068
1069
1070
1071
1072
1073
UPnP function mapping table consists of Device Mapping Table, Function Mapping Table,
Action/Event Mapping Table, Parameter Mapping Table. Each Table has two columns, global
value for generic object and local value for UPnP device information. Whenever UPnP devices
are detected by SSDP, UPnP InterWorking Function System searches this function mapping
table and recompose the generic object.
81894646
34
ISO/IEC CD 18012-2  IEC:2008
35
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Property
Field Semantic
Example
Index
Generic Device index
0
Virtual/Physical
GD or Local Physical Device
Local
GID
Global ID
UPnP, NID
LID
Local (Middleware) ID
uuid:55f52e1b
GDType
Device Type of GD
LIGHT
LDType
Device Type of Local
Light
Local address
Device Description
http://xxx.xx.x.x/light.xml
Service List
Service Table List
Action List
Action Table List
De vice Map. Tbl.
Function Map. Tbl.
Global
Local
LIGHT
uuid::sche…
MS
uuid::….
DIMMING
…
…
…
Global
Local
Device Mapping
Data Structure
Action
List
F1
F2,…
…
Action/Event Map. Tbl.
Parameter Map. Tbl.
Global
Local
Global
Local
Power
settarget…
SWITCH_ON
1
uuid
Dimming
xxaction…
SWITCH_OFF
0
…
…
…
…
…
SwitchPower uuid
Function Mapper
1074
Figure A.11 – UPnP Function Mapping Table
1075
1076
1077
Interoperable System – Functional Model
1078
A.6
1079
1080
1081
1082
1083
1084
1085
1086
1087
Interoperable system has three tables, D evice Table, BindMap Table, EventBus Table. Device
Table contains the information of generic device objects. These objects are registered by
each IWF system through IOP protocols. BindMap Table is related to interoperable
applications. Each interoperable application registers binding of two or more generic objects.
Binding means connection from an output set of events in an operational object to an input set
of events in an operational object. EventBus Table is used for managing event processing.
Whenever device change its status, IWF system catches its behaviour and causes an event to
EventBus Table of Interoperable System. In order to serialize multiple event process ing,
Interoperable system uses EventQueue with FIFO style.
1088
81894646
35
ISO/IEC CD 18012-2  IEC:2008
36
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Device Table
Interoperable System
GD#
Object ID
Generic Device Type
Device Object Action (out)
0
UPnP::LightLamp0
LightLamp
Device Object Action (in)
1
LonWorks::LightSwitch0
LightSwitch
Bind Map Table
Bind Map Manager
Lighting Application(101)
LightLamp
Object(0)
Lighting
Controller
Object(3)
LightSwitch
Object(1)
Appl#
Controller Obj#
Generic Device Obj#
101
3
0, 1
…
Event Bus Table
Event Bus Manager
Obj#
out action
Obj#
in action
1
LightSwitch.
GetSwitchValue1
3
LightingController.
SetSwitchValue1
3
LightingController.
GetSwitchValue1
0
LightLamp.
SetSwitchValue1
Event Queue
35
…
Event Queue
UPnP Light
Event#
Source
Obj#
Destination
Obj#
Type
Value
35
1
0
LightSwitch.GetSwitchValue.
SwtichValue,
On
LonWorks LightSwitch
…
1089
Figure A.12 – Interoperable System Working Flow
1090
1091
81894646
36
ISO/IEC CD 18012-2  IEC:2008
37
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Annex B
(normative)
1092
1093
1094
1095
Base Object Schema Definitions
1096
B.1
Commons
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://<namespace URL>"
xmlns="http://<namespace URL>" elementFormDefault="qualified">
<xsd:include schemaLocation="baseTypes.xsd"/>
<xsd:include schemaLocation="derivedTypes.xsd"/>
<xsd:include schemaLocation="baseDefinition.xsd"/>
<!-- Define 'Inputs' element type used by other schema such ControlModel -->
<xsd:element name="QoIRequirement">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="frequency" minOccurs="0">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="Frequency">
<xsd:attribute name="selector" type="LogicExpression"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="maxUncertainty" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="dataPricesion" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="dataAccuracy" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="low" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="high" type="xsd:decimal" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="QoI">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="frequency" minOccurs="0">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="Frequency">
<xsd:attribute name="selector" type="LogicExpression"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="maxUncertainty" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="dataPricesion" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="dataAccuracy" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="low" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="high" type="xsd:decimal" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="input">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="dataPoint"/>
<xsd:element ref="QoIRequirement" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
81894646
37
ISO/IEC CD 18012-2  IEC:2008
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
38
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
<xsd:element name="output">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="dataPoint"/>
<xsd:element ref="QoI" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="inputs">
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="input"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="outputs">
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="output"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="property">
<xsd:complexType>
<xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="value" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="properties">
<xsd:sequence>
<xsd:element ref="property" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="codeBase">
<xsd:sequence>
<xsd:element name="description" type="xsd:string" minOccurs="0"/>
<xsd:element name="codeType" type="codebaseTypes" default="JAVA"/>
<xsd:element name="codeLocation" type="xsd:string" minOccurs="1"/>
<xsd:element name="codeProperties" type="properties" minOccurs="0"/>
<xsd:element name="idlLocation" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
1203
B.2
Base Types
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema elementFormDefault="qualified"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://<namespace URL>"
targetNamespace="http://<namespace URL>">
<xsd:include schemaLocation="baseDefinition.xsd"/>
<!-- 7 SI Base Quantities -->
<xsd:complexType name="Length">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="meter"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Time">
81894646
38
ISO/IEC CD 18012-2  IEC:2008
39
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
</xsd:schema>
1271
B.3
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema elementFormDefault="qualified"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://<namespace URL>"
targetNamespace="http://<namespace URL>">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="second"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Mass">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="kg"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Temperature">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="kelvin" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ElectricCurrent">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="ampere"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="SubstanceAmount">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="mole"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="LuminousIntensity">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="candela"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Base Definitions
<xsd:simpleType name="LogicExpression">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="EQT"/>
<xsd:enumeration value="GTT"/>
<xsd:enumeration value="GTE"/>
<xsd:enumeration value="LTT"/>
<xsd:enumeration value="LTE"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="dataType">
81894646
39
ISO/IEC CD 18012-2  IEC:2008
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
40
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
<xsd:simpleContent>
<xsd:extension base="xsd:anySimpleType">
<xsd:attribute name="dataType" type="defined_data_types"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:simpleType name="codebaseTypes">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="C++"/>
<xsd:enumeration value="JAVA"/>
<xsd:enumeration value="XSL"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SIUnit">
<xsd:restriction base="xsd:string">
<xsd:pattern value="((\([0-3]\))(\((\-)?\d{1}(/\d{1})?\)){9})|((\([4-9]\))(\(0\)){9})"/>
<!-field #1 : emumeration
0= unit is described by filed #2-#10
1= unit is U/U where U is described by filed #2 -10
2= unit is log10(U) where U is described by filed #2-10
3= unit is log10(U/U) where U is described by filed #2 -10
4= unit is digital data, field #2-10 must be zero
5= arbitrary scale, field #2-10 must be zero
6-9= reserved
field
field
field
field
field
field
field
field
field
#2 : radian
#3 : steradian
#4 : meter
#5 : kilogram
#6 : second
#7 : ampere
#8 : kelvin
#9 : mole
#10: candela
- angle
- solid angle
- length
- mass
- time
- electric current
- temperature
- amount of substance
- luminous intensity
-->
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="SIUnit" type="SIUnit"/>
<xsd:simpleType name="defined_data_types">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="FLOAT"/>
<xsd:enumeration value="INT"/>
<xsd:enumeration value="BOOLEAN"/>
<xsd:enumeration value="STRING"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SIMultiple">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="exa"/>
<xsd:enumeration value="peta"/>
<xsd:enumeration value="tera"/>
<xsd:enumeration value="giga"/>
<xsd:enumeration value="mega"/>
<xsd:enumeration value="kilo"/>
<xsd:enumeration value="hecto"/>
<xsd:enumeration value="deka"/>
<xsd:enumeration value="deci"/>
<xsd:enumeration value="centi"/>
<xsd:enumeration value="milli"/>
<xsd:enumeration value="micro"/>
<xsd:enumeration value="nano"/>
<xsd:enumeration value="pico"/>
<xsd:enumeration value="femto"/>
81894646
40
ISO/IEC CD 18012-2  IEC:2008
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
41
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
<xsd:enumeration value="atto"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="Multiple">
<xsd:restriction base="xsd:float"/>
</xsd:simpleType>
<xsd:complexType name="DataValue">
<xsd:simpleContent>
<xsd:extension base="xsd:anySimpleType"/>
</xsd:simpleContent>
</xsd:complexType>
<xsd:element name="dataValue" type="DataValue"/>
<xsd:complexType name="DataVector">
<xsd:sequence>
<xsd:element name="vlaue" minOccurs="2" maxOccurs="unbounded">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:anySimpleType">
<xsd:attribute name="id" type="xsd:long"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="dataVector" type="DataVector">
<xsd:unique name="onDataValuePerID">
<xsd:selector xpath="dataVector/vlaue"/>
<xsd:field xpath="@id"/>
</xsd:unique>
</xsd:element>
<xsd:complexType name="DataUncertainty">
<xsd:simpleContent>
<xsd:extension base="xsd:float">
<xsd:attribute name="interpretation" use="optional">
<xsd:simpleType>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="ISO_GUIDE"/>
<xsd:enumeration value="CUSTOMER"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="coverageFactor" type="xsd:float" use="optional"/>
<xsd:attribute name="customerFactor" type="xsd:float" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="DataPoint" abstract="true">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="name" type="xsd:Name" use="optional"/>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attribute name="isVector" type="xsd:boolean" use="optional" default="false"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:element name="dataPoint" type="DataPoint"/>
<xsd:complexType name="PhysicalDataPoint">
<xsd:simpleContent>
<xsd:extension base="DataPoint">
<xsd:attribute name="siunit" type="SIUnit" use="required"/>
81894646
41
ISO/IEC CD 18012-2  IEC:2008
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
42
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!-- Define build-in datatype array,
currently, they are not used anywhere -->
<xsd:simpleType name="DecimalArray">
<xsd:list itemType="xsd:decimal"/>
</xsd:simpleType>
<xsd:simpleType name="IntegerArray">
<xsd:list itemType="xsd:integer"/>
</xsd:simpleType>
<xsd:simpleType name="ShortArray">
<xsd:list itemType="xsd:short"/>
</xsd:simpleType>
<xsd:simpleType name="ByteArray">
<xsd:list itemType="xsd:byte"/>
</xsd:simpleType>
<xsd:simpleType name="LongArray">
<xsd:list itemType="xsd:long"/>
</xsd:simpleType>
<xsd:simpleType name="FloatArray">
<xsd:list itemType="xsd:float"/>
</xsd:simpleType>
<xsd:simpleType name="DoubleArray">
<xsd:list itemType="xsd:double"/>
</xsd:simpleType>
<xsd:complexType name="LogicDataPoint" abstract="true">
<xsd:complexContent>
<xsd:extension base="DataPoint"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="logicDataPoint" type="LogicDataPoint"/>
<xsd:complexType name="String">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
<xsd:element name="value" type="xsd:string" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Boolean">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
<xsd:element name="value" type="xsd:boolean" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Decimal">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
81894646
42
ISO/IEC CD 18012-2  IEC:2008
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
43
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
<xsd:element name="value" type="xsd:decimal" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Integer">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
<xsd:element name="value" type="xsd:integer" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Int">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
<xsd:element name="value" type="xsd:int" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Long">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
<xsd:element name="value" type="xsd:long" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Short">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
<xsd:element name="value" type="xsd:short" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Byte">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
<xsd:element name="value" type="xsd:byte" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Float">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
81894646
43
ISO/IEC CD 18012-2  IEC:2008
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
44
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
<xsd:element name="value" type="xsd:float" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Double">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
<xsd:element name="value" type="xsd:double" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="AnyURI">
<xsd:complexContent>
<xsd:extension base="LogicDataPoint">
<xsd:sequence>
<xsd:element name="value" type="xsd:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="DigitalPoint">
<xsd:complexContent>
<xsd:extension base="PhysicalDataPoint">
<xsd:sequence>
<xsd:element name="probability" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0"/>
<xsd:maxInclusive value="1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="value" type="xsd:boolean" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="digitalPoint" type="DigitalPoint"/>
<xsd:complexType name="AnalogPoint">
<xsd:complexContent>
<xsd:extension base="PhysicalDataPoint">
<xsd:sequence>
<xsd:element name="uncertainty" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="value" type="xsd:float" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="unitMultiple" use="optional">
<xsd:simpleType>
<xsd:union>
<xsd:simpleType>
<xsd:restriction base="SIMultiple"/>
</xsd:simpleType>
<xsd:simpleType>
<xsd:restriction base="Multiple"/>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
</xsd:attribute>
81894646
44
ISO/IEC CD 18012-2  IEC:2008
45
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
1628
1629
1630
1631
1632
1633
</xsd:schema>
1634
B.4
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://<namespace URL>"
targetNamespace="http://<namespace URL>">
<xsd:include schemaLocation="commons.xsd"/>
<xsd:include schemaLocation="derivedTypes.xsd"/>
<xsd:include schemaLocation="industryTypes.xsd"/>
1660
B.5
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://<namespace URL>"
targetNamespace="http://<namespace URL>">
<xsd:include schemaLocation="commons.xsd"/>
<xsd:include schemaLocation="derivedTypes.xsd"/>
<xsd:include schemaLocation="industryTypes.xsd"/>
1686
B.6
1687
1688
1689
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema elementFormDefault="qualified"
attributeFormDefault="unqualified"
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="AnalogPoint" type="AnalogPoint"/>
Control Objects
<xsd:element name="controlModel">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="category" type="xsd:string" minOccurs="0"/>
<xsd:element name="inputs" type="inputs" maxOccurs="unbounded"/>
<xsd:element name="outputs" type="outputs" maxOccurs="unbounded"/>
<xsd:element name="modelProperties" type="properties" minOccurs="0"/>
<xsd:element name="codeBase" type="codeBase"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:Name"/>
<xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Sensor Objects
<xsd:element name="sensorModel">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="category" type="xsd:string" minOccurs="0"/>
<xsd:element name="inputs" type="inputs" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="outputs" type="outputs" maxOccurs="unbounded"/>
<xsd:element name="modelProperties" type="properties" minOccurs="0"/>
<xsd:element name="codeBase" type="codeBase"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:Name"/>
<xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Actuator Objects
81894646
45
ISO/IEC CD 18012-2  IEC:2008
46
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
</xsd:schema>
1712
B.7
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://<namespace URL>"
targetNamespace="http://<namespace URL>">
<xsd:include schemaLocation="commons.xsd"/>
<xsd:include schemaLocation="derivedTypes.xsd"/>
<xsd:include schemaLocation="industryTypes.xsd"/>
<xsd:element name="actuatorModel">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="category" type="xsd:string" minOccurs="0"/>
<xsd:element name="inputs" type="inputs" maxOccurs="unbounded"/>
<xsd:element name="outputs" type="outputs" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="modelProperties" type="properties" minOccurs="0"/>
<xsd:element name="codeBase" type="codeBase"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:Name"/>
<xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>
</xsd:element>
Application Binding Map
<xsd:element name = "application">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "models"/>
<xsd:element ref="connections"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="models">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="model" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name = "model">
<xsd:complexType>
<xsd:attribute name = "name" type = "xsd:string"/>
<xsd:attribute name = "type" type = "modelType" default = "CM"/>
<xsd:attribute name = "filename" type = "xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="connections">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="connection" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name = "connection">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "source" />
<xsd:element ref = "target"/>
81894646
46
ISO/IEC CD 18012-2  IEC:2008
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
47
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name = "source">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "map"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name = "target">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "map" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name = "map">
<xsd:complexType>
<xsd:attribute name = "id" type = "xsd:string"/>
<xsd:attribute name = "var" type = "xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:simpleType name="modelType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="CM"/>
<xsd:enumeration value="DA"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
81894646
47
ISO/IEC CD 18012-2  IEC:2008
48
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Annex C
(informative)
1791
1792
1793
1794
Base Object Schema Extension Examples
1795
C.1
Derived Types (examples)
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://<namespace URL>" targetNamespace="http://<namespace URL>">
<xsd:include schemaLocation="baseTypes.xsd"/>
<!-The purpose of this document is to define the derived da ta types
of iDACS XML Schema
-->
<!-- Some Mechnical Quantities -->
<xsd:complexType name="TranslationalSpeed">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="meter3-sec"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="AngularSpeed">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="rad-sec"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="FlowSpeed">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="meter3-sec"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Force">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="newton"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Pressure">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" default="pascal">
<xsd:simpleType>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="pascal"/>
<xsd:enumeration value="atomoshpere"/>
<xsd:enumeration value="bar"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Energy">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="joule"/>
</xsd:extension>
81894646
48
ISO/IEC CD 18012-2  IEC:2008
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
49
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="EnergyPower">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" default="watt">
<xsd:simpleType>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="watt"/>
<xsd:enumeration value="horse-power"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- Electric Quantitiy -->
<xsd:complexType name="ElectricVoltage">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="voltage"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ElectricResistance">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="ohm"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="MagneticFlux">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="weber"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- Others -->
<xsd:complexType name="Frequency">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="hertz"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- //Define some new digital datapoints-->
<xsd:complexType name="OnOff-State">
<xsd:complexContent>
<xsd:extension base="DigitalPoint"/>
</xsd:complexContent>
</xsd:complexType>
<!-- //Define some logicical datapoints-->
<xsd:complexType name="USZipCode">
<xsd:complexContent>
<xsd:restriction base="String">
<xsd:sequence>
<xsd:element name="value" minOccurs="0" maxOccurs="unbounded">
<xsd:simpleType>
81894646
49
ISO/IEC CD 18012-2  IEC:2008
50
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
</xsd:schema>
1966
C.2
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http:// <namespace URL>" targetNamespace="http:// <namespace URL>">
<xsd:include schemaLocation="baseTypes.xsd"/>
<xsd:include schemaLocation="derivedTypes.xsd"/>
<!-The purpose of this docuemnt is to provide space to allow data type to be defined
for application specific domain.
-->
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{5}"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="USPhoneNumber">
<xsd:complexContent>
<xsd:restriction base="String">
<xsd:sequence>
<xsd:element name="value" minOccurs="0" maxOccurs="unbounded">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{1}-\d{3}-\d{3}-\d{4}"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="USCurrency">
<xsd:complexContent>
<xsd:extension base="Decimal">
<xsd:attribute name="unit" default="dollar">
<xsd:simpleType>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="dollar"/>
<xsd:enumeration value="cent"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Industry-specific Types (examples)
<!-- A digital point that representing state of HVAC-Switch-->
<xsd:complexType name="HVAC-State">
<xsd:complexContent>
<xsd:extension base="DigitalPoint">
<xsd:attribute name="mode" default="auto" use="optional">
<xsd:simpleType>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="heat"/>
<xsd:enumeration value="cool"/>
<xsd:enumeration value="auto"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
81894646
50
ISO/IEC CD 18012-2  IEC:2008
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
51
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="RelativeHumidity">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit" fixed="percent"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Occupancy">
<xsd:complexContent>
<xsd:extension base="DigitalPoint"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Motor-Speed">
<xsd:complexContent>
<xsd:extension base="AnalogPoint">
<xsd:attribute name="unit">
<xsd:simpleType>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="rad-s"/>
<xsd:enumeration value="rpm"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="EnergyPrice">
<xsd:complexContent>
<xsd:extension base="Double">
<xsd:attribute name="unit" fixed="dolloars-per-mwh"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="FuelPrice">
<xsd:complexContent>
<xsd:extension base="Double">
<xsd:attribute name="unit" fixed="dolloars-per-gallon"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="RFID">
<xsd:complexContent>
<xsd:extension base="String">
<xsd:attribute name="standard">
<xsd:simpleType>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="epc"/>
<xsd:enumeration value="non-epc"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
81894646
51
ISO/IEC CD 18012-2  IEC:2008
52
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
Annex D
(informative)
2055
2056
2057
2058
Notes on interoperability
2059
D.1
General comments on the interoperability framework specification
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
This part defines the interoperability framework specification for describing distributed
automation systems. The taxonomy consists of the classification of the applications in a
framework that may be used, together with the lexicon, to instantiate an interoperable system
composed of components on the same or dissimilar networks. The lexicon is the set of
common data type primitives and the associated common action primitives tha t, within the
taxonomy framework, can be used to describe a set of application models. The interoperability
framework specification operates at the application layer of the OSI reference model. This
interoperability framework specification defines a common generic automation system
application framework to be used for syntactic translation while maintaining the semantics of
the application behaviour, independent of the implementation or mode of operation.
2070
D.2
2071
Application Domain::= SEQ of { Application Model }
2072
Application Model::= SEQ of { Functional Object, Operational Object }
2073
Functional Object ::= SEQ of { Operational Object, Functional Actions }
2074
Object ::= SEQ of { Basic Property, Operational Property, Configuration Property }
2075
2076
2077
Device Profile ::= A document description of the minimum a collection of Functional Class
instances that are implemented in a product to allow this product (physical device) to comply
with the functionality specified in the Application Model(s).
2078
D.3
2079
2080
The Table D.1 represents a mapping between different entity names into the interoperability
taxonomy framework.
2081
Table D.1 – Terminology mapping table
Taxonomy definitions
Taxonomy of the existing systems
LonWorks
CEBus
ISO/IEC 14543-3-x
EHS
ISO/IEC 18012-2
Network /
Configuration
Variable
Instance Variable
Property
Object (Object Type)
Property
Functional Block
Object
Object
Object
Object
Functional Profile
Context
Device
Device
Functional Class
(logical device)
?(Application Model)
? (Application Model
/ Group)
Application
Specification
Application Model
Application Model
Device Profile
Device Profile
Device Profile
Device Profile
Device Profile
2082
2083
2084
2085
2086
For example, the LonWorks Network Variable is no t strictly an object, according to the
definition adopted in this International Standard, as it does not exhibit behaviour. But it is the
equivalent of the EHS::Object because it is implicitly accessed at application level through
get/set actions, where allowed respectively by the access properties defined in the functional
profile for the variable.
2087
2088
Objects may have direction (in/out, producer/consumer - inherited through their properties),
access properties, an access list and notify list.
81894646
52
ISO/IEC CD 18012-2  IEC:2008
53
ISO/IEC JTC 1/SC 25/WG 1 N 1360
2008-12-17
2089
Bibliography
2090
2091
ISO/IEC 14543, Information technology — Home electronic system (HES) — Architecture (all
parts)
2092
2093
ISO/IEC 15045, Information technology — Home electronic system (HES) — HES Gateway
(all parts)
81894646
53