Simulator Configuration and Version
When working with multiple groups to build a simulation, there must be a mechanism to ensure all of the groups use a common simulation environment. This has three components:
- The choice of simulation engine,
- The configuration of the simulation engine, and
- The version of the simulation engine.
Choice of Simulation Engine
A Distributed MBD project requires that all participating groups use the same simulation engine, whether it is a formal simulation engine such as Simulink or Dymola, or an ad-hoc simulation environment with propagators built in-house.
At first glance, it might seem that this is not necessarily true because there are co-simulation techniques available to simulation teams. However, the chosen co-simulation environment becomes the de-facto choice of simulation engine: all components must work within the co-simulation environment.
Configuration
If the different organizations contributing to a Distributed MBD project are not using a common simulator configuration, problems can arise in the integrated simulation.
Differences in the propagator configuration, such as integrator algorithms and tolerances, can result in subtle numerical errors. This can be difficult to detect:
- Numerical errors are often quite small. Usually, these errors are small enough that they can be ignored, but deciding what can be ignored is a matter of engineering judgement.
- Numerical errors often look like modeling errors, and distinguishing them can be tricky.
- Differences in numerical results might not be an avoidable error. Continuous-time propagation techniques are only an approximation, and will always result in some numerical error.
- Without knowing the ‘perfect’ simulation results, deciding which configuration is more ‘correct’ is a matter of engineering judgement.
Differences in the operational configuration of the simulation engine are usually more straight-forward than numerical errors because they are flagged by the simulation engine. This type of configuration includes:
- Data type mismatches.
- Connectivity errors such as an unconnected input.
- Run-time error handling such as divide-by-zero.
- Handling rate transitions.
In some simulation engines, these errors can be suppressed or downgraded to a warning. In this situation, an unexpected error message of this type indicates a mismatched configuration.
The issue of simulator configuration holds a special place in my heart because of one particular event. On a distributed MBD project, I had to endure endless streams of warning messages because one of the engineers was rather cavalier about correctness. Some serious problems were buried in this stream, and this made it difficult to determine whether my contributions were causing any additional warnings or errors. As a result, I asked that the models be delivered without any warnings. I should have seen it coming. You guessed it: the next delivery was configured with all warnings suppressed…
Simulator Version
Most simulation engines require a match in the version of the simulator. Usually, this means that a component created in one version of the simulator cannot be loaded into an earlier version of the simulator.
For an MBD project within one organization, this a usually not an issue because the team decides on a version and uses it. Often, this decision is implicit; whatever version is loaded on their machines is what they run with.
The simulator version needs to be explicitly controlled in a Distributed MBD project:
- It is easy to overlook this issue when initially establishing the project or when inviting a new group into the project.
- An engineer could unknowingly use an incorrect version of the simulation engine. This can occur when an engineer not familiar with the project is invited to join it, and he or she does not explicitly check the version loaded on his or her machine.
- A group that is participating in a Distributed MBD project may have internally standardized on a simulator version for other projects, and this version might be incompatible with the distributed project. Juggling simulator versions between different projects can result in errors.
- Although this type of error is usually very easy to recognize and diagnose, repairing it can be a major problem. If a component is created in a later version of the simulation engine, it may be necessary to completely re-enter the entire model in an earlier, compatible version.
SystemBlend™
SystemBlend™ approaches these issues by standardizing the simulator configuration for the entire project.
Currently, SystemBlend™ is built on the Simulink simulation engine, so the choice of simulation engine is already made.
Simulator Configuration
In the SystemBlend™ application suite, the Simulink configuration is decided up front, in the SystemDesigner design application. Initially, the configuration is the default Simulink configuration, but the designer can modify any configuration element. This standardizes the configuration for the entire project.
This configuration is used in the component development application, ComponentGuide. ComponentGuide verifies the component using both a user-supplied unit test and an automatically generated test harness. In both cases, the configuration defined by the design team is applied.
In addition, ComponentGuide automatically generates a Matlab script that sets this configuration, making it easy for the developer to test the component outside of SystemBlend™ with the specified configuration.
SystemBlend’s integration application, IntegrationMaster, uses the specified configuration by default. If desired, the integrating engineer can override any or all of the simulation configuration as needed. This makes it easy for the engineer to explore configurations different from that specified by the design team.
This approach requires that any needed configuration changes be negotiated with the design team. If a component developer needs a change to the configuration, it must be negotiated with the design team. Once the new configuration is chosen, it is updated in SystemDesigner and propagated to all teams. This allows the configuration to smoothly evolve during the project lifecycle along with the rest of the simulation.
By standardizing the configuration this way, configuration difficulties described above are eliminated.
Simulator Version
Like the simulator configuration, the design team standardizes the Simulink version up front in SystemDesigner by selecting a particular Simulink version.
In ComponentGuide, any attempt to use a later version of Simulink is flagged as an error, requiring the developer to switch to a compatible version of Simulink. ComponentGuide allows the use of earlier versions of Simulink, but not later versions.
In IntegrationMaster, any attempt to use an earlier version of Simulink is flagged as an error, requiring the engineer to switch to a compatible version of Simulink. Later versions of Simulink are allowed in IntegrationMaster, but not earlier versions. This ensures that delivered component will run in the Simulink version being used.
By standardizing the Simulink version for the project, the problems from version mismatches are eliminated.
Other Articles in this Series:
- Part 1: Project Launch
- Part 2: Updating Components
- Part 3: Adding Components
- Part 4: Splitting Components
- Part 5: Replacing Components
- Part 6: Component Delivery
- Part 7: Imprecise ICDs
- Part 8: Misinterpreted ICDs
- Part 9: Naming Collisions
- Part 10: Simulation Parameters
- Part 11: Simulator Configuration
- Part 12: Location Independence
- Part 13: Shared Parameters
- Part 14: Data Capture
- Part 15: Architecture Updates
- Part 16: Deprecating Components
- Part 17: Project End-of-Life
Note: This post has been updated with links to other posts in the series