SIST EN 50090-6-2:2022
(Main)Home and Building Electronic Systems (HBES)- Part 6-2 IoT Semantic Ontology model description
Home and Building Electronic Systems (HBES)- Part 6-2 IoT Semantic Ontology model description
This document defines the HBES Information Model and a corresponding data exchange format for the Home and Building HBES Open Communication System.
Elektrische Systemtechnik für Heim und Gebäude (ESHG) - Teil 6-2: Beschreibung des IoT semantischen Ontologiemodells
Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) Partie 6-2: Semantic Ontology Model Description pour l’internet des objets
Le présent document définit le Modèle d'Information HBES et un format d'échange de données correspondant pour le Système ouvert de communication pour les foyers domestiques et les bâtiments HBES.
Stanovanjski in stavbni elektronski sistemi (HBES) - 6-2. del: Semantični opis ontološkega modela
Ta dokument opredeljuje informacijski model HBES in ustrezen format izmenjave podatkov za odprti stanovanjski in stavbni komunikacijski sistem HBES.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST EN 50090-6-2:2022
01-februar-2022
Stanovanjski in stavbni elektronski sistemi (HBES) - 6-2. del: Semantični opis
ontološkega modela
Home and Building Electronic Systems (HBES)- Part 6-2 IoT Semantic Ontology model
description
Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) Partie 6-2:
Semantic Ontology Model Description pour l’internet des objets
Ta slovenski standard je istoveten z: EN 50090-6-2:2021
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-2:2022 en,fr
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST EN 50090-6-2:2022
---------------------- Page: 2 ----------------------
SIST EN 50090-6-2:2022
EUROPEAN STANDARD EN 50090-6-2
NORME EUROPÉENNE
EUROPÄISCHE NORM December 2021
ICS 97.120; 35.240.67
English Version
Home and Building Electronic Systems (HBES)- Part 6-2 IoT
Semantic Ontology model description
Systèmes électroniques pour les foyers domestiques et les Elektrische Systemtechnik für Heim und Gebäude (ESHG) -
bâtiments (HBES) - Partie 6-2: Description du modèle Teil 6-2: Beschreibung des IoT semantischen
ontologie sémantique loT Ontologiemodells
This European Standard was approved by CENELEC on 2021-09-20. 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,
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: Rue de la Science 23, B-1040 Brussels
© 2021 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 50090-6-2:2021 E
---------------------- Page: 3 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
Contents Page
European foreword . 2
1 Scope. 3
2 Normative references . 3
3 Terms, definitions and abbreviations . 3
3.1 Terms and definitions . 3
3.2 Abbreviations . 9
4 HBES Information Model . 10
4.1 Motivation and current situation . 10
4.2 Introduction . 11
4.2.1 General . 11
4.2.2 KIM – Content . 13
4.2.3 KIM - Version . 14
4.2.4 KIM - Availability . 15
4.2.5 KIM - Data Format and Data Exchange Format . 15
4.2.6 KIM - Ontology IRIs and Namespaces . 15
4.2.7 KIM - Ontology Classes . 17
4.2.8 KIM - Semantic Dictionary . 17
4.3 Location Model . 22
4.3.1 Introduction . 22
4.3.2 Requirements . 23
4.3.3 Class and subclasses . 24
4.4 Installation Model . 28
4.4.1 Introduction . 28
4.4.2 Classes and subclasses . 29
4.5 Tag Model . 53
4.5.1 Introduction . 53
4.5.2 Tag Model – Points . 57
4.5.3 Tag Model – Function Points . 58
4.5.4 Tag Model – Application Function . 59
4.5.5 Classes and subclasses . 59
4.5.6 Tag Cardinalities . 70
4.6 Model Relations . 70
4.6.1 General . 70
4.6.2 Location Relations . 70
4.6.3 Installation Relations . 73
4.6.4 Tag Relations . 81
1
---------------------- Page: 4 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
European foreword
This document (EN 50090-6-2:2021) 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) 2022-09-20
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) 2022-09-20
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.
2
---------------------- Page: 5 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
1 Scope
This document defines the HBES Information Model and a corresponding data exchange format 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
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
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
---------------------- Page: 6 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
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, a 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 is 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
4
---------------------- Page: 7 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
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), 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 KNX 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 relation to this term created data correlates to the installation model, described in 4.2.
[SOURCE: ISO 6707-1:2020, modified – added "(devices)" and Notes to entry.]
5
---------------------- Page: 8 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
3.1.19
IoT Datapoint
rd
represents an Endpoint at an IoT 3 Party API that:
a) corresponds to one or more Function Points, such as a state data representation of a discrete
state in a building context:
EXAMPLE 1 brightness → discrete state “brightness” is represented by the value 65 (percent)
rd
b) is a fully qualified URL e.g. provided by an IoT 3 Party Server
EXAMPLE 2 https://gateway.hbes.local/hbes/api/v1/datapoints/{Id}
3.1.20
IoT Function
rd
Party API that:
represents a Function at an IoT 3
— is as a collection of IoT Datapoints that fulfils a – by the user – intended behaviour
EXAMPLE “living room – rear light dimming”, “kitchen – floor heating”
Note 1 to entry: In a Mac, an IoT Function is instantiated data of a MaC Function in an Installation respectively
MaC project. The MaC Function itself may base on an Application Function.
3.1.21
rd
IoT 3 Party API
set of requirements and regulations through which partial access to an Installation can be gained by
offering a collection of Endpoints
3.1.22
rd
IoT 3 Party Client
rd
device or service interacting with the Installation from outside using the IoT 3 Party API
rd rd
Note 1 to entry: The IoT 3 Party Client connects to a single device that provides the IoT 3 Party API and can
use this single device to fully interact with the Installation, possibly depending on a specified authorization
mechanism.
EXAMPLE 1 A mobile phone (from inside the network, or from an Internet connection) with typically short
period connections.
rd
EXAMPLE 2 A weather service permanently feeding in its weather information using the IoT 3 Party API.
3.1.23
rd
IoT 3 Party Server
rd
device that implements the IoT 3 Party API
Note 1 to entry: This can be a dedicated device; this can be a function of a device that supports other HBES
IoT and non HBES functionalities; it may be located within the local LAN of the IoT installation or outside.
3.1.24
MaC Catalog Entry
created management client data correlating to the product model, described in 4.2
3.1.25
MaC Function
Application Function created by the MaC and assigned to a building structure element, grouping
several Group Addresses
6
---------------------- Page: 9 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
3.1.26
MaC Project
project created by a MaC documenting the Configuration of an Installation
3.1.27
Management Client
means to configure and commission Devices as well as to plan, design and diagnose an entire
Installation
Note 1 to entry: The MaC is used to configure and commission Devices, as well as to plan, design and
diagnose an entire Installation. As a final step the MaC writes specific configuration data such as Device
parameters to the Devices.
3.1.28
ontology
conceptual descriptions of things that have a real-world commonality sharing the knowledge of a
domain, mainly expressed with OWL
Note 1 to entry: Ontologies are a structured way to describe the meaning of data in ontology classes and
should not be mixed up with common data model structures.
3.1.29
Object Property
in OWL a built-in concept that connects pairs of individuals, an object property expression
represents the (entire) relationship between the pairs of individuals
3.1.30
OWL
OWL 2 Web Ontology Language, informally OWL 2, specified by the World Wide Web Consortium
(W3C), mainly serialized with XML syntax for RDF (RDF/XML)
Note 1 to entry: In this specification the abbreviation OWL is always an explicit reference to OWL 2.
3.1.31
point
represents an interface to data in the system
Note 1 to entry: This document uses the term Point as an umbrella for data that can be accessed from outside
of the Device, for instance to interact with other Points from other Devices. Consequently, term Point is a generic
superset of the term Datapoint (which describes more precisely the technics how the “data” in the system are
structured and/or coded).
3.1.32
Point API
simple RESTful (CoAP or HTTP) application programming interface designed for, but not limited to,
constrained class 2 devices [RFC7228] supporting device individualization, device linking and
accessing device runtime data (e.g. Functional Block or Channel Datapoints)
3.1.33
Quality Kind
represents a certain combination of observable or actuatable properties, available as predefined parts
of the Semantic Dictionary or created individually during Configuration; the latter is the case when a
Quality Kind with the intended combination of properties respectively tags is not (yet) part of the
dictionary
Note 1 to entry: A QK 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.
7
---------------------- Page: 10 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
3.1.34
RDF
Resource Description Framework, as specified by the https://www.w3.org/RDF/
Note 1 to entry: RDF is a framework to represent information in the web by using triples. The information can
be serialized and stored in many formats such as the TURTLE or JSON(-LD) format. The general RDF concept
description can be found under https://www.w3.org/TR/rdf11-concepts/
3.1.35
runtime
process-to-process communication of data between devices, opposing to Configuration
Note 1 to entry: This concerns mainly the communication of Datapoint values (control and status information).
3.1.36
Semantic Export
project exported by the MaC reflecting an Installation in a linked data format
Note 1 to entry: The exported data is:
— structured according to the KIM, such as using Object Properties defined in KIM;
— annotated with additional semantic information from the Semantic Dictionary;
— referencing concepts of external Ontologies.
3.1.37
semantic dictionary
set of standardized terms allowing to annotate required parts of an Installation
Note 1 to entry: For details, see 4.2.8.
3.1.38
sensor
point performing an observation (executed by a specific procedure, triggered by a stimulus),
responding a result as an Installation state during Runtime
Note 1 to entry:
— The term Sensor can be mapped to sosa:Sensor in the SSN Ontology.
— The subject observation can be mapped to sosa:Observation in the SSN Ontology.
— The subject stimulus can be mapped to ssn:Stimulus 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.39
tag
kind of annotation term used to extend available data with (in most cases) well known standardized
information from a dictionary (in contrast to user defined, arbitrary term)
Note 1 to entry: A Tag is a concept-less term, without an integration in a broader concept such as the concept
of a Datapoint (used in an Application Function), it has a limited semantic meaning.
EXAMPLE Term “flow” has a weak meaning on its own, but if you relate it in a FOI with the other term
“water” this expresses at least that you observe/ actuate the water flow.
In this specification a Tag is almost exclusively a term from the Semantic Dictionary.
8
---------------------- Page: 11 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
3.1.40
thing description
semantic metadata model to describe (abstract or physical) things, as specified by the thing
description https://www.w3.org/TR/wot-thing-description/ and thing Ontology
https://www.w3.org/2019/wot/td
Note 1 to entry: TD relevant relations are described in the clause of Semantic Export.
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
DHWC Domestic Hot Water Controller
FOI Function of Interest
BOC Boiler Controller
BUC Burner Controller
FTC Flow Temperature Controller
GA Group Address
GO Group Object
FB Functional Block
FP Function Point
HBES Home and Building Electronic Systems
HDTRT Heat Demand Transformer Room Temperature
HFDM Heat Flow Demand Manager
HIRC Heating Individual Room Controller
HPM Heat Producer Manager
HVA Heating Valve Actuator
HZC Heating Zone Controller
IFC Industry Foundation Classes
IOO Info On off
IO Input Output
IoT Internet of Things
KIM HBES Information Model managed by KNX Association
KNXA KNX Association
MaC Management Client
OP Object Property
QK Quality Kind
RSM Room Setpoint Manager
RTC Room Temperature Controller
RTS Room Temperature Sensor
SOO Switch on/off
TD Thing Description
9
---------------------- Page: 12 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
4 HBES Information Model
4.1 Motivation and current situation
The current HBES model/ data information is based on XML, is managed by the KNX Association and
has its corresponding versioning. Project/ product data exported by existing HBES management
clients are in line with this XML schema.
The HBES Management clients use the XML schema mainly to define the corresponding data
structures to store/export project and product data. Consequently, the XML schema is always updated
when new versions of the HBES management clients are published, and new project and/or product
features demand a change of the data structures.
Though XML itself is a well-known and widespread format it has its drawbacks as regards:
— sharing model/project data information with external clients that use this data need to be
synchronized when a new XML schema version is announced;
— describing, expressing, mapping and sharing (semantic) information in the IoT domain.
The aim and motivation is to define a HBES Information Model and a corresponding data exchange
format:
— The model expresses only the current - by external clients requested – information.
— The model can be also easily updated.
— The exported data uses a widely used data exchange format, which should also be readable by
humans, meaning it is text based.
This model and data exchange format is more stable, compared to the frequent HBES management
client evolution.
— The HBES Information Model will be available as ontology in one or more formats, such as turtle
files.
— The data exported by HBES management clients will be available as linked data, such as JSON-
LD files.
The HBES IoT protocol suite shall support semantic information, both for runtime as well as for
configuration.
This information shall be brought to the system components in a data driven way, by the HBES
management clients software and possible other sources. It shall thus build on the information
rd
provided by the HBES management clients user, to avoid having to be entered again in the 3 Party
Client configuration.
The semantic information shall comply with the HBES standard and be available as public
information. Technically this information will be available as linked data, expressed with triples.
The use of semantics itself allows to formalize, restrict, and verify the usage of HBES subjects to
describe entities, relationships, and tags (entities have some relationship predicate to some other
entities— essentially a directed edge in a graph).
This simple (triple) structure enables the succinct and elegant composition of large, interconnected
structures of facility (building) subsystems.
The KIM shall be able express relations in an Installation to support the following use cases to
request/ query data.
— How is a building structured with floors, rooms and other?
— Where is an equipment (e.g. a Device) installed in a location (assembly place)?
10
---------------------- Page: 13 ----------------------
SIST EN 50090-6-2:2022
EN 50090-6-2:2021 (E)
— Which overall functionality is hosted on a Device?
— Which interface (e.g. a Point) is provided by a functionality or Device (Channel, FB)?
— Which Application Function affects which building structure elements, such as a room?
— What does an Application Function or Point observe or actuate upon in the real world (key word
→ feature of interest with substance, phenomenon and equipment)?
— In which operational domain or for which trades does an Application Function operate (key word
→ assignments of trades for Application Functions)?
— Which Points belong to an Application Function and what is the purpose of the Point (key word →
tag information: Logical Input/ Logical Output, Set Value or Parameter Point).
— Which phase feeds the load (e.g. Light Fixture/ Luminaire, Motor)?
— What are the setpoint and current temperature values in a specific location (room, zone) / a list of
locations?
— What is the current operation mode of primary systems (heating, cooling, ventilation, hot water
supply) in general or in location x?
— What is the identifier of a specific heating circuit (= connection from heating source
...
SLOVENSKI STANDARD
oSIST prEN 50090-6-2:2020
01-maj-2020
Stanovanjski in stavbni elektronski sistemi (HBES) - 6-2. del: Semantični opis
ontološkega modela
Home and Building Electronic Systems (HBES)- Part 6-2 IoT Semantic
Ontology_Model_Description
Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) Partie 6-2:
Semantic Ontology Model Description pour l’internet des objets
Ta slovenski standard je istoveten z: prEN 50090-6-2
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
oSIST prEN 50090-6-2:2020 en,fr
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 50090-6-2:2020
---------------------- Page: 2 ----------------------
oSIST prEN 50090-6-2:2020
EUROPEAN STANDARD DRAFT
prEN 50090-6-2
NORME EUROPÉENNE
EUROPÄISCHE NORM
March 2020
ICS
English Version
Home and Building Electronic Systems (HBES)- Part 6-2 IoT
Semantic Ontology_Model_Description
To be completed To be completed
This draft European Standard is submitted to CENELEC members for enquiry.
Deadline for CENELEC: 2020-06-12.
It has been drawn up by CLC/TC 205.
If this draft becomes a European Standard, 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.
This draft European Standard was established by CENELEC 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,
Turkey and the United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.
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
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Project: 66523 Ref. No. prEN 50090-6-2 E
---------------------- Page: 3 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
1 Contents Page
2 European foreword . 3
3 1 Scope. 4
4 2 Normative references . 4
5 3 Terms, definitions and abbreviations . 4
6 3.1 Terms and definitions . 4
7 3.2 Abbreviations . 4
8 4 HBES Information Model (Ontology) . 4
9 4.1 Motivation . 4
10 4.2 Introduction . 5
11 5 Location Model . 6
12 5.1 Introduction . 6
13 5.2 Classes and Relations . 7
14 5.2.1 Introduction . 7
15 5.2.2 Classes . 9
16 5.2.3 Relations . 14
17 6 Device Model . 16
18 7 Point Model . 17
19 8 Tagging Model . 27
20 8.1 Introduction . 27
21 8.2 Entities and Relations. 28
22 Bibliography . 31
23
2
---------------------- Page: 4 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
24 European foreword
25 This document (prEN 50090-6-2:2020) has been prepared by CLC/TC 205 “Home and Building
26 Electronic Systems (HBES)”.
27 This document is currently submitted to the Enquiry.
28 The following dates are proposed:
• latest date by which the existence of this (doa) dor + 6 months
document has to be announced at national
level
• latest date by which this document has to be (dop) dor + 12 months
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) dor + 36 months
conflicting with this document have to be (to be confirmed or
withdrawn modified when voting)
3
---------------------- Page: 5 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
29 1 Scope
30 This document defines the HBES Information Model and a corresponding data exchange format for
31 the Home and Building HBES Open Communication System.
32 2 Normative references
33 The following documents are referred to in the text in such a way that some or all of their content
34 constitutes requirements of this document. For dated references, only the edition cited applies. For
35 undated references, the latest edition of the referenced document (including any amendments)
36 applies.
37 EN 50090-1, Home and Building Electronic Systems (HBES) - Part 1: Standardization structure
38 3 Terms, definitions and abbreviations
39 3.1 Terms and definitions
40 For the purposes of this document, the terms and definitions given in EN 50090-1 apply.
41 ISO and IEC maintain terminological databases for use in standardization at the following addresses:
42 • IEC Electropedia: available at http://www.electropedia.org/
43 • ISO Online browsing platform: available at http://www.iso.org/obp
44 3.2 Abbreviations
45 For the purposes of this document, the following abbreviations apply.
IoT Internet of Things
HBES Home and Building Electronic Systems
46 4 HBES Information Model (Ontology)
47 4.1 Motivation
48 The current HBES model/ data information is based on XML, is managed by the KNX Association and
49 has its corresponding versioning. Project/ product data exported by existing HBES management
50 clients are in line with this XML schema.
51 Even if XML itself is a well-known and widespread format, it has its drawbacks in the context of
52 sharing model/ project data information with external clients using this data. HBES management
53 clients use the XML schema mainly to define the corresponding data structures to store/ export
54 project and product data. Consequently, the XML schema is always updated when a new
55 management client version is published, when new project and/or product features demand also a
56 change of the data structures. This requires always a synchronization with the external clients to
57 announce new XML schema versions.
58 The aim and motivation is to define a HBES Information Model and a corresponding data exchange
59 format:
60 — The model expresses only the current - by external clients requested - information
61 — The model can be also easily updated
62 — The exported data uses a widely used data exchange format, which should also be readable by
63 humans, means they are a text based.
4
---------------------- Page: 6 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
64 This model and data exchange format is more stable, compared to the frequent HBES management
65 client evolution.
66 — The HBES Information Model will be available as ontology in one or more formats, such as turtle
67 files.
68 — The data exported by HBES management clients will be available as linked data, such as JSON-
69 LD files.
70 The HBES IoT protocol suite shall support semantic information, both for runtime as well as for
71 configuration.
72 This information shall be brought to the system components in a data driven way, by the HBES
73 management clients software and possible other sources. It shall thus build on the information
rd
74 provided by the HBES management clients user, to avoid having to be entered again in the 3 Part
75 Client configuration.
76 The semantic information shall comply with the HBES standard and be available as public
77 information. Technically this information will be available as linked data, expressed with triples.
78 The use of semantics itself allows to formalize, restrict, and verify the usage of HBES subjects to
79 describe entities, relationships, and tags (entities have some relationship predicate to some other
80 entities— essentially a directed edge in a graph).
81 This simple (triple) structure enables the succinct and elegant composition of large, interconnected
82 structures of facility (building) subsystems.
83 4.2 Introduction
84 The HBES system is designed for direct exchange of information (i.e. communication) between
85 networked devices controlling applications in and around buildings. See Figure 1.
86
87 Figure 1 — HBES environment
88 These different aspects of the HBES environment are reflected by an individual “model” for Location,
89 Devices, Applications as well as the Communication for exchange of control information. All individual
90 model parts together form the entire HBES IoT Information Model as a single ontology. Ontologies are
91 a structured way to describe the meaning of data and should not be mixed up with common data
92 model structures. Ontologies work with the term “concepts” to describe things that have a real-world
93 commonality. In the ontology itself such things are expressed technically as ontology classes.
94 For simplification the term model will be used further down. Figure 2 describes the HBES Information
95 Model parts. It contains the following:
96 — Equipment (devices and other physical assets)
97 — Application Software (software to run the intended system behaviour)
5
---------------------- Page: 7 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
98 — Point (interface to interact with data points mainly provided by devices
99 — Aspects (grouped points that identify a specific view/perspective to the system)
100 — Location (structural building elements)
101
102 Figure 2 — HBES Information Model
103 The HBES Information Model builds upon other work in several ways.
104 It is inspired by the BRICK concept to model Points, Equipment and Context and their relationships.
105 It can be extended with tagging vocabulary such as Haystack.
106 In addition, it uses the location concepts from IFC and allows a semantic representation to utilize its
107 flexibility and extensibility. For this the HBES Information Model supports an explicit mapping to IFC
108 with a so called “bridging” ontology. The HBES-IFC mapping, respectively the bridging is available as
109 electronic turtle file under https://schema.knxiot.org/ontology/owl-mapping/knx-ifc-mapping.
110 The current HBES Information Model does not consider other aspects of a HBES installation such as
111 for instance topology or device models.
112 5 Location Model
113 5.1 Introduction
114 The Location model wishes to address the following requirements.
115 — Bridging to BIM
116 Many concepts of the Location model match concepts provided by the Industry Foundation Class
117 Ontology (ifcowl) that has been created to work with BIM models. In particular, Building, Floor and
118 Space map to IfcBuilding, IfcBuildingStorey and IfcSpace and thus make bridging to a BIM model
119 quite easy.
120 — Alternate hierarchies
6
---------------------- Page: 8 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
121 The common superclass Location of HBES IoT Information Model allows specifying an alternate
122 location hierarchy or not strictly sticking to the usual hierarchy, should someone - for some reason –
123 want to do so.
124 EXAMPLE 1 A HBES IoT Information Model element Room can be associated directly with a Building (rather
125 than with a Floor, as usual) semantically strongly expressed via object property “hasRoom” or semantically
126 weakly expressed via the object property “hasSubLocation”, without violating any constraints specified by the
127 Location model.
128 — Extensibility
129 The concept Space represents a generic location inside a building. Therefore, it can also be used to
130 define types of Locations that do not fit directly into the fabric of the existing Location model classes.
131 This can either be achieved by defining (in an extension of the current HBES Information Model)
132 additional properties or by defining new subclasses of Space that are better suited for the respective
133 purpose.
134 EXAMPLE 2 If it is wanted to model a wing as a part of a building, then a class Wing with specific wing
135 properties may be added.
136 5.2 Classes and Relations
137 5.2.1 Introduction
138 This section contains a formalized description of the location model as shown in the Figure 3 below.
139 — The blue box denotes the topmost generic Location, from which all subclasses are derived.
140 — Green boxes denote HBES Information Model concepts that are mapped to IFC concepts with
141 the HBES- IFC mapping ontology.
142 — White boxes with annotation “subClassOf” define specific (child) Location classes, white boxes
143 without this annotation describe concepts, independent from the concept Location.
144 — Red dotted lines and their direction describe relationships between classes.
7
---------------------- Page: 9 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
145
146 Figure 3 — Location Model
147 Ontology classes or their relationships have many properties. Only the main ontology classes and
148 their main properties are described here.
149 Not all relationship properties (such as being “functional”), their property domain/ range and possible
150 available inverse properties to this relationship are enumerated in the below lists. Also, if a class
151 supports an explicit name and/or description is not mentioned hereunder.
152 For these details, please refer to the HBES IoT Information Model under
153 https://schema.knxiot.org/ontology/full.
8
---------------------- Page: 10 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
154 5.2.2 Classes
155 Table 1 — Classes of the Location Model
Class Definition
Location Description
A Location is a physical named geographical place (such as “Lake side
meeting room”, “Oskar's office”, “The 5th floor”, “Mountain view dwelling”
etc.) that is used to identify a point, an area or room, inside or outside of a
Building.
Main Properties
— hasSubLocation
— hasAdjacentLocation
— hasLocationType
— hasAddress
— hasPerimeter
— hasFunction
— hasDevice
Sub Class of
-
Disjoint With
— all root classes of HBES IoT Model
Notes
The class Location can be used as a bridging class to other ontologies
(e.g. to the Point model, see Clause 1.5).
Site Description
A Site represents a collection of Buildings and grounds that belong to a
given institution.
Main Properties
— hasBuilding
— hasSiteSegment
Sub Class of
Location
Disjoint With
— Building, Floor, Space
Notes
The concept Site can be mapped to an IFC Site.
9
---------------------- Page: 11 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
Class Definition
SiteSegment Description
A SiteSegment is a part of a ground, land or of a campus. It subdivides a
Site.
Main Properties
-
Sub Class of
Site
Disjoint With
-
Notes
The concept SiteSegment can be mapped to an IFC Site.
Building Description
A Building represents a whole building. A real-world building hosts several
other real-world elements such as stacked floors or spaces or rooms, in
ontology terms this would a Room, Floor, Space, RoomSegment.
Main Properties
— hasFloor
— hasRoom
— hasRoomSegment
— hasSpace
Sub Class of
Location
Disjoint With
— Site, Floor, Space
Notes
For a Building, it might also make sense to specify a LocationType and/or
an Address.
The concept Building can be mapped to the IFC concept IfcBuilding.
10
---------------------- Page: 12 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
Class Definition
Floor Description
A Floor is a level or plane concept in a building. A Floor is separating a
Building into horizontal spaces.
A Floor can have Space assigned, in particular a Room or a
RoomSegment.
Main Properties
— hasLowerFloor
— hasUpperFloor
— hasRoom
— hasRoomSegment
— hasSpace
Sub Class of
Location
Disjoint With
— Site, Building, Space
Notes
For a Floor, it might make sense to specify a LocationType, while a postal
Address is usually already specified for the Building containing the Floor.
The concept Floor can be mapped to the IFC concept IfcBuildingStorey.
Space Description
A Space represents any kind of physical space that belongs to a Building
(inside or outside). Space can be also used on its own as a generic
location. Furthermore, it can be subdivided into locations of type Space or
any of its subclasses (Room, RoomSegment).
Main Properties
— hasRoom
— hasRoomSegment
— hasSpace
Sub Class of
Location
Disjoint With
— Site, Building, Floor
Notes
The concept Space can be mapped to the IFC concept IfcSpace.
11
---------------------- Page: 13 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
Class Definition
Room Description
A Room is a Space in a Building that is delimited by walls, ceilings, floors,
windows and doors.
A Room can be subdivided into locations of type RoomSegment.
A Room may also be part of another Room.
Main Properties
— hasRoom
— hasRoomSegment
— hasRoomType
Sub Class of
Space
Disjoint With
— RoomSegment
Notes
The concept Room can be mapped to the IFC concept IfcSpace.
RoomSegment Description
A RoomSegment is an indoor space that represents a subdivision of a
Room.
Besides that, a RoomSegment may also be part of any other kind of
Space, e.g. a Building or a Floor.
A RoomSegment can be further subdivided into locations of type
RoomSegment.
Main Properties
— hasRoomSegment
— hasRoomType
Sub Class of
Space
Disjoint With
— Room
Notes
The concept RoomSegment can be mapped to the IFC concept IfcSpace.
12
---------------------- Page: 14 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
Class Definition
Address Description
An Address is represented by an external ontology object of type
vcard:Address, which has data properties such as country-name, locality
(city), street-address.
Address can be assigned to any location via hasAddress property, but
preferably to a Site or a Building.
Main Properties
-
Sub Class of
-
Disjoint With
— all root classes of HBES IoT Model
Notes
-
PerimeterType Description
The PerimeterType denotes if a given location is inside or outside of a
Location, preferably with respect to a Building.
Outside is preferably used to a Site or a Building, while inside can be used
for a Room, RoomSegment, Floor and other.
Main Properties
-
Sub Class of
Property
Disjoint With
— all subclasses of class Property
Notes
PerimeterType is a class with two individuals (outside, inside).
Examples for such outside locations are “West Facade” or “Rooftop”; it is
obvious that they require some association with a particular building and
probably also (in case of a facade) a specification of an outside direction
(e.g. “West”).
Hence this further object properties/ attributes are required to specify the
concept of being “inside” or “outside” of something more precisely, such as
the above-mentioned geographical direction of something else that is
interpreted as outside.
13
---------------------- Page: 15 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
Class Definition
LocationType Description
LocationType defines several subclasses, each of it responsible for its own
usage concept.
— the concept room types with usage enumeration values “kitchen,
bath, …”
— the concept other types usage enumeration values “garden,
garage, parking place, …”).
This kind of attribute is preferably associated with locations of type Site or
Building but can also be used for any other kind of location, e.g. Space,
Room or RoomSegment.
The LocationType subclass RoomTypes defines the intended usage of a
Location and is preferably associated with locations of type Room or
RoomSegment but can be also used for any other kind of location, e.g.
Building or even Site.
The LocationType subclass OtherTypes defines the intended usage of a
Location and is preferably associated with locations of type Site.
Main Properties
-
Sub Class of
Property
Disjoint With
— all subclasses of Property
Notes
LocationType, subclass RoomTypes is an open enumeration and can be
extended.
LocationType, subclass OtherTypes is an open enumeration and can be
extended.
156 5.2.3 Relations
157 The class relationship describes the mandatory object relation, if given the second relationship (in
158 italic) describes the corresponding inverse relation. Domain/ Range is described for the mandatory
159 relation (usually domain and range are interchanged here). See Table 2.
160 Table 2 — Relations of the Location Model
Class Definition Domain Range
Relationship
hasSubLocation / Generically expressed semantic relationship :Location :Location
isSubLocationOf to any subclass of a Location, e.g. a room as
sub-location of a floor.
Sub Property of
RefersTo (Transitive)
hasAdjacentLocatio Relationship between two Locations that :Location :Location
n share a common interface such as a wall or
door, but do not intersect.
Sub Property of
hasAdjacency
14
---------------------- Page: 16 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
Class Definition Domain Range
Relationship
hasPerimeter / Relationship of a Location to express the :Location :Perimeter
isPerimeterOf relationship if this Location is inside or Type
outside.
Mainly used in conjunction with buildings, see
also class Building.
Sub Property of
-
hasLocationType / Generically expressed semantic relationship :Location :LocationT
isLocationTypeOf of a Location to express how the Location is ype
being used.
Sub Property of
-
hasRoomType / Strongly expressed semantic relationship of a :Room :RoomTyp
isRoomTypeOf Room or RoomSegment on how the Room or or:RoomS e
RoomSegment is used. egment
The relationship is a subproperty of
hasLocationType.
Sub Property of
hasLocationType
vcard:hasAddress Relationship of a Location to its Address. :Location vcard:Add
ress
Sub Property of
-
hasBuilding / Strongly expressed semantic relationship to a :Site :Building
isBuildingOf Building contained in a Site.
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasFloor / Strongly expressed semantic relationship to a :Builidng :Floor
isFloorOf
Floor contained in a Location.
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasUpperFloor / Relationship from one Floor to another Floor. :Floor :Floor
isUpperFloorOf
The relationship is a subproperty of
hasProximity.
Sub Property of
hasProximity
15
---------------------- Page: 17 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
Class Definition Domain Range
Relationship
hasRoom / Strongly expressed semantic relationship to a :Building :Room
isRoomOf Room contained in a Location. or:Space
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasRoomSegment / Strongly expressed semantic relationship to a :Room :RoomSeg
isRoomSegmentOf RoomSegment contained in a Room or or:RoomS ment
RoomSegment. egment
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasSpace / Strongly expressed semantic relationship to a :Building :Space
isSpaceOf Space contained in a Location. or:Space
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasSiteSegment / Strongly expressed semantic relationship to a :Site :SiteSegm
isSiteSegmentOf
SiteSegment contained in a Site. ent
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
161 6 Device Model
162 In the Device model, the parts of the devices are identified that are required in a HBES IoT
163 environment such as semantic export data and data accessible via the KNX IoT interfaces.
164 These identified elements need to be part of the HBES IoT Model.
165 As already mentioned in the chapter introduction of HBES IoT Information Model; devices are the
166 most important elements of the entire model. Devices provide Points, which are the principal data
167 interfaces of the entire installation. With their links to other Points, they build up the entire intended
168 Application Communication of the installation.
169 As an important note here, the above-mentioned links between the Points do not establish
170 automatically an Application Communication in a unicast (one to one point) or multicast (one to many
171 point) way. Technically, in HBES this is achieved by grouping (known as linking) the intended points
172 with a unique HBES group address “link”. The concept corresponding to this “link” is referred to as a
173 FunctionPoint. This is referred to as group communication.
174 In a simplified view, a device consists of two main parts.
175 1) Device hardware (such as a PCB, the device housing or “hardwired” IO input/output terminals)
16
---------------------- Page: 18 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
176 2) Application Software (provides “logical” interface IOs and Parameter values controlling the IO
177 behaviour at runtime). In the end, it is the task of the application software to handle all IO
178 requests at runtime.
179 From the perspective of logical interworking at runtime, inputs/outputs for process communication,
180 parameter and diagnostic Points exist (see the brown boxes below in Figure 4).
181 A Point may represent information of the device itself (e.g. life check signalling, power on LED) or
182 data related to the intended automation functionality.
183 This document uses the term Point as an umbrella for data that can be accessed from outside of the
184 device, for instance to interact with other Points from other devices.
185 The device depicted below hosts an Application Software represented by a blue box that contains
186 physical and logical inputs and outputs.
187 These in/outputs could belong to a dedicated device channel with the related hardware IOs (for
188 example n- dimming channel - terminals in a n- fold dimming actuator device). In this case each
189 channel is also representing a specific Functional Block, here a FB “Dimming Actuator” with its
190 mandatory/ optional in/outputs, parameter or diagnostic Points.
191 a) Parameter Points are available for Application Software configuration
192 b) Diagnostic Points are available for monitoring purposes.
193 c) Input
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.