Looking for fingertip control of your complex simulations? Need to easily remap your I/O without changing your Simulink model? Looking for fast access to simulation data? Concurrent’s SIMulation Workbench is the answer. SIMulation Workbench provides a complete framework to develop and execute realtime hardware-in-the-loop and man-in-the-loop simulations.
SIMulation Workbench’s powerful GUI allows users to conveniently configure, start, stop, record and play back simulation runs. SIMulation Workbench provides fast, direct shared memory access to all parameters and signals needed by your simulation. SIMulation Workbench’s inmemory design optimizes performance and data conversion speed.
SIMulation Workbench is built upon a client-server architecture. A real-time server provides the run-time environment for simulation while network-based GUI clients control and display simulation activities. Realtime performance is maximized because the GUI clients run outside of the simulation server.
At the heart of SIMulation Workbench is a memory-resident database called RTDB that can be accessed by all simulator processes. RTDB stores the definition of all data items used by the simulation such as model variables and their mapping to I/O boards and model parameters. RTDB is configured externally via a GUI and provides for complete I/O independence. All the information necessary to configure I/O points and data bus protocols and to read, convert, write and store simulation variables is maintained in the database.
RTDB is organized as a dictionary where a main hash table index points directly to any individual item within the database. Values can be stored as any C language scalar type such as char, unsigned char, short, int, float, double, etc. RTDB also contains the engineering unit conversions for analog values, override flags, values, alternate values as well as raw unit values. If I/O points need to be reassigned, GUI panels provide convenient, model-independent remapping.
SWB’s powerful Data Recorder tool allows simulation data points to be logged individually and independently at the rate they are produced. Hardware and engineering values, as well as run-time flags and time stamps, can be recorded. Depending on the performance required, data recording can be run on the real-time host or on a separate networked server. Data recording can be turned on and off during simulation runs by GUI command, real-time script or user program.
SWB’s Playback tool allows recorded test runs to be replayed into the system. The user selects the recorded session and simply starts a test run in playback mode.
Playback of recorded test runs is an alternate mechanism for storing data values into the RTDB. Instead of the data values being acquired from hardware, they are read from recorded files. Similarly, output variables that have been recorded override the outputs computed by the models. During a playback session, values for the data items that have not been recorded can be read from hardware as in a normal session run.
The playback interface allows a user to forward to a specified time within a recorded session as well as stepping through its execution frame-by-frame.
SIMulation Workbench fully supports simulation models developed using The MathWorks’ products. MATLAB/Simulink models can be integrated seamlessly into the SWB environment using Real-Time Workshop (RTW) and S-functions to the RTDB. Simulink model parameters are automatically extracted from the RTW model and mapped into the RTDB so they can be changed at run-time. An extensive API also allows C, C++ and Fortran legacy-code models to be integrated directly into SWB and executed together with Simulink models. Multi-rate execution is also supported.
SWB is fully supported on Concurrent iHawk™ multiprocessor platforms running RedHawk Linux. Simulation models are scheduled using RedHawk’s Frequency Based Scheduler (FBS) under control of the iHawk’s Real-Time Clock & Interrupt Module hardware (PCI) card. All I/O devices and Linux drivers required for your simulation are available directly from Concurrent.
Users can assign models to different system CPUs to achieve parallel execution. RedHawk Linux shielding features can also be used to guarantee real-time response by dedicating a CPU to a process.
An easy-to-use scripting language called SWBscript provides full control and visibility into SIMulation Workbench test runs. SWBscript gives the user real-time access to simulation model data values as well as frame timing information and data recording functions. Users can directly read and modify data, test for logical conditions, trace their test execution and generate a complete HTML report of a test run. An SWBscript file is automatically compiled to a C executable and run once per simulation cycle.
SWB’s data browsing tool allows the value of all RTDB items to be viewed and plotted in real-time. This tool also provides a basic GUI to modify RTDB values. Visualization into real-time execution can be extended by designing custom user interfaces using industry standard National Instruments’ LabVIEW virtual instruments.
1. Throughput and overall system performance
Concurrent iHawk multiprocessing systems running SIMulation Workbench are based on COTS components offering the latest, leading-edge processor, chipset, memory and I/O bus technology. Solutions that use proprietary hardware are slow in comparison to Concurrent’s latest available COTS-based systems.
With SIMulation Workbench, individual I/O processes can be targeted to different system cores and I/O buses for parallel execution, thus allowing the simulation loop to run at faster frame rates. Without the ability to run I/O on different cores, I/O processing becomes serialized thus extending execution time of the simulation loop.
SIMulation Workbench recognizes and utilizes multiple cores by default and there is no limit on the number of cores than can be used by SIMulation Workbench.
2. I/O handling
In SIMulation Workbench, all I/O is performed by processes outside of the Simulink models, thus allowing the models to be independent of the intricacies and specific behavior of the I/O devices. This provides flexibility and makes it easy to remap I/O when necessary. In other HIL solutions, I/O is implemented via Simulink S-functions that are embedded within the Simulink model. They are, for all intents and purposes, part of the model.
3. I/O limits
There are no practical limits on SIMulation Workbench configurations. Concurrent iHawk systems can be configured with thousands of hardware I/O points.
4. Parallel processing
SIMulation Workbench provides multi-model support where individual models can be targeted to separate CPU cores for parallel and faster execution.
5. Ease of system upgrade as requirements change
SIMulation Workbench operates with minimal Simulink-specific dependencies. This allows it to support new MATLAB/Simulink releases with little effort. Because the bridge to Simulink is via the Real Time Database, there are only a handful of S-functions to port and/or test against new MATLAB/Simulink releases. Other HIL solutions must port and/or test all of their I/O S-functions for all their supported devices before they support a new MATLAB/Simulink release.
6. Platform independence
Concurrent’s iHawk platforms running RedHawk Linux and SIMulation Workbench are open architecture systems. Simulink models that run on Concurrent systems can also be made to run on other systems with minimal effort. Concurrent’s SIMulation Workbench solutions also support both Linux and Windows client platforms. The use of HIL blocks in the creation of the model environment allows I/O to be run independently of specific hardware platforms.
Click image above to view larger
Click image above to view larger
Click image above to view larger