Skip to main content

What is a Safety Manual?

If you have heard about Safety manuals but have not read one, or if you have read a Safety manual, tried to apply it and found it very challenging, this article is for you. In this blog, we talk about:

  1. Who needs a Safety manual?
  2. What is a Safety manual and what does it describe?
  3. Best Practices when working with Safety manuals

Interestingly, ISO26262 never mentions “Safety manual” except in Part 11 for Semi-conductors, though its parent IEC 61508 describes the role of Safety manuals. Refer this article.

Who needs a Safety manual?

Let us assume that you are a Safety Manager or a Systems/Software/Hardware architect involved in the start of an Autonomous driving solution and the Safety goals of the program are at ASIL D.  Your technical sales team has already shortlisted two Microcontrollers that are at ASIL D, and now you are asked to evaluate both from a Safety perspective. Your first stop for information is the Safety manual of these Micros. You look through the Safety manual to understand how to use the MCU in the Autonomous driving context, check whether the assumptions made by the MCU match with your Systems’s requirements.  For example, if your system requires Lidar sensors to achieve its Safety goals, does the MCU have communication with Lidar sensors within its Safety scope?

There are mainly three different stakeholders for a Safety manual:

Stakeholder

Why are they interested in the Safety manual?

A supplier of an SEooC

They write the Safety manual. They describe how to use the SEooC in the product so that the users can successfully achieve the Safety functionality that the SEooC is providing. They describe the prerequisites, do’s and dont’s of using the SEooC.

A Project team (Safety Manager, Project Manager, System, Hardware or Software Architects) who is looking in the market for an ASIL certified HW, SW or a System

They want to understand whether the Solution available in the market will fit their needs and if there are any constraints imposed on their System when integrating the SEooC.

The Technical team (Safety Manager, System, Hardware or Software Architects) of a Project that has purchased an ASIL compliant HW, SW or System SEooC from a supplier

They want to understand how to integrate the SEooC in order to implement the required Safety functionality


Safety manuals are usually provided for System, Hardware and Software SEooCs

  1. ASIL compliant HW Components, such as Microcontrollers, PMICs
  2. ASIL compliant SW such as Operating Systems, Libraries, Low level drivers, Middleware stack or a standalone SW unit
  3. ASIL compliant Systems (for e.g., an electric parking system, a seat belt locking system)

What is a Safety manual and what does it describe?

The Safety manual is a document that describes the Safety functionality provided by the SEooC and how to use it correctly (in other words, how to integrate the SEooC correctly). It is the starting point for the user to understand the Safety features of the SEooC. A user may refer other supporting documents to get further details of the features after getting atleast an initial overview from the Safety manual.  


Best Practices while working with Safety manuals

Here are some best practices for Item development teams while working with Safety Manuals:

1. Assign qualified functional safety professionals

Do not treat the Safety Manual like a layman’s document. Assign only qualified functional safety professionals to work with Safety Manuals. Ideally, the functional safety manager together with a functional safety trained/experienced Systems/SW/HW professional. Brainstorm heavily on the assumptions stated and how to validate them.

2. Treat the assumptions as Requirements

Treat the Assumptions stated in the Safety manual like Requirements placed on the Item (just like a Customer requirement). There may be System, hardware and Software assumptions. System assumptions must be integrated in the Technical Safety Requirements (TSR) of the Item. Hardware assumptions must be integrated into the Hardware Safety requirements (HSR) and Software assumptions into the Software Safety requirements (SSR) of the Item.

3. Deeply understand every assumption

Thoroughly understand every assumption stated in the Safety manual. To do this, have an active and close coordination with the SEooC supplier. Clarify with the supplier on the rationale behind the assumptions and challenge the supplier to provide additional hints and details if required.

4. Read the Supporting technical documentation

Read not only the Safety manual but also the supporting technical documents to get a good understanding of the design of the SEooC. Be informed that a supplier cannot practically put every detail into a Safety manual. For example, if you are integrating an ASIL Micro, the data sheets is as important as the Safety manual.  

5. Start Early!

Read the Safety manual at start of the program, and not at the fag end when you have nearly finished implementation. Otherwise you will surprised with the assumptions made by the SEooC and may land up having to redesign your system or ask the SEooC to make a change to fit your item context.

That’s it! Easily written but hard to implement J!!

Please write to us if you have any challenges and we will be happy to help you.