hands-on workshop: autosar · autosar documents the sws(software specification) contains the most...

TMFreescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, mobileGT, PowerQUICC, StarCore, and Symphony are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack, CoreNet, the Energy Efficient Solutions logo, Flexis, MXC, Platform in a Package, Processor Expert, QorIQ, QUICC Engine, SMARTMOS, TurboLinkand VortiQa are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © 2010 Freescale Semiconductor, Inc.

FTF-AUT-F0764

Hands-on Workshop: AUTOSAR

June, 2010

Rebeca DelgadoFrancisco Ramirez

TM

2Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, mobileGT, PowerQUICC, StarCore, and Symphony are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack, CoreNet, the Energy Efficient Solutions logo, Flexis, MXC, Platform in a Package, Processor Expert, QorIQ, QUICC Engine, SMARTMOS, TurboLinkand VortiQa are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © 2010 Freescale Semiconductor, Inc.

AUTOSAR – An Industry Standard

2H 2005 1H 2006

2005 20062H 2006

Release 2.1

Improvements R2.1Specification R2.0

Phase I (2004 – 2006) Basic Software & RTE

Release 2.0

1H 2007 2H 2007 1H 2008 2H 2008 1H 2009

2007 2008 20092H 2009

Release 4.0

Improvements R4.0Specification R4.0

Specification R3.0

Concepts R4.0

Release 3.0

Phase II (2007 – 2009) Basic Software & RTE

Release 3.1

TM


AUTOSAR Integration Summary

Source:

Standardization

OSEK/VDX

MSRManufacturer-Supplier Relationship

Hersteller Initiative Software

ASAM ODX

HISFlexRay™ Protocol

Local Interconnect Network

Media OrientatedSystem Transport

TM


AUTOSAR Introduction: What is it?

TM


AUTOSAR Partnership Objectives

►(AUTomotive Open System ARchitecture)

►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►Improve quality and reliability of E/E systems ►Enable detection of errors in early design phases.

TM


Freescale Involvement in Industry Consortia

►Freescale, a reliable partner for automotive SW and HW innovation :

► Driving member of the OSEK/VDXTM consortium, with ownoperating system implementation

► Founding member of the LINTM consortium

► Founding member of FLEXRAYTM partnership

► First semiconductor vendor to join AUTOSARTM partnership

TM


Worldwide, OEMs and Suppliers Participate in AUTOSAR

Core Partners

Premium Members

Semi-conductors

Tier 1 StandardSoftware

Tools

AssociateMembers

CapeWare

OEM

Source: , actual status at http://www.AUTOSAR.org

TM


Microcontroller

Microcontroller Abstraction Layer

AUTOSAR Runtime Environment

ECU Abstraction Layer

AUTOSAR BSW Architecture—Basic Layers

Services Layer

Com

plex

Driv

er

Bas

ic S

oftw

are

Application LayerApplication

SoftwareComponent

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

TM


Microcontroller

AUTOSAR Runtime Environment (RTE)

AUTOSAR BSW Architecture—Sub-Layers

Com

plex

Driv

er

Bas

ic S

oftw

are

Application Layer

CommunicationServices

MemoryServices

SystemServices

Onboard DeviceAbstraction

Memory HardwareAbstraction

Communication HardwareAbstraction

Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers

I/O HardwareAbstraction

Ope

ratin

g Sy

stem

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

TM


Offering From Freescale is Based on AUTOSAR Basic Software

Microcontroller

AUTOSAR Runtime Environment (RTE)

Com

plex

Driv

er

Bas

ic S

oftw

are

Application Layer

CommunicationServices

MemoryServices

SystemServices

Onboard DeviceAbstraction


Communication HardwareAbstraction

Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers

I/O HardwareAbstraction

Ope

ratin

g Sy

stem

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

ApplicationSoftware

Component

► AUTOSAR software product packages from Freescale• MCAL• Operating System

TM


►Classes of Electrical Signals:

