Search Results

Future HD Diesel engine technology is facing a combination of both extremely low exhaust emission standards (US 2002/2004, EURO IV and later US 2007, EURO V) and new engine test procedures such as the European Transient Cycle (ETC) in Europe and the Not-to-Exceed Area (NTE) in the US). Customers furthermore require increased engine performance, improved efficiency, and long-term durability. In order to achieve all targets simultaneously, future HD Diesel engines must have improved fuel injection and combustion systems and utilize suitable technologies such as exhaust gas recirculation (EGR), variable geometry turbine turbocharger systems (VGT) and exhaust gas after-treatment systems. Future systems require precision controlled EGR in combination with a VGT-turbocharger during transient operation. This will require new strategies and calibration for the Electronic Engine Control Unit (ECU).

The trend towards even more sophisticated driver assistance systems and growing automation of driving sets new requirements for the robustness and availability of the involved automotive systems. In case of an error, today it is still sufficient that safety related systems just fail safe or silent to prevent safety related influence of the driving stability resulting in a functional deactivation. But the reliance on passive mechanical fallbacks in which the human driver taking over control, being inevitable in such a scenario, is expected to get more and more insufficient along with a rising degree of driving automation as the driver will be given longer reaction time. The advantage of highly or even fully automated driving is that the driver can focus on other tasks than controlling the car and monitoring it’s behavior and environment.

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.

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.

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.

The modern engine development process is characterized by shorter development cycles and a reduced number of prototypes. However, simultaneously exhaust after-treatment and emission testing is becoming increasingly more sophisticated. It is expected that predictive simulation tools that encompass the entire powertrain can potentially improve the efficiency of the calibration process. The testing of an ECU using a HiL system requires a real-time model. Additionally, if the initial parameters of the ECU are to be defined and tested, the model has to be more accurate than is typical for ECU functional testing. It is possible to enhance the generalization capability of the simulation, with neuronal network sub-models embedded into the architecture of a physical model, while still maintaining real-time execution. This paper emphasizes the experimental investigation and physical modeling of the port fuel injected SI engine.

A main challenge when developing next generation architectures for automated driving ECUs is to guarantee reliable functionality. Today’s fail safe systems will not be able to handle electronic failures due to the missing “mechanical” fallback or the intervening driver. This means, fail operational based on redundancy is an essential part for improving the functional safety, especially in safety-related braking and steering systems. The 2-out-of-2 Diagnostic Fail Safe (2oo2DFS) system is a promising approach to realize redundancy with manageable costs. In this contribution, we evaluate the reliability of this concept for a symmetric and an asymmetric Electronic Power Steering (EPS) ECU. For this, we use a Markov chain model as a typical method for analyzing the reliability and Mean Time To Failure (MTTF) in majority redundancy approaches. As a basis, the failure rates of the used components and the microcontroller are considered.

In the context of the ARAMiS project, AUDI AG contributed the development of a multi-core demonstrator based on car functions already in production. For this demonstrator, these legacy car functions were ported from single-core platforms to a multi-core platform to gain real world close-to-production experience while utilizing the new technology. For complex functions with high demands for computational resources, it may be necessary to distribute computation over several cores. In this context, we investigated the parallelization of a legacy sequential AUTOSAR function. A main contribution of this work is an analysis of mechanisms provided by AUTOSAR, their limitations and, possible remedy. This paper will point out observations and experiences during the development of this demonstrator and show practical solutions for parallelization in an AUTOSAR environment.

The increasing complexity of automotive functions which are necessary for improved driving assistance systems and automated driving require a change of common vehicle architectures. This includes new concepts for E/E architectures such as a domain-oriented vehicle network based on powerful Domain Control Units (DCUs). These highly integrated controllers consolidate several applications on different safety levels on the same ECU. Hence, the functions depend on a strictly separated and isolated implementation to guarantee a correct behavior. This requires middleware layers which guarantee task isolation and Quality of Service (QoS) communication have to provide several new features, depending on the domain the corresponding control unit is used for. In a first step we identify requirements for a middleware in automotive DCUs. Our goal is to reuse legacy AUTOSAR based code in a multicore domain controller.