Total 4731 registered members

5,069 views

KNX Architecture

KNX Architecture

Building Control technology as provided by KNX is a specialized form of automated process control, dedicated to the needs of home and building applications. One premise for KNX is to furnish a radically decentralized, distributed approach; hence the term network.
The KNX Device Network results from the formal merger of the 3 leading systems for Home and Building Automation (EIB, EHS, BatiBus) into the specification of the new KNX Association. The common specification of the “KNX” system provides, besides powerful runtime characteristics, an enhanced “toolkit” of services and mechanisms for network management.

On the KNX Device Network, all the devices come to life to form distributed applications in the true sense of the word. Even on the level of the applications themselves, tight interaction is possible, wherever there is a need or benefit. All march to the beat of powerful Interworking models with standardized Datapoint Types and “Functional Block” objects, modelling logical device channels.

The mainstay of S-(“System”) Mode is the centralized free binding and parameterisation (typically with the PC-based ETS tool). It is joined by E (“Easy”)-mode device profiles, which can be configured according to a structured binding principle, through simple manipulations – without the need for a PC tool. These configuration modes share common run-time Interworking, allowing the creation of a comprehensive and multi-domain home and building communication system.
The available Twisted Pair and Powerline communication media are completed with Radio Frequency (868 MHz band).
KNX explicitly encompasses a methodology and PC tools for Project Engineering, i.e. for linking a series of individual devices into a functioning installation, and integrating different KNX media and configuration modes. This is embodied in the vendor-independent Engineering Tool Software (ETS) suites for Windows.

Elements of the KNX Architecture

KNX specifies many mechanisms and ingredients to bring the network into operation, while enabling manufacturers to choose the most adapted configuration for their market. Figure 1 below shows an overview of the KNX model, bringing the emphasis on the various open choices. Rather than a formal protocol description, the following details the components or bricks that may be chosen to implement in the devices and other components a full operational system.

The KNX Model

As essential ingredients of KNX, we find in a rather top-down view.

  • Interworking and (Distributed) Application Models for the various tasks of Home and Building Automation; this is after all the main purpose of the system.
  • Schemes for Configuration and Management, to properly manage all resources on the network, and to permit the logical linking or binding of parts of a distributed application, which run in different nodes. KNX structures these in a comprehensive set of Configuration Modes.
  • Communication System, with a set of physical communication media, a message protocol and corresponding models for the communication stack in each node; this Communication System has to support all network communication requirements for the Configuration and Management of an installation, as well as to host Distributed Applications on it. This is typified by the KNX Common Kernel.
  • Concrete Device Models, summarized in Profiles for the effective realization and combination of the elements above when developing actual products or devices, which will be mounted and linked in an installation.

Applications, Interworking and Binding

Central to KNX’ application concepts is the idea of Datapoints: they represent the process and control variables in the system, as explained in the section Application Models. These Datapoints may be inputs, outputs, parameters, diagnostic data,…The standardized containers for these Datapoints are Group Objects and Interface Object Properties.

The Communication System and Protocol are expected to offer a reduced instruction set to read and write (set and get) Datapoint values: any further application semantics is mapped to the data format and the bindings, making KNX primarily “data driven”.
In order to achieve Interworking, the Datapoints have to implement Standardized Datapoint Types, themselves grouped into Functional Blocks. These Functional Blocks and Datapoint Types are related to applications fields, but some of them are of general use and named functions of common interest (such as date and time).

Datapoints may be accessed through unicast or multicast mechanisms, which decouple communication and application aspects and permits a smooth integration between implementation alternatives. The Interworking section below zooms in on these aspects. To logically link (the Datapoints of) applications across the network, KNX has three underlying binding schemes: one for free, one for structured and one for tagged binding. How these may be combined with various addressing mechanisms is described below.

Basic Configuration Schemes

Roughly speaking, there are two levels at which an installation has to be configured. First of all, there is the level of the network topology and the individual nodes or devices.
In a way, this first level is a precondition or “bootstrap” phase, prior to the configuration of the Distributed Applications, i.e. binding and parameter setting.
Configuration may be achieved through a combination of local manipulations on the devices (e.g. pushing a button, setting a codewheel, or using a locally connected configuration tool), and active Network Management communication over the bus (peer-to-peer as well as more centralized master- slave schemes are defined).
As described in the corresponding section below, a KNX Configuration Mode:

  • picks out a certain scheme for configuration and binding
  • maps it to a particular choice of address scheme
  • completes all this with a choice of management procedures and matching resource realizations.

Some modes require more active management over the bus, whereas some others are mainly oriented towards local configuration.

Network Management and Resources

