EN 50090-6-1:2017
(Main)Home and Building Electronic Systems (HBES) - Part 6-1: Interfaces - Webservice interface
Home and Building Electronic Systems (HBES) - Part 6-1: Interfaces - Webservice interface
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).
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
Standards Content (Sample)
SLOVENSKI STANDARD
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
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
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
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
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
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.
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 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:
• 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
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.
Figure 2 — General architecture
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
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 storage of any
primitive data (e.g. integer, real, date, string). The type of the data shall be specified in the
associated tag.
Figure 4 — Meta-model for entities, tags, and tag/value-pairs
Figure 5 shows the usage of this meta-model for defining tags, entities, and tag/value-pairs in terms of
an example.
• On the right hand side, some tags are defined. The short notation is used to keep the example as
clear as possible. In brackets, the type of the tag is shown. For ref tags, the name of the
referenced marker tag is also written in brackets (e.g. see tag data pointRef). Outside of the
brackets, the name of the tag is given.
• On the left hand side, two entities as containers for tag/value-pairs are listed (entity #17, entity
#45).
• In between, particular characteristics of these entities are specified by means of instances of the
TagValuePair class. In the figure, the values are written in quotes. Each value has an associated
tag in order to specify the meaning of the value. Thus, each entity is linked with a set of
tag/value-pairs, and each tag/value-pair has one distinct tag. Marker tags do not have a value,
i.e. their value is null. A tag/value-pair using a ref tag indicates a connection to another entity
marked with the specified tag. The value of this tag/value-pair is the identifier of the referenced
entity (i.e. the value that is associated with the tag id). This is exemplarily shown by the dotted
arrow indicating a virtual link between the data pointRef tag/value-pair of entity #45 and entity
#17, which is marked as data point and has the id “data point_17”.
Figure 5 — Exemplary modelling of entities, tag/value-pairs, and tags
7.3 Core tags
In the following the core tags of the vocabulary are presented, which are used within this specification
in the context of examples. Additionally, all tags that have an impact on the mapping to the HBES
Gateway technologies (e.g. tags to specify types) are listed in the following tables. Table 1 lists tags
that are specified by their names and types as well as the reference associations. The vocabulary can
be extended ad libitum and is not limited to these tags. This specification hosts, inter alia, those tags
that are absolutely necessary in the HBES Information model and the mapping to target technologies
of the HBES Gateway. In order to avoid ambiguity, all tags are hosted in the namespace HBES, which
is used as prefix for the tag name. Subsequently, the relations between the tags are shown.
Dependencies between tags can be modelled by means of these relations.
Table 1 — Core tags
Name Type Reference
accessMethod marker
application marker
buildingPart marker
buildingPartFloor marker
buildingPartRoom marker
channel marker
channelType marker
channelTypeRef ref channelType
communication bool
data point marker
data pointRef ref data point
data pointType marker
data pointTypeRef ref data pointType
description string
device marker
deviceRef ref device
dimensionA int
dimensionCd int
dimensionK int
dimensionKg int
dimensionM int
dimensionMol int
dimensionS int
direction string
encodingRef ref enumeration
enumeration marker
enumerationRef ref enumeration
functionalBlock marker
functionalBlockType marker
functionalBlockTypeRef ref functionalBlockType
functionality marker
functionalityRef ref functionality
geoAddress string
groupAddress string
groupObject marker
id string
installation marker
literal marker
literalBit bool
Name Type Reference
literalInt int
literalRef ref literal
literalString string
locale string
lsb int
manufacturer marker
manufacturerRef ref manufacturer
max real
min real
msb int
name string
offset int
orderNumber string
parameterType marker
parameterTypeRef ref parameterType
physicalAddress string
priority marker
priorityRef ref priority
readable bool
roomNumber string
scale real
serialNumber string
symbol string
translatable marker
translation marker
translationRef ref translation
transmittable bool
unit marker
unitRef ref unit
updatable bool
value marker
valueBit marker
valueDate marker
valueEnum marker
valueInt marker
valueReal marker
valueRef ref value
valueString marker
view marker
viewRef ref view
writable bool
In addition to these tag declarations, their relations to each other are of interest. Table 2 summarizes
these dependencies by defining the tag (column Tag) and its associated sub-tags (column Used with).
If a tag can occur more than once in combination with its parent tag within a single entity, the
occurrence value many is used. Otherwise, the value one is used for the occurrence. For example,
the marker view is used with the tag translatable. The occurrence is one indicating that this tag cannot
be used multiple times within an entity marked as view. In addition, the view marker can be combined
with multiple occurrences of data pointRef, deviceRef, functionalityRef, and viewRef. Thus, an
arbitrary hierarchy of view entities can be built.
It shall be noted that this list as well as the tag list is more informative than normative and should give
an overview regarding the concept of tags and the previously introduced meta-model for the overall
structure. The list of tag relations is used as primary source for creating type and contract definitions
at the HBES Web interface (interface 8) before the actual entities of the HBES Information model are
mapped. Although the column Tag in Table 2 contains only marker tags, the tag relations are not
limited to relations of the form < marker > used with < any tag > .
Table 2 — Relations of core tags
Tag Used with Occurrence
accessMethod data pointRef many
application view one
buildingPart view one
buildingPartFloor buildingPart one
buildingPartRoom buildingPart one
buildingPartRoom roomNumber one
channel channelTypeRef one
channel functionality one
channelType translatable one
data point data pointTypeRef many
data point direction one
data point parameterTypeRef one
data point translatable one
data pointType translatable one
data pointType valueRef many
device data pointRef many
device functionalityRef many
device manufacturerRef one
device orderNumber one
device physicalAddress one
device serialNumber one
device translatable one
enumeration literalRef many
enumeration translatable one
functionalBlock functionalBlockTypeRef one
functionalBlock functionality one
functionalBlockType parameterTypeRef many
Tag Used with Occurrence
functionalBlockType translatable one
functionality data pointRef many
functionality translatable one
groupObject accessMethod one
groupObject communication one
groupObject groupAddress many
groupObject priorityRef one
groupObject readable one
groupObject transmittable one
groupObject updatable one
groupObject writable one
installation translatable one
installation viewRef many
literal translatable one
literal literalBit one
literal literalInt one
literal literalString one
manufacturer geoAddress one
manufacturer id one
manufacturer name one
parameterType data pointTypeRef one
parameterType direction one
parameterType translatable one
priority literal one
translatable description one
translatable id one
translatable name one
translatable translationRef many
translation description one
translation id one
translation locale one
translation name one
unit dimensionA one
unit dimensionCd one
unit dimensionK one
unit dimensionKg one
unit dimensionM one
unit dimensionMol one
Tag Used with Occurrence
unit dimensionS one
unit offset one
unit scale one
unit symbol one
unit translatable one
value lsb one
value msb one
value translatable one
valueBit encodingRef one
valueBit value one
valueDate value one
valueEnum enumerationRef one
valueEnum value one
valueInt max one
valueInt min one
valueInt unitRef one
valueInt value one
valueReal max one
valueReal min one
valueReal unitRef one
valueReal value one
valueString value one
view data pointRef many
view deviceRef many
view functionalityRef many
view translatable one
view viewRef many
It shall be noted that the definition of tag relations directly influences the structure of objects at the
HBES Web interface. This is because automatic mapping processes use the tag vocabulary and the
corresponding relations (see 8.2) to form the HBES Web interface, e.g. for OBIX-based Gateways.
One basic principle is that the assignment of ref tags to other tags (e.g. the tag viewRef is used by the
tag installation) is motivated by the intended modelling and access methodology. In this specification,
top-down tag relations are defined, for example, providing a list of view entities in the parental
installation entity (see example in 7.4). However, also additional bottom-up tag relations can be
defined without contradiction to already existing tag relations.
7.4 Modelling example
On the next page, an exemplary mapping of an Home and Building HBES Open Communication
System, called Demo, to the HBES Information model is shown in Figure 6. First, the entities that are
relevant for the Web Client, are presented. These entities are coloured green. There are two different
views, named Lighting and All devices. According to the vocabulary, the entities are constructed and
the tag values are set. Second, entities regarding the network access (e.g. Group Objects) are
modelled in this example, which are coloured orange. Afterwards, the types for data points and
Functional Blocks are described (coloured blue). Additionally, general entities such as units and
enumerations (sometimes also referred to as encodings) are part of this HBES Information model
(coloured blue). Thus, all information that is required for the integration of the Home and Building
HBES Open Communication System into the HBES Gateway is available in this model. Models
conforming to the introduced vocabulary or an XML serialization of this vocabulary are provided at
interface 6 (see Figure 2) in order to integrate the structure of the desired Home and Building HBES
Open Communication System into a HBES Gateway implementation. As can be seen, the HBES
Information model is used to structure static information while runtime information is not part of this
model (e.g. current values of data points).
References between entities are realized by means of ref tags. Entities have a unique identifier using
the tag id. This identifier is used in the ref tags to establish a link between two entities. The example
shows two Group Objects (entities with marker groupObject). Each Group Object represents a
method for accessing a group in the underlying Home and Building HBES Open Communication
System. It can be linked with several data points, and it exists only in the internal domain of the HBES
Gateway. Web Clients do not directly use these access methods, but interact with the more abstract
data points. The HBES Gateway implementation decides internally on the correct access method for
the communication with the Home and Building HBES Open Communication System.
For a better understanding of the subsequent example, the particular modelling elements are
explained within the figure by means of the topmost entity. It shall be noted that the arrows do not
represent additional information. They are only used for better visualization of the dependencies
between entities.
Figure 6 — Exemplary HBES Information model
8 HBES Web interface OBIX
8.1 Introduction
This interface specifies the relationship between the HBES Gateway implemented in accordance with
the OBIX standard and the Web Clients as remote applications like building management systems
(BMSs). The description contains the following:
• the information presentation of the Home and Building HBES Open Communication System;
• the scheme for addressing Home and Building HBES Open Communication System objects
within the HBES Gateway; and
• an overview on interaction scenarios.
Thus, this interface specification shall be implemented in order to guarantee a standardized way of
interaction between a HBES Gateway and Web clients. Gateway internal processes and data
structures are out of scope of this standard. The aim is to define the interface for Web Clients. Thus,
these Web Clients can use a uniform interface for accessing the Home and Building HBES Open
Communication System.
8.2 Information presentation
8.2.1 Introduction
If the HBES Gateway is based on the OBIX standard, the information presentation in the HBES Web
interface shall be realized within the framework offered by OASIS.
OASIS OBIX specifies a simple and concise object model to represent the information. Everything is
modelled as an object in OBIX. Each object has a set of standardized attributes and may contain an
arbitrary number of child objects. Definitions exist for basic value objects (e.g. integer, date, or real), a
list object, an operation object, or a reference object to establish a link to other objects. The OBIX
concept is based on the Representational State Transfer (REST) paradigm, which is characterized by
its resource-orientation and the statelessness. According to this paradigm, each request is self-
contained, and the key elements of the provided services are resources (e.g. data points). Every
resource is accessed through a uniform interface via a unique address and a small set of operations.
In addition, so-called contracts can be specified to define new OBIX types. The contracts are
templates describing the syntax and the semantics of the derived, concrete objects. More details
about REST and the OBIX object model can be found in Clause 9.
A brief example that is derived from the HBES Information model example (see 7.4) demonstrates the
con
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...