Do you always need a safety plan for Functional Safety Projects?

Functional safety projects often come with a lot of documentation requirements, and one of the common questions we hear is whether a safety plan is always necessary.

For example, recently, we supported a project, where our customer was in charge of implementing two safety functions, both at Performance Level PL c (as per ISO 13849-1). The certification body informed the customer that a safety plan was not required for this project for the assessment and certification, because the project was not complex enough. There was even an argument that since an SRS (Safety Requirements Specification) was in place, a safety plan was not needed. We believe that having a safety plan is a best practice—even for less complex projects.

Let’s explore why a safety plan is important and how it benefits projects of all sizes and complexities.

What is a Safety Plan?

A safety plan is a documented roadmap that outlines how a project will achieve its safety goals. It typically includes:

• Safety objectives and goals
• Roles and responsibilities of the team
• Risk management process
• Validation and verification strategies
• Compliance with standards (e.g., ISO 13849, IEC 61508)
• Timeline and milestones for safety activities

It’s a critical tool for ensuring that all safety aspects are systematically addressed throughout the project lifecycle.

Key Difference Between a Safety Plan and SRS

While both the Safety Plan and the Safety Requirements Specification (SRS) are essential for functional safety projects, they serve different purposes:

• The Safety Plan describes how safety will be managed and implemented, i.e., the process. It outlines steps like hazard identification, risk management, validation, compliance, and assigning roles and responsibilities.
• The SRS defines what the system must do to meet safety goals, i.e., the technical requirements. It specifies details like safety functions (e.g., “emergency stop must activate within 500 ms”) and performance levels (e.g., PL c, diagnostic coverage of 90%).

When is a Safety Plan Essential?

While some might argue that a safety plan is only necessary for complex projects or big teams, we believe it is always a best practice—regardless of the project’s size or complexity. Here’s why:

1. Systematic Safety Prioritization: Even simple projects can have critical safety functions. A safety plan provides a systematic way of handling the development, putting the required priority on safety (roles, activities, etc.)
2. Compliance and Traceability: A safety plan provides a clear record of how safety requirements were met, making it easier to demonstrate compliance with standards and regulations during audits or certifications.
3. Future-Proofing: If the system is modified or expanded in the future, a safety plan serves as a reference point for understanding the original safety considerations and ensuring continuity.
4. Stakeholder Confidence: A well-documented safety plan builds trust with customers, certification bodies, and other stakeholders by demonstrating a commitment to safety.

In the case of our client’s project, the certification body determined that a safety plan was not required due to the project’s simplicity. However, we still encouraged the customer to document their safety approach thoroughly. This not only ensured compliance with ISO 13849-1 but also provided a clear and traceable record of their safety processes.

What About Simpler Projects?

For simpler projects, the safety plan doesn’t need to be overly complex. It can be tailored to the project’s scope while still covering the essential elements:

• Clear lifecycle phases
• Clear identification of roles and responsibilities for the project team
• Clear identification of compliance arguments (which standards, etc.)

By creating a safety plan, even for simpler projects, you ensure that nothing is overlooked and that the project adheres to best practices in functional safety.

Key Takeaways

• A safety plan is a best practice, regardless of the project’s complexity or performance level.
• It ensures systematic risk management, compliance, traceability, and stakeholder confidence.
• For simpler projects, the safety plan can be tailored to the scope while still covering the essentials.

What do you think?

We believe a safety plan is always a best practice, but what’s your experience? Have you worked on projects where a safety plan wasn’t required? What worked well, and what challenges did you face? Let’s discuss. Details about our offer of functional safety consulting are available here.