29. ISO 26262 6-Method Tables¶

29.1. Table 1 Topics to be covered by modelling and coding guidelines¶

The Rust project has extensive measures (lints and tests) in place to assure quality and consistency of the codebase. The certified core library uses the same implicit standards as are ensured in the upstream codebase, to minimize divergence. Increased divergence from upstream leads to a higher maintenance burden and is a source of potential bugs.

As such, the certified core library does not have a coding standard.

29.2. Table 2 Notations for software architectural design¶

Not applicable, as there is no architecture

29.3. Table 3 Principles for software architectural design¶

Not applicable, as there is no architecture

29.4. Table 4 Methods for the verification of the software architectural design¶

Not applicable, as there is no architecture

29.5. Table 5 Notations for software unit design¶

No.	Notations	ASIL B	ASIL D	Justification
1a	Natural language	++	++	Applied, see core/safety-plan/requirements.html#architecture-and-software-design
1b	Informal notations	++	+	Applied, see core/safety-plan/requirements.html#architecture-and-software-design
1c	Semi-formal notations	+	++	Not applied, functions in scope are of limited functionality, no dependencies to other components etc.
1d	Formal notations	+	+	No formal methods applied

29.6. Table 6 Design principles for software unit design and implementation¶

No.	Principle	ASIL B	ASIL D	Justification
1a	One entry and one exit point in subprograms and functions	++	++	Applied, multiple returns only for specific error handling cases
1b	No dynamic objects or variables, or else online test during their creation	++	++	Applied, no dynamic memory in library functions allocated
1c	Initialization of variables	++	++	Applied, compiler forbids use of uninitialized variable bindings
1d	No multiple use of variable names	++	++	Applied, even though shadowing is possible, library functions are very short, no shadowing taking place as per community guidelines
1e	Avoid global variables or else justify their usage	+	++	Applied, core lib is not stateful, no global variables inside
1f	Restricted use of pointers	++	++	Applied, for certain low level operations it might be necessary
1g	No implicit type conversions	++	++	Applied, rust does not allow implicit type conversions
1h	No hidden data flow or control flow	++	++	Applied, no dependencies outside of the library, no hidden flows
1i	No unconditional jumps	++	++	Applied, no unconditional jumps in rust
1j	No recursions	+	++	Not applied, Unconditional recursion is denied (except for #[lang_item]s whose bodies are replaced by the compiler), Conditional recursion is allowed

29.7. Table 7 Methods for software unit verification¶

No.	Methods	ASIL B	ASIL D	Justification
1a	Walk-through	+	o	Not applied, 1c applied
1b	Pair-programming	+	+	Not applied, 1c applied
1c	Inspection	++	++	Applied, via community process on contribution to upstream
1d	Semi-formal verification	+	++	Not applied, as there is no semi-formal notations/specification
1e	Formal verification	o	+	Not applied, as there is no formal specification
1f	Control flow analysis	+	++	Applied, symbol review via compiler outpout (subsetting)
1g	Data flow analysis	+	++	Not applied, no internal data flow to analyse, no global states, all only via the clear interfaces
1h	Static code analysis	++	++	Applied, see core/safety-plan/testing-plan.html#rustc-lints
1i	Static analyses based on abstract interpretation	+	+	Not applied, 1h applied instead
1j	Requirements-based test	++	++	Applied, all tests are based on the specification
1k	Interface test	++	++	Applied, all tests are also interface tests, as this is the only type of testing possible
1l	Fault injection test	+	++	Applied, tests cases also assume faults etc., but HW faults are out of scope
1m	Resource usage evaluation	+	++	Not applied, integrator responsibility, as only a library
1n	Back-to-back comparison test between model and code, if applicable	+	++	Not applied, as no model based development

29.8. Table 8;Methods for deriving test cases for software unit testing¶

No.	Methods	ASIL B	ASIL D	Justification
1a	Analysis of requirements	++	++	Applied, requirements/specification is the source of the testing
1b	Generation and analysis of equivalence classes	++	++	Partially applied, the test cases in coretests are crafted with a lot of care. Ferrous Systems did not do a full review to ensure boundary and extreme values are always tested. But achieving 100% line coverage will ensure all code paths have been executed and no untested code exists due to no test with a specific input.
1c	Analysis of boundary values	++	++	Partially applied, the test cases in coretests are crafted with a lot of care. Ferrous Systems did not do a full review to ensure boundary and extreme values are always tested. But achieving 100% line coverage will ensure all code paths have been executed and no untested code exists due to no test with a specific input.
1d	Error guessing based on knowledge or experience	+	+	Partially applied, the test cases in coretests are crafted with a lot of care, but not all functions include also error guessing