Supporting ‘ASIL Decomposition’ (ISO 26262, ASIL B)
The decomposition of ‘functional safety requirements’ (FSRs) is a process that is often employed in designs that are developed in compliance with international safety standards such as ISO 26262 and IEC 61508. The process is usually referred to as ‘ASIL decomposition’ or ‘SIL decomposition’.
As an illustration, the figure below summarises the end result of decomposing a single FSR (at ‘ASIL B’) into two equivalent FSRs (in this case at ‘ASIL A’).
Decomposition of FSRs is often employed because:
- confidence in the safety of the associated system can be increased through this process;
- the cost of meeting the two decomposed FSRs can be significantly lower than that of meeting the original FSR (‘ASIL B’).
To justify such a decomposition, the two new FSRs must be implemented independently (and it must be possible for the development team to demonstrate – clearly and unambiguously – that the two implementations are independent).
One way of providing an independent implementation is to begin by allocating the two new FSRs to different MCUs: our DuplicaTTor Evaluation Board is often used to prototype such designs.
An alternative way of supporting the decomposition of FSRs is to provide a means of executing two sets of tasks by means of the same MCU: we can do this if we are able to ensure that the two implementations will be able to operate independently: what we call a ‘DecomposiTTor Platform’ provides an effective means of achieving this goal.
A DecomposiTTor Platform is made up of a single MCU, a single scheduler and two independent sets of tasks. To create the two independent task sets, we – can – for example – design one set of tasks, and then – using the techniques discussed in Chapter 6 of ‘ERES2‘ – create a set of matching ‘Diverse Tasks’.
To be clear. We do not attempt to claim that we can prevent all interference between tasks that execute on the same MCU. However, by building on the techniques presented in Part Two and Part Four of the ‘ERES2‘ book, we can be confident that we will be able to detect any interference between such tasks: this is what we require to support successful ASIL / SIL decomposition on single MCU.
Complete code example (TTRD2-25a)
We’ve created a simple code framework to illustrate the process of ASIL decomposition on a single MCU.
This framework is assumed to the core software in a low-cost ECU for a passenger car: the design is assumed to be developed in compliance with ISO 26262.
The ‘Electronic Control Unit’ is based on a ‘Time Triggered‘ (TT) software architecture.
In this design, we will make the follow assumptions:
- that this product is being developed in compliance with ISO 26262;
- that the product has been identified (following the processes defined in ISO 26262) as having at least one Functional Safety Requirement (FSR) – we’ll call it ‘FSR x’ – at ‘Automotive Safety Integrity Level’ (ASIL) B, and that the task of meeting this functional safety requirement has been allocated to our ECU; and,
- through a process of ‘ASIL decomposition’ (as defined in ISO 26262) – we have decomposed FSRx into two new FSRs (FSRx1 and FSRx2), each of which is at ASIL A (B).
Our prototype code for this example targets an NXP® S32K144 processor (and the S32K144 Evaluation Board).
The example code includes the following components:
- a TTC (Task) scheduler [‘ASIL B’ in the production code];
- two sensor-processing tasks [‘ASIL A’ in the production code];
- a sensor-fusion task [‘ASIL B’ in the production code];
In the production code, the sensor-processing tasks – which are the core ‘decomposed’ compoents in this simplified example – would be implemented as ‘Diverse Tasks’: see ‘ERES2‘, Chapter 6.
In the example, the ‘sensor-processing’ involves reading two inputs (SW2 and SW7 on the S32K144 EVB). One task uses a conventional switch and the other uses a capacitive touch sensor (to illustrate the requirements for design and implementation diversity).
The ‘sensor fusion’ task then performs some sanity checks on the outputs from the two sensor tasks and – if it is happy – it changes the state of an LED.
Overall – while the example is very simple – the software architecture is appropriate for use in an ‘ASIL B’ design.
The complete code example is available on our TTRD page (look for TTRD2-25a).
Other applications of design partitioning
Use of a TT platform with ReliabiliTTy technology provides an effective means of allowing multiple functions to operate independently and safely on a single- or multi-processor TT design.
This approach has numerous applications in modern automotive systems, and in many other sectors.
For example, in aerospace designs developed in compliance with DO-178C, partitioning is seen as a key architectural consideration. In this standard, partitioning is viewed as a technique for providing isolation between software components in order to contain and/or isolate faults, and potentially reduce the effort of the software verification process [DO-178c, Section 2.4.1].
Similarly, in designs developed in compliance with IEC 61508, ‘SIL decomposition’ is also a common requirement. See IEC 61508, Part 2, Clause 7.4.3.
Learn more in ‘ERES2’
The Second Edition of ‘The Engineering of Reliable Embedded Systems’ (ERES2), documents an industry-proven approach to the development of software for reliable, real-time embedded systems, based on the use of ‘Time Triggered’ (TT) architectures.
In order to illustrate how the TT techniques presented in ERES2 can be employed in practical designs, five detailed case studies are included. These studies describe the development of embedded control and monitoring systems for the following products:
- an industrial alarm sounder unit (IEC 61508, SIL 2);
- a domestic washing machine (IEC 60730, Class B);
- a hospital radiotherapy machine (IEC 62304, Class C);
- a steering-column lock for a passenger car (ISO 26262, ASIL D);
- an aircraft jet engine (DO-178C, Level A).
Examples of current ISO 26262 projects at SafeTTy Systems Ltd
At present, we are helping many of our customers to develop automotive systems in compliance with ISO 26262.
For example, we can assist in the development of ‘Safety Elements out of Context‘ (SEooCs). These are ‘components’ (such as a sensor or a software library) that will ultimately be used as part of a larger vehicle system.
In such projects, our role might include: [i] performing an ISO 26262 ‘gap analysis’; [ii] providing design advice and / or training; [iii] assisting with the process of obtaining an ‘ISO 26262 SEooC certificate’ from a third-party organisation (such as TÜV); [iv] assisting with the creation of the Safety Manual.
A particular focus of our current work is on SEooCs for use in semi-autonomous / autonomous vehicles (up to SAE Level 4 / Level 5).
[This page was last updated: 2018-05-01]