2.1.1. 5.2.1¶

Covered by Safety Plan - Lifecycle Phases Overview.

2.1.2. 5.2.2¶

Covered by

• Safety Plan - Lifecycle Phases Overview

• Safety Plan - Roles and Responsibilities

2.1.3. 5.2.3¶

Covered by

• Safety Plan - Lifecycle Phases Overview

• Safety Plan - Release Cadence

2.1.4. 5.2.4¶

Covered by

• Certified core library API docs

• Code coverage report

• Requirements review

2.1.5. 5.2.5¶

All docs available in the Ferrocene documentation package.

2.1.6. 5.2.6¶

Covered by Qualification Plan - Documentation Validation.

2.1.7. 5.2.7¶

The core library certification documentation follows the structure of the other documents in the Ferrocene documentation package.

2.1.8. 5.2.8¶

Processes from the Rustc qualification are used, unless specific needs for the core library certification require otherwise.

2.1.9. 5.2.9¶

Covered by Change Tracking.

2.1.10. 5.2.10¶

Changes to the certified core library are included in the Ferrocene release notes. When new releases of the certified core library, which is released with Ferrocene, include new functionality such as an expanded subset, this will be covered in the release notes.

2.1.11. 5.2.11¶

Covered by

• Qualification Plan - Documentation Validation

• Roles and responsibilities

2.1.12. 6.2¶

See subsections.

2.1.13. 6.2.1¶

Covered by Safety Plan - Roles and responsibilities.

2.1.14. 6.2.2¶

Ferrous Systems is ISO 9001-2015 certified. See Qualification Plan - Ferrocene Organization.

2.1.15. 6.2.3¶

Covered by Roles and responsibilities.

2.1.16. 6.2.4¶

Covered by Customer Interactions.

2.1.17. 6.2.5¶

Covered by Patching process.

2.1.18. 6.2.6¶

Covered by Internal procedures.

2.1.19. 6.2.7¶

Covered by Release cadence.

2.1.20. 6.2.8¶

Covered by Development Process.

2.1.21. 6.2.9¶

Covered by Known Problems Tracking.

2.1.22. 6.2.10¶

Covered by Infrastructure.

2.1.23. 6.2.11¶

N/A; No emergency services involved.

2.1.24. 6.2.12¶

Covered by Ferrocene Organization.

2.1.25. 6.2.13¶

Ferrous Systems maintains a database of staff competencies consisting of staff CVs as well as any training provided by Ferrous Systems. Prior to assigning major tasks, leadership verifies the competencies of the respective staff. Ferrous Systems’s ISO 9001 managed internal handbook details how staff may undertake training for new skills, or re-training for existing skills.

2.1.26. 6.2.14¶

When assigning staff to projects, leadership verifies that staff experience, training, decision making authority, responsibilities, and level of supervision required are a fit. Where appropriate, Ferrous Systems assigns more experienced staff to work alongside less experienced staff to facilitate hands-on training.

2.1.27. 6.2.15¶

Ferrous Systems maintains a database of staff competencies consisting of their CVs as well as any training provided by Ferrous Systems.

2.1.28. 6.2.16¶

Detailed in Ferrous Systems’s ISO 9001 managed internal handbook and re-checked for each renewal of certification.

2.1.29. 6.2.17¶

N/A; No suppliers involved.

2.1.30. 6.2.18¶

Covered by

• Safety Plan - Release Cadence

2.1.31. 7.4.2¶

Covered by Failure analysis.

2.1.32. 7.5.2¶

Covered by

• Known Problems

2.2.1. 4¶

1. The Safety Plan - Certification Scope specifies and justifies the SIL level.

2. The core library certification excludes the requirement of having an architecture.

   The core library has a very simple design. It is a library of independent functions with no internal state management. Each module provides functions and data structures around a single well-defined topic. All modules have a doc-comment describing the design and contents of the module.

2.2.2. 5¶

Covered by 5.2.1 to 5.2.11 of IEC 61508-1.

2.2.3. 6.2.1¶

Covered by 6.2 of IEC 61508-1.

