3.1. Release cadence¶

Due to the use of internal apis, the core library versions are only compatible with one matching Ferrocene release. The core library will be recertified for every Ferrocene release. That is approximately every three months.

The first Ferrocene release to include the certified core library is “Ferrocene 25.11.0”. Ferrocene has distributed an uncertified version of the core library since the first Ferrocene release.

3.2. Release notes¶

Changes to the certified core library are included in the Ferrocene Release Notes.

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

3.3. Roles and responsibilities¶

Roles and responsibilities (e.g. Safety Manager, Product Manager) are documented at Ferrocene Organization.

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

3.4. Lifecycle Phases Overview¶

1. Changes to the core library are pulled from the Upstream Rust project, as part of daily upstream pulls (see Upstream Pulls).

2. On a regular cadence, latest before the release, the changes are examined and it is ensured the certification requirements are upheld.

The requirements are:

• No uncertified code is used from certified code

• Every public function of the certified subset has a requirement with sufficient quality

• The certified code adheres to the coding standard

• The certified subset is tested with 100% statement coverage.

  • There are a few lines that cannot be covered by automatic tests. These are annotated with an explanation.

3.5. Internal procedures¶

The Ferrocene Qualification Plan describes how the Ferrocene organisation works, among others: Infrastructure, and the Development, Build, Testing and Release process. It is based on software engineering best practices, to be updated upon detection of shortcomings in the development process.

3.6. V-Model¶

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.

3.7. Responsibility split¶

3.8. Configuration¶

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.

3.9. Safety Assessment¶

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