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.

This paper presents four methodologies for modeling gear mesh excitations in simple and compound planetary gear sets. The gear mesh excitations use simplified representations of the gear mesh contact phenomenon so that they can be implemented in a numerically efficient manner. This allows the gear mesh excitations to be included in transmission system-level, multibody dynamic models for the assessment of operating noise and vibration levels. After presenting the four approaches, a description is made regarding how they have been implemented in software. Finally, example models are used to do a comparison between the methods

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.

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

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.

This paper presents an object-oriented method customized for a tool-assisted development of car software components. Tough market conditions motivate smart software development. ASCET SD is a tool to generate target code from graphic specifications, avoiding costly programming in C. But ASCET lacks guidelines on what to do, how to do it, in what order, like a fully equipped kitchen without a cooking book. Plans to employ the tool for BMW vehicle software sparked off demand for an adequate, object-oriented real-time methodology. We show how to scan the methodology market in order to adopt an already existing method for this purpose. The result of the adaptation of a chosen method to ASCET SD is a pragmatic version of ROOM, which we call BROOM. We present a modeling guidebook that includes process recommendations not only for the automotive sector, but for real-time software development in general.

Increasing demand for utilities like navigation systems or user-defined electronic phonebooks on one hand and sophisticated engine and gear controls on the other hand leads to growing bus load between distributed local control units. This paper shows the benefits and the characteristics of various state of the art data-compression algorithms and their impact on typical automotive multiplex dataclasses. The evaluation and optimization of promising algorithms can be done via a proposed “communications prototyping”-approach. The hardware/software components of such a rapid prototyping package are outlined. Finally, first performance results of suitable data-compression measures are presented.

More electronic vehicle functions lead to an exponentially growing degree of software integration in automotive ECUs. We are seeing an increasing number of ECUs with mixed criticality software. ISO26262 describes different safety requirements, including freedom from interference and absence from error propagation for the software. These requirements mandate particular attention for mixed-criticality ECUs. In this paper we investigate the ability to guarantee that these safety requirements will be fulfilled by using established (deadline monitoring) and new error detection mechanisms (execution time monitoring). We also show how these methods can be used to build up safe and efficient schedules for today's and future automotive embedded real time systems with mixed criticality software.

This paper describes the first results from the AutoMoDe project (Automotive Model-based Development), where an integrated methodology for model-based development of automotive control software is being developed. The results presented include a number of problem-oriented graphical notations, based on a formally defined operational model, which are associated with system views for various degrees of abstraction. It is shown how the approach can be used for partitioning comprehensive system designs for subsequent implementation-related tasks. Recent experiences from a case study of an engine management system, specific issues related to reengineering, and the current status of CASE-tool support are also presented.

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.

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.

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.

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.

With the increasing complexity of electronic vehicle systems, one particular “gap” between function development and ECU integration becomes more and more apparent, and critical; albeit not new. The core of the problem is: as more functions are integrated and share the same E/E resources, they increasingly mutually influence and disturb each other in terms of memory, peripherals, and also timing and performance. This has two consequences: The amount of timing-related errors increases (because of the disturbance) and it becomes more difficult to find root causes of timing errors (because of the mutual influences). This calls for more systematic methods to deal with timing requirements in general and their transformation from function timing requirements to software architecture timing requirements in particular.

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.

Future applications in the automotive domain such as distributed control functions need a highly dependable communication system. The current FlexRay standard already provides high transmission speeds and addresses deterministic data communication. This paper shows how to enhance the safety properties for handling a new set of applications and speeding up the communication even more. The concept of Layered FlexRay is based on the FlexRay protocol and addresses the requirements of safety-relevant applications in a distributed communication network. An implementation of this approach is depicted with a Safety Core hardware chip. It is designed to handle the communication between the FlexRay system beneath and the application on the host CPU above, providing highly efficient data management and execution of safety functions which otherwise would have to be executed in software on the host CPU.

The term X-by-Wire is commonly used in the automotive industry to describe the notion of replacing current mechanical or hydraulic chassis and powertrain systems with pure electro-mechanical systems. The paper describes the current trends and the architecture of future chassis electronics systems. The first part of the paper covers the systems architecture of x-by-wire electronics systems. We describe the network and the software architecture in more detail. The paper also explains some of the software components, in particular the operating system and the communication layer. The second part of the paper gives a description of the current state of the development process for software intended for safety-relevant systems. A possible tool chain for this development process, current possibilities as well as limitations and challenges are described.

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.