By Mark Warburton, Ivory Egg.
I am often asked what the limitations of KNX are and whether it is an out-of-date system, especially as the protocol was initially laid down over 20 years ago. One of the most used figures in this debate is the relatively slow baud rate that KNX employs (9600bps) and the fact that newer systems can communicate at many thousands of times this rate. What is often overlooked is that by having this baud rate, the bus can have long cable lengths, a free topology and greatly reduced power consumption of the end devices that are attached to it. Even at that baud rate, the bus can still support over 50 telegrams per second.
However with advancements in the use of KNX, there is certainly a need for higher transmission rates, especially at the backbone level. With visualisation devices and central monitoring becoming more common, there is often a requirement for all telegrams to be available at the highest topological level.
If using KNX TP1 bus cable, this can present a bottleneck, which IP can resolve. To support this, the KNX Association developed the KNX/IP telegram, which is now part of the KNX specification. This allows for the use of Ethernet as a low cost, high-bandwidth medium that is common in most buildings, be they residential or commercial. It is important to understand however, that whilst LAN networks provide many benefits, the requirement to have a defined and controlled infrastructure means KNX TP1 is here to stay.
The KNX/IP Telegram
To allow the inclusion of IP as a communication medium, the KNX Association created a standardised KNX/IP telegram. This is also based on the OSI reference model with different definitions for the Transport, Network and Physical layers. Put simply, this defines how the enclosed TP1 telegram should be distributed.
The actual TP1 telegram is maintained, along with an additional field to define the KNXnet/IP action, which can be any of the following services:
KNXnet/IP Core.
KNXnet/IP Device Management.
KNXnet/IP Tunnelling.
KNXnet/IP Routing.
KNXnet/IP Remote Logging.
KNXnet/IP Remote Configuration and Diagnosis.
KNXnet/IP Object Server.
Most of the above are service functions that are fairly self-maintained, so the main terms we need to focus on are KNXnet/IP Tunnelling and KNXnet/IP Routing.
KNXnet/IP Tunnelling
KNXnet/IP Tunnelling is the primary method of interfacing to a KNX system and allows for a point-to-point communication (unicast) from a single external device to the KNX system. This is akin to using a USB or Serial Interface.
This is the simplest form of IP communication within KNX and is easy to understand as you only need to point an external device at the IP address of the KNX IP interface. This allows you to see all traffic from the bus and communicate directly to individual devices such as for ETS programming. It is also commonly used for external systems to communicate with KNX.
Note: in ETS this method is only referred to as KNX/net IP.
KNXnet/IP Routing
KNXnet/IP Routing is a multicast-based telegram, which allows a KNX IP router to perform the function of a line or area coupler. This means the backbone of a KNX system can be Ethernet-based, allowing a much higher speed of transmission and more flexibility when installing. The IP router will also manage the filter table to manage the flow of traffic where needed.
Multicast is a group-orientated connection method where, instead of using the IP all devices point to a standard multicast address. This allows all telegrams to be seen by all KNX IP devices looking at this address. The KNX Association has reserved multicast address 224.0.23.12 but any address could be used as long as it is the same on all devices.
The KNXnet/IP Routing method of communication allows all traffic on the bus to be monitored, so it is very useful for devices requiring access to entire systems such as visualisation, but does not allow you to perform ETS functions such as bus monitor or downloading to devices.
Hardware
Now that we have covered the basic communication methods, let’s take a look at which products are required. The two primary KNX IP devices are Interfaces and Routers.
A KNX IP Interface supports KNXnet/IP Tunnelling only, however a single interface, such as the Weinzierl 730, may support multiple connections. This device can have 5 simultaneous tunnelling connections which are managed by defining multiple KNX physical addresses on the device. This is useful when you have multiple instances of ETS accessing the same KNX system or if you want to use the interface for both an ETS connection and an external interface to an A/V system for example.
A KNX IP Router will support a KNXnet/IP Tunnelling and a KNXnet/IP Routing connection as well as having the filter table to allow the device to perform as a coupler. In fact some IP routers, such as the Gira 216700, allow multiple tunnelling connections as well. By its very nature, the routing connection has no limits to the number of connections due to the multicast connection. Some devices also have time servers and memory cards to record the bus as well.
Note: it is important to remember to treat this device as a line coupler. It will have to be addressed correctly within the topology, and the Medium types of all segments will have to be assigned correctly in ETS.
Both types of device generally require an additional voltage over and above the KNX bus power supply unit (PSU). Whilst this can be derived from the auxiliary voltage on many KNX PSUs, it is important to remember that most KNX PSUs offer a combined output of 640mA. Therefore it is wise to run any device requiring additional power off its own PSU. Another option on some IP devices is to power them via the Ethernet cable (PoE). This will require a network switch capable of PoE, but is a very simple and tidy method of installation.
Security and Remote Access
Once you have implemented an IP solution it is possible to configure either of the above connection types to allow remote access for commissioning and support.
Using a KNXnet/IP Tunnelling interface, it is possible to set up a direct external connection if the external WAN address is known. A port redirection will have to be implemented in the network router to navigate the firewall. However, since the KNX system does not require a password to access this, it is not the most secure of connection methods. When KNX is controlling the entire building environment, this is an important consideration.
It is better to use a VPN tunnel to establish a remote connection between an external network and the local network. This has a higher level of security and encrypts the traffic down the tunnel.
If the requirement were to connect two KNX systems via the KNXnet/IP routing connection, the VPN must support multicast traffic and be enabled by the network administrator.
Conclusion
Given the above considerations, it is no wonder we get a lot of questions on KNX over IP, especially as little time is dedicated to this in the Basic KNX certification course. Once the above terms are understood however, it becomes a lot easier to specify and install the correct products. By combining the speed and flexibility that IP brings with the reliability and simplicity of the KNX bus, you have a very powerful, flexible and future proof system.
Mark Warburton is the Sales Manager for Ivory Egg (UK) Ltd, a supplier of leading KNX products and provider of KNX training courses. Mark is also a regular contributor to KNXtoday magazine.
