Presentation 1 CUBAS AUTOSAR Overview

CUBAS Training
Ver. 1.0.0
AUTOSAR Overview
© Robert Bosch Engineering and Business Solutions Ltd. 2008. All rights reserved, also regarding any disposal,
2 exploitation, reproducing, editing, distribution, as well as in the event of a applications for industrial property rights.
AUTOSAR Overview : Contents…
 Motivation
 Objectives
 Benefits
 Partners
 Work packages phase ll
 Roadmap
 Technical scope
 AUTOSAR in brief
 ECU software architecture
 VFB
 RTE
AUTOSAR Overview : Contents
 Configuration concept
 AUTOSAR metamodel
 Configuration Methodology
 Iterations in ECU Configuration
 Error handling
 AUTOSAR Conformance
 Use case example
 Summary
AUTOSAR Overview
What is Autosar ?
(AUTomotive Open System ARchitecture)
- is an open and standardized automotive software architecture, jointly

developed by automobile manufacturers, suppliers and tool developers.
Slogan : - “Cooperate on standards, compete on implementation”.
Motivation
The share of E/E in vehicles is increasing every year
 Master complexity
 Flexible E/E architectures
 Flexible exchangeability between supplier's and manufacturer's applications
 Keep quality & reliability of E/E systems at high level
 Enable global shared development
 Gain freedom for innovation
 Reduce costs
 Solution: Reuse and exchangeability of software

 Strategy: Standardization of software architecture
Motivation
AUTOSAR Managing Complexity by Exchangeability and Reuse of Software
Components
OEM b
2- Exchangeability
between supplier‘s
OEM a solutions
Platform b.1 OEM c
Platform b.2
Platform b.n
Platform a.1
Platform a.2 Platform c.1
Platform a.n Supplier A Supplier B
 Chassis  Chassis Platform c.2
Platform c.n
 Safety  Safety
3- Exchangeability  Body/Comfort  Telematics
between  Multimedia  Multimedia OEM d

manufacturer‘s Supplier C
applications  Body/Comfort
 Powertrain
 Telematics
OEM f
 Multimedia
Platform d.1
OEM e Platform d.2
Platform d.n
Platform f.1
Platform f.2 1- Exchangeability
Platform f.n
Platform e.1
between vehicle
Platform e.2
Platform e.n
platforms
Motivation
The driving factors behind AUTOSAR standardization
 Manage increasing E/E complexity associated with growth in functional scope
 Improve flexibility for product modification, upgrade and update
 Improve scalability of solutions within and across product lines
 Improved quality and reliability of E/E systems
 Enable detection of errors in early design phases
Objectives
The primary objectives from which the main requirements are derived
 Implementation and standardization of  Maintainability throughout the whole

basic system functions as an OEM wide “Product Life Cycle“
“Standard Core“ solution
 Scalability to different vehicle and  Software updates and upgrades over

platform variants vehicle lifetime
 Transferability of functions throughout  Consideration of availability and safety

network requirements
 Integration of functional modules

from multiple suppliers
Objectives
The functional domains which are in focus of AUTOSAR
Challenges and Benefits…
Problem Solution Benefit

Immature processes because of Standardizatio Improvement in specification (format and
acting in ad-hoc mode / missing n of content).
traceability of functional specification Opportunity for a seamless tool chain.
requirements. exchange
Lack of compatible tooling formats
(supplier, OEM).
 Effort wasted on Basic Enhancement of software quality.

implementation and optimization of Software core Concentration on functions with competitive
components, which add no value value
recognized by the customer.

Stop of availability of
microcontroller models causes huge Microcontroller Microcontroller can be exchanged without
efforts in adapting existing software. abstraction need for adaptations of higher software layers.
Extended needs for microcontroller
performance (caused by new
functions) cause need for upgrade,
i.e. re-design effort.
Challenges and Benefits
Problem Solution Benefit

 Large effort when relocating Runtime  Encapsulation of functions creates
functions between ECUs Environment independence of communication technology.
 Large effort when reusing (RTE)  Communication easier through
