Data Communications for Distributed Building Automation - Networked Embedded Systems - page 770

limited to the TP medium. If required, end-to-end confirmations must be implemented at the appli-
cation layer. Group addresses are routed through the whole network. Routers are preprogrammed
with the necessary tables. Broadcasts always span the entire network.
KNX uses a shared-variable model to express the functionality of individual nodes and com-
bine them into a working system. Although this model uses state-based semantics, communication
remains event-driven. Network-visible variables of a node application are referred to as group objects .
They can be readable, writable, or both (although the latter is discouraged to better keep track of
communication dependencies). Each group of communication objects is assigned a unique group
address. his address is used to handle all network traffic pertaining to the shared value in a peer-to-
peer manner. Group membership is defined individually for each group object of a node, which can
belong to multiple groups.
Usually, data sources will actively publish new values, although a query mechanism is provided as
well. Since group addressing is used for these notifications, the publisher-subscriber model applies:
the group address is all a node needs to know about its communication partners. Its multicast nature
also means, however, that no authentication or authorization can take place this way.
Process data exchange between KNX nodes exclusively uses group addressing. Individual
addressing is reserved for client-server style management and engineering communication. System
management data like network-binding information or the loaded application program are acces-
sible through the properties of system interface objects . In addition, every device can provide any
number of application interface objects related to the behavior of the user application. On the one
hand, their properties can hold application parameters that are normally modified during setup time
only. On the other hand, they can contain run-time values normally accessed through group objects.
Basic engineering functions like the assignment of individual addresses are handled by dedicated
services.
The specification also encompasses standard system components, the most important being
the Bus Coupling Units (BCUs). BCUs provide an implementation of the complete network
stack and application environment. They can host simple user applications, supporting the use
of group objects in a way similar to local variables. Application modules can connect via a
standardized -pin external interface, which can be configured in a number of ways. Simple
application modules such as wall switches may use it for parallel digital I/O or ADC input.
More complex user applications will have to use a separate microprocessor since the process-
ing power of the MCHC family microcontroller employed in BCUs is limited. In this case,
the application processor can use the PEI for high-level access to the network stack via a serial
protocol. As an alternative, TP-based device designs can opt for the so-called twisted pair-
universal asynchronous receiver/transmitter (TP-UART) IC. This IC handles most of the KNX
TP data link layer. Unlike the transceiver ICs used in BCUs, it relieves the attached host con-
troller from having to deal with network bit timings. These design options are illustrated in
Figure ..
For commissioning, diagnosis and maintenance of KNX installations, a single PC-based software
tool called ETS (Engineering Tool Software) which can handle every certified KNX product is
maintained by KNX Association. KNX devices may support additional setup modes defined by
the standard which do not require the use of ETS. First devices implementing them are already
commercially available.
Unlike ETS, which allows linking individual communication objects, these modes perform
binding at the level of function blocks. Most of these function blocks have only recently found their
way into the specification. This may be explained by the fact that EIB has its roots in the field of
electrical installation technology, where applications seldom require more than simple switching
functions. he KNX function blocks represent application domain-specific functions, many of them
from the HVAC field.