How to make the V-model workflow iteration-free and fast?

1. Introduction

Functional safety standards require the development of a safety-critical product to be done according to the V-model of system development. Fig. 1 shows this V-model in the form that underlies the autoConform® methodology and software.

Fig. 1: System development V-model of the autoConform® methodology and software

This article is about how the content and the order of the work products (i.e. the documents) of the V-model can be defined in such a way that an iteration-free creation of all work products is possible.

An iteration-free V-model workflow has two decisive advantages.

1. A product design change or correction made in a specific V-model work product can only have an impact on subsequent work products in an iteration-free V-model. Using the (bi-directional) traces between the contents of interdependent work products, these impacts can be determined in full very quickly.
2. A product design change or correction made in a specific work product of the V-Model can only affect subsequent work products in an iteration-free V-Model. Based on the links ("traces") between the contents of interdependent work products, these effects can be fully determined very quickly.

In other words:

1. Product development according to an iteration-free V-model is significantly faster than product development according to a non-iteration-free V-model.
2. The "impact analysis" required by functional safety standards

• in case of a modification of a safety-critical product, or
• when a safety-critical product is intended to be used in a different context

is much easier to carry out if the work products documenting the product development follow an iteration-free V-model.

Section 2 describes the iteration-free V-model workflow. Section 3 summarizes the prerequisites for an iteration-free V-model workflow.

2. Iteration-free V-model workflow

The iteration-free V-model process is shown in Fig. 2.

Fig. 2: Iteration-free V-model workflow

 Fig. 2 shows the V-model process for a product whose product architecture consists of

• a system level,
• n subsystem levels (with the n-th subsystem level being the E/E hardware level), and
• 2 software levels.

Fig. 2 thus shows that there can basically be any number of system, hardware and software levels in a product architecture. At its simplest, the product architecture of an electronic product with embedded software contains only one E/E hardware level and two software levels (namely, the level of the entire software and one software detailed design level). All other system, hardware and software levels may exist, but don‘t have to exist.

In Fig. 2, the V-model workflow is indicated by green arrows. The workflow begins in the upper-left corner at the work products "Item Definition" and "External System Interface Specification". These two work products are closely related to each other and should be created together.

The same applies to the safety analyses "(A)SIL allocation", "FTA", "DFMEA" and "DFA" at each product architecture level and the safety requirements created from these analyses: these work products are also closely related to each other and should therefore be created together.

In Fig. 2, there are bidirectional arrows only between

• the design and interface specifications (far left) and
• the safety analyses (in the second block column from the left).

These bidirectional arrows indicate that,

• on the one hand, the safety analyses (in the second block column from the left) require information from the design and interface specifications (far left), and,
• on the other hand, information such as the "(Automotive) Safety Integrity Level - (A)SIL", is first determined by "Hazard Analysis and Risk Assessment" or "ASIL Allocation" and subsequently entered into the design and interface specifications.

It cannot be concluded from Fig. 2 that the iteration-free V-model workflow is uniquely defined. For instance, it is (theoretically) possible to first edit the leftmost block column (design and interface specifications) in Fig. 2 from top to bottom, subsequently the second block column from the left (safety analyses) from top to bottom, then the third block column (requirements) from top to bottom, and finally the fourth block column (test specifications).

However, the usual and most practical workflow is from left to right, level by level, starting at the top level.

3. Requirements for an iteration-free V-model

An iteration-free V-model can be applied whenever all requirement, design, and test specifications can be related to a hierarchical product architecture in which all physical hardware and software elements and their respective functions have been defined by top-down decomposition.

In addition, the expected content of each V-model work product must be defined such that it presupposes only content contained or defined in one of the upstream work products.

The work product templates of the autoConform® methodology and software are designed to meet both of these requirements. Making the V-model workflow iteration-free is key for speeding up the product development process significantly.