SIMulation Workbench Architecture

SIMulation Workbench can be configured either as monolithic system where both the real-time simulation applications and the data logger reside on the same host or in a distributed configuration where the data logger runs on a separate dedicated system. The system can thus be thought of as 2 logical systems. The simulation software runs on two logical systems interconnected via a TCP connection. The first system – the real-time host – hosts the real-time database and runs the MATLAB models while the second system serves as a data repository for test configuration data as well as logged data collected during a test run.

Real-Time Host

The real-time system hosts the memory resident real-time database (RTDB) and runs the data input and output tasks as well as the MATLAB RTW and user (Script) programs. The simulation programs run in a continuous loop divided into sub cycles where each sub cycle is scheduled to execute exclusive of the others to avoid interference with one another and avoid the need to acquire locks on RTDB items. The four main sub cycles of executions are as follows:

Hardware input: acquire hardware inputs, convert them to engineering units and store values in the RTDB.
Test Script program run. Test scripts can be written in C, C++, python or SimWB SWM macro language.
Model program execution. This sub cycle can itself be divided into multiple cycles when running multiple models whose execution is chained.
Hardware output: extract data values from the RTDB, convert from engineering units to raw value and generate hardware values.

The main loop is dispatched by Concurrent Frequency Based Scheduler connected to a hardware timer on the RCIM® board. The sub cycles are executed sequentially where a sub cycle must wait for the preceding step to finish execution before it can run. In addition to the software executing synchronously during the simulation loop, some processes run asynchronously to read inputs and write outputs to devices that are too slow to run at the speed of the simulation loop. Such devices include AFDX , ARINC 429, CAN I/O, 1553 I/O,etc.

SIMUlation Workbench Real-time Loop

The simulation cycle can also be represented in time as the following figure:

Real-time memory resident database (RTDB)

The real-time database referred to as RTDB in this document is the main memory resident repository of all the parameters necessary to define every single signal and run a simulation. It is a memory resident implementation consisting of a collection of records designed to maximize access and conversion speed.

The real-time database contains the information needed to read, convert, write and store the simulation variables. For hardware data points, the RTDB also holds the information necessary to map points to hardware devices. The mapping information is specific to each type of hardware device. The RTDB also contains engineering unit conversion for analog values, override flags, values and raw unit values.

The real-time database is organized across several structures or arrays which in its totality we refer to as the RTDB. Those structures play different roles when a program wants to access or update a RTDB item. Each individual record within the RTDB is referred to in this document as a ‘point’ or an ‘item’.

The RTDB is organized as a dictionary where a main index – the hash table – points almost directly (via a hash function) to any individual item within the RTDB. The RTDB record itself holds specific item information such as the item meta data, item alternate and CVT values and pointers to other item information that cannot be included in the RTDB record. Each item defined in the RTDB has a value in the CVT , an alternate value and a real-time flag. These are the three main components of the RTDB as a whole, meta data, hash table and current value table (CVT).

Meta data

Holds information about each data item but not the data value directly.

Hardware mapping information
Engineering units conversion factors
Engineering unit text.
Maximum and minimum engineering unit values.
Point description
Point Type
‘C’ type
Raw value type
Offset into CVT (Current Value Table). Meta flags
Default value

Data access hash table

This memory resident table is the main index into the RTDB collection of records. The index corresponding to a specific RTDB record is calculated as a hash function on the item name and gives the position of the item in the contiguous array of RTDB items.

Current Value Table (CVT)

