Resilient and ISO 26262 (Road Vehicles)

ISO 26262 governs functional safety for road vehicle E/E systems. This page lists the Part 6 (software development) objectives where Resilient features contribute evidence, and the gaps that remain the integrator’s responsibility across ASIL A–D.

Table of contents

Honest framing

Resilient is not ISO 26262 compliant and not an ISO 26262-qualified software tool. No “Confidence in Software Tool” (TCL/TD) classification has been performed for the compiler. No ASIL-D project has shipped on Resilient.

The mapping below is the realistic path for a team that chooses to evaluate Resilient: the language reduces evidence burden on specific Part 6 objectives, but tool confidence classification per ISO 26262-8:2018 §11 must be completed before Resilient artifacts can be used as primary verification evidence on an ASIL-rated item.

Part 6 objectives Resilient contributes to

  • §7.4.5 (Software architectural design — verification). Function contracts capture architectural invariants directly in source. When the verifier discharges them, the invariant is proven for all inputs in the contract’s domain.

  • §8.4 (Software unit design and implementation). The language’s restrictions — no implicit conversions, no raw pointer arithmetic, no goto, static-only heap — eliminate whole classes of MISRA-C-style defects by construction.

  • §9.4 (Software unit verification). SMT-LIB2 certificates re-verifiable under stock Z3 act as primary evidence of unit-level property satisfaction (subject to tool qualification).

  • §10.4 (Software integration and verification). Contracts that cannot be discharged at compile time become typed runtime asserts that act as instrumented oracles for integration testing.

  • Coding guidelines (Annex A, MISRA C:2012). Most of the rule classes MISRA C imposes on C are eliminated by Resilient’s type system rather than enforced by linter. See Resilient vs MISRA C.

ASIL-specific notes

  • ASIL A / B. The pre-qualification Resilient features contribute to objectives most clearly: contract-driven verification, deterministic execution, and certificate re-verification.

  • ASIL C / D. Tool qualification is mandatory. Until the Resilient compiler completes a TCL/TD classification, Resilient output is supplementary evidence, not primary.

Gaps the integrator still owns

  • Tool confidence (ISO 26262-8:2018 §11). Not started.
  • Item-level safety analysis (HARA, FTA, FMEA). Unaffected by language choice.
  • Hardware-software interaction. No certified RTOS integration documented.
  • Configuration management (Part 8 §7). Standard SCM applies.
  • Verification of software safety mechanisms. Resilient’s live { } blocks are a language mechanism, not a certified safety mechanism — system-level analysis still required.

See also