KNX is the only bus system worldwide that offers the complete range of transmission media for building control systems: Twisted Pair, Powerline, Radio Frequnecy and Ethernet IP. Transmission media can easily be coupled with KNX media couplers. The KNX applications are commissioned with ETS, the manufacturer, product and trade independent tool.

 

From the Idea to the Finished Product, the list of questions for a KNX novice on how to implement KNX into a new device can be quite long:

• Which KNX media (e.g. Twisted Pair or Radio Frequency) should be used?
• Which software requirements does KNX demand?
• Which communication objects – data formats – should be used and how are they programmed?
• What are the hardware requirements for the device?
• Are there standard components?
• How will the device be commissioned, i.e., which configuration modes should be supported?
• Is there technical support that can assist during the development?
• How is the certification process?

 

It’s helpful to learn about the KNX standard components which are available on the market for the different media, to get a better idea of which solution may be suited
to develop your devices.

 

 

For more information about available KNX devices please contact:

 

 

Eelectron	Elmos Semiconductor AG	Opternus Components GmbH	Radiocrafts AS	Siemens AG	Tapko Technologies GmbH	Weinzierl Engineering GmbH
www.eelectron.com	www.elmos.de	www.opternus.com	www.radiocrafts.com	www.siemens.com/gamma-b2b	www.tapko.de	www.weinzierl.de

 

 

Implementation Aspects for KNX TP Devices

 

One will be confronted with a several technical terms like „BIM“, „BCU“, „SIM“, „TPUART“, „chipset“ and „communication stack“ when exploring the market. These terms represent the different possibilities on how to develop a KNX TP device.

 

BCU „Bus coupling units“

These are system devices which include the KNX coupling circuitry, a microprocessor and are delivered with housing. The device developer only needs to develop the application module, the application hardware and software.

 

BIM „Bus Interface Modules“ 

They are basically built up like the inside of a BCU with additional I/O ports. BIMs are sold as modules which can be soldered directly to the circuit board.

There are versions available with 8kbyte and 48 kbyte flash memory for the application software. The software development takes place with a development environment consisting of „Evaluationboard“, „On-Chip Debug Emulator“ and C-Compiler.

 

SIM „Serial Interface Modules“

They contain the complete communication system with applications. The application hardware and software is coupled with the communication part via serial interface. SIMs are sold as modules which are soldered directly to the circuit board.

 

BAOS „Bus Access and Object Server“

The BAOS Module is both a KNX interface on Telegram level (KNX Link Layer) as on DataPoint level (KNX Application Layer). The telegram format is FT1.2 conform. An optimized serial protocol is available for the communication on Data- Point level.

 

Chipset

Chipsets of BIMs are offered to circumvent the mechanical constraints of BIMs. There is no difference between BIMs and chipsets with regard to the software.

 

TPUART

The TPUART only contains the coupling to KNX. The communication software is supplied by a micro-controller. The TPUART was developed to relieve the micro controller of the bit coding and decoding duty on the one hand and to allow the coupling to KNX through different micro-controllers on the other hand.

 

Communication Stack

To develop a KNX device with the TPUART, a communication stack is required. This kinds of coupling is the most effective, flexible and low-cost way of developing a KNX device. To eliminate the need for the developer to familiarize themselves with details of the KNX communication, KNX system vendors offer the KNX communication stack. The coupling to KNX is performed through external KNX coupler like TPUART, FZE1066. The KNX communication stack offers additional interfaces to program the actual application.

 

What is the right solution?

The modules (BIM, SIM BAOS) are recommended in case of smaller production quantities. They offer low development - and certification costs and are ideal to start with KNX development. If the available space becomes insufficient or the production quantities increase, then the chipsets are an interesting alternative. The initial costs are just a little higher as compared to BIM. TPUART is the most popular solution in case of large production quantities. The advantage of TPUART is the low cost per unit, but has on the other hand the highest development- and certificationcosts. It can in particular cases also be useful to opt for a Bit Transceiver (FZE1066).

 

 

Implementation Aspects for KNX PL devices

 

Standardized BCUs and modules (PIM) are also available for KNX PL (110) similar to Twisted Pair.

 

