PRESENTATION ON AUTOSAR

Presented by, Bhupendra kharpuse 11AT61R08

CONTENTS:


Introductory part of AUTOSAR Basic aspects of AUTOSAR with Brief discussion Conclusion about AUTOSAR

WHY AUTOSAR !
Problem definition:


High complexity of contemporary automotive E/E (electric/ electronics) architecture. Satisfactorily and fulfill of legal requirements at heightened prospectories. Interfacing of all the component of automobiles whether it is software or hardware. Methodology.
3

ARISING POINT OF AUTOSAR

 

At November 2002 Their common objective is to create a basis for industry collaboration on basic functions. Providing a platform which continues to encourage competition on innovative functions in automotive industries. To this end a of discussion, a platform formed by the OEM(Original equipment manufacturers) and Tier-1 supplier which is AUTOSAR(Automotive open system architecture).
4

WHAT IS AUTOSAR


The AUTOSAR (Automotive open system architecture) is open and standardized Architecture. It aims to be prepared for the upcoming technologies and to improve cost-efficiency without making any compromise with respect to quality. It also minimize the current barriers between functional domains. By AUTOSAR it will be possible to map functions and functional networks to different control nodes in the system(which is almost independent from the associated hardware).

WHO IS AUTOSAR?

TECHNICAL SCOPE OF AUTOSAR

New concepts
Methodology Virtual functional Bus Configuration concept ECU abstraction Drivers OS kernel Meta model Exchange format Run time environment Error handling Input Templates Gateway Bus system controller abstraction Mode management
7

Common service Network management

Existing one

BASIC AUTOSAR APPROACH

SW-C Description AUTOSAR SW-C-1 SW-C Description AUTOSAR SW-C-2 SW-C Description AUTOSAR SW-C-3 SW-C Description AUTOSAR SW-C-n

ECU Description

Tool supporting deployment of SWComponent

System constraint Des.

AUTOSAR SW-C-1

AUTOSAR SW-C-3 RTE BASIC SOFTWARE

BASIC ASPECTS OF AUTOSAR

Architecture Methodology

Application interfaces

AUTOSAR

SOFTWARE ARCHITECTURE
Software component1 AUTOSAR interface Software component2 AUTOSAR interface . Software componentn AUTOSAR interface

AUTOSAR RTE

BASIC SOFTWARE Transfer layer for different communication technologies(e.g. CAN.. Network management System services NVRAM management Microcontroller Abstraction
10

ECU Hardware

LAYERED ARCHITECTUR

11

Microcontroller Abstraction Layer:  lowest software layer of the Basic Software  Makes higher software independent of microcontroller
12

ECU Abstraction Layer:  Interfaces the drivers of Microcontroller Abstraction layer.  Makes higher software layers independent of ECU hardware layout.  Offers access to I/O Signals.

13

Service Layer:  Highest layer of the Basic Software  Offers Memory Services, Diagnostic Services, ECU management service.  Provides basic services for application and basic software modules

14

Runtime Environment:  Middleware Layer.  Provides communication services for the application software.  Makes AUTOSAR Software Components independent from the mapping to a specific ECU.

15

Application Layer:  component style.  Software components communicate with other components and/or services via the RTE.
16

INTER-INTRA ECU COMMUNICATION

ECU-1 ECU-2 Applicatio n SW-C Applicatio n SW-C

Application
Applicatio n SW-C

Port AUTOSAR Interface

RTE BSW RTE VBF BSW

Hardware Communication Bus

Sensor
17

  

Ports implement the interface according to the communication paradigm (her client-server based). Ports are the interaction points of component. The communication is channeled via the RTE. The communication layer in the basic software is encapsulated and not visible at the application layer.

18

STANDARDIZED INTERFACES COVERS



Standardization of different APIs to separate the AUTOSAR SW layers. Facilitate encapsulation of functional SWcomponents. Definition of the data types of the SW-components to be AUTOSAR compliant. Identify basic SW modules of the SW infrastructure and standardize their interfaces.

19

AUTOSAR METHODOLOGY


The AUTOSAR-project created a methodology that can be used to create the E/E system architecture starting from the design-model. This approach uses 4 stepsa) Input Description b) System Configuration c) ECU-Configuration d) Generation of software executable

20

INPUT DESCRIPTION


Software Components: It concern actual implementation of the software component. Among the necessary data to be specified are the interfaces and the hardware requirements. System: The system topology (interconnections between ECUs) need to be specified together with the available data busses, used protocols, function clustering and communication matrix and attributes (e.g. data rates, timing/latency, ). Hardware: The available hardware (processors, sensors, actuators, ) needs to be specified together with the signal processing methods and programming capabilities

21

SYSTEM CONFIGURATION


