Understanding Codethink's IEC 61508 Mapping for the Eclipse Trustable Software Framework

Codethink's mapping between the Eclipse Trustable Software Framework (TSF) and IEC 61508 shows how the methodology designed specifically for complex software system integration and modern continuous delivery workflows can be used to demonstrate compliance with the standard. We have achieved a process functional safety assessment of the Trustable Software Framework against IEC 61508, conducted by exida specialists in the assessment of software development tools for safety-critical real-time systems. Our goal is that software engineers will adopt the TSF methodology to record and organise compliance evidence across the full software lifecycle, whether they are building new software or integrating pre-existing components into safety-critical systems.

While resources like CASS provide assessment templates to guide auditors through mapping evidence to the standard’s clauses, Codethink’s mapping is designed for software engineering teams. We believe it’s the first independently assessed, openly available methodology designed for software integration at scale and speed. The mapping is available as an early access release while Codethink completes the functional safety assessment of CTRL OS, after which it will be contributed to the Eclipse Trustable Software Framework project.

What IEC 61508 Requires for Pre-Existing Software

IEC 61508 is the sector-agnostic base standard for functional safety of electrical and electronic systems. Sector-specific standards derived from it include ISO 26262 for automotive, IEC 62061 for machinery, IEC 62304 for medical devices, and EN 50128 for rail. Each adapts IEC 61508's framework to the particular demands of its domain, but the foundational requirements trace back to it.

The software part of IEC 61508 is written from the perspective that you are developing software for a defined purpose: you specify what that software must do, understand how it contributes to a system with particular safety goals, and build your assurance argument from that foundation. However, this creates a problem for open source software as it is typically intended for anyone to use in any way they like, licensed as ‘not fit for any particular purpose’, with no warranty, and no claim of quality. That determination is left to whoever integrates it. IEC 61508 recognises this reality and provides a specific Route 3S for pre-existing software that was not developed with a safety application in mind.

Route 3S requires organisations to provide evidence across a defined set of categories for software that was not developed for their specific safety application, including:

• Software safety requirements specification
• Justification for use
• Design
• Integration with the hardware
• Verification and validation
• Interference from functions not used by the safety function
• Credible failure mechanisms and mitigations
• Configuration and runtime environment
• Assumptions of use

In doing so, it provides a structured basis for the evaluation of pre-existing software based on the same criteria used for purpose-built safety-critical software. The principles underpinning Route 3S are shared by other standards addressing pre-existing software, including ISO/PAS 8926.

The mapping Codethink has published addresses those requirements directly, covering Routes 1 and 3 of IEC 61508 Edition 2.

What the Eclipse Trustable Software Framework Is

The Eclipse Trustable Software Framework (TSF) is an open source methodology, hosted at the Eclipse Foundation. Originated by Codethink through its initial project contribution, and actively supported by Codethink as a continuing maintainer, TSF provides a structured, measurable foundation for building software that can be trusted by OEMs and regulators alike. The framework is domain-agnostic: it is suited to any software-intensive system, not only Linux-based or open source systems or IEC 61508 applications.

TSF begins with a set of Tenets and Assertions. These are concise, verifiable statements about what must be true for software to be considered trustable. There are six Tenets, each defining a distinct area of evidence:

• Provenance captures where the software came from, what its dependencies are, and what is claimed about them, supported by mirrored dependencies, supply chain attestations, and regular reassessment of upstream risk.
• Construction defines how the software is built, installed, and run reproducibly, demonstrated through hash-verified, hermetic builds in controlled environments that can be reconstructed and independently verified.
• Changes tracks how the software is updated without breakage or regression and how upstream fixes are absorbed, maintained through CI-gated merge policies, vulnerability triage, and systematic tracking of upstream changes.
• Expectations document what the software must and must not do, independently of any particular implementation, grounded in defined behaviours, identified misbehaviours, and runtime monitors.
• Results establish whether the software does what it must and does not do what it must not, with test results linked directly to the specific Expectations they address in the Trustable Graph.
• Confidence brings together the reasoning about how confident we are in the software based on all of the above, including where uncertainty remains and why, maintained as an explicit, living account alongside the code.

The methodology is git-native. Statements and Artifacts live alongside source code in version control. The intent behind engineering decisions can often be lost in document-driven processes, which is why the TSF keeps it current alongside the code itself. When a developer makes a change that affects an existing Statement, the continuous integration pipeline flags it for review before it can be merged, keeping the assurance argument aligned with the software at every step.

Because the review happens inside the tools and workflow that engineers are already using, compliance is integrated into the workflow, rather than it being a separate exercise. TSF is designed to make compliance something engineers see as valuable to what they do, rather than a process imposed on top of their work.

John Ellis, "Rebuilding Trust: From Open Source to Open Accountability," OCX 2026

What the IEC 61508 Mapping to the TSF Covers

The mapping is Codethink's interpretation of how the TSF's Tenets and Assertions address the objectives of IEC 61508 Routes 1 and 3, translating each area of evidence into the standard's requirements. For example, the TSF category of Expectations documents how the behaviours, misbehaviours, indicators and constraints are derived and specified for software, and how these are traced to supporting evidence, which satisfies the IEC 61508 objectives for software safety requirements.

The mapping covers a standard-to-framework layer. An organisation that uses it will need to build on it to construct a compliance argument for a specific product and context, using the mapping as a practical, independently assessed starting point.

To understand what this looks like in a working system, consider how it operates day-to-day in our CTRL OS project. When a developer makes a change to the build environment, checking the Trustable Graph immediately surfaces any linked Statements that need review. The developer confirms the change does not invalidate them, marks them reviewed, and commits. Committed changes are reviewed through daily change control processes via tools such as GitLab, with safety-related changes signed off by a safety expert. The safety argument stays current with the code, providing a practical method for achieving continuous compliance.

Create Your Own Mapping Between the TSF and a Compliance Standard

Codethink's goal is for the Eclipse Trustable Software Framework to become the common engineering basis on which organisations across industries demonstrate alignment with the safety, security, and regulatory standards that are relevant to them.

For a long time, organisations have tried to navigate safety compliance in siloes, solving similar problems confidentially and separately. By making this mapping openly available, Codethink is taking a stand against that opacity. The vehicles, medical equipment, and industrial systems that depend on safety-critical software are used by everyone, and the reasoning behind why that software can be trusted should be open to scrutiny. That is why Codethink is inviting the industry to build on this work. The same process of mapping the TSF to IEC 61508 can be applied to other compliance standards: ISO 13849 for machinery safety, DO-178C for airborne systems, IEC 62443 for industrial security, or the medical device regulations applicable in your market. An open, community-maintained portfolio of mappings between the TSF and the world's most important safety and regulatory standards makes a shared foundation for reasoning about software trust at scale possible for open source projects, OEMs, and regulators. If you want to contribute to making software trust an open, shared endeavour, the first step is understanding what an independently assessed TSF mapping looks like in practice.

Request the early access IEC 61508 mapping here, review it, and reach out to discuss building one for the standards that matter in your domain.