• Analog• Voltage• Current• Resistance

• Discrete• Diagnosis• Pulse-Width

AUTOSAR Signal Concept

TM


Microcontroller Hardware A

DC

DIO

Tim

er

I/O Drivers

PO

RT

Driv

er

AD

C D

river

DIO

Driv

er

PW

M D

river

ICU

Driv

er

PW

M

LIN

/ S

CI

CA

N

SP

I

Flas

h

WD

T

GP

T

Microcontroller Drivers Communication DriversMemory Drivers

CA

N D

river

Inte

rnal

Fla

sh D

river

Wat

chdo

g D

river

LIN

Driv

er

MC

U D

river

Flex

Ray

™D

river

GP

T D

river

SP

I Driv

er

MC

U

Pow

er &

C

lock

Uni

t

AUTOSAR MCAL Package

PO

RTS

Flex

Ray


Flash EEPROM Emulation

► All MCAL drivers (1) + Flash EEPROM Emulation► Delivered with AUTOSAR conformant configuration tool.

(1) V2.1 package does not contain RAM Test module

TM


AUTOSAR Documents

►Released AUTOSAR documents can be found on www.autosar.org►2 documents exist for each BSW module:

• SRS: Software requirement specification• SWS: Software Specification

► The SRS describes requirements, that must be fulfilled by a Basic Software Module (BSW). ► Chapters of SRS –documents

• Chapter 1 defines the area of application of the BSW• Chapter 2 defines the structure of the document• Chapter 3 defines the acronyms used in that document• Chapter 4 is the main chapter. • Contains a brief description of the BSW functional overview and continues with the

requirements.

http://www.autosar.org/

TM


AUTOSAR Documents

► The SWS(Software Specification) contains the most detailed information for each Basic Software Module

► Each SWS document is structured as follows:• Chapter 1 –introduction and brief overview of functional behavior of the BSW• Chapter 2 –used acronyms• Chapter 3 –referenced documents• Chapter 4 –restrictions and applicability for the automotive domain• Chapter 5 –relation to other BSW modules and the file structure of the BSW• Chapter 6 –requirement matrix containing links to requirements from the related SRS

document• Chapter 7 & 8 –contain the description of the:

functional behavior of the BSWapplications programming interface (API)

• Chapter 9 –Message sequence charts are used to describe the sequential behavior of a SWC in relation to other SWCs

• Chapter 10 –possibilities of configuration are defined• Chapter 11 –Release changes are documented

TM


BSW Configuration Classes

► Pre-compile configuration• Configuration parameters can not be changed after compilation• Example: Mapping of microcontroller pins to signals

► Link-time configuration• Configuration is determined by linker scripts• Configuration parameters can not be changed after link process• Purpose: provides capability to deliver object code to the integrator

► Post-build configuration• Post-build time loadable

Configuration parameters can be changed after build process without complete re-flash of ECU• Post-build time selectable

Configuration parameter set is selected from multiple configuration sets during boot timeAll possible configuration sets need to be included at compile time

• Configuration parameters are stored at a known memory location• Post-build configuration class BSW modules might also contain pre-compile or link-time

parameters (not all parameters have to be post-build)• Purpose: use one software package in different vehicles

TM


tresos Studio – Configuration Tool

TM


Main Window

Node Outline

Error & ProblemMessages

ParameterInformation

EditorProject Browser

Source: Elektrobit

TM


Errors & Warnings

Link toerror or warning

User corrects the problem

Interactive problem resolution

Source: Elektrobit

TM


Parameter Definition

Parameter "OsCounterType"

… and its corresponding entry in the description file (*.EPD)

Jump to link

Source: Elektrobit

TM


Parameter Description Files – EPD/EPC

Source: Elektrobit

EPD

EB tresos StudioConfigurator write

read

BSWModule

Description

EB tresos StudioGenerator

c, hwrite

read

c, htemplates

read

BSW Module Configuration

GeneratedCode

