CLC/TS 50560:2014

SLOVENSKI STANDARD
01-december-2014
Okvirne specifikacije zahtev za interoperabilnost
Interoperability framework requirement specification
Rahmenspezifikation für Interoperabilitätsanforderungen (IFRS)
Spécification d’exigences cadre d’interopérabilité
Ta slovenski standard je istoveten z: CLC/TS 50560:2014
ICS:
35.240.01 Uporabniške rešitve Application of information
informacijske tehnike in technology in general
tehnologije na splošno
97.120 Avtomatske krmilne naprave Automatic controls for
za dom household use
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION CLC/TS 50560

SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
October 2014
ICS 35.240.99; 97.120 Supersedes CWA 50560:2010
English Version
Interoperability framework requirement specification
Spécification d'exigences cadre d'interopérabilité Rahmenspezifikation für Interoperabilitätsanforderungen
(IFRS)
This Technical Specification was approved by CENELEC on 2014-08-11.

CENELEC members are required to announce the existence of this TS in the same way as for an EN and to make the TS available promptly
at national level in an appropriate form. It is permissible to keep conflicting national standards in force.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2014 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. CLC/TS 50560:2014 E
Contents
Contents . 1
Foreword . 6
Introduction. 7
1 Scope . 9
2 Normative References . 9
3 Terms, definitions and Abbreviations . 10
3.1 Security Definitions . 10
3.2 Process Definitions . 12
3.3 Interoperability . 14
3.4 Abbreviations . 14
4 The Interoperability Framework . 17
4.1 The Function Steps . 17
4.1.1 General . 17
4.1.2 Discovery . 17
4.1.3 Configuration . 17
4.1.4 Operation . 17
4.1.5 Management. 18
4.2 The Levels . 18
5 Conformance clauses . 19
5.1 Interoperability Conformance Requirements . 19
5.1.1 General . 19
5.1.2 Identifier . 19
5.1.3 Object Description . 19
5.1.4 Object Discovery . 20
5.1.5 Object Configuration . 20
5.1.6 Object Operation . 20
5.1.7 Object Management . 20
5.1.8 Object Access and Safety Requirements . 20
5.2 Conformance sub-clauses . 20
5.2.1 Object Identifier Description Requirements . 20
5.2.2 Object Functional Description Requirements . 21
5.2.3 Discovery Process Requirements . 22
5.2.4 Configuration Process Requirements . 23
5.2.5 Operation Requirements . 23
5.2.6 Management Requirements . 23
5.2.7 Object Security, Safety and Priority and Access Requirements . 24
Annex A (informative) Steps of discovery, configuration, operation and management . 25
A.1 Methodology . 25
A.1.1 Objectives . 25
A.1.2 Assumptions . 25
A.2 Approach . 26
A.3 The Function Steps . 26
A.3.1 General . 26
A.3.2 Discovery . 26
A.3.3 Configuration . 29

– 3 – CLC/TS 50560:2014
A.3.4 Operation . 30
A.3.5 Management . 30
A.4 The Levels . 30
A.4.1 Level 0 . 30
A.4.2 Level 1 . 31
A.4.3 Level 2 . 32
A.4.4 Level 3 . 33
A.4.5 Level 4 . 34
A.4.6 Level 5 . 37
A.4.7 Level 6 . 38
A.4.8 Combinations of Different Levels in the Same Installation . 40
A.5 Use Cases . 41
A.5.1 Methodology . 41
A.5.1.1 General . 41
A.5.1.2 Describe use-case . 41
A.5.2 Scenarios to Illustrate Interoperability Levels . 42
A.5.2.1 General . 42
A.5.2.2 Level 0 . 43
A.5.2.3 Level 1 . 43
A.5.2.4 Level 2 . 43
A.5.2.5 Level 3 . 44
A.5.2.6 Level 4 . 44
A.5.2.7 Level 5 . 44
A.5.2.8 Level 6 . 45
A.6 IFRS Methodology . 45
A.6.1 General . 45
A.6.2 Physical Layer, Pathways and Media (PHY) . 45
A.6.3 Data Link Control (DLC) . 46
A.6.4 Network Layer and Routing (NWK) . 47
A.6.5 Transport and Session (TRS) . 48
A.6.6 Presentation and Application (APP) . 49
A.6.7 IFRS Issues – A Summary . 49
A.6.8 Working Assumptions . 50
A.6.9 Rationale for the Function Steps and Associated Processes . 51
A.6.9.1 General . 51
A.6.9.2 Architectural Issues . 52
A.7 Security, Safety, Access and Priority Considerations . 52
A.7.1 Introduction to Security Considerations . 52
A.7.2 References and Standards . 55
Annex B (normative) Interoperability Implementation Conformance Statement . 56
B.1 Scope . 56
B.2 References . 56
B.3 Definitions and abbreviations . 56

