SC25 WG1 N1361 by mh6bF4

VIEWS: 2 PAGES: 63

									                                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:          Review and ballot
ACTION
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: walter@pattay.com
         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   Information technology –
4   Home electronic system (HES)
5

6   Guidelines for product interoperability –
7   Part 2: Taxonomy and Lexicon




8
9




    3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc              1
     ISO/IEC CD 18012-2  IEC:2008                                         2                ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                                 2008-12-17

10

11                                                              CONTENTS
12   Page

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 .............................................................................. 11
19         3.1 Terms and definitions ............................................................................................ 11
20         3.2 Abbreviated terms ................................................................................................. 13
21   4     Conformance requirements ............................................................................................. 14
22         4.1 Management ......................................................................................................... 14
23         4.2 Application interoperability model .......................................................................... 14
24         4.3 Software logic encapsulation ................................................................................. 15
25         4.4 Interaction with interworking functions (IWFs) ....................................................... 15
26         4.5 Multiple bindings for application object event inputs and outputs ........................... 15
27         4.6 Multiple binding maps per application object ......................................................... 15
28         4.7 Event timestamps .................................................................................................. 15
29         4.8 Temporal association of events ............................................................................. 15
30         4.9 Home electronic system application interoperability taxonomy ............................... 15
31         4.10 Object schema ...................................................................................................... 15
32         4.11 Application binding map schema ........................................................................... 15
33   5     Application interoperability model ................................................................................... 15
34   6     Interaction model ............................................................................................................ 17
35         6.1 Overview ............................................................................................................... 17
36         6.2 Application objects ................................................................................................ 17
37         6.3 Binding map .......................................................................................................... 18
38         6.4 Events ................................................................................................................... 18
39         6.5 Event bus .............................................................................................................. 19
40   7     Home electronic system application interoperability taxonomy ........................................ 20
41         7.1      Classification ......................................................................................................... 20
42         7.2      Application domain ................................................................................................ 21
43                  7.2.1 Definition ................................................................................................... 21
44                  7.2.2 Application domain list ............................................................................... 21
45         7.3      Functional object ................................................................................................... 22
46                  7.3.1 Definition ................................................................................................... 22
47                  7.3.2 Functional object structure ........................................................................ 22
48                  7.3.3 Functional action ....................................................................................... 22
49                  7.3.4 Functional object list .................................................................................. 23
50         7.4      Application Object ................................................................................................. 23
51                  7.4.1 Definition ................................................................................................... 23
52                  7.4.2 Application Object Structure ...................................................................... 23
53                  7.4.3 Property .................................................................................................... 23
54                  7.4.4 Property data type primitives ..................................................................... 24

     3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                                                   2
      ISO/IEC CD 18012-2  IEC:2008                                        3               ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                                2008-12-17
 55              7.4.5 Property unit type primitives ...................................................................... 24
 56              7.4.6 Property action primitives .......................................................................... 24
 57              7.4.7 Object types .............................................................................................. 24
 58   8     Object schema ............................................................................................................... 24
 59         8.1   Overview ............................................................................................................... 24
 60         8.2   Base objects ......................................................................................................... 25
 61               8.2.1 General ..................................................................................................... 25
 62               8.2.2 Control objects .......................................................................................... 25
 63               8.2.3 Sensor objects........................................................................................... 27
 64               8.2.4 Actuator objects ........................................................................................ 27
 65         8.3 Data type primitives ............................................................................................... 27
 66   9     Application binding map schema .................................................................................... 28
 67      9.1 Overview ............................................................................................................... 28
 68   Annex A (informative) An interoperability application specification example ......................... 31
 69         A.1     Lighting application ............................................................................................... 31
 70         A.2     Procedure ............................................................................................................. 31
 71         A.3     Generic lighting subsystem application model ....................................................... 31
 72                 A.3.1 Functional classes ..................................................................................... 31
 73         A.4     LonWorks .............................................................................................................. 34
 74                 A.4.1 LonWorks: LightSwitch functional profile .................................................... 34
 75                 A.4.2 LonWorks  LonWorks-IOP interworking function .................................. 34
 76         A.5     UPnP .................................................................................................................... 36
 77                 A.5.1 UPnP: LightLamp functional profile ............................................................ 36
 78                 A.5.2 UPnP  UPnP-IOP interworking function ............................................... 37
 79      A.6        Interoperable System – Functional Model .............................................................. 39
 80   Annex B      (normative) Base Object Schema Definitions ......................................................... 42
 81      B.1        Commons .............................................................................................................. 42
 82      B.2        Base Types ........................................................................................................... 43
 83      B.3        Base Definitions .................................................................................................... 44
 84      B.4        Control Objects ..................................................................................................... 54
 85      B.5        Sensor Objects ...................................................................................................... 54
 86      B.6        Actuator Objects .................................................................................................... 54
 87      B.7        Application Binding Map ........................................................................................ 55
 88   Annex C      (informative) Base Object Schema Extension Examples ........................................ 57
 89      C.1 Derived Types (examples) ..................................................................................... 57
 90      C.2 Industry-specific Types (examples) ....................................................................... 59
 91   Annex D (informative) Notes on interoperability ................................................................... 61
 92        D.1 General comments on the interoperability framework specification ........................ 61
 93        D.2 Taxonomy definitions ............................................................................................ 61
 94        D.3 Taxonomy of the existing systems ......................................................................... 61
 95   Bibliography .......................................................................................................................... 62
 96
 97                                                             List of table
 98   Table 1 – Application domain list .......................................................................................... 21
 99   Table 2 – Property structure ................................................................................................. 23
100   Table 3 – Property unit type primitives .................................................................................. 24
101   Table D.1 – Terminology mapping table ................................................................................ 61
      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                                                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 ......................................................................... 16
106   Figure 3 – Binding map example ........................................................................................... 18
107   Figure 4 – Event bus example ............................................................................................... 19
108   Figure 5 – Interoperable system taxonomy ............................................................................ 20
109   Figure 6 – Object schema structure ...................................................................................... 26
110   Figure A.1 – Lighting application ........................................................................................... 31
111   Figure A.2 – LightSwitch Object ............................................................................................ 32
112   Figure A.3 – LightLamp Object .............................................................................................. 34
113   Figure A.4 – LonWorks LightSwitch Device (Switch Object 3200) .......................................... 34
114   Figure A.5 – LonWorks InterWorking Function System .......................................................... 35
115   Figure A.6 – Functional Mapping LonWorks LightSwitch Device to the Generic
116   LightSwitch ........................................................................................................................... 35
117   Figure A.7 – LonWorks Function Mapping Table ................................................................... 36
118   Figure A.8 – UPnP LightLamp Device ................................................................................... 37
119   Figure A.9 – UPnP InterWorking Function System ................................................................ 38
120   Figure A.10 – Functional Mapping UPnP LightLamp Device to the Generic LightLamp .......... 38
121   Figure A.11 – UPnP Function Mapping Table ........................................................................ 39
122   Figure A.12 – Interoperable System Working Flow ................................................................ 40
123

124




      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                                                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   ISO (the International Organisation for Standardisation) and IEC (the International
127   Electrotechnical Commission) form the specialised system for world-wide standardisation.
128   National bodies that are members of ISO or IEC participate in the development of
129   International Standards through technical committees established by the respective
130   organisation to deal with particular fields of technical activity. ISO and IEC technical
131   committees collaborate in fields of mutual interest. Other international organisations,
132   governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.

133   In the field of information technology, ISO and IEC have established a joint technical
134   committee, ISO/IEC JTC 1. International Standards adopted by the joint technical committee
135   are circulated to national bodies for voting. Publication as an International Standard requires
136   approval by at least 75% of the national bodies casting a vote.

137   This part of ISO/IEC 18012 was prepared by Joint Technical Committee ISO/IEC JTC 1,
138   Information technology, Subcommittee SC 25, Interconnection of Information Technology
139   Equipment.

140   ISO/IEC 18012 consists of the following parts, under the general title Information technology
141   — Interconnection of information technology equipment — Home electronic system —
142   Guidelines for product interoperability:

143      Part 1: Introduction
144      Part 2: Taxonomy and Lexicon
145      Part 3: Application models
146




      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                     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   The widespread development of many national and regional home and building automation
149   specifications, some standard and some proprietary, necessitates a mechanism for
150   interoperability. Interoperability ensures that products from multiple manufacturers (potentially
151   implemented using different automation systems) can interwork. It is desirable that devices
152   needing to interwork do so seamlessly to provide users with a variety of integrated
153   applications without modification of their underlying protocols. Examples of such applications
154   include lighting control, environmental control, energy management, audio/video equipment
155   control, and home security.

156   This International Standard provides a descriptive mechanism at the application level, so that
157   there is a common way of describing applications in any underlying system, and an
158   unambiguous mapping to key implementation items (e.g., data type primitives) to allow for
159   transparent interoperability. Application-level interoperability can not be achieved without
160   being able to describe applications. The term “product interoperability” should be considered
161   synonymous with application-level interoperability, since products are developed to implement
162   applications - the value of products derives from their applications.

163   Work on this International Standard began with an in-depth review of the following existing
164   systems, to understand the various application, interaction, and implementation models in
165   use: CEBus, LonTalk, EIBKNX, EHS, UPnP, and EchoNet. From that analysis, key similarities
166   were identified between the various approaches and implementations. Those similarities are
167   primarily in the high-level application functions that are being implemented, with differences
168   appearing in the details of how the functions are represented. In short, there is a great deal of
169   semantic similarity between various automation system application functions, but significant
170   differences at the syntactic level.

171   That observation establishes the approach followed in this International Standard: to facilitate
172   interoperability, it is necessary to define an application model framework with the following
173   characteristics:

174      Allows a rich set of application semantics to be clearly described in a common format
175      Incorporates a simple but flexible interaction model abstraction that can represent all the
176       potential interactions of the various system implementations (command/response, shared
177       variable, message-oriented, etc.).
178      Establishes the minimal set of common data type primitives to support unambiguous
179       mapping of logical application data descriptions into implementation-specific binary
180       representations.
181   Interoperability in distributed application systems is defined as the ability of two or more
182   distributed components to communicate and cooperate in predictable ways despite
183   differences in implementation language, execution environment, or model abstractions. Three
184   main levels of interoperability between components in a distributed application can be
185   distinguished:

186      Protocol level, where the blocking conditions (synchronous or sequential constraints) are
187       defined.
188      Syntactic level, where the ordering between the exchanged messages and where the
189       names, interfaces, and operation of the components are defined.
190      Semantic level, where the meaning of the possible interactions between the components
191       in the distributed application system is defined. For example, application behaviour
192       caused by a change in state of the variables in the interacting components, or the system
193       at large.
194   With semantic level interoperability, clashes between two application components attempting
195   to cooperate are caused by differences in the lexicon (conceptual schemas) that describe the
196   components. Simply put, a mistranslation may occur between the two systems because of
197   incomplete shared information. The possible clashes can be classified into two main groups:


      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                       6
      ISO/IEC CD 18012-2  IEC:2008                       7           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                           2008-12-17
198           Lossless clashes, those that can be resolved with no loss of information. Some examples in
199              this category include component naming clashes, where the same component/information
200              is represented by different labels; structural clashes, where information elements are
201              grouped in different ways in different systems, and unit clashes, where some scalar value
202              (e.g. distance or temperature) is represented with different units of measure.
203           Lossy clashes, which include interoperability clashes for which any transformation available, in
204              either direction, causes loss in the information being communicated between the two
205              application components. These clashes are associated with differing levels of granularity,
206              refinement or precision of the representation of the information. Note that a lossy
207              translation between the two application components may be an acceptable solution,
208              provided that it achieves the desired application behaviour, and does not affect the
209              functional safety of the application, or the system as a whole. One example of a lossy
210              clash would be a light controller with a dimmer function. This controls a light actuator
211              (lamp); the light actuator understands only three levels of dimming, whilst the light
212              controller supports up to 8 different levels. Any interoperability mapping between these
213              two devices would require the mapping of the three levels recognised by the light
214              installation to three out of the eight levels of dimming supported by the light controller.
215   This International Standard is based on understanding the difference in the primitiveness of
216   actions at different levels of object definition (i.e., different levels of abstraction). Furthermore,
217   it is based on separation of the concept of action primitives from the actual implementation of
218   these primitives. For example, if objects (devices) in System-A use <get>/<put> functions to
219   implement local or remote reading and writing of variable values, these are not considered
220   “action primitives” in the context of this International Standard, but rather a programming
221   mechanism used to invoke the application actions. The different actions are caused by <put>-
222   ing (setting) the same variable to different values, which means that it is the variable and the
223   value that it contains at a given time that define the application action. This is captured later
224   on in thethis International Standard by eventing – objects (devices) notify each-other with the
225   values of their parameters, and each device (object) makes its decisions and takes actions
226   based on these values. During this processing each device may change these values;
227   changes should be notified to all the interested parties. These same actions can be invoked in
228   System-B by performing a (different) remote or local function call. In this case it is possible for
229   both systems to implement the same lexicon, but with their own invocation mechanism.

230   For example, one automation system might implement a shared variable space for
231   communication between devices and components. In a simple lighting control example, a user
232   might turn a wall switch on, causing a shared variable in the switch device on the network to
233   change from 0 (off) to 1 (on). A lighting controller component in the system might be
234   subscribed to that shared variable, causing the automation system to notify the lighting
235   controller of the change in the variable’s state. The controller could then take actions as
236   defined by the configuration and programming of the lighting control application.

237   In a complementary example, based on a command and control-based automation system,
238   the wall switch might cause an ON“on” command to be sent across the network in a message
239   to the lighting controller component, which would then react appropriately.

240   In both examples, the behaviour of the lighting control application is the same, but the method
241   used to implement it was quite different. This is an example of two systems having the same
242   semantics (meaning and behaviour), but different syntax (implementation and codification or
243   form).

244   The interoperable system is generic, and as such it should cater to different interactivity
245   models (as described in the example above). It is assumed that any adaptation necessary
246   from a system-specific interaction model to the eventing interaction adopted by the
247   interoperability model is included in the implementation of the interworking functions provided
248   by the manufacturers (or third party providers) interfacing into the interoperability model.

249   The interoperability model in this International Standard addresses the requirements of two
250   developer communities: the component developers (e.g., manufacturers), who develop
251   individual devices and part systems, and the solution developers (e.g., integrators or field
252   installers), who provide one (or more) applications that use services provided by the
253   components. The two communities overlap at least partially. For example, a company that
      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                              7
      ISO/IEC CD 18012-2  IEC:2008                   8           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                       2008-12-17
254   develops automation devices would typically provide Interworking Function (IWF)software
255   routines that link their productproducts to a specific application Object (objects, which could
256   be a standardized objectobjects published as part of an application model, or if could be
257   something the company defined and published themselves).. In the latter case the object
258   definition isdefinitions are considered to be standard only upon publication in a registry of
259   interoperable objects.

260   This document comprises the following sections:

261      Clauses 1 through 4 are the scope, normative references, terms and , definitions and
262       abbreviations, and conformance clauses respectively.
263      Clause 5 describes the application interoperability model.
264      Clause 6 describes the interaction model in terms of an asynchronous event-bus model.
265      Clause 7 describes the taxonomy used for inter-system and intra-system interoperability.
266      Clause 8 describes the object schema framework.
267      Clause 9 describes the application binding map schema framework.
268      Annex A outline recommended procedures for interoperable product specification.
269      Annex B describes an example of an interoperable application specification.
270      Annex C contains a discussion of issues related to establishing a metadata registry.
271      Annex D Annex B contains the base object schemas.
272      Annex EC contains base object schema extension examples.
273      Annex D contains miscellaneous notes on interoperability and related taxonomy terms.
274




      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                          8
      ISO/IEC CD 18012-2  IEC:2008                    9          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                       2008-12-17
275        Information technology — Interconnection of information technology
276       equipment — Home electronic System (HES) — Guidelines for product
277                  interoperability — Part 2: Taxonomy and Lexicon
278   1    Scope
279   This standardpart of ISO/IEC 18012 specifies an interoperability model and a taxonomy
280   frameworkand lexicon for productthe interoperability of products in the area of home and
281   building automationelectronic systems by classifying applications into Application Domains,
282   Application Functions, Application Functional Actions, and a lexicon in the form of a list of
283   Sensor, Actuator, and Control Objects, Input and Output Events and Event Types, and
284   Properties, Property Data Types and Property Action Primitives. It is also specifies an
285   interoperability framework to allow products from multiple manufacturers can work together to
286   provide a specific application. This standard is concerned with layers six (Presentation) and
287   seven (Application) of the OSI Reference Model, (ISO 7498), with sufficient detail needed to
288   designestablish interoperable home and building automation componentsapplications in this
289   domain. Layers one through five are not specified here;. The interoperability framework
290   defined here is independent of all layer 1 to layer 5 communication protocol stacks used in a
291   home electronic system (for an example of layers one through five see ISO/IEC 14543). A
292   minimal set of transport layer requirements regarding these layers areis specified in Part 1 of
293   this standard where needed to check whether the devices will be able to interoperate with one
294   anotherISO/IEC 18012-1.

295   This International Standard is applicable to:

