Simulation Settings

Let's discuss first the technical parameters that shall be specified in various fields of the simulation_settings record that you can find in soda_loading_test.erl.

For the sake of clarity, a simulation should preferably have a name of its own - to be defined in the simulation_name field. An adequate naming is convenient to discriminate more easily among runs and result sets [5].

Let's forfeit any creativity and name our case "Sim-Diasca Initial State Loading Test".

We must also define the duration (in virtual time) of the fundamental time step of the simulation (or its evaluation frequency), i.e. its overall tick duration. This is probably the most important setting for synchronous simulations - to be defined in the tick_duration field, as a floating-point number of seconds.

This corresponds to the finest granularity of time that the simulation will be able to discriminate. This may relate also to how reactive the simulated world must be.

The models involved in a simulation have a temporality of their own (a model is not even aware of the various simulation cases that may include it) and will rely only on high level, absolute durations (in virtual time of course), expressed for example as "2 hours" rather than as a number of ticks.

As a result, models are defined regardless of the actual frequency at which simulations incorporating them will be run, i.e. irrespective of the tick duration chosen by each simulation case. This offers much flexibility to the simulations, and removes one cause of interdependence between models.

Of course an infinite leeway cannot be granted: ultimately, at runtime, these models will have to convert the high level durations they embed (e.g. 2 hours) into a (positive) integer number of ticks, and of course the overall tick duration of the case must be fine enough in order that this quantification does not introduce too much inaccuracy [6].

So, why not defining in the simulation case a very small evaluation period (tick duration), to ensure that, for all models, their embedded high-level durations will be nicely mapped to ticks?

Well, this is certainly possible, yet generally it forces the engine to schedule more ticks, resulting in a decrease of the performances of the simulation. Yet Sim-Diasca offers a relatively advanced scheduling (notably able to determine ticks that have no impact and jumping over them), which may mitigate that problem.

Anyway a reasonable trade-off must be found, and in this test case we opt for a rather fine granularity, namely a simulation frequency of 100Hz, i.e. a tick duration of 0.01 second. Most simulations will elect far longer time-steps, some of them for example opting for a yearly basis. This depends much on the application domain.

Another information to specify in the simulation_settings record is the results we want to obtain from the simulation. Here we will go for the simplest solution, using the default value of the result_specification field, which is to retain all outputs. Other settings allow to filter results by probe type, or based on a series of targeted and blacklisted patterns applied to the names of the potential results [7].

So, finally, our simulation settings (that we store here in a variable that we name, for clarity, SimulationSettings - in Erlang, variable names start with a capital letter) can then simply be defined as:

SimulationSettings = #simulation_settings{
  simulation_name="Sim-Diasca Initial State Loading Test",
  tick_duration=0.01
}

As mentioned, two other records aggregate the rest of the technical settings.

Deployment Settings

The deployment_settings record allows to set precisely the computing hosts involved in the execution of that simulation case.

Sim-Diasca can indeed run a simulation on the user host only (the computer on which it is run), yet it is a distributed engine - so a single simulation can be also run on a set of computers (potentially dozens of nodes of a high-performance computing cluster).

For our simulation case to be able to run indifferently either on a single host or on multiple ones, the computing_hosts field will be set to request the engine to check first whether a text file, named here sim-diasca-host-candidates.txt, can be found. The purpose of this file is to list the host names of all the potential computers that may be involved in the simulation [8].

If this host file is found, the engine will look-up and try to use as many of the host candidates listed there as possible (depending on their availability and on the checking of various prerequisites).

If this host file is not found, or if it does not list any usable host, the case will run only locally, on the user computer.

So the definition for this field of the deployment_settings record boils down to:

computing_hosts = {use_host_file_otherwise_local,
                     "sim-diasca-host-candidates.txt"}

