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

KNX 42-9
GroupValue_Write PDUs should be sent; if GroupValue_Write PDUs should lead to the value
of the GO being updated; if GroupValue_Read PDUs should be answered; and, except for legacy
stack implementations, if GroupValue_Response PDUs should be treated as GroupValue_Write
PDUs with the same destination address. Device applications come with sensible defaults and usually
provide separate GOs for command input and status output, but the final responsibility for setting up
the proper communication relationships remains with the installer.
Enabling read-back of a GO that is actually a data sink would, in theory, also allow checking if messages
requiring exactly-once delivery semantics were delivered successfully by the at-most-once transport
service. However, one will rather bind to a status feedback GO instead in such a case as this allows
checking successful execution instead of delivery only. Usually, there are reasons besides a failed transmission
that may cause a destination to ignore a message (e.g., wind alarm may block sunblind operation
even if the command to move was received properly). If such exceptions are to be caught properly,
end-to-end status feedback is mandatory anyway.
AL PDUs can be sent with different priorities (as provided by the DL). The common configuration
tool (ETS) allows choosing the priority level on a per GO basis among the lower three; the KNX specification
suggests only using the lower two.
While the AL GroupValue services deal with transferring new values from one GO to another, user
applications still need to agree on how to interpret these values. In the KNX runtime interworking model,
applications are split in FBs to be implemented on individual KNX networked devices. Application models
describing the interplay of FBs are typically specified for a single application domain or a domain substructure
(e.g., hot water heating) but can (and do) include points of contact with other applications from
the same or other domains. Note that the term “profile” refers to something different in KNX.
FBs correlate device behavior with activity regarding their network communication endpoints. In
KNX, communication endpoints of FBs are termed datapoints, irrespective of whether they are message
sources or sinks for the exchange of process control data between devices during normal operation (input
and output datapoints) or parameters that are only changed in the configuration phase. Traditionally,
parameter datapoints are accessed following a manufacturer proprietary memory mapped model, but
recent FB definitions include provisions for using a more open object-oriented model (interface objects
and properties). Input and output datapoints may also be reflected as interface object properties (and
accessed via unicast TL services) or implemented using the TP1 master/slave polling mechanism. In
practice, however, the only communication mechanism that is relevant for input/output datapoints is
the group-object model as described in detail above.
Standard data point types (DPTs) define the data type (e.g., integer) and bit-level encoding (e.g., two’s
complement) of both input/output and parameter datapoints. The unit of measurement to be associated
with a datapoint value and range restrictions are also reflected in the DPT. A wide variety of DPTs exists,
covering, among others, Boolean values, signed and unsigned integers of multiple widths, time, date,
and floating-point values. DPTs may also consist of multiple fields (“structured” DPTs). Thus, depending
on the context and AL service used to transport it, a single DPT can represent the present value of a
datapoint together with associated status information or a command with multiple parameters.
Traditionally, the meta information contained in FB definitions or DPTs is no longer visible at the
level of network messages exchanged during normal operation. Just as for group addresses, a project
specific (external) database containing the semantic information is required for interpreting monitored
communication. Such a database also must contain device configuration information, since control
information in KNX is usually reduced to trigger information. Instead of “change brightness level to
100%, taking 10.s for the transition from the current level,” a typical message will say “level 100%” or
maybe even only “on,” with the precise interpretation governed by the device configuration.
In EIB (which can be regarded as the main predecessor system to KNX), hardly any behavioral
aspects were standardized at all, with control of actuators for light dimmers and motorized blinds being
notable exceptions. Devices interacted chiefly by exchanging Boolean values. This concept actually was
very close to powering traditional electric circuits on and off, with the actual outcome depending on the
© 2011 by Taylor and Francis Group, LLC