CC BY
36Formalization and enforcement of requirements to modular discrete-event simulation runtime
E. V. Chemeritskiy, K. O. Savenkov
This paper presents an extendable architecture for a discrete-event simulation runtime (DESR). The architecture is based on a set of logic blocks. Each block encapsulates a part of the DESR functionality and provides an interface to that functionality for other blocks. Differences in requirements that are imposed by different simulation problems are encapsulated in distinct logic blocks. Interface of each block is formally specified and there is a possibility of its automated check. Instances of the logic blocks are combined to get DESR for a particular simulation problem. Therefore, there is no need either in performance trade-offs or in a custom development of the DESR.
General Terms: Discrete-Event Simulation, Simulation
Runtime, Reuse, Modular Design
I. Introduction
THIS paper is devoted to the development of the architecture for a DESR consisting of a set of logical blocks. The particular set of blocks, their interfaces and functionality give ability to build the runtime taking into account the requirements of a custom simulation task.
The Computer Systems Laboratory1 (CSL) conducts multiple diverse research projects related to the simulation of distributed systems. The terms of such problems include the modeling of on-board systems (aviation, naval, automotive) computer networks and instruction set of processors. All these problems are focused on modeling the functionality of a computer system (data processing) and its performance as well as used apparatus - discrete-event simulation.
In CSL, such problems have been solving since 1982 and with increasing number of projects and directions it was decided to create a unified DESR [1]. It is based on a single approach to the computer systems simulation and uses a specialized language to describe simulation models.
However it became clear that this approach is not entirely suitable for the development of high-tech research projects. New challenges bring with them the need for simulation in a variety of detail levels. New requirements for scalability,
Manuscript received March 22, 2010.
E. V. Chemeritskiy is with the Faculty of Computational Mathematics and Cybernetics, Moscow State University, Moscow, (e-mail: tvz@lvk.cs.msu.su).
K. O. Savenkov is with the Faculty of Computational Mathematics and Cybernetics, Moscow State University, Moscow ,( Phone: +7(495)939-46-71; fax: +7(495)939-25-96; e-mail: savenkov@cs.msu.su).
1The Computer Systems Laboratory of the Faculty of Computational Mathematics and Cybernetics of Moscow State University
performance and response time appear. General purpose solution is a compromise between expressive power and efficiency. Another problem is that it requires a tremendous effort to upgrade and maintain it in the grease condition in the future development.
As a result incompatible changes have been made in the unified DESR for each major project and currently there are several well-used variants of the same product.
This paper proposes the other way - to develop the architecture of the DESR as a collection of logical blocks. Each of these blocks encapsulates the functionality of the DESR and provides an interface to other units to use this functionality. A set of blocks has been designed so that the differences in the requirements for the DESR made by different tasks were encapsulated in separate blocks, retaining the overall structure of the DESR. The option to compose a DESR from needed copies of the different blocks gives ability to create a DESR configured to solve a custom simulation task with no need to compromise in terms of system performance and without wasting the developers’ effort to create and support a new DESR.
This paper is based on a comparative analysis of different editions of the runtime DYANA used in several projects: 1) functional simulation of on-board marine systems [3], 2) hardware-in-the-loop simulation of on-board aircraft systems [4], 3) simulation of performance of neuroprocessor
instruction set [5] and 4) on-board automotive information system simulation. Several DESR of well-known simulation systems have been also reviewed: AutoMod, SLX, Extend, SIMAN V, ProModel, GPSS/H.
Typically, the runtime consists of a set of modules [6],[7]. However, decomposition of a runtime into blocks based on the reduction of overhead costs for retargeting to a certain task hasn’t been addressed yet. This problem has two important features:
1. The blocks must encapsulate functionality which is likely to change when adapting the runtime for a new simulation task;
2. Modification mechanisms for the runtime structure and the particular implementation of the runtime blocks should be researched;
3. The requirements for block implementations and monitoring mechanisms to ensure its compliance should be specified. The requirements may concern the block interface (has methods with a specific signature, is written in the same language, is connected as an object file, etc.), and its behavior.
The research results into a set of blocks encapsulating the differences of the examined DESR. on the basis of the proposed blocks a mathematical model of the DESR has been constructed. The paper describes in detail the functionality of each of the proposed block and the formal specifications of the interfaces of these blocks. Some mechanisms for its automated check have been proposed according to the analysis of designed specifications.
II. Components of the runtime
A generalized DESR scheme is proposed on the basis of a comparative analysis of different variants of DYANA runtime [2]-[5] and several well-known simulation systems: AutoMod, SLX, Extend, SIMAN V, ProModel, GPSS/H [8],[9].
The terms of this paper are borrowed from [10] with some generalization. The basic concepts of generalized DESR are event (a signal notifies DESR on the changing of model state), logical object (LO) (entity that is able to schedule events) and resource (provide LO with some services). Resources are presented by model time, cells of a memory (variables), clipboard information, semaphores, and so on. LO may delay event arrival until some condition depending on a state of the model resources set is satisfied. This condition is called a delay condition. As a result of the event arrival DESR can produce a number of actions called the event handling.
All event transactions take place in the handling blocks. Each block is a container for events generated by LO. Any handling block can be provided with an individual scheduler to properly rank the elements of the block. Runtime environment may contain several types of handling blocks:
1. Current event block (CEB) contains ready to be handled events.
2. Future event block (FEB) stores events with a delay condition depending only on the model time.
3. Delayed event block (DEB) contains events with complex delay condition depending on set of resources. There are two general approaches to condition check: polled waiting and related waiting. Respectively, there are two types of DEB according to these approaches: related event block (REB) and polled event block (PEB).
The work of DESR blocks is coordinated by the dispatcher throughout the model execution. The result message sequence is written to output trace.
More information about logical blocks composing the runtime environment and their functionality within the DESR is available in [11].
III. Static semantics
A. Static structure of the runtime
Runtime environment w connects a set of resources R and logical objects L of the model with the dispatcher d.
w —<R,L,d> (1)
It is important to note that the resources and the logical objects
are binded to the only dispatcher throughout the model execution.
B. Resource
The set of all resources is denoted by M. For each resource r £ KL a set of variables (memory cells) VE¥ and event container E are attached. The variables from the set V can take values from the set D.
There are two types of resources: direct access resources ®Wect and indirect access resources indirect. Direct access resource keeps track of the values of related variables using the map £: Indirect ®. In this case the resource stores only a “local copy” of the original model data. Over a set of indirect access resources a map DR: IRindirect (d. 0} to the set of dispatchers is defined. This mapping allows one to distinguish between attached and free model resources.
r=<V,E > (2)
£: Indirect -> I® (3)
®R: ^indirect Wi 0} (4)
C. Message and trace
The output trace t is presented by the message sequence. The message alphabet is denoted by M.
t = (mk }”=1 (5)
D. Event
Suppose there exists a set of all possible events E. Each event has a trace message m and the type of event p. There are several event types in accordance with type of handling blocks intended to store this event p £ {CEB, FEB, PEB, REB}.
There are a number of maps defined over event set IE. The logical object arisen the particular event could be found by the mapping £: IE -» L. Suppose that there is a set of event attributes of all kinds A. Then the mapping <A\ IE -* 2A defines an attribute set for each particular event.
Suppose there is a set of predicate symbols Pred defined over a set of resources R and depending on the values D of attached variables V. So the delay condition of event e £ E could be presented as a formula of propositional logic (quantifier-free first-order logic) C e Cond over the set of predicates Pred.
The map changing the states set of resources 5R and the states set of logical objects fi associated with the event e e E is referenced as the modification >f:9ix£-»9lx£. There are only several ways to change model state:
1. To attach a new logical object 1 e L to the dispatcher d,
2. To attach a new resource r£l to the dispatcher d,
3. To change resource variables value r. V,
4. To change logical object activity limit value a.
e =< > (6)
£: E -> L (7)
Event type imposes restrictions on the delay condition. The delay condition of events of type "CEB" is always true. Events of type "FEB" essentially depends only on the model time and
types "PEB" and "REB" by contrast are independent of model time.
The notation Var(c|)) denotes a set of significant variables of t|) £ Cond and T denotes a resource containing the model time. Then, the following expressions are correct 2:
Ve (e. p — CEB -» Var(e. C) — 0)
Ve (e. p = FEB -* Var(e. C) = T)
Ve ((e. p = PEB V e. p = REB) ->Ti Var(e. <?))
The delay condition of each "FEB" event is true point on the axis of time.
Ve (e.p = FEB -»(3!D£D (e.C(D) = true))) (11)
Introduce a special operator T: E -> ID) to determine its value.
T(e) = D£D: C(D) = true (12)
There is also a dependency between the type of event and its attribute set. The events of one type have the same attribute set. Attribute set of the event with a type different from "CEB" includes all of its attributes.
VeiVe2(ei.p = e2.p -» o4(ei) = c/l(e2)) (13)
Ve1Ve2(e1.p = CEB -»¿ifo) £ oi(e2)) (14)
E. Logical object
The logical object 1 £ L uses the event generator gEd to schedule events. For each generator gEd its current state sEiS and the step function N: § -» § X E are defined.
Newly scheduled events are stored in a local event queue E = £ E} 3 with size limited by the capacity c £ NUO. In
addition to capacity the behavior of the logical object is controlled by the activity level a £ NUO and the activity limit a£ NUO.
Over the set of logical objects the mapping DL: L -» {d, 0} to the dispatcher set is defined. This mapping allows one to distinguish between attached and free logical objects.
g=<s,JV>_ (15)
l=< g,E,a,a,c> (16)
2)1:L-»{di0} (17)
Generator g £ G constructs an event sequence {en}“ using the recurrence relation sn+1 X en+1 = g.JV(sn). Generator schedules events in order of nondecreasing model time.
Vn,k £ N (n > k -* r(en) > T(ek)) (18)
The generator has ability to synchronize its own time (presented explicitly or implicitly, through the scheduled events) with the model time. In this case the step function returns an empty symbol as the event sn+1 X 0e = g. JV(sn). If
2 Here and henceforth the operator "." will be used to denote the tuple element.
3 We assume that the event queue E has several predefined operations:
1. |JT| - returns number of events in the queue,
2. pushBack(E, e) - adds event to the back of the queue, popFront(E) - takes event from the head of queue.
the generator has planned all the events then step function returns an empty symbol as the state 0S x en+1 = g. JV(s).
F. Handling block
Handling block consists of one or several event containers and a scheduler S: 2E -* {ej, 5(E) £ E. The scheduler ranks elements of attached containers and choose a certain event range.
There are several types of handling blocks b: “CEB", "FEB", "PEB" and "REB”. Each block type has its own distinctive features.
Blocks typed as "CEB", "FEB" and "REB" have a more complex structure than a block of type "PEB". Two containers are attached to these blocks. Block "FEB" also contains a model clock (defining the event horizon) and the simulation threshold 1. "REB" block has a resource container Rreb intended to store resources changed on the current iteration of event handle loop.
1>ceb — < Eceb, BCEB, <SCEB > (19)
bpEB EFeb< EpEB< “^FEB< 1 > (20)
bpEB =< Epeb,5peb > (21)
bcEB — < Ereb, Ereb, 5reb, Rreb > (22)
The event scheduler gives as the result an ordered set of events with the delay condition met. The results of the scheduler of "CEB" and "FEB" blocks includes all such events whereas the schedulers of the remaining block types allowed not giving all such events.
VX £ {CEB, FEB, PEB, REB} Vd £ O
Ve £ £X(E) e. C(d) = true (23)
VX £ {CEB, FEB} Vd £ D £X(E) = {e: e. e(d) = true} (24)
VX £ {PEB, REB} Vd £ ID) 5X(E) £ {e: e. C(d) = true} (25)
The delay condition of event moved to "FEB" block essentially depends on the model time, and is satisfied at only point on the time axis. Scheduler of this block gives a set of events with a minimum time:
Ve £ SfebOE) (Tie) = minggiE :T(e)) (26)
In addition time of each scheduled event does not exceed the simulation threshold 1:
Ve £ 5(E) T(e) < 1 (27)
G. Dispatcher
Output trace t, handling blocks set B and direct access resource container Rdirect are attached to the dispatcher d.
d—<t,B, Rdirect > (28)
Handling block set includes a single block of “FEB”, and can also include no more than one block of every other type. Thus the assertion
OJfeb} — B £ {bcEB> l>FEB)t)pEB,bREB} (29)
(8) (9) (10) at a single
IV. Operational semantics
In this chapter the concept of runtime environment and rules of its changing are introduced. Algorithms for the initialization of the runtime and model running are described.
A. Resource state
For each resource r =< V,E > the state r is determined as a tuple consisting of variable value r.V 4 and a set of events from attached container r. E 5.
r =< eval(V),eval(E) > (30)
B. Logical object state
The state I of the logical object l—<g,E,a,a,c> is defined as a pair of corresponding event generator 1. g and the event set of events contained in the attached to the logical object container 1. E.
I =< s, eval(E) > (31)
C. Handling block state
State 33 of handling block set (29) is defined as a collection of the contents of containers attached to them.
&CEB =< evai(ECEB), eval(ECEB) > (32)
i>FEB eval(EpEB) > (33)
&PEB =< eval(Epeb) > (34)
i*REB sval(E^^), eval(EREB), eval(RREB) > (35)
D. Dispatcher state
Dispatcher state b is defined as a collection of the contents of trace t, attached handling blocks state 33 and the content of attached resource container.
b =< evai(t),93,eval(Rdirect) > (36)
E. Runtime environment state
Runtime environment condition ro is characterized by the state of resources w. R and logical object w. L of the model and the state of the dispatcher w. d.
m—<R,L,d> (37)
F. The rules of the runtime state changing
Rules (38)-(40) are intended to add a direct or indirect access resource or logical object to the dispatcher.
Rule (41) describes the changes in the state of the runtime after the value of resource variables changed.
Rule (42) defines the run of the model.
rEMjndirect & set(r.D) r.D=D, Rreb =rU Rreb
___________Efeb*0____________
handleCy cle Q.advanceTime Q
(41)
(42)
relR^jrect &r^-Rdirect ^ ^direct=rUd.Rdirect re ^indirect ^ r r.d=d IgL & l.d*d
l.d=d,lookForEvents(l)
(38)
(39)
(40)
G. Searching events to transit into the handling blocks lookForEvents( 1 £1);
The algorithm checks the readiness of the logical object to schedule events and moves events created by them into the handling blocks attached to the dispatcher. If the number of such events in the handling blocks has reached the limit, some of them are buffered into the local queue.
#Used while event handling - decrement activity level a = a — 1;
IF ( a = 0 )
#There are no more events produced by I IF ( |E| = 0 ) '
#Local event queue is empty WHILE ( s * 0S & (a < a V |E| < c) ) DO #Event generator can schedule events and local queue is not full
#Invoke event generator sxe =£(s);
IF ( e = 0e )
#Generator cannot schedule events yet BREAK;
FI
IF ( a< a )
#Activity level is less than activity limit #Add event to handling block addEvent(e);
#Increment activity level a = a + 1;
ELSE
#Handling block contain a limit event number #Add event to local event queue
E. pushBack(e);
FI
OD
ELSE
#Local event queue is not empty
#Add a number of events less or equal to activity limit
limit = min(|E|,a);
WHILE ( a < limit ) DO #Transmit event from local queue to handling
blocks
addEvent(E. popFrontO); a = a + 1;
OD
4 To indicate the values of the object X the operator eval(X) will be used.
5 Under the value of the container the set of elements contained therein is infered.
FI
FI
H. Addition of event to the handling blocks addEvent( e £ IE );
The event is placed in a handling block in accordance with its type.
#Load an event to handling block of the same type IF ( p = CEB )
Eceb = BcEB^e;
ELSEIF ( p = PEB )
Epeb = EPEBUe;
ELSEIF ( p = REB )
Ereb — EREBUe;
#Event type is “FEB” - other choices are sort out ELSEIF ( t = c )
#Event time is equal to current model time
^FEB = EpEBUe;
ELSEIF ( t >1 )
#Event time is greater than simulation threshold l.s = 0S;
ELSE
Efeb = EFEBUe;
FI
I. Event handle cycle
handleCycleO;
Algorithm iteratively retrieves ready events from handling blocks, sorts them and calls for event handling. Model time does not change during this process.
WHILE ( TRUE ) DO #Search for direct access resources with changed variable value
Vr £ Rdirect
IF ( eval(r. V) =£ £(r) )
#Add resource to container of changed resource
Rreb = fURreb;
#Refresh value r.V = r.£;
FI
#Compose the contents of REB major event container #Add events with satisfied delay conditions Ereb = {e: e £ Ereb & e. C — true}
#Add the rest to resource containers Ve £ Breb\Ereb Vr £ Var(e. C) r. E = eUr. E;
#Leave in auxiliary REB container only events with satisfied delay condition Ereb — Ereb;
#Add events depending on changed resources into the REB major event container
Vr e rreb
Ereb — r- EUEreb;
#Add events independent on resource state into CEB auxiliary container
Eceb = ®ceb + ^pEB;
#Compose the contents of CEB major event container Eceb = ^ceb + ^peb(Epeb) + ^reb(Ereb);
E — 5ceb(Eceb);
IF ( \E| = 0 )
#No event was chosen
BREAK:
FI
#Handle chosen events Ve £ E
handleEvent(e);
OD
Rreb — 0;
J. Event handling handleEvent(e);
Handled event is excluded from the handling block. Then the model state changed in appropriate to this event way and the information recorded in the trace. The dispatcher also searches for the events created by the same logical object to transfer into attached handling blocks.
IF ( p = CEB V p = FEB )
#Event does not depend on resource state
Eceb — Eceb\c;
ELSEIF ( p = PEB )
Epeb = EpEB\e;
ELSEIF ( e £ Ereb )
#Event delay condition was always satisfied Ereb — EREB\e;
ELSE
#Event was added into resource container V r £ Var(e. e) r. E = r. E\e;
FI
#Change model state according to event 5R x fi = e.MQH x £);
Add message to the output trace e. m; getEvents(L(e));
K. Model time advancing
advanceTime();
Selected by the scheduler of “FEB” block, events are transferred from the major container to the additional one. During this model time is changed to the arrival time of any of the selected events (each of these events has the same arrival time).
#Move event scheduled to current model time to auxiliary container FEB
Efeb — =>feb(Efeb);
Efeb = EpEB\EpEBi =Set a new model time
c = e. t, e £ Efeb ;
V. Requirements to the runtime blocks
Mathematical model allows identifying interfaces of blocks that make up the runtime. Thus a sufficient condition for the possibility of substituting a new runtime is the compliance of its interfaces with the requirements.
There are several classes of requirements:
1. PRED - specifies pre-condition,
2. POST - specifies post-condition,
3. RET - determines the method return value,
4. EQ - specifies equivalence to the described algorithm. Requirements for the interfaces of the blocks depend on its
type, and the configuration of the runtime as a whole. All specifications are listed in table 1.
VI. Observations on the implementation
Configurable runtime environment is developed as a compile time library written in C++. The flexibility of the runtime components is achieved through the use of template classes. Thus each of these blocks is represented as a single class. The new runtime environment with the necessary properties can be created on the basis of the class layout.
The signature of class interfaces are variable and depend on the configuration of the runtime. Nevertheless, they can be checked at compile time. As appropriate tool the library Boost Concept Check Library (BCCL) can be used [12]. This library allows formal describing of the requirements for abstract data types (concepts) used in templates and verify their compliance with these requirements.
The most difficult requirements to verify are the ones to interface of the handling blocks. Depending on the configuration of the runtime their functionality can have significant differences. But the number of fundamentally different configurations of the handling block is low. Thus partially specifying a template of dispatcher class and using BCCL can impose restrictions on the interfaces of the handling blocks for any possible configuration.
Semantic requirements for class interfaces can be checked with unit testing. Tests for the blocks can be incorporated directly into the library being developed so that using the predefined flag tests new plug-in logical block [13]. Then successfully tested blocks can be incorporated into the library itself.
VII. Conclusion
Implementation of the developing library results into ability to quickly build high-performance runtime environment with the necessary properties. This only requires new instances of some blocks. Thus a sufficient condition for the correctness of the constructed DESR is the interface compliance to formulated specifications which can be verified automated.
Tested blocks can in turn be included into the library. With
the increasing number of block instances the share of reusable code will increase whereas the cost of developing new runtime will be reduced to the layout of the ready-made blocks.
References
[1] V. G. Moloney, R. L. Smelyansky, "An integrated approach to modeling distributed computing systems", Programming N.1, 1988 pp. 57-67 (In Russian)
[2] A. Bakhmurov, A. Kapitonova, R. Smeliansky, "DYANA: An Environment for Embedded System Design and Analysis", 5-th International Conference TACAS'99, Amsterdam, The Netherlands, March 22-28, 1999. Springer (LNCS Vol.1579), pp.390-404
[3] V. V. Balashov, A. G. Bahmurov, D. Yu. Volkanov, R. L. Smelyanskiy, M. V. Chistolinov, N. V. Yushchenko, G. T. Mamontov, P. Yuhta "Experience of the program DYANA implementation for simulation and integration of on-board computing systems", Abstracts of reports XXVI conference in memory of an outstanding designer gyroscopic devices N. N. Ostryakov - St. Petersburg: Central Research Institute Elektropribor, 2008. pp. 60-61 (In Russian).
[4] V. V. Balashov, A. G. Bakhmurov, M. V. Chistolinov, R. L. Smeliansky, D. Yu. Volkanov, N. V. Youshchenko, “A Hardware-in-the-Loop Simulation Environment for Real-Time Systems Development and Architecture Evaluation”, In Proc. of the Third International Conference on Dependability of Computer Systems DepCoS-RELCOMEX 2008, Szklarska Poreba, Poland, June 26-28 2008.
[5] A. G. Bahmurov, E. G. Egisapetov, O. V. Novikov, V. V. Prus, K. O. Savenkov, R. L. Smelyansky, "Tool support for software development process for a special processor-based CPU L1879VM1 ", Methods and means of processing information. Proceedings of the Second All-Russian Scientific Conference. - M.: Publishing Department, Faculty of Computational Mathematics and Cybernetics. Moscow State University, 2005, pp.450-456
[6] C. D. Pegden, “Introduction to Simio”, Proceedings of the 40th Conference on Winter Simulation (Miami, Florida, December 07 - 10, 2008), pp. 229-235.
[7] R. C. Crain, J. O. Henriksen, “Simulation using GPSS/H”, In
Proceedings of the 31st Conference on Winter Simulation: Simulation---A Bridge To the Future - Volume 1 (Phoenix, Arizona, United States, December 05 - 08, 1999), pp. 182-187.
[8] T. J. Schriber, D. T. Brunner, "Inside discrete-event simulation
software: how it works and why it matters", Proceedings of the Winter Simulation Conference, 2005, pp. 11 pp.+
[9] T. J. Schriber, D. T. Brunner, "Inside discrete-event simulation
software: how it works and why it matters", Proceedings of the Winter Simulation Conference, 1996, pp. 11 pp.+
[10] P.J. Sanchez, "Fundamentals of simulation modeling", Proceedings of the Winter Simulation Conference, 2007, 9-12 Dec. 2007 Page(s):54 -62
[11] K. O. Savenkov, E. V. Chemeritskiy, “Discrete-event simulation
runtime: from genericity to extendability and reuse”, Simulation-2010, submitted for publication.
[12] Boost library [Online]. Available: http://www.boost.org.
[13] A. H. Bagge, V. David, M. Haveraaen. “The axioms strike back: testing with concepts and axioms in C++”, In Proceedings of the Eighth international Conference on Generative Programming and Component Engineering (Denver, Colorado, USA, October 04 - 05, 2009).
Table 1. Requirements to components of the runtime.
Block Method Block type Configuration Requirement
Type Specification
Resource get(void): D £ ID) RET eval(r. V)
check(void): {true, false} ^direct RET £(r) ^ eval(r.V)
set(D £ ID>):void ^indirect POST Q II >
Related waiting PRED r. bind has been invoked.
POST d. changed has been invoked.
bind(d): void POST r. d = d
addEvent(e £ E):void POST r. E = ellr. E
deleteEvent(e £ IE): void POST r. E = r. E\e
getEventsRange(void): < first, last > RET < r. E. first, r. E. last >
Trace addEvent(m £ M,t £ ID)): void POST The message has been added to the trace.
Event getType(void): {CEB, FEB, PEB, REB} RET e.p
getMessage(void): M RET e. m
getLogicalObject(void): L RET £(e)
change (void): void POST 5R x fl = e.MQR x fi)
getTime(void): D eFEB RET He)
condition(void): {true, false} ePEB eREB RET e.C
addToResources(void): void Related waiting POST Vr £ Var(e. C) r. E = eUr. E
removeFromResources(void): void POST Vr £ Var(e. C) r. E = r. E\e
Logical object bind(d): void POST 1. d = d
lookFor Events (void): void EQ To algorithm lookForEvents(l)
setCapacity(c £ {N, 0}):void Event buffer POST l.c = c
setLimit(a £ {M, 0}): void POST 1. a = a
Handling block addEvent(e £ E):void POST b = ellb
removeEvent(e £ E):void POST b — b\e
getEventRange(void): < first, last > RET eval(b..S'({e: e £ b})).
addIndependentEvents(< first, last >):void bcEB bcEB £ d. B POST bcEB = {< first, last >}Ub
addEvents(< first, last >): void bcEB bcEB £ d. B POST bcEB - {< first, last >}Ub
^FEB bcEB Î d. B POST bpEB = {< first, last >}Ub
timeAdvance(void): void ^FEB POST bFEB-c= min r(e) eebpEB
addResource(r £ M): void ^REB bREB £ d. B POST ^REB — rUbREB
^FEB t>REB Î d. B Related waiting POST t>FEB = rUbpEB
reset(void): void bpEB POST Resource container has been reset.
^FEB POST Ready to handle events have been reset.
bcEB POST Unhandled events have been reset.
Dispatcher addResourceDirect(r £ Mdirect): void EQ To rule (1)
addResourceIndirect(r £ Rindirect): void Related waiting EQ To rule (2)
resourceChanged(r £ R): void bREB £ d. B POST bpEB - addResource(r) has been invoked.
bREB Î d. B Related waiting POST bFEB- addResource(r) has been invoked.
addLogicalObject(l £ L):void EQ To rule (3)
addEvent(e £ E):void EQ To algorithm addEvent()
handleEvent(e £ E):void EQ To algorithm handleEvent()
handleCycle(void): void EQ To algorithm handleCycle()
run(void): void EQ To rule (5)
