autosar - department of computer science 4 at fau

Department of Computer Science 4Distributed Systems and Operating Systems

Friedrich-Alexander University Erlangen-Nuremberg

Isabella Stilkerich

http://www4.cs.fau.de/Research/KESOwww.autosar.org

http://www4.cs.fau.de/[email protected]

AUTOSAR

http://www4.cs.fau.de/Research/KESO

http://www.methodpark.de

http://www4.cs.fau.de/~mike

mailto:[email protected]?subject=IIDS%202010%20presentation

[email protected] - Entwicklung und Test von verteilten, eingebetteten Systemen im Bereich Automotive (ETeS) 23.01.2012

Overview! Motivation! AUTOSAR Layered Architecture! AUTOSAR Methodology! AUTOSAR Software Components! AUTOSAR RTE! AUTOSAR Basic Software! Conclusion

2


http://www.iids-workshop.org/



Motivation

3

Climate Control Unit

Rain sensors

Infotainment

Navigation

Brake system

Cruise control

etc.

Fuel-injection





AUTOSAR! AUTOSAR development partnership founded in 2003! Open standard for the E-/E-Architecture in the

automotive field

4

Software

Hardware

Cooperate on standards – compete on implementation





Core partners and members

5





Benefits! E/E-Architecture is devided into several layers! Abstraction from underlying hardware! Provision of Basic Software (BSW) Modules ! Integration of application modules from various

suppliers! Standardization of

"Exchange formats" Interfaces"Methodology

6





Reusability of function in different vehicles

7

Seat Control Light System Wiper System

…

µ-Controller B µ-Controller B

Distributed System B

Code

Library

µ-Controller A µ-Controller A

Distributed System A

Code

Vehicle A Vehicle B

Configuration





Virtual Function Bus (VFB)

! Strict separation of application and infrastructure logic! The VFB concept is implemented by the Runtime

Environment (RTE)! The RTE provides an abstract “instruction set”

8

Virtual Function Bus

Rain Sensor Wiper Motor

Control (front)

Wiper Control Logic

Wiper Motor Control (rear)

Position Switch

SW-Components = Applications






9





Architecture

10

ECU (Electronic Control Unit) Abstraction Layer

Service Layer : OS (Operating System), I/O (Input/Output), etc.

MCAL (Microncontroller Abstraction Layer)





Discipline “Software Architecture”

11

Application

AU

TOSA

R SW

-C 1

AU

TOSA

R SW

-C 2

AU

TOSA

R SW

-C 3

AU

TOSA

R SW

-C n ...






12





Methodology! Methodologies are similar to cooking recipes, they

describe" the “ingredients“"when and how these are used

! AUTOSAR defines requirements on" the software architecture" the software development methodology

13





Methodology (Development)

14

SW-C Description

System-Constraint Description

ECU Description

ECU Config Description

System Configuration Description

ECU Binary

SW-C implementation

Configure System

Configure ECU

Generate

SW-C API Generate Implement





SW-C Description! The description contains:

"Component interfaces"Provided and required data and operations"Hardware and infrastructure requirements"Needs for services" Information on specific implementation

! Structure of information defined in the SW-C Template

15

SW-C Description





ECU Description! ECU = Electronic Control Unit (German: “Steuergerät”)! Description of

"Hardware elements such as processing units, memory"Hardware ports"Hardware connections

! Structure is defined by the ECU Resource Template

16

ECU Description





System Constraint Description! Description contains:

" Information on networking topologies (CAN, LIN, FlexRay)"Mapping and mapping constraints"Communication matrix"Protocols

! Structure defined by the System Template

17

System-Constraint Description





System / ECU Configuration

18





System Image

19

object files

SW-C files

source files

Com

piler

Linker

SW-C

OS

RTE

MCAL

other BSW






20





Software Components (SW-C)! A SW-C needs to described in an abstract way (SW-C

description)" Interfaces" Internal behavior (e.g. runnable entities, events)" Implementation

! Source/object code

21

source / object code

SW-C

C implementation description

