Using ‘TT Wrappers’ to achieve compliance with ISO 26262
During Q1 2018, we have seen particular demand for assistance in the development of components for use in ‘Advanced Driver Assistance Systems‘ (ADAS) and ‘Autonomous Vehicles‘ (AVs).
One effective way of developing such designs can be to use a ‘TT Wrapper’.
We say more about the use of TT Wrappers in ISO 26262 designs on this page.
[This page was last updated: 2018-02-02]
TT software architectures and ISO 26262
‘Time Triggered’ (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).
TT platforms such as CorrelaTTor® (illustrated below) provide a highly-effective way of implementing all of these solutions.
In a CorrelaTTor platform, a single processor is employed. For example, the combination of an ‘ASIL D’ microcontroller and CorrelaTTor software can provide an effective means of meeting the requirements of ISO 26262 (up to ‘ASIL D’).
We say more about CorrelaTTor platforms on our Technology page.
How to build a ‘TT Wrapper’
Use of a TT software architecture can offer many benefits, but it may not be possible for all parts of the system design.
This may be – for example – because it is necessary to incorporate some ‘unqualified’ software components in the design.
In other cases, a design based on an ASIC may incorporate a wide range of complex processors and other ‘hardware IP’, not all of which may be qualified at the required safety level.
In these circumstances, we may be able to use a ‘TT Wrapper’ to improve confidence in the safety of the whole system (or an individual component within the system).
In an automotive design, TT Wrappers are based on the use of what is usually called ‘ASIL decomposition’ (see ISO 26262).
Suppose (for example) that we have an automotive component that has an ‘ASIL D’ functional safety requirement (FSR).
We might decompose this FSR into a new requirement (at ‘QM(D)’ level) and a new FSR (at ‘ASIL D(D)’ level). The ‘QM(D)’ requirement will then be assigned to the ‘unqualified’ software / hardware components, and the ‘ASIL D(D)’ requirement will be assigned to the TT Wrapper.
To summarise: in such a design, all of the safety requirements will be shouldered by the TT Wrapper.
Software for a TT Wrapper is typically based on a CorrelaTTor-B platform: we illustrated such a platform in the ‘SIL 2’ example above.
The software will run on hardware that is qualified at the required ASIL level.
For example, a TT Wrapper that needs to meet ‘ASIL D(D)’ requirements will usually be implemented using an ‘ASIL D ready’ microcontroller or (in the case of an ASIC or FPGA solution) using hardware IP components – such as a ‘soft processor’ – that are ‘ASIL D ready’.
Example: Improving confidence in the safety of ADAS / AV designs using a TT Wrapper
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?
An effective solution to this challenge may be provided by adding a TT Wrapper around an existing ARVC, even where the ‘wrapped’ 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 perform continuous periodic tests on 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 more confident that the ARVC will either: [i] operate correctly; or [ii] be shut down by the TT Wrapper.
Please contact us for further information.