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

Communication Aspects of IEC 61499 Architecture 55-19
This investigation shows that CIP fits very well to the execution and object model of IEC 61499.
Our example made the assumption that all devices on the CIP network are IEC 61499-enabled
control devices. However, several advantages can be gained from combining legacy CIP devices
with IEC 61499-enabled devices. Two different application scenarios should be considered: first IEC
61499-enabled CIP slave device (i.e., programmable I/O devices) and second use standard CIP slave
devices from IEC 61499 devices. In the first case, the CIP interface of the IEC 61499 device would
be specified by utilizing the CIP FBs, and with this mechanism the interface can be adapted to the
specific IEC 61499 application running in the device. On the other end of the communication, a CIP
master device (e.g., a PLC) would interact with the IEC 61499 device in the same way as with any other
CIP slave device. However, the use of IEC 61499 allows to pre-process I/O data and to provide higher
level information to the PLC. This use case is an important step toward a fully distributed control
system as described by IEC 61499. In the second use case, the IEC 61499 control device will take the
place of the PLC, and the CIP communication FBs will mimic the behavior of a CIP master. However,
in contrast to the existing PLC interface where the network data are presented to the application as a
flat memory region, IEC 61499 allows a structured access to the data. This is achieved by representing
each slave device as a separate FB. This allows to leverage existing investments in plants and I/O device
development, or to extend dumb I/O modules by adding own CPUs. Therefore this will be an important
part of an IEC 61499-based control environment.
Both use cases are not specific to the CIP environment. They can be applied to any fieldbus system
used in industrial control systems.
55.11 Impact of Communication Semantics
on Application Behavior
One word of caution however. Traditional control applications running on a single controller periodically
or cyclically read from, and write to, all the remote devices connected to the network bus (even
when no changes to the state of these devices is required); so if the network suffers a transient error during
one period/cycle, the application will naturally recover in the next period/cycle, when a new network
message is generated. In contrast, an IEC 61499 application is event oriented, so it will typically only
generate a network message when the PUBLISH or SEND FBs receive an REQ event, or when an RCV
FB receives an RSP event. While this may be considered an advantage due to the lower traffic imposed
on the network, it also has the drawback that the application becomes much more susceptible to transient
communication errors that may occur on this same network.
Consider, for example, the system in Figure 55.13. Now imagine that a CR event generated by FB Logic1
does not reach the NEW event input of Logic2 due to a transient communication error on the network
used by the publish and subscribe CR2 FBs. The result will be that all the lights connected to Logic1 will
be correctly switched off, and no light connected to Logic2 will be lit to continue the chasing sequence.
We may conclude that due to the asynchronous event-based architecture used by IEC 61499 applications,
these are more susceptible to network failures. Nevertheless, this does not mean that the application
will fail at the smallest network interference. In fact, many communication protocols include error
detection and correction algorithms. If the communication protocol used between the CR2 PUBLISH
and SUBSCRIBE FBs includes error detection and correction mechanisms, the IEC 61499 application
will not be affected by the transient network failure. However, note that in the presence of failures, the
exact semantics of the communication service interface FBs is not specified by the IEC 61499 standard,
as well as the choice of which specific implementation of the communication service interface FBs will
affect how the IEC 61499 application will react when in the presence of transient network failures.
The message delivery semantics in the presence of failures may generally be classified into three
classes: “at most once,” “at least once,” and “exactly once.” Although the “exactly once” semantics are
usually the preferred semantics, due to the higher number of messages required, sometimes semantics
© 2011 by Taylor and Francis Group, LLC