By Dr. Thomas Weinzierl, Weinzierl Engineering GmbH.
While KNX has grown into the most important building automation standard, Ethernet has evolved into a universal communications solution that can also be employed in automation systems. Because of their different system characteristics, KNX and Ethernet complement each other well.
The advantage of the KNX bus is that it is optimised for the special requirements of building control. It uses a single twisted-pair (TP) cable to network all of the devices to be controlled, as well as supplying them with power. Its relatively low bandwidth of 9600b/s is sufficient for communication within a bus line, and had the advantage of allowing long cable lengths and a free topology. It also reduces the energy consumption of devices since the power consumption of a microcontroller depends heavily on the clock rate.
KNX TP is easy and inexpensive to install, because the bus can be looped from one device to the next without a hub or switch through. Above all, KNX devices are functionally and mechanically designed specifically for building installations.
Ethernet on the other hand, supports high bandwidth communication between relatively low-cost components. Its use is widespread, not only for networking computers in offices, but also for multimedia applications in the home and for industrial automation. While LAN networks support the high transmission speeds required for certain applications, they cannot replace the KNX bus due to its low-bandwidth nature, so the combination of KNX TP and LAN would be an optimal solution for future building automation.
KNX TP is primarily suited for local control, while the LAN is used for inter-system communication. The transmission of control commands can take place in a LAN network together with Internet use, PC networking and multimedia. Overall, this results in a hierarchical architecture for building networking.
Tunnelling: PC access via a LAN connection
An important application of IP within the KNX system is the functionality of an interface to the bus. KNXnet/IP tunnelling describes the access, for example, from a PC to a KNX network during configuration and commissioning. The focus is always the connection of a client (PC) with a bus line. The tunnelling protocol only uses UDP, but includes a connection-oriented layer, so that telegrams will be repeated in case of an error.
The tunnelling protocol can be selected in the Connection Manager of the ETS program and is also suitable for remote access over the Internet. It can also be used to connect a visualisation device to a bus line. The tunnelling protocol supports the bus monitor function.
Routing in hierarchical architectures
A major motivation for the extension of the KNX system using Ethernet/IP was to increase the transmission capacity of the overall system. While the transmission speed of KNX TP is perfectly adequate to build a bus line with up to 256 participants, a much higher bandwidth may be required in the backbone. This is especially the case when central devices such as visualisation tools are connected, to which all telegrams must be transferred. In this case, there can be no selective routing.
Here, the high bandwidth of a LAN network offers an optimal solution. While with KNX TP a maximum of only 50 telegrams can be transmitted per second, transmission via LAN exceeds 10,000 telegrams at 10Mb/s. To process this traffic without loss, high computational power in addition to an adequate telegram buffer from IP to KNX TP is required.
Since Ethernet forms the backbone of the system, a corresponding protocol was standardised in KNX. The routing subtopic of the KNXnet/IP specification describes how KNX/IP routers forward telegrams via IP. For forwarding via Ethernet, the KNX telegrams are individually packed in UDP/IP telegrams and sent as multicast telegrams. All KNX/IP routers in the network receive these telegrams simultaneously and use their routing tables to determine whether to forward the telegram to the connected KNX line.
The routing protocol can be used to connect an unlimited number of visualisation devices to a KNX installation with an IP backbone, but does not support the bus monitor function.
Object server: from the telegram to the data point
For an increasing number of devices, such as in the areas of multimedia and security technology, it is important to be able to exchange control information with the building automation system. However, for certain devices, it would preferable to access the bus indirectly by establishing a connection to the KNX system via Ethernet. Communication via Ethernet is particularly interesting for devices that are already equipped with a network port. If the protocol stack for TCP/UDP/IP already exists in the operating system, applications can communicate with other devices via Ethernet with little additional effort and thus also with KNX. This applies to many devices based on Linux or Windows CE.
If you were to use tunnelling or routing as a solution, the devices would be able to access the KNX network but would still have to generate and interpret KNX telegrams. It is far simpler for the KNX/IP interface to take over this task. In addition to the standard interface functionality, which enables access to the KNX bus on the telegram level, the KNX IP BAOS (Bus Access and Object Server) provides direct access to the data points (communication objects) of the building. In other words, the KNX stack in the device assigns the received data packets to their associated communication objects and holds their values in memory. Registered clients are automatically informed of any changes to the data points.
The communication object values are automatically updated upon receipt, even when clients are not connected. This allows, for example, a smartphone to instantly access the state of the KNX bus from the BAOS device, without loading the network with a burst of read requests. In order to send data to the bus, a client has write access to the communication objects. The device can independently generate and send group messages.
The configuration of the data points within the BAOS device is performed with the ETS, in which the device appears as a conventional bus participant. Within the parameters dialogue, the data types of the communication objects can be set and the group addresses are assigned as usual.
Using the BAOS protocol, a client can access and control data points of other bus participants without having to know the encoding of KNX telegrams. The client addresses the data points on the same number that they have in the ETS. If the group addresses in the KNX network are modified, the interface can be updated automatically by an ETS download, and the client application can remain unchanged. The Weinzierl KNX IP BAOS 771/772 for example, offers two separate client access protocols:
• Binary Protocol
The device supports an extension of the KNX BAOS binary protocol that is implemented by the BAOS 770 (Protocol Version 1). The KNX IP BAOS 771/772 device implements Protocol Version 2.0, an improved version. It is available over TCP/IP and UDP/IP. The binary protocol is particularly suitable for devices that support traditional programming languages such as C, C++ or C# and IP sockets.
• Web Services
The KNX BAOS binary protocol typically precludes the development of client applications that run in a web browser. For this reason, access to the object server is now possible via the new KNX BAOS Web Services, based on HTTP and Java Script Object Notation (JSON). This means it is now possible to embed KNX IP BAOS 771/772 directly in your own web applications.
The Web Services offer the same feature set as KNX BAOS binary protocol, however they use a familiar text-based syntax that is sent over HTTP (port 80). The Web Services do not implement a graphical interface. This must be done separately, typically in HTML and Java Script, and can be stored, for example, in client memory, or wrapped directly into a stand-alone application using Webkit.
Sample application for Web Services of the KNX IP BAOS 772 (KNX BAOS gadget)
The Weinzierl KNX BAOS gadget is a mini-visualisation for Windows desktop, which communicates with the BUS via KNX IP BAOS 772. The PC or laptop is connected to the BAOS interface via network or WLAN and receives all necessary information via Web Services.
Power over Ethernet replaces auxiliary voltage
KNX IP devices cannot derive all of their power requirements from the KNX bus alone. Therefore, they must be fed via a separate power supply or via Ethernet cable using PoE (Power over Ethernet) which simplifies the wiring within the switchboard. Obviously, for PoE, a network switch is required which supports this feature.
WLAN – the wireless alternative
With the introduction of KNXnet/IP the ETS as well as other software programs gain the possibility to connect to the bus via IP. One essential benefit of the Internet protocol is its independence of the transmission medium. Besides the network cable, a wireless transmission-based WLAN (wireless LAN) is possible as well.
A WLAN adapter is already integrated in nearly all new laptops, so together with a wireless IP interface such as the Weinzierl KNX IP Interface 740 wireless, an installer can move around the building almost freely.
Conclusion
For multimedia applications in the home, and for industrial automation, it makes sense to take advantage of the high-bandwidth capabilities of an Ethernet-based LAN or WLAN for inter-system communication, combined with the local control benefits of KNX TP. Whether you need KNXnet/IP tunnelling, routing, BAOS IP object server Web Services, wired or wireless and PoE, there is a powerful range of KNX IP devices available to help you for different applications.
Dr. Thomas Weinzierl is the CEO of Weinzierl Engineering GmbH. Weinzierl Engineering is focussed on building automation based on open standards. For more than twelve years, Weinzierl has developed and produced innovative system technology for KNX, including stacks, modules, software and system devices.
