Unit testing in SPICE and ISO 26262

This is the first of a couple of posts dealing with testin in Automotive SPICE and ISO 26262 projects. In this post we will focus on unit testing.

Looking in the Automotive SPICE Assessment Model (PAM) we get only vague guidance on what is expected.

In the notes to this base practice it is stated that verification criteria must include test specification including unit test cases (if required by contract) and that coverage goals should be defined.

As an assessor I see three different approaches. All of which I regard as valid although they have different strengths and weaknesses. See the table below:

Test_SWOT

 

 

 

 

ISO 26262 is much more specific.

It states that requirements based and test should be performed (Part 6, table 10) and that the analysis for deriving test cases should cover requirements, equivalence classes and boundary values (table 11).

The standard further states that a purpose of the coverage criteria are to demonstrate that there is no unintended functionality (para 9.4.5).

The coverage criteria are:

– ASIL A: Statement coverage
– ASIL B – C: Branch coverage
– ASIL D: Modified condition / decision coverage

From the above there are some implications. First unit testing of safety mechanisms should be black box (on the unit level) and based on requirements. Secondly the coverage requirement will lead to longer test vectors especially for ASIL D, see the example below.

Test vector

 

 

 

 

 

 

 

 

Can you have the same unit test approach for a SPICE and ISO 26262 project? Yes, definetely but that would mean more effort on the SPICE “side” than what is typical in a non-safety project.

To get good coverage when black box testing units you should aim for a cohesive design. Each unit has a well defined task defined by one or a few requirements.

If your architectural pattern forces a separation of a safety mechanism into parts like:
– fault detection
– fault handing
– safety timing (typically on integration level)
You should consider splitting requirements into separate parts.

What is your experience with unit testing in ISO 26262. What questions are you facing?