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:
- Who needs a Safety manual?
- What is a Safety manual and what does it describe?
- 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
- ASIL compliant HW Components, such as Microcontrollers, PMICs
- ASIL compliant SW such as Operating Systems, Libraries, Low level drivers, Middleware stack or a standalone SW unit
- 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.