Home and Building Electronic Systems (HBES) - Part 6-1: Interfaces - Webservice interface

This European Standard defines a standardized web service based interface between HBES networks and other information technology (IT) systems.
The standardized interface is encapsulated in a gateway device, the HBES Gateway, which shall be able to communicate with both the HBES network and the connected IT systems. The HBES Gateway shall implement a set of encoding standards (see 10.2) as well as various message exchange protocols (see 10.3) to enable remote access to the HBES network via the Internet or another wide area network (WAN). For this purpose, gateway profiles define different implementation levels (see 10.4).

Elektrische Systemtechnik für Heim und Gebäude (ESHG) - Teil 6-1: Schnittstellen - Webservice-Schnittstelle

Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) - Partie 6-1 : Interfaces - Interface de services web

Stanovanjski in stavbni elektronski sistemi (HBES) - 6-1. del: Vmesniki - Mrežni vmesnik

Ta evropski standard določa standardizirani mrežni vmesnik med omrežji stanovanjskih in stavbnih elektronskih sistemov (HBES) ter drugimi sistemi informacijskih tehnologij (IT).
Standardizirani vmesnik je zaprt v napravi za prenos, tj. prehodu stanovanjskega in stavbnega elektronskega sistema (HBES), ki lahko komunicira tako z omrežjem stanovanjskega in stavbnega elektronskega sistema kot s povezanimi sistemi informacijskih tehnologij. Prehod stanovanjskega in stavbnega elektronskega sistema (HBES) mora vključevati nabor kodirnih standardov (glej 10.2) in različne protokole za izmenjavo sporočil (glej 10.3), da omogoča oddaljen dostop do omrežja stanovanjskega in stavbnega elektronskega sistema prek interneta ali drugega prostranega omrežja (WAN). Zato profili prehodov določajo različne ravni implementacije (glej 10.4).

General Information

Status
Published
Publication Date
08-Oct-2017
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
05-Oct-2017
Due Date
10-Dec-2017
Completion Date
09-Oct-2017

Buy Standard

Standard
EN 50090-6-1:2017 - BARVE
English language
36 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

SLOVENSKI STANDARD
SIST EN 50090-6-1:2017
01-november-2017
Stanovanjski in stavbni elektronski sistemi (HBES) - 6-1. del: Vmesniki - Mrežni
vmesnik
Home and Building Electronic Systems (HBES) - Part 6-1: Interfaces - Webservice
interface
Ta slovenski standard je istoveten z: EN 50090-6-1:2017
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
97.120 Avtomatske krmilne naprave Automatic controls for
za dom household use
SIST EN 50090-6-1:2017 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST EN 50090-6-1:2017

---------------------- Page: 2 ----------------------

SIST EN 50090-6-1:2017


EUROPEAN STANDARD EN 50090-6-1

NORME EUROPÉENNE

EUROPÄISCHE NORM
September 2017
ICS 35.240.67; 97.120

English Version
Home and Building Electronic Systems (HBES) - Part 6-1:
Interfaces - Webservice interface
Systèmes électroniques pour les foyers domestiques et les Elektrische Systemtechnik für Heim und Gebäude (ESHG) -
bâtiments (HBES) - Partie 6-1 : Interfaces - Interface de Teil 6-1: Schnittstellen - Webservice Schnittstelle
services web
This European Standard was approved by CENELEC on 2017-05-15. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
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, Serbia, 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
© 2017 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
 Ref. No. EN 50090-6-1:2017 E

