Search Results

Reductions of hardware costs as well as implementations of new innovative functions are the main drivers of today's automotive electronics. Indeed more and more resources are spent on adapting existing solutions to different environments. At the same time, due to the increasing number of networked components, a level of complexity has been reached which is difficult to handle using traditional development processes. The automotive industry addresses this problem through a paradigm shift from a hardware-, component-driven to a requirement- and function-driven development process, and a stringent standardization of infrastructure elements. One central standardization initiative is the AUTomotive Open System ARchitecture (AUTOSAR). AUTOSAR was founded in 2003 by major OEMs and Tier1 suppliers and now includes a large number of automotive, electronics, semiconductor, hard- and software companies.

The paper presents a comparison between the acceleration pulses of vehicle-to-vehicle crash tests with those of different single-vehicle crash tests. The severity of the full frontal rigid barrier test is compared with that of the vehicle- to-vehicle crash test based on average acceleration and time-to-zero-velocity. Based on this a 30mph full frontal rigid barrier test is found equivalent to a 41mph vehicle-to-vehicle crash. A reduced speed of 22mph for full frontal rigid barrier test is found to represent vehicle-to- vehicle crashes with 50%-100% overlap, with each vehicle travelling at 30mph. The paper also presents a comparison of the acceleration pulses from different crash tests based on the pulse shape and the pulse phase cross-correlation. None of the single-vehicle crash tests have been found to resemble vehicle-to-vehicle crashes in terms of the pulse shape and the pulse phase.

Electronic Control Units (ECUs) are typically programmed using external programming devices - frequently called Diagnostic Testers. We propose a system and software architecture that requires no Diagnostic Tester for ECU (re)programming. ECU (re)programming is instead managed by an on-board software component, the Flashware-Reprogramming-Controller. It can reside in any ECU that has sufficient memory and processing power as well as good connectivity to internal networks and external sources from which to receive the software to be installed. Appropriate choices could be modern telematic devices. A second co-located on-board software component - the Installation-Configuration-Controller - is used to supervise the installation of new software releases and to validate their integrity after installation. The proposed architecture can be used for software download into ECUs in development, end-of-line production and after sales.

Barrier impacts are routinely used to estimate the impact response of vehicles in vehicle-to-vehicle crashes. One area of investigation is the detection of the secondary energy absorbing structures provided for under-/over-ride mitigation as a result of increased structural engagement -- improved geometric compatibility. The flat rigid barrier and the Transportation Research Laboratory’s (TRL) full width honeycomb barrier are commonly considered. In the present study, a vehicle-to-vehicle impact that exhibited no under-/over-ride condition was compared to finite element analysis of vehicle impacts to the two different barriers in order to evaluate their ability to detect the secondary energy absorbing structure. This study demonstrates that the rigid barrier and the TRL barrier yield similar quantitative information with regard to vehicle-to-vehicle crashes.

The new generation of drive-by-wire systems currently under development has demanding requirements on the electronic architecture. Functions such as brake-by-wire or steer-by-wire require continued operation even in the presence of component failures. The electronic architecture must therefore provide fault-tolerance and real-time response. This in turn requires the operating system and the communication layer to be predictable, dependable and composable. It is well known that this properties are best supported by a time-triggered approach. A consortium consisting of German and French car manufacturers and suppliers, which aims at becoming a working group within the OSEK/VDX initiative, the OSEKtime consortium, is currently defining a specification for a time-triggered operating system and a fault-tolerant communication layer.1 The operating system and the communication layer are based on applicable interfaces of the OSEK/VDX standard.

Most driver information systems offered in automobiles today display vehicle speed, fluid levels, fluid temperatures, and some basic diagnostic information (warnings, panel lamps). Optional driver information systems add to this list by offering fuel economy information, compass heading, outside temperature and other comfort and convenience related items. Very few provide information in regards to the real performance of the vehicle, its motion in 3-dimensional space, or the driver’s skill and performance. Making this information available to the driver can enhance the “fun-to-drive” aspects of driving.