296      StandaloneSingle implementation home and            building   automationelectronic   system
297       networks, connected devices and applications.
298      Multiple implementation home and building automationelectronic system networks,
299       connected devices and applications.
300      Automatically configured devices.
301      Installer configured devices.
302      Installer configured groups/clusters of devices.
303   This standard specifies anpart of ISO/IEC 18012 addresses interoperability framework for
304   system operation and management of products connected to a single automationhome
305   electronic system or to different automationhome electronic systems. Although a single
306   uniform automationhome system would simplify operations, this International Standard
307   recognises that multiple different networks may co-exist in the same distributed
308   automationhome electronic system.

309   The interoperability framework is used to describe automation system components such that
310   products from multiple manufacturers can work together to provide a specific application.

311   This standard specifies a taxonomy specified here is based on application domain
312   classification criteria for applications in home and building automationelectronic systems, as
313   well as a lexicon of objects, events, properties, and primitive actions to effect or otherwise
314   propagate change in the objects (their properties). This The full lexicon for the interoperability
315   of home electronic systems will be defined in Part 3 of this standard, as part of the Application
316   Model specifications. This International Standard enables the specification and
317   implementation of distributed application functions and services within the context of home
318   and building automationelectronic systems.
319   This International Standard does not specify how two automationhome electronic systems
320   simultaneously share (i.e. resolve possible contention for) a common resource or how to
321   ensure that two automationhome electronic systems used within the same premises do not
322   interfere with each other. However, this standard requiresnote that it is required by Part 1 of
323   this International Standard that two automationhome electronic systems may share a common
324   resource, and that they shall not interfere with one another.



      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                        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             HGI B




                      Objects on                                          Objects on
                      Network A         Network A         Network B       Network B




325                               Figure 1 -– Two Interoperating Networks

326   This International Standard applies to application components in operation within networks,
327   between networks, and to components located at the junction of dissimilar networks. Two (or
328   more) dissimilar networks (referring to Figure 1 as an example) mustthat conform to this
329   standard ifInternational Standard, when linked by some communication system, they are
330   expected to behave as if both networks were logically the same network from an application
331   perspective.

332   2      Normative references

       No:      Reference                    Descriptive Title

       [1]      ISO 7498 : 1984              Information processing systems - Open Systems
                                             Interconnection - Basic Reference Model

       [2]      ISO/IEC TR-14543             Home Electronic System Architecture

       [3]      ISO/IEC TR-14762             Guidelines for Functional Safety for Home Control
                                             Systems

       [4]      ISO/IEC 18012-1              ISO/IEC FDIS 18012-1 Information technology —
                                             Interconnection of information technology equipment —
                                             Home electronic system — Guidelines for product
                                             interoperability — Part 1: Introduction

       [5]      ISO/IEC 15045-1              ISO/IEC 15045-1 Information technology —
                                             Interconnection of Information technology equipment —
                                             Home electronic system (HES) — HES Gateway Part 1::
                                             Introduction

333   ISO/IEC 646 Information technology — ISO 7-bit coded character set for information
334   interchange

335   ISO 7498:1984, Information processing systems – Open Systems Interconnection – Basic
336   Reference Model
      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                   10
      ISO/IEC CD 18012-2  IEC:2008                          11            ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                2008-12-17
337   ISO/IEC 18012-1, Information technology — Home electronic system (HES) — Guidelines for
338   product interoperability — Part 1: Introduction

339   IEC 60050-714:1992, International Electrotechnical Vocabulary - Chapter 714: Switching and
340   signalling in telecommunications

341   IEC 60559, Binary floating-point arithmetic for microprocessor systems

342   3     Terms, definitions and abbreviations
343   3.1    DefinitionsTerms and definitions
344   For the purposes of this International Standard, the following terms and definitions apply.

345   3.1.1
346   API
347   application programming interface
348   API
349   collection of invocation methods and associated parameters used by one piece of software to
350   request actions from another piece of software

351   3.1.2
352   co-existence
353   two or more networks within a premise that do not interfere with one another

354   3.1.3
355   component
356   logical subunit of a larger, encompassing concept
357   NOTE The concept of interoperability is broken down into constituent components such as safety, management
358   and operation. These constituent components are further broken down within their respective sections. The term
359   component is also used to refer to logical subunits of system architecture concepts, such as the components of a
360   networking implementation (for example, addressing) .

361   3.1.4
362   device
363   distinct physical unit on a network
364   NOTE It can either be an end node on the network, or an intermediate node (as in the case of a network gateway
365   device connecting two distinct physical networks).
366   3.1.5
367   event
368   individual output of an application object, typically corresponding to a simple or complex state
369   variable used in the application object
370   NOTE See 6.4: Events.
371   3.1.6
372   functional action
373   modelling of functionally composite behaviour within a functional class

374   3.1.7
375   functional class
376   a collection of objects and actions on objects that models a particular application function
377   within an application domain

378   3.1.63.1.8
379   functional action
380   allow for modelling of functionally composite behaviour within a functional class (i.e. in a
381   specific context)

382   3.2
383   interoperability
384   logical entities functioning together for applications on a network

      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                     11
      ISO/IEC CD 18012-2  IEC:2008                             12            ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                   2008-12-17
385   3.2.1
386   network
387   distinct interconnection of devices that share a single physical layer implementation in terms
388   of the OSI layered network model
389   NOTE See IISO/IEC 7498-1:1994.
390   3.3
391   object
392   unit of software functionality
393   NOTE This definition is similar to that traditionally used in object-oriented programming..
394   3.4
395   product
396   device or network that may be purchased to make up a Home Electronic System

397   3.5
398   single implementation
399   single, homogeneous network implementation, where interoperability is only of concern within
400   the single network

401   3.6
402   multiple implementation
403   mixed collection of two or more network implementations
404   NOTE To establish interoperability, each network has a routing path to every other network in the system. This
405   path may involve one or more hops through multiple intermediate networks.
406   intermediate implementation
407   mixed collection of two or more network implementations
408   NOTE To establish connectivity, an intermediate implementation provides for a common intermediate translation
409   between any two networks, assuring a worst-case translation path of two hops (from any network to the common
410   translation, and then from the common translation to the destination network).
411   3.6.13.1.9
412   interoperability gateway
413       (1) logical device that implements entities functioning together for applications on a
414           network

415       (2) the ability of two or more distributed components to communicate and cooperate in
416           predictable ways despite differences in implementation language, execution
417           environment, or model abstraction

418   3.1.10
419   interoperability domain
420   ID
421   logical space where interoperable objects seamlessly interact with one-another using an event
422   bus

423   3.1.11
424   interoperability domain interface
425   IDI
426   software object interfaces to and from different systemsthat provides the translation between
427   a generic interoperable object instance and a corresponding system-specific counterpart by
428   using an interworking function
429   NOTE It may be the same as the residential gateway/home gateway devices.                  An example is the HES
430   Gateway [5].
431   3.6.23.1.12
432   interworking
433   ability of two or more devices to support exchange of data and actions between them, having
434   the same communication interface and application data types



      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                    12
      ISO/IEC CD 18012-2  IEC:2008                             13             ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                    2008-12-17
435   3.6.33.1.13
436   interworking function
437   IWF
438   software module that provides syntactic and semantic translation services between a device
439   and its standardised interoperable representation residing; it resides in an intermediary unit
440   that connects two, possibly different, communication systems
441   3.6.43.1.14
442   3.7     Abbreviations
       API                       Application Programming Interface
       HAN                       Home Area Network
       HES                       Home Electronic System
       IWF                       Interworking Function
       HGI                       Home Gateway Interface
       GL                        Gateway Link

443   4     Conformance clauses
444   multiple implementation
445   mixed collection of two or more network implementations
446   NOTE To establish interoperability, each network has a routing path to every other network in the system. This
447   path may involve one or more hops through multiple intermediate networks.
448   3.1.15
449   network
450   distinct interconnection of devices that share a single physical layer implementation

451   3.1.16
452   object
453   unit of software functionality
454   NOTE This definition is similar to that traditionally used in object-oriented programming.
455   3.1.17
456   product
457   device or network that may be purchased to make up a home electronic system

458   3.2     Abbreviated terms
459   For the purposes of this International Standard, the following abbreviated terms apply.

460   3.2.1
461   API
462   application programming interface

463   3.2.2
464   GL
465   gateway link

466   3.2.3
467   HAN
468   home area network

469   3.2.4
470   HES
471   home electronic system

472   3.2.5
473   HGI
474   home gateway interface




      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                   13
      ISO/IEC CD 18012-2  IEC:2008                  14          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                      2008-12-17
475   3.2.6
476   ID
477   interoperability domain

478   3.2.7
479   IDI
480   interoperability domain interface

481   3.2.8
482   IWF
483   interworking function

484   54 Conformance requirements
485   In order to conform to this standard of Product Interoperability, HES products and networks
486   shall meet the conformance clauses listed in [4] and the following clauses.

487   5.1   Safety
488   It is required that particular considerations regarding safety in Interoperating Home Electronic
489   Systems identified in       shall be followed. Safety is the fundamental consideration for
490   implementation of the interoperability framework into HES products. No action shall be
491   translated between dissimilar network systems if there is any doubt about the safe outcome of
492   the action being carried out.

493   5.24.1 Management
494   Interoperability considerations regarding general management processes in HES are
495   described in reference .ISO/IEC 18012-1. This part of the standard addresses only the
496   management aspects related to the operation mode of interoperable HES and does not cover
497   the management processes of individual constituent networks. Examples of these are the
498   device address acquisition and maintenance or resource management processes (contention
499   for gaining exclusive access to some object). Different systems define different management
500   protocols and procedures for realising these. This standardpart only covers, for example, the
501   device management functions pertaining to application configuration. In this context it is
502   assumed that the propagation of the necessary actions to support the operational application
503   object binding further down the protocol stack (for example, device address or network
504   variable number), as well as the provisioning of the necessary conditions are fulfilled by
505   separate management services not described in this part of the standard.. These functions
506   are standardised or specified in the domain of the individual networks. As the Interworking
507   Functions (IWF)IWFs are used as the device interface proxy to the interoperability system and
508   are normally provided by the manufacturer of the device (or an inte rested third party
509   provider), these management functions are carried out within the interworking functionIWF
510   code and are not part of this International Standard.

511   Further examples of management issues outside the scope of this International Standard
512   include establishing and maintaining connectivity between devices hosting the distributed
513   application objects independently of the fact that the devices belong to the same or different
514   systems. Interoperability management allows for transparency to the native application
515   management support services provided by separate, though interoperable, systems
516   independently of the fact that these services are automatic or installer-based.

517   5.3   Additional clauses
518   None in this version.

519   4.2   Application interoperability model
520   An implementation shall conform to the application interoperability model described in Clause
521   5: Application interoperability model, including the use of an ID and IDIs with appropriate
522   IWFs to achieve interoperability.




      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                     14
      ISO/IEC CD 18012-2  IEC:2008                   15          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                       2008-12-17
523   4.3     Software logic encapsulation
524   An implementation shall support encapsulating software logic within application objects, as
525   described in subclause 6.2: Application objects.
526   4.4     Interaction with interworking functions (IWFs)
527   An implementation shall support interaction between IWFs and application objects, as
528   described in subclause 6.2: Application objects.

529   4.5     Multiple bindings for application object event inputs and outputs
530   An implementation shall support the definition of multiple bindings per application object event
531   input or output, as described in subclause 6.3: Binding map.

532   4.6     Multiple binding maps per application object
533   An implementation shall support application objects belonging to more than one binding map,
534   as described in subclause 6.3: Binding map.

535   4.7     Event timestamps
536   An implementation shall support event timestamps as described in subclause 6.4: Events.

537   4.8     Temporal association of events
538   An implementation shall support the requirement for multiple events generated concurrently
539   from a single application object to be delivered at the same time to any application object that
540   has a binding to two or more of those concurrent events, as described in subclause 6.4:
541   Events.

542   4.9     Home electronic system application interoperability taxonomy
543   An implementation shall use the taxonomy defined in Clause 7: Home electronic system
544   application interoperability taxonomy when defining interoperable application objects and
545   events.

546   4.10    Object schema
547   An implementation shall use the schema defined in Clause 8: Object schema when defining
548   interoperable application objects, including:

549        Conforming to the use of the base objects defined in 8.2 as the foundation for deriving
550         specific application objects.
551        Assuring that all events either match a data type primitive defined in 8.3, or are derived
552         from a combination of those primitives that defines a more complex data type.
553   4.11    Application binding map schema
554   An implementation shall support a binding map mechanism that conforms to the requirements
555   defined in Clause 9, such that any interoperable application may be fully specified to the
556   interoperability framework implementation.

557   65 Application interoperability model
558   The application interoperability model is based on the definition of an Application Domain one
559   or more application domains, where each domain is identified explicitly in the HES object
560   taxonomy. Each domain is populated with application objects that representing sensor,
561   actuator and control devices. These application objects interact with each otherone another
562   by posting and receiving events across an information a logical event communication bus (the
563   event bus); the event bus provides the communication services to the application objects. An
564   application is formed as a collection of objects with specified and one or more application
565   objects with specified bindings, and with verifiable behaviour. A generic application example
566   is a controller application object instance which collects sensor information from sensor
567   application objects of a pre-defined binding. type, and requests action from actuator
568   application objects, again from a list of pre-defined types. Note that this view does not
569   assume that a physical device (product) will be modelled as only one of these three classes
570   (i.e. a product may be realised as a combined sensor/actuator/controller entity if the particular
      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                      15
      ISO/IEC CD 18012-2  IEC:2008                   16           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                        2008-12-17
571   application requires it to be designed in that way); however, for the purposes of the
572   interoperability framework each of the three functionalities will be presented by different
573   objects when and if they are required to interoperate across systems belonging to different
574   specifications and/or standards.

575   The application objects are programs running on individual devices, for example a
576   temperature sensor device has ana corresponding application object that is called
577   Temperature SensorTemperatureSensor. The association of interoperable application objects
578   with actual devices is performed through management functions,configuration processes
579   which are outside the scope of this standard; they are part of the Interworking FunctionIWF
580   provided by the device manufacturer or a suitable/an interested third party. These
581   configuration processes are outside the scope of this International Standard.The interoperable
582   application objects connect to the actual devices they represent via the Interworking
583   FunctionsIWFs.




                                            Interoperability Domain


                                    Interoperabi              Interoperabi
                                    lity Object 1             lity Object 2




                                         IDI                  IDI
                                       (IWF-A)              (IWF-B)




                     Device 1-A        Network A           Network B          Device 2-B



584                          Figure 2 – Application interoperability model