---------------------- Page: 3 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017
Contents Page
European foreword . 3
Introduction . 4
1 Scope. 5
2 Normative references . 5
3 Terms, definitions and abbreviations . 5
3.1 Terms and definitions . 5
3.2 Abbreviations . 5
4 Overall introduction . 5
5 General technical introduction to HBES Web Services . 6
6 Overview . 7
6.1 General architecture . 7
6.2 General Home and Building HBES Open Communication System structure . 8
6.3 Structure of this document . 10
7 HBES Information model . 10
7.1 Introduction . 10
7.2 Vocabulary structure . 11
7.3 Core tags . 13
7.4 Modelling example . 18
8 HBES Web interface OBIX . 21
8.1 Introduction . 21
8.2 Information presentation . 21
8.2.1 Introduction . 21
8.2.2 Contract mapping . 23
8.2.3 Data point Type contract mapping . 25
8.2.4 Functional Block Type contract mapping . 26
8.2.5 Entity mapping . 27
8.3 Object addressing . 28
8.4 Object interaction . 29
8.4.1 Introduction . 29
8.4.2 Read transaction . 30
8.4.3 Write transaction . 31
8.4.4 Invoke transaction . 31
9 HBES Gateway OBIX . 32
9.1 Introduction . 32
9.2 Object model . 32
9.3 Representational State Transfer . 33
10 Gateway profiles . 33
10.1 Introduction . 33
10.2 Information encoding . 34
10.3 Message exchange . 34
10.4 Profiles . 35
10.5 Conflict handling . 36

2

---------------------- Page: 4 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017
European foreword
This document (EN 50090-6-1:2017) has been prepared by CLC/TC 205 “Home and Building
Electronic Systems (HBES)”.
The following dates are fixed:
• latest date by which this document has to be (dop) 2018-09-01
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) 2020-09-01
conflicting with this document have to be
withdrawn
3

---------------------- Page: 5 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017
Introduction
The European Committee for Electrotechnical Standardization (CENELEC) draws attention to the fact
that it is claimed that compliance with this document may involve the use of a patent.
CENELEC takes no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has assured CENELEC that he/she is willing to negotiate licences
under reasonable and non-discriminatory terms and conditions with applicants throughout the world.
In this respect, the statement of the holder of this patent right is registered with CENELEC.
Information may be obtained from:
KNX Association De Kleetlaan 5, Bus 11
B-1831 Brussels-Diegem
Tel: +32 (0)2 775 86 44 Mob: +32 (0) 476 21 56 58 Fax: +32 (0)2 675 50 28
e-mail: info@knx.org
www.knx.org
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights other than those identified above. CENELEC shall not be held responsible for identifying
any or all such patent rights.
4

---------------------- Page: 6 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017
1 Scope
This European Standard defines a standardized web service based interface between Home and
Building HBES Open Communication System and other information technology (IT) systems.
The standardized interface is encapsulated in a gateway device, the HBES Gateway, which is able to
communicate with both the Home and Building HBES Open Communication System and the
connected IT systems. The HBES Gateway implements a set of encoding standards (see 10.2) as
well as various message exchange protocols (see 10.3) to enable remote access to the Home and
Building HBES Open Communication System via the Internet or another wide area network (WAN).
For this purpose, gateway profiles define different implementation levels (see 10.4).
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.
EN 50090-1:2011, Home and Building Electronic Systems (HBES) - Part 1: Standardization structure
EN 50090-3-3, Home and Building Electronic Systems (HBES) - Part 3-3: Aspects of application -
HBES Interworking model and common HBES data types
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 50090-1:2011 apply.
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
BAS Building Automation System
BMS Building Management System
IoT Internet of Things
OASIS Open Building Information Exchange
WS Web Services
4 Overall introduction
Home and Building HBES Open Communication System is dedicated to the control and monitoring of
networked building automation systems (BASs). Currently, Home and Building HBES Open
Communication System has limited capability to communicate with other systems, as a result of the
use of different protocols, incompatibility or various other restrictions. For the integration of Home and
Building HBES Open Communication System and for solving specific problem scenarios, customized
solutions are currently on offer. A standard interface between the HBES world and the remaining
systems would however constitute a common link to bridge the gap and integrate Home and Building
HBES Open Communication System into systems like the traditional Internet or the emerging Internet
of Things (IoT).
A standard bridge between Home and Building HBES Open Communication System and IT systems
based on Web services (WSs) is currently missing to support upcoming use case scenarios. This
standard specifies such a standard interface.
5

