At the heart of digital simulation for Model-Based Design and Model-Based Systems Engineering lies two fundamental approaches; simulation for design and simulation for testing. While each approach can support the other they should not be confused.
Simulation based testing
Fundamentally a test has 3 criteria:
- There are objective measurable pass and failing criteria
- The test is bounded in the scope of functionality covered
- The test is repeatable under simulation
These three criteria are part of the “locking down” acceptance process and define when a software object is ready for integration or release.
Simulation based design
Simulation for design is an exploration process; it is informed by the objective criteria of testing but it is not bound by the objectives. Simulation for design is an iterative process of refining the outcomes of simulation until the software object is ready for formal testing.
Transitioning between
The design based simulation activities can often be transitioned to formal tests, or barring a direct transformation they can inform the formal test. To facilitate this transitioning, a testing / design framework should be developed that allows the design engineer to simulate and evaluate the model within the testing framework while keeping the infrastructural costs for doing so low. The following basic infrastructural components aid in this transition.
- Create a common “set up / tear down” method for models and data: The method for loading models and model data should be consistent for both the testers and the developers. A set up and tear down method enforces a common execution behavior for both groups.
- Create basic evaluation methods for examining simulation results: While test developers are able to create complex evaluation methods for simulation results, the design engineer should not be burdened with the creation of these sorts of tools. In practice roughly 75% of initial testing can be encapsulated with standard modular evaluation methods.
- Standardize requirement descriptions: While not required to meet the strict definition of the requirement document, the design engineer should be working towards that specification. A consistent requirements description language will facilitate the design process.