The first step to deploying V&V on a project using Model-Based Design is to assess what V&V activities are needed to both satisfy requirements and to realize the time savings from Model-Based Design. This determination should be based on the time, quality, and cost goals of the project. An obvious strategy would be to do only as much as necessary.
Second, to reduce project costs and ramp-up time, the extent of automation must be carefully chosen and should only be fully automated after the steps in the V&V process are identified and proven. Industry and regulatory standards and guidelines provide objectives for development process activities which impose additional constraints and require creation of additional artifacts to show conformance. Model-Based Design supports these activities through automation and reuse of models to facilitate early and continuous verification.
In summary, to assess your V&V needs:
Shift the focus to model review
- Determine standards that apply and objectives that must be met (industry and internal objectives) For example Level A of DO-178B requires traceability to object code whereas other levels do not.
- Analyze past SW projects to determine the primary source of major defects and waste.
- Identify additional areas for improvement, such as cost, schedule, etc. For example, if unit testing fell behind schedule due to time required to create test vectors for full coverage. This can be addressed by adding in an objective in the development process to automate test vector generation. Conversely, if manual vector generation has never been an obstacle then automation of test vector generation should not be considered as an initial focus area.
- Determine activities and level of automation required to support objectives
- Choose tools to facilitate activities and automation required.
Code reviews are an important part of the traditional design process. In Model-Based Design, models become the true source, translation errors when generating code are minimal [Ref. 11] and automated technologies such as software-in-the-loop (SIL) provide additional verification that the code directly implements the design. More focus is placed on model reviews and formal verification and validation. As a result, engineering time is spent more productively.
Migrate key supporting processes
In a production environment, teams of engineers often work on multiple related projects and update multiple components in parallel. Lack of careful management of component versions and configurations will lead to build and integration errors, adding inefficiency to the project. In many companies, configuration management (CM) is already a formal part of the development process. Whereas traditionally code is at the center of CM because it is often the most accurate reflection of the design, with Model-Based Design the focus shifts to the model, and the CM strategy needs to be adjusted to facilitate engineers working with models.
The model and other design artifacts are in text format so they can be managed just like source code files, thus requiring no major upgrade of the existing CM infrastructure. However, a few considerations on what artifacts should be placed under CM should be made:
- A design consists of the model, data dictionary, and model libraries, all of which should be in CM, so the design can be reconstructed completely. Tools supporting Model-Based Design also allow that the design be linked with requirements so bi-directional traceability between the two can be established. Thus to maintain integrity, requirements documents should be CM’ed as well.
- A design should also cover its test environment, including test harness models, test vectors, and expected output. A test environment that is managed with the model ensures that model-based verification including regression testing can be carried out quickly and efficiently.
- It is important that tool automation scripts and settings for code generation along with source files for legacy application code, and files describing I/O drivers and communication stacks be configuration managed with the model so that the application can be consistently recreated. Whether or not the generated code is placed in CM upon each release along with the model should be based on the CM requirement of the company and the project. For instance, if the requirement is all files including object code and flash image of the application will be CM’ed, then the generated code should be CM’ed too.
A tool chain supporting Model-Based Design typically includes tools from multiple vendors, so openness is a requirement for any tool to be deployed effectively within the tool chain. CM is no different. For example, to support the basic capabilities required for CM, MATLAB
provides an open API which allows it to interface to many common revision control systems. CM strategies vary from company to company. Reference 13 recommends a set of practical strategies, including how to define sets of associated model files to form configurations.
Beyond configuration management, change management is a process in which engineering changes are formally requested, reviewed to determine whether the change is to be made, and results from the change documented. Model-Based Design has no impact on this process. However, automation capabilities provided by tools supporting Model-Based Design can simplify or accelerate tasks such as design review and regression testing.