functions standardized mechanisms.
 Partitioning and relocatability of
functions possible
Non-competitive functions have Standardizati Reduction/avoidance of interface
to be adapted to OEM specific on of proliferation within and across OEMs and
environments. interfaces suppliers.
Tiny little innovations cannot be Eased implementation of hardware
implemented at reasonable effort independent software functionality by using
as provision of interfaces from generic interface catalogues.
other components requires a lot of Simplifies the model-based development
effort. and allows the use of standardized
Missing clear interfaces between AUTOSAR code generation tools.
basic software and code Reusability of modules cross-OEM.
generated from models. Exchangeability of components from
different suppliers.
Core Benefits
AUTOSAR
Conventional, by now
Application Software
Software
standardized
AUTOSAR RTE
Services
ECU Abstraction
and Complex Drivers
Microcontroller Abstraction
HW-specific
Hardware
Hardware
 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 Basic Software will become a product.
AUTOSAR partnership
- To develop AUTOSAR products the partnership level of at least the Associate member is required
- There is no royalty fees to be paid, only annual membership fees is sufficient.
Premium Members
CorePartner
Partner(OEM
(OEM&&Tier Tier11Supplier)
Supplier) Premium Members
Core  Leadership of Working Groups
 Organizational control  Leadership of Working Groups
 Organizational control  Involvement in Working Groups
 Technical contributions  Involvement in Working Groups
 Technical contributions  Technical contributions
 Administrative control  Technical contributions
 Administrative control  Access to current information
 Definition of external Information  Access to current information
 Definition of external Information
(web-release, clearance, etc.)
(web-release, clearance, etc.)
 Leadership of Working Groups
 Leadership of Working Groups
 Involvement in Working Groups
 Involvement in Working Groups
Support Roles
Associate Members  Development
Associate Members
 Access to finalized documents
 Access to finalized documents Member Agreement
 Utilization of AUTOSAR standard  Attendee Agreement
 Utilization of AUTOSAR standard
AUTOSAR in brief
SW-C SW-C SW-C SW-C
Description Description Description Description
OEM’s are able to validate the vehicle functions using the VFB
AUTOSAR
AUTOSAR
AUTOSAR
AUTOSAR
SW-C during the early development phase
SW-C
SW-C
SW-C
...
2
1
n
Virtual Functional Bus
Tool supporting deployment

of SW components
ECU System Constraint

Descriptions Description
Through the use of AUTOSAR methodology and tooling the

Vehicle functions (SWC’s) could be partitioned across
ECU I ECU II ECU m different ECU’s and configured appropriately.
AUTOSAR
AUTOSAR
AUTOSAR
AUTOSAR
SW-C
SW-C
SW-C
SW-C
...
1
RTE RTE RTE

The RTE+Basic s/w supports partitioning of SWC’s
Basic Software Basic Software Basic Software
across ECU’s and hardware independence.
Gateway
AUTOSAR ECU s/w architecture
AUTOSAR Application Actuator Sensor Application

Software
Component
Software
Component
Software
Component
Software
Component
AUTOSAR Software
Component
AUTOSAR AUTOSAR AUTOSAR Software AUTOSAR
Interface
Interface Interface Interface
.............. Interface
ECU
AUTOSAR Runtime Environment (RTE)
Firmware
Standardized
Standardized Standardized AUTOSAR AUTOSAR
Standard AUTOSAR
Interface Interface Interface Interface
Software Interface
ECU
Services Communication
API 2 Abstraction
VFB & RTE Standardized Standardized Standardized
Standardized
relevant Interface Interface Interface

Inteface
API 1 Complex
Operating
RTE Device
System
relevant Drivers
Standardized
API 0 Interface
Basic Software Microcontroller
API 3 Private Abstraction
Interfaces inside
Basic Software
possible ECU-Hardware
AUTOSAR Basic Software
 The Basic software provides the

SW-Component SW-Component
1
SW-Component
2 n
infrastructural (schematic
AUTOSAR AUTOSAR
.................... AUTOSAR
dependent and schematic
Interface Interface Interface independent) functionalities of an
ECU
 The Basic Software contains
