This week I started reading a paper entitled “Certification cost estimates for future communications radio platforms”. I really like the V model given in the paper as it shows a nice way of capturing software, hardware and an ASIC development in the one V-model. It started me thinking about other nice V-models I have seen and suddenly I had the topic for this month’s safety matters blog.

Figure 1 - V model from Certification cost estimates for future communications radio platforms

The Wikipedia V-model page states that the V-model is an extension of the waterfall model except that the second half of the process after the coding face is bent back upwards after the coding phase. The page continues to state that “the V-model demonstrates the relationship between each phase of the development life-cycle and its associated phase of testing." It’s very hard to argue with any of that.

A page on tryqa.com states that the “V-model means verification and validation model” which is something I hadn’t heard before and I just always thought it was called a V-model because of its shape. What I do agree with is their statement that “testing of the product is planned in parallel with a corresponding phase in the V-model”. This I believe is why functional safety guys love V-models. The fact that for every development stage there is a matching verification or validation step.

To demonstrate the love functional safety people have for V-models below is the one for an ASIC from IEC 61508-2:2010. There is also a V-model in ISO 26262, but the ISO 26262 V model is superimposed on a lot of text and is one of my least favorite of all the V-models I have seen.

Figure 2 V-model from IEC 61508-2:2010 figure 3

While captioned as a V-model for an ASIC it does start with the system requirements specification on the top left which then gets converted into an ASIC requirements specification. Then next on the left of the V you choose an architecture to meet those ASIC specifications. There is a little interplay going on in the top left with bidirectional arrows ensuring that the ASIC architecture matches the system architecture. Thereafter as you move down the left hand side of the V you get more and more detailed design phases. In contrast to what was said earlier regarding the waterfall model you will note that the V-model from IEC 61508 anticipates iteration with arrows pointing back up to a higher point on the V-model. As you move up the right hand side of the V-model you see the real benefit of a V-model in functional safety, in that for each stage on the left hand side of the V there is a matching verification or validation step, before finally you end up with a validated ASIC. This V-model also highlights the difference between verification and validation. Verification is checking the output of a given stage and validation is checking against an intended use case.

Note – E/E/PE stands for electric/electronic/programmable electronic

Functional safety also has the idea of tailoring the process to remove steps which are not relevant for a given development. IEC 61508-3 has an almost identical V-model for software development as shown above for an ASIC development. If the software is very simple you might be able to tailor this V-model from IEC 61508 into something more appropriate. For instance if the software is very simple, there is no requirement to break it artificially into modules just because the standard talks about modules. As usual with functional safety you need to document your design decisions and not do silly things just to follow what the standard seems to require.

Figure 3 - An example of how the software V-model from IEC 61508-3:2010 might be tailored

 

Martin Allen who I follow on LinkedIn recently showed a minimalistic V model. It dispenses with the details on each of the layers (development and its matching verification stage on the opposite side of the V) while still capturing the sense of the V-model.

Figure 4 - A V-model in the style of Martin Allen

Other V-models I like include the one below from an Altera paper entitled 8 Reasons to use FGPAs in IEC 61508 Functional Safety Applications. It has nicely tailored the V-model for an FPGA application with some elements that would normally be on the right-hand side of the V taken across to an expanded left-hand side.

Figure 5 - A nice V-model from Altera

Thorsten Lagenhan who I also follow on LinkedIn has a repetitive V-model in this book Basic guide to automotive functional safety. Rather than getting a validated system at the top right of the first V you get a prototype which is then the starting point for a new V.

Figure 6 - Thorsten Langenhan V-model

I am writing this blog at the end of July for publishing in August. It is the week before my holidays so a light blog like this one suited me. When I return from my holidays, I really must tackle some blogs I have kept postponing...

1) Verilog software

2) Are all random failures really systematic?

Item 2) might then provide a platform for part 2 of a blog on whether failures due to noise should be counted as part of the PFH (probability of dangerous failure per hour) or be considered as systematic failures.

Until next time...

Anonymous