---------------------- Page: 7 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017
5 General technical introduction to HBES Web Services
The HBES Gateway is an abstract concept, and thus not restricted to any hardware requirements or
limitations. Constrained devices can be used as well as enterprise systems as HBES Gateway
device. It shall be kept in mind that some configurations may overload the used hardware regarding
the mentioned limitations. For example, a computationally intensive message exchange protocol
cannot be used in resource-constrained HBES Gateways. However, the HBES Web services
specification defines the HBES Gateway in an abstract and platform-independent way irrespective of
any particular hardware.
Figure 1 sketches the intended setting containing the Home and Building HBES Open Communication
System, the IT systems and the HBES Gateway between these two components.

Figure 1 — General intention of the HBES WS interface
In a first version, the HBES Gateway and its WS interface is based on OASIS Open Building
Information Exchange (OBIX). The OBIX integration is specified in Clauses 8 and 9.
The HBES Gateway shall allow browsing of information on the Home and Building HBES Open
Communication System and reading or modifying runtime data of devices, Data points, Functional
Blocks, Interface Objects or channels. Thus, any high level management use case to manipulate or
monitor the underlying Home and Building HBES Open Communication System is covered by this
standard and can be implemented using the presented interfaces.
By default, the HBES Gateway is intended for two target groups:
6

---------------------- Page: 8 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017
• Web Client developers use the defined interface to implement Web Clients, which are remote
applications for accessing Home and Building HBES Open Communication System. These
applications are not limited to Web technologies (e.g. HTML5), but also other applications can
use the introduced WSs. Thanks to the standard interface, Web Client developers require no
HBES expert knowledge. Interactions with the HBES Gateway are handled via common WS
calls. However, the Web Client developers need to understand the structure of a BAS and the
possible ways of interacting with its elements to implement management applications.
• Gateway manufacturers have to provide the Web Client developers with the common and
standardized interface. In addition, they are faced with the integration of information from Home
and Building HBES Open Communication System into the HBES Gateway. Gateway
manufacturers need knowledge on the HBES Specification as given in the EN 50090 series as
well as on implementing and providing WSs. The HBES knowledge is needed for the realization
of a communication interface between the HBES Gateway and the Home and Building HBES
Open Communication System.
There are three interfaces on the boundaries of the specified HBES Gateway that shall be
implemented.
• First, the HBES Information model interface defines the structure of the input model to integrate a
representation of the Home and Building HBES Open Communication System into the HBES
Gateway. All available elements and their representation are specified by this interface.
Depending on the used technology in the HBES Gateway, mappings of the information to the
technology-specific representation is required.
• Secondly, the HBES Web interface between the HBES Gateway and the remote IT systems
describes the available access points and the structure of the data both provided and expected
by the services of the HBES Gateway.
• Thirdly, the Home and Building HBES Open Communication System access interface is required
to connect the HBES Gateway with the Home and Building HBES Open Communication System
to enable message exchange and routing requests from and to the remote IT systems.
This HBES Web services specification covers the first and the second interface while the third one is
left to the gateway manufacturer responsible for establishing an adequate link to the Home and
Building HBES Open Communication System.
6 Overview
6.1 General architecture
The overall architecture of the HBES Web services consists of nine main components, which are
illustrated in Figure 2. This overview is used throughout this standard to specify in detail the different
components and interfaces. Moreover, a workflow from the Home and Building HBES Open
Communication System to the final integration into the HBES Gateway is illustrated in this figure. The
following list describes the components in general terms.
1. Home and Building HBES Open Communication System covers all kinds of HBES
installations. Twisted Pair (TP) as well as the Internet Protocol (IP) or USB connections can be
used to establish a link to the HBES Gateway component.
2. All settings and configuration actions in Home and Building HBES Open Communication Systems
are done by means of appropriate tools. Afterwards export functionality can be used to provide
the available data of the Home and Building HBES Open Communication System for further
processing. However, this component is not mandatory. If the data can be obtained from another
information source, the tool export does not need to be used (cf. the following component).
3. Additional information illustrates an extra information source besides the configuration tool.
Similarly, information is modelled by means of the HBES Information model. This modelling step
7

