AUTOSAR ( Automotive Open System ARchitecture ) is a development partnership of automotive manufacturers, control equipment manufacturers and vendors of development tools, ECU basic software and microcontrollers. Goal of AUTOSAR is to facilitate the exchange of software on different ECUs. For this purpose, a unified software architecture was developed with standard description and configuration formats for embedded automotive software. Can be AUTOSAR defines methods for describing software in the vehicle, to ensure that software components reused, exchanged, scaled and integrated.
One of the basic ideas of the AUTOSAR development partnership is cooperation on standards - Competition in the implementation (English cooperate on standards - compete on implementation ).
The following issues and objectives are addressed:
- Standardization of important system functions
- Standardization domain- border interfaces of the application software
- Meet future vehicle requirements for availability, security and software update
- Flexible integration, Moving and Replacing functions in the ECU network
- Support COTS software from different vendors
- Dominance of increased product and process complexity
- Cost-effective scalability
- Maintained throughout the entire product life cycle
After initial discussions the company BMW, Daimler, Bosch, Continental and Siemens VDO 2002 Volkswagen joined the partnership, which was officially adopted in 2003. Further, added later bumped partners are Ford, General Motors, Toyota and Peugeot. These companies represent the core partners who by Premium Members and Associate Members ( other 1st tier ) are supplemented. Following the acquisition of Siemens VDO by Continental AG in 2007, there are nine companies core partners of AUTOSAR: BMW, Bosch, Continental, Daimler, Ford, General Motors, PSA (Peugeot Citroën), Toyota, Volkswagen. In addition to the Core Partners are around 50 Premium Members of AUTOSAR represented (as of Dec. 2013). These include automobile manufacturers (eg, Fiat, Honda, Hyundai, Mazda, Renault, TATA, Volvo ), Control Equipment Manufacturers ( eg Delphi, Denso, Magneti Marelli, Valeo ), maker of development tools (eg dSPACE, Elektrobit, ETAS, The MathWorks, Vector computer science, MBtech ) and semiconductor manufacturers (eg, Freescale, Infineon, Renesas ).
The creation and adoption of standards takes place in various working groups. A jointly developed roadmap secures both the content and the time horizon.
Post Phase III
In addition to these major releases, there are a number of smaller further revision, which mainly includes bug fixes and minor corrections.
Essential for AUTOSAR is the logical division into the ECU-specific basic software ( Basic software, BSW) and the control device-independent application software (ASW ). In between there is a virtual function bus system (Virtual Functional Bus, VFB). This virtual functional bus connects all the software components, including those that are implemented in different ECUs. So they can be moved between different ECUs, without requiring changes in the software components in question must be made yourself. This can be useful for optimization of processing power, memory requirements, or communication load. The functional software components ( software component, SWC) are strictly separated from each other and from the base software. They communicate via the AUTOSAR interface with the other functions and the control device interfaces. These interfaces ( API) defined in SWC XML descriptions. The basic software ( Basic software, BSW ) contains the control unit-specific program components, such as the communication interfaces, diagnosis, and storage management.
The core of the architecture concept is the AUTOSAR runtime environment (Run - Time Environment, RTE), a communication layer that abstracts according to the principle of the Virtual Functional Bus (VFB ) in the sense of middleware from the real control device topology and the resulting communication relationships. Two functions can exchange with each other by using so-called communication ports of the runtime environment, therefore, without knowledge of the signal path information. This mechanism makes advantageous noticeable that functions can be developed independently of the existing later in the vehicle topology. The actual signal paths are defined late in the development process through a configuration mechanism.
In addition to the specification of the basic architecture with the RTE and the APIs of the base software, the specification of the method and the template is ( including the meta-model is to understand ) the second important part of AUTOSAR. This XML specifications are input for the RTE ( file extension. ARXML ). However, other non-directly executable code in question specifications such as documentation aspects are covered by the templates.
A third part of AUTOSAR, the specification of signals from the bodywork and comfort ( "Body and Comfort" ), drivetrain ("Power Train" ), chassis ( "Chassis" ), vehicle occupant and pedestrian protection ( " Occupant and Pedestrian Safety" ) as well as user interface, multimedia and telematics ( "HMI, Multimedia and Telematics " ) dar. These are provided as blueprints ( " blueprints ").