C internal behavior description C Type description





Interfaces (Classification)! AUTOSAR Interface (relevant for SW-C)! Standardized AUTOSAR interface! Standardized interface

22





AUTOSAR Interface! Interface=Typification of a connection between entities! Definition of SW-C ports (interaction points=interface

instance)! Ports needed for SW-C Communication / Basic

Software access! Communication can be done locally or via a network

23

AUTOSAR Interface

Sender-/Receiver- Interface

Client-/Server- Interface





Interfaces and ports! Interface

"A type definition of an interaction point (port)! Port

"An instantiation of an interface.! Provided port

"A component offers an interface, that can be used by another component (created by providing component)

! Required port"A components needs access to an interface,

that is provided by another component (created by the requiring component)

! Required and provided ports have to be connected in a composition component

24

SW-C_1

SensorPort

Temperature

SW-C_2

ClimateControl

Temperature





Sender-/Receiver-Interface! m:n communication, uni-directional! Different semantics

"Data distribution: Last-is-best (explicit/implicit)"Event distribution

25

Sender SW-C

Receiver_1 SW-C

Receiver_2 SW-C

receiver information

Send/provide signal

Receive/require signal





Sender-/Receiver-Interface (Example)

26

Sender-Receiver-Interface If_Switch {

Boolean SwitchPosition

}

PositionSwitch

P_Switch If_Switch





Client-/Server-Interface! n:1 communication! Synchronous and asynchronous calls! Server runnable in

"Task context"Client context

27

requests service

provides service





Interfaces and ports (revised)! Sender-/Receiver-Interface:

"Component sending the signal, defines the provided port – the receiver the required port

! Client-/Server-Interface: Different perspective"The direction of the control flow defines, which component has

the provided or required port (function call direction)! Example: SW-C_1 interested in sensor data by SW-C_2

"SW-C_2 offers functionality, data flow from SW-C_2 to SW-C_1"Polling: SW-C_2 provides interface SensorValues

28

SW_C_2 SW-C_1

«interface» SensorValues

getExternalTemperature() : float

SensorValues SensorValuesQuery





Interfaces and ports (revised)! Direction of the control flow defines, which component

has the provided or required port (function call direction)! Example: SW-C_1 interested in sensor data by SW-C_2

"SW-C_1 offers functionality, data flow from SW-C_2 to SW-C_1"Pushing: SW-C_1 provides notification interface

SensorValuesUpdate

29

SW-C_2 SW-C_1

«interface» SensorValuesUpdate

newTemperatureData(float) : void

SensorValuesUpdate SensorValuesUpdate





Software Components (SW-C)! A SW-C needs to described in an abstract way (SW-C

description)" Interfaces" Internal behavior (e.g. runnable entities, events)" Implementation

! Source/object code

30

source / object code

SW-C

C implementation description

C internal behavior description C Type description





Internal Behavior! Runnable Entities (runnables)

"Schedulable piece of code in SW-C"Usually mapped to tasks, execution triggered by RTE

31

PositionSwitch

CheckPosition

void SwitchControl_CheckPosition() {

Std_ReturnType success;

boolean activated;

… /* Read HW state and write to activated */ …

success = Rte_Write_P_Switch_SwitchPosition(activated);

…

}

TASK(Rte_Task) {

…

/* trigger Runnable Entity Switch_Position */ SwitchControl_Switch_Position();

…

}

Runnable

Generated RTE Code

Code in SW-C





Internal Behavior! Events

"Operation Invoked Event"Timing Event"Data Received Event" ...

! Points and accesses" Information about interaction between SW-C in Runnables

! Port API Options"Logical Representation of data entities on SW-C level

32





AUTOSAR SW-C vs Classical App! No task bodies in SW-C! SW-Cs communicate only via ports

"No interrupt handlers in SW-C"No shared memory usage

! Abstract use of services via RTE"OS"Communication"Memory" I/O

33





Application Design

34





Application Design (Revised)

35





SW-C development (Summary)

! Model component (ports, interfaces)! Connection between the SW-C! Creation of a runnable, events

