wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

42-10 Industrial Communication Systems
devices connected. Consequently, there was only very basic type compatibility checking even at setup
time, limited to value encodings. There were no provisions to prohibit binding the output of a motion
detector to the slat angle adjustment input of a sunblind actuator. Still today with KNX, integrators can
bind GOs individually and with minimal restrictions (free binding)—taking the responsibility for the
devices to work together as intended.
Only recently, the key function blocks for the electrical trade (lighting and shutters/blinds sensors and
actuators) have been thoroughly revised. Parameters were standardized; still, process data exchange remains
not only backward compatible but essentially unchanged. Besides lighting and blinds, typical EIB applications
included simple room temperature control and basic energy management. As the focus of KNX has
expanded beyond the electrical trade, the amount of interworking specifications has increased considerably.
Today, function blocks for the HVAC domain outnumber all others. Their definitions are so far the
only ones to include maximum and typical message generation rates, allowing the network load generated
by devices implementing them to be estimated a priori and serve as a guideline for network planning.
Mappings for the CHAIN (CECED Home Appliances Interoperating Network) white goods profiles
specified in EN 50523 have also been developed but are not contained in the KNX Handbook. Most
recently, metering has been added. The specification includes parts of the M-Bus RF protocol stack as
well as function blocks for representing the metering data obtained this way within the KNX system,
effectively defining a gateway. A similar approach was taken for integrating OpenTherm, a protocol
standard for connecting home heating appliances and room thermostats: Essential control information
was mapped to KNX FBs, while a tunneling mechanism allows OpenTherm communication as usual.
What was described so far is the traditional mode of runtime interworking, also known as “S-Mode.”
Another mode has been designed and is used for HVAC applications (although it is not necessarily
limited to them). It is known as “LTE” (logical tag extended). While S-Mode and LTE devices can coexist
on the same KNX network, their message formats are different. Therefore, LTE devices additionally
implement S-Mode communication for a subset of their functions. Instead of free addressing and binding,
LTE uses a “tagged” assignment scheme. In it, zoning information is statically mapped into the
group-address space, defining a fixed correlation between certain addresses and locations (as well as
domain substructures). A hierarchical structure allows addressing supersets of destinations at once. The
group-address range was quadrupled by making use of the Extended Frame Format field. This means
that the TP1/PL110 standard frame format cannot be used (see Figure 42.2).
Although LTE input/output datapoints are connected via multicast communication, they make use of
the interface object/property concept (which is otherwise only used for parameter datapoints) for sending
semantic information along. In every message, the object number identifying the function block
and the property number identifying the datapoint within the block are included. As an example of
LTE runtime interworking, consider a room temperature sensor sending the current measured value to
a fancoil controller.
Since the sensor includes the object number of the Room temperature sensor (RTS) FB and the property
number of the TempRoom datapoint with its transmission, the controller knows what to do with the
value without further configuration. To establish the binding between a particular sensor and contoller,
the installer sets the same location tag on both devices. This tag uniquely defines the group address that
the sensor will use as the destination address and that the controller will listen for.
LTE also distinguishes between reporting the state of a value and ordering it changed. To accommodate
these changes and additions, the AL services GroupPropValue_Read/-Response,
GroupPropValue_Write, and GroupPropValue_InfoReport were introduced. All of them
use the Data_Tag_Group TL service, which was defined for this purpose.
Finally, the recent addition of a file system access and bulk data transfer protocol (e.g., for trend logs)
that is closely modeled on FTP deserves mention.
© 2011 by Taylor and Francis Group, LLC