That same deployment_settings record is also the place where we can define the simulation elements (code and data) beyond the mere engine that shall be deployed on the computing nodes. This includes typically the binary files corresponding to the implementation of the models and scenarios [9], possibly with any set of data files they might rely upon.

Our Soda-Example case involves only a few models (e.g. model of the soda vending machine, or of a type of customer) - that will be defined in the same directory as this simulation case - and no specific data, thus setting the following field accordingly will be sufficient:

additional_elements_to_deploy = [ { ".",code} ]

This means select all code (BEAM files) recursively found from the current directory (".", i.e. mock-simulators/soda-test/src here) and add it to the deployment archive.

Still in the deployment_settings record, other parameters can be set (e.g. node_availability_tolerance) and other services can be activated (e.g. enable_data_exchanger, enable_performance_tracker), yet the Soda-Example case can do without them. So for this record, which we choose to store in a variable named DeploymentSettings, we finally end up with the following definition:

DeploymentSettings = #deployment_settings{
    computing_hosts = {use_host_file_otherwise_local,
                   "sim-diasca-host-candidates.txt"},
    additional_elements_to_deploy = [ {".",code} ]
}

Again: long to explain, very short to specify!

Load Balancing Settings

As there is no specific measure to be taken regarding load balancing here, the corresponding record will be used with all its default values set (no field specifically overridden).

We name our variable consistently with the two previous ones, for clarity, so we have:

LoadBalancingSettings = #load_balancing_settings{}

As a result we now have determined the three key records (regarding simulation, deployment and load balancing) that will allow to initialise the engine. That will be done simply thanks to:

DeploymentManagerPid = sim_diasca:init(SimulationSettings,
           DeploymentSettings,LoadBalancingSettings)

This shall be read as:

• we have a module named sim_diasca
• which exports a function named init
• that takes three parameters (our three records)
• and returns a value, stored in a variable that we named DeploymentManagerPid

We say that the arity (number of parameters) of this function is 3, and that its full name is sim_diasca:init/3.

The returned value is a PID, an Erlang shorthand for process identifier. Knowing the PID of a process allows to send messages to it; here we will then be able to send messages to the deployment manager of the engine, from the simulation case.

In Erlang, one can optionally specify the signature of a function, i.e. the types of its parameters and of its returned value.

Such a type specification clarifies the code and the developer's intent, and allows some static type checking tools to perform more in-depth verifications.

Here this would be a pretty self-explanatory specification [10]:

-spec sim_diasca:init(simulation_settings(),deployment_settings(),
              load_balancing_settings()) -> pid().

Let's continue now the simulation specification by its heart: the models.

Construction Parameters for a Soda Vending Machine

We will suppose here that a given soda vending machine instance can be created from following construction parameters:

• its name, as a character string (e.g. "My soda machine") [14] - a type designated as string()
• the number of soda cans it stores initially, as a positive integer (e.g. 100), of type can_count() [15]
• the unitary cost of the soda cans that it sells, as a floating-point cost in euro (e.g. 1.2 euro per can), of type amount() [16]

These three construction parameters will be enough to create any instance of vending machine. Note that we have no idea yet of how the state of a vending machine will be structured - that is the point of using construction parameters.

Construction Parameters for a Thirsty Customer

As for customers, we mentioned that in our simulation there were two kinds of them; indeed we consider that there are:

• "deterministic" customers, which are thirsty again after a constant duration (e.g. 15 minutes after having drunk)
• "stochastic" customers, whose repletion duration is determined by a random law in order to illustrate their use (e.g. the duration will be drawn from an exponential law of rate parameter lambda=2.2)

So a deterministic thirsty customer instance can be defined from following construction parameters:

• his name, as a character string (e.g. "John") - a string()
• the vending machine he knows, as an instance reference [17] - a type designated as class_Actor:actor_pid(), which is actually an alias for pid(); we see here that we consider that such a customer knows exactly one vending machine - neither none, nor multiple ones (we would have defined in this case a list of PIDs)
• his repletion duration, i.e. how soon, after having drunk a soda can, he will feel thirsty again (e.g. exactly 2 minutes - he is deterministic), of type duration() [18]
• his budget, i.e. how much money he initially has in his pocket (e.g. 35.0 euros) - of type amount()

