diff --git a/arewesafetycriticalyet.org/docs/main/intro.md b/arewesafetycriticalyet.org/docs/main/intro.md index d50b7288..2e51ff4f 100644 --- a/arewesafetycriticalyet.org/docs/main/intro.md +++ b/arewesafetycriticalyet.org/docs/main/intro.md @@ -3,3 +3,45 @@ sidebar_position: 1 --- # Are We Safety Critical Yet? + +## What is Safety-Critical? + +Software is not inherently "safe" or "unsafe" in isolation - it becomes safety-critical when it controls actions in the physical world that could potentially cause harm to people or the environment. Whether software is safety-critical is thus determined by its operational context: specifically, whether it contributes to system hazards as established through risk analysis and system design. + +**Note:** Functional safety addresses risks from unintended malfunctions. It is distinct from cybersecurity, which addresses intentional malicious attacks. + +## Evaluating safety-critical readiness of β€œRust” + +In practice, software is considered safe by demonstrating compliance with the relevant safety standard for the target industry and application. It is worth noting that compliance is a proxy for safety: compliant systems can still be unsafe, and non-compliant systems can be safe. The standard provides a structured framework, not a guarantee. + +For this analysis, safety-critical readiness is measured by how well Rust's language design, toolchain, and ecosystem enable developers to meet the requirements of the relevant safety standards when developing safety-critical applications. + +## Standards-Based Evaluations + +The following evaluation examines how well specific safety-standard requirements can be satisfied when using Rust, based on the following scale: + +🟒 Well supported - requirement can be met with no additional effort + +🟑 Achievable - requirement can be met with moderate additional effort + +πŸ”΄ Gap - requirement needs substantial additional effort or qualification activity + +βšͺ Not impacted - requirement is not directly affected by the choice of programming language + +**Note:** Safety standards generally leave room for interpretation. In standards such as ISO 26262, final compliance claims are subject to the assessor's judgment. + +### ISO 26262 + +🟑 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. + +[Detailed Rust vs. ISO 26262 gap analysis](iso26262.md) + +### IEC 61508 + +Analysis in preparation. Contributions welcome via [GitHub](https://github.com/rustfoundation/safety-critical-rust-consortium). + +### DO-178C + +Analysis in preparation. Contributions welcome via [GitHub](https://github.com/rustfoundation/safety-critical-rust-consortium). diff --git a/arewesafetycriticalyet.org/docs/main/iso26262.md b/arewesafetycriticalyet.org/docs/main/iso26262.md new file mode 100644 index 00000000..80a3a0f1 --- /dev/null +++ b/arewesafetycriticalyet.org/docs/main/iso26262.md @@ -0,0 +1,262 @@ +--- +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 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. + +**Scope and limitations:** This analysis provides a general overview. The actual readiness for a specific project depends on the target ASIL, the organizational context, and the specific system architecture, etc. Requirements at ASIL A/B may have fewer gaps than those at ASIL C/D. This assessment should be used as an orientation - individual evaluation for your application context is necessary. + +*Last updated: March 2026* + +Contributions and corrections are welcome via [pull request](https://github.com/rustfoundation/safety-critical-rust-consortium). + +**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). + +### 🟒 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 | (Process) **statically enforceable** by clippy tool e.g. cyclomatic_complexity | 🟒 | +| **1b** | Use of language subsets | (Language) **coding guidelines** (are in progress by Subcommittee), need to be developed individually | 🟑 | +| **1c** | Enforcement of strong typing | (Language) **inherent** feature of Rust | 🟒 | +| **1d** | Use of defensive implementation techniques | (Architecture) **encouraged** by use of Types `Option`/`Result`,`assert!`/`panic!` macros, exhaustive match, mandatory bounds checking on array/slice access, and explicit per-operation overflow handling available via checked_*/saturating_* methods (can also be allowed implicitly by configuring) | 🟒 | +| **1e** | Use of well-trusted design principles | (Architecture) **encouraged** by Rust inherent features like encapsulation and RAII by default | 🟒 | +| **1f** | Use of unambiguous graphical representation | (Process) UML can be used - no specific graphical representation for Rust available | βšͺ | +| **1g** | Use of style guides | (Process) **statically enforceable** by clippy tool | 🟒 | +| **1h** | Use of naming conventions | (Process) **statically enforceable** by clippy tool | 🟒 | +| **1i** | Concurrency aspects | (Architecture) **partially** concurrent aspects can be enforced by Rust such as borrow checker on shared resources. Typical constructs such as Mutex, RefCells to provide guarantees also exist - but e.g. priority inversion, deadlocks etc. are still possible and need to be managed | 🟒 | + +**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, 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. 🟒 +- Coding Guidelines 🟑 + - [Safety-Critical Rust Coding Guidelines](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines) are in active work + - need to be complemented by individual/organizational-specific guidelines + - Tool "clippy" can be used to enforce guidelines (but is not qualified) +- IDEs 🟒 + - Multiple Supported IDEs with all common features: e.g. VSCode, JETBRAINS RustRover, ... +- Debugging and tracing support 🟑 + - Multiple tools available for debugging on target for ARM, RISC V, AURIX, (e.g. probe-rs, knurling-rs, gdb/OpenOCD) + - Tracing Lauterbach TRACE32 +- Build system & CI/CD 🟒 + - cargo inherently allows to configure different runners + - Tests are encouraged to be written alongside the code + - Well supported by commonly available build systems (e.g. Jenkins, etc.) +- Qualified Compiler 🟒 + - Multiple available for up to ASIL D for multiple targets (e.g. Hightec, Ferrocene) + +### 🟒 6-6 Specification of software safety requirements + +This clause is not impacted by the programming language choice much. + +**General considerations:** + +- Requirements traceability tooling 🟒 + - 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 + +Table 2 on software architecture notations is omitted, because it has no direct impact by/for using Rust. + +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 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 | βšͺ | +| **1e** | Loose coupling between software components | (Architecture) **neutral** Rust does not impose this logical design constraint | βšͺ | +| **1f** | Appropriate scheduling properties | (Architecture) **partially available** - multiple unqualified Rust-native concurrency frameworks exist: RTIC (static priority scheduling, formally analyzable), Embassy (cooperative async), Hubris (microkernel with MPU isolation). Integration with foreign RTOS (e.g. VxWorks, QNX, Zephyr) possible via C ABI, though the scheduler itself is outside of Rust's safety guarantees. Rust's no_std without allocator guarantees absence of hidden dynamic allocation, improving WCET analyzability. | 🟑 | +| **1g** | Restricted use of interrupts | (Architecture) **neutral** Rust does not impose this constraint | βšͺ | +| **1h** | Appropriate spatial isolation of the software components | (Architecture + Compiler) Logical isolation: Rust natively enforces strict visibility rules and memory safety but physical isolation requires hardware MPU/MMU that requires Rust drivers | 🟑 | +| **1i** | Appropriate management of shared resources | (Architecture) **available** by Rust's Send/Sync trait system statically prevents data races. Safe concurrency primitives (Mutex, RwLock) enforce access discipline at compile time. Logical race conditions and deadlocks remain architectural concerns. See also Table 1 item 1i for coding-level concurrency. | 🟒 | + +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 | (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 | βšͺ | +| **1e** | Formal verification | (Tools) **partially available** unqualified tools exist, e.g. creusot or kani | 🟑 | +| **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) exists +- Software partitioning and freedom from interference 🟑 + - 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 + - Stack usage: Analyzable via binary inspection (e.g. stack-sizes crate, AbsInt StackAnalyzer). Deterministic in no_std without allocator. + - Heap: avoidable in no_std Rust without an allocator, making memory usage statically bounded. +- C/C++ Interoperability 🟑 + - Legacy Code, vendor SDKs or specific drivers might require C-code + - the boundary (e.g. bindgen) is generally unqualified and needs to be verified individually + +### 🟑 6-8 Software unit design and implementation + +Table 5 on unit design notations is omitted, because it has no direct impact by/for using Rust. + +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 (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 in safe Rust | 🟒 | +| **1h** | No hidden data flow or control flow | **largely inherent** as Rust prevents most sources of hidden data flow: compared to C++ exceptions Rust's ? operator is explicit. 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 | 🟑 | + +**General considerations:** + +- FuSa Library support for qualified microcontroller 🟑 + - e.g. ARM Self Test Library support to provide diagnostic coverage for microcontroller exists only in C + - are generally provided as binary blobs or C-files and require FFI (which might tamper qualification) +- Hardware Abstraction Layer (HAL) availability 🟑/πŸ”΄ + - ARM Cortex-M: Mature ecosystem β€” embedded-hal trait abstractions, PACs generated via svd2rust, HALs for major MCU families (STM32, nRF, ESP32, RP2040). 🟒 + - ARM Cortex-R: Minimal ecosystem. No mature HALs or PACs. Limited community activity. πŸ”΄ + - Infineon AURIX (TC3xx/TC4xx): Hightec Rust toolchain available, but HAL maturity unclear. πŸ”΄ + - RISC-V: Growing ecosystem, esp-hal for ESP32-C3/C6 relatively mature, but broader RISC-V automotive targets underserved. 🟑 +- Qualified RTOS / concurrency frameworks πŸ”΄ + - No Rust-native RTOS or framework is qualified to ISO 26262 today. + - OxidOS: Pursuing automotive qualification + - RTIC, Embassy, Hubris, Tock: Actively maintained but unqualified and not yet API-stable + - 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 + +Table 7 β€” Methods for software unit verification + +| ID | Method | Solution: Rust Native or Tool | Readiness | +| :--- | :--- | :--- | :--- | +| **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** | Pair-programming | (Process) **neutral** no impact by Rust | βšͺ | +| **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 - 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 | 🟒 | +| **1k** | Interface test | (Tools) **available** cargo test handles execution. Traceability to interface specifications requires external tools | 🟒 | +| **1l** | Fault injection test | (Tools) **possible** to manually implement fault injections. Currently no tool support | 🟒 | +| **1m** | Resource usage evaluation | (Tools) **tools exist** e.g. Orbuculum or TRACE32 by Lauterbach | 🟑 | +| **1n** | Back-to-back comparison test | (Tools) **not available** requires model generators to support Rust and export test vectors | πŸ”΄ | + +Table 8 on test case derivation methods is omitted, because it is typically a manual effort and has no direct impact by/for using Rust. + +Table 9 β€” Structural coverage metrics at the software unit level + +| ID | Method | Solution: Rust Native or Tool | Readiness | +| :--- | :--- | :--- | :--- | +| **1a** | Statement coverage | **available** by llvm | 🟒 | +| **1b** | Branch coverage | **not available** yet | πŸ”΄ | +| **1c** | MC/DC (Modified Condition/Decision Coverage) | **not available** yet, is in discussions | πŸ”΄ | + +**General considerations:** + +- 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 + - 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 + - custom runner can be configured to run on embedded targets (e.g. by defmt-test by knurling-rs) +- Demonstrate equivalence between target/test environment and object code, when unit tests are not performed on target πŸ”΄ + - No information available +- Traceability between test case implementation and test case specification 🟑 + - achievable using tools such as mantra + +### 🟑 6-10 Software unit integration and verification + +Table 10 β€” Methods for verification of software integration + +| ID | Method | Solution: Rust Native or Tool | Readiness | +| :--- | :--- | :--- | :--- | +| **1a** | Requirements-based test | (Tools) **available** cargo test handles execution. Traceability to requirements requires tool as e.g. sphinx-needs or mantra. knurling-rs allows tests to run on target | 🟒 | +| **1b** | Interface test | (Tools) **available** cargo test handles execution. Traceability to interface specifications requires external tools. knurling-rs allows tests to run on target | 🟒 | +| **1c** | Fault injection test | (Tools) **possible** to manually implement fault injections. Currently no tool support | 🟒 | +| **1d** | Resource usage evaluation | (Tools) **exist** e.g. Orbuculum or TRACE32 by Lauterbach | 🟑 | +| **1e** | Back-to-back comparison test | (Tools) **not available** requires model generators to support Rust and export test vectors | πŸ”΄ | +| **1f** | Verification of the control flow and data flow | (Tools) **not available** | πŸ”΄ | +| **1g** | Static code analysis | (Process) **exists** clippy is standard - but does not offer all checks for coding-guidelines | 🟑 | +| **1h** | Static analyses based on abstract interpretation | (Tools) **not available** lacking support for tools like Polyspace or Astree | πŸ”΄ | + +Table 11 on test case derivation methods for integration testing is omitted, because it has no direct impact from the programming language choice. + +Table 12 β€” Structural coverage at the software architectural level + +| ID | Method | Solution: Rust Native or Tool | Readiness | +| :--- | :--- | :--- | :--- | +| **1a** | Function coverage | (Tools) **supported** by llvm | 🟒 | +| **1b** | Call coverage | (Tools) **supported** by llvm | 🟒 | + +For general testing-related considerations see 6-9, no specifics for integration testing. + +### 🟑 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 | +| :--- | :--- | :--- | :--- | +| **1a** | Requirements-based test | (Tools) **available** cargo test handles execution. Traceability to requirements requires tool as e.g. sphinx-needs or mantra. knurling-rs allows tests to run on embedded targets | 🟒 | +| **1b** | Fault injection test | (Tools) **possible** to manually implement fault injections. Currently no tool support | 🟒 | + +For general testing-related considerations see 6-9, no specifics for embedded testing. + +### 🟑 Annex C (normative) Software configuration + +Table C.1: Mechanisms for the detection of unintended changes of data + +| ID | Method | Solution: Rust Native or Tool | Readiness | +| :--- | :--- | :--- | :--- | +| **1a** | Plausibility checks on calibration data | (Architecture) **neutral** needs to be implemented manually | βšͺ | +| **1b** | Redundant storage and comparison of calibration data | (Architecture) **not available** no qualified libraries for redundant storage and integrity checks of data (e.g. encoding booleans as specific bit patterns to detect corruption) | 🟑 | +| **1c** | Calibration data checks using error detecting codes | (Architecture) **partially available** crate to calculate e.g. CRCs available - PACs for CRC engines are not available | 🟑 | + +### πŸ”΄ 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 + - 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 πŸ”΄ + - Qualification of software components used within the product needs to be performed as per ISO 26262-8 clause 12 + - Most of the open RTOS, PACs, HALs, crates/libraries etc. are not qualified and thus can't be directly used within the product + - Where these are not qualified, this has to be individually performed based on the usage context + +**Note:** Unqualified tools and software components are partially rated as yellow or green, rated based on estimated effort required for qualification in typical usage contexts. diff --git a/arewesafetycriticalyet.org/docusaurus.config.ts b/arewesafetycriticalyet.org/docusaurus.config.ts index 1e703e8b..f85bcb9e 100644 --- a/arewesafetycriticalyet.org/docusaurus.config.ts +++ b/arewesafetycriticalyet.org/docusaurus.config.ts @@ -8,7 +8,7 @@ const baseUrl = process.env.BASE_URL || '/'; const config: Config = { title: 'Are We Safety Critical Yet?', - tagline: 'It depends πŸ€”, we have a few certified compilers, a few certification products in-progress and a few use cases.', + tagline: 'Tracking Rust\'s readiness for safety-critical development across industry standards.', favicon: 'img/favicon.ico', // Set the production url of your site here diff --git a/arewesafetycriticalyet.org/src/components/HomepageFeatures/index.tsx b/arewesafetycriticalyet.org/src/components/HomepageFeatures/index.tsx index 24e34759..57f71184 100644 --- a/arewesafetycriticalyet.org/src/components/HomepageFeatures/index.tsx +++ b/arewesafetycriticalyet.org/src/components/HomepageFeatures/index.tsx @@ -66,6 +66,9 @@ export default function HomepageFeatures(): ReactNode { return (
+ + Consortium Working Groups +
{FeatureList.map((props, idx) => ( diff --git a/arewesafetycriticalyet.org/src/components/StandardsOverview/index.tsx b/arewesafetycriticalyet.org/src/components/StandardsOverview/index.tsx new file mode 100644 index 00000000..918abf63 --- /dev/null +++ b/arewesafetycriticalyet.org/src/components/StandardsOverview/index.tsx @@ -0,0 +1,128 @@ +import type {ReactNode} from 'react'; +import clsx from 'clsx'; +import Link from '@docusaurus/Link'; +import Heading from '@theme/Heading'; +import styles from './styles.module.css'; + +type Rating = 'green' | 'yellow' | 'red' | 'grey'; + +interface Standard { + name: string; + rating: Rating; + verdict: string; + description: string; + detailsUrl: string | null; +} + +const standards: Standard[] = [ + { + name: 'ISO 26262', + rating: 'yellow', + verdict: 'Achievable with moderate additional effort', + description: + "Rust's core language features - memory safety, strong typing, and data race prevention - provide an excellent basis for ISO 26262 compliance. Critical gaps exist in qualified tools, control/data flow analysis, and qualified RTOS/HAL/PAC support.", + detailsUrl: '/docs/iso26262', + }, + { + name: 'IEC 61508', + rating: 'grey', + verdict: 'Analysis in preparation', + description: 'Contributions welcome.', + detailsUrl: null, + }, + { + name: 'DO-178C', + rating: 'grey', + verdict: 'Analysis in preparation', + description: 'Contributions welcome.', + detailsUrl: null, + }, +]; + +const ratingDotClass: Record = { + green: styles.dotGreen, + yellow: styles.dotYellow, + red: styles.dotRed, + grey: styles.dotGrey, +}; + +const ratingCardClass: Record = { + green: styles.standardCardGreen, + yellow: styles.standardCardYellow, + red: styles.standardCardRed, + grey: '', +}; + +function RatingDot({rating}: {rating: Rating}) { + return ; +} + +function StandardCard({standard}: {standard: Standard}) { + return ( +
+
+ + {standard.name} +
+

{standard.verdict}

+

{standard.description}

+ {standard.detailsUrl ? ( + + View detailed analysis → + + ) : ( + + Contribute on GitHub → + + )} +
+ ); +} + +export default function StandardsOverview(): ReactNode { + return ( +
+
+ + Standards-Based Evaluations + +

+ Safety-critical readiness is measured by how well Rust's language design, toolchain, and + ecosystem enable developers to meet the requirements of the relevant safety standards. + For more context, see the{' '} + full overview. +

+ +
+ + Well supported + + + Achievable with effort + + + Gap + + + Not yet rated + +
+ +
+ {standards.map(standard => ( +
+ +
+ ))} +
+
+
+ ); +} diff --git a/arewesafetycriticalyet.org/src/components/StandardsOverview/styles.module.css b/arewesafetycriticalyet.org/src/components/StandardsOverview/styles.module.css new file mode 100644 index 00000000..ccd3856c --- /dev/null +++ b/arewesafetycriticalyet.org/src/components/StandardsOverview/styles.module.css @@ -0,0 +1,99 @@ +.overview { + padding: 2rem 0; +} + +.introText { + max-width: 700px; + margin: 0 auto 1rem; +} + +.legend { + display: flex; + flex-wrap: wrap; + gap: 1.5rem; + justify-content: center; + margin-bottom: 2rem; + color: var(--ifm-color-emphasis-700); +} + +.legendItem { + display: flex; + align-items: center; + gap: 0.4rem; +} + +.dot { + width: 12px; + height: 12px; + border-radius: 50%; + display: inline-block; + flex-shrink: 0; +} + +.dotGreen { + background-color: var(--rating-green); +} + +.dotYellow { + background-color: var(--rating-yellow); +} + +.dotRed { + background-color: var(--rating-red); +} + +.dotGrey { + background-color: var(--rating-grey); +} + +.standardCard { + border: 1px solid var(--ifm-color-emphasis-200); + border-left: 4px solid var(--rating-grey); + border-radius: 6px; + padding: 1.25rem; + height: 100%; + display: flex; + flex-direction: column; +} + +.standardCardGreen { + border-left-color: var(--rating-green); +} + +.standardCardYellow { + border-left-color: var(--rating-yellow); +} + +.standardCardRed { + border-left-color: var(--rating-red); +} + +.standardCardPending { + opacity: 0.6; + border-left-style: dashed; +} + +.cardHeader { + display: flex; + align-items: center; + gap: 0.5rem; + margin-bottom: 0.5rem; +} + +.cardHeader h3 { + margin: 0; +} + +.verdict { + font-weight: 600; + margin-bottom: 0.5rem; +} + +.description { + color: var(--ifm-color-emphasis-700); + flex: 1; +} + +.detailsLink { + margin-top: 0.75rem; +} diff --git a/arewesafetycriticalyet.org/src/css/custom.css b/arewesafetycriticalyet.org/src/css/custom.css index ed98b415..50e15217 100644 --- a/arewesafetycriticalyet.org/src/css/custom.css +++ b/arewesafetycriticalyet.org/src/css/custom.css @@ -15,6 +15,12 @@ --ifm-color-primary-lightest: #273168; --ifm-code-font-size: 95%; --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1); + + /* Match the emoji colors: 🟒 🟑 πŸ”΄ βšͺ */ + --rating-green: #4caf50; + --rating-yellow: #fdd835; + --rating-red: #f44336; + --rating-grey: #bdbdbd; } /* For readability concerns, you should choose a lighter palette in dark mode. */ diff --git a/arewesafetycriticalyet.org/src/pages/index.module.css b/arewesafetycriticalyet.org/src/pages/index.module.css index 9f71a5da..01a4ef8b 100644 --- a/arewesafetycriticalyet.org/src/pages/index.module.css +++ b/arewesafetycriticalyet.org/src/pages/index.module.css @@ -21,3 +21,9 @@ align-items: center; justify-content: center; } + +.divider { + border-top: 1px solid var(--ifm-color-emphasis-200); + max-width: 800px; + margin: 0 auto; +} diff --git a/arewesafetycriticalyet.org/src/pages/index.tsx b/arewesafetycriticalyet.org/src/pages/index.tsx index b941ddc9..15378876 100644 --- a/arewesafetycriticalyet.org/src/pages/index.tsx +++ b/arewesafetycriticalyet.org/src/pages/index.tsx @@ -4,6 +4,7 @@ import Link from '@docusaurus/Link'; import useDocusaurusContext from '@docusaurus/useDocusaurusContext'; import Layout from '@theme/Layout'; import HomepageFeatures from '@site/src/components/HomepageFeatures'; +import StandardsOverview from '@site/src/components/StandardsOverview'; import Heading from '@theme/Heading'; import styles from './index.module.css'; @@ -21,7 +22,7 @@ function HomepageHeader() { - Find out! + Read the overview
@@ -30,13 +31,14 @@ function HomepageHeader() { } export default function Home(): ReactNode { - const {siteConfig} = useDocusaurusContext(); return ( + title="Are We Safety Critical Yet?" + description="Tracking Rust's readiness for safety-critical software development across ISO 26262, IEC 61508, and DO-178C.">
+ +