Summary
Supervision of individual addresses in a KNX system allows us to optimize the security level of that. To perform this monitoring it is necessary to use an external tool (software) to undertake a continuous sampling or polling devices. This will also allow, in combination with a visualization of the KNX devices location and the laying of the bus, to identify and analyze the possible causes of the detected deficiencies.
The problem
Security is a critical factor in any installation and, in our opinion, it should be considered the primary design factor in a KNX installation. Furthermore, the decentralized nature of a KNX bus system requires, on multiple occasions, to make a cyclical monitoring of signals that may affect their safety. For example: wind alarms are monitored to control awnings and blinds because, in the absence of these signals, serious consequences may occur on site. On other hand, temperature signal from an external sensor may be cyclically monitored by a room thermostat to avoid unnecessary energy consumption if the sensor fails.
However, the cyclical monitoring of certain signals do not solve all possible problems in a KNX installation. KNX devices themselves may be affected by multiple types of incidents: theft, damage (rare, but possible), bus cable cutting, power failures, etc.
Therefore, monitoring of the devices themselves is needed in KNX installations, where an optimum level of security is desired. This monitoring, which is done through the individual address, also enable us to make an own traceability of the bus, and can be helpful to precisely locate not only any particular effect, but also more significant failures, such as power failure in a whole line or a possible bus cutting that affects multiple devices.
The solution
To perform monitoring of individual addresses from a KNX installation en external help is needed. We will use the NETx BMS Server for monitoring devices in a KNX installation.
We will also use a visualization tool, the Voyager 5.0 OPC from NETxAutomation, to represent the bus traceability. That is, we represent the bus cable laying of one line, allowing us to interpret whether any errors are individual types (burglary, connection failure, breakdown, etc.) or group (cut on the bus, power failure of the line, etc.).
After installing the BMS Server, the steps for configuring the physical addresses monitoring are very simple. First, we need to extract data from ETS project using the NETx BMS App.
NOTE: Both the BMS Server and Voyager NETxAutomation 5.0 are available for download (30 days demo version) from www.netxautomation.com. The NETx BMS APP for ETS4 and ETS5 is free and can be downloaded from https://my.knx.org/es/shop/ets-apps/project-export-tools
Once the Project has been imported in the BMS Server, we can appreciate the "KNX Device Definitions" table with the "mapping" of the individual addresses (allocated to each line – IP address). In the next picture, you can see this table, where we assigned a 10 second polling for Line 1.1. devices.
Also, the item tree in the image below, shows us that all devices on the line 1.1 respond positively to the polling.
Although the information displayed by the item tree is very valuable to assess the health of each individual device, it´s not enough to give a complete traceability of the installation. To supplement this information it is recommended to visually capture the physical layout of the devices as well as the laying of the bus. Hereby we can see an example of this visualization.
Finally, we will see two examples of possible failures in physical devices, to evaluate the usefulness of the proposed solution.
Example 1: Error in a single device
In this case we have disconnected the device 1.1.1 from the bus. As shown in the following pictures, first the item tree and then the visualization shows the device with undefined state (???).
After a (courtesy) timeout, finally the item tree in the BMS Server shows the device in FALSE state. Right now, for example, we could set an automatic email from the BMS Server warning about this device failure.
Example 2: Simultaneous Error in a group of devices
In this latter case we have simulated a cut in the wire bus, forcing the shutdown of bus devices 1.1.11 to 1.1.15. As shown in the pictures below, both the items tree and the visualization shows all these devices in an undefined state (???).
Finally, after the timeout, the five devices go to FALSE status.
In the visualization we can see the location of all this five devices in FALSE state so we can infer, as one of the most likely causes of the failure, a bus break between the 1.1.7 device and the KNX Auxiliary Board.
