Distributed MBD Project Lifecycle, Part 10: Simulation Parameters

This is the tenth in a series of posts discussing the lifecycle of MBD projects that are distributed across multiple managerial domains.

Simulation Parameters

For this article, I’ll define a simulation parameter as

"A value required by the simulation for proper operation that cannot change during execution of the simulation, but might change for different runs of the simulation"

 
This includes:

  • Initial conditions. These are typically initial output values of integrators or delay blocks.
  • Variable parameters. These allow an analyst to adjust the design when exploring engineering concepts.
  • Fixed parameters. These are parameters that do not change from run to run, for example manufacturer-specified values.

These parameters fall into one of two categories:

  • System-level parameters. These are parameters that are shared by more than one component, and must have the same values for all components. Examples include:

    • Ambient temperature and pressure
    • Gravity parameters
    • Nominal engine thrust on a multi-engine aircraft*
  • Component-level parameters. These are parameters that are specific to each component, and can be different for different components. This includes parameters that can be different between copies of the same component. Examples include:

    • Initial position and velocity
    • Variations in manufacturing
    • Cargo mass and distribution

When developing a component for integration into a larger simulation in a different organization, the developer must provide mechanisms for initializing the component, including:

  • Mechanisms for an analyst to adjust parameters,
  • An automated mechanism to support Monte Carlo simulations, and
  • A technique to supply default, or at least plausible, values for the initialization parameters.

In Simulink development, these parameters are usually supplied as either Matlab workspace variables or data files, and they are set using initialization scripts. Discovering and modifying the parameters in these scripts and files is often rather difficult because Matlab scripts can be difficult to fathom.

Automating Matlab scripts for Monte Carlo simulations can be very time consuming, because making the parameters accessible to automation can be tricky.

Any Distributed MBD project must have mechanisms to address these issues.

SystemBlend™

SystemBlend™ has an extensive, yet intuitive, parameter management facility. Different applications in the application suite provide different parameter capabilities:

  • SystemDesigner, in which the simulation is designed, lets the designer specify system-level parameters, and requires that the designer specify nominal values and Monte Carlo variations for them.
  • SystemDesigner lets the designer specify component parameters that the component must supply.
  • ComponentGuide, in which the components are implemented, lets the developer specify component-level parameters.
  • ComponentGuide requires that the developer provide nominal values and Monte Carlo variations for all component-level parameters, including parameters specified by the designer.
  • Both SystemDesigner and ComponentGuide allow the user to specify whether a parameter is fixed or variable.
  • IntegrationMaster, in which the simulation is integrated, has uniform and intuitive techniques to discover and modify both system-level and component-level parameters.
  • IntegrationMaster allows the analyst to override nominal values and Monte Carlo variations in system-level and component-level parameters.
  • IntegrationMaster fully automates the assignment of values during Monte Carlo execution.

The SystemBlend™ GUI makes this facitily intuitive and straight-forward.

Other Articles in this Series:

Note: This post has been updated with links to other posts in the series

 

* Bonus points if you thought of the B-36!

Request More Information

Contact Us To Learn More