Search Results

The current automotive electronic and electrical (EE) architecture has reached a scalability limit and in order to adapt to the new and upcoming requirements, novel automotive EE architectures are currently being investigated to support: a) an Ethernet backbone, b) consolidation of hardware capabilities leading to a centralized architecture from an existing distributed architecture, c) optimization of wiring to reduce cost, and d) adaptation of service-oriented software architectures. These requirements lead to the development of Zonal EE architectures as a possible solution that require appropriate adaptation of used security mechanisms and the corresponding utilized hardware trust anchors. 1 The current architecture approaches (ECU internal and in-vehicle networking) are being pushed to their limits, simultaneously, the current embedded security solutions also seem to reveal their limitations due to an increase in connectivity.

Advanced safety features and new services in connected cars depend on the security of the underlying vehicle functions. Due to the interconnection with the outside world and as a result of being an embedded system a modern vehicle is exposed to both, malicious activities as faced by traditional IT world systems as well as physical attacks. This introduces the need for utilizing hardware-assisted security measures to prevent both kinds of attacks. In this paper we present a survey of the different classes of hardware security devices and depict their different functional range and application. We demonstrate the feasibility of our approach by conducting a case study on an exemplary implementation of a function-on-demand use case. In particular, our example outlines how to apply the different hardware security approaches in practice to address real-world security topics. We conclude with an assessment of today’s hardware security devices.

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.

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.

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 infrastructure in modern cars is a heterogeneous and historically grown network of different field buses coupling different electronic control units (ECUs) from different sources. In the past years, the amount of ECUs in the network has rapidly grown due to the mushrooming of new functions which historically were mostly implemented on a one-ECU-per-function basis resulting in up to a hundred ECUs in fully equipped luxury cars. Additionally, new functions like parking assist systems or advanced chassis control functions are getting increasingly complex and require more computing power. These two facts add up to a complex challenge in development. The current trend to host several functions in single ECUs as integration platforms is one attempt to address this challenge. This trend is supported by the increased computing power of current and upcoming multi-core microcontrollers.

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.

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

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.