1.4.3 Simulation

DCharts are executable. Every DCharts model has a rigorous semantics and can be simulated in a simulation environment such as SVM (Statechart Virtual Machine), which is discussed later in detail.

Figure 1.11: Matrix of simulation and execution

As an overview of model simulation, Figure 1.11 illustrates the different simulation and execution strategies as a three-dimensional matrix. The meaning of the axes is described here:

• The x axis indicates whether the simulation (or execution) is sequential or parallel. Sequential simulation is step by step simulation that guarantees no overlap of two or more operations (such as change of states and execution of action code) at the same time. Parallel simulation, however, strives to perform operations in a parallel way typically to maximize performance. Due to the sequential nature of most of the models, it is very hard to tell which operation can overlap with another. The overhead of finding out potential overlapable operations and synchronizing different parallelized parts is usually so high that the simulation slows down rather than speeds up.

• The y axis indicates whether the simulation (or execution) is local or distributed. Local simulation is done on a stand-alone process. There are three kinds of local simulation: single-threaded, multi-threaded, and multi-process. In distributed simulation, multiple processes are involved in a single simulation. Components participating in the simulation are deployed among those processes in a modular way. They communicate with each other by means of messages via a network.

• The z axis indicates whether it is a virtual-time simulation or real-time execution. Real-time execution is synchronized with the real time (or wall-clock time). It may need to satisfy several time constraints in order to guarantee the real-time behavior of the model. The satisfaction of those time constraints usually requires support from the underlying operating system. Virtual-time simulation uses a timer that is usually not synchronized with the wall clock. If the timer is proportional to the real time, the simulation is called scaled real-time simulation; if the timer is a counter that keeps track of the time and it is advanced as fast as possible (i.e., as soon as all the components are waiting for their scheduled events), the simulation is called as-fast-as-possible simulation.

It is important and interesting to know all the combinations of these schemes, though only some of the combinations are reasonable, and only some of the reasonable combinations are relevant to this thesis work.

• Sequential local real-time execution. This type of execution is natively implemented in SVM, the interpreter for DCharts. All the operations are sequentially executed on a multi-threaded process. Different threads are synchronized to guarantee that only one operation is performed at a time.

• Sequential local virtual-time simulation. The two types of virtual time (scaled and as-soon-as-possible) are not directly supported by the SVM simulation kernel. However, scaled real-time simulation can be easily simulated with real-time simulation. This can be accomplished by redefining the macro that retrieves or schedules time (with the $after$ event), as discussed later. The later part of this thesis also shows that as-soon-as-possible simulation can be simulated with a clock component (section 9.2). As a result, there is no need to internally implement this kind of simulation.

• Sequential distributed real-time execution. For distributed execution, it is natural to allow parallel behavior between components on different computers. Sequential behavior can be simulated with parallel execution by means of global semaphores or a global clock component. However, this makes the execution less efficient than sequential real-time execution on a single computer (because of latency in the network and the overhead of synchronization). Because it is rarely useful, sequential distributed real-time execution is not directly supported by the SVM.

• Sequential distributed virtual-time simulation. For the same reason of inefficiency, sequential distributed virtual-time simulation is not supported. The users should use sequential local virtual-time simulation instead.

• Parallel local real-time execution. SVM provides support for multi-process simulation on a single machine. Those processes are highly parallel. They influence each other in the form of messages via ports. The execution is real-time so that each of the processes directly accesses the time given by the computer hardware.

• Parallel local virtual-time simulation. Virtual time is not directly supported by SVM. However, with a special clock component running as a separate process and providing time service to all the other processes, the two types of virtual-time simulation are made possible. As a result, there is no need to implement this kind of simulation internally in the SVM.

• Parallel distributed real-time execution. This kind of execution directly corresponds to distributed software systems and is thus interesting. SVM builds parallel distributed real-time execution on top of PVM (Parallel Virtual Machine) [10]. Ports are defined on the boundary of components. Individual components have parallel behavior. They communicate with messages sent via connections between ports over a network.

• Parallel distributed virtual-time simulation. This kind of simulation is simulated with parallel distributed real-time execution with an additional clock component. The clock component reveals its ID to all the other components and provides global timing service to them. This clock component is discussed later in general.

From this discussion, it is easily seen that SVM is a powerful simulation tool that supports most of the simulation schemes, though some are simulated by the others with extra components. The concept of a clock component is important because it reduces the requirements on the simulation engine. The simulator is thus minimal and optimizable.