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 (SimWB) 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 in-memory 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 can be automatically created from Simulink 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.
SimWB’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.
SimWB’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. Variables can be dynamically modified for tuning during playback via SimWB's scripting language.
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 32-bit and 64-bit MathWork’s products. Models can be easily imported from Simulink using the SimWB Configuation Tool without a need for inserting hardware specific S-function blocks.
Model parameters are automatically extracted from MATLAB/Simulink Coder C/C++ and mapped into the RTDB allowing them to be modified at run-time. An extensive API also allows C, C++ and Fortran legacy-code models to be integrated directly into SimWB and executed together with Simulink models. Multi-rate execution is also supported.
SimWB 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 Swm provides full control and visibility into SIMulation Workbench test runs. Swm 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 Swm file is automatically compiled to a C executable and run once per simulation cycle.
SimWB provides a generic GUI viewer tool that can display RTDB items either as a values or as a chart plotted in real-time. Values are refreshed in real-time and time plots can be zoomed in, paused and configured as needed. The viewer can also be used to set RTDB item values. In addition, SimWB provides Windows and Linux java apps that enable a user to build custom displays including charts, gauges, knobs and image animation. These widgets allow an operator to interact with a running test in real-time. The widget set includes buttons and slider to set the values of any items defined in the RTDB.
1. Throughput and overall system performance
Concurrent iHawk multiprocessing systems running SimWB 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 SimWB, 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.
SimWB recognizes and utilizes multiple cores by default and there is no limit on the number of cores than can be used by SimWB.
2. I/O handling
In SimWB, 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 SimWB configurations. Concurrent iHawk systems can be configured with thousands of hardware I/O points.
4. Parallel processing
SimWB 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
SimWB 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 SimWB 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 SimWB 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

Model can be easily imported to SimWB directly from Simulink.
Click image above to view larger

SimWB allows point and click connection of RTDB variables to I/O points.
Click image above to view larger

Click image above to view larger

Click image above to view larger