Simulator

This plug-in provides data-types to support the interactive or automatic execution of discrete event systems. It serves as a basis for applications that interactively inspect or debug closed-loop dynamics, perform a hardware-in-the-loop simulation of a controller interacting with a physical plant, or perform an (elementary) stochastic performance analysis.

Implementation details for application development are given in the the Simulator C++ API documentation, and - for hardware-in-the-loop simulation b) - in the IODevice C++ API documentation.

This user reference presents simulation semantics and relevant features by examples for the command-line tool simfaudes. It is organized as follows:

Configuration files and shell scripts corresponding to the examples presented are located in tutorial directories of the simulator plug-in and the iodevice plug-in.

Copyright (C) 2008, 2009 Thomas Moor, Klaus Schmidt, Sebastian Perk

Basic Configuration

The simulator is based on a hierarchy of executor classes which execute transitions in a synchronous product of participating generators. Executor classes are configured by faudes-style token streams, e.g. read from a configuration file.

The following example configures an executor class to simulate the closed loop from the very-simple machine, however, extended by the possible break-down mue_* and maintenance lambda_* of the two machines. 

<Executor>
% Configuration "exectest.sim"

<Generators>
"machinea.gen"
"machineb.gen"
"bufferab.gen"
"superab.gen"
</Generators>

</Executor>

Note that the specification of file-names for generators is relative to the directory of the overall configuration file. Alternatively, generators can be added in-line as token sequence.

Interactive Simulation

Interactive simulation can be used to inspect an overall closed-loop behaviour by selecting and executing transitions step by step. In order to perform an interactive simulation, run simfaudes on the above configuration file: 

$ cd ./libfaudes/plugins/simulator/tutorial
$ ./simfaudes -i -v data/exectest.sim

The command-line options -i and -v are for interactive simulation and verbose output, respectively. A list of all command-line options is given below.

simfaudes prompts with information about the current state and proposes an event to execute: 

% simfaudes: ========================================= current state:
<DiscreteState> "idle"        "idle"        "empty"       "idle|idle|1|empty"  </DiscreteState> 
...
% simfaudes: ========================================= enabled events:
<EnabledEvents> "alpha_a"      </EnabledEvents> 
...
% simfaudes: ========================================= proposed action:
<ProposedEvent> "alpha_a" </ProposedEvent>
% simfaudes: ========================================= enter command:

By the above, alpha_a is the only enabled event. Available commands include

  • press the return key to accept the proposed default (i.e. alpha_a), or

  • enter an event by name "some_event" to execute the respective event, or

  • enter ? to get a list of further commands.

You can inspect the closed-loop dynamics by executing events step-by-step.

Resolving Ambiguities

At each instance of time, a discrete event system is in a particular state and the model distinguishes between enabled and disabled events. However, the model does neither determine which particular event will actually occur, nor when this will happen. Both ambiguities must be resolved for a non-interactive simulation. Executor classes address this issue by interpreting

  • timed automata with clocks, guards and invariants;

  • priority event attributes;

  • stochastic event attributes.

Timed automata extend the modelling framework to capture physical time. Executor classes implement the synchronous product referring to R. Alur and D.L. Dill's real time semantics, however, using an integral data type to count faudes-time units (ftu). Effectively, this results in certain intervals at which an event can take place and bounds, up to which an event must take place. In interactive simulation mode, simfaudes will indicate not only the set of enabled events, but also the interval of time on which this set remains constant and the maximum amount of time that may pass without any event executed.

Priority attributes attach a positive or negative priority to each event. At each instance of time, the enabled event with the highest positive priority will be executed. If no event with positive priority is enabled, and if the model allows for time to elapse, no event is executed. If the model does not allow for time to elapse, the enabled event with highest (negative) priority will be executed. If no such event exists, the system is dead-locked.

For our example, we configure the processing of a workpiece and the machine maintenance to take place immediately when enabled, where M1 has priority over M2 and starting the process has priority over maintenance. 

<Executor>
% Configuration "machines.sim"

...

<SimEvents>
% Start machines immediately
"alpha_a"  <Priority> 55 </Priority>
"alpha_b"  <Priority> 50 </Priority>
% Immediate maintenance
"lambda_a" <Priority> 25 </Priority>
"lambda_b" <Priority> 20 </Priority>
</SimEvents>

