Formalization and enforcement of requirements to modular discrete-event simulation runtime

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.

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.

T
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 connects a set of resources and logical objects of the model with the dispatcher .
(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 .For each resource a set of variables (memory cells) and event container are attached.The variables from the set can take values from the set .
There are two types of resources: direct access resources and indirect access resources .Direct access resource keeps track of the values of related variables using the map .In this case the resource stores only a "local copy" of the original model data.Over a set of indirect access resources a map to the set of dispatchers is defined.This mapping allows one to distinguish between attached and free model resources.

C. Message and trace
The output trace is presented by the message sequence.The message alphabet is denoted by . (5)

D. Event
Suppose there exists a set of all possible events .Each event has a trace message and the type of event .There are several event types in accordance with type of handling blocks intended to store this event .There are a number of maps defined over event set .The logical object arisen the particular event could be found by the mapping .Suppose that there is a set of event attributes of all kinds .Then the mapping defines an attribute set for each particular event.
Suppose there is a set of predicate symbols defined over a set of resources and depending on the values of attached variables .So the delay condition of event could be presented as a formula of propositional logic (quantifier-free first-order logic) over the set of predicates .The map changing the states set of resources and the states set of logical objects associated with the event is referenced as the modification .There are only several ways to change model state: 1. To attach a new logical object to the dispatcher , 2. To attach a new resource to the dispatcher , 3. To change resource variables value , 4. To change logical object activity limit value .
(6) (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 denotes a set of significant variables of and denotes a resource containing the model time.Then, the following expressions are correct2 : (8) (9) (10) The delay condition of each "FEB" event is true at a single point on the axis of time.(11) Introduce a special operator to determine its value.
(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.

E. Logical object
The logical object uses the event generator to schedule events.For each generator its current state and the step function are defined.Newly scheduled events are stored in a local event queue 3 with size limited by the capacity .In addition to capacity the behavior of the logical object is controlled by the activity level and the activity limit .Over the set of logical objects the mapping to the dispatcher set is defined.This mapping allows one to distinguish between attached and free logical objects.
(15) (16) (17) Generator constructs an event sequence using the recurrence relation .Generator schedules events in order of nondecreasing model time.
(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 .
If the generator has planned all the events then step function returns an empty symbol as the state .

F. Handling block
Handling block consists of one or several event containers and a scheduler .The scheduler ranks elements of attached containers and choose a certain event range.
There are several types of handling blocks : "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 ."REB" block has a resource container intended to store resources changed on the current iteration of event handle loop.
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.(23) (24) (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: (28) Handling block set includes a single block of "FEB", and can also include no more than one block of every other type.

K. Model time advancing
; 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 ; ; Set a new model time ; 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.
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.

Formalization
and enforcement of requirements to modular discrete-event simulation runtime E. V. Chemeritskiy, K. O. Savenkov (26) In addition time of each scheduled event does not exceed the simulation threshold : (27) G. Dispatcher Output trace , handling blocks set and direct access resource container are attached to the dispatcher .