B.3.1 Definitions . 56
B.3.1.1 General Definitions . 56
B.3.1.2 Security Definitions . 60
B.3.1.3 Interaction Model Definitions . 62
B.3.1.4 Process Definition . 66
B.3.1.5 Interoperability . 67
B.3.1.6 Other Definitions . 68
B.4 Requirements for Conformance to this IICS . 69
B.4.1 General . 69
B.4.2 Object Identifier Description Requirements . 69
B.4.3 Object Functional Description Requirements . 69
B.4.3.1 General . 69
B.4.3.2 Object Classification . 69
B.4.3.3 Object Discovery Interface . 70
B.4.3.4 Object Configuration Interface . 70
B.4.3.5 Object Management Interface . 70
B.4.3.6 Object Functional Interface . 70
B.4.4 Discovery Requirements . 70
B.4.4.1 General . 70
B.4.4.2 Object Descriptions: Self and Objects to be Discovered . 70
B.4.4.3 Communication Mode . 71
B.4.4.4 Discovery Process . 71
B.4.4.5 Discovery Scope . 71
B.4.4.6 Security and Privacy . 71
B.4.5 Configuration Requirements . 71
B.4.5.1 Bindings . 71
B.4.5.2 Communication Mode . 71
B.4.5.3 Configuration Process . 71
B.4.5.4 Security and Privacy . 72
B.4.6 Operation Requirements . 72
B.4.6.1 Application Operation . 72
B.4.6.2 Security and Privacy . 72
B.4.7 Management Requirements . 72
B.4.7.1 Communication Mode . 72
B.4.7.2 Management Process . 72
B.4.7.3 Security and Privacy . 73
B.5 Instructions for Completion of the IICS . 73
B.5.1 General . 73
B.5.2 Key to the Table Entries . 73
B.6 Global Statement of IICS Conformance . 74
B.7 Specific Statements of IICS Conformance . 74
B.7.1 General . 74
B.7.2 Object Catalogue. 74

– 5 – CLC/TS 50560:2014
B.7.3 Operation Catalogue . 75
B.7.4 Object and Operation Interoperability Catalogue . 76
B.7.5 Upper Layer PICS (APP) . 77
B.7.5.1 General . 77
B.7.5.2 Additional Requirements for Gateways at APP Layer . 77
B.7.6 Network Layer and Routing PICS (NWK) . 78
B.7.6.1 General . 78
B.7.6.2 Additional Requirements for Gateways at NWK Layer. 79
B.7.7 Data Link Control and MAC PICS (DLC/MAC) . 80
B.7.7.1 General . 80
B.7.7.2 Additional Requirements for Gateways at DLC/MAC Layer . 81
B.7.8 Media and PHY PICS (PHY) . 82
Bibliography . 83

Foreword
This document (CLC/TS 50560:2014) has been prepared by CLC/TC 205, "Home and Building
Electronic Systems (HBES)".
This document supersedes CWA 50560:2010.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such
patent rights.
This document has been prepared under a mandate given to CENELEC by the European Commission
and the European Free Trade Association.

– 7 – CLC/TS 50560:2014
Introduction
The objective of this Technical Specification, the Interoperability Framework Requirements
Specification (IFRS), is to specify a methodology that will give consumers the confidence to buy
products from different companies both now and in the future, knowing that they will operate together.
Achieving this requires several phases of standardisation to ensure integration from the physical
connectors to the way systems function. There are three phases of integration:
• Co-existence - where different systems can operate in the same environment without hindering
each other's’ operation;
• Interworking - where different technologies are connected together to transfer data end-to-end. It
is primarily a technical solution encompassing connectors, protocols, bridges, etc. ;
• Interoperability - where different application functions are able use the shared information in a
consistent way. This requires interworking as a building block as well as coexistence, and adds
business rules, processes, and security provisions that enable applications to be joined together.

