Why Safety Manuals Matter: Getting the Most from Safety-Certified Software
15 Sep, 2026Key takeaways:
Safety Manuals play a critical role in functional safety compliance by explaining how a safety-certified component must be integrated and used. This article explains:
- What a Safety Manual is and why it matters.
- Why Assumptions of Use (AoUs) are critical for certification.
- What auditors look for during safety assessments.
- How SAFERTOS® and the DAP help reduce certification effort and improve audit readiness.
Developing a safety-critical system is rarely a matter of building every component from scratch. Instead, system developers typically integrate certified safety elements that provide proven functionality and can be incorporated into a larger safety architecture. SAFERTOS® is one such example: a Safety Element out of Context (SEooC), developed and assessed independently of any specific end application.
However, obtaining a safety-certified component is only part of the story. To benefit from the safety integrity level achieved by that component while supporting functional safety compliance, it must be used correctly within the final system. This is where the Safety Manual becomes a critical part of the certification process.
What is a Safety Manual?
A Safety Manual provides guidance on how a safety-certified product must be integrated, configured, and operated so that its certified safety properties remain valid in the target application.
The manual captures the assumptions made during the product’s safety assessment and translates them into practical guidance for system integrators and developers. By following these requirements, developers can demonstrate that the product is being used in the way that was evaluated during certification.
For a safety-certified RTOS such as SAFERTOS®, the Safety Manual forms an essential bridge between the certification evidence produced by the RTOS vendor and the safety case being developed for the final application.
The Importance of Assumptions of Use (AoUs)
One of the most important concepts described in a Safety Manual is the Assumption of Use (AoU).
An AoU defines a condition that must be met by the system integrator or application developer for the safety certification of the product to remain applicable. These assumptions may relate to system architecture, configuration choices, hardware features, development processes, verification activities, or operational constraints.
The safety certification of a SEooC is achieved under a defined set of assumptions. If those assumptions are respected, the certification evidence can be reused by the end application. If they are not, additional analysis, justification, or even re-certification activities may be required.
For this reason, AoUs should not be viewed as recommendations. They are requirements that preserve the validity of the certified safety claims.
What Auditors Look For
During a functional safety assessment, auditors do not simply verify that a certified component has been selected. They also verify that it has been used according to the conditions specified in its Safety Manual.
A common activity during an audit is the review of AoU compliance. Auditors typically expect to see:
- Evidence that every AoU has been reviewed.
- Traceability showing how each AoU has been addressed.
- Justification where an AoU is not directly applicable.
- Documentation demonstrating that the system design remains consistent with the assumptions made during certification.
The ability to quickly demonstrate compliance with all applicable AoUs can significantly simplify the assessment process and improve audit readiness.
Reducing Certification Effort
One of the key benefits of using a safety-certified RTOS is the ability to leverage existing certification evidence.
The safety assessment of SAFERTOS® already addresses many aspects of operating system behaviour, including mechanisms related to error detection, partitioning, scheduling, health monitoring, and fault handling. When the Safety Manual guidance is followed, system developers may rely on these assessed characteristics rather than having to justify equivalent functionality from first principles.
This allows development teams to focus their effort on their application-specific functionality while building on a trusted and independently assessed foundation.
In practical terms, less effort is spent generating duplicate safety evidence, and more effort can be directed toward demonstrating the safety of the application itself.
Avoiding Delays and Rework
Failure to address Safety Manual requirements early in a project can create significant challenges later during certification.
AoUs often influence architectural decisions, development practices, test strategies, and configuration choices. Discovering late in the project that an AoU has not been satisfied may require design modifications, additional verification activities, or updates to safety documentation.
Such findings can delay certification activities and introduce unnecessary project risk.
By reviewing the Safety Manual at the start of the development lifecycle and continuously tracking compliance with applicable AoUs, teams can identify potential issues early, reduce rework, and maintain a smoother path toward certification.
The SAFERTOS® Design Assurance Pack
The Safety Manual provides the integration guidance needed to deploy SAFERTOS® within a safety-critical application. The SAFERTOS® Design Assurance Pack (DAP) provides the evidence that supports those instructions. Together, they help organisations reduce certification effort by leveraging existing certification evidence instead of generating everything from scratch.
The DAP contains the complete lifecycle evidence generated during the development and certification of SAFERTOS® for a specific processor and compiler combination, including requirements traceability, design documentation, hazard analyses, verification and validation records, source code, test harnesses, and structured safety case documentation.
Combined with the guidance provided by the Safety Manual, the DAP helps improve audit readiness, reduce unnecessary re-testing, minimise certification risk, and provide the transparency needed to demonstrate how safety has been achieved, from source code to instruction set.
Conclusion
A Safety Manual is far more than a supporting document supplied alongside a certified product. It is the mechanism that allows safety certification evidence to be transferred from a SEooC to the final application.
For safety managers, it provides a clear set of requirements that must be satisfied. For developers, it identifies the conditions necessary to preserve certified safety properties. For auditors, it provides the basis for verifying that a product has been integrated correctly.
Ultimately, following the guidance contained in the Safety Manual helps preserve certification claims, reduce assessment effort, avoid rework, and streamline the path to successful certification. Combined with the SAFERTOS® DAP, it provides the evidence and guidance needed to demonstrate compliance and leverage existing certification work more effectively.
Author
Emiliano Costagli, Product Manager
Back to News