Real-time simulation systems are specialized resources. They may contain target-specific processors, physical I/O, connected controllers, and laboratory equipment shared among multiple engineering teams.

Requiring access to that complete system for every model change can slow development. Engineers may spend valuable target time correcting variable definitions, resolving dependencies, adjusting initial conditions, or fixing model logic that could have been tested elsewhere.

A Windows-based development environment can move many of those activities off the real-time target. Engineers can prepare models, verify interfaces, exercise test logic, and identify functional problems using their regular workstations.

The Windows environment does not replace the real-time Linux system. Deterministic timing, physical I/O behavior, processor allocation, and complete closed-loop performance must still be validated on the intended target.

The objective is to use each environment for the work it can evaluate reliably.

Why Move Early Simulation Work Off the Target?

A real-time HIL system may be needed by model developers, test engineers, hardware teams, controller developers, and integration groups.

If every change requires deployment to the target, development can become constrained by:

• Limited laboratory availability
• Scheduling conflicts
• Remote-access requirements
• Lengthy deployment procedures
• Dependence on connected hardware
• Difficulty isolating model problems from I/O problems
• Risk of disrupting an active test configuration
• Limited access for distributed engineering teams

Many early model-integration problems do not require deterministic execution or physical hardware to diagnose.

Examples include:

• Missing model dependencies
• Incorrect variable names
• Unit or data-type mismatches
• Invalid parameter values
• Initialization failures
• Model build errors
• Script syntax problems
• Incorrect test sequences
• Unexpected model-state transitions
• Basic numerical differences

Finding these problems before target deployment preserves the real-time system for work that genuinely requires it.

What Can Be Tested on Windows?

A Windows-based simulation environment can support several useful development activities.

Model preparation

Engineers can import, configure, and prepare models before deployment. Depending on the supported toolchain, this may include generated Simulink models, FMI-compatible FMUs, and custom compiled models.

Interface verification

Model inputs, outputs, parameters, data types, units, and initial values can be reviewed before the model is connected to physical I/O.

Functional model testing

Known input sequences can be applied to confirm that the model initializes and produces expected outputs.

Multi-model integration

Models can be connected through a common data interface to identify naming, dependency, initialization, and execution-order problems.

Script development

Test scripts can be developed and checked for basic sequence behavior, conditions, timeouts, cleanup, and error handling.

Configuration preparation

Engineers can define model sets, data items, parameters, initial conditions, and test-session settings before moving the configuration to the target.

Data visualization

Model values can be observed and plotted during functional testing to help identify integration or numerical problems.

These activities reduce avoidable target iterations, but their results must be interpreted within the limits of the Windows environment.

What Cannot Be Established on a Non-Real-Time Windows System?

A functional test on Windows cannot demonstrate that the model will meet its real-time deadlines on the target.

The Windows environment does not reproduce all characteristics of a Redhawk Linux real-time system, including:

• Real-time scheduling behavior
• CPU shielding
• Controlled interrupt routing
• Target-specific processor topology
• Physical I/O execution
• Complete device-driver behavior
• Target memory and cache effects
• Worst-case model execution time
• Real-time synchronization among models and I/O
• Timing under the full HIL workload

A model may run successfully on Windows while missing deadlines on the target. Conversely, a model may appear to run slowly on a development workstation but meet its requirements after being compiled, configured, and isolated on the target system.

Functional performance on Windows should not be treated as a real-time benchmark.

Functional Validation and Real-Time Validation

The division of work can be summarized as follows:

Validation activity	Windows development environment	Real-time Linux target
Model imports and initializes	Yes	Confirm again
Inputs and outputs are defined	Yes	Confirm deployed mapping
Basic numerical behavior	Yes	Compare after deployment
Script logic and cleanup	Yes	Confirm with target hardware
Model-to-model data flow	Yes	Confirm scheduling behavior
Physical I/O integration	Limited or representative only	Required
Maximum execution time	Not authoritative	Required
Jitter and overruns	Not authoritative	Required
CPU affinity and shielding	Not representative	Required
Closed-loop timing	Not representative	Required
Complete system validation	No	Required