So a deterministic thirsty customer will require these four parameters in order to be created.

Finally, a stochastic thirsty customer will be constructed quite similarly, except that its repletion duration will not be specified as a constant, but as a random law. For example his repletion duration in minutes could be drawn from a Gaussian law whose mean is 10, and variance is 2.

Its constructor shall thus reflect this: the repletion duration that had to be set for the deterministic customer is replaced, in the construction parameters of the stochastic one, by a random law, of type class_RandomManager:random_law() [19].

From Construction Parameters To Constructors

Now that we have specified the construction parameters that will be used, we will have to define in later steps how the state of these models will be stored.

Then only we will be able to define their constructors, which are the functions that convert the former (the construction parameters) into the latter (the initial state of the corresponding models).

But, for that, the implementation must be better known: the structure of the state of the model will have to be determined first.

Just A Bit of Computer Science To Better Understand The Whole

In Practice For Our Soda-Example Case

As we have seen, three models will be needed. They will thus be implemented in three corresponding classes:

• the SodaVendingMachine model will be implemented as class_SodaVendingMachine, specified in the class_SodaVendingMachine.erl file
• the DeterministicThirstyCustomer model will similarly be implemented in the class_DeterministicThirstyCustomer.erl file
• and of course the StochasticThirstyCustomer model will be in the class_StochasticThirstyCustomer.erl file

(as mentioned, all these files are to be found in the mock-simulators/soda-test/src directory)

The class_ prefix is mandatory to specify that we are defining a WOOPER class (and not a basic Erlang module), and, as mentioned previously, the .erl file extension corresponds to Erlang source files (i.e. that contains the Erlang code corresponding to the module of the same name).

We can see that each model will be defined separately from the others, and that it will be contained in a single, standalone source file.

For the sake of this simple test case, none of these models will inherit from others: all three will be direct child classes of the class_Actor abstract class.

A slightly more complex alternative would have been to define an abstract ThirstyCustomer model directly deriving from Actor, from which DeterministicThirstyCustomer and StochasticThirstyCustomer would have then derived.

As we can see, there are often multiple ways of modelling the same target system. We chose the simplest here.

Creating Initial Instances Programmatically

For this test case, we want following basic initial setting to be simulated:

• there will two soda vending machines (referenced as SVM1 and SVM2)
• there will three thirsty customers: TC1 and TC2, who will be both using SVM1, and TC3, who will use SVM2; TC1 and TC3 shall be deterministic customers, while TC2 will be a stochastic one

This corresponds to the following setting:

This is a fairly simple simulation, where no actor is created or deleted in its course. So it will begin and end with exactly the same five model instances (but f course their respective state will change over the simulation).

These instances will be created programatically in this example: the simulation case will explicitly create them, by code, one by one.

Actually, even if the implementation of the models is not known yet, we can already determine the corresponding snippet that will be part of the simulation case in order to create the expected initial instances.

We must just know that:

• initial instances must be created by using the class_Actor:create_initial_actor/2 static method, whose first parameter is the name of the class of the instance to create (e.g. class_Incinerator), and whose second one is the (ordered) list of the construction parameters for that upcoming instance
• in Erlang:
  • comments start with the % character
  • as mentioned, a variable name starts with a capital letter (e.g. MyVariable) but prefixing it by an underscore (e.g. _MyVariable) makes it a mute variable, i.e. a variable that will be ignored by the compiler - so specifying it just serves documentation purposes
  • a list is denoted by brackets, and may not be homogeneous (e.g. MyList=["hello",42])

These programmatic creations translate as:

% First machine starts with 100 cans, 2 euros each:
SVM1 = class_Actor:create_initial_actor( class_SodaVendingMachine,
    [ _FirstMachineName="First soda machine", _FirstInitialCanCount=100,
      _FirstCanCost=1.0 ] ),

% Second machine starts with 8 cans, 1.15 euro each:
SVM2 = class_Actor:create_initial_placed_actor( class_SodaVendingMachine,
    [ _SecondMachineName="Second soda machine", _SecondInitialCanCount=8,
      _SecondCanCost=1.15 ], _PlacementHint=gimme_some_shelter ),

% First customer is deterministic, uses SVM1, is thirsty 2 minutes
% after having drunk, and has 35 euros in his pockets:
_TC1 = class_Actor:create_initial_actor(
  class_DeterministicThirstyCustomer,
  [ _FirstCustomerName="John", _FirstKnownMachine=SVM1,
    _FirstRepletionDuration=2, _FirstInitialBudget=35.0 ] ),

% Second customer uses SVM1 too, yet is stochastic: he will be thirsty
% again between 1 and 7 minutes after having drunk, and has 40 euros in
% his pockets initially:
_TC2 = class_Actor:create_initial_actor( class_StochasticThirstyCustomer,
  [ _SecondCustomerName="Terry", _SecondKnownMachine=SVM1,
    _SecondRepletionLaw={ uniform, 7 }, _SecondInitialBudget=40.0 ] ),

% Third customer uses SVM2, is deterministic and thirsty 2 minutes
% after having drunk, and has 77 euros in his pockets:
_TC3 = class_Actor:create_initial_actor(
  class_DeterministicThirstyCustomer,
  [ _ThirdCustomerName="Michael", _ThirdKnownMachine=SVM2,
    _ThirdRepletionDuration=2, _ThirdInitialBudget=77.0 ] ),

Scrupulous readers noticed that the creation of SVM2 actually relies on a variation of class_Actor:create_initial_actor/2.

This static method, named class_Actor:create_initial_placed_actor/3, takes an extra parameter: a placement hint. The engine will ensure that all instances created with the same hint (here, the gimme_some_shelter atom [21]) will be co-allocated, i.e. created on the same computing node (whichever it is).

This allows to deliver locally the numerous messages they exchange, which is a lot more efficient than sending them through a network.

Thus a user knowing that by design a set of instances will be tightly coupled (for example, models of a modern human being and of his beloved smartphone) is able to have them co-allocated for best performances, irrespective of how the simulation case, depending on each simulation run, will be later dispatched on a set of networked computing nodes.

Here, at least another initial instance should be created with gimme_some_shelter for this hint to be useful.

Creating Initial Instances From a Data Stream

Of course "real" simulations tend to be far more demanding than the previous case relying on five actors, and may involve literally millions of model instances.

It would be unlikely that such a large number of actors be created programmatically; instead these actors should preferably be instantiated from a data stream, typically a text file.

Sim-Diasca provides a simple, compact, flexible format to do so; as always, initial creations are to be triggered from the simulation case.

In a few words, remembering that the construction parameters of a soda-vending machine are [MachineName,InitialCanCount,CanCost], creating such a machine would just boil down to having, in said data file, a line like:

{ class_SodaVendingMachine, ["Machine #1 read from data",
                              45,1.5] }.

If wanting to be able, in another point of the data stream, to refer to an initial instance, then its creation shall be prefixed by the specification of a user identifier ("My second machine" here), like in:

"My second machine" <- { class_SodaVendingMachine,
                            ["Machine #2",4,1.4] }.

Then other initial instances could refer to that instance (i.e. know it at construction time), like in:

{ class_DeterministicThirstyCustomer, [ "Cresus",
  {user_id,"My second machine"}, 12, 16000.0 ] }.