2.2.4. 6.2.2¶

Covered by Safety Plan.

2.2.5. 6.2.3¶

Covered by

• Development Process

• Change Tracking

• Infrastructure

2.2.6. 7.1.2.1-3¶

Covered by Safety Plan - Lifecycle Phases Overview.

2.2.7. 7.1.2.4-6¶

We diverge from the V-Model, because we are certifying an existing project, not developing the code from scratch.

To explain it in V-model-terms: The Rust project, who is maintaining the upstream core library, performs the requirement specification, the software architecture, the software design, the module design and the coding. Ferrous Systems, consumes the output of those activities from upstream and performs module testing, integration testing, and validation testing on the code received from upstream pull requests.

2.2.8. 7.1.2.7¶

Covered by IEC 61508-3 Annex A.

2.2.9. 7.1.2.8-9¶

The following relevant artefacts are included in the deliverables:

• Code coverage report

• Test results

• Doc-comment review

• Certified core library API docs

2.2.10. 7.2.2.1-3¶

Covered by Requirements Management.

2.2.11. 7.2.2.4¶

N/A

The core library has a very simple design. It is a library of independent functions with no internal state management. Each module provides functions and data structures around a single well-defined topic. All modules have a doc-comment describing the design and contents of the module.

All functions included in the subset are certified SIL2.

2.2.12. 7.2.2.5¶

Ferrous Systems certifies core as a library, to be used in other systems whose requirements are unknown. Users of the certified core library should consider their specific system safety requirements when developing safety related software with the certified core library.

2.2.13. 7.2.2.6-9¶

N/A; the core library is a pure software library. Hardware constraints should be taken into consideration when integrating the certified core library into a hardware environment.

2.2.14. 7.2.2.11¶

N/A; There is no way to configure the core library binary after it is compiled.

2.2.15. 7.2.2.12-13¶

N/A; the core library does not use, and therefore does not configure, any pre-existing software.

2.2.16. 7.3.2.1-5¶

The core library is tested as laid out in the Testing Plan, and those test results, for all qualified targets, are available in the Test results overview.

2.2.17. 7.4.2.1¶

The upstream Rust project is responsible for developing the core library.

Ferrous Systems performs verification activities to prove that the core library can be used in safety critical applications up to SIL 2.

Integration into hardware and into a broader system must be performed by the user of the core library.

2.2.18. 7.4.2.2-6¶

Covered by Doc-comments in the core library.

2.2.19. 7.4.2.7¶

N/A, because core is a library and does not build on top of a pre-existing component.

2.2.20. 7.4.2.8-11¶

All functions in the certified core library are deemed to be of the same SIL.

2.2.21. 7.4.2.12-14¶

N/A, because core is a library and does not build on top of a pre-existing component.

2.2.22. 7.4.3¶

N/A, therefore no architecture is needed

The core library has a very simple design. It is a library of independent functions with no internal state management. Each module provides functions and data structures around a single well-defined topic. All modules have a doc-comment describing the design and contents of the module.

2.2.23. 7.4.4.1-9¶

No online tools are used for the core library certification, only offline tools. In Safety Plan - Tool Safety Assessments all used tools are specified and justified.

2.2.24. 7.4.4.10-11¶

The certified core library is being build with the safety Qualified Ferrocene compiler, which uses Rust as defined by the Ferrocene language specification. Rust is well matched to the needs of the core library.

2.2.25. 7.4.4.12-13¶

The Rust project has extensive measures (lints and tests) in place to assure quality and consistency of the codebase. The certified core library uses the same implicit standards as are ensured in the upstream codebase, to minimize divergence. Increased divergence from upstream leads to a higher maintenance burden and is a source of potential bugs.

2.2.26. 7.4.4.14¶

N/A; Rust macros are not automatic code generation, since they are written in source code.

2.2.27. 7.4.4.15-18¶

All testing infrastructure, including offline support tools, and related configuration, is stored in the GitHub repository, versioned, and subject to the same quality control process as other code.

Infrastructure of Ferrocene is detailed in Infrastructure.

