Large simulation environments rarely rely on models from a single source.

A test may combine a Simulink control model, an FMU supplied by a component vendor, a vehicle or flight-dynamics model from a commercial package, and custom C or C++ code developed internally. Each model may have its own interfaces, sample rates, solver assumptions, build dependencies, and initialization requirements.

Supporting each file format is only the beginning. The models must exchange data consistently, execute within their assigned deadlines, and produce the same intended behavior after deployment to the real-time target.

Successful real-time model integration therefore requires a common execution and data architecture, not simply a long list of compatible modeling tools.

Figure 1. Models from different sources come together through one common execution and data architecture rather than a list of compatible tools.

Why Engineering Teams Use Models from Multiple Sources

Different tools are suited to different parts of a system.

A controls team may use Simulink to design and generate code for control algorithms. A supplier may deliver a protected FMU rather than source code. Another group may maintain a high-fidelity plant model in C++, while an existing test system may contain validated Fortran routines developed years earlier.

Rebuilding every model in one environment would be expensive and could invalidate previous engineering work.

A heterogeneous simulation environment allows teams to preserve those investments while combining models into a larger system-level test. Potential benefits include:

• Reusing validated subsystem models
• Allowing engineering groups to work in their preferred tools
• Integrating supplier-delivered intellectual property
• Supporting legacy and newly developed models together
• Replacing individual models without rebuilding the entire simulation
• Progressing from subsystem tests to system-level HIL environments

The challenge is establishing clear boundaries among the models.

File Compatibility Is Not Enough

A model may compile successfully and still be unsuitable for real-time execution.

Real-time integration also requires answers to questions such as:

• What function initializes the model?
• How is one simulation step invoked?
• What is the required sample time?
• Does the model contain multiple rates?
• Which solver assumptions does it make?
• How are inputs and outputs represented?
• Does it require external files or libraries?
• Does it allocate memory during execution?
• Does it create its own threads?
• Does it make blocking operating-system calls?
• How does it report errors?
• How is its state reset between tests?
• What is its maximum execution time?

These details determine whether the model can participate in a scheduled simulation loop.

Integrating Simulink Models

Simulink is widely used to develop control, plant, and signal-processing models. Moving a Simulink model into a real-time environment generally involves generating compiled code that can execute on the target system.

The integration process commonly includes:

1. Configuring the model for code generation.
2. Selecting a fixed-step execution method appropriate for real-time use.
3. Identifying the model’s inputs, outputs, parameters, and states.
4. Generating source or compiled model code.
5. Building the model for the real-time target.
6. Registering the model with the simulation scheduler.
7. Mapping its variables to other models and I/O.
8. Verifying numerical and timing behavior on the target.

The model may contain one sample rate or several discrete rates. A multirate model can produce separate execution functions or threads that must be scheduled at the correct intervals.

The sample-time relationships need to remain consistent after deployment. Changing a model’s step size simply to make it fit the test system can alter its numerical behavior.

Figure 2. Integrating a Simulink model moves it from a design-time tool through code generation, scheduling, and on-target verification.

Fixed-Step Execution and Solver Assumptions

Offline models can often use variable-step solvers that adjust the calculation interval according to model behavior. Real-time execution generally requires a schedule that can be completed within a fixed period.

The model integration process must therefore identify:

• Whether the model already uses a fixed-step solver
• The required base step size
• Any additional discrete sample rates
• Continuous states that require numerical integration
• Solver configuration and tolerances
• Algebraic loops
• Zero-crossing behavior
• Computationally expensive model paths

A model that produces acceptable offline results with a variable-step solver may require modification or a different solver configuration for fixed-step real-time execution.

That conversion should be treated as an engineering activity, not merely a build setting.

Integrating FMUs

The Functional Mock-up Interface, or FMI, provides a standardized method for exchanging simulation models. A packaged model conforming to the standard is called a Functional Mock-up Unit, or FMU.

FMUs are useful when:

• A supplier needs to deliver a model without exposing its internal source
• Teams use different modeling tools
• A model needs a defined set of inputs, outputs, and parameters
• The same model may be used in more than one simulation environment
• Intellectual property must remain encapsulated

An FMU package can contain model metadata, variables, binaries, resources, and information required by the importing environment.

