Automotive ECU (ISO 26262)
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 – in outline – several potential designs for a general-purpose automotive ‘Electronic Control Unit’ (ECU) on this page.
Such an ECU may serve as the main Vehicle Control Unit (in which case, it may need to meet ‘ASIL D’ requirements); alternatively, such an ECU may be required to operate as part of the Battery Management System (in which case it may need to meet ‘ASIL B’ requirements).
The solution presented here are all based on a ‘Time Triggered‘ (TT) software architecture.
[This page was last updated: 2021-01-22]
Developing an ‘ASIL B’ ECU (based on a single microcontroller)
We start by considering an ECU design that is capable of meeting ‘ASIL B’ requirements: this design is based on a single microcontroller.
The figure below gives an overview of the CorrelaTTor® software platform (we pronounce it ‘correlator’) that we would typically employ as the basis of such a design.
In a CorrelaTTor platform, a single processor is employed with internal monitoring (using MoniTTor® and PedicTTor® components).
Further information about the CorrelaTTor platform is provided on our Technology page.
The combination of an ‘ASIL B’ microcontroller and CorrelaTTor software can provide a highly-effective means of meeting the requirements of ISO 26262 (up to ‘ASIL B’). Such processors include the NXP® S32K devices (such as that shown in the figure below).
Developing an ‘ASIL D’ ECU (based on two low-cost microcontrollers)
Where required, we can extend the design outlined above in order to meet ‘ASIL D’ requirements by adding a second low-cost microcontroller and using a DuplicaTTor® (‘duplicator’) software platform.
The figure below gives an overview of a DuplicaTTor platform.
In a DuplicaTTor platform, two processors are employed (with cross-checks between them). For example, the combination of two ‘ASIL B’ microcontrollers and DuplicaTTor software can provide an effective means of meeting the requirements of ISO 26262: 2018 (up to ‘ASIL D’).
Two NXP S32K devices could (for example) be used as the basis of such a design.
Where multiple ECUs with different safety requirements are required in a vehicle, use of a combination of single-MCU and dual-MCU designs can help organisations to use a common code base throughout the system.
Further information about the DuplicaTTor platform is provided on our Technology page.
Developing an ‘ASIL D’ ECU (based on a single microcontroller)
We can also develop an ECU design that is capable of meeting ‘ASIL D’ requirements based on a single microcontroller.
Again, this will use a CorrelaTTor software platform.
In this case, we require a microcontroller that has been designed to meet ‘ASIL D’ requirements.
One possible example is the TC3xx family from Infineon®.
Such a design could (for example) be prototype on the cost-effective ShieldBuddy 375 board from Hitex®.
The TC3xx family of devices have multiple cores (all of which can be supported by the DuplicaTTor software platform) and can meet the performance requirements of a wide range range of automotive designs.
Does your design require ‘Fail Safe’ or ‘Fail Operational’ behaviour?
A key question that may arise during the early stages of developing an ECU design is whether the system is required to support ‘fail safe’ or ‘fail operational’ behaviour.
- A fail-safe design will shut down if a significant fault (that is, a fault that may prevent the system from continuing to operate safely) is detected during normal operation.
- A fail-operational design will continue to operate (possibly in a ‘limp home’ or similar mode) if a significant fault is detected.
In the designs outlined above, fail-safe behaviour is assumed, but DuplicaTTor platforms (in combination with appropriate MCU targets) also provide a highly-effective platform for a wide range of fail-operational designs, as outlined in the figure below.
