Search Results

The development of highly automated driving functions (AD) recently rises the demand for so called Fail-Operational systems for native driving functions like steering and braking of vehicles. Fail-Operational systems shall guarantee the availability of driving functions even in presence of failures. This can also mean a degradation of system performance or limiting a system’s remaining operating period. In either case, the goal is independency from a human driver as a permanently situation-aware safety fallback solution to provide a certain level of autonomy. In parallel, the connectivity of modern vehicles is increasing rapidly and especially in vehicles with highly automated functions, there is a high demand for connected functions, Infotainment (web conference, Internet, Shopping) and Entertainment (Streaming, Gaming) to entertain the passengers, who should no longer occupied with driving tasks.

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.

Driven by the growing internet and remote connectivity of automobiles, combined with the emerging trend to automated driving, the importance of security for automotive systems is massively increasing. Although cyber security is a common part of daily routines in the traditional IT domain, necessary security mechanisms are not yet widely applied in the vehicles. At first glance, this may not appear to be a problem as there are lots of solutions from other domains, which potentially could be re-used. But substantial differences compared to an automotive environment have to be taken into account, drastically reducing the possibilities for simple reuse. Our contribution is to address automotive electronics engineers who are confronted with security requirements. Therefore, it will firstly provide some basic knowledge about IT security and subsequently present a selection of automotive specific security use cases.

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.

The German funded project ARAMiS included work on several demonstrators one of which was a multicore approach on large scale software integration (LSSI) for the automotive domain. Here BMW and Audi intentionally implemented two different integration platforms to gain both experience and real life data on a Hypervisor based concept on one side as well as using only native AUTOSAR-based methods on the other side for later comparison. The idea was to obtain figures on the added overhead both for multicore as well as safety, based on practical work and close-to-production implementations. During implementation and evaluation on one hand there were a lot of valuable lessons learned about multicore in conjunction with safety. On the other hand valuable information was gathered to make it finally possible to set up a cost model for estimation of potential overhead generated by different integration approaches for safety related software functions.

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.

Multicore-based ECUs are increasingly used in embedded automotive software systems to allow more demanding automotive applications at moderate cost and energy consumption. Using a high number of parallel processors together with a high number of executed software components results in a practically unmanageable number of deployment alternatives to choose from. However correct deployment is one important step for reaching timing goals and acceptable latency, both also a must to reach safety goals of safety-relevant automotive applications. In this paper we focus at reducing the complexity of deployment decisions during the phases of allocation and scheduling. We tackle this complexity of deployment decisions by a mixed constructive and analytic approach.

ISO 26262 is the actual standard for Functional Safety of automotive E/E (Electric/Electronic) systems. One of the challenges in the application of the standard is the distribution of safety related activities among the participants in the supply chain. In this paper, the concept of a Safety Element out of Context (SEooC) development will be analyzed showing its current problematic aspects and difficulties in implementing such an approach in a concrete typical automotive development flow with different participants (e.g. from OEM, tier 1 to semiconductor supplier) in the supply chain. The discussed aspects focus on the functional safety requirements of generic hardware and software development across the supply chain where the final integration of the developed element is not known at design time and therefore an assumption based mechanism shall be used.

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.

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.