Once the SCADA system has been completely tested, the network con-
nection between the PLCs and the simulated devices is replaced with the
serial connection with the physical devices. The rest of the SCADA system
remains unaffected by this substitution. Even this solution has a major draw-
back. The physical links between any two tanks (i.e. the pipes) are simulated
as the interconnection of two software applications that run on remote
computers (see Figure 13.6). Synchronization problems may arise when two
networked simulated devices need to enforce consistency constraints. The
transfer of a certain amount of paint between two tanks must result in the
simultaneous update of paint level in both tanks. We know that communi-
cation over the internet is affected by unpredictable delays. This might
cause the situation where a pump transfers a certain volume of paint from an
empty tank or to a full tank.
An alternative design solution consists in simulating each physical device
as a component of an application that runs on a single networked computer.
The PLCs will have visibility of each individual component as a remote
object (see Figure 13.7). The second prototype will address this issue and
will introduce the Java mechanisms for the invocation of public methods on
remote objects. According to these mechanisms it is completely immaterial
whether the physical devices are simulated by components that run on a
single computer or on different networked computers. The transition from
the simulated prototype to the physical system will require the simple sub-
stitution of the network connection between each PLC and the work cell
simulator with the serial connection between each PLC and the controlled
group of physical devices.
Simulation model: discrete events or thread-based simulation?
According to the discrete events model (see the Chapter 9 case study
“Manufacturing work cell”), the behaviour of each physical device is
Figure 13.6 The structure of the fully distributed simulator