Eclipse Foundation Functional Safety Process Operations Guide
Updated 2026-01-26
The document describes the operation of the Eclipse Foundation Functional Safety Process by the Eclipse Foundation.
In the event of any conflict between the terms set forth in this document and the terms of the documents listed above, the terms of those documents shall take precedence.
1. Functional Safety Projects
The EFFSP focuses on Functional Safety Projects in matters of governance (e.g. project structure, committers and project leads). That is, in matters of governance, open source projects are the atomic unit.
- Functional Safety Projects are a special type of open source project
-
In mathematical terms, a Functional Safety Project (as defined by the EFFSP) can be thought of as a subtype of project (as defined by the EDP). The EDP describes governance that applies to both Projects and Functional Safety Projects; the EFFSP defines additional governance that applies to Functional Safety Projects.
A Functional Safety Project may (or may not) operate under the purview of one Functional Safety Committee (which operates as a committee of a working group).
Functional Safety Project is a subtype of Project (EDP). - A Functional Safety Project may have more than one Git repository
-
A Functional Safety Project can have as many GitLab and GitHub repositories as required. All repositories are managed by the Eclipse Foundation on behalf of the project and community.
Functional Safety Projects operating under the EFFSP follow the same life cycle as open source Projects operating under the EDP.
1.1. Base Practices
The bare minimum set of practices that a Functional Safety Project shall apply in order to support its software development life cycle concern documentation, requirements, coding guidelines, testing, and release process, as follows:
- Documentation
-
-
The Project shall have a document that explains clearly what the Project does and in which part of a typical application/architecture it is intended to be used;
-
The Project shall have a Getting Started guide that explains how to use the Project (how to build it, install it, use it, etc.); and
-
The Project shall have all the necessary documentation about the external behaviour of the Project (considering the project as a black box) and on how to extend the Project so that the extension fits all the practices that the Project follows (e.g. adding new functionality, new requirements, with all that it implies, traceability, testing and test coverage, build instructions, CI/CD specifics that need to be kept/maintained).
-
The Project shall have clearly defined Functional Safety Goals, Functional Safety Cases and Functional Safety Arguments
-
- Requirements
-
-
Requirements shall be identified and documented;
-
They shall be comprehensive and expose 100% of the project’s features; and
-
Any changes made to the Requirements throughout the lifetime of the project shall be identifiable and specified at the project’s Release point.
-
All requirements shall be traceable back and forth throughout the project artefacts (e.g. from requirements to documentation, to code, to tests, to releases and back again)
-
- Coding Guidelines
-
-
The Project shall define and adopt a set of coding guidelines, and shall document the said guidelines;
-
The Project shall identify, adopt and establish automatic methods to check out the appliance of the adopted coding guidelines, and shall document these methods;
-
The Project shall report any warnings and/or violations of its coding guidelines; and
-
The Project Team shall regularly analyse the reported violations, shall document the respective analysis, shall decide which violations to fixed, raising issues for those, and which violations to be justified through documentation.
-
- Testing
-
-
The Project shall establish a fully integrated CI/CD test pipeline;
-
The Project shall provide dedicated tests that are linked to the corresponding requirements;
-
All Project requirements shall be covered by tests; and
-
All main-merges and all releases of the project shall pass all the project tests.
-
- Release Process
-
-
The Project’s Releases are created according to the Eclipse Foundation Development Process;
-
The Project shall establish and document a well defined Release process which includes clear release identifiers;
-
The Project shall provide release notes for each Release of the Project, through which the Project is documenting the contents of the respective release (e.g. all artefacts involved: code, documentation, requirements, tests, etc.);
-
The Project’s release process shall be automated and shall produce the release notes; and
-
The Project shall provide a published Release schedule for the Project and the Project Team shall followed the respective schedule;
-
|
The Eclipse Foundation recommends that all Projects adopt Semantic Versioning. |
1.2. Functional Safety Artefacts
Artefacts typically include:
-
A safety plan outlining the overall strategy;
-
Requirements specifications ensuring clarity and traceability;
-
Risk analysis and assessment reports;
-
Design documentation;
-
Code analysis and review records; and
-
Testing and verification reports.
2. Approved Frameworks
The EMO has approved the following frameworks for use by Functional Safety Projects:
- Eclipse Trustable Software Framework
-
The Eclipse Trustable Software Framework (TSF) provides an evidence-based, data-driven approach to evaluating and quantifying the risks and trustworthiness of software, especially in safety- and security-critical systems. It uses a structured set of tenets and assertions to track claims, evidence, and requirements to enable continuous quantitative analysis and informed decision-making throughout the software life cycle.
3. Functional Safety Committee
3.1. Composition
The composition of the Functional Safety Committee is defined in the Working Group Charter.
Here is an example (template) for consideration in a Working Group Charter:
Powers and Duties
Functional Safety Committee members are required to:
Ensure that all Functional Safety Projects operate in an open, transparent, and vendor-neutral fashion in compliance with the Eclipse Foundation Functional Safety Process.
Apply and govern the Functional Safety Projects in the scope of this working group according to the Eclipse Foundation Functional Safety Process.
Approve Functional Safety Projects for adoption by the community.
Work with the related Project Management Committee (PMC) to ensure that the Eclipse Foundation Functional Safety Process is complied with by all related working group Functional Safety Projects.
Define (if any) customisations to the Eclipse Foundation Functional Safety Process.
Composition
Each Strategic Member of the working group is entitled to have a seat on the Functional Safety Committee.
Participant Members shall be entitled to at least one (1) seat on the Functional Safety Committee. In addition, an additional seat on the Functional Safety Committee shall be allocated to the Participant Members for every additional five (5) seats beyond one (1) allocated to Strategic Members via election. Participant Member seats are allocated following the Eclipse “Single Transferable Vote”, as defined in the Eclipse Bylaws.
One seat is allocated to Committer Members via election. The Committer Member seat is allocated following the Eclipse “Single Transferable Vote”, as defined in the Eclipse Bylaws.
Any additional individuals as designated from time to time by the Executive Director.
The Committee elects a chair who reports to the Steering Committee. This chair is elected among the members of the Committee. They will serve for a 12 month period or until their successor is elected and qualified, or as otherwise provided for in this Charter. There is no limit on the number of terms the chair may serve.
Meeting Management
The Functional Safety Committee meets at least once a quarter.
4. Certification
Only the Eclipse Foundation may pursue certification of the products created by Eclipse open source projects.
It is inappropriate for a specific vendor to engage in the process of certifying an Eclipse open source project. To do so would be a violation of vendor neutrality and Eclipse Foundation Trademark Usage Policy. On the other hand, it would be entirely appropriate for a vendor to engage in the process of certifying their own product based on the Eclipse open source project (which could be byte-for-byte identical to project contents), but under their own name.