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

Communication Aspects of IEC 61499 Architecture 55-13
Different addresses of devices
Device 1 Device 2
INIT
INITO
INIT
INITO
REQ
CNF
RSP
IND
Same ID
CLIENT_2_1
SERVER_1_2
as the server
has:
QI QO
QI QO
147.11.22.4:2048 ID STATUS
Localhost:2048 ID STATUS
15 SD_1 RD_1 3
3 SD_1 RD_1 15
147.11.22.3:1501 MGR_ID 23 SD_2
147.11.22.4:1499 MGR_ID
RD_2 23
FIGURE 55.10 Point-to-point bidirectional communication implemented using SERVER_1_2 and
CLIENT_2_1 FBs.
55.8 adding Distribution and Communication
to the Sample System
In this section, we see how distribution and communication can be added to our extended example
from Figure 55.5. Assume that the peripherals are grouped into three networking devices as shown in
Figure 55.11. There are two LED panels (LED1 and LED2), one of which (LED1) has increase–decrease
speed buttons and control panel (device panel) for setting parameters of the running lights process.
The devices are connected by two different networks: LED1 and LED2 with a DeviceNet segment, while
Panel and LED1 with Ethernet.
These physical connections need to implement the logical connection between the devices that can
be different. Thus, LED2 and panel have no direct physical connection, but information flow from Panel
to LED2 is required.
In terms of IEC 61499, network topology of this system can be described within a simulation system
configuration as shown in Figure 55.12. The system configuration is supposed to produce on-screen
simulation of our system; that is why three devices have type “FRAME_DEVICE.”
The FB application capturing the behavior logic of this system is exactly the same as was seen in Figure
55.8. Applying the mapping technique for distribution of our application across these three devices, we
obtain the system configuration with explicit communication as shown in Figure 55.13.
The communication FBs SEND/RCV used in the distributed version of our system implement the
point-to-point communication model. They are similar to PUBLISH/SUBSCRIBE, with the only difference
that multicast is not supported. We also assume that if the ID parameter is left blank, then the
compiler inserts the instance name as the ID, and each ID uniquely belongs to a pair of SEND and
RCV FBs. (This way of addressing is implemented for the local communication FBs PUBL/SUBL in
FBDK/FBRT.)
There are two modifications of the SEND/RCV FBs, one for communication over MODBUS
protocol and the other for communication in DeviceNet using the CIP. The latter FBs are called
CIP_SEND_n/CIP_RCV_n.
© 2011 by Taylor and Francis Group, LLC