Figure 1
The Interoperability Framework Requirements Specification, IFRS, addresses the third of these terms.
It provides a common set of rules to enable products that use different standards to interoperate when
they are present in an installation.
This TS covers four high level functional activities: discovery, configuration, operations and system
management. It puts forward a common set of requirements that if complied with, and if coexistence
and interworking are assured, will enable interoperability. It does not address co-existence or
interworking on the basis that this is achieved by technology standards.

Interoperability is provided by alliances of commercial businesses (and there are several such
alliances), but to ensure interoperability customers are limited to purchasing products from members
of the alliance. This TS acknowledges the work and the value of such alliances but specifically
addresses the ability for customers to purchase products and services from competing alliances and
still achieve interoperability. In doing so it expects to increase the market for those alliances that
conform to the IFRS as customers will purchase their products with greater freedom of choice and
confidence that they will work.

– 9 – CLC/TS 50560:2014
1 Scope
This Technical Specification contains a specification of an Interoperability Requirements Framework,
specifying seven levels of interoperability, based on four groups of interoperability steps specified by
five types of interaction, plus a methodology based on conformance clauses for satisfying
requirements related to the claimed level of interoperability of devices installed in a Home and Building
Electronic System (HBES, HES).
It is applicable to installations of a single type of HBES, or that interconnect two or more dissimilar
HBESs. Within a HBES of a single type any of its capabilities for service, applications and connectivity
topology can be used. Interconnection technologies used to interconnect dissimilar HBES are similarly
unconstrained.
For applicable installations, the scope of its provisions applies to: the connection of devices to the
various communications services to enable them to communicate end-to-end across internetworked
media; the processes of discovery by which devices find out about each other and configuration to
associate them with each other; and the generic aspects of application operation; and management.
This Technical Specification is not applicable to the interoperability required between devices to
implement specific applications, such as heating or lighting control, energy management, or
entertainment. The interoperability requirements defined in this Technical Specification are necessary
for such application interoperability but not sufficient. This Technical Specification does not define how
measurements are made; nor the algorithms that receive, process and respond to them; nor the
interaction between users, service providers, and the HBES application(s). This is the responsibility of
experts and organisations that specialise in particular application domains.
2 Normative References
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ETSI/TS 101 761-2, Broadband Radio Access Networks (BRAN);HIPERLAN Type 2; Data Link
Control (DLC) Layer;Part 2: Radio Link Control (RLC) sublayer
ETSI/TS 300 406:1995, Methods for testing and Specification (MTS); Protocol and profile,
conformance testing specifications; Standardization methodology.
ISO/IEC 9646-1, Information technology — Open Systems Interconnection — Conformance testing
methodology and framework — Part 1: General concepts.
ISO/IEC 9646-7, Information technology — Open Systems Interconnection — Conformance testing
methodology and framework — Part 7: Implementation Conformance Statements
ITU X.800, Data communication networks: Open systems interconnection (OSI); Security structure
and applications - Security architecture for open systems interconnection for CITT applications

