Search Results

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.

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.

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 CPU time and memory space. These functions can easily be integrated into existing systems that have free resources. This paper describes some encapsulation techniques and mechanisms that can be used in the automotive domain. The discussion also takes into account the additional resources consumed on the microcontroller to meet these requirements and by the software to implement the encapsulation mechanisms. Overviews of some general concepts of software-architectures that provide encapsulation are also shown.

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.