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.
|
# |
Topics
described in the Safety Manual |
Examples |
|
1 |
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. |
|
2 |
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. |
|
3 |
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. |
|
4 |
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 |
|
5 |
The highest ASIL level that the SEooC has been
developed for |
Whether the SEooC can be used upto ASIL-A, B, C
or D. |
|
6 |
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 |
|
7 |
The Functional use cases in which the SEooC can
be used |
An Autosar-Watchdog manager can be used in several use cases such as
|
|
8 |
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 |
|
9 |
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) |
|
10 |
(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.