To accommodate all active configuration needs of the system, and maintain unity in diversity, KNX is equipped with a powerful toolkit for network management. One can put these instruments to good use throughout the lifecycle of an installation: for initial set-up, for integration of multi-mode installations, for subsequent diagnostics and maintenance, as well as for later extension and reconfiguration. Network Management in KNX specifies a set of mechanisms to discover, set or retrieve configuration data actively via the network. It proposes Procedures (i.e. message sequences) to access values of the different network resources within the devices, as well as identifiers and formats for these resources – all of this in order to enable a proper Interworking of all KNX network devices. These resources may be addresses, communication parameters, application parameters, or complex sets of data like binding tables or even the entire executable application program.

The network management basically makes use of the services offered by the application layer. Each device implementing a given configuration mode (see below) has to implement the services and resources specified in the relevant “profile” (set of specifications, see below).
For managing the devices, these services are used within procedures. The different configuration modes make use of an identified set of procedures, which are described in the “configuration management” part. As indicated above, and further demonstrated in the Configuration Modes section below, KNX supports a broad spectrum of solutions here, ranging from centralized and semi- centralised “master-slave” versions, over entirely peer-to-peer to strictly local configuration styles.

However, mechanisms and Resources are not enough. Solid Network Management has to abide by a set of consistency rules, global ones as well as within and among profiles, and general Good Citizenship. For example, some of these rules govern the selection of the (numerical value of) the address when binding Datapoints.

But now, we first turn our attention to how the Communication System’s messaging solutions for applications as well as management, beginning with the physical transmission media.

Communication: Physical Layers

The KNX system offers the choice for the manufacturers, depending on his market requirements and habits, to choose between several physical layers, or to combine them. With the availability of routers, and combined with the powerful Interworking, multi-media, and also multi-vendor configurations can be built.

The different media are :

  • TP 1 (basic medium inherited from EIB) providing a solution for twisted pair cabling, using a SELV network and supply system. Main characteristics are: data and power transmission with one pair (devices with limited power consumption may be fed by the bus), and asynchronous character oriented data transfer and half duplex bi-directional communication. TP 1 transmission rate is 9600 bit/s.
    TP1 implements a CSMA/CA collision avoidance. All topologies may be used and mixed ( line, star, tree, ….)
  • PL 110 (also inherited from EIB) enables communication over the mains supply network. Main characteristics are: spread frequency shift keying signalling, asynchronous transmission of data packets and half duplex bi-directional communication. PL 110 uses the central frequency 110 kHZ and has a data rate of 1200 bit/s.
    PL110 implements CSMA and is compliant to EN 50065-1 (in the frequency band without standard access medium protocol).
  • RF enables communication via radio signals in the 868,3 MHz band for Short Range Devices. Main characteristics are: Frequency Shift Keying, maximum duty cycle of 1%, 32 768 cps, Manchester data encoding.
  • Beyond these Device Network media, KNX has unified service- and integration solutions for IP-enabled (1) media like Ethernet (IEEE 802.2), Bluetooth, WiFi/Wireless LAN (IEEE 802.11), “FireWire” (IEEE 1394) etc., as explained in the KNXnet/IP section below.

Communication: Common Kernel and Message Protocol

The Communication System must tend to the needs of the Application Models, Configuration and Network Management. On top of the Physical Layers and their particular Data Link Layer, a Common Kernel model is shared by all the devices of the KNX Network; in order to answer all requirements, it includes a 7 Layers OSI model compliant communication system.

  • Data Link Layer General, above Data Link Layer per medium, provides the medium access control and the logical link control.
  • Network Layer provides a segment wise acknowledged telegram; it also controls the hop count of a frame. Network Layer is of interest mainly for nodes with routing functionality.
  • Transport Layer (TL) enables 4 types communication relationship between communication points: one-to-many connectionless (multicast), one-to-all connectionless (broadcast), one-to-one connectionless, one-to-one connection-oriented. For freely bound models (see below), TL also separates (“indirects”) the network multicast address from the internal representation.
  • Session and presentation Layers are empty.
  • Application Layer offers a large “toolkit” variety of application services to the application process. These services are different depending on the type of communication used at transport layer. Services related to point-to-point communication and broadcast mainly serve to the network management, whereas services related to multicast are intended for runtime operation.

Remember KNX does not fix the choice of microprocessor. Since in addition, KNX covers an extensive range of configuration and device models, the precise requirements governing a particular implementation are established in detailed Profiles, in line with the Configuration Modes. Within these boundaries, the KNX developer is encouraged to find the optimal solution to accommodate his implementation requirements! This is expounded in later sections.

Related articles