...

</Executor>

As an alternative to priority attributes, stochastic attributes can be used to schedule the occurrence of events. Given the interval of time on which an event is enabled, the executor samples a random variable to determine the exact instance of time, at which the respective event will occur. It shall be noted that our approach here is somewhat ad-hoc and subject to future revisions.

For our example, we configure normal distributed processing time, where M1 is twice as fast as M2, and exponentially distributed machine break down. See ProposingExecutor, for more detailed documentation of the respective parameters. 

<SimEvents>

...

% Gauss distributed time of operation, 
"beta_a"      
<Stochastic> +Trigger+ +Gauss+   <Parameter> 50 20 </Parameter> </Stochastic>
"beta_b"      
<Stochastic> +Trigger+ +Gauss+  <Parameter> 100 20  </Parameter> </Stochastic>

% Exponentially distributed break down
"mue_a"  
<Stochastic> +Delay+   +Exponential+  <Parameter> 500 </Parameter> </Stochastic>
"mue_b"       
<Stochastic> +Delay+   +Exponential+  <Parameter> 500 </Parameter> </Stochastic>

</SimEvents>

Simulation Conditions

The simulator can recognise so called simulation conditions triggered by start and stop events or entering and exiting state sets. The presence of a condition is logged for the purpose of validation and elementary performance evaluation. As an example, consider the following conditions: 

<Executor>
% Configuration "machines.sim"
...
<Conditions>

% Event condition: Operation cycle
"Performance"     
<EventCondition>
<StartEvents>
"alpha_a"     
</StartEvents>
<StopEvents>
"beta_b"       
</StopEvents>
</EventCondition>

% State Condition: MA is idle because the buffer is full
"Bottleneck"      
<StateCondition>
+Conjunction+
<StateSet> "idle" </StateSet>  % machine a
<StateSet>        </StateSet>  % machine b (dont care)
<StateSet> "full" </StateSet>  % buffer
<StateSet>        </StateSet>  % supervisor (dont care)
</StateCondition>

</Conditions>
...
</Executor>

To monitor the long term throughput of the machine setup, we define a condition "Performance" to be enabled by alpha_a and disabled by beta_b.

The "Bottelneck" condition is characterised by machine M1 waiting while the buffer is full. This condition is expressed as a conjunctive state condition.

Hardware-in-the-Loop

The simulator can synchronise both time and events with a physical plant system that is connected via digital IO hardware or network messages. The actual mapping from executor events to physical events is done via an abstract interface implemented by the iodevice plug-in.

Hardware-in-the-loop operation is enabled by the -d filename.dev command-line option to specify the device configuration. The tutorial section of the iodevice plug-in provides examples for specific lab experiments at LRT, but also a network setup where plant and controller are simulated on different desktop PCs. See iodevice plug-in for more details.

Command-Line Options

A list of all command-line options can be retrieved by the -? option: 

$ cd ./libfaudes/plugins/simulator/tutorial
$ ./simulator -?

simfaudes: usage: 

  simfaudes [-q][-v][-i][-bc] [-bt <nnn>][-bs <nnn>] [-l <logfile>] [-ls] [-le] [-lt] <simfile> 

where 

  <simfile>: simulation configuration file

  -q:  less console output 
  -qq: absolutely no console output 
  -v:  more console output
  -vv: even more console output
  -i: interactive mode 

  -bc: break on condition
  -bt <nnn>: break on time <nnn> 
  -bs <nnn>: break on step <nnn>

  -l <logfile>: log to <logfile> 
  -ls: log states
  -le: log events
  -lt: log time
  -la: log all
  -t <nnn>: fifo trace buffer length <nnn>

  -d <devfile>: use io device configured from file
  -dt <nnn>: tolerance in time synchronisation
  -dr: accept reset request from io devive

libFAUDES 2.32b --- 2024.03.01 --- with "synthesis-observer-observability-diagnosis-hiosys-iosystem-multitasking-coordinationcontrol-timed-simulator-iodevice-luabindings-hybrid-example-pybindings"

>>