---------------------- Page: 9 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017
can be done either automatically by any tool support or manually by editing the model prior to its
integration into the HBES Gateway device.
4. Remote access covers all access activities from Web Clients, which use various message
exchange protocols (e.g. HTTP, CoAP, or WebSocket). Data for requests and responses can be
encoded in different formats (e.g. XML, EXI, JSON, or CBOR).
5. HBES Gateway specifies the component that shall enable the link between the Home and
Building HBES Open Communication System and the Web Clients. Its interfaces shall be the
HBES Information model for the import of network configuration information as well as the Home
and Building HBES Open Communication System access and the HBES Web interface as
service interfaces for Web Client access to the Home and Building HBES Open Communication
System.
6. HBES Information model specifies the interface that consolidates the configuration data and the
information of additional data sources. This model is based on a common vocabulary (tag
vocabulary) defining a list of tags and relations between these tags. The HBES Information model
is independent of both the data source of the Home and Building HBES Open Communication
System (i.e. input sources to the model) and the technology used to implement the HBES
Gateway (i.e. OBIX). The generated model is the source for integration of Home and Building
HBES Open Communication System information into the HBES Gateway. This interface is used
for configuration purposes while the subsequently described Home and Building HBES Open
Communication System access and HBES Web interface provide their services at runtime of the
HBES Gateway.
7. Home and Building HBES Open Communication System access is consigned to handle the
message exchange between the HBES Gateway and the connected Home and Building HBES
Open Communication System.
8. HBES Web interface, on the other hand, provides services for Web Clients via common Web
protocols. The messages can be encoded by using different formats. The HBES Web interfaces
according to the various HBES Gateway technologies are described throughout this standard.
9. Tag vocabulary defines a list of available tags to specify entities in the HBES Information model.
Additionally, relationships between tags are defined in the vocabulary in order to structure the
tags. First, the tag vocabulary is used during the creation of the HBES Information model.
Second, the HBES Web interface uses this vocabulary to transform the internal data
representation into the format expected by Web Clients.
6.2 General Home and Building HBES Open Communication System structure
This schematic representation should facilitate the understanding of modelling a Home and Building
HBES Open Communication System at the HBES Gateway interfaces. An overview of this model is
depicted in Figure 3. This abstract model is independent from the used HBES Gateway technology
(OBIX). Moreover, it is intentionally kept abstract using an intuitive notation in order to give a first
overview of the various elements.
The top element of the model is an installation, which contains a set of views. Each view is linked to
other view elements and to devices, functionalities, or data points.
A topology view will represent the topological structure of the network with its hierarchy of subnets
and devices. A building view will create a structure of building parts and corresponding devices, and
trades categorize the devices of a network in different application domains (e.g. lighting). A device is
linked with functionality elements or is directly connected with its data points. A functionality element
is a container for various data points combined in order to reach a common goal or to describe a
common task. Examples for functionality elements are Functional Blocks or channels. Finally, a data
point has one or multiple access methods to interact with the underlying Home and Building HBES
Open Communication System.
8

---------------------- Page: 10 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017

Figure 2 — General architecture
9

---------------------- Page: 11 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017