3 Terms, definitions and Abbreviations
For the purposes of this document, the following terms and definitions apply.
3.1 Security Definitions
3.1.1
access control
the prevention of unauthorized use of a resource, including the prevention of use of a resource in an
unauthorized manner
[SOURCE: ITU X.800]
Note 1 to entry : Access Control becomes important when more than one entity or system is required to access a
resource. In such cases and especially where safety is an issue, there may need to be levels of Access Rights
depending on the priority of the accessing application and the nature of the resource. Permission and ability to
use an object for a specified purpose – requesting information from it, changing values of variables in it or
modifying its state.
Note 2 to entry: Where more than one service or Application requires access to an Object for one or more specific
purposes, then levels of access shall be defined, including the definition of the primary owner of the Access
Rights (possibly the owner of the Object)
EXAMPLE: Read access to a shared variable; permission to turn on, or off, i.e. execute certain operations.
3.1.2
access rights
permission and ability to use an Object for a specified purpose – requesting information from it,
changing values of variables in it or modifying its state
Note 1 to entry: Where more than one service or application requires access to an Object for one or more specific
purposes, then levels of access shall be defined, including the definition of the primary owner of the access rights
(possibly the owner of the Object)
EXAMPLE: read access to a shared variable; permission to turn on, or off, i.e. execute certain operations.
3.1.3
authentication
the validation of a claimed identity
Note 1 to entry: The validation of a claimed identity of a user can be made by verifying some secret knowledge,
key, or property associated with that user, e.g. a password, a SSL key, a PGP private key, or a hand-written
signature.
3.1.4
authorisation
the decision to permit a user to make none (deny access), one or more types (permit access) of
operations on an object
Note 1 to entry: The permission is made by comparing the validated user's Access Rights with the user's
requested action(s) on an Object, for example to read and to modify some content of an Object.
3.1.5
confidentiality
the property that information is not made available or disclosed to unauthorized individuals, entities, or
processes
[SOURCE: ITU X.800]
– 11 – CLC/TS 50560:2014
3.1.6
denial of service
the prevention of authorized access to resources or the delaying of time-critical operations (by
unwanted or malicious messages that render network resources non-functional)
[SOURCE: ITU X.800]
3.1.7
eavesdropping
attack where an unauthorised user is listening in on transmissions to which they should not have
access. Information remains intact, but its privacy is compromised
EXAMPLE: intercepting credit card numbers or classified information – the interception of any communications
information may render the eavesdropper useful information. See Privacy
3.1.8
encryption
the process of disguising data to hide its content. As used in a network security context, Encryption is
usually accomplished by putting the data through any of several established mathematical
algorithms developed specifically for this purpose
3.1.9
information security
provides confidentiality, integrity, availability and accountability of data
EXAMPLE: key for Encryption or detection of tampering, access permissions for reading and writing objects, audit
trails for modifications to data.
3.1.10
integrity
the property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ITU X.800]
3.1.11
non-repudiation
proves communications took place so that the sender (or receiver) cannot refute sending (or receiving)
information
EXAMPLE: a digital signature may provide proof of non-repudiation as it links the sender with the message.
3.1.12
physical security
rules and systems put in place to safeguard the physical access to a premise or devices from physical
interference
EXAMPLE: a self-opening and closing door for wheelchair access, compliant with standards for such devices.
3.1.13
priority
relative ordering given to a process or action with respect to other processes
EXAMPLE: Life critical processes may have a higher priority than other user processes.
3.1.14
privacy
the protection of information that might be derived from the observation of network activities (see
Eavesdropping)
[SOURCE: ITU X.805]
3.1.15
replay attack
the interception and recording of messages for sending out at a later time so that the receiver
unknowingly thinks the bogus traffic is legitimate
3.1.16
repudiation
denial by one of the entities involved in a communication of having participated in all or part of the
communication
[SOURCE: ITU X.800]
3.1.17
safety
the state of being certain that adverse effects will not be caused by some agent under defined
conditions
Note 1 to entry: As an actuator becomes progressively more remote from a device or action, the scope for actions
that may result in unsafe conditions increases. This problem is accentuated when there are two or more actuators
acting on that device or action.
3.1.18
security
rules and policies stated by owners that control the use of their property by other owners
EXAMPLE: people allocated car-parking spaces are allowed to open the garage doors. People with no allocation
may not open the doors.
3.1.19
security requirements
the purpose, objectives and success criteria applied to an Application or service
Note 1 to entry: This Technical Specification specifies requirements for Security in relation to Levels of
Interoperability that cover both Physical Security and Information Security and these shall be combined with
Safety and other considerations such as the permission and Priority of access, Discovery, Configuration and
Management.
3.1.20
validation
the act of examining information provided by a person (or a system) to ascertain what rights,
privileges, or permissions they may (or may not) have to perform some action
3.1.21
verification
in cryptography, the act of testing the authenticity of a digital signature by performing special
mathematical operations on data provided by a sender, to see if it matches an expected result. If the
information provided by the sender yields the expected result, the signature is valid, because
calculating the proper answer requires secret data known only by the sender. Verification proves that
the information was actually sent by the signer and that the message has not been subsequently
altered by anyone else
3.2 Process Definitions
3.2.1
object
an embodiment of information as data structures and operations upon them realised in electronic
hardware, software, or embedded in a stream of data, that can be referenced and with which
interaction can be achieved by processes, other Objects and users

