Search Results

The recent adoption of the ISO26262 Functional Safety Standard has lead to the need for a greater degree of rigor in the technical, organizational and process aspects of electronic ECU engineering. One new facet of this standard also covers (in part 9.7) the analysis of dependent failures at manufacturing time, not only the microcontroller, but also for the plethora of connected system ASICs, input circuits, output drivers and communication devices in the PCB of the ECU. This paper will describe the CAN based end of line ECU self test system that was implemented at a major tier 1 supplier to address the issues of efficiently gaining a high degree of diagnostic coverage of single point faults and latent faults in highly integrated automotive ECUs.

With the advent of AUTOSAR version 4 and the availability of automotive specific multicore microcontrollers in volume production it is now possible to make very large scale integrations of different vehicle functions in a single ECU, running on a single high performance microcontroller. These microcontrollers typically provide all the hardware diagnostic mechanisms to achieve functional safety up to ISO 26262 ASILD, however careful consideration must be made in regard to the overall availability when undertaking large scale integrations in a single MCU. The motivation is clear. Up integration reduces costs, energy usage, wire harness complexity, and system bus traffic. However, when a multicore microcontroller is running different software for different applications on each of the available cores, if a fault is detected in one core the side effects and fault reactions must be contained, to prevent the fault propagating to other cores and applications.

Electronic Control Units of safety critical systems require constant monitoring of the hardware to be able to bring the system to a safe state if any hardware defects or malfunctions are detected. This monitoring includes memory checking, peripheral checking as well as checking the main processor core. However, checking the processor core is difficult because it cannot be guaranteed that the error will be properly detected if the monitor function is running on a processing system which is malfunctioning. To circumvent this issue, several previously presented monitoring concepts (e.g. SAE#2006-01-0840) employ a second external microprocessor to communicate with the main processor to check its integrity. The addition of a second microcontroller and the associated support circuitry that is required adds to the overall costs of the ECU, increases the size and creates significant system complexity.

Electronic Control Units of safety critical systems require constant monitoring of the hardware to be able to bring the system to a safe state if any hardware defects or malfunctions are detected. This monitoring includes memory checking, peripheral checking as well as checking the main processor core. However, checking the processor core is difficult because it cannot be guaranteed that the error will be properly detected if the monitor function is running on a processing system which is malfunctioning. To circumvent this issue, several previously presented monitoring concepts (e.g. SAE#2006-01-0840) employ a second external microprocessor to communicate with the main processor to check its integrity. This paper will present a concept which maps the functions of the external monitoring unit into an internal second processing core which are frequently available on modern, 32bit, monolithic, dual-core microcontrollers.