Search Results

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.

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.

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.

How can car manufacturers, which are primary mechanical engineers, become software specialists? This is a question of prime importance for car electronics in the future. Modern vehicles offer a large number of electronic and software based functions to achieve a high level of safety, fuel economy, comfort, entertainment and security which are developed under pressure of regulations, of consumers needs and of competitive time to market aspects. This contribution draws a picture, what could be important in future for in car communication and information system in terms of development process, HW & SW architectures, partnerships in automotive industry and security of industrial properties. For this purpose the automotive development is reviewed and actual examples of system designs are given.

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.

When investigating the posture comfort in vehicles two important influencing factors can be distinguished: In order to evaluate these influences a combined laboratory-field-experiment was carried out. A real car was equipped with cameras to record the body posture and the joint angles. The static forces exerted by the driver on his contact points were recorded in a corresponding mock-up. The forces to maintain the body posture were calculated. The following results were found:

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.

Nowadays, a continually growing system complexity due to the development of an increasing number of vehicle concepts in a steadily decreasing development time forces the engineering departments in the automotive industry to a deepened system understanding. The virtual design and validation of individual components from subsystems up to full vehicles becomes an even more significant role. As an answer to the challenge of reducing complete hardware prototypes, the virtual competence in NVH, among other methods, has been improved significantly in the last years. At first, the virtual design and validation of objectified phenomena in analogy to hardware tests via standardized test rigs, e.g. four poster test rig, have been conceived and validated with the so called MBS (Multi Body Systems).

The improvement of low-speed MUX-systems in car-body areas gets important in a scenario where on one hand, the possible number of integrated local control units (LCU's) gets larger and on the other hand, the possible versions of a car range from basic to top-of-the-line. Cost and developement time can be reduced if the same MUX-System is used throughout this whole range. A possibility to realize this is the use of data-compression (DC) for data-transmission. Basic configurations integrating only a small number of LCU's of a car-MUX can communicate without using data-compression, whereas for the top-of-the-line versions, the performance can be enhanced using DC only for communication processes between additional control units causing critical peak load situations. Specifically, the use of adaptive algorithms in automotive multiplex systems is a promising way to improve the MUX's capacity performance by minimizing redundant symbols/information in peak-load situations.

The potential to reduce the cost of embedded software by standardizing the application behavior for Automotive Body and Comfort domain functions is explored in this paper. AUTOSAR, with its layered architecture and a standard definition of the interfaces for Body and Comfort application functions, has simplified the exchangeability of software components. A further step is to standardize the application behavior, by developing standard specifications for common Body and Comfort functions. The corresponding software components can be freely exchanged between different OEM/Tier-1 users, even if developed independently by multiple suppliers. In practice, individual OEM users may need to maintain some distinction in the functionality. A method of categorizing the specifications as ‘common’ and ‘unique’, and to configure them for individual applications is proposed. This allows feature variability by means of relatively simple adapter functions.