23.03.2017 Views

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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Communication Aspects of IEC 61499 Architecture 55-3<br />

55.2 Illustrative Example<br />

We illustrate the ideas and problems of IEC 61499 using an example of an imaginary system that, nevertheless,<br />

represents many properties of real distributed measurement and control <strong>systems</strong>.<br />

Let us imagine that our company is producing a kind of programmable running lights system as<br />

shown in Figure 55.1, left side. The system consists of four lamps blinking according to a required mode<br />

of operation. The operation modes include “blink all lamps together” or “chase the light to the left or to<br />

the right,” and so on. The lamps are “controlled” by a controller box with four output control signals,<br />

each of which is connected to a lamp and serves as a switch, turning the lamp on and off. The control<br />

panel of the system consists of a start/stop switch and a selector knob having three fixed positions (from<br />

0 to 2) corresponding to three pre-programmed modes of operation. It could also include a potentiometer<br />

knob giving a continuous range of values from 0 to 32,767 to set the frequency of blinking (time<br />

interval in milliseconds between two consecutive flashes). As seen from Figure 55.1, all the input/output<br />

devices are wired to the interface modules of the controller box.<br />

Now, let us imagine that the R&D division of our company is working on the new generation of this<br />

system, with the main innovation being flexibility. As also shown in Figure 55.1, it is planned to extend<br />

the lights section on customer’s demand with multiple 4-LED sections and allow them to be physically<br />

distributed along large areas. Frequency of blinking may be displayed using the numeric display. The<br />

input part of the system can be extended by the buttons increasing or decreasing the blinking frequency.<br />

These buttons can be placed anywhere, say near the 4-LED sections, and pressing them shall have global<br />

effect on the frequency of blinking across the whole system. Possible extensions can also include operating<br />

the system via a portable device or cellular phone.<br />

Obviously, in this case, the direct connection of all the peripherals to the controller may require a lot of<br />

wires. The use of a network bus instead of direct wires allows saving on wiring as illustrated in Figure 55.2. In<br />

such a configuration, new peripheral devices can be easily plugged into the system. However, the hardware<br />

requires some modifications: the controller and peripherals need to be equipped with network interfaces.<br />

The question is how to organize the control logic in such a way as to allow the same easy manipulation<br />

with functions within the control program. In the following, we show how that can be achieved in the<br />

IEC 61499 architecture.<br />

The functionality of our system (simplest initial version) is programmed in Figure 55.2 as an IEC<br />

61499 application, with the correspondence shown between peripheral devices and FBs. As can be seen<br />

from Figure 55.2, FBs are represented as strange shapes with a head and a body having inputs (on the<br />

left) and outputs (on the right). The blocks are connected to one another using connection arcs. Thus, the<br />

FB diagram defines not only the data flow between the blocks, but also the control flow. To indicate that<br />

all peripheral devices are physically connected to the control unit, we have used the single bus architecture,<br />

but at this stage the details of this physical network connection are not important.<br />

The inputs and outputs located at the block’s head are called event inputs and outputs. When an event<br />

output is connected to the event input of some other block, the event emitted on the output side activates<br />

execution of the recipient FB. Thus, the control logic of the application is determined by that of each FB<br />

and by event connections between the blocks.<br />

The roles of core FBs in our example are as follows:<br />

RUNSTOP<br />

DT<br />

MODE<br />

Implements interfacing with the start/stop switch. Upon every switching generates an<br />

event at the IND output. The switch status is delivered via the OUT logic output<br />

Interface to the time-setting knob. The initial position of the knob is set to 250.ms. Upon<br />

any change of the knob’s position emits event via the IND output. The current value is<br />

available via the OUT data output<br />

Interface to the mode-setting switch. Any change of the switch’s position results in the<br />

IND event. The current status is available as a 0, 1, or 2 number at the I data output<br />

© <strong>2011</strong> by Taylor and Francis Group, LLC

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!