The Windows environment should reduce uncertainty before deployment. It should not be used to waive target testing.

Windows Subsystem for Linux and Real-Time Simulation

Windows Subsystem for Linux 2, or WSL2, provides a Linux environment within Windows. This can make it easier to use Linux-oriented simulation components and development workflows from a Windows workstation.

However, WSL2 is not RedHawk Linux and should not be treated as a deterministic real-time target.

The operating-system kernel, scheduler, virtualization layer, interrupt behavior, hardware access, and processor controls differ. A model running under WSL2 is still subject to the timing behavior of the Windows host and its virtualized Linux environment.

WSL2 can provide a compatible development workflow without providing equivalent real-time execution behavior.

A Practical Development-to-Deployment Workflow

A controlled workflow helps prevent differences between the Windows and target environments from becoming integration problems.

1. Define the target requirements

Before model development begins, identify:

• Required sample rates
• Supported model formats
• Target processor architecture
• Operating-system and software versions
• Compiler requirements
• Physical I/O interfaces
• Expected data dependencies
• Timing deadlines
• Logging requirements

The development environment should be configured with the target in mind.

2. Develop or import the model

Create the model in Simulink, package or receive the FMU, or prepare the custom source code and libraries.

Document the model’s inputs, outputs, units, parameters, sample times, initialization behavior, and dependencies.

3. Integrate the model on Windows

Add the model to the development simulation and connect it to the shared data interface.

Confirm that:

• The model loads correctly.
• Required libraries are available.
• Variables and parameters are visible.
• Initial conditions are accepted.
• Model-to-model data exchanges work.
• Errors are reported clearly.

4. Compare against reference results

Run known inputs and compare the results with the originating modeling environment or another validated reference.

Differences may indicate problems with:

• Code generation
• Solver configuration
• Step size
• Data types
• Units
• Initialization
• Compiler behavior
• External dependencies

5. Develop test scripts and configurations

Create reusable test sequences, parameter sets, logging definitions, and initial conditions.

As described in HIL Test Automation: Scripting, Data Logging, and Playback, scripts should include readiness checks, timeouts, diagnostic messages, and cleanup behavior.

6. Package the controlled artifacts

Identify the exact versions of:

• Models
• Source code
• FMUs
• Libraries
• Parameters
• Scripts
• Data definitions
• Configuration files
• Build tools
• Generated artifacts

Avoid deploying an untracked collection of files from a developer’s workstation.

7. Deploy to the real-time target

Move the controlled configuration to the RedHawk Linux system. Resolve any target-specific build, library, path, permission, or architecture differences.

8. Repeat numerical validation

Run the same known input cases used during Windows development and compare the target outputs.

This helps separate deployment changes from subsequent timing and I/O problems.

9. Validate real-time behavior

Measure:

• Model execution time
• Complete frame time
• Timing variation
• Deadline overruns
• Processor-core utilization
• Synchronization delays
• Logging overhead
• Physical I/O timing
• Behavior under demanding test conditions

10. Complete closed-loop testing

Connect the intended hardware and verify the complete model, scheduler, I/O, script, logging, and device-under-test configuration.

Keep Development and Target Environments Aligned

The closer the development environment matches the target’s supported software stack, the fewer deployment problems engineers are likely to encounter.

Important items to control include:

• SimWB version
• Model-integration toolkit version
• Compiler and runtime versions
• FMI or FMU requirements
• Shared libraries
• Model source and generated code
• Configuration formats
• Script versions
• Environment variables
• File and directory assumptions

Identical version numbers do not guarantee identical behavior across operating systems, but uncontrolled version differences create avoidable uncertainty.

A compatibility matrix can help teams record which development and target versions have been tested together.

Watch for Platform-Specific Dependencies

A model may work on Windows while relying on behavior that is not available on the Linux target.

Potential issues include:

• Windows-specific file paths
• Case-insensitive filenames
• Platform-specific libraries
• Native Windows APIs
• Different path separators
• Assumed drive letters
• User-specific directories
• Different line-ending behavior
• Unavailable environment variables
• Host-specific licensing
• Different compiler behavior

The reverse can also occur when a Linux-oriented model expects resources not available in the Windows development environment.

Models should avoid unnecessary platform assumptions, and required differences should be documented explicitly.

Preserve Model Portability

Separating models from physical I/O makes the Windows-to-target workflow easier.

A model can interact with named engineering variables during functional development and connect to physical channels after deployment. The target configuration supplies the I/O mappings without requiring hardware calls to be embedded throughout the model.

This architecture is discussed further in Why HIL Simulation Models Should Be Independent of the I/O Configuration.

Portability still depends on the model’s compiled code, libraries, sample-time requirements, and target support. A stable data interface reduces one major source of coupling but does not remove every platform dependency.

Test Timing Only on the Intended Target

Windows testing can confirm that a model produces the correct values. It cannot confirm that those values will be produced at the correct time in the complete HIL system.

Target timing validation should include:

• The full set of models
• All intended sample rates
• Physical I/O
• Communication traffic
• Data logging
• Test scripts
• Visualization clients
• Processor assignments
• Interrupt configuration
• Fault conditions
• Peak computational paths

As explained in Why DeterministicWhy Deterministic Timing Matters in Real-Time Simulation Timing Matters in Real-Time Simulation, average execution speed is not enough. Maximum execution time, jitter, overruns, and processing headroom must be evaluated on the real-time system.

Supporting Parallel Engineering Work

A Windows development environment can allow more engineers to work on models and test configurations without competing for a limited number of real-time targets.

This can support a division of responsibilities in which:

• Model developers verify numerical behavior.
• Integration engineers define data interfaces.
• Test engineers develop scripts and expected results.
• I/O engineers prepare target mappings.
• Real-time engineers validate scheduling and processor allocation.
• System engineers conduct complete HIL testing.

The approach does not eliminate coordination. Teams still need shared interface definitions, controlled versions, and agreed deployment procedures.

It does allow many integration problems to be resolved before they reach the laboratory.

Stimulation Workbench on Windows

Stimulation Workbench on Windows uses WSL2 to provide a SimWB development environment on Windows workstations.

It is intended for model preparation, functional testing, configuration development, and other early simulation work before deployment to a real-time target.

The Windows environment can support a consistent workflow for preparing models and tests, while the Linux-based Stimulation Workbench system remains the environment for deterministic execution with RedHawk Linux and physical real-time I/O.

This distinction allows teams to reduce unnecessary use of the target without implying that Windows results establish real-time performance.

Development-to-Deployment Checklist

Before moving a simulation from Windows to the target, confirm:

• Target sample rates are documented.
• Model interfaces and units are defined.
• Models initialize successfully.
• Reference input cases produce expected outputs.
• Required libraries are identified.
• Platform-specific dependencies are documented.
• Model, script, and configuration versions are controlled.
• Target-compatible build artifacts are available.
• I/O mappings are prepared separately from model logic.
• Numerical checks will be repeated after deployment.
• Timing validation is planned on the target.
• Physical I/O testing is included.
• The full test configuration will be evaluated for overruns.
• Windows performance has not been treated as a real-time benchmark.

Windows-based development can make real-time simulation projects more efficient by moving model preparation, interface verification, script development, and functional testing away from a limited target system.

The value comes from finding ordinary integration problems earlier and giving more engineers access to a representative development workflow.

The boundary must remain clear. Windows and WSL2 do not reproduce the deterministic scheduling, processor controls, physical I/O, or closed-loop timing of the RedHawk Linux target.

Functional development can begin on Windows. Final numerical comparison, timing analysis, I/O integration, and system validation must occur on the intended real-time platform.

For a broader discussion of development workflows, model integration, scheduling, I/O architecture, multicore execution, and test automation, download Designing Scalable, Deterministic X-in-the-Loop Simulation Environments.

Frequently Asked Questions