– 13 – CLC/TS 50560:2014
3.2.2
application
a collection of functions that have measurable effects on the physical world and are used by people to
achieve objectives consistent with the specified capabilities of the Application
Note 1 to entry: Also used to refer to use of a technology, system, or product. An Application may consist of a
number of elements or entities working together to provide a service or product. It may utilise specific elements in
a system or technology in delivering the application. Alternatively, an application may be a program that carries
out a particular service within a computer, processor or (home) system.
EXAMPLE: Devices in the Smart House collaborate to execute an energy management Application that the owner
uses to reduce electricity consumption. No additional service is required.
3.2.3
configuration
the set of status parameters for an Object or device
EXAMPLE: a device is connected to the application using a certain network address, its Objects are registered
with Objects in other devices.
3.2.4
configuration process
configuration of parameters of an object or objects or applications. This may be carried out by means
of a Configuration tool and other actions that may be automatic and driven by other services and/or
applications
EXAMPLE: the association of objects in a device with those in other devices.
3.2.5
discovery
enabling users, Applications, Objects, and devices participating in systems to discover new units and
to recognise what they are
Note 1 entry: Objects may present or publish their parameters or respond to a broadcast for information about
specific object types).
EXAMPLE: UPnP.
3.2.6
discovery process
the process of execution of discovery activities
3.2.7
middleware
middleware is a generic term for functions that make a communications infrastructure that is part of a
distributed system usable by applications
Note 1 to entry: Middleware may be used for the purposes of Interoperability to translate the data presented by an
Object under one specific home system specification to the requirements of another.
EXAMPLE 1: the IP routing functionality in a home gateway to ISP services provides middleware to connect with
the ISP, register local devices for access to Internet services and route IP packets between local processes and
external ones.
EXAMPLE 2: a smart meter provides middleware that authenticates application objects downloaded into it before
allowing them to use its communications services to implement specific application functions.
3.2.8
operations
application services requested between Objects in the system that collectively implement its function

3.2.9
system management
application services requested between objects in the system that are not related to the Applications
that it executes
Note 1 to entry: Examples: collection of statistics, diagnostic troubleshooting, firmware and software upgrade
installation.
3.3 Interoperability
3.3.1
coexistence
objects and Applications exist in the same environment and they do not conflict with one another
Note 1 to entry: their functions may, or may not, be related to, or dependent on, one another.
EXAMPLE: a security service monitors events in a home via the smart electricity meter communicating via a
Zigbee link to the home security gateway. Due to excessive traffic between other Zigbee connected devices, such
as the Consumer Display Unit, the meter is temporarily too busy to relay security events and there is a delay in
reporting a break-in. The systems do not coexist.
3.3.2
interoperability
interoperability is the ability of two or more networks, systems, devices, Applications or components to
exchange information between them and use the information so exchanged
Note 1 to entry: this definition is due to IEEE/CENELEC.
EXAMPLE: see elsewhere in this Technical Specification.
3.3.3
interworking
the capability to exchange information between services and devices of dissimilar capability and/or
provenance such that Interoperability is achieved
EXAMPLE: a home gateway to ISP services provides interworking between Ethernet and Wifi media in the home
and the ADSL media outside the home to support routing of IP packets so that the applications objects in the
home are interoperable via IP protocol with application objects elsewhere.
3.3.4
open standard
in the context of this Technical Specification, a document available to all, approved by the processes
of designated international standards bodies defining architecture, function, protocols and
conformance criteria of aspects of communications systems
3.4 Abbreviations
Acronym Explanation
AC Alternating Current
ACID Atomic, consistent, isolated, durable – properties of interactions involving multiple
distributed objects sharing resources concurrently.
ADSL Asymmetric DSL
API Application Programming Interface
APP Application, Presentation, Transport and Session layers, specific to this Technical
Specification.
AS Autonomous system
– 15 – CLC/TS 50560:2014
ASN.1 Abstract Syntax Notation One
ATM Asynchronous Transfer Mode
CDU Consumer Display Unit
CENELEC Comité Européen de Normalisation Electrotechnique
CWA CENELEC Workshop Agreement
DLC Data Link Control
DLNA Digital Living Network Alliance
DOS Denial of Service
DSL Digital Subscriber Link
DVB Digital Video Broadcast
ETSI European Telecommunications Standards Institute
FCD Final Committee Draft
FDL Formal Description Language
GPRS General Packet Radio Service
GSM Groupe Special Mobile, Global System for Mobiles
HAN Home Area Network
HBES Home and Building Electronic System
HDMI High-Definition Multimedia Interface
HES Home Electronic Systems
HSPA High Speed Packet Access
HTTPS HyperText Transfer Protocol - Secure
ICT Information and Communications Technologies
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IFRS Interoperability Framework Requirements Specification
IICS Interoperability Implementation Conformance Statement
IP Internet Protocol
IR Infra-Red
IS International Standard
ISO International Standards Organisation
ISP Internet Service Provider
ITU-T International Telecommunications Union - Telecommunications
LAN Local Area Network
MAC Medium Access Control
MAC Message Authentication Code
Mbps Megabit per second
NWK Network (Layer of the OSI-RM)
OMG Object management Group
OSI Open System Interconnection

