Class Transport should implement the state transitions triggered by the
assembler's FULL and NOTFULL events.
Class Machine should extend the finite state automaton to consider the
possibility of a machine breaking down at random time instants and
getting repaired after a certain time period.
Class DiscreteProcess should offer the possibility of removing an event from
the list of active events. If this functionality is available, the implemen-
tation of its subclasses should be revised.
Class Piece could be introduced to represent different types of piece with
different processing times and different sequences of manufacturing
operations. For example, a piece might need two sequential operations by
the same machine.
The simulator should elaborate statistical data describing the work cell
behaviour in a given time frame. For example, it might report the work
cell throughput, the total processing time of each machine, the total
number of bolts produced, and the number of times the buffers got full or
The case study exemplified the development of a simulated work cell
Architectural style . The problem specification clearly sketched the
physical architecture of the work cell system in terms of physical devices,
their individual behaviour and their functional dependencies. The work cell
controller has been designed as a virtual machine that simulates the event-
driven dynamic of the physical devices.
Generic components . In order to promote software reuse, the design of
the work cell simulator defined an architecture that clearly factorizes the
basic simulation mechanisms (e.g. the event clock) of any event-driven
system from the specific description of the work cell components' dynamics.
Communication . From an implementation point of view, the simulator
architecture builds on the model of asynchronous communication between
Concurrency . The behaviour of the work cell components has been
formalized by means of finite state automata. This choice appeared parti-
cularly appropriate for an event-driven system since a finite state automaton
models components in terms of states (the possible configurations of their
attributes), transitions (the rules to change the current state), and events
(the stimuli that fire transitions). Event-driven systems can be found in a
variety of application domains: factory automation, telecommunications,
traffic forecasting and control, robotics, video games, simulation of physics