Code Templates

AUTOSAR Files

Elektrobit Files

Generated Files

Legend

read

EPC

TM


Parameter Description Files – XDM

Source: Elektrobit

XDM


read

BSWModule

Description


c, hwrite

read

c, htemplates

read


GeneratedCode

Code Templates

AUTOSAR Files

Elektrobit Files

Generated Files

Legend

read

EPD

convert

XDM

EPCimport/export

TM


XDM


arxml

SW-CDescription

arxml

import

read

BSWModule

Description

dbc,ldf,

fibex1)

LegacyDescription


c, hread

htmldocxml

Generated Documentation

(optional)

write

write

read

c, htemplates

read


GeneratedCode

Code Templates

read(RTE Generator only)

AUTOSAR Files

Elektrobit Files

Generated Files

Legend

read

System Description

read

EPD

convert

XDM

EPCimport/export

1) currently in development

Parameter Description Files – Beyond MCAL

Source: Elektrobit

TM


AUTOSAR Operating System

TM


AUTOSAR Operating System

► Configurable in AUTOSAR-conformant configuration tool

► Available in Scalability Classes 1, 2, 3, 4 to fit the needs of different applications

• SC1 – deterministic RTOS baseline (tasks, events, counters, alarms, messages)

• SC2 – timing based task determinism (low-latency, precise timing for periodic tasks)

• SC3 – protected memory (MMU/MPU) for tasks avoids memory collisions for safety systems

• SC4 – timing and memory protected tasks, utilizes the full capabilities of the silicon for secure and protected RTOS designed specifically for the automobile.

System Services

Com

mun

icat

ion

Man

ager

EC

U S

tate

Man

ager

Func

tion

Inhi

bitio

nM

anag

er

Wat

chdo

gM

anag

er

Dia

gnos

tic E

vent

Man

ager

Dia

gnos

tic E

rror

Trac

er

Ope

ratin

g S

yste

m

CRC Library

TM


AUTOSAR OS overview

►AUTOSAR OS is OSEK/VDX™ OS plus:

• New core featuresSoftware and hardware countersSchedule tables with time synchronisationStack monitoring

• Protection featuresTiming protection, memory protection and service protectionOS applications, trusted and non-trusted codeProtection hook

TM


OS Application and Trusted and Non-Trusted Code

►Integrity level: trusted and non-trusted code

►OS application • A block of software including tasks, ISRs, hooks and

trusted functions • Trusted: An OS application that has unrestricted

access • Non-trusted: An OS application that has restricted

access

►Trusted function• A service function with unrestricted access • Provided by a trusted OS application

TM


Usage of Memory Protection

►A Non-trusted OS application task• Can only access the memory it needs• Therefore not this OS application task is protected, but all other tasks

are protected from it

►Memory protection can be used, e.g.,• To separarate different applications on one MCU• For isolating controller functionality from independent sub-suppliers• To fulfill safety constraints • As a debug feature (faulty memory access is prevented, stack overflow

is prevented, protection hook is called)

►Memory protection MUST be supported by on-chip MPU

TM


Usage of Service Protection

►Service Protection• Protection against faulty/corrupted OS service calls by an OS

Application• Examples

OS Application calls ShutDownOS()OS Application tries to execute ActivateTask() on a task belonging to another OS Application

• Protection Hook is called upon detection of a service protection error

TM


Usage of Timing Protection & Global Time

►Timing Protection• Execution time enforcement

Bounds the execution of ISRs, resource locks and interrupt disabled sections at runtime to a statically configured value („time budget“)

• Arrival rate enforcementBounds the number of times that an ISR can execute in a given timeframe to a statically configured limit

• Protection Hook is called upon detection of a timing protection error

►Global Time / Synchronization Support• Requires a global time source, e.g. the FlexRay network time• This feature allows schedule tables to be synchronized with a global

time through special OS service calls

TM


Protection Hook

