AutoSAR Overview FESA Workshop at KTH 2010 04 12 Prof. Jakob Axelsson Volvo Cars and Mälardalen University This presentation is based on a tutorial prepared by the AutoSAR Consortium
AUTOSAR Members Status June 2007 10 Core Partners 49 Premium Members 57 Associate Members 2
Exchangeability and Reuse of s OEM b OEM a Platform b.1 Platform b.2 Platform b.n Exchangeability between supplier s s solutions OEM c Platform a.1 Platform a.2 Platform a.n Exchangeability between manufacturer s applications OEM f OEM e Supplier A Chassis Safety Body/Comfort Multimedia Supplier B Chassis Safety Telematics Multimedia Supplier C Body/Comfort Powertrain Telematicsl Multimedia Platform c.1 Platform c.2 Platform c.n OEM d Platform d.1 Platform d.2 Platform d.n Platform f.1 Platform f.2 Platform f.n Platform e.1 Platform e.2 Platform e.n Exchangeability between vehicle platforms 3
Changing Automotive SW Development Conventional Software Hardware AUTOSAR Application Software AUTOSAR Hardware standardized HW specific Hardware and software will be widely independent of each other. Development processes will be simplified. This reduces development time and costs. Reuse of software increases at OEM as well as at suppliers. This enhances also quality and efficiency. Automotive Software will become a product.
AUTOSAR Main Working Topics Architecture Application Interfaces Methodology Architecture Application Interfaces Methodology Architecture: Software architecture including a complete basic or environmental software stack for ECUs the so called AUTOSAR Basic Software as an integration platform for hardware independent software applications. Methodology: Exchange formats or description templates to enable a seamless configuration process of the basic software stack and the integration i of application i software in ECUs and it includes even the methodology how to use this framework. Architecture Application Interfaces Methodology Application Interfaces: Specification of interfaces of typical automotive applications from all domains in terms of syntax and semantics, which should serve as a standard for application software. 5
Intra and Inter ECU Communication Ports implement the interface according to the communication paradigm (here clientserver based). Ports are the interaction points of a component. The communication is channeled via the RTE. The communication layer in the basic software is encapsulated and not visible at the application layer. ECU I Application A RTE BSW VFB Application B ECU II RTE BSW Application C Application Ports AUTOSAR Infrastructure Sensor Hardware Communication Bus Communication Path 6
AUTOSAR Methodology VFB view AUTOSAR 1 AUTOSAR 2 AUTOSAR 3... AUTOSAR n Standardized di d description templates t for application software components (interfaces and BSW requirements) ECU s Virtual Functional Bus System Constraint Standardized exchange formats and methodology for component, ECU, and system level Tool supporting deployment of SW components Mapping AU TOSAR 1 ECU I RTE Basic Software AU TOSAR 3 ECU II AU TOSAR 2 RTE Basic Software... ECU m AUT TOSAR n RTE Basic Software Tools for support of component mapping generation of RTE, i.e. inter and intra ECU communication Standardized Basic Software (BSW) architecture, detailed specifications for implementation and configuration of BSW Gateway 7
AutoSAR s ECUs Software Components SwitchEval ECU Resource ECU Resource ECU Resource omponent BlinkInputModule omponent SwitchEval Supported protocols: CAN, LIN, FlexRay BC V SMLS BC H System BlinkMaster omponent LightActuatorsControl BlinkInputModule BlinkMaster LightActuatorsControl CAN omponent LightSourceSetting LIN LightSourceSetting LM L LM R omponent 8
AUTOSAR System Design Process Input: Requirements & Vehicle Info 1a 1c 1b 2 3 System Configure System & generate extracts of ECU descriptions Configure each ECU ECU Resource Iterative corrections and/or optimizations (if required) 4 Generate SW executables tbl SW executables 9
AUTOSAR System Design Process Input: Requirements & Vehicle Info 1a 1c 1b General characteristics (name, manufacturer, etc.) Communication properties: p_ports r_ports interfaces inner structure (composition) sub components connections required HW resources: processing time scheduling memory (size, type, etc.) 2 3 4 System Configure System & generate extracts of ECU descriptions Configure each ECU Generate SW executables SW executables ECU Resource Iterative corrections and(/or optimizations (if required) 10
AUTOSAR System Design Process Input: Requirements & Vehicle Info 1a 1c 1b 2 3 System ECU Resource Configure System & generate extracts of ECU descriptions Iterative corrections ECU Resource and(/or optimizations General characteristics (name, manufacturer, etc.) (if required) Temperature (own, environment, cooling/heating) Configure Available signal processing methods each ECU Available programming capabilities Available HW: µc, architecture (e.g. multiprocessor) 4 memory Generate SW interfaces (CAN, LIN, MOST, FlexRay) executables periphery (sensor / actuator) connectors (i.e. number of pins) SW below RTE for micro controller Signal path from Pin to ECU abstraction SW executables 11
AUTOSAR System Design Process Input: Requirements & Vehicle Info 1a 1c 1b 2 System Configure System & System generate extracts of ECU descriptions Network topology bus systems: CAN, LIN, FlexRay 3 connected ECUs, Gateways power Configure supply, system activation Communication (for each each ECU channel) K matrix gateway table 4 Mapping / Clustering Generate of SW SW components executables ECU Resource Iterative corrections and(/or optimizations (if required) SW executables 12
AUTOSAR Metamodel The metamodel is modeled in UML The structure of the information can be clearly visualized The consistency of the information is guaranteed Using XML, a data exchange format can be generated automaticallyout out of the metamodel METAMODEL Datatype SW Component Interface MODEL Mirror Mirror Adjustment Actuator 13
Application Interfaces to Ease Reuse 2nd Yaw I 6 Rate Controller Base Sensor Signals Ínterface of ESP and external yaw rate controller System-level Brake Actuator Interface I 7 ESP-Sensors I 1 ESP Interface of ESP and VLC I 4 SW-Component I 2 I 3 I 5 Brake Actuator Vehicle Longitudinal Controller Standard Signals from ESP Information signals from other functions / domains Command signals to other functions / domains Standardized application interfaces on system level (ESP system, chassis domain) Data Type Name Data Type Name Data Type LongAccBase YawRateBase Yaw rate measured along vehicle z- axis (i.e. compensated for orientation). Coordinate system according to ISO 8855 S16 Integer Range -32768..+32767 Physical Range -2,8595..+2,8594 Physical Offset 0 Unit Remarks Data Type Name rad/sec. This data element can also be used to instantiate a redundant sensor interface. Range might have to be extended for future applications (passive safety). RollRateBase 14