AUTOSAR RTE standardized and ECU specific
components.
 The different modules include OS,
 Operating system
Basic Software drivers and services for accessing
 Transfer layers for different communication technologies (e.g. CAN, LIN, …)
communication devices like CAN,
 Network management LIN, memory devices, IO
 System services (diagnostic protocols, …)
peripherals and system devices
 NVRAM management
 … etc….
ECU Hardware
Virtual Function Bus
SW-C
SW-C1 SW-C2 SW-CN
SW-C SW-C SW-C
AUTOSAR AUTOSA AUTOSAR
Interface Interface Interface
AUTOSAR AUTOSAR RTE

AUTOSAR
AUTOSAR
AUTOSAR
SW-C
SW-C
SW-C
SW-C
...
2
1
n
Basic Software
Virtual Functional Bus
ECU Hardware
 VFB is a virtual bus supporting communication mechanisms (Send-receive, client-server)

between the AUTOSAR SW-C’s and Basic SW modules
 Virtual vehicle wide integration of AUTOSAR software components before implementation
 Early validation of system design i.e. completeness of communication interfaces
 Partitioning of Software Components on ECU’s
Run Time Environment
ECU I ECU II ECU m
AUTOSAR
AUTOSAR
AUTOSAR
AUTOSAR
SW-C
SW-C
SW-C
SW-C
n
2
1
3
...
RTE RTE RTE
Basic Basic Basic

Software Software Software
Gateway
CAN FlxRy
 RTE is the ECU specific instantiation of the VFB

 RTE decouples the application SW-C’s from the underlying HW and Basic SW
 RTE+BSW enables relocatability of the Autosar SW-C’s within different ECU’s. I.e. it supports
intra-task, inter-task, and inter-ECU communication.
AUTOSAR methodology
SW-C SW-C SW-C SW-C
Standardized description templates for application
AUTOSAR
AUTOSAR
AUTOSAR
AUTOSAR
SW-C
software components (interfaces and BSW
SW-C
SW-C
SW-C
...
2
1
n
requirements)
Virtual Functional Bus Standardized exchange formats and

methodology for component, ECU,
and system level
Tool supporting deployment
of SW components
ECU System Constraint

Descriptions Description Tools for support of component
mapping
ECU I ECU II ECU m

Generation of RTE, i.e. inter- and intra
ECU communication
AUTOSAR
AUTOSAR
AUTOSAR
AUTOSAR
SW-C
SW-C
SW-C
SW-C
...
1
RTE RTE RTE Standardized Basic Software (BSW)

Basic Software Basic Software Basic Software architecture, detailed specifications for
implementation and configuration of
Gateway
BSW
Configuration concept
 Generic OR dedicated
configuration editor
 Configuration variants with
combination of following
configuration classes
-Pre-compile time
-Link time
-Post build time
iSolar iSolar
iSolar
iSolar
Configuration Methodology
 The System configuration input means filling out templates for S/W components, ECU resources,
System constraints.
The activity of the Configure System mainly maps the software components to the ECUs with regard to resources and timing requirements.
Iterations in ECU configuration
Error handling
event
Software DEM memory
Component
diagnosis
function
in field
Template reports inhibition
Application diagnostic
Software events
Component
Basic
Software reports
integration
Module development
support
Basic
Software errors serial
Specification communication
DET debugger
breakpoint
design
phase
DEM: Diagnostic Event Manager – Supports monitor and control needs during normal operation
DET: Development Error Tracer – Supports diagnostics during implementation and integration phase
Use case front light management
SwitchEvent LightRequest Front-Light Manager Headlight
check_switch () switch_event(event) request_light(type, mode) set_light(type, mode)
get_keyposition()
switch_event request_light
set_light(type, mode) set_current (…)
(event) (type, mode)
AUTOSAR Int. AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface
AUTOSAR RTE
Standardized Std. AUTOSAR Standardized AUTOSAR AUTOSAR
Interface Interface Interface Interface Interface
Communi- ECU
Services cation Abstraction
Std. Interface
Standardized
Std. Interface Std. Interface

