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.

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.

It is the beginning of a new age: multicore technology from the PC desktop market is now also hitting the automotive domain after several years of maturation. New microcontrollers with two or more main processing cores have been announced to provide the next step change in available computing power while keeping costs and power consumption at a reasonable level. These new multicore devices should not be confused with the specialized safety microcontrollers using two redundant cores to detect possible hardware failures which are already available. Nor should they be confused with the heterogeneous multicore solutions employing an additional support core to offload a single main processing core from real-time tasks (e.g. handling peripherals).

The increased pressure for power, space, and cost reduction in automotive applications together with the availability of high performance, automotive qualified multicore microcontrollers has lead to the ability to engineer Domain Controller ECUs that can host several separate applications in parallel. The standard automotive constraints however still apply, such as use of AUTOSAR operating system, support for legacy code, hosting OEM supplied code and the ability to determine warranty issues and responsibilities between a group of Tier 1 and Tier 2 vendors who all provide Intellectual Property to the final production ECU. Requirements for safety relevant applications add even more complexity, which in most current approaches demand a reconfiguration of all basic software layers and a major effort to redesign parts of the application code to enable co-existence on the same hardware platform. This paper outlines the conflicting requirements of hosting multiple applications.

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.

The number of safety critical automotive applications employing high current brushless motors continues to increase (Steering, Braking, and Transmission etc.). There are many benefits when moving from traditional solutions to electrically actuated solutions. Some of these benefits can include increased fuel economy, simplified vehicle installation and packaging, increased feature set, improved safety and/or convenience, simplified unit assembly and modular testability prior as well as during vehicle manufacturing. The trend to implement brushless motors in these applications (which require electronically controlled commutation) has also brought with it the need for powerful inverters, which primarily consist of Power MOSFETs and MOSFET Driver ICs. This paper reviews the challenges associated with the design of safety critical electronic systems which combine sensing, control and actuation.

Machine learning systems are gaining acceptance in the fields of inferential sensing, mechatronic control and prognostics. However, software implementations can place excessive demands on the ECU, and so real-time classification rates are not always possible. This paper describes the integration of a hardware implementation of a machine learning algorithm into a comprehensive hardware and software prototyping environment for powertrain applications. The paper describes the hardware and software architectures developed, provides an overview of the new methodologies necessary to access the power of the machine learning system, and illustrates its application in the powertrain control field