KNX1: Importing large KNX projects

Owned by verena.katzlinger (Unlicensed)
Last updated: Apr 30, 2018 by Wolfgang Granzer
4 min read

The summary

When we have to manage a big KNX installation, the data traffic can be a nightmare if we need to monitor the entire system, even if we use IP-Routers. An extra software is needed to avoid this bottle neck issue in IP-Routers. NETxAutomation´s is the OPC Server recommended since 2006 by KNX International for KNX big installations. The NETxAutomation´s BMS Server includes KNX OPC Server and many other functionalities, and has been the tool shown in this example.

With the (free) NETx BMS App Secure we can export easy and very fast all the mapped data of any KNX Project to the NETxAutomation´s OPC Server and the BMS Server.

The problem

KNX systems were designed to integrate any kind of installation, from small to a very big one. The well-known KNX TP topology is ready for up to 15 areas with 15 complete lines each, but in practice, when such big installations need to be monitored from one or more central points, KNX TP main and backbone lines are not ready at all to admit tens or even hundreds of accumulated line traffic.

KNX IP-Routers were created about 12 years ago to solve this situation, but they are not enough when we have several lines in a KNX system. When we want to monitor a big KNX system using a visualization/control software, we may use KNXnet/IP Routing connection (Falcon) to do so. KNXnet/IP (tunneling) connection is so robust (like USB connection), but only allow to see one line´s traffic, so this connection is not enough for visualize the entire system. Using KNXnet/IP Routing means that every telegram has to be redirected to the backbone (using dummies or, much better, editing filter tables manually).

With IP backbone we have solved the bandwidth issue that we have in TP systems, but this is not the only problem we have in this big installations. E.g. imagine that we have a system with 100 KNX(IP) lines. For the IP-Routers, acting as line couplers, the traffic is only 1x on local side, but it will be 100x on main side. This will mean that we have a bottle neck on each coupler at the backbone and many of the telegrams may be lost.

The solution

It´s clear that the best IP connection is KNXnet/IP (Tunneling), but we only have one possible connection using Falcon driver. On other hand, using KNXnet/IP-Routing we have to launch all the traffic to the backbone, so we may suffer with the line couplers.

The solution is not complicated to understand: an extra help is needed to avoid this traffic in the backbone. This means an extra software to establish simultaneous IP-tunneling connections, one for each line. So, we will have all the project data in an item tree (group address, but also physical address), mapped for each line. NETxAutomation´s OPC Server and BMS Server can do this easily. In this example we will use NETxAutomation´s BMS Server, because we will use this tool for other future examples.

First, we need to get all project data from ETS5. In principle, it should take a lot of work and time because we need to know which GA or PA is related to which line (IP tunneling address), but we will use a (free) ETS5 App to do so in seconds: The NETx BMS App Secure.


After installing it, just select the NETx BMS App from ETS5 Extras Menu (also available for ETS4). Then select the options wished to export. Do not worry, if the IP tunneling addresses are not parameterized, the app will ask for that.

Detail information:

  1. If a group address is reachable through different KNX lines, the NETx BMS ETS App chooses the line with the lowest line address.
  2. If a line is not uniquely accessible through a KNXnet/IP device (i.e. there is none or more than one), the NETx BMS ETS App prompts for the user to choose a device manually.


After exporting, we can now do the import process in the NETxAutomation´s BMS Server Studio. You can download a free 30 days trial from www.netxautomation.com. Just select the KNX menu and the first option, as we can see in the next Image.

  

The Import process will take also only a few seconds.

    

 

 

After restarting the BMS Server we can see all the KNX project data (group addresses and also physical addresses if needed) mapped for each line (represented by their respective IP Tunneling Adresses).

  

The result is that we can now use this Item tree e.g. for Visualization/Control in any OPC Client, and we do not need all the traffic in the backbone. This is the real way to manage a big KNX Project.

Other example for a big KNX project can also be the integration of several stores (e.g. 200 small supermarkets). If we have a VPN between all of them we can manage all this stores with just one OPC Server or BMS Server. This can be even a much cheaper solution, because we just need IP-Interfaces to do this (no IP-Routing multicast is needed at all).