Search Results

It is very common that a microcontroller is used in a safety relevant system to acquire data from sensors, process the data and then control actuators. With the shrink of technology every few years it becomes ever more common to use digital serial interfaces and high speed PWM links for both inputs and outputs. The microcontroller vendors have responded to the need for functional safety in the CPU cores by lock-stepping them and adding ECC to buses and memories. They are also implementing highly flexible and complex timer peripherals to be able to automate much of the real-time processing of the digital signals. However these timers are becoming significantly large, and many have their own embedded sequence engines or microkernels, which although powerful, often lack the rigorous diagnostic mechanisms required to reach ASILD.

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.

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 migration of many vehicle security features from mechanical solutions (lock and key) to electronic-based systems (transponder and RF transceiver) has led to the need for purely electrically operated locking mechanisms. One such example is a steering column lock, which locks and unlocks the steering wheel movement via a reversible electric motor. The safety case for this system (in respect to ISO26262) is highly complex, as there is no single safe state of the steering column lock hardware because there is a wider system-level interlock required. The employed control platform uses ASIL D capable multicore microcontroller hardware, together with the first implementation of AutoSAR® version 4.0 operating system to demonstrate a real-world usage of the newly specified encapsulation and monitoring mechanisms using the multicore extensions of AutoSAR and those of PharOS.

With the introduction of the ISO26262 automotive safety standard there is a burden of proof to show that the processing elements in embedded microcontroller hardware are capable of supporting a certain diagnostic coverage level, depending on the required Automotive Safety Integrity Level (ASIL). The current mechanisms used to provide actual metrics of the Built-in Self Tests (BIST) and Lock Step comparators use Register Transfer Level (RTL) simulations of the internal processing elements which force faults into individual nodes of the design and collect diagnostic coverage results. Although this mechanism is robust, it can only be performed by semiconductor suppliers and is costly. This paper describes a new solution whereby the microcontroller is synthesized into a large Field Programmable Gate Array (FPGA) with a test controller on the outside.

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

With the ever increasing amount of available software processing resources in a vehicle, more and more high-level algorithms are emerging to improve the existing systems in a car. Often these algorithms only need a platform with a bus connection and some resources such as processing power and memory space. These functions are predestined to be integrated into existing systems that have free resources. This paper will examine the role of time protection in these multi-algorithm systems and describe what timing protection means and why it is required. The processing time will be partitioned to the different processing levels like interrupts, services and tasks. The problems of timing protection will be illustrated as well as its limitations. The conflict between real-time requirements and timing protection will be shown. Finally Autosar will be examined with focus on timing protection and applicability in actual development projects.

With the increased adoption of AUTOSAR operating systems across the different automotive system domains a notable exception has been that of the safety critical systems. This domain has strict requirements on precise requirements capturing, proven design flow, robust implementation, exhaustive testing, detailed documentation and traceability, and project management processes. These requirements are normally prohibitive to adopt for commercial ‘one size fits all’ solutions due to the huge expense and resources required to meet such a strict regime. So under these constraints AUTOSAR is far from a perfect fit for safety systems. Nonetheless, the attractive features of reuse and portability still make AUTOSAR based systems highly desirable.

This paper will give an overview of multicore in automotive applications, covering the trends, benefits, challenges, and implementation scenarios. The automotive silicon industry has been building multicore and multiprocessor systems for a long time. The reasons for this choice have been: increased performance, safety redundancy, increased I/O & peripheral, access to multiple architectures (performance type e.g. DSP) and technologies. In the past, multiprocessors have been mainly considered as multi-die, multi-package with simple interconnection such as serial or parallel busses with possible shared memories. The new challenge is to implement a multicore, micro-processor that combines two or more independent processors into a single package, often a single integrated circuit (IC). The multicores allow a computing device to exhibit some form of thread-level parallelism (TLP).

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.

Developing automotive chassis applications is becoming increasingly complex due to cross-functional system interactions and the inherent safety critical nature of the systems involved. One consequence is the need for a rapid prototyping platform, targeted and tailored to meet the specific needs of the chassis domain. This paper describes an example of such an architecture for a chassis rapid prototyping system incorporating several Infineon TriCore embedded microcontrollers and Emulation Devices (ED), networked together by the Micro Link Interfaces (MLI). It also discusses how using such a development platform can lead to a significant reduction in the overall development time of a production intent chassis system.

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.

Prototyping of a complete powertrain controller is not generally permissible due to the large number of subsystems involved and the resources required in making the design a reality. The availability of a complete control system reference design at an early stage in the lifecycle can greatly enhance the quality of the system definition and allows early ideas to be prototyped in the application environment. This paper describes the implementation of such a reference design for a gasoline engine and gearbox management control system, integrated into robust housing which can be used for development in a prototype vehicle. The paper also outlines the powertrain subsystems involved, discusses how the system partitioning is achieved, shows the implementation of the partitioning into the physical hardware, and concludes with presenting the system benefits which can be realized.

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