Automotive ECU (ISO 26262, ASIL B)


We receive many enquiries from organisations that need to develop products in compliance with international safety standard ISO 26262.

As an example of the type of design solution that we use in such products, we explore the development of an automotive ECU (at ‘ASIL B’) on this page.

Our solution is based on a ‘Time Triggered‘ (TT) software architecture running on a single (low cost) microcontroller, and employs what is often called ‘ASIL decomposition’.

[This page was last updated: 2018-08-24]
empty_space


empty_space

Supporting ‘ASIL Decomposition’ (ISO 26262, ASIL B)

empty_space
The decomposition of ‘functional safety requirements’ (FSRs) is a process that is often employed in designs that are developed in compliance with international safety standards such as ISO 26262 and IEC 61508. The process is usually referred to as ‘ASIL decomposition’ or ‘SIL decomposition’.

As an illustration, the figure below summarises the end result of decomposing a single FSR (at ‘ASIL B’) into two equivalent FSRs (in this case at ‘ASIL A’).

empty_space

empty_space

Decomposition of FSRs is often employed because:

  • confidence in the safety of the associated system can be increased through this process;
  • the cost of meeting the two decomposed FSRs can be significantly lower than that of meeting the original FSR (‘ASIL B’).

To justify such a decomposition, the two new FSRs must be implemented independently (and it must be possible for the development team to demonstrate – clearly and unambiguously – that the two implementations are independent).

One way of providing an independent implementation is to begin by allocating the two new FSRs to different MCUs: our DuplicaTTor Evaluation Board is often used to prototype such designs.

An alternative way of supporting the decomposition of FSRs is to provide a means of executing two sets of tasks by means of the same MCU: we can do this if we are able to ensure that the two implementations will be able to operate independently: what we call a ‘DecomposiTTor Platform’ provides an effective means of achieving this goal.

empty_space

empty_space

A DecomposiTTor Platform is made up of a single MCU, a single scheduler and two independent sets of tasks. To create the two independent task sets, we – can – for example – design one set of tasks, and then – using the techniques discussed in Chapter 6 of ‘ERES2‘ – create a set of matching ‘Diverse Tasks’.

To be clear. We do not attempt to claim that we can prevent all interference between tasks that execute on the same MCU. However, by building on the techniques presented in Part Two and Part Four of the ‘ERES2‘ book, we can be confident that we will be able to detect any interference between such tasks: this is what we require to support successful ASIL / SIL decomposition on single MCU.


empty_space

Complete code example (TTRD2-25a)

empty_space
We’ve created a simple code framework to illustrate the process of ASIL decomposition on a single MCU.

This framework is assumed to the core software in a low-cost ECU for a passenger car: the design is assumed to be developed in compliance with ISO 26262.

The ‘Electronic Control Unit’ is based on a ‘Time Triggered‘ (TT) software architecture.

In this design, we will make the follow assumptions:

  • that this product is being developed in compliance with ISO 26262;
  • that the product 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) B, and that the task of meeting this functional safety requirement has been allocated to our ECU; and,
  • 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 A (B).

Our prototype code for this example targets an NXP® S32K144 processor (and the S32K144 Evaluation Board).

The example code includes the following components:

  • a TTC (Task) scheduler [‘ASIL B’ in the production code];
  • two sensor-processing tasks [‘ASIL A’ in the production code];
  • a sensor-fusion task [‘ASIL B’ in the production code];

In the production code, the sensor-processing tasks – which are the core ‘decomposed’ compoents in this simplified example – would be implemented as ‘Diverse Tasks’: see ‘ERES2‘, Chapter 6.

In the example, the ‘sensor-processing’ involves reading two inputs (SW2 and SW7 on the S32K144 EVB). One task uses a conventional switch and the other uses a capacitive touch sensor (to illustrate the requirements for design and implementation diversity).

The ‘sensor fusion’ task then performs some sanity checks on the outputs from the two sensor tasks and – if it is happy – it changes the state of an LED.

Overall – while the example is very simple – the software architecture is appropriate for use in an ‘ASIL B’ design.

The complete code example is available on our TTRD page (look for TTRD2-25a).

empty_space

empty_space

empty_space


empty_space

Other applications of design partitioning

empty_space

Use of a TT platform with ReliabiliTTy technology provides an effective means of allowing multiple functions to operate independently and safely on a single- or multi-processor TT design.

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.

empty_space


empty_space

Complete your cost-effective ISO 26262 design successfully using a SafeTTy Solutions™ package

empty_space
The design example presented on this page is based on a SafeTTy Solutions™ Package (SSP-RTL2).

SafeTTy Solutions Packages are designed to help your development team produce a safety-related embedded system quickly and cost-effectively, in compliance with one or more international safety standards (such as ISO 26262).

SafeTTy Solutions Packages are based on TT designs and include carefully-selected combinations of our various products and services.

SafeTTy Solutions Packages include an appropriate ReliabiliTTy® Technology Licence.

Learn more about SafeTTy Solutions Packages …

empty_space


empty_space