Here, remembering that the construction parameters of a deterministic thirsty customer are [CustomerName,KnownMachinePid,RepletionDuration,InitialBudget], the customer named Cresus would detain a reference (translated into a PID at construction time) onto the vending machine named Machine #2.

As a result, the customer will be able to interact with the machine from the simulation start (since it will know the PID of this machine). Until it has done so (thus letting the machine knows about its own PID), the machine will not be aware of him (as here, by design, it has no means of knowing that customer).

In such an initialisation data stream, the order of the lines does not matter, cyclic references are supported (so we could define two actors mutually aware of the other), and comments (lines starting with %) and blank lines are ignored.

One may refer to the soda-instances.init data file as a full example.

For a simulation case to read initial instances from such an initialisation file, the corresponding filename must be listed in the initialisation_files field of the simulation_settings record, like in:

[...]
SimulationSettings = #simulation_settings{
  [...]
  initialisation_files = ["soda-instances.init"]
  [...]
},
[...]

One may refer to the section 10.3 of the Sim-Diasca Technical Manual for more information about instance creation.

What About Scenarios?

Instance creation has been discussed, and we saw how actors (model instances) shall be created.

As mentioned in our mini-ontology about simulation (see chapter 3 of the Sim-Diasca Technical Manual), the overall simulated world is the union of the target system and of its context.

While the target system as a whole (e.g. a city) is described based on the various models involved (e.g. buildings, roads, people), in a simulation this target system might have to be evaluated on par with a context that may interact with it (e.g. the country surrounding that city, the weather system over its districts, the mayor and his team).

How shall this context be described, initialised and evaluated then? The good news is that if, semantically, the target system and its context are different, technically they have to be managed the same, notably to preserve simulation properties.

Knowing that the context is made of scenarios exactly like the target system is made of models, creating the context (which, in the general case, can be disaggregated, can have a state, can interact with its parts and with the target system) is to be done exactly as shown previously with the models.

So multiple scenarios may apply (e.g. regarding weather, pollution, population) and multiple instances of them can coexist concurrently (e.g. one weather cell per spatial subdivision of the city).

For example, like we defined class_SodaVendingMachine we could define class_CanCostScenario, an horrible scenario that would reproduce a creeping inflation and would make the price of soda cans steadily increase over time.

An instance of such scenario would be created from two construction parameters, the (supposedly constant) monthly cost increase (e.g. 7%, hence 0.07) and the list of the soda vending machines that would be affected by this inflation.

Then, taking a programmatic creation as an example, we could have:

_SC = class_Actor:create_initial_actor( class_CanCostScenario,
    [ _MonthlyRate=0.07, _VendingMachines=[SVM1,SVM37] ] )

We can thus see that nothing more than models is to be learned in order to manage scenarios, since they are technically the same beast. As hinted by the static method used here, which is defined in the context of the Actor class, the engine does not even make a difference between models and scenarios.

Instanciation Example

Of course the two approaches (programmatic/data-based) for instance creation can be mixed. One may refer to our simulation case of interest here (soda_loading_test.erl) that creates 5 initial actors thanks to code, and 9 others thanks to the soda-instances.init data file it refers to (in its initialisation_files field).

So we started the work on the models by establishing their construction parameters, in order that the initial state of the simulation could be defined, in the simulation case.

As now this case is almost complete, let's discuss the last few bits necessary to the implementation of a case, before continuing the work on the models.

Initial Time and Date

By default, a simulation starts on the first of January of year 2000, at 00:00:00. The Soda-Example relies on that default, but some cases will want to override that.

The initial simulation timestamp can be changed by communicating a new date and time to the root time manager [22] (from the simulation case and, obviously, before the simulation is started).

First step is to retrieve a reference (a PID) onto this root time manager. It can be obtained thanks to the PID of the deployment manager, which is the entry point of the simulation that was returned by the call to sim_diasca:init/3 that we already mentioned:

[...]
DeploymentManagerPid = sim_diasca:init(SimulationSettings,
            DeploymentSettings,LoadBalancingSettings),
