Real-time simulation platforms often appear similar when compared through feature lists. Many support common modeling tools, physical I/O, multicore processors, test automation, and data recording.

The important differences emerge when those capabilities are combined in a complete test configuration.

A platform may support a particular model format but struggle with the model’s required execution rate. It may offer a large I/O catalog while tightly coupling channel assignments to model code. It may record data successfully until logging is enabled alongside the full real-time workload.

An effective evaluation should therefore begin with the engineering requirements of the intended test not with a general product demonstration.

Figure 1. The 11-point framework this article walks through, area by area.

Start by Defining the Simulation Workload

Before comparing platforms, document what the system will need to execute and connect.

The initial workload definition should include:

• Model sources and formats
• Model sizes and computational requirements
• Base simulation period
• Additional sample rates
• Data dependencies among models
• Physical I/O types and channel counts
• Communication buses and message rates
• Connected controllers or hardware
• Fault-injection requirements
• Data-recording rates
• Test-automation requirements
• Visualization and operator interfaces
• Expected program lifecycle
• Anticipated model and I/O growth

Requirements should distinguish between what is needed now and what the program is likely to require later.

A platform sized only for the first model and initial channel count may become difficult to extend when the simulation grows.

Figure 2. Document the workload , now and later, before comparing platforms at all.

1. Evaluate Deterministic Timing

The first question is whether the complete simulation can meet its deadlines consistently.

Processor speed and average model execution time provide only partial information. The evaluation should also examine:

• Maximum observed model execution time
• Complete simulation-frame time
• Timing variation between frames
• Deadline overruns
• Available processing headroom
• Interrupt activity
• Effects of operating-system workloads
• Behavior with logging and visualization enabled
• Timing under demanding model paths
• Behavior when multiple rate groups coincide

Ask how the platform detects and records overruns. A missed deadline should not remain hidden while the test continues producing apparently valid data.

The evaluation should use the intended target hardware and a representative configuration. Results from a small demonstration model or unloaded system may not predict the behavior of the production test.

Why Deterministic Timing Matters in Real-Time Simulation explains why average speed is not equivalent to deterministic execution.

2. Examine Scheduling and Multirate Support

Complex simulations frequently contain models that operate at different rates. The platform must coordinate those rates while preserving data dependencies and execution order.

Questions to ask include:

• Can models run at different scheduled frequencies?
• How is the base simulation period defined?
• Must slower rates be integer multiples of the base period?
• How are multiple rate groups represented?
• Can rate groups be assigned to different processor cores?
• When do values transfer between rates?
• How are same-cycle dependencies enforced?
• What happens when a task misses its deadline?
• Can execution order be inspected and controlled?
• How are the busiest rate alignments measured?

A platform may advertise multirate support without providing enough visibility into how the rates interact.

The evaluation should include a cycle in which several rate groups execute together. That cycle may have a substantially higher workload than the average frame.

For a deeper discussion, see How Multirate Real-Time Simulation Works.

3. Test Model Integration, Not Just Format Compatibility

A list of supported modeling tools does not establish that the intended models can run on the real-time target.

The evaluation should use representative models from the actual program, including:

• Simulink-generated models
• FMI-compatible FMUs
• Custom C, C++, or Fortran models
• Supplier-delivered binary models
• Models with multiple sample rates
• Models requiring external libraries
• Models containing significant initialization data
• Models with protected intellectual property

For each model, verify:

• Target compatibility
• Solver and fixed-step requirements
• Input and output definitions
• Parameter handling
• Initialization and reset behavior
• External dependencies
• Maximum execution time
• Error reporting
• Data-type and unit handling
• Model-version management

FMU compatibility requires particular care. The FMI version, FMU type, included binaries, internal solver, and runtime dependencies can affect whether the model is suitable for the target.

Integrating Simulink, FMUs, and Custom Models into a Real-Time Simulation Environment provides a more complete model-integration checklist.

4. Review the Model and I/O Architecture

Determine whether models communicate directly with physical hardware or through a separate data and mapping layer.

Embedding board identifiers, channel numbers, device APIs, and conversions in model code can make the system difficult to maintain. Replacing an I/O device may then require model changes even when the simulated behavior remains the same.

A separated architecture should allow:

• Models to use named engineering variables
• I/O processes to manage physical devices
• Configuration to map variables to channels
• Scaling and unit conversions to be controlled
• Models to be reused with different I/O configurations
• Hardware changes to be tested without unnecessary model modification
• Scripts and logging tools to access shared simulation data

Ask to change a channel assignment or supported I/O configuration during the evaluation. Observe whether the change requires editing and rebuilding the model.

The architectural issues are covered in Why HIL Simulation Models Should Be Independent of the I/O Configuration.

5. Evaluate Synchronous and Asynchronous I/O

Not every device should operate in the same part of the simulation schedule.

Fast closed-loop signals may need to execute synchronously with the models. Communication buses and independently timed devices may need asynchronous processing outside the critical loop.

