Posts Tagged ‘Ferrocene’
[OxidizeConf2024] Safety Compliance of Rust Libraries
Navigating Automotive Safety Standards
The automotive industry’s shift toward software-defined vehicles has intensified the need for robust safety compliance, particularly for software components used in safety-critical applications. At OxidizeConf2024, Amit Dharmapurikar and Gnana Ganesh from Thoughtworks delivered an insightful presentation on qualifying Rust libraries for compliance with ISO 26262, a standard governing functional safety in automotive systems. With Thoughtworks’ expertise in software-defined vehicles, Amit and Gnana provided a comprehensive overview of the processes and tools required to ensure Rust libraries meet stringent safety requirements, focusing on the Rust Core library as a case study.
ISO 26262 mandates rigorous documentation, requirement coverage, and structural code coverage to ensure software reliability in electronic control units (ECUs). Amit emphasized that while the Ferrocene compiler, developed by Ferrous Systems, has already achieved safety compliance, libraries—both standard and third-party—must also be qualified. This involves producing formal specifications, verifying requirements through testing, and generating code coverage reports. The speakers highlighted the collaborative effort with Ferrous Systems to qualify the Rust Core library, underscoring the importance of aligning open-source tools with automotive standards.
Documentation and Requirement Coverage
A cornerstone of ISO 26262 compliance is comprehensive documentation, which serves as a formal specification of software components. Gnana detailed how Thoughtworks approaches this by deriving testable requirements from the Rust Core library’s standard documentation. This process involves translating descriptive text into precise, verifiable requirements, a task that poses challenges due to the library’s frequent updates as an open-source project. To address this, Amit and Gnana proposed developing tools to automate the interpretation of documentation changes, ensuring that requirements remain aligned with the library’s evolution.
Requirement coverage, as mandated by ISO 26262 Part 6, ensures that all functional requirements are tested. The speakers demonstrated a proof-of-concept where requirements for the Rust Core library were linked to test cases, providing traceability essential for audits. This approach leverages open-source tools like Sphinx, which facilitates bidirectional traceability by connecting requirements to code. By integrating these tools into the development pipeline, Thoughtworks ensures that compliance artifacts are generated iteratively, reducing manual effort and enhancing accountability.
Advancing Code Coverage with Rust Tooling
Structural code coverage is another critical aspect of ISO 26262 compliance, requiring developers to measure how thoroughly code is exercised by tests. Amit showcased a demo using the Rust toolchain’s coverage capabilities, specifically the --coverage flag in the test subcommand. This flag, combined with a custom bootstrap command (dotx), embeds profiler builtins into executables, generating profile files that tools like grcov process into coverage reports. The demo illustrated coverage analysis for the Rust Core library, excluding documentation to focus on executable code.
While statement coverage is already supported, Gnana noted that branch coverage is available in draft pull requests, and Modified Condition/Decision Coverage (MCDC) is in progress within the Rust community. These advancements, driven by initiatives like Ferrocene, demonstrate Rust’s growing maturity for safety-critical applications. The speakers acknowledged challenges, such as managing frequent library updates, but emphasized the potential of automated tools to streamline compliance, making Rust a viable choice for automotive software development.