The CVT is a contiguous area of memory containing EU values for RTDB items. This area of memory can thus be mapped as a ‘C” structure by multiple processes to gain direct access into real time data base values without knowledge about the structure of the real-time data base and with no need for a special API to set/get values. This ‘C’ structure is automatically mapped within the RTW model address space. The header file corresponding to this ‘C’ structure is created automatically when saving the RTDB from the GUI. All RTDB header files reside in the /usr/local/ccursim/include/rtdb_cvt/ directory where they are included by the RTW model at compile time. The CVT is also mapped into user processes by calling the appropriate SimWB API functions such as ccurRTDB_mapDB(). The initialization of the model is done within the ccurrt_mainC.c source file which initializes access to the RTDB and hooks into the SimWB scheduler. When creating a RTW model that will run by SimWB, a Makefile necessary to compile and link the application is also generated using the Simulink/RTW template makefile mechanism. At initialization time, the RTW main() function will map the program global variables into the CVT shared memory segment. This shared memory segment is also accessible using the RTDB access API functions to set and get the values of variables.

Note: the names of the RTDB items must be valid ‘C’ language identifiers. Invalid ‘C’ identifiers will cause the compilation of any program that includes the CVT to fail.

A valid ‘C’ identifier is defined by the following regular expression: ^[a-zA-Z_][a-zA-Z_0-9]*

RTDB CVT Values & Alternate Values

Every RTDB item is associated with 2 values: CVT value which is the value that can be directly accessed from user programs or models. This is the value that should be used as input by models and user process. This should always be the value produced as output by models and user processes. Alternate values: this is used as a transparent mechanism to override inputs to the models and override the output produced by the models. The source of the data can changed without the model needing to be aware of it. This can be used as a fault injection mechanism to check the response of the unit under test under faulty conditions. This way, the model does not have to be programmed to handle bad conditions and can be a true representation of the physical system. A run time flag is associated with every RTDB item. This flag keeps track of whether the CVT or Alternate value is in use at the moment. Two bits in the flag signal the following: Alternate; the CVT value has been overridden by the alternate. Operator entry; the CVT value has been overridden by a value set by the operator. The meaning of the real-time flag alternate/operator entry bit is different based on whether the RTDB Item is an input or an output. The real-time flag is used by the I/O task to decide where to place the hardware value read from the I/O device, and what value should be written to the device by the output task.

See also this tutorial about CVT/ALT value concept.

SIMulation Workbench scheduler

The SimWB scheduler initiates, monitors and dispatches the execution of one or more models/processes. Models and/or processes are executed according to their run position in the simulation loop. The scheduler itself runs cyclically and its execution can be dispatched through several mechanisms:

RCIM RTC interrupt via the Concurrent FBS
RCIM ETI interrupt via FBS
Internal OS timer.
FBS external FBS configuration to which it can attach itself.
SimWB Red Line scheduler.

The scheduler is started by the cfgsrv process when the user wants to a run a test. It gets the test and session name as command line arguments. The scheduler always runs on cpu 1 with a priority of 99 in the fifo scheduling class.

According to the resources defined for the specific test run, the scheduler will: Load the specified RTDB from disk into memory, reads and parses the files that define the RTDB configuration and creates the corresponding shared memory regions. From the RTDB records, determine what I/O processes need to be launched, start the optional script and model processes, build the sequence of execution for the processes according to their type (input, output, models, script)‏ and Initiates the cyclical simulation loop. Upon completion of each cycle, the scheduler checks that all the processes that are last to run in the cycle, If any process has not completed execution, and an overrun is signaled.

Scheduler pre and post processes can be optionally written by the user. Those processes can be written in any programming language, C, perl,etc.

SIMulation Workbench Data Logging

Each individual item defined in the RTDB can be logged at a configurable period. Whether an item is logged and at what period it should be logged is defined in the RTDB.Whenever the CVT value, alternate value or real-time flag associated with the item changes, the item is placed in a data logger record for the specific fame under execution. A record in the binary data file consists of a fixed length header followed by a collection of value fields, one field for every RTDB item that has a value in the record. The following data is recorded per item:

*CVT value

*Alternate value

*Raw value

*Real-time flag (1 byte)‏

