Simulation of system level models is the holy grail(1) of Model-Based Systems Engineering, giving the ability to validate system level functional requirements in a virtual environment. So what is the current state of the system-level simulation? I would say it is looking for its Galahad.
The past, the present
What should you simulate at the system level and what level of detail (fidelity) do you need to achieve? Fidelity limitations limit the answer to the first part; presently the majority of system level simulations run at low levels of fidelity to enable reasonable simulation times(2) and because it’s difficult to validate high fidelity full system level physical models.(3) As a result, scenario based testing(4) compromises the majority of system level testing.
A call to the future
When I first started working, some engineers thought that Moore’s Law would solve the simulation fidelity issue; however as fast as processing power has increased, model complexity has grown as fast or faster; the red queen’s problem. Fortunately there are other solutions.
Divide, smooth, and conquer
Not all of your physical model needs to be high fidelity in the system level simulation; components of different levels of fidelity can be joined together and then “smoothing” operations can be performed on the exchanged data if there are rate or discontinuous behaviors. The full suite of system level models can be comprised of multiple sets of models of different fidelity, allowing for specific types of system level tests.
Avoiding Risk(5)
However the greatest risk to system level simulation is not technical, it is political. Since system level simulation is new to most organizations there may not be an internal champion. Unlike many process adoptions system level simulation by it’s nature requires cooperation across multiple groups. How do you inspire an organization to believe in the holy grail?
- Start small: While the ultimate objective may be the full system level simulation, errors and improvements can still be found at the subsystem integration level.
- Identify past integration failures: It is a two step process; first identify the past system integration failures, second demonstrate(6) how system level simulation could have detected the issue prior to deployment.
- Case studies: While the domain is maturing there is a long history of existing case studies across multiple domains.
Closing thoughts
Ideally system level simulation is started at the start of the project, moving the issue detection upstream. When it is started late in the process it can serve a secondary purpose; providing the tool for root cause analysis for system level bugs. Regardless of where you are in your process it is time to get started.
Footnotes
- Like the grail quest, it is never complete but always transformative in a positive fashion.
- In general, simulation times of 1/10 of real time are reasonable. For some scenarios slower than real time is accepted to validate critical systems.
- Difficulties in validating high fidelity system level models
- Practical: Lack of full system interaction data (e.g., how does the AC pump respond to high torque engine loads and high electrical loads?)
- Pragmatic: Length of time required to simulate the full model.
- Political: Lack of a key stake holder willing to fund the work required.
- Scenario based testing is an excellent method for detecting system level faults for intermittent messaging, e.g. what are the effects of system latency in the communication of critical data.
- The last image was not an endorsement of the board game Risk.
- System level failures are easy to show when you have full test logs of existing products “in the field.” A static playback of the data can be provided to stand in for the model