However, an FMU is not automatically suitable for every target or real-time workload.

Model Exchange and Co-Simulation FMUs

FMI supports different execution approaches. Two commonly encountered types are model exchange and co-simulation.

Model exchange

A model-exchange FMU provides the model equations but relies on the importing environment to manage numerical integration.

This gives the host more control over scheduling and solver behavior but requires compatible integration support.

Co-simulation

A co-simulation FMU includes or manages its own solver and advances when the host requests the next communication step.

This can make a model more self-contained, but the internal solver must still complete within the real-time deadline. Its behavior between communication points must also be compatible with the rest of the simulation.

Engineering teams should identify the FMU type, supported FMI version, target operating system, processor architecture, and execution assumptions before planning deployment.

Why an FMU May Not Be Real-Time Ready

An FMU that works in a desktop simulation may contain behavior that is difficult to schedule predictably.

Potential concerns include:

• A variable-step internal solver
• Unbounded iteration
• Dynamic memory allocation
• File access during a model step
• Network or license-server calls
• Unsupported binary dependencies
• Background threads
• Platform-specific libraries
• Large initialization files
• Execution paths with highly variable duration
• Error handling that blocks while waiting for another resource

The FMU should be tested on the intended target with representative inputs and operating conditions. Average execution time alone is not sufficient; maximum execution time and timing variation also matter.

As discussed in Why Deterministic Timing Matters in Real-Time Simulation, the relevant question is whether the model completes predictably within its assigned deadline.

Integrating Custom Compiled Models

Custom models are often written in C, C++, or Fortran. They may represent specialized physics, proprietary algorithms, legacy simulations, or functionality not available in a commercial modeling package.

A custom model typically needs a defined lifecycle:

• Initialize the model
• Set initial conditions
• Receive inputs
• Execute one simulation step
• Publish outputs
• Update parameters
• Report errors
• Reset or terminate the model

A clear interface allows the scheduler to control when the model executes and the data architecture to control how it exchanges values.

Custom models should avoid unexpected blocking behavior inside the real-time loop. File access, network requests, console output, memory allocation, and synchronization with external services can all introduce timing variation if they occur during time-critical execution.

The model should also expose enough information for engineers to understand its sample time, variable definitions, units, parameters, and error states.

Establishing a Common Data Interface

Models created in different tools rarely use identical variable names or data structures. A common data layer provides a stable boundary among them.

Each model can publish and consume defined simulation variables rather than communicating directly with every other model or physical device.

For example:

• A flight-dynamics model publishes angular rate.
• A sensor model reads angular rate and produces a simulated sensor output.
• A controller model consumes the sensor output and calculates an actuator command.
• An I/O task maps the command to the connected hardware.

The models do not need to contain direct calls to each other. They interact through defined data items.

This approach supports the model and hardware separation described in Why HIL Simulation Models Should Be Independent of the I/O Configuration.

Define More Than Variable Names

A reliable model interface should document:

• Variable name
• Description
• Data type
• Engineering units
• Valid range
• Update rate
• Producing model
• Consuming models
• Initial value
• Invalid-data behavior
• Timing or freshness requirements
• Coordinate system or reference frame
• Sign convention
• Scaling or conversion requirements

Two models can use the same variable name while interpreting it differently. Unit, coordinate, and timing mismatches can produce plausible but incorrect results.

Interface definitions should be reviewed with the same care as model source code.

Coordinating Sample Rates

Models imported from different sources may execute at different rates.

A control model may run every millisecond, while a thermal model runs every 20 milliseconds. A supplier FMU may expect a five-millisecond communication step, and a sensor model may require a faster interval.

The simulation environment must define:

• The common base period
• Each model’s execution rate
• Whether the rates are compatible
• When data transfers between rates
• Whether values are held between updates
• Required execution order
• Any intentional delays
• What happens if a model misses its deadline

How Multirate Real-Time Simulation Works examines these scheduling and data-transfer issues in more detail.

Managing Model Dependencies

Some models can execute in parallel. Others require a specific order.

If Model B needs the current output from Model A, the scheduler must ensure that Model A completes before Model B begins. If a one-cycle delay is acceptable and represented in the design, Model B may use the previous value instead.

Dependencies should be documented explicitly. Relying on the incidental order in which threads happen to run can create behavior that changes when models are moved to different processor cores.