A record of all packages used by the build and test environment of each version of Ferrocene, including the core library, is contained in the ferrocene-src component, which contains:

• The root directory contains the entire Ferrocene source.

• The vendor/rust folder contains a copy of the source of each Rust dependency for Ferrocene in a format suitable for use with x.py.

• The vendor/uv folder contains a copy of the source of each Python dependency for Ferrocene in a format suitable for using with uv.

• The vendor/build-environment folder contains a comprehensive list of all distribution provided packages and their versions, as well as the hashes and URLs of all additional packages used (versions included).

This component is available to all customers and contains everything necessary to reproduce releases of Ferrocene.

2.2.28. 7.4.4.19¶

The “Technical Lead” is responsible for making or approving technical decisions, including which tools to use and how they are going to be configured.

2.2.29. 7.4.5.1-2¶

See Contributing to Upstream for the upstream development and quality management process.

Ferrous Systems monitors upstream doc-comments, used as requirements and design, and verifies them for each pull request by running the full test suite.

2.2.30. 7.4.5.3-5¶

The core library has a very simple design. It is a library of independent functions with no internal state management. Each module provides functions and data structures around a single well-defined topic. All modules have a doc-comment describing the design and contents of the module.

2.2.31. 7.4.6¶

All upstream Rust code is reviewed by a documented team of appointed Rust experts, and heavily tested, before being merged. Changes are reviewed by an expert who was not involved in the change. Test results and review evidence are public. Ferrous Systems tests that code for correctness on all qualified targets.

2.2.32. 7.4.7-8¶

The core library is tested as laid out in the Testing Plan, and those test results, for all qualified targets, are available in the Test results overview.

2.2.33. 7.5¶

The core library is tested as laid out in the Testing Plan, and those test results, for all qualified targets, are available in the Test results overview.

2.2.34. 7.6¶

See 7.8.

2.2.35. 7.7.1¶

Objective met.

2.2.36. 7.7.2.1-4¶

The core library is tested as laid out in the Testing Plan, and those test results, for all qualified targets, are available in the Test results overview.

2.2.37. 7.7.2.5-6¶

The corestests test suite specifies all test cases and expected results in source code.

2.2.38. 7.7.2.7-9¶

The core library is tested as laid out in the Testing Plan, and those test results, for all qualified targets, are available in the Test results overview.

2.2.39. 7.8¶

Covered by

• Development Process

• Upstream Pulls

2.2.40. 7.9.1¶

Objective met.

2.2.41. 7.9.2.1-7¶

The core library is tested as laid out in the Testing Plan, and those test results, for all qualified targets, are available in the Test results overview.

2.2.42. 7.9.2.8¶

N/A; There is no system, only software requirements.

2.2.43. 7.9.2.9¶

N/A; There is no architecture design.

2.2.44. 7.9.2.10-13¶

The core library is tested as laid out in the Testing Plan, and those test results, for all qualified targets, are available in the Test results overview.

2.2.45. 7.9.2.14¶

N/A; Timing performance depends on the system requirements, which are unknown during the certification phase.

2.2.46. 8.1-3¶

Certification is carried out by TÜV SÜD, an independent assessment body.

2.3.1. Table A.1¶

2.3.2. Table A.2¶

2.3.3. Table A.3¶

2.3.4. Table A.4¶

2.3.5. Table A.5¶

2.3.6. Table A.6¶

N/A; No electronics or other hardware.

2.3.7. Table A.7¶

2.3.8. Table A.8¶

2.3.9. Table A.9¶

2.3.10. Table A.10¶

2.4.1. Table B.1 - Design and coding standards¶

2.4.2. Table B.2 - Dynamic analysis and testing¶

2.4.3. Table B.3 - Functional and black-box testing¶

2.4.4. Table B.4 - Failure analysis¶

2.4.5. Table B.5 - Modelling¶

2.4.6. Table B.6 - Performance testing¶

2.4.7. Table B.7 - Semi-formal methods¶

Covered by Requirements Management.

2.4.8. Table B.8 - Static analysis¶

2.4.9. Table B.9 - Modular approach¶