►The Protection Hook• Is called on all types of protection errors (memory / service / timing)• Defines the action by the return value:

Kill the faulty Task/Category 2 ISR, orKill the faulty OS application, orKill the faulty OS application and restart the OS application, orCall ShutdownOS()

TM


OSEK OS (all conformance classes)

Counter Interface

Schedule Tables

Stack Monitoring

Protection Hook

Timing Protection

Global Time/Synchronization Support

Memory Protection

OS Applications

Service Protection

CallTrustedFunction

Sca

labi

lity

Cla

ss 1

Sca

labi

lity

Cla

ss 2

Sca

labi

lity

Cla

ss 3

Sca

labi

lity

Cla

ss 4

AUTOSAR OS Scalability Classes 1–4

TM


Microcontroller Abstraction Layer

TM


AUTOSAR Layers

►Complex Device Driver• implements complex sensor evaluation and actuator control with direct access

to the μC using specific interrupts and/or complex μC peripherals (like TPU), examples:

• injection control• electric valve control• incremental position detection• System Basis Chips

TM


MCAL General AUTOSAR ConceptsRegister Initialization

TM


MCAL General AUTOSAR ConceptsInitialization Sequence

►[BSW12068]• The modules of the MCAL shall be initialized in the following sequence

disable global interruptsinitialize overall registers (MCAL system module)initialize all driversgobal interrupts may be enabled

TM


MCAL General AUTOSAR ConceptsReentrancy in most MCAL API functions

►Usually API function will reject a request for an active resource►thus, reentrancy is naturally given

TM


Freescale Implementation TopicsMCAL Delivery File Structure

X = Target (11 – Freescale S12X)Y = Derivate ( 3 – S12XEP100 )Z = Module Major VersionA = Module Minor VersionB = Reserved

package name schemadefined by Elektrobit

Module_TS_TxDyMzIaRb

TM


Freescale Implementation Topics3 Layer Architecture

►3 Layer Architecture• AUTOSAR API• LLD: low level, IP independent• IP dependent

Gpt_StartTimer(…)/* error reporting and detection */

TM


Port and Dio Modules

MCAL Training – MPC560xB

TM


MPC5604B (512K)

CROSSBAR SWITCH

48K SRAM

PowerPCTM

e200z0Core

VReg

Communications I/O System

Crossbar Slaves

Interrupt Controller

Crossbar Masters

Nexus 2+

JTAG

Debug

512KFlash

BootAssist

Module (BAM)

Oscillator

Memory Protection Unit (MPU)

System Integration

I/OBridge

3 FlexCAN

4LINFlex

1I2C

3 DSPI

FMPLL

CORE► PowerPC e200z0 core running 48-64MHz► VLE ISA instruction set for superior code density► Vectored interrupt controller► Memory Protection Unit with 8 regions, 32byte granularity

MEMORY► 512Kbyte embedded program Flash, 64KByte data flash► 64Kbyte embedded data Flash (for EE Emulation)► Up to 64MHz non-sequential access with 2WS► ECC-enabled array with error detect/correct► 48Kbyte SRAM (single cycle access, ECC-enabled)

COMMUNICATIONS► 3x enhanced FlexCAN

► 64 Message Buffers each, full CAN 2.0 spec► 4x LINFlex► 3x DSPI, 8-16 bits wide & chip selects► 1x I²C

ANALOG► 5V ADC 10-bit resolution

TIMED I/O► 16-bit eMIOS module

OTHERCTU (Cross Triggering Unit) to sync ADC with PWM Channels► Debug: Nexus 2+► I/O: 5V I/O, high flexibility with selecting GPIO functionality► Packages: 100LQFP, 144LQFP, 208MAPBGA (Development only)► Boot Assist Module for production and bench programming

PIT 4ch 32b

MCM

Power Mgt

Standby RAM

64K DataFlash

36 chADC10bit

eMIOSLite6ch IC/OC50ch PWM

CTU

TM


Port/Dio ModuleFunctional Overview

