P L A S A

 

     
     
     
_
 

PLASA - Piecewise Linear Aggregate Simulation Architecture

The PLASA architecture is intended for simulation of queueing systems. It is based on the Theory of Piecewise Linear Aggregates founded by Ukrainian scientists N.P.Buslenko and I.N.Kovalenko in 70s.

Main idea

The main idea of this approach is that the queuing system may be performed as an oriented graph. The nodes of the graph correspond to some processing devices like queues, servers, gates, generators etc. The arcs correspond to some streams of elements, which are being processed. In order to build the model we need to describe the behavior of the nodes and element routing. 

We hope that this approach should be clear for researcher’s understanding. If we are able to model real-life system by queuing one, we need to directly transform this abstract queuing model into simulation categories. It means that we should be able to put the real-life objects into correspondence with simulation objects as well as to put real-life system behavior and rules into correspondence with some algorithms for their describing. This clearance is the main aim of PLASA approach.

PLA

PLA – Piecewise Linear Aggregate is an abstract object, which is capable to perceive entering signals X, produce output signals Y and be in each instant in a condition Z.

 



As far as the PLA has the discrete-event essence, the internal parameters Z have piecewise dynamics.

Model objects

The objects of the model may be divided into dynamic and static.

The dynamic objects are transactions. They correspond to the elements, which are being processed in queueing systems. They can have arbitrary structure and size, different priority levels and can be preemptive or non-preemptive.

The static objects are aggregates. The aggregates, which process transactions, are blocks. So, the blocks correspond to the nodes of queuing graph. Another kind of aggregates is schedulers, which are used for planning of any user-defined event.

Activation

Activation is the event occurring in the aggregate due to time movement.

It may be:
-  Finishing of the transaction service in server or storage
-  Expiration of appropriate waiting time for the transaction in the queue
-  Transaction generation in generator
-  User-defined event in the scheduler

In order to occur, the activation should be previously ordered. The ordering of future aggregate activation takes place when:

Time movement

The model time movement is based on the List of Future Events (LFE), which keeps the records with the information about the future activation. Actually, the ordering future aggregate activation means insertion of this record into LFE.

 

As far as the LFE is ordered by time, the time movement is implemented as a cycle of LFE scanning. Each scanning of the list means getting the first record, change of the model time, activation of the aggregate and executing all possible transaction passes.

The result of block’s activation is its ability to pass transaction. All blocks, which are ready to pass transactions (non-empty queues, servers after the end of service, generators after generation), are stored in the List of Current Events (LCE). Executing all possible passes means scanning the LCE and attempt to pass transaction from one block to another. 

Transaction passing

When the block is ready to pass transaction we need to solve what block the transaction should be passed to. This procedure is called routing. In our approach the routing considered as event. In order to handle this event the user should to write own algorithm. So, the routing may be very flexible.

The transaction will be passed to another block only if it is ready to receive the transaction. The only exclusion is the priority preempting.

Event handling

The events are the key mechanism to use general algorithms for describing the model’s behavior. That is an easy way to provide flexibility in the modeling of complex systems. The events handling gives answer to the questions like “What should be done when:

-  Transaction enters to the block
-  Transaction exits from the block
-  Transaction is preempted by another one
-  Transaction should be routed
-  Waiting time in the queue is expired for some transaction
-  The scheduler is activated

Limitation

The limitation of PLASA architecture is that in each instant each transaction is placed in one block.

Performance

From the performance point of view, the PLASA has the following advantages:

-  Simulation algorithm does not carry on transactions
-  Transaction in blocks are directly accessible
-  All time dependence is concentrated in LFE

Simulation performance may be considered as the number of transaction passes per second. In the simulation using PLASA architecture the performance

-  Does not depend on the number of transaction in the model
-  Is back proportional to the binary logarithm of LFE length
-  Is back proportional to the LCE length

Hybrid modeling

The architecture we have suggested may be easily applied for simulation of hybrid systems. The continuing process, which is usually described by some equation like X = F (t), may be transformed into discrete form.

 

  

The change of X value at some moment of model time may be considered as an event and be handled by Scheduler. These events may be kept in the common List of Future Events.  In this way we can combine simulation of continuing process with any other discrete logic.  

Application

The PLASA architecture is applied in Softland simulation tool Delsi 1.1, which is implemented as a set of components for Borland Delphi 3.0 & 4.0.

To see how does it work, download the trial version of Delsi.