The platform should define:

• Which I/O tasks run inside the simulation loop
• When synchronous inputs are acquired
• When synchronous outputs are written
• How asynchronous messages enter the simulation
• How data is buffered
• When new asynchronous values become visible
• How stale or missing data is identified
• What happens when a queue overflows
• Whether custom I/O tasks can be added
• How I/O execution time is measured

An asynchronous device should not be allowed to alter model-facing data at an uncontrolled point during execution.

Similarly, a synchronous device should not block the simulation loop while waiting indefinitely for data.

The distinction is examined in Synchronous vs. Asynchronous I/O in Real-Time Simulation.

6. Determine How the Platform Uses Multiple CPU Cores

A large core count does not guarantee that a simulation workload will scale.

The platform must provide mechanisms for assigning models, rate groups, I/O tasks, and support processes to appropriate processor resources.

Evaluate:

• CPU affinity
• CPU shielding or isolation
• Interrupt routing
• Placement of operating-system activity
• Support for multithreaded models
• Assignment of discrete rate groups
• Synchronization between cores
• Visibility into per-core execution
• Memory and NUMA placement
• Treatment of logical processors
• Processing headroom

Ask the supplier or integration team to explain the proposed processor map for the intended workload.

The explanation should identify which tasks can run concurrently, which must execute in order, and which resources remain available for operating-system services, logging, networking, and future growth.

Scaling Real-Time Simulation Across Multiple CPU Cores discusses these considerations in more detail.

7. Review Test Automation and Data Handling

A simulation platform should support repeatable test execution and preserve enough information to diagnose unexpected results.

Automation capabilities may include:

• Test scripting
• Programmatic APIs
• Initial-condition management
• Parameter control
• Fault injection
• State- and time-based actions
• Readiness checks
• Timeouts
• Automatic cleanup
• Pass/fail evaluation
• Batch or regression execution

Data capabilities should include:

• Selection of recorded signals
• Appropriate recording rates
• Time correlation
• Engineering-unit handling
• Timing and overrun information
• Result export
• Post-test visualization
• Playback or frame-by-frame review
• Association of results with the test configuration

Evaluate logging with the complete workload active. Recording a high number of signals at fast rates may affect processor, storage, memory, or network resources.

The platform should also preserve or identify the model versions, I/O mappings, scripts, parameters, and initial conditions associated with each test.

For additional guidance, see HIL Test Automation: Scripting, Data Logging, and Playback.

8. Consider Development and Deployment Workflow

Not every development activity needs to occur on the real-time target.

A useful workflow may allow engineers to prepare models, verify interfaces, develop scripts, and perform functional tests on ordinary workstations before using the target for deterministic timing and physical I/O validation.

Evaluate:

• Where models are developed and compiled
• Whether functional testing can occur off-target
• How configurations move between environments
• Whether interfaces remain consistent
• How platform-specific dependencies are identified
• How target artifacts are versioned
• Whether numerical comparisons can be repeated after deployment
• How distributed teams access the development environment

A Windows-based workflow can reduce target contention, but it should not be presented as evidence of real-time performance.

Developing HIL Models on Windows Before Real-Time Deployment explains which activities can move off-target and which must remain on the real-time system.

9. Examine Configuration and Version Control

A repeatable test includes more than the model binaries.

The platform should make it possible to identify or preserve:

• Model versions
• I/O mappings
• Simulation data definitions
• Initial conditions
• Parameter sets
• Test scripts
• Scheduler settings
• CPU assignments
• Data-logging definitions
• Driver versions
• Platform software versions
• Hardware configuration

Ask how configurations are exported, compared, backed up, restored, and moved between test systems.

If important settings exist only within an undocumented graphical interface, change review and long-term maintenance can become difficult.

Readable or exportable configuration formats can make version control easier, but the complete workflow should be demonstrated rather than assumed.

10. Plan for Lifecycle and Hardware Changes

A HIL system may remain in use far longer than the processor, I/O card, compiler, or modeling tool originally selected for it.

Lifecycle questions include:

• How are software releases supported?
• What is the upgrade process?
• Can older models run on newer hardware?
• What happens when an I/O board becomes obsolete?
• Can models be moved without rewriting hardware-specific code?
• How are driver changes handled?
• Are configuration migrations documented?
• Can the platform support mixed legacy and current models?
• What training and technical documentation are available?
• Can the supplier support custom integration work?

The least expensive initial configuration may not have the lowest lifecycle cost if every hardware change requires extensive model redevelopment.

11. Evaluate Openness and Extension Points

No simulation platform will include every model interface, device, or analysis tool required by every program.

The evaluation should determine how the system can be extended.

Relevant capabilities include:

• APIs
• Custom model interfaces
• Custom I/O tasks or drivers
• Scriptable test control
• Standard model formats
• Data export
• External visualization
• Integration with analysis tools
• Support for customer-developed code
• Access to configuration data

“Open” can mean different things, so ask for a specific demonstration.