585   Figure 2 shows an instantiation of the application interoperability model. Two objects
586   (Objectdevices (Device 1-A and ObjectDevice 2-B) are installed in two different network
587   systems, respectively Network A and Network B, and need to interact with each other to
588   provide an interoperable application within the premises.. The networks are linked together
589   through a logical entity called the interoperability Gateway (IGdomain (ID). The
590   Interoperability Gateway interfaces ID connects with different network systems via an
591   Interoperability Gateway Interface (IGIa set of interoperability domain interfaces (IDIs). The
592   IGIsIDIs are software entities that containcontaining software functions that provide theany
593   necessary translation between the generic interoperable object instance (e.g.
594   Interoperability Object 1 within the IG domain)interoperability domain) defined in this
595   International Standard and the corresponding system-specific counterpart (ObjectDevice 1-A
596   in Network A) by using an). These translation services are called Interworking Function
597   (IWFFunctions (IWFs). The Interoperable Gateway maintainsIDIs maintain the logical
598   connection between the generic interoperable object instance within the IGinteroperability
599   domain and the corresponding device (or the system-specific counterpart.). This
600   involvesincludes maintaining object-state consistency between the interoperable object
601   instance and the system-specific counterpart. , as necessary; this is performed by the IWF.

602   Note that both Networks A and B may contain other devices. They will not be represented in
603   the gatewayinteroperability domain if these devices are not required to interwork in the
604   context of this specification with devices on differingother different systems and/or networks.

      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                      16
      ISO/IEC CD 18012-2  IEC:2008                  17          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                      2008-12-17
605   The interoperability Gatewaydomain is a functionallogical entity. It can be implemented ason a
606   single separate entity, as aphysical device/platform, distributed entityover several devices, or
607   its functionality may be integrated with other functional entities such as a ResidentialHES
608   Gateway.

609   The Specific network systems shall specify the IWFs to the Interoperability Gatewaybe used
610   for the objectsinteroperable object instantiation and running on an interoperability domain for
611   which they offer interoperabilitydevices that are intended to be interoperable.

612   76 Interaction model
613   7.16.1 Overview
614   An interaction model between the application objects in the Interoperablity Gateway
615   (IG)interoperability domain is described here to passfor passing application events across a
616   logical event communication path or bus defined within the interoperability Gatewaydomain,
617   known here as the event bus or GL. Event passing is asynchronous, occuringoccurring at any
618   time that the application objects require.

619   Events are originated by application objects. It should be noted that an application object is
620   not required to produce outputs: some application objects might only be receivers of events.

621   Each application object can have multiple inputevent inputs and output eventsevent outputs,
622   which correspond to the input and output parameters (as defined in IEC 60050-714:1992,
623   Definition 714-21-08) of that application object’s function or functions. Therefore, the
624   individual function parameters of an application object are being passed across the event bus
625   as separate events. This effectively breaks any tight association between the application
626   object function interfaces (or application programming interfaces) and the communication
627   protocol used to move the parameters across the network: the. The event bus protocol simply
628   moves individual events from a source application object to a destination application object or
629   objects, and is not affected bydependent on future changes into the application object
630   function interfaces. In other words, the event bus communication protocol is completely
631   independent of the applications that it is supporting.

632   Event destinations are specified by a binding map that is part of the application
633   interoperability model. framework definition. The binding map is used to define event
634   connections (bindings) between application objects at the individual event level. These
635   bindings are simply the declaration of a connection from an event produceroutput of an
636   application object to one or more event consumersinputs of an application object or objects.

637   It would not be efficient, from a communication channel perspective, to send every individual
638   application object function parameter as a discrete transaction on the event bus., . Therefore,
639   it is expected that implementations of this International Standard will make use of both the
640   application object schemas and the binding map information to enable efficient automated
641   aggregations of multiple concurrent events. This means that during execution
642   implementations should group together concurrent events (e.g., event outputs that were
643   generated concurrently by an application object) that have the same destination, and move
644   them across the event bus as a single communication transaction (e.g., a single message
645   payload, or a single memory transfer, etc.). See 6.5: Event bus for a further discussion of this
646   concept.

647   This aggregation of events is independent of the application object function interfaces, and
648   could easily result ineven allow for the outputs of multiple application objects beingto be
649   moved across the event bus as a single unit. Upon arriving at the destination, the grouping
650   should be disaggregated into their individual events for posting to the appropriate application
651   object inputs. This approach enables global system-level optimization of communication
652   bandwidth, rather than individual application-level optimization.

653   7.26.2 Application objects
654   Application objects represent the operational components of an interoperable application.
655   They are software representations of the sensors, actuators, control devices, and higher -level
656   functions in ana HES system that must interoperate.

      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                     17
      ISO/IEC CD 18012-2  IEC:2008                      18            ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                            2008-12-17
657   Depending on their function, application objects can have zero or more event inputs and
658   event outputs. An application object with only event outputs is considered a sensor
659   application object; one with only inputs is considered an actuator application object. Control
660   application objects have one or more event input(s) and one or more event output(s). See
661   Clause 8: Object schema for a complete description.

662   Application objects encapsulate software logic appropriate to the component the y represent in
663   the system. For example, a temperature sensor application object for a temperature sensor
664   device would receive temperature readings from the device via an IDI using thean appropriate
665   mechanism (e.g., LonTalk), and then perform any IWF that performs any necessary data
666   reformatting or translation on the readings to put them in the form of the interoperable
667   properties defined in 7.4.2: Application Object Structurereading. The temperature sensor
668   application object can then perform any additional application processing desired (if any)
669   before generating an output event on the event bus containing the temperature reading.

670   7.36.3 Binding map
671   A binding map corresponds to a single application in the IGinteroperability domain. There will
672   typically be many binding maps active, one for each application that is running.

673   The binding map defines the connections between the application objects that make up a
674   complete application. A binding identifies the source-end and the destination-end of an event
675   connection. See Figure 4 – Event bus exampleThere can be multiple bindings from a single
676   application object output, and there can be multiple bindings to a single application object
677   input for a graphical depiction of this concept.

678   There can be multiple bindings from each application object event output, and there can be
679   multiple bindings to each application object event input. In other words, an application object
680   event output can be used as an input by more than one application object, and conversely an
681   application object event input can receive events from more than one application object.

682   Also, application objects might be part of more than one application, and as such they might
683   be included in more than one active binding map as shown in Figure 3 – Binding map
684   example. In this simple example Lighting Controller B is part of both the manual lighting
685   switch application and the motion-activated lighting security application.


                                                              D
                                                         Security
                                                         Controller
                                                                                     Security Application
                                                                                        Binding Map
                                               B                       E                  (B, D, E)
                                             Lighting                 Motion
                                            Controller                Sensor
        Lamp Control Application
             Binding Map
               (A, B, C)             A                        C
                                   Switch                  Lamp


686
687                                  Figure 3 -– Binding map example
688   7.46.4 Events
689   Events correspond to the individual outputs of application objects, and as such the structure
690   of their application-specific content, are defined using the application object schema
691   described in Clause 8: Object schema. Events shouldshall also contain a timestamp, as
692   defined by the application object schema.

693   At a minimum, there should be a timestamp that corresponds to the time at which an event is
694   placed on the event bus by an application object. In addition, depending on the capabilities of
695   the underlying system implementation, there could be a second timestamp that represents the

      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                              18
      ISO/IEC CD 18012-2  IEC:2008                                               19                         ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                                                  2008-12-17
696   time when a physical event actually occurred. (e.g., the time that a temperature sensor
697   reading occurred).

698   7.56.5 Event bus
699   The event bus provides the delivery mechanism for events to pass from an application that
700   produces the event to any number of application objects that consume the event and
701   potentially take some action. Events are asynchronous, occurring at any time.

702   The intent is that the event bus model be as simple as possible, allowing it to be implemented
703   on the broadest possible set of underlying communication mechanisms. One implementation
704   might be based on a shared memory for an IG domain that is completely contained in a single
705   processing device such as a simple embedded gateway. A more comprehensive
706   implementation wouldcould be a distributed event bus on top of a publish/subscribe transport
707   spanning multiple processing devices (such as a collection of half-gateways connected over a
708   network).HES-Links or GLs, as defined in ISO/IEC 15045-2, connected over a network), or
709   any combination of such implementations – the event bus does not have to be implemented
710   on a uniform underlying communication mechanism, and in fact is likely to span multiple
711   underlying communication mechanisms as part of building an interoperable HES.

712   An important characteristic of the event bus is that multiple events generated at the same
713   time from a single application object must be delivered at the same time to any application
714   object that has a binding to two or more of those concurrent events. The following diagram
715   depicts an application descibeddescribed by a binding map between four application objects
716   (A through D). For this example, assume that the events generated by Object A outputs o2
717   and o3 were produced at the same time (for example, concurrent sensor outputs in reaction to
718   a change in the physical world). Object D inputs i1 and i3 are bound to those outputs from
719   Object A, and must be delivered to Object D simultaneouslyconcurrently to maintain correct
720   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
                                                                                                1            3
                                                                                                    2
                                                   DataVarSet
                                                     Output




                              i1       i2     i3
                                   Object D

                          <<Application Object>>                         i1           i2   i3           i4

                                                                                      Object C

                                                                     <<Application Object>>
721
722                                                                  Figure 4

723   Quality of service capabilities such as guaranteed delivery of events, latency guarantees, and
724   other similar communication issues must be clearly defined for any implementation.

725               HES Application Interoperability Taxonomy – Event bus example
726


      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                                           19
      ISO/IEC CD 18012-2  IEC:2008                         20         ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                            2008-12-17
727   7   Home electronic system application interoperability taxonomy
728   7.67.1 Classification
729   The HES application interoperability taxonomy is shown in Figure 5Figure 5. For purposes of
730   the interoperability specification the HES domain is classified into the following categories:

731       1. Application Domain
732       2. Functional Object
733       3. Application Object
734       4. Functional Actions
735       5. Property
736       6. Property Primitive Actions




                            Application Domain


                                    Functional Object

                                            Application Object

                                                           Property
                                                           Primitive Action



                                            Functional Action




737
738                               Figure 5 – Interoperable system taxonomy

739   Application Domains are specified in terms of Functional Objects, which represent logical
740   grouping of some device functionality. Each Functional Object is specified as a collection of
741   OperationalApplication Objects (as well as Configuration Objects, possibly, objects related to
742   its configuration) that represent application atomic state and functions. This specifies the
743   semantics of the applications and the components of the Functional Object. Objects in turn
744   are specified as collection of properties, which define the content representation for storage,
745   transport (syntax), and interaction purposes.

746   The classification of the home electronic systemHES components into Functional Objects,
747   Application Objects and Properties, as logical entities in the taxonomy, is designed to allow
748   for separation of the syntactic and semantic aspects of the interoperability. Functional Objects
749   model controller entities (hardware or logical devices) in a home electronic system.
750   Application Objects model sensor and actuator entities. Properties are used to specify the
751   syntax, i.e. the data representation of the object information components. This allows for a
752   direct mapping (data type translation and matching) between properties as specified in this
753   International Standard and those specified in other specifications through the use of
754   interworking functions. IWFs.


      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                     20
      ISO/IEC CD 18012-2  IEC:2008                       21             ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                              2008-12-17
755   Objects cover, in general, represent the semantics of the application;, i.e. they represent
756   behaviour, which is exhibited through the interaction with other objects by invoking primitive
757   actions on the properties. The use of both Functional Objects and Operational Objects allows
758   the interoperability, through translation in the IWF, to cater for both variable-oriented and
759   device-oriented HES specifications. The separation between the semantics (object level) and
760   the syntactic representation of the data (property) allows for flexibility in the definition of the
761   interoperability interworking functionsIWFs. In the simplest case, Application Objects can be
762   used to present a single network variable, and allow the modification of the processing of its
763   value for representation into the Interoperability Framework space.

764   For As an example, a Functional Object named TemperatureSensor functional object may
765   have an Application Object called RoomTemperature of <Temperature> data type, which is
766   measured in degree celsius (semantic). The Appplication Object in the interoperability
767   specification is defined as having a Property called "TempValue", which is of type "Float"
768   whichthat follows the ANSI/IEEE 754 IEC 60559 specification (syntax).

769   Detailed definitions of the framework components are given belowin the following subclauses.

770   7.77.2 Application Domainsdomain
771   7.7.17.2.1 Definition
772   Application Domains serveAn application domain serves as context-setting descriptions. They
773   groupdescription. It groups together functions that interact in semantically related
774   applications. A non-exhaustive list of the application domains is given in clause 7.2.2.

775   Application domains are enumerated entities. As part of the taxonomy they can be used in
776   word form or represented by the corresponding enumerated value, to form part of the object
777   name for application binding.

778   7.7.27.2.2 Application domain list
779   The application domain list provided in Table 1. The list is not exhaustive..

780                                  Table 1 – Application domain list

             Application Domain                                      Description
                    Name
      1    General                 This domain groups together functions that provide generic services to other
                                   entities in a home electronic system. E.g.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 electronic 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,

      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                        21
      ISO/IEC CD 18012-2  IEC:2008                  22           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                       2008-12-17
                                   Cooker, Oven, …

              …

781

782   7.7.3       Additions and modifications
783   The Application Domain List is non-exhaustive. Proposals for adding new domains should be
784   submitted to the standardisation body maintaining the list. Additions are made official upon
785   publication of the new registry.

786   7.87.3 Functional object
787   7.8.17.3.1 Definition
788   A functional object is a collection of objects and actions on objects that models a particular
789   application function within the application domain. An instantiation of a functional object is a
790   logical device, i.e. a software entity that provides some specific standardised control and/or
791   information functionality in the HES in which it is installed. Functional Objects form the basis
792   of the classification in this standard.

793   7.8.2       Functional Object structure
794   Functional objects model controller entities (hardware or logical devices) in a home electronic
795   system. Functional objects form the basis of the classification in this International Standard.

796   7.3.2       Functional object structure
797   A functional object is composed of Operative Objectshas its properties and functional actions.
798   Functional actions are specified as (possibly aggregate) actions on individual objects that
799   lead to a functional operation of the logical device in the system. For example, scene setting
800   requires a series of (inter)actions with several sensor and actuator objects (lighting,
801   communication, AV, etc.); a scene setting controller can be modelled as a functional object
802   that has a functional action composed of actions on individual operational objects modelling
803   devices as described above. A functional action has contextual meaning, and is specified
804   together with the functional object. The invocation of a functional action leads to a specified
805   series of invocation of component (operative) objects., and results in moving the operational
806   objects into a specified, and verified, end state, where applicable.

807   A functional object describes the application layer interface, including input and output
808   operation objects, configuration properties, default and power-up behaviour required on
809   devices for specific commonly used control functions. An instance of a functional object is
810   implemented in a physical device as (part of) the application.

811   An instance of a functional object is a logical device locally addressed via a functional object
812   identifier (ID).. The functional object IDidentifier (FOID) value can be a result of local
813   enumeration, or a global FOID can be used. In any case the mapping between the FOID and
814   the service access point serving this instance of the functional object is maintained by the
815   application support layer.

816   7.8.2.1       Objects                                                                               Comment [RA1]: Editor’s note: Only the
                                                                                                          operational properties of objects are subject to
817   Objects are actionable entities that contain one or more properties. They are locally               this part of the standard.
818   addressable entities. An object models, through its properties and primitive actions, the most
819   generic behaviour of sensors and actuators in a home electronic system. An object contains
820   basic descriptive properties, configuration properties, and operational properties.

821   Objects are described in detail in Clause .

822   7.8.37.3.3 Functional Actionsaction
823   Functional Actions allowaction allows for modelling of functionally complex behaviour within a
824   functional object (i.e. in a specific context). Functional actions are enumerated entities within
825   a functional object, and have meaning only within that object. ExamplesAn example of a
826   functional action is <SwitchOn> within a LightController functional object.

      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                      22
      ISO/IEC CD 18012-2  IEC:2008                                23          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                    2008-12-17
827   Invoking a functional action means to invoke at least one primitive action on at least one of
828   the properties in at least one operational object within the same functional profile, local or
829   remote.

830   7.8.47.3.4 Functional object list
831   The functional object list consists of all the defined functional classes for each application
832   domain. The Functional Class List is maintained by an internationally recognised body...

833   7.8.5            Additions and modifications
834   The Functional Object List is non-exhaustive. Proposals for adding new Functional Objects
835   should be submitted to the standardisation body maintaining the list, outlining the Application
836   Models to which they belong. Additions are made official upon publication of the new
837   standard.

838   7.9            Objects
839   7.4            Application Object
840   7.9.17.4.1 Definition
841   Application objects are self-describing actionable, locally addressable, entities that contain
842   one or more properties. They are locally addressable entities. An application object models
843   via, through its properties and primitive actions, the most generic behaviour of sensors and
844   actuators in a home electronic system. An object contains basic descriptive properties,
845   configuration properties, and operational properties.

846   7.9.27.4.2 Application Object Structure
847   Application Objects are collections of one or more properties. Each property is an internally
848   structured self-describing entity that encapsulates some information source (in sensors) or
849   control (in actuators) variable.

850   Every application object has a self-description property and an object instance identifier
851   property.

852   The object instance identifier can be instantiated dynamically, or seeded with a (default) value
853   specified in the published generic application model.

854   7.9.2.1            Properties
855   7.4.3            Properties areProperty
856   A Property is an atomic actionable structured data entitiesentity that containcontains a single
857   variable. The structure of Propertiesa property is given in Table 2 below. They are presented
858   in a simple data format, and are characterised by a data type, methods, and information flow
859   direction (in, out, in/out).

860   The property methods defined implicitly are given in 7.4.6Clause .

861                                                   Table 2 – Property structure

            Property                                                      Notation                                       Formatted Table
             ptio
             scri
             De




                               Property_Name                              Character String
              n




                               Property_Action_List                       Array of String
             din
             Co




                               Property Data Type                         [Array of] Primitives from clause 7.4.4
              g




                               Number of elements                         Unsigned Integer


                               Value
             Value




                               Default Value
                               Value Range
             atio



             ntic
             plic



             ma
             Ap



             Se




                               Property Unit Type
              n



              s




      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                      23
      ISO/IEC CD 18012-2  IEC:2008                             24         ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                2008-12-17
                          Support (Mandatory / Optional / Conditional)
                          Access (In / Out / IO ),

862   7.9.37.4.4 Property data Types Primitivestype primitives
863            Character string (ISO/IEC 646)
864            Boolean
865            Integer (Integer8, Integer16, Integer32)
866            Unsigned integer (UInt8, Uint16, Uint32,Uint64)
867            Float (ANSI/IEEE754IEC 60559)
868            Date
869            Time (and Date/Time)
870                    Data Octet String
871   7.9.47.4.5 Property unit type primitives
872   These are semantic data units, for example degree Kelvin for temperature semantic data type.
873   These are grouped into basic data units and derived data units.
874   The basic data units are given in Table 3 below, and outlined in the XML schema file in Annex B.2:
875   Base Types. Using this set of unit type primitives, any physical unit type can be derived. Derived data
876   units will be listed and maintained in the same way the lexicon registry is maintained.
877                                      Table 3 – Property unit type primitives

                                       Property unit type                  Unit
                                              Length                      Meter
                                               Time                      Second
                                           Temperature                    Kelvin
                                              Mass                       Kilogram
                                         ElectricCurrent                 Ampere
                                        SubstanceAmount                   Mole
                                        LuminousIntensity                Candela
878
879   7.9.57.4.6 Property action primitives
880   The actions allowed on the properties are:

881        GET: the value of the property being queried is returned.
882        SET: the value of the property being accessed is set to the given value.
883        EVENT_REPORT: the value of the property is reported to the subscribed entities.
884        SUBSCRIBE: the operational object updates the list of subscribed entities (objects) for the
885         given/required property. If the list is empty the property changes are not reported.
886   7.9.67.4.7 Object types
887   Objects can be classified into two groups: operational application objects and application
888   management objects (configuration). Only the application objects are addressed by this
889   International Standard.

890   The Object Schema shall specifyspecifies the type of object.

891   8     Object schema
892   8.1       Overview
893   The object schema design reflects the interaction model described in Clause 6: Interaction
894   model, and emphasises describing the input and output events of objects. This includes the
      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                24
      ISO/IEC CD 18012-2  IEC:2008                   25           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                        2008-12-17
895   names, the data types, and optionally other informationcharacteristics about the inputs and
896   outputs (. These other characteristics are an open-ended set that will take the form of
897   metadata such aselements that extend the input and output elements in the schema, an
898   example of which might be maximum latency requirements on inputs, for example)..

899   The object schema must also reference the executable logic that implements the object’s
900   functions. This reference is implementation-independent, and needs to be able to support any
901   execution platform and language. The purpose is to enable an interoperability framework
902   implementation to invoke any executable logic for an object, and present the input events that
903   are pending (i.e., that have arrived for the object from the event bus).

904   There can also be additional, global metadata associated with an object. This might be for
905   configuration parameters affecting the behaviour of the object. (versus the individual input or
906   output metadata described above).

907   8.2     Base objects
908   8.2.1     General
909   There are three types of primitive object types in the schema: sensors, actuators, and control
910   objects. Although these names imply very different types of objects from a conceptual
911   perspective, the functional difference between the three object types in this schema areis
912   simply that sensors only have event outputs, actuators only have event inputs, and control
913   objects have both event inputs and outputs.

914   There can be other input and output settings for any of these objects, such as the ability to set
915   or change metadata characteristics to adjust the object configuration, but these would be
916   separate from the asynchronous application event flows. For example, object settings could
917   be managed through a synchronous call interface to the object.

918   Using the these three basic building blocks of sensors, actuators, and control objects with
919   asynchronous input and output events, connected together across an event bus, it is possible
920   to construct a description of any automation application or function.

921   There is no association between an input or output and Events do not contain any explicit
922   identification of the base type of object it is part of (sensor, for example). that generated the
923   event. This means that any object with an output can be bound to any object with an input.
924   Importantly, it means that control objects can provide inputs to other control objects. (i.e.,
925   inputs do not have to come from sensor objects). This provides the basis for creating sub-
926   automation components in an application description, allowing groups of sensors, actuators,
927   and control objects to appear conceptually as sensor inputs or actuator outputs to higher level
928   control objects in a complex application.

929   The intention is that specific types of sensor, actuator, and control object schemas will be
930   derived from the base object schemas, and those specific types can then be further derived
931   into vendor-specific variations if needed. For example, a temperature sensor object schema
932   can be derived from the base sensor schema, defining a single output of type Fahrenheit
933   degrees. A vendor might then further refine the temperature sensor schema with vendor-
934   specific characteristics such as additional features. These can be described by defining global
935   configuration properties or perhaps additional outputs.

936   The Base Object XML object schema definitions are shown in Annex B.

937   8.2.18.2.2 Control objects
938   Control objects have any number of inputs and outputs. Conceptually, they are the objects
939   that will contain the core functions of an application: the decision logic, the control loops, etc.
940   This clausesubclause will describe the content of the base control schema. The following
941   clausessubclauses discuss the sensor and actuator schemas.

942   The block diagram below shows the basic structure of the control object schema. The
943   commons section is shared between the sensor, actuator, and control object



      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                        25
      ISO/IEC CD 18012-2  IEC:2008                         26             ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                2008-12-17
944   schemas.
                           controlModelTypes

                                                         controlModel




         commons
                                            inputs      outputs            codeBase                  properties



                                                                                       description
                                  input                 output                                            property
                                                                                       codeType

                                dataPoint              dataPoint
                                                                                      codeLocation

                               QoIRequirement
                                 <<complexType>>             QoI
                                                        <<complexType>>                idlLocation
                                  <<complexType>>        <<complexType>>
                                eventProperties
                                 eventProperties       eventProperties
                                                        eventProperties

945
946                                       Figure 6 – Object schema structure
947   The commons section describes the basic structure of all the objects: inputs, outputs, global
948   object properties (such as configuration settings, etc.), and a reference to the executable
949   code that implements the logic of the control object. The commons section schema is listed in
950   Annex B.1: Commons.

951   The inputs section of the schema is comprised of one or more input elements:

952     <xsd:element name="input">
953        <xsd:complexType>
954           <xsd:sequence>
955             <xsd:element ref="dataPoint"/>
956             <xsd:element ref="QoIRequirement" minOccurs="0"/>
957           </xsd:sequence>
958        </xsd:complexType>
959     </xsd:element>
960   It consists of a dataPoint elementselement, which decribeddecribes the data type and other
961   characteristics of of an input data itemevent, and a QoIRequirement or Quality of Information
962   Requirement elementselement, which describeis used to define other requirements on
963   characteristics of the input, such as events, examples of which might be precision, frequency,
964   etc. These are considered metadata that describe things about the input data itemevent,
965   rather than describing the itemevent itself.

966   The outputs section is similar in structure and content, with the exception that instead of
967   having QoIRequirement metadata, it refers to QoI or Quality of Information metadata, which
968   describe the actualdefine other characteristics of the outputsoutput events, and are suitable
969   for matching or validation against input QoIRequirements.

970   Both the QoIRequirement and the QoI metadata are open-ended sets of information, and will
971   be expanded as needed to support different application requirements.

972   The codeBase section of the schema is:

973     <xsd:complexType name="codeBase">
974        <xsd:sequence>
975           <xsd:element name="description" type="xsd:string" minOccurs="0"/>
976           <xsd:element name="codeType" type="codebaseTypes" default="JAVA"/>
977           <xsd:element name="codeLocation" type="xsd:string" minOccurs="1"/>
978           <xsd:element name="codeProperties" type="properties" minOccurs="0"/>
979           <xsd:element name="idlLocation" type="xsd:string" minOccurs="0"/>
980        </xsd:sequence>
981     </xsd:complexType>
982   It provides the tagselements needed to define an unambiguous reference to the executable
983   logicsoftware that implements the control object.object’s application logic, such that the
      3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                       26
       ISO/IEC CD 18012-2  IEC:2008                             27   ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                           2008-12-17
 984   interoperability framework runtime system can invoke the executable software. The intention
 985   is that any type of executable environment can be referenced, such as C runtime code , Java
 986   code, rules engines, etc... The interoperability framework implementation would need to
 987   supportinclude appropriate language bindings for whatever runtime environments are
 988   supported. (for example, the implementation might need to use the correct stack structures for
 989   invoking C executable modules in memory).

 990   The codeLocation tagelement would typically be a Uniform Resource Locator (URL) reference
 991   to the executable logic. This could be a dynamically referenced library routine or other type of
 992   runtime code reference.

 993   The idlLocation tagelement can be used to point toreference an optional Interface Description
 994   Language (IDL) description if needed as part of the implementation. This would typically be
 995   used to provide additional details required by the implementation to support language binding
 996   mismatches.

 997   The properties section of the schema is comprised of one or more property elements:

 998     <xsd:element name="property">
 999        <xsd:complexType>
1000           <xsd:attribute name="name" type="xsd:string"/>
1001           <xsd:attribute name="value" type="xsd:string"/>
1002        </xsd:complexType>
1003     </xsd:element>
1004   It can be used to to define properties that apply to the control object in general, rather than to
1005   individual inputs or outputs. input or output events. A property element consists of a
1006   name/value pair. This could include configuration parameters, calibration information, version
1007   tags, etc.

1008   8.2.28.2.3 Sensor objects
1009   Sensor objects are based on the commons section, but only have definitions of the outputs,
1010   codeBase, and properties components of the commons.

1011   8.2.38.2.4 Actuator objects
1012   Actuator objects are based on the commons section, but only have definitions of the inputs,
1013   codeBase, and properties components of the commons.

1014   8.3    Data type primitives
1015   The purpose of the data type primitives in this specificationInternational Standard is to
1016   support implementation-level interoperability across dissimilar automation systems that are
1017   compatible at a semantic level. In other words, to support interoperability of systems that
1018   perform the same application functions, but which are implemented differently in terms of
1019   communication mechanisms, data description methods, and other syntactic details.

1020   The key requirement is that each property unit type listed in 7.4.5Clause : Property unit type
1021   primitives must map unambiguously to a single data type primitive in 7.4.4Clause : Property
1022   data type primitives. This provides an unambiguous mapping to the underlying execution
1023   environment (for example, a C language environment), and allows unambiguous conversion
1024   between property unit types in different automation systems (for example, one system may
1025   have a temperature sensor that outputs Fahrenheit degrees in floating point representation in
1026   C, but it may need to interoperate with a control object that expects a Celsius degree input in
1027   integer representation in Java).

1028   The baseTypes schema in Annex B.2: Base Types defines the property unit type primitives.
1029   Using these physical property unit type primitives, any physical unit can be derived (Annex
1030   C.1: Derived Types (examples) contains examples of such derivative definitions). Because an
1031   implementation of this International Standard must have an unambiguous mapping from each
1032   unit type primitive (i.e., Base Type) to a single data type primitive in the underlying
1033   implementation programming language (e.g., integer32), the runtime representation for all unit
1034   types (base or derived) is well-defined, and can therefore support automatic conversion
1035   between unit type variations (such as between Fahrenheit and Celsius).
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                       27
       ISO/IEC CD 18012-2  IEC:2008                  28           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                        2008-12-17
1036   9     Application binding map schema
1037   9.1    Overview
1038   The binding map defines the event input/output connections between the sensor, actuator,
1039   and control object inputs and outputs.input and output events of an application. A binding
1040   between two application objects will name the two objects involved, and also the specific input
1041   and output events that are being connected.

1042   An example of a portion of a Binding Map is

1043   …
1044         <binding source="cm02" target="cm01">
1045              <iomapping from="o1" to="i1"/>
1046         </binding>
1047
1048         <binding source="cm05" target="am01">
1049              <iomapping from="o1" to="i1"/>
1050         </binding>
1051
1052         <binding source="sm02" target="cm06">
1053              <iomapping from="o1" to="i1"/>
1054              <iomapping from="o2" to="i2"/>
1055         </binding>
1056   …
1057   In this example, output o1 from control object cm02 is bound to input i1 of control object cm01
1058   in the first clause. The next clause binds output o1 of control object cm05 to input i1 of
1059   actuator object am01, and finally the last clause binds outputs o1 and o2 of sensor object
1060   sm02 to inputs i1 and i2 of control object cm06, repectively.

1061   As shown in this example section, it is the individual inputsinput and outputsoutput events that
1062   are being bound together over the event bus, and not the sensor, actuator, and control
1063   objects. In other words, the binding is at the individual input/output event granularity, and not
1064   at the object granularity. This provides a great deal of detail to the interoperability runtime
1065   implementation, allowing such optimisations as dynamic message payload construction on the
1066   event bus communication links between nodes, basedinteroperability domain interfaces (IDIs).
1067   Depending on the specific subset of output events that need to move from one implementation
1068   nodeIDI to another across the networkevent bus, the interoperability framework runtime
1069   implementation can assemble message payloads that include all the events that must be
1070   transported across the event bus to another device implementing the interoperability domain
1071   at a specific point in time (rather than transporting all output events from a sensor, actuator,
1072   or control object across the networkevent bus communication links).

1073




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                      28
       ISO/IEC CD 18012-2  IEC:2008                    29          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                         2008-12-17
1074                            Annex A Interoperability Procedures
1075   A.1.1    Overview
1076   The interoperability specification consists of the description of:

1077          Application Model and Scenarios

1078          Functions required

1079          States and state transitions within the Functional Classes to ensure safe feature
1080           interaction in the home electronic system.

1081          Functional Classes (logical devices) and their composite objects

1082          Conformance requirements (mandatory, optional and conditional components).                   Comment [RA2]: Editor's note: We want to
                                                                                                            describe the interoperability procedure. Within
1083   A.1.2    Application Models and Scenarios                                                            the product interoperability we define
                                                                                                            application interoperability, i.e., the specification
1084   The scenarios establish the framework for understanding the requirements and defining                of Functional Objects, which represent the
1085   functional profiles required to realise the scenarios. The analysis of the scenarios shall lead to   mapping of the controller devices into this
                                                                                                            application interoperability model. It is the
1086   application models with abstract components (Functional Classes and composing generic                responsibility of the manufacturer to make sure
1087   Objects) by focusing on the functional aspects of the application.                                   that the devices, which are expected to change
                                                                                                            much more often than the application model to
1088   A.1.3    States and state-transitions                                                                which they belong, map into this interoperable
                                                                                                            application model. The manufacturer either has
1089   It is recommended that a graphical presentation, such as Grafcet (IEC 848) or an informal            to provide this mapping, or conform to an
1090   tabular notation is used to specify the state machine for the given application, following the       already specified application model.
1091   style of many OSI/ISO protocol descriptions. The tabular notation consists in listings of            Comment [EE3]: Ron:
1092   events  states  actions  transition rules (the Mealy/Moore model).
                                                                                                            Need to check what else is
1093   A.1.4    Functional Objects and Operational Objects                                                  recommended/standardised out there (ISO /
                                                                                                            IEC). Leave it open for comment. Also Check
1094   The baseline for this work is the functional decomposition in the application model derived          the IEC 61499 for recommendations for
                                                                                                            graphical representation language and tool, or
1095   from the analysis of the application scenarios. The main task is to specify exactly the              what UML defines.
1096   Functional Classes, i.e. the composing objects and Functional Actions. Functional Actions
1097   shall be specified from the application scenarios, but it is recommended that primitive object       Ron is going to check in W3C what they use for
1098   interactions are taken into consideration so as not to build too complex aggregation of object       programming specifications or similar
                                                                                                            specification activities.
1099   action invocations to achieve a specified Functional Action.




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                       29
       ISO/IEC CD 18012-2  IEC:2008              30   ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                            2008-12-17
1100




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                    30
       ISO/IEC CD 18012-2  IEC:2008                                     31               ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                               2008-12-17
1101                                                      Annex BAnnex A
1102                                                        (informative)
1103
1104                         An interoperability application specification (example)
1105   B.1A.1               Lighting application
1106   NOTE: This example has been prepared by Dr. Young-Sung Son of Korea, and will be
1107   inserted when complete.

1108   This example is taken from PDTRISO/IEC/TR 15067-2 Information technology - Home
1109   Electronic System – Guidelines for Product Interoperability (ISO/IEC JTC1 SC25
1110   N889),Systems (HES) application model - Part 2: Lighting Subsystem sectionmodel for HES.

1111   B.2A.2               Procedure
1112   The procedure followed in this example consists in the definition of a generic lighting
1113   subsystem application model (simple case). The components of the system are installed on
1114   two different network systems (namely System A (possibly LonWorks) and System B (possibly
1115   CEBusUPnP). The components of the framework are exemplified in (a) logical interoperable
1116   system, (b) respective functional/device profiles in each system, and (c) examples of the
1117   interworking functionsIWFs for each case.

                                      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                                     Object 2
                                                  LightSwtich                                   LightLamp




                 LonWorks                                                                                        UPnP Light
                LightSwtich
                                                  LonWorks Network                                UPnP Network
1118
1119                                              Figure A.1 - – Lighting application

1120

1121   B.3A.3               Generic lighting subsystem application model
1122   B.3.1A.3.1           Functional classes
1123   The examples will include partial XML schemas for the individual components, and exemplify
1124   the interoperability lexicon as outlined in this document (Generic HES Interoperability –
1125   GHESIO).

1126   B.3.1.1A.3.1.1 LightSwitch
1127   LightSwitch object represents a switch device that includes a functional object, BinarySwitch.
1128   BinarySwitch object has two operational objects, SetSwitchValue and GetSwitchValue.
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                          31
       ISO/IEC CD 18012-2  IEC:2008                  32        ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                     2008-12-17

       <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>

1129                                   Figure A.2 – LightSwitch Object


       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                             32
       ISO/IEC CD 18012-2  IEC:2008                 33        ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                    2008-12-17
1130

1131   B.3.1.2A.3.1.2 LightLamp
1132   LightLamp object represents a lamp device that includes a functional object, PowerSwitch.
1133   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>


       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                              33
       ISO/IEC CD 18012-2  IEC:2008                      34            ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                             2008-12-17
         </eventList>

       </function>

1134                                   Figure A.3 – LightLamp Object

1135

1136   A.4     LonWorks
1137   A.4.1       LonWorks: LightSwitch functional profile
1138   LonWorks LightSwitch device has Switch Object type 3200 that include 4 SNVT (Standard
1139   Network Variable Type). Especially, nviLampValue and nvoLampValueFb are SNVT_switch as
1140   Mandatory Network Variables. nvoRunHours and nvoEnergyCnt are Optional Network
1141   Variables and not used for interoperable application.


                                                    S witch Object
                                                      ty pe 3200



                                  n viLampValue       M a ndatory      n voLampValueFb
                                   S NVT_switch   Ne twork Variables      S NVT_switch



                                                                         n voR unHours
                                                      Optional
                                                                       S NVT_elapsed_tm
                                                  Ne twork Variables


                                                                        n voEnergyCnt
                                                                        S NVT_elec_kwh




                                                    Con figuration
                                                     P r operties

1142

1143   B.3.1.2.1       Figure A.4LightSensor
1144   B.3.2       System A
1145   B.3.2.1       System A: Light Switch Fucntional Profile
1146             System A  SysA – LonWorks LightSwitch Device (Switch Object 3200)

1147

1148   B.3.3A.4.2       LonWorks  LonWorks-IOP interworking function
1149   The interworking function system has several functions. IOP system also translates control
1150   messages because a device in a middleware network understands only its middleware-
1151   dependent message. The IOP system translates the control message to an standard lighting
1152   application model event flow between two different middleware networks from the point of
1153   view of the message translation. The message translation between the LonWorks application
1154   interface and the standard lighting application model interface is done in the IWF.

1155   LonWorks IOP system has two middleware stacks as LonWorks PLC middleware and IOP
1156   middleware. LonWorks PLC middleware built on LonTalk manages network variables. In order
1157   to control LonWorks Devices, LonWorks PLC middleware generate network variables
1158   dynamically. IOP middleware communicates the interoperable system with standard lighting
1159   application model event passing on the event bus.




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                     34
       ISO/IEC CD 18012-2  IEC:2008                                       35                                                ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                                                                  2008-12-17

                                   binding                               IWF
                                                                                        Interoperable System
                                                                         IWF

                                                                                          Global Dispatcher


                                                   Dynamic NV               Device
                                                                           Manager
                                                                                                Func tion
                                                                                                 Ma pper            Event
                                                                                                                   Handler

                                                   ge nerator                                   Event DB

                                                                                           Local Dispatcher
                                                                                                                                               Interoperable System
               Application                                                     Local Middle ware Ne twork Manage me nt




                 NM layer                              NM layer                           TCP/IP                                                      Lig hting Application
                                      or
                 LonTalk                                LonTalk                     Ethernet


                                     NM                                                                                        Interoperable
                                 transaction                                                                                      Protocol
                   Lo n
                  Switch                         PLC     System A - Lo nWorks                                                 IP ne twork
                  De vice
1160

1161                          Figure A.5 – LonWorks InterWorking Function System

1162

1163   The following picture describes how to map LonWorks device function to the generic device
1164   object. Switch object type 3200’s mandatory network variables are mapped to the generic
1165   device objects. nviLampValue SNVT_switch is translated to SetSwitchValue and
1166   nvoLampValueFb SNVT_switch is mapped to GetSwitchValue.

                                                                                                                               <function>
                                                                                                                                 <functionType>BinarySwitch</functionType>
                                                                                                                                 <actionList>
                                                                                                                                    <action>
                              S witch Object                                                                                           <actionId>SetSwitchValue</actionId>
                                ty pe 3200                                                                                             <parameterList>
                                                                                                                                         <parameter>
                                                                                                                                            <parameterId>SwitchValue</parameterId>
                                                                                                                                            <dataType>boolean</dataType>
                                                                                                                                            <direction>in</direction>
          n viLampValue         M a ndatory            n voLampValueFb
                                                                                                                                         </parameter>
           S NVT_switch     Ne twork Variables            S NVT_switch
                                                                                                                                       </parameterList>
                                                                                                                                    </action>

                                                                                                                                     <action>
                                                         n voR unHours
                                Optional                                                                                                <actionId>GetSwitchValue</actionId>
                                                       S NVT_elapsed_tm
                            Ne twork Variables                                                                                          <parameterList>
                                                                                                                                          <parameter>
                                                                                                                                             <parameterId>SwitchValue</parameterId>
                                                                                                                                             <dataType>boolean</dataType>
                                                        n voEnergyCnt
                                                                                                                                             <direction>out</direction>
                                                        S NVT_elec_kwh
                                                                                                                                          </parameter>
                                                                                                                                        </parameterList>
                                                                                                                                     </action>
                                                                                                                                  <actionList>
                                                                                                                                  <eventList>
                                                                                                                                     <event>
                              Con figuration                                                                                            <eventId>SwitchValue</eventId>
                               P r operties                                                                                             <dataType>boolean</dataType>
                                                                                                                                     </event>
                                                                                                                                  </eventList>
                                                                                                                               </function>
1167

1168    Figure A.6 – Functional Mapping LonWorks LightSwitch Device to the Generic LightSwitch

1169

1170   For these mapping, the predefined function mapping table is used. LonWorks function
1171   mapping table consists of Device Mapping Table, Function Mapping Table, Action/Event
1172   Mapping Table, Parameter Mapping Table. Each Table has two columns, global value for
1173   generic object and local value for LonWork device information. Whenever LonWorks devices
1174   are configured by LonTalk, LonWorks InterWorking Function System searches this function
1175   mapping table and recompose the generic object.

       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                                                                                       35
       ISO/IEC CD 18012-2  IEC:2008                                   36          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                        2008-12-17

                           Property                 Field Semantic               Example         Device Mapping
                            Index               Generic Device index                0            Data Structure
                      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                         Action
                                                                                    F1                        List
                        Function List           Available Function List
                                                                                   F2,…
                         Action List              Available Action List             …




         De vice Map. Tbl.             Function Map. Tbl.            Action/Event Map. Tbl.       Parameter Map. Tbl.
         Global       Local              Global       Local        Global          Local             Global      Local
        LIGHTSW    0x05 0x01            LIGHTSW        1         SetSwitch                         SWITCH_ON     200,1
                                                                   Value
                                                                             Update_NV, NV_idx
         Router    0x01 0x01            DIMMING        2                                           SWITCH_OFF     0,0
                                                                  Dimming    Update_NV, NV_idx
             …         …                   …           …                                               …           …
                                                                       …             …

                    Function Mapper
1176

1177                                   Figure A.7 – LonWorks Function Mapping Table

1178

1179

1180   A.5       UPnP
1181   A.5.1       UPnP: LightLamp functional profile
1182   This is a description of UPnP LightLamp device. UPnP LightLamp is described as a
1183   BinaryLight service that includes a DimmingService and SwitchPower.

       <?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>


       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                          36
       ISO/IEC CD 18012-2  IEC:2008                 37         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-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>

1184                              Figure A.8 – UPnP LightLamp Device

1185

1186   A.5.2      UPnP  UPnP-IOP interworking function
1187   UPnP IOP system has two middleware stacks, UPnP middleware and IOP middleware, on top
1188   of TCP/IP. UPnP middleware built on SSDP/GENA/SOAP manages generic control point.
1189   Through generic control point, UPnP middleware can control UPnP device. IOP middleware
1190   communicates the interoperable system with interoperable protocols.

1191




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                             37
       ISO/IEC CD 18012-2  IEC:2008                                                                 38                                            ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                                                                                        2008-12-17


                                                                                 Ge neric             IWF
                    Application                                                Co ntrol Point                       Interoperable System
                                                                                                      IWF

                                                                                                                       Global Dispatcher




                                                                                                                                                                          Interoperable System
                                                                                                                            Function
                                                                                                         Device              Mapper            Event
                                                                                                        Manager                               Handler
                                                                                                                            Event DB



                          N
                   SSDP/GE A/SOAP                                                    N
                                                                              SSDP/GE A/SOAP
                                                                                                                       Local Dispatcher


                                                                                                            Local Middleware Network Management




                          TCP/IP                                                                   TCP/IP                                                                         Lig hting Application


                       Ethernet                           SSDP                                    Ethernet
                                                          GENA
                                                          SOAP

                                                        UPnP                                                                                                Interoperable
                                                      Protocol                                                                                                 Protocol
                         UPnP
                         Light                             IP ne twork                  System B - UPnP                                                 IP ne twork
                        De vice
1192

1193                                                Figure A.9 – UPnP InterWorking Function System

1194

1195   The following picture describes how to map a UPnP device description to the generic device
1196   object. Light(UPnP) device has two services, DimmingServic:1 and SwitchPower:1. But,
1197   SwitchPower is mapped to SetSwitchValue and GetSwitchValue of the generic LightLamp
1198   object.

                                                                                                                                                        <function>
         <?xml version="1.0" encoding="utf-8" ?>
                                                                                                                                                          <functionType>PowerSwitch</functionType>
         <root xmlns="urn:schemas-upnp-org:device-1-0">
           <specVersion>
                                                                                                                                                          <actionList>
              <major>1</major>                                                                                                                              <action>
              <minor>0</minor>                                                                                                                                 <actionId>SetSwitchValue</actionId>
           </specVersion>                                                                                                                                      <parameterList>
           <device>
                                                                                                                                                                 <parameter>
              <deviceType>urn:schemas-upnp-org:device:BinaryLight:1</deviceType>
                                                                                                                                                                    <parameterId>SwitchValue</parameterId>
              <friendlyName>Light (UPnP)</friendlyName>
                                                                                                                                                                    <dataType>boolean</dataType>
              <manufacturer>Intel Corporation</manufacturer>
              <manufacturerURL>http://www.intel.com</manufacturerURL>                                                                                               <direction>in</direction>
              <modelDescription>Software Emulated Light Bulb</modelDescription>                                                                                  </parameter>
              <modelName>Intel CLR Emulated Light Bulb</modelName>                                                                                             </parameterList>
              <modelNumber>XPC-L1</modelNumber>                                                                                                             </action>
              <modelURL>http://www.intel.com/xpc</modelURL>
              <UDN>uuid:55f52e1b-62a7-4e23-841b-283bca65a3fb </UDN>
                                                                                                                                                             <action>
              <serviceList>
                                                                                                                                                                <actionId>GetSwitchValue</actionId>
                 <service>
                       <serviceType>urn:schemas-upnp-org:service:DimmingService:1</serviceType>
                                                                                                                                                                <parameterList>
                       <serviceId>urn:upnp-org:serviceId:DimmingService.0001</serviceId>                                                                          <parameter>
                       <SCPDURL>_DimmingService.0001_scpd.xml</SCPDURL>                                                                                             <parameterId>SwitchValue</parameterId>
                       <controlURL>_DimmingService.0001_control</controlURL>                                                                                         <dataType>boolean</dataType>
                       <eventSubURL>_DimmingService.0001_event</eventSubURL>                                                                                         <direction>out</direction>
                   </service>
                                                                                                                                                                  </parameter>
                                                                                                                                                                </parameterList>
                   <service>
                        <serviceType>urn:schemas-upnp-org:service:SwitchPower:1</serviceType>                                                                </action>
                       <serviceId>urn:upnp-org:serviceId:SwitchPower.0001</serviceId>                                                                      <actionList>
                       <SCPDURL>_SwitchPower.0001_scpd.xml</SCPDURL>                                                                                       <eventList>
                       <controlURL>_SwitchPower.0001_control</controlURL>                                                                                    <event>
                        <eventSubURL>_SwitchPower.0001_event</eventSubURL>                                                                                      <eventId>SwitchValue</eventId>
                   </service>
                                                                                                                                                                <dataType>boolean</dataType>
              </serviceList>
           </device>
                                                                                                                                                             </event>
         </root>                                                                                                                                           </eventList>
                                                                                                                                                        </function>
1199

1200    Figure A.10 – Functional Mapping UPnP LightLamp Device to the Generic LightLamp

1201

1202   UPnP function mapping table consists of Device Mapping Table, Function Mapping Table,
1203   Action/Event Mapping Table, Parameter Mapping Table. Each Table has two columns, globa l
1204   value for generic object and local value for UPnP device information. Whenever UPnP devices
1205   are detected by SSDP, UPnP InterWorking Function System searches this function mapping
1206   table and recompose the generic object.



       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                                                                                                              38
       ISO/IEC CD 18012-2  IEC:2008                                   39              ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                            2008-12-17

                        Property                   Field Semantic                     Example
                                                                                                             Device Mapping
                           Index              Generic Device index                         0
                                                                                                             Data Structure
                     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               Action
                                                                                          F1                             List
                       Service List               Service Table List
                                                                                         F2,…
                        Action List                Action Table List                       …




         De vice Map. Tbl.            Function Map. Tbl.               Action/Event Map. Tbl.                Parameter Map. Tbl.
         Global       Local             Global       Local         Global              Local                    Global      Local
         LIGHT     uuid::sche…        SwitchPower uuid             Power           settarget…                SWITCH_ON        1
          MS        uuid::….           DIMMING       uuid         Dimming           xxaction…                SWITCH_OFF       0
             …         …                  …           …                …                  …                       …           …


                   Function Mapper
1207

1208                                    Figure A.11 – UPnP Function Mapping Table

1209

1210

1211   A.6       Interoperable System – Functional Model
1212   Interoperable system has three tables, Device Table, BindMap Table, EventBus Table. Device
1213   Table contains the information of generic device objects. These objects are registered by
1214   each IWF system through IOP protocols. BindMap Table is related to interoperable
1215   applications. Each interoperable application registers binding of two or more generic objects.
1216   Binding means connection from an output set of events in an operational object to an input set
1217   of events in an operational object. EventBus Table is used for managing event processing.
1218   Whenever device change its status, IWF system catches its behaviour and causes an event to
1219   EventBus Table of Interoperable System. In order to serialize multiple event processing,
1220   Interoperable system uses EventQueue with FIFO style.

1221




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                                     39
       ISO/IEC CD 18012-2  IEC:2008                                    40               ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                              2008-12-17
                                                                              Device Table
                                                                               GD#                 Object ID                      Generic Device Type


         Interoperable System                    Device Object Action (out)      0             UPnP::LightLamp0                         LightLamp

                                                 Device Object Action (in)       1          LonWorks::LightSwitch0                      LightSwitch



               Bind Map Manager                                               Bind Map Table
                  Lighting Application(101)                                    Appl#       Controller Obj#                  Generic Device Obj#

                                                                                101                 3                                   0, 1
                                    Lighting         LightSwitch
                  LightLamp
                                   Controller          Object(1)                …
                  Object(0)
                                   Object(3)

                                                                              Event Bus Table
                              Event Bus Manager                                  Obj#             out action               Obj#                in action
                                   Event Queue                                                   LightSwitch.                           LightingController.
                                                                                     1                                       3
                                                                                               GetSwitchValue1                           SetSwitchValue1
                                                      35
                                                                                               LightingController.                          LightLamp.
                                                                                     3                                       0
                                                                                                GetSwitchValue1                          SetSwitchValue1

                                                                                     …


                                                                              Event Queue
                                                                                         Source    Destination
                                                                              Event#                                             Type                 Value
                                                                                          Obj#        Obj#
                                                       LonWorks LightSwitch
          UPnP Light
                                                                                                                     LightSwitch.GetSwitchValue.
                                                                                35         1             0                                                 On
                                                                                                                            SwtichValue,

                                                                                …
1222

1223   B.3.4           Figure A.12System B
1224   B.3.4.1           System B: Light Lamp Context
1225   B.3.4.2           System B: Light Sensor Context
1226   B.3.4.3           System B  SysB-IOP Interworking Function
1227   Interoperable System – Functional Model

1228




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                                                                 40
       ISO/IEC CD 18012-2  IEC:2008              41      ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                               2008-12-17
1229            Metadata Registry Discussion – Interoperable System Working Flow

1230




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                       41
       ISO/IEC CD 18012-2  IEC:2008                         42            ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                2008-12-17
1231                                             Annex CAnnex B
1232                                               (normative)
1233
1234                                   Base Object Schema Definitions
1235   C.1B.1           Commons
1236   <?xml version="1.0" encoding="UTF-8"?>
1237   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://<namespace URL>"
1238     xmlns="http://<namespace URL>" elementFormDefault="qualified">
1239     <xsd:include schemaLocation="baseTypes.xsd"/>
1240     <xsd:include schemaLocation="derivedTypes.xsd"/>
1241     <xsd:include schemaLocation="baseDefinition.xsd"/>
1242
1243     <!-- Define 'Inputs' element type used by other schema such ControlModel -->
1244
1245     <xsd:element name="QoIRequirement">
1246        <xsd:complexType>
1247           <xsd:sequence>
1248             <xsd:element name="frequency" minOccurs="0">
1249                <xsd:complexType>
1250                   <xsd:complexContent>
1251                     <xsd:extension base="Frequency">
1252                        <xsd:attribute name="selector" type="LogicExpression"/>
1253                     </xsd:extension>
1254                   </xsd:complexContent>
1255                </xsd:complexType>
1256             </xsd:element>
1257             <xsd:element name="maxUncertainty" type="xsd:decimal" minOccurs="0"/>
1258             <xsd:element name="dataPricesion" type="xsd:decimal" minOccurs="0"/>
1259             <xsd:element name="dataAccuracy" type="xsd:decimal" minOccurs="0"/>
1260             <xsd:element name="low" type="xsd:decimal" minOccurs="0"/>
1261             <xsd:element name="high" type="xsd:decimal" minOccurs="0"/>
1262           </xsd:sequence>
1263        </xsd:complexType>
1264     </xsd:element>
1265
1266     <xsd:element name="QoI">
1267        <xsd:complexType>
1268           <xsd:sequence>
1269             <xsd:element name="frequency" minOccurs="0">
1270                <xsd:complexType>
1271                   <xsd:complexContent>
1272                     <xsd:extension base="Frequency">
1273                        <xsd:attribute name="selector" type="LogicExpression"/>
1274                     </xsd:extension>
1275                   </xsd:complexContent>
1276                </xsd:complexType>
1277             </xsd:element>
1278             <xsd:element name="maxUncertainty" type="xsd:decimal" minOccurs="0"/>
1279             <xsd:element name="dataPricesion" type="xsd:decimal" minOccurs="0"/>
1280             <xsd:element name="dataAccuracy" type="xsd:decimal" minOccurs="0"/>
1281             <xsd:element name="low" type="xsd:decimal" minOccurs="0"/>
1282             <xsd:element name="high" type="xsd:decimal" minOccurs="0"/>
1283           </xsd:sequence>
1284        </xsd:complexType>
1285     </xsd:element>
1286
1287     <xsd:element name="input">
1288        <xsd:complexType>
1289           <xsd:sequence>
1290             <xsd:element ref="dataPoint"/>
1291             <xsd:element ref="QoIRequirement" minOccurs="0"/>
1292           </xsd:sequence>
1293        </xsd:complexType>
1294     </xsd:element>
1295
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                            42
       ISO/IEC CD 18012-2  IEC:2008                             43     ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                             2008-12-17
1296     <xsd:element name="output">
1297        <xsd:complexType>
1298           <xsd:sequence>
1299             <xsd:element ref="dataPoint"/>
1300             <xsd:element ref="QoI" minOccurs="0"/>
1301           </xsd:sequence>
1302        </xsd:complexType>
1303     </xsd:element>
1304
1305     <xsd:complexType name="inputs">
1306        <xsd:sequence maxOccurs="unbounded">
1307           <xsd:element ref="input"/>
1308        </xsd:sequence>
1309     </xsd:complexType>
1310
1311     <xsd:complexType name="outputs">
1312        <xsd:sequence maxOccurs="unbounded">
1313           <xsd:element ref="output"/>
1314        </xsd:sequence>
1315     </xsd:complexType>
1316
1317     <xsd:element name="property">
1318        <xsd:complexType>
1319           <xsd:attribute name="name" type="xsd:string"/>
1320           <xsd:attribute name="value" type="xsd:string"/>
1321        </xsd:complexType>
1322     </xsd:element>
1323
1324     <xsd:complexType name="properties">
1325        <xsd:sequence>
1326           <xsd:element ref="property" minOccurs="1" maxOccurs="unbounded"/>
1327        </xsd:sequence>
1328     </xsd:complexType>
1329
1330     <xsd:complexType name="codeBase">
1331        <xsd:sequence>
1332           <xsd:element name="description" type="xsd:string" minOccurs="0"/>
1333           <xsd:element name="codeType" type="codebaseTypes" default="JAVA"/>
1334           <xsd:element name="codeLocation" type="xsd:string" minOccurs="1"/>
1335           <xsd:element name="codeProperties" type="properties" minOccurs="0"/>
1336           <xsd:element name="idlLocation" type="xsd:string" minOccurs="0"/>
1337        </xsd:sequence>
1338     </xsd:complexType>
1339
1340   </xsd:schema>
1341

1342   C.2B.2           Base Types
1343   <?xml version="1.0" encoding="UTF-8"?>
1344   <xsd:schema elementFormDefault="qualified"
1345                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
1346                  xmlns="http://<namespace URL>"
1347                  targetNamespace="http://<namespace URL>">
1348
1349   <xsd:include schemaLocation="baseDefinition.xsd" />
1350
1351        <!-- 7 SI Base Quantities -->
1352
1353        <xsd:complexType name="Length">
1354             <xsd:complexContent>
1355                  <xsd:extension base="AnalogPoint">
1356                       <xsd:attribute name="unit" fixed="meter"/>
1357                  </xsd:extension>
1358             </xsd:complexContent>
1359        </xsd:complexType>
1360
1361        <xsd:complexType name="Time">
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                     43
       ISO/IEC CD 18012-2  IEC:2008                      44            ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                             2008-12-17
1362              <xsd:complexContent>
1363                   <xsd:extension base="AnalogPoint">
1364                        <xsd:attribute name="unit" fixed="second"/>
1365                   </xsd:extension>
1366              </xsd:complexContent>
1367         </xsd:complexType>
1368
1369         <xsd:complexType name="Mass">
1370              <xsd:complexContent>
1371                   <xsd:extension base="AnalogPoint">
1372                        <xsd:attribute name="unit" fixed="kg"/>
1373                   </xsd:extension>
1374              </xsd:complexContent>
1375         </xsd:complexType>
1376
1377         <xsd:complexType name="Temperature">
1378              <xsd:complexContent>
1379                   <xsd:extension base="AnalogPoint">
1380                        <xsd:attribute name="unit" fixed="kelvin" use="required"/>
1381                   </xsd:extension>
1382              </xsd:complexContent>
1383         </xsd:complexType>
1384
1385         <xsd:complexType name="ElectricCurrent">
1386              <xsd:complexContent>
1387                   <xsd:extension base="AnalogPoint">
1388                        <xsd:attribute name="unit" fixed="ampere"/>
1389                   </xsd:extension>
1390              </xsd:complexContent>
1391         </xsd:complexType>
1392
1393         <xsd:complexType name="SubstanceAmount">
1394              <xsd:complexContent>
1395                   <xsd:extension base="AnalogPoint">
1396                        <xsd:attribute name="unit" fixed="mole"/>
1397                   </xsd:extension>
1398              </xsd:complexContent>
1399         </xsd:complexType>
1400
1401         <xsd:complexType name="LuminousIntensity">
1402              <xsd:complexContent>
1403                   <xsd:extension base="AnalogPoint">
1404                        <xsd:attribute name="unit" fixed="candela"/>
1405                   </xsd:extension>
1406              </xsd:complexContent>
1407         </xsd:complexType>
1408
1409   </xsd:schema>

1410   C.3     Derived Types (examples)
1411   <?xml version="1.0" encoding="UTF-8"?>
1412   <xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
1413       xmlns="http://<namespace URL>" targetNamespace="http://<namespace URL>">
1414       <xsd:include schemaLocation="baseTypes.xsd"/>
1415   <!--
1416         The purpose of this document is to define the derived data types
1417         of iDACS XML Schema
1418   -->
1419
1420         <!-- Some Mechnical Quantities -->
1421         <xsd:complexType name="TranslationalSpeed">
1422               <xsd:complexContent>
1423                    <xsd:extension base="AnalogPoint">
1424                         <xsd:attribute name="unit" fixed="meter3-sec"/>
1425                    </xsd:extension>
1426               </xsd:complexContent>
1427         </xsd:complexType>
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                     44
       ISO/IEC CD 18012-2  IEC:2008                     45            ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                            2008-12-17
1428       <xsd:complexType name="AngularSpeed">
1429            <xsd:complexContent>
1430                 <xsd:extension base="AnalogPoint">
1431                      <xsd:attribute name="unit" fixed="rad-sec"/>
1432                 </xsd:extension>
1433            </xsd:complexContent>
1434       </xsd:complexType>
1435
1436       <xsd:complexType name="FlowSpeed">
1437            <xsd:complexContent>
1438                 <xsd:extension base="AnalogPoint">
1439                      <xsd:attribute name="unit" fixed="meter3-sec"/>
1440                 </xsd:extension>
1441            </xsd:complexContent>
1442       </xsd:complexType>
1443       <xsd:complexType name="Force">
1444            <xsd:complexContent>
1445                 <xsd:extension base="AnalogPoint">
1446                      <xsd:attribute name="unit" fixed="newton"/>
1447                 </xsd:extension>
1448            </xsd:complexContent>
1449
1450       </xsd:complexType>
1451       <xsd:complexType name="Pressure">
1452            <xsd:complexContent>
1453                 <xsd:extension base="AnalogPoint">
1454                      <xsd:attribute name="unit" default="pascal">
1455                           <xsd:simpleType>
1456                                  <xsd:restriction base="xsd:token">
1457                                       <xsd:enumeration value="pascal"/>
1458                                       <xsd:enumeration value="atomoshpere"/>
1459                                       <xsd:enumeration value="bar"/>
1460                                  </xsd:restriction>
1461                           </xsd:simpleType>
1462                      </xsd:attribute>
1463                 </xsd:extension>
1464            </xsd:complexContent>
1465       </xsd:complexType>
1466       <xsd:complexType name="Energy">
1467            <xsd:complexContent>
1468                 <xsd:extension base="AnalogPoint">
1469                      <xsd:attribute name="unit" fixed="joule"/>
1470                 </xsd:extension>
1471            </xsd:complexContent>
1472       </xsd:complexType>
1473
1474       <xsd:complexType name="EnergyPower">
1475            <xsd:complexContent>
1476                 <xsd:extension base="AnalogPoint">
1477                      <xsd:attribute name="unit" default="watt">
1478                           <xsd:simpleType>
1479                                  <xsd:restriction base="xsd:token">
1480                                       <xsd:enumeration value="watt"/>
1481                                       <xsd:enumeration value="horse-power"/>
1482                                  </xsd:restriction>
1483                           </xsd:simpleType>
1484                      </xsd:attribute>
1485                 </xsd:extension>
1486            </xsd:complexContent>
1487       </xsd:complexType>
1488
1489       <!-- Electric Quantitiy -->
1490       <xsd:complexType name="ElectricVoltage">
1491             <xsd:complexContent>
1492                   <xsd:extension base="AnalogPoint">
1493                        <xsd:attribute name="unit" fixed="voltage"/>
1494                   </xsd:extension>
1495             </xsd:complexContent>
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                    45
       ISO/IEC CD 18012-2  IEC:2008                      46           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                            2008-12-17
1496       </xsd:complexType>
1497       <xsd:complexType name="ElectricResistance">
1498            <xsd:complexContent>
1499                 <xsd:extension base="AnalogPoint">
1500                      <xsd:attribute name="unit" fixed="ohm"/>
1501                 </xsd:extension>
1502            </xsd:complexContent>
1503       </xsd:complexType>
1504
1505       <xsd:complexType name="MagneticFlux">
1506            <xsd:complexContent>
1507                 <xsd:extension base="AnalogPoint">
1508                      <xsd:attribute name="unit" fixed="weber"/>
1509                 </xsd:extension>
1510            </xsd:complexContent>
1511       </xsd:complexType>
1512
1513       <!-- Others -->
1514
1515       <xsd:complexType name="Frequency">
1516            <xsd:complexContent>
1517                 <xsd:extension base="AnalogPoint">
1518                      <xsd:attribute name="unit" fixed="hertz"/>
1519                 </xsd:extension>
1520            </xsd:complexContent>
1521       </xsd:complexType>
1522
1523       <!-- //Define some new digital datapoints-->
1524
1525       <xsd:complexType name="OnOff-State">
1526            <xsd:complexContent>
1527                 <xsd:extension base="DigitalPoint"/>
1528            </xsd:complexContent>
1529       </xsd:complexType>
1530
1531       <!-- //Define some logicical datapoints-->
1532
1533       <xsd:complexType name="USZipCode">
1534            <xsd:complexContent>
1535                 <xsd:restriction base="String">
1536                      <xsd:sequence>
1537                            <xsd:element name="value" minOccurs="0" maxOccurs="unbounded">
1538                                  <xsd:simpleType>
1539                                       <xsd:restriction base="xsd:string">
1540                                            <xsd:pattern value="\d{5}"/>
1541                                       </xsd:restriction>
1542                                  </xsd:simpleType>
1543                            </xsd:element>
1544                      </xsd:sequence>
1545                 </xsd:restriction>
1546            </xsd:complexContent>
1547       </xsd:complexType>
1548
1549       <xsd:complexType name="USPhoneNumber">
1550            <xsd:complexContent>
1551                 <xsd:restriction base="String">
1552                      <xsd:sequence>
1553                            <xsd:element name="value" minOccurs="0" maxOccurs="unbounded">
1554                                  <xsd:simpleType>
1555                                       <xsd:restriction base="xsd:string">
1556                                            <xsd:pattern value="\d{1}-\d{3}-\d{3}-\d{4}"/>
1557                                       </xsd:restriction>
1558                                  </xsd:simpleType>
1559                            </xsd:element>
1560                      </xsd:sequence>
1561                 </xsd:restriction>
1562            </xsd:complexContent>
1563       </xsd:complexType>
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                    46
       ISO/IEC CD 18012-2  IEC:2008                      47           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                            2008-12-17
1564
1565         <xsd:complexType name="USCurrency">
1566              <xsd:complexContent>
1567                   <xsd:extension base="Decimal">
1568                        <xsd:attribute name="unit" default="dollar">
1569                             <xsd:simpleType>
1570                                    <xsd:restriction base="xsd:token">
1571                                         <xsd:enumeration value="dollar"/>
1572                                         <xsd:enumeration value="cent"/>
1573                                    </xsd:restriction>
1574                             </xsd:simpleType>
1575                        </xsd:attribute>
1576                   </xsd:extension>
1577              </xsd:complexContent>
1578         </xsd:complexType>
1579
1580   </xsd:schema>

1581   C.4     Industry-specific Types (examples)
1582   <?xml version="1.0" encoding="UTF-8"?>
1583   <xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
1584       xmlns="http:// <namespace URL>" targetNamespace="http:// <namespace URL>">
1585         <xsd:include schemaLocation="baseTypes.xsd"/>
1586         <xsd:include schemaLocation="derivedTypes.xsd"/>
1587   <!--
1588         The purpose of this docuemnt is to provide space to allow data type to be defined
1589         for application specific domain.
1590   -->
1591
1592         <!-- A digital point that representing state of HVAC-Switch-->
1593         <xsd:complexType name="HVAC-State">
1594               <xsd:complexContent>
1595                     <xsd:extension base="DigitalPoint">
1596                           <xsd:attribute name="mode" default="auto" use="optional">
1597                                 <xsd:simpleType>
1598                                       <xsd:restriction base="xsd:token">
1599                                            <xsd:enumeration value="heat"/>
1600                                            <xsd:enumeration value="cool"/>
1601                                            <xsd:enumeration value="auto"/>
1602                                       </xsd:restriction>
1603                                 </xsd:simpleType>
1604                           </xsd:attribute>
1605                     </xsd:extension>
1606               </xsd:complexContent>
1607         </xsd:complexType>
1608
1609         <xsd:complexType name="RelativeHumidity">
1610              <xsd:complexContent>
1611                   <xsd:extension base="AnalogPoint">
1612                        <xsd:attribute name="unit" fixed="percent"/>
1613                   </xsd:extension>
1614              </xsd:complexContent>
1615         </xsd:complexType>
1616
1617         <xsd:complexType name="Occupancy">
1618              <xsd:complexContent>
1619                   <xsd:extension base="DigitalPoint"/>
1620              </xsd:complexContent>
1621         </xsd:complexType>
1622
1623         <xsd:complexType name="Motor-Speed">
1624              <xsd:complexContent>
1625                   <xsd:extension base="AnalogPoint">
1626                        <xsd:attribute name="unit">
1627                             <xsd:simpleType>
1628                                   <xsd:restriction base="xsd:token">
1629                                        <xsd:enumeration value="rad-s"/>
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                    47
       ISO/IEC CD 18012-2  IEC:2008                     48           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                           2008-12-17
1630                                       <xsd:enumeration value="rpm"/>
1631                                  </xsd:restriction>
1632                           </xsd:simpleType>
1633                      </xsd:attribute>
1634                 </xsd:extension>
1635            </xsd:complexContent>
1636       </xsd:complexType>
1637
1638       <xsd:complexType name="EnergyPrice">
1639            <xsd:complexContent>
1640                 <xsd:extension base="Double">
1641                      <xsd:attribute name="unit" fixed="dolloars -per-mwh"/>
1642                 </xsd:extension>
1643            </xsd:complexContent>
1644       </xsd:complexType>
1645
1646       <xsd:complexType name="FuelPrice">
1647            <xsd:complexContent>
1648                 <xsd:extension base="Double">
1649                      <xsd:attribute name="unit" fixed="dolloars -per-gallon"/>
1650                 </xsd:extension>
1651            </xsd:complexContent>
1652       </xsd:complexType>
1653
1654       <xsd:complexType name="RFID">
1655            <xsd:complexContent>
1656                 <xsd:extension base="String">
1657                      <xsd:attribute name="standard">
1658                      <xsd:simpleType>
1659                                  <xsd:restriction base="xsd:token">
1660                                       <xsd:enumeration value="epc"/>
1661                                       <xsd:enumeration value="non-epc"/>
1662                                  </xsd:restriction>
1663                           </xsd:simpleType>
1664                      </xsd:attribute>
1665                 </xsd:extension>
1666            </xsd:complexContent>
1667       </xsd:complexType>
1668
1669   </xsd:schema>

1670   C.5B.3          Base Definitions
1671   <?xml version="1.0" encoding="UTF-8"?>
1672   <xsd:schema elementFormDefault="qualified"
1673                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
1674                  xmlns="http://<namespace URL>"
1675                  targetNamespace="http://<namespace URL>">
1676
1677     <xsd:simpleType name="LogicExpression">
1678        <xsd:restriction base="xsd:string">
1679           <xsd:enumeration value="EQT"/>
1680           <xsd:enumeration value="GTT"/>
1681           <xsd:enumeration value="GTE"/>
1682           <xsd:enumeration value="LTT"/>
1683           <xsd:enumeration value="LTE"/>
1684        </xsd:restriction>
1685     </xsd:simpleType>
1686
1687     <xsd:complexType name="dataType">
1688        <xsd:simpleContent>
1689           <xsd:extension base="xsd:anySimpleType">
1690              <xsd:attribute name="dataType" type="defined_data_types"/>
1691           </xsd:extension>
1692        </xsd:simpleContent>
1693     </xsd:complexType>
1694
1695     <xsd:simpleType name="codebaseTypes">
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                   48
       ISO/IEC CD 18012-2  IEC:2008                            49              ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                                     2008-12-17
1696        <xsd:restriction base="xsd:string">
1697           <xsd:enumeration value="C++"/>
1698           <xsd:enumeration value="JAVA"/>
1699           <xsd:enumeration value="XSL"/>
1700        </xsd:restriction>
1701     </xsd:simpleType>
1702
1703     <xsd:simpleType name="SIUnit">
1704       <xsd:restriction base="xsd:string">
1705          <xsd:pattern value="((\([0-3]\))(\((\-)?\d{1}(/\d{1})?\)){9})|((\([4-9]\))(\(0\)){9})"/>
1706          <!--
1707                        field #1 : emumeration
1708                                        0= unit is described by filed #2-#10
1709                                        1= unit is U/U where U is described by filed #2 -10
1710                                        2= unit is log10(U) where U is described by filed #2-10
1711                                        3= unit is log10(U/U) where U is described by filed #2 -10
1712                                        4= unit is digital data, field #2-10 must be zero
1713                                        5= arbitrary scale, field #2-10 must be zero
1714                                        6-9= reserved
1715
1716                        field   #2 : radian        - angle
1717                        field   #3 : steradian   - solid angle
1718                        field   #4 : meter         - length
1719                        field   #5 : kilogram       - mass
1720                        field   #6 : second         - time
1721                        field   #7 : ampere          - electric current
1722                        field   #8 : kelvin       - temperature
1723                        field   #9 : mole         - amount of substance
1724                        field   #10: candela         - luminous intensity
1725                   -->
1726        </xsd:restriction>
1727     </xsd:simpleType>
1728     <xsd:element name="SIUnit" type="SIUnit"/>
1729
1730     <xsd:simpleType name="defined_data_types">
1731        <xsd:restriction base="xsd:string">
1732           <xsd:enumeration value="FLOAT"/>
1733           <xsd:enumeration value="INT"/>
1734           <xsd:enumeration value="BOOLEAN"/>
1735           <xsd:enumeration value="STRING"/>
1736        </xsd:restriction>
1737     </xsd:simpleType>
1738
1739     <xsd:simpleType name="SIMultiple">
1740        <xsd:restriction base="xsd:token">
1741           <xsd:enumeration value="exa"/>
1742           <xsd:enumeration value="peta"/>
1743           <xsd:enumeration value="tera"/>
1744           <xsd:enumeration value="giga"/>
1745           <xsd:enumeration value="mega"/>
1746           <xsd:enumeration value="kilo"/>
1747           <xsd:enumeration value="hecto"/>
1748           <xsd:enumeration value="deka"/>
1749           <xsd:enumeration value="deci"/>
1750           <xsd:enumeration value="centi"/>
1751           <xsd:enumeration value="milli"/>
1752           <xsd:enumeration value="micro"/>
1753           <xsd:enumeration value="nano"/>
1754           <xsd:enumeration value="pico"/>
1755           <xsd:enumeration value="femto"/>
1756           <xsd:enumeration value="atto"/>
1757        </xsd:restriction>
1758     </xsd:simpleType>
1759
1760     <xsd:simpleType name="Multiple">
1761        <xsd:restriction base="xsd:float"/>
1762     </xsd:simpleType>
1763
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                             49
       ISO/IEC CD 18012-2  IEC:2008                      50           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                            2008-12-17
1764     <xsd:complexType name="DataValue">
1765        <xsd:simpleContent>
1766           <xsd:extension base="xsd:anySimpleType"/>
1767        </xsd:simpleContent>
1768     </xsd:complexType>
1769     <xsd:element name="dataValue" type="DataValue"/>
1770
1771     <xsd:complexType name="DataVector">
1772        <xsd:sequence>
1773           <xsd:element name="vlaue" minOccurs="2" maxOccurs="unbounded">
1774              <xsd:complexType>
1775                 <xsd:simpleContent>
1776                    <xsd:extension base="xsd:anySimpleType">
1777                       <xsd:attribute name="id" type="xsd:long"/>
1778                    </xsd:extension>
1779                 </xsd:simpleContent>
1780              </xsd:complexType>
1781           </xsd:element>
1782        </xsd:sequence>
1783     </xsd:complexType>
1784
1785     <xsd:element name="dataVector" type="DataVector">
1786        <xsd:unique name="onDataValuePerID">
1787           <xsd:selector xpath="dataVector/vlaue"/>
1788           <xsd:field xpath="@id"/>
1789        </xsd:unique>
1790     </xsd:element>
1791
1792     <xsd:complexType name="DataUncertainty">
1793        <xsd:simpleContent>
1794           <xsd:extension base="xsd:float">
1795              <xsd:attribute name="interpretation" use="optional">
1796                 <xsd:simpleType>
1797                    <xsd:restriction base="xsd:token">
1798                       <xsd:enumeration value="ISO_GUIDE"/>
1799                       <xsd:enumeration value="CUSTOMER"/>
1800                    </xsd:restriction>
1801                 </xsd:simpleType>
1802              </xsd:attribute>
1803              <xsd:attribute name="coverageFactor" type="xsd:float" use="optional"/>
1804              <xsd:attribute name="customerFactor" type="xsd:float" use="optional"/>
1805           </xsd:extension>
1806        </xsd:simpleContent>
1807     </xsd:complexType>
1808
1809     <xsd:complexType name="DataPoint" abstract="true">
1810        <xsd:simpleContent>
1811           <xsd:extension base="xsd:string">
1812              <xsd:attribute name="name" type="xsd:Name" use="optional"/>
1813              <xsd:attribute name="id" type="xsd:ID" use="optional"/>
1814              <xsd:attribute name="isVector" type="xsd:boolean" use="optional" default="false"/>
1815           </xsd:extension>
1816        </xsd:simpleContent>
1817     </xsd:complexType>
1818     <xsd:element name="dataPoint" type="DataPoint"/>
1819
1820     <xsd:complexType name="PhysicalDataPoint">
1821        <xsd:simpleContent>
1822           <xsd:extension base="DataPoint">
1823              <xsd:attribute name="siunit" type="SIUnit" use="required"/>
1824           </xsd:extension>
1825        </xsd:simpleContent>
1826     </xsd:complexType>
1827
1828       <!-- Define build-in datatype array,
1829             currently, they are not used anywhere -->
1830
1831       <xsd:simpleType name="DecimalArray">
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                        50
       ISO/IEC CD 18012-2  IEC:2008                  51           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                        2008-12-17
1832            <xsd:list itemType="xsd:decimal"/>
1833       </xsd:simpleType>
1834
1835       <xsd:simpleType name="IntegerArray">
1836            <xsd:list itemType="xsd:integer"/>
1837       </xsd:simpleType>
1838
1839       <xsd:simpleType name="ShortArray">
1840            <xsd:list itemType="xsd:short"/>
1841       </xsd:simpleType>
1842
1843       <xsd:simpleType name="ByteArray">
1844            <xsd:list itemType="xsd:byte"/>
1845       </xsd:simpleType>
1846
1847       <xsd:simpleType name="LongArray">
1848            <xsd:list itemType="xsd:long"/>
1849       </xsd:simpleType>
1850
1851       <xsd:simpleType name="FloatArray">
1852            <xsd:list itemType="xsd:float"/>
1853       </xsd:simpleType>
1854
1855       <xsd:simpleType name="DoubleArray">
1856            <xsd:list itemType="xsd:double"/>
1857       </xsd:simpleType>
1858
1859     <xsd:complexType name="LogicDataPoint" abstract="true">
1860        <xsd:complexContent>
1861           <xsd:extension base="DataPoint"/>
1862        </xsd:complexContent>
1863     </xsd:complexType>
1864
1865     <xsd:element name="logicDataPoint" type="LogicDataPoint"/>
1866       <xsd:complexType name="String">
1867             <xsd:complexContent>
1868                  <xsd:extension base="LogicDataPoint">
1869                       <xsd:sequence>
1870                            <xsd:element name="value" type="xsd:string" minOccurs="0"
1871     maxOccurs="unbounded"/>
1872                       </xsd:sequence>
1873                  </xsd:extension>
1874             </xsd:complexContent>
1875       </xsd:complexType>
1876
1877       <xsd:complexType name="Boolean">
1878            <xsd:complexContent>
1879                 <xsd:extension base="LogicDataPoint">
1880                      <xsd:sequence>
1881                           <xsd:element name="value" type="xsd:boolean" minOccurs="0"
1882     maxOccurs="unbounded"/>
1883                      </xsd:sequence>
1884                 </xsd:extension>
1885            </xsd:complexContent>
1886       </xsd:complexType>
1887
1888       <xsd:complexType name="Decimal">
1889            <xsd:complexContent>
1890                 <xsd:extension base="LogicDataPoint">
1891                      <xsd:sequence>
1892                           <xsd:element name="value" type="xsd:decimal" minOccurs="0"
1893     maxOccurs="unbounded"/>
1894                      </xsd:sequence>
1895                 </xsd:extension>
1896            </xsd:complexContent>
1897       </xsd:complexType>
1898
1899       <xsd:complexType name="Integer">
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                51
       ISO/IEC CD 18012-2  IEC:2008                  52          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                       2008-12-17
1900            <xsd:complexContent>
1901                 <xsd:extension base="LogicDataPoint">
1902                      <xsd:sequence>
1903                           <xsd:element name="value" type="xsd:integer" minOccurs="0"
1904     maxOccurs="unbounded"/>
1905                      </xsd:sequence>
1906                 </xsd:extension>
1907            </xsd:complexContent>
1908       </xsd:complexType>
1909
1910
1911       <xsd:complexType name="Int">
1912            <xsd:complexContent>
1913                 <xsd:extension base="LogicDataPoint">
1914                      <xsd:sequence>
1915                           <xsd:element name="value" type="xsd:int" minOccurs="0"
1916     maxOccurs="unbounded"/>
1917                      </xsd:sequence>
1918                 </xsd:extension>
1919            </xsd:complexContent>
1920       </xsd:complexType>
1921
1922       <xsd:complexType name="Long">
1923            <xsd:complexContent>
1924                 <xsd:extension base="LogicDataPoint">
1925                      <xsd:sequence>
1926                           <xsd:element name="value" type="xsd:long" minOccurs="0"
1927     maxOccurs="unbounded"/>
1928                      </xsd:sequence>
1929                 </xsd:extension>
1930            </xsd:complexContent>
1931       </xsd:complexType>
1932
1933       <xsd:complexType name="Short">
1934            <xsd:complexContent>
1935                 <xsd:extension base="LogicDataPoint">
1936                      <xsd:sequence>
1937                           <xsd:element name="value" type="xsd:short" minOccurs="0"
1938     maxOccurs="unbounded"/>
1939                      </xsd:sequence>
1940                 </xsd:extension>
1941            </xsd:complexContent>
1942       </xsd:complexType>
1943
1944       <xsd:complexType name="Byte">
1945            <xsd:complexContent>
1946                 <xsd:extension base="LogicDataPoint">
1947                      <xsd:sequence>
1948                           <xsd:element name="value" type="xsd:byte" minOccurs="0"
1949     maxOccurs="unbounded"/>
1950                      </xsd:sequence>
1951                 </xsd:extension>
1952            </xsd:complexContent>
1953       </xsd:complexType>
1954
1955       <xsd:complexType name="Float">
1956            <xsd:complexContent>
1957                 <xsd:extension base="LogicDataPoint">
1958                      <xsd:sequence>
1959                           <xsd:element name="value" type="xsd:float" minOccurs="0"
1960     maxOccurs="unbounded"/>
1961                      </xsd:sequence>
1962                 </xsd:extension>
1963            </xsd:complexContent>
1964       </xsd:complexType>
1965
1966       <xsd:complexType name="Double">
1967            <xsd:complexContent>
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                               52
       ISO/IEC CD 18012-2  IEC:2008                   53          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                        2008-12-17
1968                 <xsd:extension base="LogicDataPoint">
1969                      <xsd:sequence>
1970                           <xsd:element name="value" type="xsd:double" minOccurs="0"
1971     maxOccurs="unbounded"/>
1972                      </xsd:sequence>
1973                 </xsd:extension>
1974            </xsd:complexContent>
1975       </xsd:complexType>
1976
1977       <xsd:complexType name="AnyURI">
1978            <xsd:complexContent>
1979                 <xsd:extension base="LogicDataPoint">
1980                      <xsd:sequence>
1981                           <xsd:element name="value" type="xsd:anyURI" minOccurs="0"
1982     maxOccurs="unbounded"/>
1983                      </xsd:sequence>
1984                 </xsd:extension>
1985            </xsd:complexContent>
1986       </xsd:complexType>
1987
1988     <xsd:complexType name="DigitalPoint">
1989        <xsd:complexContent>
1990           <xsd:extension base="PhysicalDataPoint">
1991              <xsd:sequence>
1992                 <xsd:element name="probability" minOccurs="0">
1993                    <xsd:simpleType>
1994                       <xsd:restriction base="xsd:decimal">
1995                          <xsd:minInclusive value="0"/>
1996                          <xsd:maxInclusive value="1"/>
1997                       </xsd:restriction>
1998                    </xsd:simpleType>
1999                 </xsd:element>
2000                 <xsd:element name="value" type="xsd:boolean" minOccurs="0"
2001     maxOccurs="unbounded"/>
2002              </xsd:sequence>
2003           </xsd:extension>
2004        </xsd:complexContent>
2005     </xsd:complexType>
2006     <xsd:element name="digitalPoint" type="DigitalPoint"/>
2007
2008     <xsd:complexType name="AnalogPoint">
2009        <xsd:complexContent>
2010           <xsd:extension base="PhysicalDataPoint">
2011              <xsd:sequence>
2012                 <xsd:element name="uncertainty" type="xsd:decimal" minOccurs="0"/>
2013                 <xsd:element name="value" type="xsd:float" minOccurs="0" maxOccurs="unbounded"/>
2014              </xsd:sequence>
2015              <xsd:attribute name="unitMultiple" use="optional">
2016                 <xsd:simpleType>
2017                    <xsd:union>
2018                       <xsd:simpleType>
2019                          <xsd:restriction base="SIMultiple"/>
2020                       </xsd:simpleType>
2021                       <xsd:simpleType>
2022                          <xsd:restriction base="Multiple"/>
2023                       </xsd:simpleType>
2024                    </xsd:union>
2025                 </xsd:simpleType>
2026              </xsd:attribute>
2027           </xsd:extension>
2028        </xsd:complexContent>
2029     </xsd:complexType>
2030     <xsd:element name="AnalogPoint" type="AnalogPoint"/>
2031
2032   </xsd:schema>




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                         53
       ISO/IEC CD 18012-2  IEC:2008                   54          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                        2008-12-17
2033   C.6B.4          Control Objects
2034   <?xml version="1.0" encoding="UTF-8"?>
2035   <xsd:schema elementFormDefault="qualified"
2036                  attributeFormDefault="unqualified"
2037                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
2038                  xmlns="http://<namespace URL>"
2039                  targetNamespace="http://<namespace URL>">
2040     <xsd:include schemaLocation="commons.xsd"/>
2041     <xsd:include schemaLocation="derivedTypes.xsd"/>
2042     <xsd:include schemaLocation="industryTypes.xsd"/>
2043
2044     <xsd:element name="controlModel">
2045        <xsd:complexType>
2046           <xsd:sequence>
2047              <xsd:element name="category" type="xsd:string" minOccurs="0"/>
2048              <xsd:element name="inputs" type="inputs" maxOccurs="unbounded"/>
2049              <xsd:element name="outputs" type="outputs" maxOccurs="unbounded"/>
2050              <xsd:element name="modelProperties" type="properties" minOccurs="0"/>
2051              <xsd:element name="codeBase" type="codeBase"/>
2052           </xsd:sequence>
2053           <xsd:attribute name="name" type="xsd:Name"/>
2054           <xsd:attribute name="id" type="xsd:ID"/>
2055        </xsd:complexType>
2056     </xsd:element>
2057
2058   </xsd:schema>

2059   C.7B.5          Sensor Objects
2060   <?xml version="1.0" encoding="UTF-8"?>
2061   <xsd:schema elementFormDefault="qualified"
2062                  attributeFormDefault="unqualified"
2063                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
2064                  xmlns="http://<namespace URL>"
2065                  targetNamespace="http://<namespace URL>">
2066     <xsd:include schemaLocation="commons.xsd"/>
2067     <xsd:include schemaLocation="derivedTypes.xsd"/>
2068     <xsd:include schemaLocation="industryTypes.xsd"/>
2069
2070         <xsd:element name="sensorModel">
2071        <xsd:complexType>
2072           <xsd:sequence>
2073              <xsd:element name="category" type="xsd:string" minOccurs="0"/>
2074              <xsd:element name="inputs" type="inputs" minOccurs="0" maxOccurs="unbounded"/>
2075              <xsd:element name="outputs" type="outputs" maxOccurs="unbounded"/>
2076              <xsd:element name="modelProperties" type="properties" minOccurs="0"/>
2077              <xsd:element name="codeBase" type="codeBase"/>
2078           </xsd:sequence>
2079           <xsd:attribute name="name" type="xsd:Name"/>
2080           <xsd:attribute name="id" type="xsd:ID"/>
2081        </xsd:complexType>
2082     </xsd:element>
2083
2084   </xsd:schema>

2085   C.8B.6          Actuator Objects
2086   <?xml version="1.0" encoding="UTF-8"?>
2087   <xsd:schema elementFormDefault="qualified"
2088                  attributeFormDefault="unqualified"
2089                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
2090                  xmlns="http://<namespace URL>"
2091                  targetNamespace="http://<namespace URL>">
2092     <xsd:include schemaLocation="commons.xsd"/>
2093     <xsd:include schemaLocation="derivedTypes.xsd"/>
2094     <xsd:include schemaLocation="industryTypes.xsd"/>
2095
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                    54
       ISO/IEC CD 18012-2  IEC:2008                    55           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                          2008-12-17
2096      <xsd:element name="actuatorModel">
2097        <xsd:complexType>
2098           <xsd:sequence>
2099              <xsd:element name="category" type="xsd:string" minOccurs="0"/>
2100              <xsd:element name="inputs" type="inputs" maxOccurs="unbounded"/>
2101              <xsd:element name="outputs" type="outputs" minOccurs="0" maxOccurs="unbounded"/>
2102              <xsd:element name="modelProperties" type="properties" minOccurs="0"/>
2103              <xsd:element name="codeBase" type="codeBase"/>
2104           </xsd:sequence>
2105           <xsd:attribute name="name" type="xsd:Name"/>
2106           <xsd:attribute name="id" type="xsd:ID"/>
2107        </xsd:complexType>
2108     </xsd:element>
2109
2110   </xsd:schema>

2111   C.9B.7           Application Binding Map
2112   <?xml version="1.0" encoding="UTF-8"?>
2113   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
2114
2115   <xsd:element name = "application">
2116
2117   <xsd:complexType>
2118        <xsd:sequence>
2119             <xsd:element ref = "models"/>
2120             <xsd:element ref="connections"/>
2121        </xsd:sequence>
2122   </xsd:complexType>
2123
2124   </xsd:element>
2125
2126   <xsd:element name="models">
2127        <xsd:complexType>
2128              <xsd:sequence>
2129           <xsd:element ref="model" maxOccurs="unbounded"/>
2130           </xsd:sequence>
2131        </xsd:complexType>
2132    </xsd:element>
2133
2134   <xsd:element name = "model">
2135        <xsd:complexType>
2136             <xsd:attribute name = "name" type = "xsd:string"/>
2137             <xsd:attribute name = "type" type = "modelType" default = "CM"/>
2138             <xsd:attribute name = "filename" type = "xsd:string"/>
2139        </xsd:complexType>
2140   </xsd:element>
2141
2142   <xsd:element name="connections">
2143        <xsd:complexType>
2144              <xsd:sequence>
2145           <xsd:element ref="connection" maxOccurs="unbounded"/>
2146           </xsd:sequence>
2147        </xsd:complexType>
2148    </xsd:element>
2149
2150   <xsd:element name = "connection">
2151        <xsd:complexType>
2152             <xsd:sequence>
2153                  <xsd:element ref = "source" />
2154                  <xsd:element ref = "target"/>
2155             </xsd:sequence>
2156        </xsd:complexType>
2157   </xsd:element>
2158
2159   <xsd:element name = "source">
2160        <xsd:complexType>
2161             <xsd:sequence>
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                      55
       ISO/IEC CD 18012-2  IEC:2008                      56         ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                          2008-12-17
2162                  <xsd:element ref = "map"/>
2163             </xsd:sequence>
2164        </xsd:complexType>
2165   </xsd:element>
2166
2167   <xsd:element name = "target">
2168        <xsd:complexType>
2169             <xsd:sequence>
2170                  <xsd:element ref = "map" maxOccurs="unbounded"/>
2171             </xsd:sequence>
2172        </xsd:complexType>
2173   </xsd:element>
2174
2175   <xsd:element name = "map">
2176        <xsd:complexType>
2177             <xsd:attribute name = "id" type = "xsd:string"/>
2178             <xsd:attribute name = "var" type = "xsd:string"/>
2179        </xsd:complexType>
2180   </xsd:element>
2181
2182   <xsd:simpleType name="modelType">
2183        <xsd:restriction base="xsd:string">
2184           <xsd:enumeration value="CM"/>
2185           <xsd:enumeration value="DA"/>
2186        </xsd:restriction>
2187     </xsd:simpleType>
2188
2189   </xsd:schema>




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                  56
       ISO/IEC CD 18012-2  IEC:2008                      57           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                            2008-12-17
2190                                                Annex C
2191                                              (informative)
2192
2193                           Base Object Schema Extension Examples
2194   C.1     Derived Types (examples)
2195   <?xml version="1.0" encoding="UTF-8"?>
2196   <xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
2197       xmlns="http://<namespace URL>" targetNamespace="http://<namespace URL>">
2198       <xsd:include schemaLocation="baseTypes.xsd"/>
2199   <!--
2200         The purpose of this document is to define the derived data types
2201         of iDACS XML Schema
2202   -->
2203
2204         <!-- Some Mechnical Quantities -->
2205         <xsd:complexType name="TranslationalSpeed">
2206               <xsd:complexContent>
2207                    <xsd:extension base="AnalogPoint">
2208                         <xsd:attribute name="unit" fixed="meter3-sec"/>
2209                    </xsd:extension>
2210               </xsd:complexContent>
2211         </xsd:complexType>
2212         <xsd:complexType name="AngularSpeed">
2213               <xsd:complexContent>
2214                    <xsd:extension base="AnalogPoint">
2215                         <xsd:attribute name="unit" fixed="rad-sec"/>
2216                    </xsd:extension>
2217               </xsd:complexContent>
2218         </xsd:complexType>
2219
2220         <xsd:complexType name="FlowSpeed">
2221              <xsd:complexContent>
2222                   <xsd:extension base="AnalogPoint">
2223                        <xsd:attribute name="unit" fixed="meter3-sec"/>
2224                   </xsd:extension>
2225              </xsd:complexContent>
2226         </xsd:complexType>
2227         <xsd:complexType name="Force">
2228              <xsd:complexContent>
2229                   <xsd:extension base="AnalogPoint">
2230                        <xsd:attribute name="unit" fixed="newton"/>
2231                   </xsd:extension>
2232              </xsd:complexContent>
2233
2234         </xsd:complexType>
2235         <xsd:complexType name="Pressure">
2236              <xsd:complexContent>
2237                   <xsd:extension base="AnalogPoint">
2238                        <xsd:attribute name="unit" default="pascal">
2239                             <xsd:simpleType>
2240                                    <xsd:restriction base="xsd:token">
2241                                         <xsd:enumeration value="pascal"/>
2242                                         <xsd:enumeration value="atomoshpere"/>
2243                                         <xsd:enumeration value="bar"/>
2244                                    </xsd:restriction>
2245                             </xsd:simpleType>
2246                        </xsd:attribute>
2247                   </xsd:extension>
2248              </xsd:complexContent>
2249         </xsd:complexType>
2250         <xsd:complexType name="Energy">
2251              <xsd:complexContent>
2252                   <xsd:extension base="AnalogPoint">
2253                        <xsd:attribute name="unit" fixed="joule"/>
2254                   </xsd:extension>
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                    57
       ISO/IEC CD 18012-2  IEC:2008                      58           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                            2008-12-17
2255            </xsd:complexContent>
2256       </xsd:complexType>
2257
2258       <xsd:complexType name="EnergyPower">
2259            <xsd:complexContent>
2260                 <xsd:extension base="AnalogPoint">
2261                      <xsd:attribute name="unit" default="watt">
2262                           <xsd:simpleType>
2263                                  <xsd:restriction base="xsd:token">
2264                                       <xsd:enumeration value="watt"/>
2265                                       <xsd:enumeration value="horse-power"/>
2266                                  </xsd:restriction>
2267                           </xsd:simpleType>
2268                      </xsd:attribute>
2269                 </xsd:extension>
2270            </xsd:complexContent>
2271       </xsd:complexType>
2272
2273       <!-- Electric Quantitiy -->
2274       <xsd:complexType name="ElectricVoltage">
2275             <xsd:complexContent>
2276                   <xsd:extension base="AnalogPoint">
2277                        <xsd:attribute name="unit" fixed="voltage"/>
2278                   </xsd:extension>
2279             </xsd:complexContent>
2280       </xsd:complexType>
2281       <xsd:complexType name="ElectricResistance">
2282             <xsd:complexContent>
2283                   <xsd:extension base="AnalogPoint">
2284                        <xsd:attribute name="unit" fixed="ohm"/>
2285                   </xsd:extension>
2286             </xsd:complexContent>
2287       </xsd:complexType>
2288
2289       <xsd:complexType name="MagneticFlux">
2290            <xsd:complexContent>
2291                 <xsd:extension base="AnalogPoint">
2292                      <xsd:attribute name="unit" fixed="weber"/>
2293                 </xsd:extension>
2294            </xsd:complexContent>
2295       </xsd:complexType>
2296
2297       <!-- Others -->
2298
2299       <xsd:complexType name="Frequency">
2300            <xsd:complexContent>
2301                 <xsd:extension base="AnalogPoint">
2302                      <xsd:attribute name="unit" fixed="hertz"/>
2303                 </xsd:extension>
2304            </xsd:complexContent>
2305       </xsd:complexType>
2306
2307       <!-- //Define some new digital datapoints-->
2308
2309       <xsd:complexType name="OnOff-State">
2310            <xsd:complexContent>
2311                 <xsd:extension base="DigitalPoint"/>
2312            </xsd:complexContent>
2313       </xsd:complexType>
2314
2315       <!-- //Define some logicical datapoints-->
2316
2317       <xsd:complexType name="USZipCode">
2318            <xsd:complexContent>
2319                 <xsd:restriction base="String">
2320                      <xsd:sequence>
2321                            <xsd:element name="value" minOccurs="0" maxOccurs="unbounded">
2322                                  <xsd:simpleType>
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                    58
       ISO/IEC CD 18012-2  IEC:2008                       59           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                             2008-12-17
2323                                         <xsd:restriction base="xsd:string">
2324                                              <xsd:pattern value="\d{5}"/>
2325                                         </xsd:restriction>
2326                                    </xsd:simpleType>
2327                              </xsd:element>
2328                        </xsd:sequence>
2329                   </xsd:restriction>
2330              </xsd:complexContent>
2331         </xsd:complexType>
2332
2333         <xsd:complexType name="USPhoneNumber">
2334              <xsd:complexContent>
2335                   <xsd:restriction base="String">
2336                        <xsd:sequence>
2337                              <xsd:element name="value" minOccurs="0" maxOccurs="unbounded">
2338                                    <xsd:simpleType>
2339                                         <xsd:restriction base="xsd:string">
2340                                              <xsd:pattern value="\d{1}-\d{3}-\d{3}-\d{4}"/>
2341                                         </xsd:restriction>
2342                                    </xsd:simpleType>
2343                              </xsd:element>
2344                        </xsd:sequence>
2345                   </xsd:restriction>
2346              </xsd:complexContent>
2347         </xsd:complexType>
2348
2349         <xsd:complexType name="USCurrency">
2350              <xsd:complexContent>
2351                   <xsd:extension base="Decimal">
2352                        <xsd:attribute name="unit" default="dollar">
2353                             <xsd:simpleType>
2354                                    <xsd:restriction base="xsd:token">
2355                                         <xsd:enumeration value="dollar"/>
2356                                         <xsd:enumeration value="cent"/>
2357                                    </xsd:restriction>
2358                             </xsd:simpleType>
2359                        </xsd:attribute>
2360                   </xsd:extension>
2361              </xsd:complexContent>
2362         </xsd:complexType>
2363
2364   </xsd:schema>

2365   C.2     Industry-specific Types (examples)
2366   <?xml version="1.0" encoding="UTF-8"?>
2367   <xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.o rg/2001/XMLSchema"
2368       xmlns="http:// <namespace URL>" targetNamespace="http:// <namespace URL>">
2369         <xsd:include schemaLocation="baseTypes.xsd"/>
2370         <xsd:include schemaLocation="derivedTypes.xsd"/>
2371   <!--
2372         The purpose of this docuemnt is to provide space to allow data type to be defined
2373         for application specific domain.
2374   -->
2375
2376         <!-- A digital point that representing state of HVAC-Switch-->
2377         <xsd:complexType name="HVAC-State">
2378               <xsd:complexContent>
2379                     <xsd:extension base="DigitalPoint">
2380                           <xsd:attribute name="mode" default="auto" use="optional">
2381                                 <xsd:simpleType>
2382                                       <xsd:restriction base="xsd:token">
2383                                            <xsd:enumeration value="heat"/>
2384                                            <xsd:enumeration value="cool"/>
2385                                            <xsd:enumeration value="auto"/>
2386                                       </xsd:restriction>
2387                                 </xsd:simpleType>
2388                           </xsd:attribute>
       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                     59
       ISO/IEC CD 18012-2  IEC:2008                     60           ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                           2008-12-17
2389                 </xsd:extension>
2390            </xsd:complexContent>
2391       </xsd:complexType>
2392
2393       <xsd:complexType name="RelativeHumidity">
2394            <xsd:complexContent>
2395                 <xsd:extension base="AnalogPoint">
2396                      <xsd:attribute name="unit" fixed="percent"/>
2397                 </xsd:extension>
2398            </xsd:complexContent>
2399       </xsd:complexType>
2400
2401       <xsd:complexType name="Occupancy">
2402            <xsd:complexContent>
2403                 <xsd:extension base="DigitalPoint"/>
2404            </xsd:complexContent>
2405       </xsd:complexType>
2406
2407       <xsd:complexType name="Motor-Speed">
2408            <xsd:complexContent>
2409                 <xsd:extension base="AnalogPoint">
2410                      <xsd:attribute name="unit">
2411                           <xsd:simpleType>
2412                                  <xsd:restriction base="xsd:token">
2413                                       <xsd:enumeration value="rad-s"/>
2414                                       <xsd:enumeration value="rpm"/>
2415                                  </xsd:restriction>
2416                           </xsd:simpleType>
2417                      </xsd:attribute>
2418                 </xsd:extension>
2419            </xsd:complexContent>
2420       </xsd:complexType>
2421
2422       <xsd:complexType name="EnergyPrice">
2423            <xsd:complexContent>
2424                 <xsd:extension base="Double">
2425                      <xsd:attribute name="unit" fixed="dolloars -per-mwh"/>
2426                 </xsd:extension>
2427            </xsd:complexContent>
2428       </xsd:complexType>
2429
2430       <xsd:complexType name="FuelPrice">
2431            <xsd:complexContent>
2432                 <xsd:extension base="Double">
2433                      <xsd:attribute name="unit" fixed="dolloars -per-gallon"/>
2434                 </xsd:extension>
2435            </xsd:complexContent>
2436       </xsd:complexType>
2437
2438       <xsd:complexType name="RFID">
2439            <xsd:complexContent>
2440                 <xsd:extension base="String">
2441                      <xsd:attribute name="standard">
2442                      <xsd:simpleType>
2443                                  <xsd:restriction base="xsd:token">
2444                                       <xsd:enumeration value="epc"/>
2445                                       <xsd:enumeration value="non-epc"/>
2446                                  </xsd:restriction>
2447                           </xsd:simpleType>
2448                      </xsd:attribute>
2449                 </xsd:extension>
2450            </xsd:complexContent>
2451       </xsd:complexType>
2452
2453   </xsd:schema>




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                   60
       ISO/IEC CD 18012-2  IEC:2008                            61       ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                              2008-12-17
2454                                                    Annex D
2455                                                  (informative)
2456
2457                                           Notes on interoperability
2458   D.1     General comments on taxonomy and lexiconthe interoperability
2459           framework specification
2460   This part of the standard defines the taxonomy and lexiconinteroperability framework
2461   specification for describing distributed automation systems. The taxonomy consists of the
2462   classification of the applications in a framework that may be used, together with the lexicon,
2463   to instantiate an interoperable system composed of components on the same or dissimilar
2464   networks. The lexicon is the set of common data type primitives and the associated common
2465   action primitives that, within the taxonomy framework, can be used to describe a set of
2466   application    models.     The    taxonomyinteroperability  framework    and    the    lexicon
2467   operatespecification operates at the application layer of the OSI reference model. This
2468   taxonomy and lexicon defineinteroperability framework specification defines a common
2469   generic automation system application framework to be used for syntactic translation while
2470   maintaining the semantics of the application behaviour, independent of the implementation or
2471   mode of operation.

2472   D.2     Taxonomy definitions

2473   Application Domain::= SEQ of { Application Model }

2474   Application Model::= SEQ of { Functional Object, Operational Object }

2475   Functional Object ::= SEQ of { Operational Object, Functional Actions }

2476   Object ::= SEQ of { Basic Property, Operational Property, Configuration Property }

2477   Device Profile ::= A document description of the minimum a collection of Functional Class
2478   instances that are implemented in a product to allow this product (physical device) to comply
2479   with the functionality specified in the Application Model(s).

2480   D.3     Taxonomy of the existing systems
2481   The Table D.1following table represents a mapping between different entity names into the
2482   interoperability taxonomy framework.

2483                                    Table D.1 – Terminology mapping table
             LonWorks                  CEBus         EIB/KNXISO/IEC 14            EHS           GenericISO/IEC 180
                                                          543-3-x                                      12-2
       Network /              Instance Variable      Property            Object (Object Type)   Property
       Configuration
       Variable
       Functional Block       Object                 Object              Object                 Object
       Functional Profile     Context                Device              Device                 Functional Class
                                                                                                (logical device)
       ?(Application Model)   ? (Application Model   Application         Application Model      Application Model
                              / Group)               Specification
       Device Profile         Device Profile         Device Profile      Device Profile         Device Profile

2484   For example, the LonWorks Network Variable is not strictly an object, according to the
2485   definition adopted in this International Standard, as it does not exhibit behaviour. But it is the
2486   equivalent of the EHS::Object because it is implicitly accessed at application level through
2487   get/set actions, where allowed respectively by the access properties defined in the functional
2488   profile for the variable.



       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                                     61
       ISO/IEC CD 18012-2  IEC:2008                62          ISO/IEC JTC 1/SC 25/WG 1 N 1360
                                                                                     2008-12-17
2489   Objects may have direction (in/out, producer/consumer - inherited through their properties),
2490   access properties, an access list and notify list.

2491                                         Bibliography
2492   ISO/IEC 14543, Information technology — Home electronic system (HES) — Architecture (all
2493   parts)

2494   ISO/IEC 15045, Information technology — Home electronic system (HES) — HES Gateway
2495   (all parts)




       3ff35cc6-8a3c-4807-8882-82f1ecc1844a.doc                                                 62

								
To top