Ptolemy simulation environment

Ptolemy

Ptolemy is a real-time simulation environment for parallel heterogeneous systems. The project is being developed by students at the University of Berkeley under the supervision of Professor Edward Lee. The development language used is Java. Ptolemy is constantly evolving. Support for new calculation models and new demo models are added, and documentation is expanded.

Ptolemy allows you to work with dozens of different calculation models, among which, for example, there is a discrete-event modeling and a finite-state machine. The modeling is based on the concepts of Actor and Director, which can be translated as "Executive link" and "Manager link", respectively. Director defines the calculation model in which the simulated system works. Many Actor'ov in combination with the connections between them determine the actual device system. In the first article, I want to turn to the discrete-time model.

Discrete event

DE provides basic tools for simulating real-time systems, such as queuing systems and communication networks. The simulation process is the movement of tokens between Actor's. A marker inherently represents some kind of data structure. When the marker enters the Actor, it will launch some action that can change the internal state of the Actor and generate new events. The DE scheduler ensures that all events occur strictly synchronously. Transfer of a marker between Actor'ami does not take time. It is important to remember that markers cannot spontaneously appear or disappear.

Let's assemble a simple discrete-time model. Let it be a data channel in which delay and packet loss are modeled. Markers will act as packages. First, open the editor window ( File - New - Graph Editor ). Most of the window is occupied by the workspace on which to assemble the model. To the left of the workspace is a library of Actor's and Director's. Add DE Director from the Directors section to the workspace . Instead of the English word Actor, which in this context is not succinctly translated into Russian, I will continue to use the word “block”.

Since markers cannot spontaneously appear and disappear, we need some source. We use the block SingleEventfrom Actors / DomainSpecific / DescreteEvents . This block does not work cunningly: it produces one marker at a specified point in time. The marker value and time can be specified in the block settings (the parameter settings window is opened by double-clicking on the block). Next, we need to simulate the delay of packet transmission in the channel. To do this, add the Server block from the same section of the library.As the name implies, this block models the server in terms of a queuing system. If the token came to a free server, then it is issued with a delay equal to the value of the serviceTime parameter, and the server goes into the busy state for this time. If the token arrives and the server is busy, then it is placed in the server queue (the size of which is determined by the capacity parameter). The queue works according to the FIFO principle, respectively, when the server is freed, the oldest token in the queue is sent to the exit with a serviceTime delay. The server is good in that, unlike, for example, a simple Delay block, it determines the delay for each token at the time of selection from the queue (if the server was free, then the selection occurs at the moment of arrival of the token). In simple words, this means that the delay does not have to take into account the waiting time in the queue.

Connect the SingleEvent output to the server input. If you run the model, then with the standard parameters of both blocks the following will happen: at a time equal to 0.0, a marker of the boolean type with the value true will appear at the output of the SingleEvent block, it will go to an unoccupied server, and at the same time it will be delayed by model time equal to 1.0. At time 1.0, the token will exit the server. To convince of this, add a plotter ( Actors / Sinks / TimedSinks / TimedPlotter ). The plotter accepts markers of type Double and displays them on the graph (time-value). The white color of the input port of the plotter means that more than one line can be connected to it. On the chart, markers of different lines will be displayed in different colors.

Change the marker value in SingleEvent to zero so that the plotter can display it. For clarity, let the server output to the input of the Const block ( Actors / Sources / GenericSources ), which will generate a marker with a value of 1 at the time of arrival of any marker at the input. The Const output is fed to the plotter. After starting the model, the plotter window should open.
In the display format settings, set the type of dots. The plotter is an indispensable tool in debugging models, because it visually displays not only the value of the marker, but also the corresponding point in time.

So far, the Server block delays any token for a strictly defined time specified in its parameters. We introduce an element of randomness. For this you need a Uniform blockfrom the Actors / Random section , which when a marker enters the input generates a new marker with a random value distributed according to the normal law between the lower and upper boundaries (set in the parameters). Let's submit the server output to the trigger input of the Uniform block, and its output to the serviceTime input of the Server block. Thus, the token passing through the server generates a new delay value, which is applied to the next token.


For rough correspondence of the simulated channel to the real one, only packet losses during transmission are lacking. To model losses, use the DiscreteRandomSource block.from the same section of Random. An array of generated values ​​is indicated in its values ​​parameter, and an array of probabilities of generating each value in a parameter pmf (Probability mass function). We specify values ​​0 and 1 in values, and in pmf - 0.85 and 0.15.

When the marker arrives at the trigger input, a block with a probability of 85% will generate zero and with a probability of 15% - one. Connect the trigger input to the server output. (Nodes are used for branching the lines - a black rhombus on the toolbar) We use these values ​​as a sign of loss (unit - packet lost).

Now, when the presence of packet loss is determined in the model of random images, it remains to realize the loss itself. To do this, use the Switch element (section Actors / FlowControl / Aggregators) The packet arriving at its input is transmitted to one of the outputs, the number of which determines the value at the control input. The first line connected to the Switch output is index 0, the next is 1, and so on. Connect the server output through the node to the input of the Switch block. If now we connect the packet loss flag to its control input, and only one line to the output, then when the loss flag (unit at the control input) is generated, the marker will be transmitted to the line with index 1, and for the line with index 0, which is a continuation of our channel, he will be "lost."

Such a simple channel in itself is of little interest, but it is convenient to use it for modeling network protocols. A simulated channel can transmit packets with a random delay and lose them with a certain probability.

Ptolemy allows you to create new Actor'y, collecting them from existing ones. In the Utilities library section, there is a CompositeActor block into which you can place any other blocks, including CompositeActor. Place the channel model in the CompositeActor. The CompositeActor workspace is opened by the OpenActor command from the context menu. The SingleEvent block is no longer needed. Instead, add one input and one output port.Connect the Server input to the input port, and the Switch output to the output port. A block encapsulating a simple channel model is ready.

You can simplify the work with the channel if you “bring out” all the important parameters: the lower and upper boundaries of the time delay range and the probability of packet loss. To do this, add the parameters lowDelayBorder, highDelayBorder and lossProbability in the block parameter settings window. The Add button brings up the corresponding dialog, in which in particular you can specify the default values ​​for the added parameters. New parameter names are now available inside the block. Replace specific values ​​with parameter names in Uniform and DiscreteRandomsource blocks.Now you can work with the channel like with any other block without even looking inside - all settings are accessible from the outside.

By building a primitive package source:

You can test the operation of the channel:

In the settings of DE Director, there is an important parameter - stopTime. By default, it is set to infinity, but to observe such a simple model, a value of 50 will be quite enough. Let

me end this acquaintance with Ptolemy. If the topic is in demand, it will soon be continued.