Verification and validation are important but separate topics within functional safety. However, the terms of often misused and mixed up including in a recent draft functional safety standard I was reading. In a nutshell, validation is the final verification that the item achieves its ultimate goals.

In case the rather dry nature of this topic puts you off I would advise you not to miss the video at the end of this blog as it is a good one.

Looking at a typical V model we see design tasks on the left and verification and validation items on the right. The top right shows the validation testing. The V model below is from IEC 61508-2:2010.

While the above V-model is for a digital ASIC it can also be interpreted for a mixed signal or analog design. Simulations done before tape out are examples of verification items while measurements done on the silicon are validation items with reliability testing including HTOL (high temperature operating life), HAST (highly accelerated stress testing), etc. being particularly important as they demonstrate suitability for the final application.

There is a nice definition in Continuous Engineering for Dummies – “Verification checks to see if the design achieves the defined requirements and complies with standards (in other words, that you are building the system right). Validation checks to see if the design meets the end-user needs (in other words, that you are building the right system)". This definition makes it clear that verification can be applied at any level and for any process step. So, for instance if you have to do an FMEDA for an IC you can verify that the company process was followed when producing the FMEDA and that all the things you would expect to see in the FMEDA are there. Similarly, if you have a new product development process you can verify that all the applicable steps were followed.

Other definitions that catch my eye include the below from J3061 the Cybersecurity guidebook for cyber physical vehicle systems which emphasizes the internal vs external dimensions of verification and validation.

To some extent in IEC 61508 the term deviates from the above where for instance software validation is given as “confirming by examination and provision of objective evidence that the software satisfies the software safety requirements specification” – See IEC 61508-4:2010 clause 3.8.2. The use of this definition is justified in IEC 61508-3:2010 clause 7.9.1 as “Checking whether the safety requirements specification is itself correct is carried out by domain experts”. To some extent this is similar to the case with ICs where validation testing for Analog Devices is generally not able to prove that it will perform in the safety function as intended in contrast to the ideal case from the video below.

Philip Koopman in his book Better Embedded System Software also describes V&V (verification and validation) when he says on page 49 “Testing involves the actual execution of a piece of software to see whether its behaviour conforms to requirements, designed behaviour, and other expectations. It is distinct from other forms of verification and validation in that it is actually based on what the code does, as opposed to what reviewers think the code might do” which makes it clear that testing is a form of verification. He later continues “verification is ensuring that the design steps are being followed properly, and roughly corresponds to the notion of backward trace-ability (knowing you are adhering to the outputs of the previous design step.)The blanket term V&V(verification and validation) is often used to describe any activity that falls in the general arena of making sure the design process is on track.…..It is the total effort of V&V that matters…..”.

I could continue with lots more examples but I will give one more from UL 1998 and leave it at that.

Hopefully the differences are now clear in your head.

This week’s video is at and shows the validation of a nuclear transport cask design. Verification items would have been the thickness of the steel, the air tightness of the cask etc. but the ultimate validation is to discover does it meet the application requirements. I really like this video because while the V model at the top shows validation testing done vs the requirements specification the validation testing from the video bypasses the requirements specification and goes directly back to the intended use cases.