The simulation is virtually indefinite iterative evaluation of the model’s actuators that operate on system’s state.

Given inspiration in biochemistry, the nature of the Sepro system does not impose any evaluation order of the actuators and selection order of objects. However, to be able to perform the simulation on Von-Neumann computer architecture which is sequential, we need to define the order of events in the simulation, and understand it’s impact on the simulation result. The emphasis is more on the explicit impact description than on the actual order definition. The evaluation order is a meta-problem that we are not trying to solve yet, but we need to propose few solution to start with.


In this evolutionary step of the system we consider the time to be unified globally. That means that time is the same for every entity of the system.

Having global time of discrete nature, we can refer to each state by global time reference t and can say that state of the system at time t is described as a state of objects and bindings at time t.


Simlation step \(\Delta\) is an approximation of system’s transition in form of a function \[G^{t+1}=\Delta(G^t, M)\] where \(G^0\) is the graph \(G\) from the model \(M\).

We have to keep in mind that the \(\Delta\) is not a true simulation mechanism, just an approximation. It is so due to the assumption of global time and potential effects of linearization.

During the simulation step the following happens:

As mentioned above, the order how the actuators, their evaluation and application is executed is left to the concrete implementation of the simulation engine. The decision whether the simulation is performed in parallel and what kind of parallelism is used is an implementation choice of the simulation engine. It has to be remembered that, as mentioned before, the simulation might be highly sensitive to the order of execution.

“Sequential Scan” Simulation Method

Here we propose a simple, quite primitive yet straightforward simulation method: Sequential scans with actuators first. This method performs the simulation step in a single thread and considers the time to be system-global.

The simulation step can be described in a pseudo-language as:

    FOR actuator IN unary actuators DO:
        evaluate unary actuator
    FOR actuator IN binary actuators DO:
        evaluate binary actuator

We serialise the simulation process by applying the transitions of the system in the order as given by a lazy selection algorithm described below. The method is analogous to vertical and horizontal line scan of a CRT screen where an object can be seen as a point on the screen and where the beam traverses the points in fixed pattern. One simulation step can be modelled by a single full scan of the whole screen. Once the beam touches a point on the screen, it does not go back within the same full screen scan.

The unary actuator scan is depicted in the following figure:

Unary scan
Unary scan

The evaluation of unary actuator is a single pass through the lazy selection of objects matching actuator’s predicates:

selection := objects matching actuator selector
FOR object IN selection DO:
    IF object matches selector:
        apply actuator transitions to object

The binary actuator “scans” a cartesian product of the “left” and “right” selector of the actuator:

Binary actuator - scan of cartesian product
Binary actuator - scan of cartesian product

The evaluation of the binary selector is as follows:

selection L := GET objects matching left selector of actuator
selection R := GET objects matching right selector of actuator

FOR left IN L DO:
    FOR right IN R DO:
        IF left does not match left selector:
        IF right does not match right selector:

        apply transition to left and right

The inner conditions are to filter out objects that might have been already modified in the scan pass and might not fit the selection predicates any more.

Binary actuator - skipping
Binary actuator - skipping

Known Issues

The scan method described above has two major factors that influence the the simulation’s outcome:

Let’s consider two actuators A and B evaluated in the same order: first A then B. If an object does not match predicates of A, matches predicate for B and actuator B modifies the object in a way that it would match actuator A, the object is not evaluated again with the actuator A. We will call this actuator order error.

Let’s consider order of objects \({o_1,o_2,\ldots,o_n}\) and an actuator that by evaluating \(o_1\) modifies \(o_2\) in a way that \(o_3\) will not match the actuator’s predicate (will lose candidacy, will not be visited). If we provide another order, for example reverse order, then \(o_2\) will be visited. We will call this object selection order error.

Here we suggest that how the simulation sub-steps are ordered must be known fact to the simulator user.

For further research, it might be interesting to further investigate effect of ordering to the outcome of certain models. For example:

In a potential virtual laboratory where one might test different kinds of ordering the controller might provide mechanisms to compare different outcomes based on the orderings. This investigation is out of scope of this article, left as an exercise to the reader.

Parallel Evaluation

Massively parallel evaluation is the ultimate goal of the system as it closely mimics the behaviour in the real world. By massively parralel we mean one processing unit per object per actuator observing the relevant context of the unit-associateid object.

Simplified parallelism can be achieved by splitting the object graph into smaller parts, performing partial evalutaions and then consolidating the results. This is a whole are to be explored as it opens many questions, such as:

Control Signaling

The language gives a possibility to provide signals to the simulator. Signals are triggered together with activation of the associated actuator. The control signalling has no direct effect on the model and it’s interpretation is given by the simulator. It can be thought as an action to communicate unidirectionally with the observer.

There are three kinds of signals: notify, trap and halt. The notify and trap signals can carry a set of tags associated with them to provide more information to the signal handlers.