Shared Parameters
In most simulations, some of the subsystem models need to share data in order to ensure consistency. Examples include:
- Within the simulation, fuel mixture models, engine cooling model, and tire models should all use the same atmospheric pressure and temperature.
- Within the same simulation, ICBMs, interceptors, and tracking satellites should all use the same parameters in their gravity models.
A good example of the importance of shared parameters comes from the U.S. Missile Defense Agency. Different contractors were building elements of an overall simulation of the interceptor system. For reasons that were not obvious, the simulations were indicating failure when the system should have worked. With some good detective work, the engineers on the project tracked it down to differences in the gravity models. These models varied by only a miniscule fraction of a percent, but the flight ranges are thousands of kilometers and the acceptable miss distance is less than a meter, so the simulations didn’t work. By standardizing on a common set of gravity parameters across the entire project, these errors were eliminated.
Sharing parameters between components can be tricky simply because most simulation engines make it so easy to hard-code parameters at their point of use. It’s just easier to type in "101325 Pa" for atmospheric pressure, instead of getting the value from a shared location. Without a straight-forward way to share variables, the simulation can have many different instances of a parameter, each with slightly different values.
In order to support Monte Carlo simulations, the simulation tools need an effective mechanism to automatically set and re-set the values of shared parameters (and component-specific parameters as well).
Models of Software vs. Engineering Models
The goal of using a common set of parameters should be applied judiciously. Many simulation projects consist of a model of the mechanical system (a car or a spacecraft) and a model of the controller software (engine controller or G&C). The goal for the simulation developer is to make the parameters in these models match what they are modeling, and this often means that the same parameters in these models will have different values.
Consider a simulation of a spacecraft with an on-board controller. The on-board controller could track the spacecraft’s position using a gravity model with low-order coefficients and rely on occasional updates from ground tracking. The simulation would probably need to propagate the spacecraft position using a high-order gravity model. In this situation, the two propagators might be the same algorithms, and the coefficient matrices are different sizes.
SystemBlend™
The SystemBlend™ application suite has a simple, intuitive facility for specifying shared parameters and for ensuring different models use a consistent set of parameters.
In a distributed MBD project, the team specifying the simulation uses the design application, SystemDesigner, to define which parameters are present in the project and to specify their values. The parameters are constructed graphically, and their values are provided through the GUI. SystemDesigner provides cues to guide the designers in specifying shared parameters.
The component development application, ComponentGuide, provides these shared variables in several different forms so that the engineer(s) developing the components can access them in whatever way is most convenient.
Finally, the scenario assembly application, IntegrationMaster, provides techniques for the analyst to adjust the parameters, to aid in exploring alternatives and optimizing the design. It also include facilities to fully automate Monte Carlo simulations.
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