final touches and editing

Author: fried-gluttony

arewesafetycriticalyet.org/docs/main/intro.md

@@ -34,7 +34,7 @@ The following evaluation examines how well specific safety-standard requirements
 
 🟡 Achievable with moderate additional effort
 
-Rust's core language features-memory safety, strong typing, and data race prevention provide excellent basis for ISO 26262 compliance. However, critical gaps exist in qualified tools, control/data flow analysis, and qualified RTOS/HAL/PAC support. These require individual qualification efforts and are barriers for production use.
+Rust's core language features - memory safety, strong typing, and data race prevention - provide excellent basis for ISO 26262 compliance. However, critical gaps exist in qualified tools, control/data flow analysis, and qualified RTOS/HAL/PAC support. These require individual qualification efforts and are barriers for production use.
 
 [Detailed Rust vs. ISO 26262 gap analysis](iso26262.md)
 

arewesafetycriticalyet.org/docs/main/iso26262.md

@@ -4,7 +4,7 @@ sidebar_position: 1
 # ISO 26262 vs. Rust Gap Analysis
 
 ISO 26262 is a standard comprising 12 parts, covering Vocabulary, Management, System-, Hardware-, and Software-Level, as well as supporting processes and general guidelines.
-Compliance to the standard can be claimed by fulfilling each single requirement, unless it has been tailored according to part 2 or a sound technical rationale is given.
+Compliance with the standard can be claimed by fulfilling each single requirement, unless it has been tailored according to part 2 or a sound technical rationale is given.
 
 The following analysis evaluates specifically the readiness of Rust to meet the requirements of Part 6: "Product development at the software level.", following the software reference phase model (V-Model) and corresponding clauses. The structure is based around the normative tables and an additional section on "general considerations" for each clause. These considerations are derived from practical experience and address indirect requirements or ecosystem constraints - while not explicitly mentioned in the standard, they are critical for successful implementation.
 