► Port• Initialization of all pins and ports of the Mcu• Reinitialization with alternate configurations at

runtime possible• Reconfiguration of pins at runtime• Port Pin Function Assignment (GPIO, Adc, SPI,

PWM, ...)PadSelection implicitly via HW assignment

• PortPin is the only structural element

► Dio• no initialization (done be Port)• provides APIs to read and write GPIO ports/pins• requires an initialized Port module

pins/ports need to be initialized via Port moduleno formal connection between Port and Dio Ecu Configurations

• API synchronous and unbuffered• consistent read and write services (interruptible read-

modify-write not allowed)• Structural Elements:

Channel (single pin)ChannelGroup (adjacent pins in the same port)Port (aggregates Channels and ChannelGroups)

TM


Port/Dio ModulesFreescale Implementation

Port Access:Port_Init(...)

Port_SetPinDirection(...)Port_RefreshPinDirection(...)

Port_SetPinMode(...)

Dio Read Accesses:Dio_ReadChannel

Dio_ReadPortDio_ReadChannelGroup

Dio Write Accesses:Dio_WriteChannel

Dio_WritePortDio_WriteChannelGroup

TM


Port ModulePin Configuration

SMC – Safe Mode ControlAPC – Analog Pad ControlPA – Output Pad AssignmentOBE – Output Buffer EnableIBE – Input Buffer EnableODE – Open Drain EnableSRC – Slew Rate ControlWPE – Weak Pull Up/Down EnableWPS – Weak Pull Up/Down Select

Pad Configuration Register PCR

TM


Port ModuleAPI Functions

void Port_Init(const Port_ConfigType *ConfigPtr

)

defined by AUTOSAR

►Initializes all Pins and Padselection Registers►Reconfiguration at runtime possible►Should be called also after reset

TM


ADC Module


TM


ADC – Functional OverviewChannel Concept

►Adc Channel• represents a ADC entity bound to one port pin. • multiple ADC entities can be mapped to the same port pin• consists of

Analog input pinADC circuitryconversion result register

• NO own RAM buffer►Adc Channel Group

• A group of Adc Channels linked to the same hardware unit• One common trigger source: hardware or software• Only groups can be triggered for convertion• Multiple channel assignments to groups are allowed• User must provide RAM buffers for the entire group• Adc driver module internally implements a state machine for each group

TM


ADC – Functional OverviewConversion

►Conversion Modes• One Shot

The conversion of an ADC channel group is performed once after a trigger and the result is written to the assigned buffer. A trigger can be a software API call or a hardware event.

• ContinousThe conversions of an ADC channel group are performed continuously after a software API call (start). The conversions themselves are running automatically (hardware/interrupt controlled). Continuous conversions can be stopped by a software API call (stop).

TM


ADC – Normal OperationRead Access modes

►AUTOSAR Channel Group Parameter AdcGroupAccessMode• ADC_ACCESS_MODE_SINGLE

Latest samples of all group channels are available in the RAM buffer• ADC_ACCESS_MODE_STREAMING

Latest n samples of all group channels are available in the RAM buffer

TM


ADC Normal OperationValue Access

Std_ReturnType Adc_ReadGroup(Adc_GroupType Group,Adc_ValueGroupType* DataBufferPtr

)

defined by AUTOSAR

►Reads the latest available conversion results into the given buffer►Raw values – no further scaling►...

TM


ADC – Channel Group State MachineOne Shot / Software Trigger / Single Access

TM


PWM Module


TM


PWM – Functional Overviewrequired by AUTOSAR

► Each PWM channel corresponds to a hardware PWM on the device

► Polarity• A parameter PwmPolarity specifies the pin output

level for each channel for dutycycle and off-dutycycle.

► PWM duty cycle scaling• resolution: 16bit• range: 0x0000 (0%) to 0x8000 (100%)• rationale: absolute duty cycle can be