[...]
DeploymentManagerPid ! {getRootTimeManager,[],self()},

Explaining this last line is a good occasion to introduce more information about how Erlang is to be used.

Erlang processes communicate between them solely thanks to the sending of messages. This sending is asynchronous: a process A having to send a message M (whatever it is) to a process B (designated by its PID, stored in the BPid variable) will simply have to specify: BPid ! M.

As mentioned, all Erlang processes live concurrently, i.e. they are all executed in parallel. Unless a process is looping over its code or blocked in a receive clause (waiting for a message to be received), it will simply terminate.

This message (M) can be any Erlang term, for example the content of any Erlang variable. Here, in our simulation case, the message that we saw is a tuple (i.e. a fixed-length series of terms) of three elements [23] (respectively here: the getRootTimeManager atom, the empty list [] and the result of a call to the self/0 function). This last function returns the PID of the current process, namely here the one executing currently the simulation case.

A message is sent in a "fire and forget" manner: the sending process, A, will transfer it to the Erlang runtime and directly continue with its next instructions, without waiting for example that B receives it [24].

When the simulation case sends the {getRootTimeManager,[],self()} message to the deployment manager, this Erlang message will be interpreted according to the WOOPER conventions: the getRootTimeManager request method (i.e. a method returning a result, as opposed to oneway methods that do not return anything) of the deployment manager will be executed (here with no specific parameter, since the specified list is empty) and its result (here, the PID of the root time manager) will be returned to the sender (here, the simulation case, which specified its own PID for that, as last element of the triplet).

As a result, the PID of the (root) time manager will be returned by the deployment manager and stored in the RootTimeManagerPid variable thanks to:

RootTimeManagerPid = test_receive()

So now the simulation case knows the PID of the root time manager, and is able to interact with it.

This allows us to finally specify the initial simulation timestamp discussed in this section, simply thanks to:

% Let's start on 2020, October 21st at 7h, 12 minutes
% and 10 seconds:
StartYear = 2020,

StartDate = {StartYear,10,21},
StartTime = {7,12,10},

RootTimeManagerPid ! {setInitialSimulationDate,
                         [StartDate,StartTime]}

So here we called the setInitialSimulationDate oneway method (we do not expect any result when setting a date) of the root time manager to have its initial simulation timestamp set.

Termination Criteria

The engine must of course have also some way of determining when the evaluation of the simulation shall be stopped.

Multiple criteria can be defined, the first that applies will be the one to actually end the simulation.

Typically the models and scenarios may decide of the termination (e.g. "stop when we reach this total cost or this level of pollution", or "stop when its combination of events happens").

The simulation case can also define such a criterion, typically to mark an upper bound to the duration of the simulation.

Supposing we defined the initial time and date as described in the previous section, we can now define also its maximum duration, i.e. conversely define the final simulation time and date. This could be done thanks:

% We will end exactly 5 years later:
SimulationDurationInYears = 5,

EndDate = {StartYear+SimulationDurationInYears,10,21},
EndTime = StartTime,

RootTimeManagerPid ! {setFinalSimulationDate,
                           [EndDate,EndTime]}

So here the simulation will end no later (as other termination criteria may be triggered first) than the 21st of October of year 2005, at 7h, 12 minutes and 10 seconds.

Starting the Simulation

The simulation can be started simply by requesting the root time manager to do so:

RootTimeManagerPid ! start

This message will therefore trigger the start/1 oneway method of the root time manager.

By the way, one may wonder why this call (i.e. the message sending) visibly does not involve any parameter (e.g. we have BPid ! myMethod, not BPid ! {myMethod,["hello",42]}) yet triggers start/1 (whereas we could expect it would trigger start/0).

The reason is that the Erlang process corresponding to a WOOPER instance keeps internally the state of this instance in a term (of type wooper:state() [25]), and that this state is added as first argument when calling a method.

