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-06-11]
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 effective way of supporting “ASIL decomposition” (a key feature of many ISO 26262 designs).
Improving confidence in the safety of autonomous road vehicles
In our experience, use of a simple ‘TT Wrapper’ and a suite of run-time tests can provide a very effective way of dealing with complex (or incompletely-defined) systems, including AI-based systems.
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 potentially very powerful: if our COTS ARVC is seen as having an ‘AI brain’, we are providing an ‘imagination circuit’ (or ‘dream circuit’) for this brain.
To be clear. Use of a TT Wrapper in this way need not require large-scale code changes to the ARVC.
If – in due course – we create a TT implementation of the ARVC this would provide further confidence (but we would still wish use the ‘imagination circuit’).
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.