Figure 3 — Abstract model
6.3 Structure of this document
In the following clauses, the interfaces 6 (HBES Information model) and 8 (HBES Web interface) are
specified. First, the HBES Information model and the corresponding tag vocabulary are defined (see
Clause 7). The internal processing (model integration) and storage (internal data structures) of the
HBES Information model in the HBES Gateway is manufacturer-specific. Thus, there is enough
freedom in designing HBES Gateways. Second, the HBES Web interface for the HBES Gateway
technologies OBIX (see Clause 8) is specified. Here, mappings from the tag vocabulary and the
HBES Information model to the technology-specific Web interface are addressed. In Clause 9,
characteristics of the OBIX gateway technology are presented.
In summary, this standard focuses on the interfaces for the Web Clients (HBES Web interface) and
the HBES Gateway manufacturers (HBES Web interface, HBES Information model). Issues regarding
internal data processing, network access, and data storage are out of scope and left to the
manufacturers.
7 HBES Information model
7.1 Introduction
The HBES Information model specifies the input data of the HBES Gateway on interface 6
(cf. Figure 2). This model conforms to a list of tags stored in a common tag vocabulary. In order to
provide a structured vocabulary, a meta-model specifies the characteristics of tags and their relations
to each other. Gateway manufacturers shall use the HBES Information model and its vocabulary to
integrate information from the Home and Building HBES Open Communication System into the HBES
Gateway. The HBES Information model based on tags of the vocabulary defines the Home and
Building HBES Open Communication System in a neutral and flexible way independent of any HBES
Gateway technology. The model describes the static structure of a Home and Building HBES Open
Communication System and semantic information while runtime information such as actual values of
data points is modelled at interface 8 and within the HBES Gateway implementation. Compared to a
restrictive object model specifying classes and their attributes, a vocabulary of tags is more easily to
extend to future needs.
All HBES Gateway devices shall be able to handle the full HBES Information model and its
vocabulary for the integration of Home and Building HBES Open Communication Systems. The HBES
10

---------------------- Page: 12 ----------------------

SIST EN 50090-6-1:2017
EN 50090-6-1:2017
Information model exclusively defines the interface for integrating Home and Building HBES Open
Communication System information into the HBES Gateway.
First, the overall structure of the vocabulary and the core tags of this vocabulary are specified. Next,
an example is given to illustrate the usage of the vocabulary to represent a particular Home and
Building HBES Open Communication System in the form of a HBES Information model.
7.2 Vocabulary structure
The vocabulary defines a set of tags and the relations between different tags. Subsequently, a tagged
model defines entities and tag/value-pairs, which characterize these entities and correspond to tags of
the vocabulary. Thus, the tags are used to add characteristics to the HBES-relevant entities when
creating an HBES Information model. In Figure 4, the structure of the tags, their relations, the entities,
and the tag/value-pairs are specified.
• Each Tag shall have a name and a description. The name of the tag shall be a unique identifier.
Additionally, the tag shall have a type specifying the datatype of the tag’s value. Three kinds of
datatypes for a tag exist:
— Primitive datatypes (e.g. bool, string, or real) can be used to specify standard tags. For
example, the tag with the name serialNumber is of type string, and thus corresponding
values can contain any text character.
— The type marker shall indicate an “is-a relationship” and shall have no value. For example,
the marker tag named device can be used to classify a particular entity as a HBES device.
Marker tags do not need a value as the characterization is given by the tag assignment itself.
— The type ref shall define a reference to another marker tag. For this purpose, the reference
association of the class tag is used to specify this referenced tag. For example, deviceRef,
which is a tag of type ref, shall be used to model a reference to an entity that is marked with
the tag device, which is, on the other hand, a tag of type marker. The value of a tag/value-
pair using a ref tag shall be the identifier of the referenced entity (i.e. the value of its
tag/value-pair that is associated with the tag id).
• In order to define relationships between tags, the class Relation shall be used. A relation shall
specify a tag (tag) and its associated sub-tag (used with). The occurrence shall define if a tag can
be used only once (one) or multiple times (many) within a particular entity. For example, the
marker tag device can use the tag name, but this is allowed only once per entity
(occurrence = one).
• An Entity shall be a container for tag/value-pairs. Tag/value-pairs that belong together shall
be grouped within one entity, for example to describe a distinct device in the Home and
Building HBES Open Communication System. In general, an identifier for each entity is
mandatory in order to ensure identifiability (i.e. each entity shall have a tag/value-pair that is
associated with the tag id). Furthermore, the values of identifiers shall not be case sensitive.
A digit shall not be used as first character in an identifier, and allowed characters shall be
ASCII letters, digits, and underscore. Identifiers for entities shall be globally unique, but
should be meaningful and descriptive in order to ease addressing via the HBES Web
interface.
• The intermediate class TagValuePair shall be used as building block of entities. Each
tag/value-pair instance shall belong to an entity and refer to a predefined tag of the
vocabulary. Its value attribute shall be of type object in order to enable the stora
...

Questions, Comments and Discussion

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