Safe autonomy and SOUP

empty_space
Many of our customers need to achieve compliance with IEC 61508, ISO 26262, DO-178 and related international safety standards and guidelines. We help them to meet these requirements through the use of state-of-the-art “Time-Triggered” (TT) software architectures.

Two of the design challenges that have been raised by our customers in recent months are:

  • producing autonomous systems that are both safe and secure, in compliance with ISO 26262 (or related standards); and,
  • handling ‘Software of Unknown Provenance’ (SOUP), in compliance with IEC 62304.

If you are facing one of these challenges, we may be able to help.

We say more about our solutions to these challenges on this page.


empty_space

Creating safe and secure autonomous systems in compliance with ISO 26262

empty_space

One of the key challenges that has been raised by our customers in recent months is the need to produce autonomous systems (such as ‘driverless’ cars) that are both safe and secure.

This is not a trivial challenge, not least because existing ‘autonomous system controllers’ (ASCs) tend to be highly-adaptive in nature. The adaptive characteristics of ASCs 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 ASC can change on a day-to-day basis, how can we tell that the system is doing something wrong? What benchmark can we use?

Fortunately, we have some key technology – we call it a (Duplex) WarranTTor® unit – that can help to ‘wrap’ up ASCs, resulting in an autonomous system that is much safer and more secure.

One potential application of such a WarranTTor unit is shown in the figure below.

empty_space

empty_space

In this design example, we give the WarranTTor 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 ARV is seen as having an ‘AI brain’, we are providing an ‘imagination circuit’ for this brain.

By adding the WarranTTor compoonent, we can have much greater confidence that the ARVC will guide the vehicle safely (even after it has ‘adapted’).

If – in due course – we create a TT implementation of the main ARV Controller this would provide further confidence (but we would still wish use the ‘imagination circuit’).

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 WarranTTor unit in your own designs.

empty_space


empty_space

Dealing with SOUP in an IEC 62304 design

empty_space

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).

The use of SOUP is considered extensively throughout this standard (and the approach is slightly different to that described for IEC 61508 and ISO 26262). 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.

For example (to summarise and paraphrase again) the user of SOUP in compliance with IEC 62304 must do the following:

  • specify the functional and performance requirements of SOUP item (Clause 5.3.3);
  • specify the hardware and software requirements of the SOUP item (Clause 5.3.4);
  • identify the level of segregation necessary for controlling risk (Clause 5.3.5); and,
  • verify the software architecture to ensure (for example) the correct operation of any SOUP items (Clause 5.3.6).

Use of a WarranTTor unit and a suite of run-time tests can provide a very effective way of dealing with SOUP in many systems (even complex systems).

Use of the WarranTTor unit in this way need not require large-scale code changes to the system (and is compatible – for example – with the use of Linux or other operating systems in the product).

Please contact us to discuss ways in which we may be able to help you to employ a WarranTTor unit to deal with SOUP in your designs.