AUTOSAR

AUTOSAR Automotive Open System ARchitectureChallenges and Achievements 2005

Dr. Thomas Scharnhorst, AUTOSAR Spokesperson

2 Friday, 06 July 2007

Management summary


AUTOSAR aims to improve complexity management of integrated E/E architectures through increased reuse and exchangeability of SW modules.

Platform m.nPlatform m.2

Platform m.1

OEM m

Platform 2.nPlatform 2.2

Platform 2.1

OEM 2

Supplier BChassisSafetyTelematicsMultimedia

Supplier AChassis

SafetyBody/Comfort

Multimedia

Supplier CBody/Comfort

PowertrainTelematicsMultimedia

Platform 1.nPlatform 1.2

Platform 1.1

OEM 1

Platform m.nPlatform m.2Platform m.1

OEM n

Transferabilitybetween suppliers

Transferabilitybetween vehicle platforms

Transferabilitybetween manufactureres


AUTOSAR integrates existing and emerging industry electronics standards.

2001

ASAM/ODX 2002

HISFlexRay

MSRManufacturer-Supplier Relationship

Hersteller Initiative Software

2006

Media OrientatedSystem Transport

ASAM ODX

AUTomotive Open System ARchitecture

OSEK/VDX

Local interconnect network


Worldwide, OEMs and suppliers participate in AUTOSAR.Status: June 9th, 2005

10 Core Partner

Development MembersAttendees

GeneralOEM

GenericTier 1 Software Tools Semi-

conductors

15 AssociateMembers

45 Premium Members


The AUTOSAR core partners manage the project and maintain organizational control.

Adm

inis

tratio

n

Technical Office

Technical Manager

Project ControlOffice

Project Organization

Executive Board

Steering Committee

PL Team

Working Groups

System Team

Support Functions

Spokes-person

Basic SWArchitecture Team


Project Objectives Topics

Methods of Software Integration

Basic Software

Functional APIs

Consideration of availability and safety requirements

Redundancy activation

Scalability to different vehicle and platform variants

Implementation and standardization of basic system functions as an OEM wide “Standard Core“ solution

Transferability of functions throughout network

Integration of functional modules from multiple suppliers

Maintainability throughout the whole “Product Life Cycle“

Increased use of “Commercial off the shelf hardware“

Software updates and upgrades over vehicle lifetime

To achieve the objectives, AUTOSAR has to address the main topics:software integration, basic software, and functional APIs.


ActuatorSoftware

Component

AUTOSARInterface

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component

..............AUTOSARSoftware

Basic Software

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

StandardizedInterface

MicrocontrollerAbstraction

AUTOSARSoftware

Component

ECUFirmware

StandardSoftware

StandardizedAUTOSARInterface

Services


ECUAbstraction

AUTOSARInterface



Communication


API 2VFB & RTErelevant

API 1RTE relevant

API 0

API 3 PrivateInterfaces insideBasic Software

possible

DifferentKinds of

Interfaces

AUTOSAR Runtime Environment (RTE)

OperatingSystem



ComplexDeviceDrivers

AUTOSARInterface

ECU-Hardware

The AUTOSAR ECU software architecture comprises the layers Application, AUTOSAR Run Time Environment (RTE), and Basic Software.


ActuatorSoftware

Component

AUTOSARInterface

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component


Basic Software

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface



AUTOSARSoftware

Component

ECUFirmware

StandardSoftware


Services


ECUAbstraction

AUTOSARInterface



Communication



API 1RTE relevant

API 0


possible

DifferentKinds of

Interfaces


OperatingSystem




AUTOSARInterface

ECU-Hardware

Basic Software Architecture: The layered architecture is finalized

Services Layer

ECU Abstraction LayerComplexDrivers

Microcontroller Abstraction Layer


ActuatorSoftware

Component

AUTOSARInterface

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component


Basic Software

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface



AUTOSARSoftware

Component

ECUFirmware

StandardSoftware


Services


ECUAbstraction

AUTOSARInterface



Communication



API 1RTE relevant

API 0


possible

DifferentKinds of

Interfaces


OperatingSystem




AUTOSARInterface

ECU-Hardware

Basic Software Architecture: The layered architecture is split up in more than 80 different modules

Services Layer

ECU Abstraction LayerComplexDrivers

Microcontroller Abstraction Layer

Weitere Detaillierung der LayeredArchitecture

Konzeptfolie


Service Layer – Flow through the layer

COM Drivers

Memory Hardware Abstraction

EEPROM Interface

SPI Handler

µC

Memory Drivers

InternalEEPROM DriverSPI Driver

SPI EEPROM

ExternalEEPROM Driver

Memory Services

NVRAMManager

ExternalEEPROM

Spi_Read()Spi_Write()

EepIf_Read()EepIf_Write() ECU

device #2

device #1

µC I/O driver

driver #1

µC

driver #2IF


Following the AUTOSAR Method, the E/E architecture is derived from the formal description of software and hardware components.

