EN 50090-6-3:2023
(Main)Home and Building Electronic Systems (HBES) - Part 6-3: 3rd Party HBES IoT API
Home and Building Electronic Systems (HBES) - Part 6-3: 3rd Party HBES IoT API
This document defines a 3rd Party API for the Home and Building HBES Open Communication System.
Elektrische Systemtechnik für Heim und Gebäude (ESHG) - Teil 6-3: Drittanbieter ESGH IoT API
Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) - Partie 6-3 : API tierce IdO HBES
Le présent document définit une API tierce pour le Système ouvert de communication pour les foyers domestiques et les bâtiments HBES.
Stanovanjski in stavbni elektronski sistemi (HBES) - 6-3. del: Tretja zveza HBES Iot API
Ta dokument opredeljuje vmesnik za aplikacijsko programiranje (API) tretje strani za odprti stanovanjski in stavbni komunikacijski sistem HBES.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-september-2023
Stanovanjski in stavbni elektronski sistemi (HBES) - 6-3. del: Tretja zveza HBES Iot
API
Home and Building Electronic Systems (HBES)- Part 6-3 -3rd Party HBES IoT API
Elektrische Systemtechnik für Heim und Gebäude (ESHG) – Teil 6-3: Drittanbieter ESGH
IoT API
Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) - Partie 6-
3 : API tierce IdO HBES
Ta slovenski standard je istoveten z: EN 50090-6-3:2023
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-3
NORME EUROPÉENNE
EUROPÄISCHE NORM July 2023
ICS 35.240.67; 97.120
English Version
Home and Building Electronic Systems (HBES) - Part 6-3: 3rd
Party HBES IoT API
Systèmes électroniques pour les foyers domestiques et les Elektrische Systemtechnik für Heim und Gebäude (ESHG) -
bâtiments (HBES) - Partie 6-3 : API tierce IdO HBES Teil 6-3: Drittanbieter ESGH IoT API
This European Standard was approved by CENELEC on 2022-12-22. 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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye 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: Rue de la Science 23, B-1040 Brussels
© 2023 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 50090-6-3:2023 E
Contents Page
European foreword . 3
1 Scope. 4
2 Normative references . 4
3 Terms, definitions and abbreviations . 4
3.1 Terms and definitions . 4
3.2 Abbreviations . 10
4 HBES IoT 3rd Party API . 11
4.1 Introduction . 11
4.1.1 Mapping of terms . 11
4.1.2 General . 12
4.1.3 API - Content . 13
4.1.4 API - Conformance . 13
4.1.5 API - Version . 14
4.1.6 API – Availability . 14
4.1.7 API – Data Format . 14
4.1.8 API – Examples Format . 14
4.1.9 Motivation . 14
4.1.10 Resources . 15
4.2 Specifications . 16
4.2.1 Server requirements . 16
4.2.2 Client requirement . 34
4.2.3 Message data structure . 34
4.2.4 URL structure . 52
4.2.5 Resource path definitions . 53
4.2.6 Discovery . 121
European foreword
This document (EN 50090-6-3:2023) 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) 2024-01-07
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) 2026-07-07
conflicting with this document have to be
withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national committee. A
complete listing of these bodies can be found on the CENELEC website.
1 Scope
This document defines a 3rd Party API for the Home and Building HBES Open Communication
System.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. 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
EN 50090-6-2, Home and Building Electronic Systems (HBES)- Part 6-2 IoT Semantic Ontology
model description
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 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1.1
actuator
point performing an actuation (executed by a specific procedure, with an expected result) that
changes an Installation state during Runtime
Note 1 to entry:
— The term Actuator can be mapped to sosa:Actuator in the SSN Ontology.
— The subject actuation can be mapped to sosa:Actuation in the SSN Ontology.
— The subject procedure can be mapped to sosa:Procedure in the SSN Ontology.
— The subject result can be mapped to sosa:Result in the SSN Ontology.
3.1.2
Application Function
function that uses a set of Functions to achieve the desired behaviour of a technical system, typically
using a combination of devices exchanging information via their input and output Datapoints
Note 1 to entry: An Application Function may be split into several Functional Blocks with their input and
output Datapoints that are logically connected to each other. The Functional Blocks may be located in one or
more devices.
EXAMPLE Application Functions examples are “direct electrical heating”, “electrical heating with
accumulators”, “warm water heating”, “fan coil air-conditioning” …
Note 2 to entry: The Application Function and Application are meant to be the same. Reason to introduce an
alias term is to use a clear (understandable) reference from Application/ Application Function to the
corresponding KIM class:ApplicationFunction or to the Function in the Management Client.
3.1.3
aspect
generally, a specific perspective on a system that contains things with different properties; a
referencing mechanism to organize KIM elements in a specific perspective
EXAMPLE A Function Point is an ex officio Aspect with an important specific perspective. It is a referencing
mechanism to organize together all to a Function Point interoperating Points (all GOs linked to a GA).
3.1.4
BIM
Building Information Model
digital process to describe and document a building in all its life cycle phases, from its planning,
construction, operation up to its demolition
3.1.5
channel
collection of Datapoints of a device that are logically related to each other typically by association with
a hardware feature or a specific function of that device
Note 1 to entry: These Datapoints may be derived from one or more defined Functional Blocks or may be an
expansion above and beyond defined Functional Blocks or may be independent of a Functional Block if none is
defined for the function associated with the Channel. The concept of a Channel is well-understood by the market
participant, e.g. installers.
3.1.6
datapoint
represents a logical input entity of a device acting as recipient of Installation state data, whereas a
logical output of a device acts as source of Installation state data
Note 1 to entry: In case of implementation as a Group Object, state data are communicated with the use of
Function Points.
Note 2 to entry: The term Datapoint is the common term; to specifically denote a Datapoint available on an
IoT 3rd Party API, the term IoT Datapoint is used.
3.1.7
device
physical element that is part of the network; it is a physical, concrete object that a customer can buy
3.1.8
endpoint
entry point to a service, a process, or a queue or topic destination in service-oriented architecture
3.1.9
Feature of Interest
abstraction of a real-world thing (phenomenon, equipment, person, event…) defined by its observable
or actuatable properties
Note 1 to entry: In colloquial terms, a FOI is a property carrier.
Note 2 to entry: A Sensor operates on a FOI with observable properties, an Actuator with actuatable
properties.
Note 3 to entry: A FOI is not a “classification/type” tag itself; the “classification/ type” is accomplished with
the help of tags. Examples are defined in 4.5.1.4.
3.1.10
function
describes a part of the intended behaviour of a FB in a building context
3.1.11
Functional Block
consists of one or more Functions that belong together and that cannot be separated across two
devices but big enough that a device with only one such Functional Block could be marketed
Note 1 to entry: A Functional Block has a well-defined black box behaviour.
3.1.12
Function Point
runtime system state information of a specific Application Function
Note 1 to entry: Shared by at least two Datapoints.
Note 2 to entry: Has a unique identifier that addresses a group of controlled objects. This identifier is called
a Group Address.
EXAMPLE < Light Switch > in living room on/off, whereas the < … > is the Function Point name
3.1.13
Group Address
numerical identifier of a Function Point
3.1.14
Group Communication
communication model in which one sender communicates information to one and typically more
receivers
Note 1 to entry: In IoT, this can be realized by simple UDP communication or by using a message broker
system or other.
3.1.15
Group Object
foreseen for Group Communication using Group Address(es)
Note 1 to entry: May be accessed via point-to-point communication without an assigned Group
Address. With assigned Group Address, it becomes a member of that Function Point represented by
the Group Address.
3.1.16
HBES Information Model
ontology based model of HBES System relevant parts, including additional semantic (dictionary)
information
Note 1 to entry: It is managed by the HBES Association, hence the abbreviation KIM.
3.1.17
Industry Foundation Classes
open standard to describe BIM data in a digital way
Note 1 to entry: IFC data and models are specified in ISO 16739-1.
3.1.18
installation
assembly of materials and components (devices) placed in position to provide a service
Note 1 to entry: An Installation is a deployed system (e.g. HVAC system or fire protection system) and
consists of equipment and Functions that are used for a particular purpose.
Note 2 to entry: In
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.