BCU „Bus coupling units“

These are system devices which include the KNX coupling circuitry, a microprocessor and are delivered with housing. The device developer only needs to develop the application module, the application hardware and software.

 

PIM „Powerline Interface Modules“ 

They are basically built up of the low voltage part of the BCU. PIMs are modules that are soldered to the circuit board together with other network coupling parts.

 

ACIS with Communication Stack

An ASIC for PL110 is responsible for sending and receiving bits. To build a KNX device based on such an ASIC a KNX stack for Powerline (communication software) is necessary. A communication stack contains interfaces for the programming of the application.

 

What is the right solution?

In case of flush-wall mounted devices and lower production quantities, BCUs are best suited to develop cost effective devices. For medium production quantities, PIMs are recommended - a circuit diagram is available. The development of PL devices with ASIC and communication stack requires larger investments as compared to BCUs and PIMs and is therefore generally only suited for high production quantities.

 

 

Implementation Aspects for KNX RF devices

 

The development of KNX RF devices does not require special KNX components. To reduce development time and - costs however, it can be useful to integrate ready-made RF Modules - usually in case of low production quantities. A KNX RF node basically consists of the following elements:

 

Transceiver Chip

For KNX RF no dedicated chip is necessary.

Today there are a couple of chips available which can be used to implement a KNX RF node. For unidirectional devices, low cost transmit-only chips are available.

 

RF circuit

The transceiver builds togethere with a couple of passive components the RF circuit. Based on the reference design of the chip manufacturer, a circuit can be designed and optimized to the KNX RF requirements.

 

Microcontroller

The core of any KNX device is a microcontroller which handles the communication as well as the application task. For RF one of the most important requirements is low power consumption. The interface logic to connect the transceiver should be present in most of today’s controllers.

 

Communication stack

The KNX standard defines a complex protocol which leads to a high implementation and certification effort. The communication stack is the system software for a KNX RF device. It controls the transceiver and handles complete communication, including the configuration procedure. The communication stack provides an interface (API) for application development.

Implementation Aspects for KNX IP

 

The transmission of KNX telegrams via Ethernet is defined as KNXnet/IP and is a part of the KNX Standard. Until now the specifications included the use of this medium for PC interfaces and for routers. IP routers are similar to line couplers, except that they use Ethernet for the main line. Moreover it is nowadays also possible to integrate KNX end devices directly via IP in the KNX network. That’s why Ethernet resp. IP (Internet Protocol) is a fully valued KNX medium. The development of KNX IP devices does not require special KNX components. A KNX IP node basically consists of the following elements:

 

Ethernet controller

Ethernet controllers are available from different semiconductor manufacturers. The Ethernet controllers basically comply with the KNX IP requirements. Controllers with a bitrate of 10 MBits are generally sufficient.

 

Microcontroller

Choosing which microcontroller basically depends on the required calculating performance for the device. KNXnet/ IP can principally be implemented on a 8-bit controller. Depending on the application more powerful controllers can also be required. Many controllers already offer an interface for Ethernet on the chip, so that you only need to complete it with the physical layer.

 

Communication stack

The system software of a KNX IP device consists of two protocol- stacks. Communication via Ethernet requires an IP Stack with UDP (User Datagram Protocol) because of the fact that KNXnet/IP is based on connectionless communication. Unicast as well as multicast telegrams are transmitted via UDP. The KNX Stack is put on top of the IP/UDP Stack. This is the KNX Common Kernel, which has to be implemented especially for each device model. The KNX Stack uses the IP/UDP stack as the interface to the system. The translation from KNX telegrams to UDP telegrams is established via KNXnet/IP. The KNX application accesses the API (Application Programming Interface) of the KNX stack, in order to communicate with the whole system.

 

What is the right solution?

Choosing the proper hardware depends basically on the type of application. Hardware implementations made especially for KNX IP devices are already available on the market. Appropriate stacks are also offered. However, for complex devices, more powerful operating systems e.g. Linux, which basically contain an IP Stack with UDP can be used. In this case only the KNX stack as well as the corresponding application program is required.