Using „Software Component Descriptions“ as input, the „VirtualFunctional Bus“ validates the interaction of all components and interfaces before actual software implementation.

The AUTOSAR Method supports the generation of an E/E architecture.


Description of Topology

System-Constraint Description

ECU Resource Descr.

ECU Resource Descr.

ECU Resource Descr.

LightSourceSetting

BlinkInputModule

BlinkMaster

LightActuatorsControl

SwitchEvalSW-Component Description

BlinkInputModule

SW-Component Description

BlinkMaster



BC-HBC-V

SMLS

LM-L LM-R

BodyFlexRay

LIGHTCAN


SwitchEval


LightSourceSetting

Net of ECUs Net of Software Components

Konzeptfolie


Description of Mapping

System-Constraint Description

SW-C to ECUs Interface Connections to Bus Signals

LightSourceSetting

BlinkInputModule

BlinkMaster


SwitchEval

SWCMappingDefs

SwitchEval

BlinkInput

Module

switchStatus

Comm.Matrix for BodyFlexRay

…FrameInstance BlinkSwitch

SignalBS1SignalBS2 SignalBS3

DataMappingDefs

Konzeptfolie


Unified functional interfaces are been standardized to ensure the interoperability of functional Software-Components (applications) from different sources

Body/Comfort domainPowertrain domainChassis domainSafety domainMultimedia and HMI domain

Body Comfort

Exterior Light ready for approvalInterior Light ready for approvalCentral Locking 60%Anti Theft 60%Wiper Washer ready for approval

Powertrain

Chassis

Driver Request 95%Functional Architecture 50%System Functionalities 50%

ACC 91%External ESP Interfaces just started


The AUTOSAR standard will be completed and available to OEM product development in 2006.

Test & Validation

- BSW and RTE prototype implementations and integrations completed, test specification completed

- All documents formally released, specificationsverified on an applicationdemonstrator, proof of concept demonstrated

Milestones

Phases

Status

actualtimeline

- Autosar BSW specifications for Release 1 are finalized

15.12.2005 31.5.2006 15.12.200630.4.2005

Validation- Autosar BSW and

RTE specifications for Release 2 are finalized

- Autosar concept finalized

30.9.2005

Specification of Templates, BSW and RTE

30.9.2004

IntegrationMethodologySpec R2.0Spec R1.0Concept

2H 2004 1H 2005 2H 2005 1H 2006 2H 2006

Konzeptfolie

- methodology and templates finalized

Implementation and Integration

Update BSW and RTE Specifications via CCB


Time

Proprietary Basic SW Core

AUTOSAR-development

MS 1

OEM infrastructure

MS 2’MS 2

Partly proprietary solutions

Implantation of components not available from AUTOSAR

Incorporation of all available AUTOSAR specifications

Today Future – AUTOSAR LifeTransition period

Migration scenarios allow concurrent deployment of AUTOSAR modules and existing proprietary components to one ECU.


Conclusion

Fast growth of the complexity of automotive E/E architectures is a major challenge with respect to product quality.1

Systems Engineering is an integrated approach which covers the development process and the complete product life cycle.3

AUTOSAR enables management of the growing E/E complexity with respect to technology and economics.4

Through interconnection of subsystems, new system properties emerge which have to be understood and controlled.2

AUTOSAR pushes the paradigm shift from an ECU based to a functionbased approach in automotive software development.5

Konzeptfolie


How to get in contact with AUTOSAR …

[email protected]

http://www.autosar.org


Thank you for your attention!

[email protected]

http://www.autosar.org


Backup


HeadingSub-Heading

Level 1Level 2

Level 3– Level 4

– Level 5


Document information and change history

0.1Document Version<Draft | Ready for Approval | Final>Document Status

<AUTOAR_VDI_BadenBadenPresentation.ppt> Document TitleSCDocument ResponsibilityDr. Thomas ScharnhorstDocument Owner

Document creation

Change DescriptionGabriel Schwab

Changed by0.107.06.2005

VersionDateDocument Change History


AUTOSAR concept (specification and preparation of a de-facto

standard) is feasible and in plan

09/04

12/03

Phases

Mile-stones

Structure & BasisSpecification

Standardization of theAUTOSAR architecture

Initiation of Partnership

05/03 11/05

06/05

08/06

AUTOSAR compatibility of selected SW modules is approved. First

tools and generators are available

AUTOSAR specifications are tested and verifiedon an application

02/06

Realization of Run Time Environment feasible and on

track

Evaluated test and integration process (product oriented)

Implementation of theSW-Components

Test- & Integration-process

Project plan created

and agreed

AUTOSAR concept (specification and preparation of a de-facto

standard) is feasible and in plan

AUTOSAR Concept and first specification are created and

executability is approved

WP10 / WP20

The AUTOSAR standard will be completed and available to OEM product development in 2006.

Konzeptfolie


Colors

Documents

AUTOSAR