efficiently computed:AbsoluteDutyCycle = ((uint32)AbsolutePeriodTime * RelativeDutyCycle) >> 15

► PWM Time Unit• Timing is adressed by Mcu and thus is subject to

the upper layer. Pwm expects all time values expressed in ticks.

► Type of PWM channel is implementation specific (e.g. center align, left align ...)

TM


PWM – Functional Overviewrequired by AUTOSAR

► Idle State: high or low; after init (configurable) or Pwm_SetOutputToIdle()► Initialization

• Pwm_Init(ConfigPtr)• after initialization, all pwm pins are set to the idle state

output is high, low according to PwmIdleStatesettings for period and duty cycle according to

– PwmPeriodDefault– PwmDutyCycleDefault

• No notifications occur until the first call of Pwm_EnableNotification• Must not be called during running operation

►De-Initialization• Pwm_DeInit()• all pins are reset to the default state (high, low, default period and duty cycle)

TM


API Functions

void Pwm_SetDutyCycle(Pwm_ChannelType ChannelNumber,uint16 DutyCycle

)

defined by AUTOSAR

►Sets the DutyCycle of a PwmChannel►Deviations from AUTOSAR:

• Effective always with the next cycle• PwmDutycycleUpdatedEndperiod without effect (usually this

precompile switch forces the dutycycle to be updated only at the end of the current period)

TM


PWMeMIOS Counter Busses and Unified Channels

► example for MPC5607B► Implementation available

for• OPWMB (Pulse width

modulation)• OPWMT (Pulse Width

Modulation with Trigger)• OPWMFB (Frequency

Modulation)► Hardwaremapping done

via Parameter PwmHwChannel

► All other channels cannot be selected in Tresos

► Counterbus generation via GPT, ICU or PWM module

TM


$000800

PWM – Freescale ImplementationOPWMB: Output Pulse Width Modulation Buffered

Generates a simple output PWM signal- Can use Internal or Modulus counter- EDPOL allows selection between active HIGH or active LOW duty cycle.

Notes:► Write UCA[n] (A1) with Leading Edge. Write UCB[n] (B1) with trailing edge► On Comparator A1 match, Output pin is set to value of EDPOL► On Comparator B1 match, Output pin is set to complement of EDPOL► The transfers from register B2[n] to B1[n] and from register A2[n] to A1[n] are performed at the first clock of the next cycle.► FLAGS can be generated only on B1 matches or on both A1 and B1 matches depending on MODE[5] bit.

$000800

B1 match B1 match

0x0010000x000800

0x000200

A1 match

$000200 $000400

update of A1 & B1

$000400$000400

A1 match

$000200

$000600

0x0006000x000400

$000600$000600

$000400

write into A2 & B2

$000600

Selected counter bus

$000800

$000200

$000200

B1 value

A1 value

A2 value

output flip-flopEDPOL=1

$000800B2 value

TM


PWM – Hardware ModesOPWMB: Output Pulse Width Modulation Buffered

►leading and trailing edge placement via parameter PwmOffset

►variable duty cycle►fixed period►Intented usage:

• in conjunction with other channels sharing the same timebase►Timebase: internal counter or one of EMIOS counterbusses

TM


GPT Module


TM


GPT ModuleFreescale Implementation Features

►Available Clock Modules• eMIOS (enhanced Modular IO Subsystem)• PIT (Periodic Interrupt Timer)• STM (System Timer Module)• RTC / API (Real Time Clock / Autonomous Periodic Interrupt)

►Clockmodule implicitly selectable via hardware assignement at configuration time for each channel

• Configuration Parameter GptHwChannel

TM


Gpt ModuleAUTOSAR Functional Overview

Structural Elements:►GptChannel

• Mapping to a Hardware Channel• Wakeup Source

Features:►Services to start and stop timers►Notification callbacks►oneshot mode / continous mode►wakeup from timer (sleep mode)►timeout limited to hardware counters

TM


Gpt ModuleAUTOSAR Functional Overview