Is there a secret sauce for functional safety? I have been asked if there was only one thing from functional safety that I think should be applied to every product development, what would it be. 

My answer: Rigorous requirements management.

Requirements management is important for any project but functional safety takes it to a new level and insists on minimum standards.

In theory, requirements capture and management are easy and if you read the books on the topic it all looks good. However, when you try to apply it you will often run into problems. The advent of tools such as Jama and Doors have taken some of the hassle out of requirements management but there is still a lot of work to do.

All functional safety standards have requirements related to the properties of individual requirements and to the set of requirements.

Individual requirements need to have properties such as

  • Correct – technically and legally possible
  • Feasible – can be accomplished within cost and schedule
  • Clear – unambiguous and not confusing
  • Verifiable – it can be determined that the system meets the requirements
  • Traceable – can be uniquely identified and tracked
  • Abstract – does not impose a specific design solution on the layer below

While the set of requirements needs to have properties including

  • Complete – expresses a whole idea, all requirements are present
  • Consistent – no conflicting requirements
  • Unique – each requirement is only specified once
  • Modular – requirements that belong together are put close together
  • Structured – top down and traceable

There are differences between the standards such as for instance the avionics standard D0-178C looking for one requirement for every 25 lines of code and no unreachable or dead code but in general they all require the above.

Aside from the properties of the requirements there are requirements in IEC 61508 that insist on requirements traceability such as the table below from IEC 61508-3:2010.

For an IC forward traceability implies that you should be able to trace from the top-level requirements to the block on silicon which implements it and the test on real silicon which verifies that it was met. The purpose being that if it was worth writing down a requirement then it is worth making sure it has been implemented. In turn, if you have design blocks which don’t trace back to top level requirements it might represent gold plating on the part of the designer or missing top-level requirements.

Backwards traceability means that you can trace back from a test performed on the silicon to the top level requirement which required that test. Amongst the advantages of backwards traceability is that fact that if you discover a problem with a test you can immediately know which top level requirements might be impacted. If you have a test that doesn’t trace back to a top-level requirement it demonstrates that you are probably missing a top-level requirement, otherwise you are doing unnecessary testing. Tools such as Jama can provide compliance matrices to demonstrate that there are no untraceable requirements.

One place where I believe most of the standards fall down in terminology is in mixing up the terms requirements and specifications. Requirements express what needs to be achieved and specifications express one means of achieving it. Many of the standards however use the terms interchangeably and even use terms such as requirements specifications.

An interesting future talk might be functional safety and Agile where requirements management needs to be considered.

Apologies if I have used the six red lines video already but it is good so I will take the risk -

For next time, the discussion will be on the “soft errors”.