When I release a model it will

• Reach 100% requirements coverage for the model
• Reach 90% test coverage of requirements
  • With 100% passing
• Be in full compliance with 70 Modeling Guidelines
  • Reach 90% compliance with an additional 7
• Achieve 95% MISRA compliance
  •  100% with exception rationale
• …

However, if I asked anyone to reach these levels early on in the development process then I would both slow down the process and increase the frustration of the developers.

What is a phased approach to verification?

The phased approach to verification imposes increasing levels of verification compliance as the model progresses from the research phase to the final release.

The following recommendations are rough guidelines for how the verification rigor is applied at each phase.

Research phase

The research phase has the lowest level of rigor.  The model and data from this phase may or may not be reused in later phases.  The model should meet the functional requirements within a predetermined tolerance.   Modeling guidelines, requirements coverage, and other verification tasks should not be applied at this phase.

Initial phase

With the model in the initial phase, we have the first model that will be developed into the released model. With this in mind, the following verification tasks should be followed

• Verify the interface against the specification:  The model’s interface should be locked down at the start of development.  This allows the model to be integrated into the system level environment.
• Compile with model architecture guidelines:  Starting the model development with compliant architecture prevents the need to rearchitect the model later in development.
• Create links to high-level requirements:  The high-level requirements should be established with the initial model.

Development phase

The development phase is an iterative process.  Because of this, the level of verification compliance will increase as the model is developed.  As would be expected the level of requirements coverage will increase as the implementation of the requirements is done.  The verification of the requirements should directly follow their implementation.

With respect to the increasing compliance with modeling and MISRA compliance; in general, I recommend the following.

• 50% guideline compliance/MISRA at the start of the development phase
• 70% guideline compliance/MISRA when 50% of the requirements are implemented
• 90% guideline compliance/MISRA when 80%  of the requirements are implemented

Release phase

With the release phase, I finally hit the targets I initially described.  Entering this phase from development all of the functional requirements should be complete. The main task of the release phase is the final verification of requirements and compliance with guidelines (model and code).

Additionally, the release phase may include a “targeting” component; where the model which was designed for a generic environment is configured for one or more types of target hardware.  In this case the functionality of the component should be verified for each target.

Final thoughts

Ramping up compliance with verification tasks is a standard workflow.  The suggested levels of compliance during the development phase should be adjusted based on a number of factors including

• Reuse of components:  When components are reused the compliance should be higher from the start of development.
• Compliance requirements: If you are following a safety critical workflow, such as DO-178C or IEC-61508, then the compliance should be higher from the start of development.
• Group size:  The more a model is shared among multiple people the sooner the model should be brought into compliance with modeling guidelines.  This facilitates understanding of the model under development