Home and Building Electronic Systems Information Model (EN50090-6-2)

Overview

The European standard EN50090-6-2 defines the schema and vocabulary for describing building automation system graphs. It standardizes the semantic representation of devices, datapoints, locations, and their relationships within an installation.

The information model supports Energy Efficiency Classification, Commissioning and Smart Linking, and semantic project export/import through ETS. These capabilities enable subsystem integration, visualizations, and other applications.

For context on how the information model fits into the broader KNX IoT architecture, see the System Overview. For details on the Point API stack that implements device communication, see the Point API Introduction.

Specifications and Ontology Files

The specification 3-10-3 KNX IoT Information Model and published schemas are available at schema.knx.org and GitLab. To visualize and explore the ontology hierarchy, see the Model Viewer page.

Model Concepts

The Knowledge and Information Model (KIM) comprises several models. KNX related definitions extend these. Together they describe the different aspects of the building control domain. Each model uses an individual namespace prefix. It defines a specific set of semantically standardized entities and relationships amongst them.

Core model:

• Describes the common concepts of the building control domain for an Installation.
• A datapoint (I/O interface) of a device, where the device resides in a room.

Aspect model:

• Describes the grouping concepts for datapoints across devices to represent functional aspects of an Installation.
• An Application Function groups sensor and actuator datapoints to control, for example, the room temperature. A Function Point represents communication links between devices.

Location model:

• Describes the spatial location structure of an Installation.
• A location structure represents a building with rooms, floors, and other spatial divisions.

Tag model:

• Describes a set of entities used as indications for information classification. Each entity has a standardized semantic meaning independent of an Installation.
• A device with datapoints, where each datapoint carries specific tags such as output interface, air, or temperature.

KNX model:

• Describes KNX system-specific entities for an Installation.
• A device with datapoints (core model concepts), where each datapoint carries a specific datapoint type (DPT) (a KNX model concept), such as a boolean type for the values 'on' or 'off'.

The KNX Model derives from the Core, Tag, and Location models. The entire Information Model represents an aggregation of the models.

Information Model = Core/Location/Tag/KNX model + Semantic Dictionary

Separating a model and its entities enables independent extension/update. Especially for the content of the Semantic Dictionary, which is subject to change such as when including a new functional block or similar.

Semantics

The semantic understanding and meaning of an ontology must remain consistent across different domains and humans. Tools and machines that process this information (pre/post-processing) depend on this consistency. The Knowledge and Information Model (KIM) comprises various ontology classes that define terms and concepts with clear semantic specifications for the building control domain.

From the perspective of a control system, user, system integrator, or installer, the information model addresses the following aspects of an installation:

• The physical placement (Location) of Devices and the Points that they host.
• The association of Points on a Device with their corresponding Application Functions.
• The Location where an Application Function exerts its influence or control.
• The interaction between an Application Function or its Points with the physical world, including the observed phenomena or substances and the corresponding measurements.
• The interplay between different Application Functions, such as the flow of energy from energy producers to energy consumers.

Asset Entities

The diagram illustrates the concept of an Asset, which represents something of economic value owned and managed by an entity, such as a service organization. An Asset differs from a building's structure but sits inside or attaches to it.

Assets fall into two categories:

• Tangible Assets: Physical properties with a visible presence within the building, commonly associated with fixed assets. This category includes buildings, HVAC systems, and equipment.
• Intangible Assets: Non-physical assets that require management, such as licenses for commissioning tools or office software. These assets hold value despite lacking a physical presence.

The diagram also includes a device, such as a KNX device, which is a product from a manufacturer. The devices or equipment typically have an installation or mounting Location.

Location Entities

The diagram illustrates the location model, which encompasses the essential concepts for describing the location structure of an Installation. This model defines a minimal ontology that establishes relationships between different locations. Some concepts align with the IFC Ontology, enabling compatibility with Building Information Modeling (BIM) models.

The diagram focuses on the core entities for modeling a building: floors, spaces, and rooms. Each location associates with devices installed or mounted within it and with application functions that affect physical phenomena.