The CVT and alternate value are logged under the format in which they are defined in the RTDB, i.e. double, float, int, etc. The length of the value field in the record is thus variable based on the item data type. For a double item with an int raw type, the value field would then be:

2*8+4+1 = 21 bytes

The fixed length header is a bitmask indicating that a specific item has a value in the record.

The SimWB data logging subsystem is a client/server architecture. The real-time host builds records of item value change at the frame rate of the simulation loop. Those records are sent to the data logging server process (logsrv) via a network connection. This means that the logsrv can run on a separate system. This is important for system where the data logging load is so heavy that it can impact the real-time performance of the SimWB core real-time host. Depending on the amount of data you log, the speed at which you log and the frequency of change in values of the items, the load can be significant. For instance, if your simulation runs at 1 millisecond and you want to log 2000 RTDB items that change at every frame, you will generate: 21*2000*1000 = 42 MB/s SimWB has achieved in a separate data logger system configuration sustained rate of around 250 MB/s. This requires RAID subsystem that can maintain that rate.

I/O Tasks

Synchronous I/O tasks

SimWB I/O tasks handle the specifics of talking to a hardware device. By keeping the separation between I/O tasks, Models and Scripts, the user can write his/her application models and scripts transparently. The peculiarities of the hardware devices connected to the system will not affect his/her application. This independence also allows for the RTDB items to be remapped to different hardware devices without affecting the models and scripts running under SimWB. I/O tasks are divided in two classes according to the hardware they drive.

Synchronous: when the device is fast enough to be driven at the speed of the simulation loop.
Asynchronous: when the device is asynchronous by nature and the device natural speed essentially drives the I/O task.

Synchronous I/O tasks run at the speed of the simulation loop. They run once per simulation cycle. Their run time behavior must be deterministic so that their execution time is constrained within known limits and do not cause the simulation loop to overrun. Synchronous I/O tasks typically read/write all their device inputs/outputs once per cycle. Synchronous I/O tasks are divided into input and output tasks since those run during different sub cycles of the simulation loop. This can be a problem when a synchronous I/O device supports both input and output functionalities since as per the SimWB model, those must be implemented by two separate and independent processes.

In SimWB, every synchronous I/O task is implemented so that it will drive a single board of a particular type. For a configuration where multiple instances of the same hardware board -i.e. AI64LL,DIO96 - exist in the system, multiple instances of the I/O task are run. Each instance will run on a designated CPU according to the SimWB configuration. This allows optimization of CPU and I/O bus bandwidth as access to the deviced can occur in parallel. In the default configuration provided through the SimWB installation, every synchronous I/O task will run at priority 99 under the fifo scheduling class.

I/O tasks are programmed so that they minimize use of blocking system calls and thus are not pre-empted by the OS. This limits the overhead of context switch and thus reduces execution time for the tasks. By running at priority 99, we ensure that the task will run its cycle in one short run without being interrupted by the OS or any other tasks running at a higher priority.

Asynchronous I/O tasks

Asynchronous I/O tasks run at the speed of the device they handle. The execution rate of the task is determined by the device and is typically completely asynchronous from the SimWB simulation loop. Examples of asynchronous devices are:

Serial
1553
AFDX
ARINC 429
CAN
FlexRay

In SimWB, most asynchronous I/O tasks are implemented as multi threaded processes where separate threads are used for input and output. This is device dependent and the design of an asynchronous I/O task is usually predicated by the functionality of the device. Even though asynchronous I/O tasks are driven by their respective device, the consistency of the RTDB must be maintained. They cannot update the RTDB at random as this could cause a model or script to work with two different values for the same RTDB item. The same applies to the output. They need to be gathered in one shot during the output cycle so that only one value of a particular output item will be used at a particular time. For this purpose, all asynchronous I/O tasks queue their RTDB updates through a SimWB async I/O input FIFO. The FIFO is processed during the simulation loop input sub cycle. See the following diagram for a representation of an asynchronous I/O task implementation.