Skip to main content

FuSa Myth 2 - It is just paper work!

"Lets get the Implementation done, and go out to an agency like XYZ, find out about the paper work and get our work certified"

This is a language we have heard being spoken several times.

MYTH 1: Functional Safety is just "paper work"!
Fact: Functional Safety is the discipline of designing Safety into every stage of the product life cycle starting right at the concept phase
For some one who has just started with functional safety, and refers the standard, this can be overwhelming:

The 2nd edition of ISO26262 has
  • 11 Parts
  • 37 Clauses
  • > 100 Work products!
Here is a mindmap of the different work products needed (those starting with x.5.x)

Why do we need so many work products?

This is because Functional Safety is designed into
- every phase of the product life cycle
- processes as well as technical methods
- every stage of every phase
In other words, the Standard spans the entire breadth and width of how a safety-relevant product is built, right from concept till production, operation, service and decommissioning.
How do these work products really help us?

Broadly in the following ways:

1. Work products enable and guide us to design a Safe System.

ISO26262 provides Methodologies on how to design Safety in every phase of the product. With a good understanding on why these methods are suggested, and how to implement them, it is possible to build a state-of-the-art Safety system. This is where work product templates can be a great aid. A well-defined template shall be designed to cover the expectations of the Standard, by way of expanding on how to implement the suggested methods. This goes hand-in-hand with a clear definition on an Organizational level on what are the metrics that can be verified to evaluate if a certain method has been applied correctly for the required ASIL level. Well defined templates, supported by the Organization's best practices will enable the design of a Safe system.
2. Well-described and documented Work products act as the Evidences to prove that the developed System is sufficiently Safe and satisfy the OEM’s ASIL Requirements.
These evidences can be evaluated against the Organization's metrics to ensure that the system is safe enough (for the required Safety level). Evidences help remove ambiguities on the design, ensures best practices are followed, and promotes higher reuse in a longer run.
Please also note that the Standard never expects you to do more than what is required-- So it provides very clear guidelines on which methods or processes are mandatory, optional or not even required for a particular ASIL level. Hence, documenting diligently will actually help to simplify the System and avoid over-engineering.
So, next time if you hear some one sigh about the paper work, please tell them its not. It is a liability issue - for someone's life.