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:


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.   


Topics described in the Safety Manual



The Safety features, functionalities and mechanisms provided by the SEooC

For a Microcontroller SEooC, it describes the peripherals or HW blocks that were considered to be safety-relevant and the safety mechanisms implemented by the Micro to detect failure modes in its Input acquisition, processing and Output activation.


Boundaries of the SEooC

If a Micro vendor provides also SW such as MCALs or libraries, then the boundary of the SEooC would be only those specific MCALs and libraries provided, and everything else will be outside of this boundary.


The shortest FTTi that can be achieved by the SEooC

A Microcontroller SEooC assumes a certain FTT time for its ‘assumed’ Safety goals, for e.g., 300ms. 


HW Metrics (for HW SEooC)

The FIT rate, SPFM and LPFM that can be achieved by the SEooC if all the Safety mechanisms provided by the SEooC are used in the Item


The highest ASIL level that the SEooC has been developed for

Whether the SEooC can be used upto ASIL-A, B, C or D.


The Application Safety context in which the SEooC is assumed to be used

For a Microcontroller SEooC, that can be used in Body control applications as well as ADAS Applications, what is the Safety path for the assumed Safety goals for each application and which peripherals of the Microcontroller are involved in every Safety path


The Functional use cases in which the SEooC can be used

An Autosar-Watchdog manager can be used in several use cases such as

  • To check the aliveness of a task or process
  • To check the sequence of execution of different tasks
  • To verify that the time taken from 1 execution step to another step does not exceed a specified deadline


Assumptions regarding the context and conditions of use

a SW SEooC can be used only in Autosar Architecture

a SW SEooC can only be used with a QNX ASIL certified OS

a HW SEooC can only be used upto a temperature of 100 deg C


Assumptions made while developing the SEOOC that need to be validated by the product integrating the SEooC

These assumptions can be placed on the HW, SW or the System of the Item in which the SEooC is integrated. For example, a Microcontrollor SEooC typically depends on the SW of the integrating Item to detect some of the failures that it cannot internally handle (such as implementing a core test). It will also depend on SW to enable or configure the Safety mechanisms that is providing (such as enabling ECC)


(Optionally) Strategy for Safety Analyses and DFA

In some cases, an SEooC may also describe their Safety analyses and DFA strategy and what are the Safety measures either implemented within the SEooC or assigned to the Integrating item, in order to address all the applicable faults.

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.