23.08.2013 Views

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

SHOW MORE
SHOW LESS

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

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

380 Case Study<br />

(local) sensors and actuators (see Figure 12.2). Notice that the model does not distinguish<br />

between the different kinds <strong>of</strong> feeders shown in Figure 12.1. This emphasises the<br />

strive for generic modules with generic interfaces. Next to the controllers, Figure 12.2<br />

shows a product information server. The information server produces information for<br />

the main feeder stations and consumes information that leaves the stacker station.<br />

12.3.2 Message Flow Diagram<br />

The Architecture Structure Diagram <strong>of</strong> Figure 12.2 shows the structure <strong>of</strong> our conceptual<br />

solution, but does not give any clue about behaviour and communication. A conceptual<br />

solution <strong>of</strong> how stations communicate and exchange information can be found<br />

by considering the requirement <strong>of</strong> personalised mail. The solution is shown in the<br />

Message Flow Diagram <strong>of</strong> Figure 12.3. The diagram shows a cluster instance for each<br />

Feeder<br />

Station<br />

accept<br />

(PI)<br />

accept(PI)<br />

Merger<br />

Station<br />

accept(PI)<br />

Feeder<br />

Station<br />

Feeder<br />

Station<br />

accept<br />

(PI)<br />

Feeder<br />

Station<br />

accept<br />

(PI)<br />

accept(PI) Product_<br />

Information_<br />

accept(PI)<br />

Server<br />

Packer<br />

Station<br />

accept<br />

(PI)<br />

Printer/<br />

Separator<br />

Station<br />

accept(PI)<br />

Figure 12.3: Message Flow Diagram <strong>of</strong> the Control System<br />

accept<br />

(PI)<br />

Stacker<br />

Station<br />

controller with corresponding sensors and actuators. These clusters communicate by<br />

sending each other accept ¢<br />

messages. The idea is to create a flow <strong>of</strong> product informa-<br />

PI£<br />

tion objects through the controllers. Product information objects are generated by the<br />

Product Information Server and <strong>of</strong>fered to both the main Feeder Stations. The information<br />

objects leaving the Stacker Station are accepted by the Product Information Server for further<br />

processing3 . Product information objects are modelled by data objects <strong>of</strong> data class<br />

PI. Each PI object contains the personal information <strong>of</strong> a corresponding physical mailing<br />

product on the production line. The flow <strong>of</strong> PI objects is completely synchronous with<br />

the flow <strong>of</strong> their physical counterparts, i.e. with the personalised packets. By processing<br />

the PI objects the appropriate way, the position <strong>of</strong> each mailing product can be precisely<br />

known, and appropriate services can be performed at the right time. To give a more<br />

in-depth understanding <strong>of</strong> how this conceptual solution works we have to look inside<br />

one <strong>of</strong> the station clusters.<br />

3 The information server can for instance retransmit a PI corresponding to a damaged packet.

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

Saved successfully!

Ooh no, something went wrong!