Rule A1-2-1 (required, toolchain, non-automated)

When using a compiler toolchain (including preprocessor, compiler itself, linker, C++ standard libraries) in safety-related software, the tool confidence level (TCL) shall be determined. In case of TCL2 or TCL3, the compiler shall undergo a “Qualification of a software tool”, as per ISO 26262-8.11.4.6 [6].

Rationale

Vulnerabilities and errors in the compiler toolchain impact the binary that is built.

Example

The following mechanisms could help to increase the Tool error Detection (TD) and thus allowing to reduce the Tool Confidence Level:

  1. Achievement of MC/DC code coverage on generated project assembly code
  2. Diverse implementation of safety requirements at software or even at system level (e.g. two micro-controllers)
  3. Usage of diverse compilers or compilation options
  4. Diversity at the level of operating system
  5. Extensive testing (e.g. equivalence class testing, boundary value testing), testing at several levels (e.g. unit testing, integration testing) Note that in most automotive applications, the compiler is evaluated TCL3 or TCL2. In case of TCL2 or TCL3, the following are typically performed (by compiler vendor or by a project), see table 4 in ISO 26262-8:
  6. Evaluation of the tool development process
  7. Validation of the software tool, by performing automatic compiler tests that are derived from the C++ language specification

## See also
ISO 26262-8 [6]: 11 Confidence in the use of software tools.

Rule A1-4-1 (required, implementation / verification, non-automated)Code metrics and their valid boundaries shall be defined and code
shall comply with defined boundaries of code metrics.

## Rationale
Code metrics that concern i.e. project’s structure, function’s complexity and size of a
source code shall be defined at the project level. It is also important to determine
valid boundaries for each metric to define objectives of the measurement.
Source code metrics needs to be measured for the project and comply with defined
boundaries. This gives valuable information whether the source code is complex,
maintainable and efficient.

See also

HIC++ v4.0 [9]: 8.3.1 Do not write functions with an excessive McCabe Cyclomatic Complexity. HIC++ v4.0 [9]: 8.3.2 Do not write functions with a high static program path count. HIC++ v4.0 [9]: 8.2.2 Do not declare functions with an excessive number of parameters.