This step distributes the software component descriptions to the different ECU. This is an iterative process where ECU-resources and systemconstraints are taken into account. For example, there needs to be checked whether the necessary communication-speeds are met.

22

ECU-CONFIGURATION


In this step, the Basic Software and the Run Time Environment of each ECU is configured. This is based on the dedication of the application software components to each ECU. All information that is local to a specific ECU the runnable software can be built from this information and the code of the software component will be based on that information.
23

GENERATION OF S/W EXECUTABLES



Based on the configuration of the previous step, the software executables are generated. For this step, its necessary to specify the implementation of each software component. This methodology is automated by using toolchains. All subsequent methodology steps up to the generation of executables are supported by defining exchange formats (using XML) and work methods for each step.

24

AUTOSAR- SYSTEM DESIGN

Input: Requirement and vehicle info SW Component Description System Description Configure system & generate extracts of ECU description Configure each ECU Generate SW executable for each ECU
25

ECU resource Description

SW Component

Iterative Correction and/or Optimization (if required)

SW Component Description

Work product Compile RTE Activity .obj Compiled RTE

.XML ECU Configuration

Generate RTE

.h
RTE header Work product

.c
26

RTE code

OVERVIEW OF METHODOLOGY
.XML System configuration input .XML System configuration description .XML ECU extract of System configuration EE-SI Extract ECU specific information EE-SI Configure system ECU configuration description .XML

ECU executable .XM L

Generate executable

Configure ECU

27

METHODOLOGY TO META MODEL

Advantageous points:


To support the AUTOSAR-methodology, a metamodel is developed. This is a formal description of all methodology related information, modeled in UML. This leads to the following benefits: 1) The structure of the information can be clearly visualized. 2) The consistency of the information is guaranteed. 3)Using XML, a data exchange format can be generated automatically out of the meta-model and be used as input for the methodology. 4)Easy maintenance of the entire vehicular system.

28

MAIN MOTIVATION
Management of E/E complexity associated with growth in functional scope.  Flexibility for product modification, upgrade and update.  Scalability of solutions within and across product lines.  Improved quality and reliability of E/E systems.

29

GOALS


OF AUTOSAR

  

 

Implementation and standardization of basic system functions as an OEM wide "Standard Core" solution. Scalability to different vehicle and platform variants. Transferability of functions throughout network. Integration of functional modules from multiple suppliers. Consideration of availability and safety requirements. Redundancy activation. Maintainability throughout the whole "Product Life Cycle.

30

Increased use of "Commercial off the shelf hardware. Software updates and upgrades over vehicle lifetime.

31

BENEFITS FROM AUTOSAR

OEM (original equipment manufacturers)

 

 

OEM overlapping reuse of software modules. Maintaining ability to compete on innovative functions, enlarged design flexibility. Simplification of the integration task. Reduction of total SW development costs.
32

BENEFITS FROM AUTOSAR

Tool supplier

 

Common interfaces with development processes. Seamless, manageable, task optimized (time dependent) tool landscape.

33

BENEFITS FROM AUTOSAR

New market entrant

Transparent and defined interfaces enable new business models.

34

RELATED CRITICISM


Timing Related to latencies. Efficiency Reuse of basic function on application s/w. Too much standard Many supplier offers different subsets of standards.

35

SOME RESTRICTION WITH EXCEPTION

 

When A-SW-C shipped as object code, this code is of-course highly dependent on ECU architecture. The implementation might contain dependencies on a specific microcontroller, when we use assembly language. System constraints related to issue of security and safety might also reduces the mapping flexibility on ECUs. If two s/w component are very closely connected to each other than it should be in same ECU.
36

A U T O S A R

Cooperate on standards, compete on implementation.

AUTOSAR is ready to be used automotive product development Exploitation has already started

O U T L O O K
37

REFERENCES:
[1] AUTOSAR GbR: Technical Overview http://www.autosar.org/download/AUTOSAR_TechnicalOv erview.pdf [2] AUTOSAR GbR: About AUTOSAR http://www.autosar.org/ [3] AUTOSAR GbR: Layered Software Architecture http://www.autosar.org/layered_software_architecture.pdf
38

[4] VOLKSWAGEN AG, Carmeq GmbH: AUTOSAR-Compliant Functional Modeling with MATLAB, Simulink, State flow and Real-Time Workshop Embedded Coder of a Serial Comfort Body Controller, at Math works Automotive Conference 2007 http://www.mathworks.com/industries/auto/mac200 7/proceedings/day2/presentations/2_autosar.pdf [5] [Conv2004] Automotive open system architecture- An industry wise initiative to manage the complexity of emerging automotive E/Earchitecture. http://www.autosar.org/download/ AUTOSAR_paper_convergence_2004.pdf

39