Electronic Control Unit (ISO 26262, ASIL D)
On this page, we explore the design of a ‘Electronic Control Unit’ (ECU) for a passenger car, in compliance with ISO 26262 (ASIL D).
The design is based on a ‘Time Triggered‘ (TT) software architecture.
We begin by looking briefly at some of the links between TT systems and ISO 26262.[This page was last updated: 2017-09-15]
TT software architectures and ISO 26262
TT software architectures – supported by the techniques described in the ‘ERES2’ book – provide an excellent foundation for robust and cost-effective ISO 26262 designs.
What distinguishes TT approaches is that it is possible to model the expected system behaviour precisely. This means that: [i] during the development process, we can demonstrate that all of the requirements have been met; and [ii] at run time, we can detect problems very quickly.
The end result is that we can have a high level of confidence that a TT system will either: [i] operate precisely as required; or [ii] move into an appropriate state if a problem occurs.
To understand some of the particular benefits offered by a TT approach when developing products in compliance with ISO 26262, please consider the following potential run-time faults:
- blocking of execution;
- incorrect allocation of execution time; and,
- incorrect synchronisation between software elements.
To address these faults, solutions involving time-triggered scheduling, monitoring of processor execution time and program sequence monitoring are proposed in ISO 26262 (please refer to ISO 26262-6, Annex D). The TT platforms explored in this design example provide a highly-effective way of implementing all of these solutions.
In addition. TT architectures provide an effective way of supporting “ASIL decomposition” (a key feature of many ISO 26262 designs): we will say more about this in the example below.
Developing a cost-effective automotive ECU (ASIL D)
In this example, we will consider a TT “electronic control unit” (TT ECU) for use in an automotive application.
We will make the follow assumptions:
- that this design is being developed in compliance with ISO 26262;
- that the design 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) D, 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 B (D).
Design A: Employing two ‘ASIL B’ MCUs
We will first explore a design in which we provide implementations that meet both FSRx1 and FSRx2 by means of two different microcontrollers (MCUs). For example, we could implement our ‘ASIL D’ design using two “ASIL B” processors: we’ll call these ‘MCU-A’ and ‘MCU-B’.
Since we are using two MCUs, we have the potential for a high level of independence between the FSR1 and FSR2 implementations (assuming that we employ a hardware design that does not introduce the potential for common-cause failures – for example, through the use of a shared power supply). This allows us to meet the key requirements for ASIL decomposition.
The second goal of a two-processor solution is to ensure that if one MCU fails to operate correctly, the second MCU can detect this and act ‘appropriately’. Such appropriate actions will often mean ensuring that the system moves into a fail-safe state.
Use of a TT design can greatly simplify this important monitoring activity.
For example, in Design A, we would expect to incorporate the following activities on each MCU:
- we would use an internal watchdog timer to ensure that the TT scheduler is operating correctly.
- we would monitor the execution time of each task that is released by the scheduler, to ensure that it always operates within precisely predetermined ‘Worst Case Execution Time’ (WCET) and ‘Best Case Execution Time’ (BCET) limits.
- while each task is operating, we would perform memory checks and tests of the relevant register configurations.
In addition, we would typically perform the following cross-MCU checks:
- MCU-A would check that MCU-B is releasing the correct tasks, in the correct execution sequence.
- MCU-B would check that MCU-A is releasing the correct tasks, in the correct execution sequence.
- MCU-A would check that the operating environment for MCU-B – such as the power supply voltage and the temperature – is appropriate.
- MCU-B would check that the operating environment for MCU-A is appropriate.
In this way, we can detect all of the faults identified above (blocking of execution, deadlocks, livelocks …).
Example hardware platform for exploring Design A
Our DuplicaTTor Evaluation Board (DEB) provides an effective way of exploring Design A.
The DEB has two independent channels, each of which incorporates:
- an STM32F405VG microcontroller with debug (JTAG/SWD) and trace (ETM) interfaces;
- a 16MHz crystal-based oscillator module;
- a voltage supervisor with watchdog and manual reset functions;
- a linear power supply (3.3VDC / 400mA);
- a USB-UART Interface (typically used for reporting to a laptop and / or fault injection);
- a CAN Interface with protection and on-board termination;
- a reference voltage source (3.0V ) for analogue measurements;
- a PTC-based temperature sensor;
- a 7-segment LED display with driver circuitry;
- three LEDs (red, yellow, green) for general use;
- a Power-On Reset (POR) button;
- a reset button;
- a user button;
- two 40-pin port extension connectors.
Further information can be found on our DEB page.
Design B: Working with a single (‘ASIL D’) MCU plus external monitoring unit
We will now explore a design in which we provide implementations that meet both FSRx1 and FSRx2 by means of the same microcontroller.
We can justify such a design if (and only if) we are able to ensure that the two implementations will be able to operate independently.
In many cases, this can be achieved effectively using a TT software design running on a single ‘ASIL D’ MCU.
The key to demonstrating independent operation of the implementations resulting from FSRx1 and FSRx2 is to run the related tasks in interleaved time-slots: this is straightforward in a TT design.
It is very important that we are clear what we can realistically expect to achieve in a single-MCU design:
- in any non-trivial embedded system, there are a great many ways in which it is possible for tasks (and other software components) that share a CPU, memory and other resources to interact;
- any claim that we can prevent any interference between these components would be likely to be met with some scepticism – even if we hardware hardware devices such as “memory protection” / or “memory management” units available on our chosen microcontroller;
- while it may not be possible to prevent all forms of interference, we can detect it, if we use [i] an appropriate hardware platform; [ii] an appropriate software architecture; and [ii] appropriate monitoring systems. This is what we seek to achieve in Design B.
In this case, the use of a monitoring unit (incorporating ReliabiliTTy® technology) would provide a very high level of diagnostic coverage, and allow us to be confident that any interference between the implementations resulting from the two FSRs will be detected within a pre-determined time interval (typically measured in microseconds, where required).
Example hardware platform for exploring Design B
The single-MCU software design presented on this page could be applied with a very wide range of target hardware.
For example, some ‘ASIL D’ MCU options that could be considered are:
- The ST SPC570S family;
- The NXP / Freescale MPC564xL family;
- The TI TMS570 family;
- The Infineon AURIX™.
We can assist with such implementations: please contact us for details.
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.
Working with a TT Wrapper
In the ECU design example presented on this page, we have assumed that the complete system will be created using a TT software architecture.
In some systems, use of a TT architecture is not possible for all parts of the design. This may be – for example – because some components (e.g. sensors, vehicle controllers, actuators) have already been incorporated in the vehicle design. In some cases, these components may not be fully ISO 26262 compliant.
In these circumstances, we may be able to incorporate a TT Wrapper to address this problem.
One potential application of such a TT Wrapper is shown in the figures below.
We say more about TT Wrappers in our autonomous vehicle design example.
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).