@@ -16,7 +16,7 @@ Contributions and corrections are welcome via [pull request](https://github.com/
 
 **Note:** Where specific tools are referenced below, a comprehensive curated list is maintained [by the Tooling subcommittee](https://github.com/rustfoundation/safety-critical-rust-consortium/tree/main/subcommittee/tooling/tool-list).
 
-![Diagram illustrating the ISO 26262 Part 6 software development phase reference model. The image shows the V-Model lifecycle, with phases for specification, architectural design, unit design and implementation, unit verification, integration and verification, and testing of embedded software. Each phase is connected by arrows indicating progression and feedback loops, highlighting the relationship between development and verification activities required for safety-critical automotive software according to ISO 26262.](iso26262-6reference.png)
+![Diagram illustrating the ISO 26262 Part 6 software development phase reference model. The image shows the V-Model lifecycle, with phases for specification of safety requirements, architectural design, unit design and implementation, unit verification, integration and verification, and testing of embedded software. Each phase is connected by arrows indicating progression and feedback loops, highlighting the relationship between development and verification activities required for safety-critical automotive software.](iso26262-6reference.png)
 
 ### 🟢 6-5 General topics for the product development at the software level
 
@@ -37,7 +37,7 @@ Table 1 — Topics to be covered by modelling and coding guidelines
 **General considerations:**
 
 - Rust achieves requirement 5.4.2 The criteria that shall be considered when selecting a design, modelling or programming language are: 🟢
-    - an unambiguous and comprehensible definition; 🟢
+    - an unambiguous and comprehensible definition, by the Ferrocene Language Specification; 🟢
     - suitability for specifying and managing safety requirements according to ISO 26262-8:2018 if modelling is used for requirements engineering and management; ⚪ (no model-based Rust code generation available)
     - support the achievement of modularity, abstraction and encapsulation; and 🟢
     - support the use of structured constructs. 🟢
@@ -64,8 +64,8 @@ This clause is not impacted by the programming language choice much.
 **General considerations:**
 
 - Requirements traceability tooling 🟢
-    - Multiple tools supported convenient requirement traceability to implementation (e.g. sphinx-needs, mantra) 
-    - Those integrates well with Rust/Cargo project and allow for automatic report generation
+    - Multiple tools support convenient requirement traceability to implementation (e.g. sphinx-needs, mantra) 
+    - These integrate well with Rust/Cargo project and allow for automatic report generation
 
 ### 🟡 6-7 Software architectural design
 
@@ -75,7 +75,7 @@ Table 3 — Principles for software architectural design
 
 | ID | Principle | Solution: Rust Native or Tool | Readiness |
 | :--- | :--- | :--- | :--- |
-| **1a** | Appropriate hierarchical structure of the software components | (Architecture) **encouraged** by Rusts module system (`mod` hierarchy) and visibility rules (pub, pub(crate)) | 🟢 |
+| **1a** | Appropriate hierarchical structure of the software components | (Architecture) **encouraged** by Rust's module system (`mod` hierarchy) and visibility rules (pub, pub(crate)) | 🟢 |
 | **1b** | Restricted size and complexity of software components | (Architecture) **neutral** Rust does not impose this logical design constraint | ⚪ |
 | **1c** | Restricted size of interfaces | (Architecture) **neutral** Rust does not impose this logical design constraint | ⚪ |
 | **1d** | Strong cohesion within each software component | (Architecture) **neutral** Rust does not impose this logical design constraint | ⚪ |
@@ -92,18 +92,18 @@ Table 4 — Methods for the verification of the software architectural design
 | **1a** | Walk-through of the design | (Process) **improved** by Rust's explicit ownership annotations, error handling (Result/Option), and type signatures make control flow and data dependencies easier visible | 🟢 |
 | **1b** | Inspection of the design | (Process) **improved** see entry 1a. | 🟢 |
 | **1c** | Simulation of dynamic behavior of the design | (Tools) **not available** no Rust-specific architectural simulation tool exists. Standard approaches (software-in-the-loop testing, hardware emulation via Renode) work | 🟡 |
-| **1d** | Prototype generation | (Process) **neutral** no specific gap | 🟢 |
+| **1d** | Prototype generation | (Process) **neutral** no specific gap | ⚪ |
 | **1e** | Formal verification | (Tools) **partially available** unqualified tools exist, e.g. creusot or kani | 🟡 |
-| **1f** | Control flow analysis | (Tools) **partially available** at MIR-level e.g. by llvm-flow | 🟡 |
+| **1f** | Control flow analysis | (Tools) **partially available** at MIR-level by e.g. llvm-flow | 🟡 |
 | **1g** | Data flow analysis | (Tools) **not available** | 🔴 |
 | **1h** | Scheduling analysis | (Tools) **partially** WCET analysis tool available, target support unclear | 🟡 |
 
 **General considerations:**
 
 - Model based code generation tools 🔴
-    - No Rust code generation from modeling tools (e.g. Simulink/TargetLink) exist
+    - No Rust code generation from modeling tools (e.g. Simulink/TargetLink) exists
 - Software partitioning and freedom from interference 🟡
-    - Logical isolation is encouraged at the software level through  Rust's ownership and module system
+    - Logical isolation is encouraged at the software level through Rust's ownership and module system
     - Temporal and spatial freedom from interference still requires hardware mechanisms (MPU/MMU) or a hypervisor
 - Upper estimation of required resources (execution time, storage, communication resources) 🟡
     - Timing: analysis tools (e.g. AbsInt aiT) supported
@@ -122,13 +122,13 @@ 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 | (Architecture) **possible, not encouraged** Rust idiomatically uses early returns and the ? operator for error propagation, resulting in multiple exit points. This is widely considered safer than deeply nested single-return patterns, as each exit point has explicit type-checked error handling. An assessor may accept this with justification; if not, a custom clippy lint or coding guideline can restrict it. | 🟢 |
-| **1b** | No dynamic objects or variables, or else online test during their creation | (Architecture) **encouraged** by no_std Rust without a global allocator statically guarantees the absence of heap allocation at compile time. For cases requiring dynamic-like containers, the heapless crate provides fixed-capacity collections. With a global allocator enabled, a fallible allocation API exists (try_reserve), but online testing of allocation failure remains the developer's responsibility. | 🟢 |
+| **1b** | No dynamic objects or variables, or else online test during their creation | (Architecture) **encouraged** by no_std Rust without a global allocator statically guarantees the absence of heap allocation at compile time. For cases requiring dynamic-like containers, the heapless crate provides fixed-capacity collections. With a global allocator enabled, a fallible allocation API exists (try_reserve), but online testing of allocation failure remains the developer's responsibility (and would require qualification). | 🟢 |
 | **1c** | Initialization of variables | (Language) **inherent** feature, safe Rust doesn't allow reading uninitialized variables | 🟢 |
 | **1d** | No multiple use of variable names | (Language) **inherent** Rust encourages variables shadowing, but clippy can disallow it (clippy::shadow_reuse) | 🟢 |
 | **1e** | Avoid global variables or else justify their usage | (Language) **inherent** feature of safe Rust, mutable global variables are considered unsafe | 🟢 |
-| **1f** | Restricted use of pointers | (Language) **inherent** feature of safe Rust, | 🟢 |
-| **1g** | No implicit type conversions | (Language) **inherent** enforced of safe Rust | 🟢 |
-| **1h** | No hidden data flow or control flow | **largely inherent** as Rust prevents most sources of hidden data flow: no global mutable state without explicit synchronization, no implicit type conversions, no pointer aliasing. Control flow is explicit | 🟡 |
+| **1f** | Restricted use of pointers | (Language) **inherent** feature of safe Rust | 🟢 |
+| **1g** | No implicit type conversions | (Language) **inherent** enforced in safe Rust | 🟢 |
+| **1h** | No hidden data flow or control flow | **largely inherent** as Rust prevents most sources of hidden data flow: no global mutable state without explicit synchronization, no implicit type conversions, no pointer aliasing. Control flow is explicit. The usage of macros can generate hidden control flow. | 🟡 |
 | **1i** | No unconditional jumps | (Language) **inherent** feature of Rust: no goto support | 🟢 |
 | **1j** | No recursions | (Architecture) **statically enforceable** Rust allows recursions. Rule should be enforced by static checks and no clippy lint exists so far | 🟡 |
 
@@ -149,6 +149,12 @@ Table 6 — Design principles for software unit design and implementation
     - Foreign RTOS integration (VxWorks, QNX, Zephyr): Supported via C ABI/FFI.
 - Panic Handling 🟢
     - A panic_handler must be defined to reset the system safely
+- Unsafe code management 🟡
+    - Rust's safety guarantees (memory safety, data race freedom) hold only for safe Rust; unsafe blocks opt out of compiler checks
+    - Embedded Rust typically requires unsafe for hardware register access, interrupt handlers, and FFI to C libraries
+    - `#[forbid(unsafe_code)]` can be used at module/crate level to guarantee absence of unsafe in application-level code
+    - Tools exist to audit unsafe usage (e.g. `cargo-geiger`) but are not qualified
+    - A formal unsafe usage and justification policy (analogous to MISRA deviation management) is needed
 
 ### 🟡 6-9 Software unit verification
 
@@ -162,7 +168,7 @@ Table 7 — Methods for software unit verification
 | **1d** | Semi-formal verification | (Tools) **partially available** Semi-formal verification includes methods like systematic test derivation from semi-formal specifications (e.g. state machines, decision tables). Rust's enum + match exhaustiveness checking provides compiler-verified state machine completeness — a lightweight form of semi-formal verification built into the language. For test generation from external UML or SysML specifications, no Rust-specific tooling exists | 🟡 |
 | **1e** | Formal verification | (Tools) **partially available** unqualified tools exist, e.g. creusot or kani, but quality unknown | 🟡 |
 | **1f** | Control flow analysis | (Tools) **partially** The Rust compiler builds and analyzes a control flow graph (MIR) for every function on every compilation. Miri can detect undefined behavior along execution paths. Binary-level CFA tools (e.g. AbsInt aiT) exist | 🟡 |
-| **1g** | Data flow analysis | (Tools) **partially** The borrow checker tracks variable definitions, uses, moves, and borrows. Miri extends this into unsafe code. No traditional DFA tool exists | 🟡 |
+| **1g** | Data flow analysis | (Tools) **partially** The borrow checker tracks variable definitions, uses, moves, and borrows. Miri extends this into unsafe code - but no reports are generated. No traditional DFA tool exists | 🟡 |
 | **1h** | Static code analysis | (Tools) **exists** clippy provides configurable static analysis. Miri detects undefined behavior in unsafe code, but clippy doesn't cover all emerging coding guideline rules yet | 🟡 |
 | **1i** | Static analyses based on abstract interpretation | (Tools) **not available** lacking support for tools like Polyspace or Astree | 🔴 |
 | **1j** | Requirements-based test | (Tools) **available** cargo test handles execution. Traceability to requirements requires tool as e.g. sphinx-needs or mantra | 🟢 |
@@ -185,7 +191,7 @@ Table 9 — Structural coverage metrics at the software unit level
 
 - Coverage instrumentation for embedded targets 🔴
     - Host-based: LLVM source coverage works on x86/ARM Linux.
-    - embedded Target: no direct instrumentation to measure code-coverage available
+    - embedded target: no direct instrumentation to measure code-coverage available
     - Binary-level coverage via hardware trace (ETM/ITM + Lauterbach) is language-independent but requires hardware-support and tooling.
 - General test tooling and report generation 🟡
     - test runner inherent feature by cargo test
@@ -223,6 +229,8 @@ For general testing-related considerations see 6-9, no specifics for integration
 
 ### 🟡 6-11 Testing of the embedded software
 
+Table 13 on the verification of the software safety requirements specification is omitted, because it has no direct impact from the programming language choice.
+
 Table 14 — Methods for tests of the embedded software
 
 | ID | Method | Solution: Rust Native or Tool | Readiness |
@@ -245,7 +253,7 @@ Table C.1: Mechanisms for the detection of unintended changes of data
 ### 🔴 8 Supporting Processes
 
 - 11 Tool Qualification 🔴
-    - Tools being used during the development/operation need to have undergone Tool Qualification as per ISO 26262-8 clause 11)
+    - Tools being used during the development/operation need to have undergone Tool Qualification as per ISO 26262-8 clause 11
     - Most of the open source tools mentioned before are not qualified
     - Where not (sufficiently) available, this has to be individually performed based on the usage context
 - 12 Qualification of software components 🔴