By Julio Díaz García, Sapienx Automation.
The Problem
KNX systems were designed to integrate any kind of installation, from small to a very large ones. The traditional KNX TP (Twisted Pair) topology was supposed to support up to 15 areas with 15 complete lines each, but in practice, when such big installations have to be monitored from one or more central points, KNX TP main and backbone lines cannot cope with tens or even hundreds of accumulated line traffic.
KNX IP routers were created about 12 years ago to deal with this situation, but they are not enough when we have several lines in a KNX system. If we want to monitor a big KNX system using visualisation/control software, we could use the KNXnet/IP routing connection (Falcon) to do so. Whilst the KNXnet/IP (tunnelling) connection is robust (like a USB connection), it only allows us to see one line´s traffic, so this connection is not enough for visualising the entire system. Using KNXnet/IP routing means that every telegram has to be redirected to the backbone using dummies or, better still, editing filter tables manually.
By using an IP backbone, we have solved the bandwidth issue that we had with TP systems, but this is not the only problem we have in large installations. For example, imagine that we have a system with 100 KNX (IP) lines. For the IP-Routers, acting as line couplers, the traffic is only x1 on the local side, but it will be x100 on the main side. This will result in a bottleneck on each coupler at the main line, and many of the telegrams could be lost.
The Solution
It is clear that the best IP connection is KNXnet/IP (tunnelling), but we only have one possible connection using the Falcon driver. On other hand, using KNXnet/IP routing, we have to launch all of the traffic to the backbone, so we may suffer with the line couplers.
The solution is not complicated to understand: extra help, in the form of software, is needed to avoid this traffic in the backbone by establishing simultaneous IP tunnelling connections, one for each line. So, we will have all of the project data in an item tree (group address (GA), but also physical address (PA)), mapped for each line. The NETxAutomation OPC Server and BMS Server can do this easily – indeed NETxAutomation is the OPC server recommended since 2006 by KNX International for large KNX installations. In the following example, we will use NETxAutomation´s BMS Server, because we will use this tool for other, future examples too.
Establishing Simultaneous IP Tunnelling Connections
First, we need to get all of the project data from ETS5. Normally, this would take a lot of time and effort because we need to know which GA or PA is related to which line (IP tunnelling address). However, we will use a free ETS app, the NETx BMS App, which allow us to do this in seconds.
After installing the app, simply select the NETx BMS App from ETS5 Extras Menu (also available in ETS4).
Then select the options you wish to export. Do not worry if the IP tunnelling addresses are not parameterised, the app will ask for that.
After exporting, we can now do the import process in the NETxAutomation BMS Server Studio (you can download a free 30-day trial from www.netxautomation.com). Just select the KNX menu and the first option, as shown below.
The import process will take also only a few seconds.
After restarting the BMS Server, we can see all of the KNX project data (GAs and also PAs if needed) mapped for each line (represented by their respective IP tunnelling addresses).
The result is that we can now use this Item tree for visualization/control in any OPC client for example, and we do not need all of the traffic in the backbone. This really is the proper way to manage a large KNX Project.
Another example of using this method for a large KNX project could be the integration of multiple stores, such as, say, 200 small supermarkets. If we were to have a VPN between all of them, we could manage all of these stores with just one OPC server or BMS server. This could be a much cheaper solution, because all we would need are IP interfaces to do this – no IP routing multicast would be needed at all.
Conclusion
When we have to manage a large KNX installation, the data traffic can be a nightmare if we need to monitor the entire system, even if we use IP routers. To avoid the bottleneck issue in IP routers, extra software is required. The NETxAutomation BMS Server includes a KNX OPC server and many other functions, and was the tool used in this example. Furthermore, with the free NETx BMS App, we can export all of the mapped data of any KNX project to the NETxAutomation´s OPC server and the BMS server, easily and quickly.
Julio Díaz García is the Owner of Sapienx Automation. He is an Engineer and KNX International Award-winning KNX++ Tutor. Sapienx Automation provides engineering, training and consultancy services for smart buildings, smart metering and smart cities.
