TT Design Example (ISO 26262, ASIL D)
From our base in the UK Midlands, the team at SafeTTy Systems Ltd provides support for organisations across the world that need to create real-time embedded systems that are reliable, safe and secure.
Our customers include developers of industrial, automotive, marine, medical, aerospace, defence and satellite systems, as well as companies producing high-end consumer goods.
Our products and services are based on the use of ‘Time-Triggered‘ (TT) system architectures.
On this page, we explore the design of a TT ‘Electronic Control Unit’ (TT ECU) for a passenger car, in compliance with ISO 26262 (ASIL D).
We begin by looking briefly at some of the links between TT systems and ISO 26262.[This page was last updated: 2017-04-13]
TT software architectures
You’ll find an introduction to TT software architectures on our Technology page.
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.
For example, to address the following faults: blocking of execution; deadlocks; livelocks; incorrect allocation of execution time; incorrect synchronisation between software elements, solutions involving time-triggered scheduling, monitoring of processor execution time and program sequence monitoring are proposed in the standard [ISO 26262-6, Annex D].
In addition, in ISO 26262-5 (Annex D), detailed consideration is given to ways in which the level of diagnostic coverage provided by different mechanisms can be assessed. When considering processing units, it is considered that use of software diversified redundancy can be a way of achieving what is defined in this standard as “High” diagnostic coverage (see ISO 26262-5 Table D.4 and Section D.2.3.4).
TT architectures also provide an extremely effective way of supporting “ASIL decomposition” (a key feature of many ISO 26262 designs): we say more about this in the example below.
Developing a cost-effective automotive ECU (ASIL D)
In this example, we will consider an “electronic control unit” (ECU) for use in an automotive application. We will assume that this design is being developed in compliance with ISO 26262.
We will assume that this 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.
We will further assume that – 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: Working with a single (‘ASIL D’) MCU plus external monitoring unit
We will first explore a design in which we provide implementations that meet both FSRx1 and FSRx2 by means of the same microcontroller.
We can clearly 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 very effectively (and economically) using a TT design and external monitoring unit.
Partitioning the ECU design
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, and is supported by the available TTRDs.
However, use of a TT architecture alone is not sufficient to meet our requirements in this case: we need to provide an appropriate run-time monitoring system.
We need to be clear what we can realistically expect to achieve in such a 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. As a consequence, 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 such interference if / when it occurs, 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 A.
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).
It should be emphasised that such monitoring can be carried out [i] on the same processor platform that is used to execute the implementations resulting from FSRx1 and FSRx2; or [ii] on a separate (independent) processor platform. Where an independent processor is employed, we call this a WarranTTor® design.
If the WarranTTor detects a problem, it is able to move the system to a safe state (even if the main processor unit is behaving outside the specification, or has ceased to function altogether): again, the timing of the transition to a safe state can be determined precisely at design time. It is also important to appreciate that the WarranTTor unit need not be located immediately adjacent to the unit that is being monitored: for example in some designs the WarranTTor unit may be located several metres from the main processor.
Overall, both internal monitoring and external monitoring can be effective in TT designs, but there is usually a higher risk of common-mode failures in situations where an external device is not employed. It is therefore not surprising that – in an ISO 26262, ASIL D design – use of an external monitoring facility is “Highly Recommended” (ISO 26262-6 , Table 4) as a means of error detection at the software architecture level.
Working with “Plausibility Checks”
Once we have the main ECU software architecture and monitoring system in place, we can move on to consider the detailed design and implementation process. Again, there are various TTRDs that can assist in this work.
In this case, our implementation will be based on a TT task scheduler that supports what is sometimes called “Contract-Based Design” (CBD) and is referred to in ISO 26262 as “Plausibility Checks” (PCs). Use of CBD/PCs is widely recognised as a means of reducing the number of residual errors in complex software systems, and – in an ISO 26262 project – use of this approach is “Highly Recommended” for ASIL D designs (ISO 26262-6, Table 4).
Use of CBD/PCs in reliable embedded systems is described in Chapter 5 of ‘ERES2‘.
Completing the design of main ECU unit
Please refer to our TT Design Guide for further information about the techniques that would be employed to complete the design and implementation of the main ECU unit.
Design B: Employing two ‘ASIL B’ MCUs
In the discussions above, we have assumed that the design will be based on a single “lockstep” processor plus an external monitoring unit.
Another – obvious – way of providing an independent implementation is to begin by allocating FSRx1 and FSRx2 to different microcontrollers. For example, rather than employing a single “ASIL D” processor plus monitor, we could consider a design based on two (independent) “ASIL B” processors. This can be a cost-effective effective design option in some cases.
One potential advantage of such an approach is that we can employ a different software design on each processor (potentially reducing the risk of systematic design failures): we may also wish to employ a different microcontroller family for each processor (potentially reducing the chances of common-cause hardware failures).
We call this a DuplicaTTor® design.
Note that in a DuplicaTTor design, we usually employ a “cross PredicTTor”: that is, each microcontroller will check the task sequence on the other microcontroller. This can be a very effective solution.
Our DuplicaTTor® packages provide a very effective means of prototyping such designs.
Other applications of design partitioning
Use of a TT platform with MoniTTor and PredicTTor technology provides an effective means of allowing multiple functions to operate with independently and safely on a single processor.
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.
SIL decomposition is often implemented using a DuplicaTTor® design.
Read the complete case study 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.
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.
The above characteristics mean that appropriately-implemented TT systems provide a particularly effective means of meeting the requirements of various international safety standards.
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).
Developing safe and secure autonomous vehicles in compliance with ISO 26262
You may also be interested in our design notes about the development of autonomous road vehicles in compliance with ISO 26262.
Learn more on our autonomy page.