AutoSAR OverviewFESA Workshop at KTH 2010‐04‐12
Prof. Jakob AxelssonVolvo Cars and
Mälardalen University
This presentation is based on a tutorial prepared by the AutoSAR ConsortiumAutoSAR Consortium
AUTOSAR – Members Status June 2007
10 Core Partners10 Core Partners
57 Associate Members49 Premium Members
2
Exchangeability and Reuse of SW Components
Exchangeabilitybetween supplier‘s
OEM b
between supplier ssolutionsOEM a
Platform b.nPlatform b.2Platform b.1 OEM c
Supplier B
Chassis
Safety
Telematics
Supplier A
Chassis
Safety
Body/ComfortExchangeabilityPlatform c.nPlatform c.2Platform c.1Platform a.n
Platform a.2Platform a.1
OEM f
MultimediaBody/Comfort
Multimedia
Supplier C
Body/Comfort
Powertrain
T l ti
Exchangeabilitybetween
manufacturer‘sapplications
OEM d
OEM f Telematics
Multimedia
Platform d.nPlatform d.2Platform d.1
OEM e
3
Exchangeabilitybetween vehicle
platformsPlatform e.nPlatform e.2Platform e.1
Platform f.nPlatform f.2Platform f.1
Changing Automotive SW DevelopmentChanging Automotive SW Development
Conventional AUTOSAR
SoftwareApplication Software
AUTOSAR
standardized
HardwareHardware
AUTOSARHW‐specific
• Hardware and software will be widely independent of each other.• Development processes will be simplified. p p p
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
Architecture:Software architecture including a complete basic or environmental
AUTOSAR Main Working Topics
ApplicationInterfaces
Methodology
g psoftware stack for ECUs – the so called AUTOSAR Basic Software – as an integration platform for hardware independent software applications.
ApplicationInterfaces
Methodology
Architecture
Methodology:Exchange formats or description templates to enable a seamless configuration process of the basic software stack and the i i f li i f i d i i l d hInterfaces integration of application software in ECUs and it includes even the methodology how to use this framework.
ApplicationInterfaces
Methodology
Architecture
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
a standard for application software.
Intra‐ and Inter‐ECU Communication• Ports implement the interface according to
the communication paradigm (here client‐server based).
• Ports are the interaction points of a component.
• The communication is channeled via the RTE.
Appli‐cationSW‐CA
ECU I
Appli‐cationSW‐CB
ECU II
Appli‐cationSW‐CC
Application
• The communication layer in the basic software is encapsulated and not visible at the application l
RTE RTEVFBAUTOSAR
Ports
layer.
BSW BSW
AUTOSARInfrastructure
Sensor
Communication Bus
Communication Path
Hardware
6
AUTOSAR MethodologyAUTOSAR MethodologyVFB view
SW‐CDescription
SW‐CDescription
SW‐CDescription
SW‐CDescription
St d di d d i ti t l t fAUTO
SAR
SW‐C
1
AUTO
SAR
SW‐C
2
AUTO
SAR
SW‐C
3
AUTO
SAR
SW‐C
n...
Standardized description templates for application software components (interfaces and BSW requirements)
Virtual Functional Bus
System ConstraintDescription
ECUDescriptions
Tool supporting deployment
Standardized exchange formats and methodology for component, ECU, and system level
ECU m
AUTS
Mapping
of SW components
ECU II
AUS
ECU I
AUS
AUS
Tools for ‐ support of component mapping ‐ generation of RTE, i.e. inter‐ and intra ECU communicationTO
SAR
SW‐C
n
RTE
Basic Software
...
TOSA
RSW
‐C2
RTE
Basic Software
TOSA
RSW
‐C1
RTE
Basic Software
TOSA
RSW
‐C3
Standardized Basic Software (BSW) architecture, detailed specifications for implementation and configuration
intra ECU communication
7
Gateway
for implementation and configuration of BSW
AutoSAR Descriptions
ECUs Software Components
SW‐Component DescriptionECU Resource Description
ECU Resource ECU Resource
SwitchEval
SW‐Component Description
Description Description Description
BlinkInputModule
SwitchEvalBlinkInputModule
S t d t l
SW‐Component DescriptionBlinkMaster
LightActuatorsControl
BlinkMaster
LightActuatorsControlBC‐H
BC‐V
SMLS System Description
Supported protocols:CAN, LIN, FlexRay
SW‐Component Description LightSourceSetting
LightActuatorsControl
LightSourceSetting
BC‐V
CAN
LIN
8
SW‐Component DescriptionLM‐L LM‐R
AUTOSAR System Design ProcessInput: Requirements & Vehicle Info
ECU ResourceSW ComponentSystem
D i ti
Input: Requirements & Vehicle Info
1a 1c 1bECU ResourceDescription
SW ComponentDescription
Description
Configure System & generate extracts
2
& generate extracts of ECU descriptions
Configure
Iterative correctionsand/or optimizations
(if required)3
SW Component
geach ECU
Generate SW t bl
4
SW executables
executables for each ECU
9
SW executables for each ECU
AUTOSAR System Design ProcessInput: Requirements & Vehicle Info
1a 1c 1bECU ResourceDescription
SW ComponentDescription
SystemDescription
1a 1c 1b
2Configure System & generate extracts of ECU descriptions Iterative corrections
and(/or optimizations(if required)3
SW Component DescriptionGeneral characteristics (name, manufacturer, etc.)
SW Component
Configure each ECU
3
4
Communication properties:‐ p_ports‐ r_ports‐ interfaces
inner structure (composition)
Generate SW executables for each ECU
4‐ sub‐components‐ connections
required HW resources:‐ processing time‐ scheduling
10
SW executables for each ECU
‐memory (size, type, etc.)
AUTOSAR System Design ProcessInput: Requirements & Vehicle Info
1a 1c 1bECU ResourceDescription
SW ComponentDescription
SystemDescription
1a 1c 1b
2Configure System & generate extracts of ECU descriptions Iterative corrections
and(/or optimizations(if required)3
ECU Resource DescriptionGeneral characteristics (name, manufacturer, etc.)
SW Component
Configure each ECU
3
4
Temperature (own, environment, cooling/heating)
Available signal processing methods
Available programming capabilities
Available HW: ‐ µC, architecture (e.g. multiprocessor)
Generate SW executables for each ECU
4 ‐memory‐ interfaces (CAN, LIN, MOST, FlexRay)‐ periphery (sensor / actuator)‐ connectors (i.e. number of pins)
SW below RTE for micro controller
11
SW executables for each ECU
Signal path from Pin to ECU‐abstraction
AUTOSAR System Design ProcessInput: Requirements & Vehicle Info
1a 1c 1bECU ResourceDescription
SW ComponentDescription
SystemDescription
1a 1c 1b
2Configure System & generate extracts of ECU descriptions Iterative corrections
and(/or optimizations(if required)3
System DescriptionNetwork topology
‐ bus systems: CAN, LIN, FlexRay
SW Component
Configure each ECU
3
4
‐ connected ECUs, Gateways‐ power supply, system activation
Communication (for each channel) ‐ K‐matrix‐ gateway table
Generate SW executables for each ECU
4Mapping / Clustering of SW components
12
SW executables for each ECU
AUTOSAR Metamodel
• The metamodel is modeled in UML
METAMODEL
SWDatatype
• The structure of the information can be clearly visualized
SW‐Component
Interface
visualized
• The consistency of the information is guaranteed
MODEL
Mirror Adjustment
Mirror Actuator
• Using XML, a data exchange format can be generated automatically out of the
Adjustment Actuator
automatically out of the metamodel
13
Application Interfaces to Ease Reuse
Data Type Name LongAccBase
…
ESP-SensorsESP-Sensors
Interface of ESP
Base Sensor Signals I 1
ESP-SensorsESP-Sensors
Interface of ESP
Base Sensor Signals I 1
Data Type Name YawRateBase
Description Yaw rate measured along vehicle z- axis (i.e. compensated for orientation). Coordinate system according to ISO 8855
ESP
SW-Component
ESP
SW-Component2nd Yaw
Rate Controller2nd Yaw
Rate Controller
Information signals
Ínterface of ESP and external yaw rate controller
Standard Signals from ESP
VehicleLongitudinal
Controller
VehicleLongitudinal
Controller
Interface of ESP and VLC
I 2
I 6
I 4
ESP
SW-Component
ESP
SW-Component2nd Yaw
Rate Controller2nd Yaw
Rate Controller
Information signals
Ínterface of ESP and external yaw rate controller
Standard Signals from ESP
VehicleLongitudinal
Controller
VehicleLongitudinal
Controller
Interface of ESP and VLC
I 2
I 6
I 4 Data Type S16
Integer Range -32768..+32767
Physical Range -2,8595..+2,8594
Ph i l Off t 0gfrom other functions / domains
Command signals to other functions / domains
System-level BrakeActuator Interface
I 7
I 3
I 5
gfrom other functions / domains
Command signals to other functions / domains
System-level BrakeActuator Interface
I 7
I 3
I 5
Physical Offset 0
Unit rad/sec
… ….
Remarks This data element can also be used to Brake ActuatorBrake ActuatorBrake ActuatorBrake Actuator
Standardized application interfaces on system level
instantiate a redundant sensor interface.Range might have to be extended for future applications (passive safety).
…
Data Type Name RollRateBase
14
(ESP‐system, chassis domain) Data Type Name RollRateBase
Top Related