I recently read an article that mentions model re-use in simulations. That got me thinking about some of the issues surrounding this topic. This is a generic issue, applicable to a wide variety of simulations, but it takes on significantly increased importance for my passion: simulations that are built by multiple organizations.
A holy grail of simulation is to have a re-usable library of components that can be re-used across multiple projects. It is helpful to understand some aspects of model re-use:
- Building components for use across a set of projects.
- Building components for generic re-use.
- Fidelity match.
- Interface compatibility.
- Project maturity.
- Component specificity.
- Components are rarely truly re-usable.
- Always design for re-usability.
Those last two bullets might seem to be incompatible, but I’ll describe that later.
I’m passionate about simulations built by multiple groups, even by multiple companies. In these situations, usually a company is invited to provide a subsystem model because it already has one in place, so re-use is critical. This article describes re-use in general, although everything described herein certainly applies to distributed projects.
Building Components for Use Across Multiple Projects
This scenario is occasionally encountered, for example when an organization is building a line of closely related products, such as series of trim levels in a consumer automobile, or a family of farming implements.
In this situation, the best approach is to adapt both sides of the interface to achieve re-usability. The component developer should build the subsystem model so that it can be adapted, and the various simulation projects should be designed to accommodate the component. The most obvious and best way to achieve this is to parameterize the component so that its behavior can be modified according to the needs of each system-level project, and then requiring the system-level project to provide the parameters.
Another technique that might help is to provide defaults for inputs that the system-level project can’t provide. Consider a line of measurement instruments with a variety of advertised accuracy. In this scenario, it might be desirable to build a single model to accommodate the different sensors in the product line. For the low-end product, the system might not provide temperature, and the low-end sensor might not need it. For a simulation of the low-end product, it might make sense for the system-level simulation to provide a default temperature just to satisfy the interface, but for the high-end product it could make sense for the system-level simulation to model and provide the temperature.
In this limited case, re-usability can be achieved, but it is the exception.
Building Components for Generic Re-Use
This is a more problematic than building a component for a pre-defined set of projects. Without knowing precisely how the component will be re-used, there is no way to accurately anticipate the needs of the component.
Consider an orbit propagator. At first glance it might seem that this is quite achievable. It might seem that if I build an orbit propagator for one satellite, I should be able to use it for any satellite. But consider the different factors that might, or might not, be considered in a satellite simulation:
- Different gravity models
- Atmospheric drag
- Lunar gravity
- Long-duration propagation vs. short-duration propagation
- Re-use for other planets or for Earth’s moon
For a sub-orbital propagator, a simple atmosphere model provides quite good accuracy, and a more sophisticated atmosphere would slow down the execution. A propagator for a lunar orbit is much more complicated than a simple LEO vacuum propagator. Basically, any re-usability is limited to systems which are very closely related to the use case for which the component was designed. But there are other limitations that further limit re-use, as described below.
Fidelity Match
To re-use a component in a larger simulation, the fidelity of the component should approximately match the fidelity of the simulation. Using a high-fidelity component in a low-fidelity simulation will not add much, and will slow down the simulation. Conversely, using a low-fidelity component in a high-fidelity simulation might not provide sufficiently detailed behavior to support the analysis.
Consider a simulation of a chemical processing plant to determine maintenance schedules. Typically, such a simulation models failure with a random distribution, and perhaps simply counts the number of times a control element is cycled. In such a simulation, it probably would make sense to build a simple valve model, that models the pressure drop as a simple, parameterized function of opening percentage, flow rate, and approximate temperature, and re-using this model throughout the simulation. If a high-fidelity CFD model of a valve is available, it probably would not make sense to use it for two reasons: First, a CFD model would dramatically slow down the simulation. Second, the CFD model would probably need inputs not supplied by the simulation, such as incoming turbulence or temperature variations in the process fluids.
Conversely, consider a simulation of the reactor in the same processing plant, developed to fine-tune the processes. In this situation, a full CFD simulation of the valves might be warranted, in order to understand the mixing dynamics. Using a simple, parameterized valve model would not work for two reasons: First, it probably would not capture the needed phenomena to understand the chemical reaction. Second, it probably would not supply the detailed information required by other elements in the simulation.
Interface Compatibility
This is perhaps the most common roadblock in re-using models, but it also often the most easily managed. Often, when the fidelity of the model matches the fidelity of the simulation, the information passed across the interface (in both directions) is defined by the needs of the project, and not the specifics of the implementation. When this is the case, the component can often be plopped into a ‘wrapper’ which comprises the block and some ‘impedance matching’, such as:
- Units conversion,
- Coordinate transformation, and/or
- Timing adjustments.
By wrapping the existing component this way, the interface of the wrapper can match the interface defined by the other elements of the simulation, thereby matching the ‘impedance’ of the component to the simulation.
Project Maturity
The appropriateness of a component for a project might depend on the maturity of the project. Often, a simulation will grow from simple to complex. It might start as a proof-of-concept or a feasibility study and grow into a high-fidelity simulation suitable for detailed engineering decisions.
Consider a project to design a land vehicle to take on unique terrain, and the suspension is the primary engineering challenge. Also assume there is a high-fidelity model of the engine you will be using. In this project, it probably makes sense to first determine the basic parameters of the suspension. The simulation might start simply with the chassis modeled as a simple, rigid structure with the mass distribution described as a simple MOI, and the engine is a crude torque source. In this beginning stage, the high-fidelity engine model would not add much to the initial suspension design. Later in the project, as the simulation fidelity increases, it will be necessary to consider other factors such as fuel consumption and regulatory constraints, so it would make sense to bring the high-fidelity engine model into the simulation.
Component Specificity
Some components, by necessity, are very specific to a particular project and simply cannot be re-used on another project without extensive re-work.
Consider a model of the thermal environment on a satellite. Such a model will have heat flow very specific to the external surfaces, internal structure, and materials for a particular satellite, and transferring it to another satellite will require adjusting most of the structural layout of the component.
Components are Rarely Re-Usable
With the limited exception described above, components usually are not directly re-usable.
In my 35 years of experience in simulation, I have never encountered a situation in which I could directly use a component built for one project on another project. In almost every case, I was able to overcome this with an impedance-matching wrapper.
Aside: There are actually highly re-usable simulation elements, but they are far too simple to be considered a component. Every block included with a basic license of Simulink is a good example of this, such as gain blocks, switches, and routing blocks. But these do not contain any engineering information until they are connected together, so they do not qualify as ‘components’.
Probably the best example of this is a library that was designed by industry experts specifically for re-usability: The Aerospace Block Set from The Mathworks. In all of my career, every project involving attitude and orientation has used quaternions in which the last element is the scalar, but the Aerospace Block Set uses quaternions with the scalar element first. Neither is ‘right’ or ‘wrong’, they are just different conventions. In order to use this block set in any of my projects, I would have to include some impedance matching on every block from the block set, or I would have to change the convention on my projects.
Always Design for Re-Use
I just claimed that components are not re-usable, so how can I say you should always design a component for re-use? Simple:
- If you design for re-use, you probably won’t achieve complete re-use, but you make it feasible to use your component elsewhere.
- If you don’t design for re-use, you are ensuring that no other project can use your component.
If you carefully consider re-usability factors in your component design, then you will minimize the modifications needed to incorporate your component into other projects. Hopefully, you can set it up so other projects can simply update parameters and use an impedance-matching wrapper. For situations that need more modification, a re-usable design will minimize the needed re-work.
Conclusion
I wrote this article just to help the reader understand some of the issues behind component re-usability in simulations. If nothing else, I hope you remember:
- Components are seldom re-usable, but often there are ways to manage it.
- You should always try to achieve re-usability when building a component.
Edit: This topic is closely related to the topics in my post on Location Independence.