Interface
Complex
Operating Device
System Drivers
Standardized Interface
DIO PWM CAN Driver
ECU-Hardware
Exchange of type of front light
SwitchEvent LightRequest Front-Light Manager Headlight
Xenonlight
check_switch () switch_event(even request_light(type, mode) set_light(type, mode)
t) get_keyposition()
switch_event request_light
set_light(type, mode) set_current (…)
(event) (type, mode)
AUTOSAR Int. AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface
AUTOSAR RTE
Standardized Std. AUTOSAR Standardized AUTOSAR AUTOSAR
Interface Interface Interface Interface Interface
Communi- ECU
Services cation Abstraction
Std. Interface
Standardized
Std. Interface Std. Interface

Interface
Complex
Operating Device
System Drivers
Standardized Interface
DIO PWM
DIO CAN Driver
ECU-Hardware
AUTOSAR conformance testing
CTA (Conformance Test Agency) Product Supplier

CTS (Conformance Test Suite) Product under Test
with CTA without CTA

Objective: Verify that a product
Path A Path B Path C Path D
under test adheres to
corresponding AUTOSAR Conformance Test Agency (CTA)
specifications.
First party First party
PS (licensee of
AUTOSAR)
Third party CTA CTA
CTA Own test procedure
with purchased
with own CTS
CTS Inhouse support
Third party Self- Self- Self-

Attestation Declaration Declaration Declaration
Release x.y
Conformance types : Procurement decision
Implementation Cluster Conformance Class (ICC) Customer (e.g. OEM)

Functional Conformance Class (FCC)
Configuration Conformance Class (CCC)

Presentation 1 CUBAS AUTOSAR Overview

Uploaded by

Copyright:

Available Formats

You might also like

Presentation 1 CUBAS AUTOSAR Overview

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Presentation 1 CUBAS AUTOSAR Overview

Uploaded by

Copyright:

Available Formats

CUBAS Training

(AUTomotive Open System ARchitecture)

- is an open and standardized automotive software architecture, jointly

Slogan : - “Cooperate on standards, compete on implementation”.

 Solution: Reuse and exchangeability of software

between  Multimedia  Multimedia OEM d

The driving factors behind AUTOSAR standardization

 Manage increasing E/E complexity associated with growth in functional scope

 Improve flexibility for product modification, upgrade and update

 Improve scalability of solutions within and across product lines

 Improved quality and reliability of E/E systems

 Enable detection of errors in early design phases

 Implementation and standardization of  Maintainability throughout the whole

 Scalability to different vehicle and  Software updates and upgrades over

 Transferability of functions throughout  Consideration of availability and safety

 Integration of functional modules

Problem Solution Benefit

 Effort wasted on Basic Enhancement of software quality.

Problem Solution Benefit

 Hardware- and software will be widely independent of each other.

Automotive Basic Software will become a product.

Tool supporting deployment

ECU System Constraint

Through the use of AUTOSAR methodology and tooling the

RTE RTE RTE

AUTOSAR Application Actuator Sensor Application

relevant Interface Interface Interface

 The Basic software provides the

AUTOSAR AUTOSAR RTE

 VFB is a virtual bus supporting communication mechanisms (Send-receive, client-server)

ECU I ECU II ECU m

Basic Basic Basic

 RTE is the ECU specific instantiation of the VFB

Standardized description templates for application

Virtual Functional Bus Standardized exchange formats and

ECU System Constraint

ECU I ECU II ECU m

RTE RTE RTE Standardized Basic Software (BSW)

AUTOSAR Int. AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface

Std. Interface Std. Interface

AUTOSAR Int. AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface

Std. Interface Std. Interface

CTA (Conformance Test Agency) Product Supplier

with CTA without CTA

Third party Self- Self- Self-

Conformance types : Procurement decision

Implementation Cluster Conformance Class (ICC) Customer (e.g. OEM)

You might also like