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 as a distributed where the data logger run 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 inputs: acquire hardware inputs, convert them to engineering units and store values in the RTDB. Script program run. Model program run. This sub cycle can itself be divided into multiple cycle when running multiple models whose execution is chained. Hardware outputs: 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.
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 resided 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 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 programs that map the CVT to fail. A valid ‘C’ identifier is defined by the following regular expression: ^[a-zA-Z_][a-zA-Z_0-9]*