"Entry in SW-C description"Needs on RTE (called cyclically, response to an event?)"or: mark as “can be invoked concurrently”

36

xml








37

xml

! Writing source code for the SW-C! Schedulable code resides in dedicated functions

programming language








38

xml

! Writing source code for the SW-C! Schedulable code resides in dedicated functions

programming language

! Mapping of the function to an appropriate runnable

xml






39





The Broker

40

Runtime Environment

SW-C SW-C SW-C

OS Services Com I/O





A Middleware for abstract Communication! Classification of Communication

" Intra-ECU com within a single SW-C (runnables)" Intra-ECU com between SW-C " Intra-ECU com between SW-C and BSW (system software)" Inter-ECU communication

! Implementation of communication patterns:"Client-Server"Sender-Receiver

! Tasks of the RTE are also:"Multiple instances of SW-Cs"Synchronization (concurrency issues)

! RTE code fully generated by the RTE generator"Two-phase approach

41





Intra SW-C Communication! Example: Lost update issue

"Notice: Can also occur, if REs have activated the canBeInvokedConcurrently feature, i.e. simple function call

42

x

Runnable mapped to Task_1

Runnable mapped to Task_2

Memory

(1) read x=3

(1) read x=3 (2) x=x+5 (3) write x=8

Task switch





Synchronization! Developer sometimes has to ensure data consistency

by"Exclusive areas" Inter-Runnable-Variables

43

Task_1

Rte_Enter() Rte_Exit()





Synchronization Techniques! Disable / Enable interrupts (via OS API)! Sequential scheduling! Task blocking! Employment of OS resources! Cooperative runnable placement (Fine-grained task blocking)! Copy strategy

"Read, write copy (Implicit S/R communication)"Single writer

! Per-Instance memory (SW-C developer has to insure consistency)!

! No semaphores allowed in AUTOSAR!

44






45





AUTOSAR Basic Software (BSW)! Communication Stack! Memory Stack! ECU State Management! Complex Drivers! System Stack! I/O Stack

46





Memory Access - Example

47

void Write_Value() {

Std_ReturnType success;

… /* Write Value to Block */ …

success = Rte_Write_P_block_RAINDATA(55);

…

}

Test SW-C

RTE

NVRAM Manager





Memory Stack! Memory services:

"Abstract from location of memory devices

"Checksum protection and reliable storage

! Memory Abstraction Interface: Broker

48

RAM

ROM (default)

NVRAM+CRC

NVRAM+CRC

/* Memory Abstraction Interface */ Std_ReturnType MemIf_Write( uint8 DeviceIndex, uint16 BlockNumber, uint8* DataBufferPtr )

/* Flash EEPROM Abstraction */ Std_ReturnType Fee_Write( uint16 BlockNumber, uint8* DataBufferPtr )





Memory Interface! Example 1: Single non-volatile device employed

49

! Example 2: Multple device types employed

#define MemIf_Write (DeviceIndex, BlockNumber, DataBufferPtr) \

Fee_Write (BlockNumber, DataBufferPtr)

/* MemIf.h */ extern const WriteFctPtrType WriteFctPtr[2]; #define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) \ WriteFctPtr[DeviceIndex](BlockNumber, DataBufferPtr)

/* MemIf.c */ #include “Ea.h“ /* for getting the API function addresses */ #include “Fee.h“ /* for getting the API function addresses */ #include “MemIf.h“ /* for getting the WriteFctPtrType */ const WriteFctPtrType WriteFctPtr[2] = {Ea_Write, Fee_Write};






50





Conclusion! Reduction of software complexity due to standardization

"Costs"Time-to-market

! SW-C developers can concentrate on actual functionality"Model-driven approach"Faster development cycles

! Approved solutions for BSW and infrastructure"Code reusability"Reduce error-proneness

! Abstraction from Hardware facilitates portability! Easier software module exchange! Legacy software can be embedded in AUTOSAR

architecture51




autosar - department of computer science 4 at fau

Documents