Defining a Software Unit

Tuesday, November 13, 2018

#Functional Safety    #Automotive SPICE

When striving for compliance with the automotive standards ISO 26262 and Automotive SPICE, a smart approach to better software component quality is to set a common definition of a software unit. Unfortunately, neither standard provides much guidance. Companies striving to comply with these standards need to adopt their own definition using measures and methods that make sense for their organization. As an assessor, this is one of the first questions I ask as I wade into the left side of the V-model for ASPICE or ISO 26262 assessments. If the organization has failed to adopt a definition or if the definition is vague or relative, I will expect to see holes in the unit test and integration test results and processes.

Typically, the unit definition exists in a tension between the requirements of high cohesion and low code complexity versus the practical aspect of managing the design, verification, traceability, and reporting of a very large number of small atomic units.   Many companies adopt a definition based on a source code file and its associated header files. This strategy can work if there are strict guidelines concerning the organization of source code files. It also gives flexibility to the developer to support more complex yet highly related functions into single libraries. Others adopt an atomic strategy where a unit is a single function with a single exit point. This strategy works well for small systems and certainly fits with a strict reading of the ISO 26262 standard. However, it requires rigor at the architecture level to define interfaces that can support such a singularity of functions and classes as well as a strong discipline to maintain design guidelines for larger systems and bigger teams. Software (and software developers) rarely fit all of their designs into neat atomic functions with interfaces that support such intensive modularity.

Which Approach?

How does an organization go about making a unit definition and sticking to it? Is it possible to make one definition for all automotive projects? ISO 26262 part 1 gives us the definition that a unit is “an atomic level software component of the software architecture that can be subjected to stand-alone testing”. This last part of the definition, “subjected to stand-alone testing” gives us guidance. Unfortunately, too often stand-alone unit testing is bypassed because of the argument that the components and/or units require so much system support in order to be tested that the best way to test them is within the integrated system. This approach leads to low coverage, buggy units, and often bloated components.

Testability and Flexibility

I propose approaching the definition from the point of view of testability but with a view toward flexibility. Here are some of the requirements for unit test coverage from ISO 26262 part 6:

  • 100% statement coverage for non-ASIL level (QM) software units
  • 100% statement coverage for ASIL A software units
  • 100% branch coverage for ASIL B and C software units
  • 100% MC/DC scoring for ASIL D software units

ASPICE has less to say about coverage, only stating that coverage goals should be set (SWE.4, BP2 note 2). ASPICE does require traceability of unit test cases to detailed design; while this doesn’t force 100% statement and branch coverage, it does support high test coverage for all static and dynamic behavior of the design.

With regards to cohesion, ISO 26262 states that software components must (a common interpretation of the ++ notation) have high cohesion within each software component. Assuming a component is made up of one or more units, the property of cohesion is passed down to the unit. As a practical rule, this looks like a unit that has a singular purpose.

While testability and cohesion tend to drive the unit definition to atomic, the desire to create a common definition, which could be used across many types of software projects, should drive the definition to something more flexible. Not all solutions fit into a single purpose function.   A more flexible solution is based on a source file + a corresponding header file. Complexity and cohesion could be partially regulated by limiting the number of lines of code (note: this requires a definition of a line of code) per source file. Finally, design guidelines and coding standards, along with a culture of code reviews and inspections, can help propagate good unit design across the organization.

Final Notes

How well does your organization develop software engineering standards like coding and design guidelines? While these activities can be challenging and polarizing, they pay off big down the road in terms of software quality and consistency.  Leaving the definition of the unit to the team’s discretion, for ASPICE and ISO 26262 compliant projects, opens the door to a wide variance of unit design – too wide in this assessor’s opinion.


Do you need to improve your automotive product development, to increase efficiency, or to comply with ASPICE and Functional Safety? You are at the right place.