Functionality Entities

The diagram depicts the relationship between Application Programs, Functionalities, and their respective subclasses in the context of software implementation for devices. An Application Program represents software that implements specific functionalities of a device. The Application Program connects to the Functionality concept, which represents a concrete piece of software with a set of interfaces (Points).

Several subclasses differentiate the specific use of Points based on the context of either a Channel or a Functional Block.

A Functional Block represents standardized or manufacturer-specific device functionality. Each Functional Block comprises a set of Points with specified behavior and interworking capabilities. Standardized Functional Blocks may include additional manufacturer-specific Points. Channels are manufacturer-specific groupings of Points, for example for Smart Linking, from one or more Functional Blocks. The page Functional Blocks provide a list of Functional Blocks contained in the KNX Information Model.

Functional Block Specifications

Download the KNX Volume 7 Application Descriptions from https://www.knx.org/ that contains Functional Block descriptions for different domains (HVAC, Lighting, Metering, Shading, etc.).

Aspect Entities

The diagram represents the concepts of Aspect, Application Function, Functionality, and Function Point in the context of a control system and location.

An Aspect serves as a generic grouping concept for Points on one or more devices. It reflects a specific viewpoint or functionality of the Installation by grouping related Points together. In contrast, Functionality groups Points of a single device.

An Application Function represents a partial functionality of a control system. It processes input information from sensors, actuators, or upstream application functions to produce output information. The Application Function uses intermediate variables to reflect specific process variables or states in its control loop (see also Application Function Model).

The Application Function directly or indirectly actuates upon QualityKind (quantities of interest) associated with physical phenomena or equipment. It operates within specific trades, reflected through a defined OperationKind relationship predicate (see also section Point and tags).

Application Functions interact with each other through defined relationships. A key example is energy control, where Application Functions representing energy producers (for example, solar panels, grid connection) interact with Application Functions representing energy consumers (for example, heating systems, lighting). Energy control focuses on energy level assessment and energy flow management within the Installation.

A Function Point also groups Points across devices. It enables data exchange through communication links (for example, S-Mode communication). The Points within a Function Point serve as the input and output data interfaces of Devices within the Installation.

Point and Tag Entities

A Datapoint represents the internal state of a device, allowing direct access (read) and optional manipulation (write). It can contain datapoint type information or additional Tag information from the Semantic Dictionary, including Quality Kinds and Operation Kinds. This specification enables a precise definition of a Datapoint.

The diagram illustrates the structure of a Datapoint, Application Function, and the tag model, which serves as a framework for defining the semantics of a Datapoint and Application Function. The diagram omits specific tags, but they fall into subclasses, each carrying its unique meaning. Tags combine to form tag sets, representing joint concepts with distinct semantic interpretations.

All tags, including predefined tag sets, serve as components of the Semantic Dictionary (see also Tag & TagSet Model).

Room Temperature Control Example

This example illustrates entities and relationships between entities to demonstrate the basic concepts of the Information Model. The example represents only a subset of the potential information that a model can encompass.

The diagram depicts a building with a room on the first floor, designated as an office. Within the room, two devices exist: a room temperature sensor and a valve actuator (such as a radiator valve actuator).

Both devices have an Application Program, each comprising a Channel. The SSH91102TH valve actuator possesses a channel with a runtime input Datapoint (if:i), while the QAA2890WI has a sensor channel with a room temperature Datapoint output (if:o).

The FunctionPoint "GO 1/1/1" represents the communication link between a communication output (sender) and its corresponding input (receiver). This link facilitates the exchange of information between connected Channels. A FunctionPoint compares, for example, to a BACnet reference between two BACnet devices that exchange data. This means that a BACnet reference would also model as an entity derived from an Aspect.

In this context, the RoomTemperature Datapoint assigns to the Application Function AirTemperatureCtrl_142. The sensor observes a Quality Kind (air temperature). This assignment indicates that the sensor value controls the air temperature within Room_142 (actsOnPhenomenonQualityKind).