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

55-18 Industrial Communication Systems
For the exchange of real-time application data, CIP provides the means of so-called implicit messages.
Implicit messages have a connection-oriented uni- or multicast producer/consumer messaging model
(i.e., similar to publish/subscribe model). In general, fieldbuses feature a cyclic execution behavior. In
difference, CIP allows the so-called application-triggered message production behavior, which fits very
well to the event-triggered execution model of IEC 61499. CIP furthermore provides QoS mechanisms
that can be utilized for simplifying an IEC 61499 application, as certain communication errors can be
handled at CIP stack level. These QoS mechanisms are
1. Sequence counter: Each message is identified with an increasing sequence number, which allows
the detection of wrong message order and lost messages.
2. Production inhibit timer: With this value, the minimum time between two messages can be specified
on the producer’s side. This allows to bound the network traffic.
3. Expected packet rate: This rate gives the consumer an estimation of how often messages will
arrive. This can be used to determine if the producer was lost.
As CIP producers do not keep track of and do not request an acknowledgment from consumers, the
producer has no CIP means for detecting the loss of consumers.
With these basic assumptions, the behavior of the CIP_SEND_1 and the CIP_RCV_1 communication
FBs (Figure 55.15) is as follows:
• The device containing the CIP_SEND_1 FB initializes this FB with an INIT+ event. The FB will
create a CIP assembly object with the given ID. To this assembly object, the CIP_RCV_1 can now
connect. The size of the data and the meaning of the data are defined by the number of inputs
and their data types. As CIP uses the same data types as IEC 61499, namely the data types of IEC
61131-3, the CIP data encoding mechanisms can be directly used.
• After the CIP_SEND_1 set up its side of the communication, the CIP_RCV_1 can establish the
connection. This is again triggered with an INIT+ event. The ID input has to specify the address
of the device and the assembly object to connect to (i.e., the assembly object created by the CIP_
SEND_1). As a result, the CIP stack is configured for a consumer, and a unicast CIP connection
between the two devices is established. As the application cannot guarantee that the CIP_SEND_1
is initialized before the CIP_RCV_1, the implementation has to be robust enough to handle this
case (e.g., automatic retry to establish the connection).
• On triggering the REQ event of the CIP_SEND_1, the input data are encoded into the CIP network
format, and the message is sent. With a CNF event, the IEC 61499 application is informed
on the success of this procedure. No information on the consumer side, such as if the data have
been received and processed is given.
• On receiving a message, the CIP stack will inform the CIP_RCV_1 FB. There the data is decoded
and placed on the outputs. The application is then notified with an IND event.
• Through INIT events, the connection can be closed from both sides. If the connection is closed
from the CIP_SEND_1 side, the CIP_RCV_1 will be informed, otherwise not.
Event
INIT
REQ
INITO
CNF
INIT INITO
IND
Data
CIP_SEND_1
ID
SD_1
CIP_RCV_1
ID
RD_1
FIGURE 55.15
Producer–consumer pair implemented with CIP.
© 2011 by Taylor and Francis Group, LLC