Creating safer autonomous road vehicles in compliance with ISO 26262

One of the challenges that has been raised by our customers in recent months is the need to improve confidence in the safety of autonomous systems (such as ‘driverless’ cars).

This is a far from trivial challenge, not least because existing ‘autonomous road vehicle controllers’ (ARVCs) tend to be highly-adaptive in nature. The adaptive characteristics of ARVCs arise through the use of neural networks or other artificial intelligence (AI) components that allow them to acquire new patterns of behaviour.


If the behaviour of an ARVC can change on a day-to-day basis, how can we tell that the system is doing something wrong? What benchmark can we use?

In this short article, we consider ways of improving confidence in the safety of autonomous road vehicles through the use of a form of a ‘Time Triggered‘ (TT) software architecture. More specifically, we will consider the use of a form of ‘TT Wrapper’ around an existing ARVC.

We begin by looking briefly at some of the links between TT systems and ISO 26262.

[This page was last updated: 2017-09-12] empty_space


TT software architectures and ISO 26262

The designs discussed on this page employ ‘Time Triggered‘ (TT) software architectures.

TT 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;
  • deadlocks;
  • livelocks;
  • 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). TT platforms 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).


Developing a cost-effective automotive ECU (ASIL D)

In a related ISO 26262 design example, we consider the design of an “electronic control unit” (ECU) for use in an automotive application.

When developing this ECU, we assumed:

  • that this design was being developed in compliance with ISO 26262;
  • that the design had been identified (following the processes defined in ISO 26262) as having at least one Functional Safety Requirement (FSR) – we call it “FSR x” – at Automotive Safety Integrity Level (ASIL) D, and that the task of meeting this functional safety requirement had been allocated to our ECU;
  • through a process of “ASIL decomposition” (as defined in ISO 26262) – we had decomposed FSRx into two new FSRs (FSRx1 and FSRx2), each of which was at ASIL B (D); and,
  • that the complete design would be implemented using TT software.




Working with a TT Wrapper

In the ECU design example, we assumed that the complete system would be created using a TT software architecture.

In many designs, 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.

Fortunately, this problem is not entirely new to developers of safety-critical embedded systems.

For example, IEC 62304 (‘Medical device software: Software life-cycle processes’) defines a software item that has already been developed, is generally available and that was not developed for the purpose of being incorporated into a medical device as ‘SOUP’ (Software Of Unknown Provenance).

Use of SOUP is common in safety-related medical systems. One reason for this is that some medical systems rely in part on the use of COTS operating systems (e.g. Linux® or Windows®), and it would not be practical to re-work this software completely. Instead, it is probably fair to summarise the approach in IEC 62304 as one of segregation and containment of SOUP components.

When developing IEC 62304 designs that incorporate SOUP, we can use a TT Wrapper (as we illustrate in a related design example).

In our experience, use of a ‘TT Wrapper’ and a suite of run-time tests can also provide a very effective way of improving confidence in the safety of automotive systems, even where these components incorporate ‘AI’ or ‘deep learning’ mechanisms.

As an example, one potential application of such a TT Wrapper in an autonomous road veicle is shown in the figure below.



In this design example, we give the TT Wrapper unit the ability to inject faults / tests (e.g. test images, image overlays) into the ARVC at run time. This is an effective solution because – while the ARVC may be highly adaptive – the TT Wrapper has fully deterministic behaviour: this ensures that we can be confident that the ARVC will either operate correctly – or be shut down by the TT Wrapper.



Further information

You may also like to read our short article on the use of TT Wrappers with ‘SOUP’.

Please contact us for further information about this example, or to discuss ways in which we may be able to help you to employ a TT Wrapper in your own designs.