OSI-RM Reference Model (for OSI)
PC Personal Computer
PDU Protocol Data Unit
PGP Pretty Good Privacy
PHY Physical (Layer of the OSI-RM)
PICS Protocol Implementation Conformance Statement
PIN Personal Identification Number
PIXIT Protocol Implementation Extra Information for Testers
PLC Powerline Communications
PPPoATM Point-to-Point Protocol over ATM
PSTN Public Switched Telephone Network
QoS Quality of Service
RJ45 Registered Jack No. 45 – standardised as TIA/EIA-568-B, used for telephony and
communications applications
RPC Remote Procedure Call
RPC IDL RPC Interface Definition Language
RS232 Recommended Standard 232, a standard for serial connection between a Data Terminal
Equipment and a Data Circuit-terminating Equipment. The ITU-T standard is V.24.
SDU Service Data Unit
SLA Service Level Agreement
SLR Service Level Requirement
SMS Short Message Service
SSL Secure Socket Layer
STB Set Top Box
TCP Transmission Control Protocol
TRS Transport (Layer of the OSI-RM)
TS Technical Specification
UPnP Universal Plug and Play
USB Universal Serial Bus
VC Virtual Circuit
VP Virtual Path
WAN Wide Area Network
WiFi Wireless Fidelity, IEEE 802.11
WiMAX Worldwide Interoperability for Microwave Access
XML Extensible Markup Language

– 17 – CLC/TS 50560:2014
4 The Interoperability Framework
4.1 The Function Steps
4.1.1 General
This section outlines the steps of discovery, configuration, operation and management. They are
described in detail in A.3
4.1.2 Discovery
Support for discovery is a fundamental requirement to ensure interoperability in systems of dynamic
composition such as envisioned by this Technical Specification, where devices and services will be
installable professionally or by end users directly, and where these devices and services will evolve in
time.
4.1.3 Configuration
When the discovery process has completed, objects in the system will have a map of the objects
elsewhere that they will need to interact with to implement the application. This Technical Specification
does not constrain the form, content or location of such a map, nor the means by which it is created.
The main step in configuration is to make an association (or binding) between objects that are
required to interact. In some systems this binding may be implemented as part of the last sub-step in
discovery. The binding may be permanent for the lifetime of the system, or it may be repeatedly
renewed and torn down. One object may have multiple bindings with others when its capabilities are
reused by multiple applications.
Binding may be permitted, or forbidden, depending on policy or access control. The object may require
a password supplied by another object that wishes to interact with it before it will perform an action or
return information. It may initiate a sequence of interactions with its owners and users to enable a
binding to be made. Key exchange may be done during binding as part of the system security
provisions.
The configuration step may also involve one object supplying information to others that enables them
to interact with yet other objects. For example, in a lighting application using a powerline medium,
switches and lights have no natural binding: it is quite likely that any switch can discover all the lights
in an installation, and vice versa. The manager object may interact with the occupants to map the
relationship between switches and lights. Once this map has been built, the switch/light pairs can be
told of each other’s existence and set up bindings accordingly. This example makes many
assumptions about the architecture, functions
...