Search Results

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.

Today's automotive software integration is a static process. Hardware and software form a fixed package and thus hinder the integration of new electric and electronic features once the specification has been completed. Usually software components assigned to an ECU cannot be easily transferred to other devices after they have been deployed. The main reasons are high system configuration and integration complexity, although shifting functions from one to another ECU is a feature which is generally supported by AUTOSAR. The concept of a Virtual Functional Bus allows a strict separation between applications and infrastructure and avoids source code modifications. But still further tooling is needed to reconfigure the AUTOSAR Basic Software (BSW). Other challenges for AUTOSAR are mixed integrity, versioning and multi-core support. The upcoming BMW E/E-domain oriented architecture will require all these features to be scalable across all vehicle model ranges.

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.

Hardware-in-the-loop (HIL) simulation has become a key technique for the validation of today's automotive electronics. OEMs and suppliers are investing heavily in hardware-in-the-loop equipment and tests. Typically, suppliers test the electronic control unit (ECU) as a component. The OEM on the other hand tests the ECU more from a network point of view. This paper describes the main differences between component and network HIL tests. ZF Friedrichshafen AG has been using HIL test benches since 1985. In order to ensure high quality, especially with respect to network aspects, we not only test the ECUs as components but as part of the network. For that purpose, and to stay on the leading edge of HIL technology, ZF has set up a new test bench for networked HIL testing. The control network contains the driveline and chassis domain.

a practice-oriented approach for an accelerated product development and product design process for mechatronic systems is presented. The handling of complex and versatile product data to perform this process is shown in the area of electrical drives and actuators in cars. It is discussed, how the coordination of all the necessary disciplines as development, design, testing field, specification and release management should be software supported and PDM integrated. The advantages and benefits of the presented methods are shown on particular examples. The necessary software modules are introduced, showing that the realized solution gives both opportunities - the integration into a PDM backbone and at the same time an independent communication within department and/or company. The practical way, to realize the expert-specific needs of the development department, which is not possible with a general PDM system is pointed out.

This paper presents new comfort and convenience features in the luxury segment and focuses especially on Comfort Access and iDrive. The Comfort Access System offers the customer the possibility of unlocking the vehicle without active use of a key, of starting the engine and at the end of the journey of locking the car again. The aim of the iDrive concept was to enable intuitive operation of the various functions with simultaneously improved ergonomics. Both, a monitor and a controller with its variable haptic are the concept’s innovation. In addition, this paper also discusses future ECU (Electronic Control Unit) networks for body electronics. The focus is on package-driven ECU network architecture, having many functions developed by different suppliers on a single ECU.

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.

Handling characteristics, ride comfort and active safety are customer relevant attributes of modern premium vehicles. Electronic control units offer new possibilities to optimize vehicle performance with respect to these goals. The integration of multiple control systems, each with its own focus, leads to a high complexity. BMW and ITK Engineering have created a tool to tackle this challenge. A simulation environment to cover all development stages has been developed. Various levels of complexity are addressed by a scalable simulation model and functionality, which grows step-by-step with increasing requirements. The simulation environment ensures the coherence of the vehicle data and simulation method for development of the electronic systems. The article describes both the process of the electronic control unit (ECU) development and positive impact of an integrated tool on the entire vehicle development process.

The individual development process for distributed, communicating electronic control units hinders the integration of Automotive systems and increases the overall costs. In order to facilitate such applications, services and protocols for Communication, Network Management, and Operating System must be standardized. The aim of the OSEK project is to work out a respective specification proposal in cooperation with several car manufacturers and suppliers. This will permit a cost-effective system integration and support the portation of system functions between different electronic control units.

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.

This contribution deals with the fundamental trends in car electronics, driveline, and chassis technology. Electronically controlled active systems replace most of purely mechanic systems. In driveline systems, additional hybrid systems will find a place on the market. In Europe, the largest advantage gained will be the extension of functionalities in the fields of dynamics and car behavior. The advantages and the added value generated by functional driveline networking for the manufacturer and vehicle owner are explained by means of examples. A look into the future allows the depiction of comprehensive system integration with reference to driveline and chassis, e.g. refer ti information provided. Making this new networked based functionalities possible, requires a lot of new competencies e.g. in mechatronics, software, real-time control, model - based and software development processes, tools, test methods, and equipment.

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.

Increasing demand for dynamically controlled safety features, passenger comfort, and operational convenience in upper class automobiles requires an intensive use of electronic control units including software portions. Modeling, simulation, rapid prototyping, and verification of the software need new technologies to guarantee passenger security and to accelerate the time-to-market of new products. This paper presents the state-of-the-art of the design methods for the development of electronic control unit software at BMW. These design methods cover both discrete and continuous system parts, smoothly integrating the respective methods not merely on the code level, but on the documentation, simulation, and design level. In addition, we demonstrate two modeling and prototyping tools for discrete and continuous systems, namely Statemate and MatrixX, and discuss their advantages and drawbacks with respect to necessary prototyping demands.

This paper presents the challenges in automotive electronics. Considering the deficiencies of the current ECU (electronic control unit) design process, a new design process is outlined. This design process mainly focuses on the independence of the ECU hardware architecture development and the software function development.

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 permanently increasing number of convenience and safety functions leads to higher complexity of in-car electronics and the rapidly growing amount of sensors, actuators and electronic control units places higher demands on high- speed data communication protocols. Safety-critical systems need deterministic protocols with fault-tolerant behavior. The need for on-board diagnosis calls for flexible use of bandwidth and an ever-increasing number of functions necessitates a flexible means of extending the system. None of the communication solutions available on the market until now (like CAN or TTP) have been able to fulfill all these demands. To solve these problems, BMW together with several semiconductor companies has developed a new protocol for safety-critical applications in automotive vehicles.

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.