For example:

• Add a simple custom model.
• Connect an unsupported data source.
• Export recorded data.
• Control a test through an external script.
• Change an I/O mapping.
• Add a new calculated data item.

The time and engineering effort required are more informative than a general claim of extensibility.

Build a Representative Proof of Concept

A proof of concept should resemble the intended application closely enough to expose architectural constraints.

Include:

• At least one representative high-rate model
• Multiple sample rates
• Realistic model dependencies
• Representative physical I/O
• Communication traffic
• Test scripting
• Fault injection
• Data logging
• Visualization
• A demanding computational condition
• A defined overrun policy

Establish acceptance criteria before running the test.

Example criteria might include:

• Every scheduled task meets its deadline.
• No unacknowledged overruns occur.
• Model results match an accepted numerical reference.
• Required I/O updates occur at the intended points.
• Logging does not cause timing failure.
• The configuration can be saved and reproduced.
• A model or I/O mapping can be changed without unnecessary redevelopment.
• A failed test produces sufficient diagnostic data.

A polished demonstration using an unrelated model is not a substitute for a representative proof of concept.

Use a Weighted Evaluation Matrix

Not every capability has equal importance.

A simple evaluation structure can assign each requirement a weight and evidence level.

Evaluation area	Example weight	Evidence
Deterministic timing	20%	Measured on representative target workload
Model integration	15%	Program models imported and executed
I/O architecture	15%	Required interfaces tested
Multirate scheduling	10%	Rate alignment and dependencies demonstrated
Multicore scaling	10%	Processor map and timing measurements reviewed
Automation and logging	10%	Representative scripted test completed
Development workflow	5%	Configuration moved from development to target
Extensibility	5%	Custom integration demonstrated
Lifecycle and support	10%	Upgrade and obsolescence plan reviewed

The weights should reflect the program. A training simulator, controller-development bench, and certification-oriented system may prioritize different criteria.

Score evidence separately from claimed support. A capability demonstrated with the intended workload should receive greater confidence than one described only in documentation.

Figure 3. Weight each evaluation area by what matters for the program, and score evidence, not claims.

Common Evaluation Mistakes

Selecting based on processor specifications

Processor frequency and core count do not describe scheduling, isolation, I/O behavior, or model dependencies.

Testing only a small demonstration model

A minimal model may not expose memory contention, rate alignment, logging load, or synchronization problems.

Treating tool compatibility as completed integration

A supported file type may still require solver changes, libraries, code generation, or target-specific validation.

Ignoring the complete I/O path

Timing includes acquisition, conversions, model execution, output generation, and device behavior.

Measuring average performance only

Occasional deadline misses can matter even when the average execution time is low.

Excluding logging and visualization from timing tests

Support processes can change the behavior of the complete configuration.

Ignoring lifecycle requirements

Model and hardware maintenance can exceed the cost and effort of the initial installation.

Evaluating only the graphical interface

Usability matters, but it does not replace evidence of deterministic execution, model portability, or system extensibility.

Applying the Evaluation to SIMulation Workbench

SIMulation Workbench provides an architecture built around scheduled model execution, independent I/O tasks, a memory-resident real-time database, test scripting, data recording, and playback.

Models and I/O processes can exchange data through the RTDB rather than requiring direct model-to-device connections. SimWB supports multiple model sources, multirate execution, processor-core assignment, synchronous and asynchronous I/O, and programmatic test control.

It runs on Concurrent Real-Time’s RedHawk Linux platform for deterministic real-time execution. SIMulation Workbench on Windows provides a supporting environment for model preparation and functional development before target deployment.

These architectural capabilities should still be evaluated against the intended models, I/O, deadlines, and test workflow. The most useful next step is a representative configuration with clearly defined acceptance criteria not an assumption that general product support guarantees application fit.

Real-Time Simulation Platform Evaluation Checklist

Before selecting a platform, confirm that it can demonstrate:

• Representative models running on the intended target
• Required base and multirate schedules
• Measured maximum execution behavior
• Overrun detection and reporting
• Adequate processing headroom
• Controlled CPU and interrupt assignment
• Model-to-I/O separation
• Required synchronous and asynchronous I/O
• Support for target model formats and dependencies
• Repeatable test scripting
• Data logging under full load
• Configuration and result traceability
• Development-to-target deployment
• Extension through documented interfaces
• A credible lifecycle and upgrade path

Conclusion

Choosing a real-time simulation platform requires more than comparing model-format lists, I/O catalogs, or processor specifications.

The platform must execute the intended models within their deadlines, coordinate different rates, exchange data with physical hardware, record useful evidence, and remain maintainable as the test system changes.

The strongest evaluation uses representative workloads and predefined acceptance criteria. It measures the complete system with models, I/O, scripts, logging, and support applications operating together.

For a deeper architectural guide and a reusable evaluation checklist, download Designing Scalable, Deterministic X-in-the-Loop Simulation Environments.

Frequently Asked Questions