The dependency graph also affects multicore scaling. Parallel hardware cannot eliminate a required serial sequence.

Engineering teams should identify the longest dependent path through the model set and confirm that it fits within the simulation deadline.

External Libraries and Runtime Dependencies

Generated and custom models may rely on:

• Shared libraries
• Compiler runtimes
• Tool-vendor libraries
• Data files
• Environment variables
• Licensing components
• Lookup tables
• Configuration files
• Hardware-specific APIs

A model that runs on a development workstation may fail on the target because a dependency is missing, incompatible, or built for a different processor or operating system.

Dependencies should be inventoried and packaged deliberately. Their licensing and redistribution terms may also affect how the model can be deployed across test systems.

For long-running programs, recording compiler, library, and tool versions makes future rebuilding and troubleshooting considerably easier.

Validate Numerical and Timing Behavior Separately

Model validation for real-time deployment has at least two distinct parts.

Numerical validation

Does the deployed model produce the expected outputs for known inputs and initial conditions?

Useful methods include:

• Comparing against offline reference results
• Running defined input vectors
• Checking steady-state values
• Comparing transient responses
• Verifying limits and fault conditions
• Confirming unit and coordinate conversions

Timing validation

Does the model complete predictably within its assigned period as part of the complete test configuration?

Timing validation should include:

• Maximum execution time
• Jitter
• Processor-core utilization
• Synchronization delays
• Rate-group alignment
• I/O processing
• Logging and visualization
• Demanding model paths
• Fault-injection conditions

A model can pass numerical validation while failing its real-time timing requirements.

Figure 3. Numerical validation and timing validation ask different questions a model must pass both.

Protecting Supplier Intellectual Property

Heterogeneous integration frequently involves supplier-delivered models that cannot expose source code.

FMUs and compiled libraries can protect implementation details while providing a documented variable interface. However, the test-system team still needs enough information to integrate and validate the model.

At minimum, the supplier should provide:

• Supported target platforms
• Input and output definitions
• Units and ranges
• Sample-time requirements
• Initialization procedure
• Parameter definitions
• Expected execution behavior
• External dependencies
• Error and validity indicators
• Version information
• Known limitations

A black-box model without an adequate interface specification can be difficult to integrate even when the binary runs successfully.

Model Integration in SIMulation Workbench

SIMulation Workbench provides a common framework for executing models from multiple sources alongside physical I/O, scripts, and data-recording processes.

SimWB includes integration mechanisms for Simulink-generated models, FMI-compatible models, and user-developed compiled models. It also supports models from several commercial simulation environments through available interfaces and toolkits.

Its memory-resident real-time database provides the shared data layer among models and I/O tasks. Model variables can be mapped to other model variables or physical channels without embedding the complete I/O configuration in each model.

The SimWB scheduler controls when registered models and model threads execute. Models with different rates can operate within the same test, and appropriate workloads can be assigned across processor cores.

The platform provides the integration framework, but each imported model must still be reviewed for target compatibility, solver behavior, dependencies, execution time, and interface correctness.

Real-Time Model Integration Checklist

Before adding a model to a system-level simulation, confirm:

• The model’s source format and supported target platform
• Required tool and compiler versions
• FMI version and FMU type, when applicable
• Fixed-step and solver requirements
• Base sample time and additional rates
• Input, output, parameter, and state definitions
• Units, ranges, and coordinate conventions
• Initialization and reset behavior
• External libraries and files
• Threading and memory-allocation behavior
• File, network, or license-server access
• Maximum execution time
• Data dependencies on other models
• Required execution order
• Error and invalid-data behavior
• Numerical comparison against a reference
• Timing behavior in the complete test configuration

This checklist helps identify integration risks before the model becomes part of a larger HIL test.

Conclusion

Combining Simulink, FMU, and custom models can preserve existing engineering investments and allow specialized teams to contribute to a shared simulation environment.

The difficult part is not recognizing the file format. It is coordinating solver assumptions, sample rates, data interfaces, dependencies, runtime libraries, and execution timing.

A successful architecture gives each model a clear lifecycle and variable interface, schedules it according to its timing requirements, and validates both its numerical outputs and its behavior on the real-time target.

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

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

Frequently Asked Questions