By Mark Warburton, Ivory Egg.
Having just been at the KNX training conference in Helsinki, it was great to meet tutors and training centre organisers from around the world. There was a lot of talk about the future of KNX training and what we can do to help integrators on their journey.
This was coupled with a fantastic boat trip around the Helsinki archipelago on a beautiful, unseasonably warm evening.
During various conversations, system design came up. As with any control system, this has the biggest impact on the reliability of the system. But with KNX, it also affects how you deliver the project, which in turn has an impact on its profitability.
System architecture considerations
The system architecture of KNX is well known by anyone who has done the basic course where we teach that devices that are working together should be on the same line or in the same area. This prevents the higher-level main line or backbone line from getting overloaded with traffic.
The use of visualisation and interfaces to other systems adds another dimension. One of the most common mistakes we see is the lack of consideration for the ‘acknowledge’ reply telegram. If the sending object doesn’t get an ‘ACK’ telegram, it will repeat the message three times. This is often the case when using an IP Interface (tunnelling) and the external system isn’t implementing the KNX stack properly. Line couplers or IP routers will send the ACK telegram when they pass the telegram up a level, which is one of the reasons why interfaces should be on the main line or backbone line.
However, depending on the size of the project, this could lead to a large amount of traffic on the higher lines. Although this is less of an issue when using an IP backbone, the telegrams still need to processed by the IP router, which can introduce delays. This can cause issues, especially when downloading to devices or sending system-wide messages such as evacuation or alarm response.
To counter this, some visualisation and servers allow the connection of individual tunnelling connections instead of using the single multicast connection. This means you can have an IP interface per floor, with the visualisation system talking to each individual IP interface depending on which group address it need to communicate with. You can achieve the same with ABB’s IP router which supports a similar function and has an external plug-in to download custom routing tables – perfect for installations that can’t use the sometimes contentious multicast method.
Device and group address assignment
This approach requires careful planning of device addressing and group address assignment. If the project is small, then it would be possible to treat the whole system as one project and let ETS automatically assign group address to the filter table. Using the split and merge ETS App from the KNX Association, you can divide the project into different sections, allowing commissioning to be performed in different parts of the building simultaneously, then joining them together on completion of the project.
Another useful app is Extended Copy, also by the KNX Association, which allows devices, bus lines, complete building parts together with their destination address assignments, parameterisation, group addresses, links, text attachments and other information to be quickly and easily replicated throughout the project.
Splitting the ETS project – a practical example
On a large project, however, you may wish to consider splitting the ETS project permanently. A recent project for which this approach was used is the Urban Sciences Building in Newcastle. Delivered by IBT Group (formerly Entech), the system has DALI lighting, HVAC including active chilled beam control, weather stations including monitoring of direct and indirect radiation (see last month’s article Tips: Making the Most of Weather Stations) and full integration with a Siemens Desigo CC system which is used for visualisation and building management.
On this project, each floor was treated as a completely separate ETS project. This meant that different teams of engineers could build, program, commission and test the KNX system, and because the group addresses won’t be combined, a more logical, intuitive and flexible approach can be used to create more granularity for the rooms and various different services.
To link the different systems together, an IP backbone runs throughout the building in the traditional way, with all inter-floor commands in main groups 14 and 15. The IP routers were then configured to pass the main groups and block all other traffic.
Because the central Desigo system can communicate directly with each IP router via a tunnelling connection, visualisation of devices and functions on each line is possible without compromising the integrity of the multicast communication between lines.
All of this means project teams can work on multiple floors with multiple concurrent downloads to create workflow efficiency, which was critical, given the commissioning window was condensed as is usual on a large project. Because the group addresses are replicated on each floor, as are the device address, it is easy to navigate each project without having to deal with the entire system.
Managing the multiple projects does present its own complications, but using the Auto Backup ETS App by IT Gesellschaft für Informationstechnik GmbH, it is possible to backup projects to a cloud server such as Dropbox, making it easy for handover between engineers as needed.
Conclusion
Even on small projects, implementing some of the points above will help to make the project quicker to deliver and more reliable in the future. On a large project, it can have a much bigger impact, and could be the difference between finishing a project on time or overrunning.
Throughout the KNX industry, there are countless examples of taking the education offered by the KNX Association and pairing this with experience gained onsite. When this is done well, it can make even the most complex project manageable and, most importantly, deliverable.
Mark Warburton is the Technical Director of Ivory Egg (UK) Ltd, a supplier of leading KNX products and provider of KNX training courses.
