9.2 The Clock Component for Virtual-Time Simulation

SVM only supports real-time execution. However, virtual-time simulation is required sometimes. The clock component makes it possible to simulate DCharts models in an as-fast-as-possible way.

The textual description of the clock component is included below:

Clock.des

The clock component uses variables to explicitly model the scheduler of an as-fast-as-possible simulation. (This clock component is not functional in distributed simulation. Timewarp [31] technology is needed for as-fast-as-possible distributed simulation.) To use this component, the designer designs a real-time model as usual, but imports the clock as a top-level orthogonal component. Some transitions in the model need to be modified to interact with the scheduler. After this, the real-time model is converted into a virtual-time model. In a virtual-time model, there must be exactly one clock component.

In a real-time simulation, a model schedules transitions simply with the $after$ special event. The transitions with this event are triggered after the specified number of seconds. In as-fast-as-possible simulation, scheduling becomes different. The simulator does not really wait. When no event is scheduled at the current time, the virtual time counter is immediately increased to be the next scheduled time, and the transitions scheduled at that time are fired without delay.

When the clock component is used, the model schedules transitions with the schedule event. This event is broadcast by other parts of the model, and it is handled by the clock component. Two parameters must be sent with this event:

1. The first parameter is an arbitrary ID. This ID can be any Python variable. When the virtual time becomes equal to the scheduled time, the clock broadcasts a notifier with this ID as a parameter. Transitions in the model that react to the notifier test this ID in their guards to determine whether or not the event is scheduled by themselves.

2. The second parameter is a float number of the difference between the scheduled time and the current time. It must be positive or 0. If its value is 0, the notifier will be received before the clock component advances the time counter.

For example, if an orthogonal component in the model has ID ``o1'' (arbitrarily determined by the designer), and it schedules a transition after 5.3 seconds, it may send the schedule event with action ``[EVENT("schedule", ["o1", 5.3])]'', which is then handled and recorded by the clock component.

The clock component increases the virtual time automatically when no more events are scheduled at the current time. At that time, all the orthogonal components are considered idle because they are waiting for notifiers from the clock. This condition is expressed with the following guard:

len(eventhandler.event_list)==1 and len(sched)$>$0

Here, eventhandler.event_list is the internal list of scheduled events in SVM. If its length is equal to 1, no event other than the one that the clock component itself schedules is in the event list. This means all other orthogonal components are idle. This guard also checks whether there is any event scheduled in sched (the list of schedule requests maintained by the clock component).

When all the other orthogonal components are idle, the clock component increases the time counter to the smallest scheduled time. It then broadcasts notifiers. A notifier is a notify event with the same parameters as the schedule event that schedules it. If multiple events are scheduled at exactly the same time, the clock component broadcasts multiple notifiers with different parameters. The transitions in other orthogonal components reacting to the notify event use guards to test whether they are the ones to be notified. To continue with the last example, ``[PARAMS][0]="o1"'' is the guard of the transition that reacts to the notify event.

In real-time simulation, the current time can be retrieved by calling the time function in the time Python library. This function returns the current time according to the hardware clock. However, as-fast-as-possible simulation uses a different concept of time. The current time is maintained in a time counter. To retrieve the current time from the clock component, a gettime event should be sent without parameter. When the clock component receives this event, it immediately replies with a timereturn event. The current time (a float number) is the only parameter with the event. The receiver retrieves the current time with ``[PARAMS][0]''.

The following are several rules for the current time broadcast by the clock component:

• It is impossible to request and retrieve the current time in the output of a transition. At least 2 transitions are required for this purpose: one sends the gettime event, and the other reacts to the immediate timereturn event. (As a trick, the model may directly access the global_time variable in the clock component, since all the variables in a model, including those of the clock component, share the same name space. However, this method is not modular.)

• Usually, there is no need to retrieve the current time in a scheduled transition, because the current time is always equal to the time when it is scheduled, received as the second parameter of the notify event.

• Using the clock component and the $after$ special event (with $t$ larger than 0) in combination produces unpredictable result and is strongly discouraged.

• Multiple clock components in the same model conflict with each other. For as-fast-as-possible simulation, there must be exactly one clock component.