So, typically, here the message sending would trigger class_TimeManager:start/1 that way:

-spec start(wooper:state()) -> oneway_return().
start(State) ->
  % Actual implementation of that method.
  [...]

We can see first the type specification for this Erlang function (such a specification is optional, yet we recommend writing it down, in order to rely on clearer code that moreover can be more thoroughly type-checked).

The function is named start, takes one parameter (the state that WOOPER keeps and adds automatically) and returns as a oneway (meaning that it only returns an updated state, kept by WOOPER, and no specific result).

The Soda-Example case uses a variation of this start oneway, defined as class_TimeManager:startFor/3 and that can be called with:

% In (virtual) seconds:
SimulationDuration = 150,
RootTimeManagerPid ! {startFor,[SimulationDuration,self()]}

The corresponding definition is:

-spec startFor(wooper:state(),unit_utils:any_seconds(),pid())
    -> oneway_return().
startFor(State,Duration,SimulationListenerPID) ->
  % Actual implementation of that method.
  [...]

Here, beside the usual state, the oneway specifies a duration (the maximum one for the simulation) and a PID (here, of the simulation case).

The corresponding process will then be notified if/when the simulation successfully ends, so the case uses afterwards:

receive

     simulation_stopped ->
         ?test_info("Simulation stopped spontaneously, "
                    "specified stop tick must have been reached.")

 end

Indeed, when the simulation stops, the root time manager notifies all simulation listeners of it by sending them a simulation_stopped message.

The simulation case is not a WOOPER instance (e.g. its module name, soda_loading_test, is not prefixed with class_), hence Erlang messages are not intercepted by WOOPER and managed as method calls. Therefore the case can performs a standard Erlang receive to block and wait for such a message to arrive and, here, send a trace message and continue with its execution.

Other Elements To Include in a Simulation Case

Behaviour

Specifying

Implicitly we can anticipate that no can will be sold:

• from a vending machine having none left
• or to a customer that does not know that machine (as he is not even aware of its existence)
• or to a customer who would not have enough money to buy a can from that machine

No can should be sold to a non-thirsty customer, as at the first place it should not have tried to purchase one.

We can fairly easily imagine the underlying "appicative protocol" ruling the exchanges between a customer and a vending machine, i.e. the series of interactions that can take place between these two.

One of the many ways to formalize a bit a high-level description of the behaviour of each model is to use Finite State Machines (FSM) that interact.

The following graphical conventions are used here:

Not specifying an event condition on a state transition means here that the state change is time-based, i.e. it will occur automatically once a specific duration (in simulation time) will be elapsed.

The two models are interacting, thus the two FSMs will interact as well, based on message exchanges:

No inter-customer exchange is shown here: as an exercise, we could imagine that an impoverished customer may try to borrow money from another he knows.

So, from each of these FSMs, we can derive the behaviour of the corresponding model, from its initial logical state to all others. Transitions are clearly related to internal changes (e.g. the thirst of a customer builds over time - a.k.a. spontaneous behaviour) and external changes (denoted as the receiving of an actor message, like when a customer is notified of the price of a can of the vending machine.

-spec orderSoda(wooper:state(),amount(),pid()) ->
                  class_Actor:actor_oneway_return().

construct(State,[...],RepletionDuration,[...] ) ->
  [...]

TickRepletionDuration = class_Actor:convert_seconds_to_ticks(
             60*RepletionDuration, ActorState ),
[...]
setAttributes( ActorState, [
    [...]
    {repletion_duration,TickRepletionDuration},
    [...]
                            ] ).

actSpontaneous(State) ->
  CurrentTick = class_Actor:get_current_tick(State),
  NextSpontaneousTick = CurrentTick + ?getAttr(repletion_duration),
  ScheduledState = executeOneway(State,addSpontaneousTick,
                                 NextSpontaneousTick),
  [...]

State