Safety-Critical-Rust-Consortium · PLeVasseur · Mar 16, 2026 · Feb 11, 2026 · Feb 25, 2026 · Feb 25, 2026
diff --git a/arewesafetycriticalyet.org/docs/main/intro.md b/arewesafetycriticalyet.org/docs/main/intro.md
@@ -3,3 +3,44 @@ sidebar_position: 1
 ---
 
 # Are We Safety Critical Yet?
+
+## What is safety-critical?
+
+A piece of software or a standalone ECU cannot be 'safe' in isolation because they cannot inherently cause physical harm. Hazards arise only when these elements control or take action in the environment (real world) and are e.g. capable of injuring people or environmental/financial damage. Therefore, if something is safety-critical is defined by it’s context.
+
+If the software does contribute to a hazard, it is deemed safety-critical. The contribution of the software to these hazards is determined/designed through the overall product life cycle.
+Note to delimit from Cybersecurity: Functional Safety generally stems from malfcuntions, while Cybersecurity stems from malicious outside actors.
+
+## How to judge safety-critical readiness of “Rust”?
+
+In general the software is presumed to be safe by conforming to the relevant safety-standard in your industry (context!).
+It should be mentioned, that conformity to a standard (like ISO 26262) is a proxy for safety, but they are not identical, as conform systems can be unsafe, as well as non-conforming systems can be safe.
+
+For this context safety-critical readiness is judged by how well the requirements of the specific standards can be achieved when using Rust as programming language to implement safety-critical software. This includes the language itself, the toolchain as well as overall ecosystem.
+
+## Readiness in terms of standards
+
+In the following the safety-critical readiness is judged by looking at the specific requirements of relevant industry standards and how well an organization can conform to them when using Rust. For example there might some direct requirement that a programming language has to conform to e.g. a strong typing system. This directly is required by Rust. There might are also indirect requirements, e.g. that certain test coverage metrics need to be achieved - here we would judge how well the existing toolchain, ecosystem etc. can be used to satisfy these requirements.
+
+We will be using the following scale:
+🟢 Well supported with no extra effort
+🟡 Possible with some manual extra effort
+🔴 Possible with high manual extra effort
+
+Note: Additionally it has to be stated, that there is always room for interpretation in those standards. In some standards an assessor will have to judge at the end of the development lifecylce, if conformity to the standard can be claimed.
+
+### ISO 26262
+
+🟡 Possible with some manual effort
+TODO: add executive summary
+
+See detailed explanation:
+[ISO 26262 vs. Rust detailed gap analysis](iso26262.md)
+
+### IEC 61508
+
+TODO
+
+### DO-178C
+
+TODO
diff --git a/arewesafetycriticalyet.org/docs/main/iso26262-6reference.png b/arewesafetycriticalyet.org/docs/main/iso26262-6reference.png
diff --git a/arewesafetycriticalyet.org/docs/main/iso26262.md b/arewesafetycriticalyet.org/docs/main/iso26262.md
@@ -0,0 +1,175 @@
+---
+sidebar_position: 1
+---
+# ISO 26262 vs. Rust Gap Analysis
+
+The ISO 26262 is a standard that is split into 13 parts. Management, System-level, Hardware-level, Software-Level and supporting.
+Conformity to the ISO 26262 standard reached, by conforming to each single requirement. 
+In the following for each clause of the Software part it is judged how well it is possible to conform to each requirement.
+Most interesting is of course the Software part. But the context of the other parts matter.
+
+Note: ISO 26262 allows for tailoring. If a requirement can't be met literally (ior doesn't make sense in the given context), it can be satisfied by providing a sound technical argumentation proving that the intent of the requirement is met or exceeded by other means. It is recommended to discuss that with the assessor apriori though.
+The best way to describe the readiness is here along the reference phase model.
+
+![ISO 26262 software development phase reference model](iso26262-6reference.png)
+
+## 2 Management of FuSa
+
+TODO
+
+### 🟢 6-5 General topics for the product development at the software level
+
+Table 1 — Topics to be covered by modelling and coding guidelines
+
+| ID | Method | Solution: Rust Native or Tool | Readiness |
+| :--- | :--- | :--- | :--- |
+| **1a** | Enforcement of low complexity | `clippy::cyclomatic_complexity` | 🟢 |
+| **1b** | Use of language subsets | Coding Guidelines (in progress) | 🟡 |
+| **1c** | Enforcement of strong typing | inherent | 🟢 |
+| **1d** | Use of defensive implementation techniques | possible e.g. Option'<T'>, Result<T, E> | 🟢 |
+| **1e** | Use of well-trusted design principles | n.A. for Rust | n.A. |
+| **1f** | Use of unambiguous graphical representation | n.A. for Rust | n.A. |
+| **1g** | Use of style guides | clippy can enforce rules | 🟢 |
+| **1h** | Use of naming conventions | clippy can enforce rules | 🟢 |
+| **1i** | Concurrency aspects | native compile-time enforcable | 🟢 |
+
+General considerations based on experience:
+
+- IDE & Debugging support
+    - dependent on target...
+
+### 🟡 6-6 Safety requirements
+
+- Traceability establishment from requiremets to implementation 🟢
+    - Tooling exists: mantra
+    - ... TODO
+
+### 🟡 6-7 Software Architectural Design
+
+Table 3 — Principles for software architectural design
+
+| ID | Principle | Solution: Rust Native or Tool | Readiness |
+| :--- | :--- | :---: | :---: |
+| **1a** | Appropriate hierarchical structure of the software components | possible | 🟢 |
+| **1b** | Restricted size and complexity of software components | possible | 🟢 |
+| **1c** | Restricted size of interfaces $^a$ | possible | 🟢 |
+| **1d** | Strong cohesion within each software component $^b$ | possible | 🟢 |
+| **1e** | Loose coupling between software components $^{b,c}$ | possible | 🟢 |
+| **1f** | Appropriate scheduling properties $^d$ | scheduler available (RTIC, ) - qualification unknown | 🟡 |
+| **1g** | Restricted use of interrupts $^a$ | possible | 🟢 |
+| **1h** | Appropriate spatial isolation of the software components | TBD | TBD |
+| **1i** | Appropriate management of shared resources $^e$ | borrow checker/Mutexes available | 🟢 |
+
+Table 4 — Methods for the verification of the software architectural design
+
+| ID | Principle | Solution: Rust Native or Tool | Readiness |
+| :--- | :--- | :---: | :---: |
+| **1a** | Walk-through of the design $^a$ | n.A. for Rust | n.A. |
+| **1b** | Inspection of the design $^a$ | n.A. for Rust | n.A. |
+| **1c** | Simulation of dynamic behaviour of the design | n.A. for Rust | n.A. |
+| **1d** | Prototype generation | n.A. for Rust | n.A. |
+| **1e** | Formal verification | creusat, ... TBD | 🟡 |
+| **1f** | Control flow analysis $^b$ | TBD | TBD |
+| **1g** | Data flow analysis $^b$ | TBD | TBD |
+| **1h** | Scheduling analysis | WCET available | 🟡 |
+
+- Model based code generation tools 🔴
+    - TODO: no tools exist so far afaik
+- upper estimation of required resources? (execution time, storage, communication ressources)
+    - TODO what exists here?
+
+### 🟡 6-8 Software unit Design & Implementation
+
+Table 6 — Design principles for software unit design and implementation
+
+| ID | Principle | Solution: Rust Native or Tool | Readiness |
+| :--- | :--- | :---: | :---: |
+| **1a** | One entry and one exit point in subprograms and functions $^a$ | TBD clippy enforcable? panic handler? needs argumentation | TBD |
+| **1b** | No dynamic objects or variables, or else online test during their creation $^a$ | use no_std, heapless, borrow checker | 🟢 |
+| **1c** | Initialization of variables | TBD clippy enforcable | TBD |
+| **1d** | No multiple use of variable names $^a$ | shadowing possible, TBD clippy enforcable | TBD |
+| **1e** | Avoid global variables or else justify their usage $^a$ | TBD clippy enforcable | TBD |
+| **1f** | Restricted use of pointers $^a$ | disallow safe rust - pointer usage discouraged | 🟢 |
+| **1g** | No implicit type conversions $^a$ | inherent | 🟢 |
+| **1h** | No hidden data flow or control flow | TBD clippy enforcable | TBD |
+| **1i** | No unconditional jumps $^a$ | TBD clippy enforcable | TBD |
+| **1j** | No recursions | TBD clippy enforcable | TBD |
+
+- tbd: ARM FuSa Library support
+- tbd: support of ARM Cortex R based microcontroller
+
+### 🟡 6-9 Software unit verification
+
+Table 7 — Methods for software unit verification
+
+| ID | Method | Solution: Rust Native or Tool | Readiness |
+| :--- | :--- | :---: | :---: |
+| **1a** | Walk-through $^a$ | n.A. for Rust | n.A. |
+| **1b** | Inspection $^a$ | n.A. for Rust | n.A. |
+| **1c** | Pair-programming $^a$ | n.A. for Rust | n.A. |
+| **1d** | Semi-formal verification | + | + |
+| **1e** | Formal verification | o | o |
+| **1f** | Control flow analysis $^{b,c}$ | + | + |
+| **1g** | Data flow analysis $^{b,c}$ | + | + |
+| **1h** | Static code analysis $^d$ | TBD partially clippy, TBD how far Coding Guidelines | 🟡 |
+| **1i** | Static analyses based on abstract interpretation $^e$ | + | + |
+| **1j** | Requirements-based test $^f$ | inherent cargo test | 🟢 |
+| **1k** | Interface test $^g$ | inherent cargo test | 🟢 |
+| **1l** | Fault injection test $^h$ | TBD | TBD |
+| **1m** | Resource usage evaluation $^i$ | TBD | TBD |
+| **1n** | Back-to-back comparison test $^j$ | TBD | TBD |
+
+Table 9 — Structural coverage metrics at the software unit level
+
+| ID | Method | Solution: Rust Native or Tool | Readiness |
+| :--- | :--- | :---: | :---: |
+| **1a** | Statement coverage | llvm/Tool TBD | 🟢 |
+| **1b** | Branch coverage | llvm/Tool TBD | 🟢 |
+| **1c** | MC/DC (Modified Condition/Decision Coverage) | no tool support yet | 🔴 |
+
+- Coverage instrumentation 🟡
+    - Exists for x86 
+    - For embedded targets TBD
+- General test tooling and report generation 🟢
+    - inherently supported by cargo test
+    - report generation TBD
+- Tracebility tooling between test case definition and test case specification 🟡
+    - TBD
+
+### 🟡 6-10 Software unit integration & verification
+
+Table 10 — Methods for verification of software integration
+
+| ID | Method | Solution: Rust Native or Tool | Readiness |
+| :--- | :--- | :---: | :---: |
+| **1a** | Requirements-based test $^a$ | TBD | TBD |
+| **1b** | Interface test | TBD | TBD |
+| **1c** | Fault injection test $^b$ | TBD | TBD |
+| **1d** | Resource usage evaluation $^{c, d}$ | TBD | TBD |
+| **1e** | Back-to-back comparison test $^e$ | TBD | TBD |
+| **1f** | Verification of the control flow and data flow | TBD | TBD |
+| **1g** | Static code analysis $^f$ | TBD | TBD |
+| **1h** | Static analyses based on abstract interpretation $^g$ | TBD | TBD |
+
+Table 12 — Structural coverage at the software architectural level
+
+| ID | Method | Solution: Rust Native or Tool | Readiness |
+| :--- | :--- | :---: | :---: |
+| **1a** | Function coverage $^a$ | llvm/Tool TBD | 🟢 |
+| **1b** | Call coverage $^b$ | llvm/Tool TBD | 🟢 |
+
+### 🟡 6-11 Testing embedded software
+
+Table 14 — Methods for tests of the embedded software
+
+| ID | Method | Solution: Rust Native or Tool | Readiness |
+| :--- | :--- | :---: | :---: |
+| **1a** | Requirements-based test | TBD | TBD |
+| **1b** | Fault injection test $^a$ | TBD | TBD |
+
+### Annex C
+
+## 🔴 8 Supporting Processes
+
+- Tool Qualification 🔴
+    - TODO: keep in mind the usage of tools requires tool qualification. Depending on your usage, context, processes, this might require you to qualify the tool.