Automotive SW Architecture: Engine Management Systems · Automotive SW Architecture: Engine...

ETR 13 École d'Été Temps Réel 2013

Automotive SW Architecture:

Engine Management Systems

28/08/2013

Denis Claraz – Continental Automotive France

[email protected]

1 / Denis Claraz / January, 28, 2013 © Continental Automotive SAS

Introduction : Plan of the presentation

1. Introduction / Context

2. Static architecture

3. Dynamic architecture

4. Coding

Automotive Systems Division Powertrain


4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion

Passenger and Light Truck Tires

OriginalEquipment

ReplacementEurope

Commercial Vehicle Tires

Truck Tires Europe

Truck TiresThe Americas

Rubber Group

ContiTech

Air Spring Systems

Benecke-Kaliko

Conveyor Belt

Divisions and Business Units

Continental Corporation

Chassis & Safety

ElectronicBrake Systems

HydraulicBrake Systems

Transmission

Hybrid Electric Vehicle

PowertrainInterior

Body & Security

Connectivity

Commercial

Continental Automotive

Employees Sales

148.000 26 bn €


Europe

ReplacementThe Americas

ReplacementAsia

Two-Wheel Tires

The Americas

Truck Tires Asia

Industrial Tires

Conveyor Belt

ElastomerCoatings

Fluid Technology

Power Transmission

Vibration Control

Other Operations

Brake Systems

Sensorics

Passive Safety& ADAS

Chassis Components

Sensors & Actuators

Engine Systems

Commercial Vehicles & Aftermarket

Instrumentation & Displays

Interior Modules

Multimedia

3 / Denis Claraz / June, 6th, 2013 © Continental Automotive SAS

Employees Sales

13.000 2.4 bn €

1.100 (SW)

Status: Nov. 2011

System overview

CompositeManifold

Mass Air FlowSensor with Integrated

Temp. Sensor

ExhaustTemperature

Sensor

Dual Cont. Var.Cam Phaser

ElectronicThrottle Control

Exhaust GasRecirculationValve (EGR)

Air Cleaner Box

3-Way Catalyst Lean NOx

Trap Catalyst

CamshaftPosition Sensor

ManifoldAbsolute Pressure

Sensor

Piezo DirectInjection Piezo

Injector

Ignition Coil


ActiveCarbonCanister

Canister PurgeSolenoid

Fuel Supply Unit High PressureFuel Pump with

Flow Control Valve

Fuel PressureSensor

NOx SensorLinear/BinaryO2 Sensor

Trap Catalyst

Active Crankshaft Position Sensor

Engine Coolant Temperature

Sensor

Knock Sensor

EngineControl Unit

High-end ECU:Up to 200 I/Os


Market Driver: Emissions standards / CO2 reduction

Euro 2

Euro 3

Diesel EnginesDiesel Engines

Euro 4

Tier 2 Bin 5 0.05

0.10

0.15

PM [g/km]

CO [g/km]

0.25 0.50 0.75

NOx[g/km]

7.50 5.00 2.50150

170

190

210

230

250

270

per k

ilom

eter

, nor

mal

ized

to N

ED

C

US-LDV

California-LDVCanada-LDV

EU

Japan

China

S. Korea

Australia


Sources: European Commission, EPA

HC [g/km] 1996: EURO 2

2000: EURO 32005: EURO 42009: EURO 52014: EURO 6

Euro 5

Euro 6

0.30

0.20

0.10

US 2025:107EU 2020: 95

Japan 2020: 105China 2020: 117

90

110

130

150

2000 2005 2010 2015 2020 2025

Gra

ms

CO

2pe

r kilo

met

er, n

orm

aliz

ed to

NE

DC


1 000

10 000

50

60

70

80

90

100

Average program size (kB)

Max program size (kB)

Average ECU price

ROM (kB)

1 000

10 000

50

60

70

80

90

100

Average program size (kB)

Max program size (kB)

Average ECU price

ROM (kB)1.0

0.9

0.8

0.7

0.6

0.5

Consequence : Evolution of complexity (Powertrain)

32 bit ControllerOSEK operating system

SULEV Emissions

Example High End Project :- OEM, 3rd party, competitors code- 900 system functions- 200 I/O- 250.000 lines of code

High End :x 10 / 7 years


10

100

89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 05 06

0

10

20

30

40

50

10

100

89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 05 06

0

10

20

30

40

50

0.4

0.3

0.2

0.1

0.0

TLEV EmissionsOBD-2 Diagnosis

C-Language

16 bit ControllerSequential Injection

Knock control

ULEV EmissionsElectronic throttle control

LEV EmissionsVariable valve timing

(Inlet and outlet)

SULEV Emissions

In average :x 10 / 10 years


Consequence: High Reuse orientation

Reuse by Reference (“SW Factory”) since 90’s

Generic teams develop generic reusable (& configurable) components

Project teams integrate generic components and configure them

Problem:

Compositionality & composability of Timing Constraints & Properties ?

How to ensure that a SW-C developed in a Generic Team works in a Specific Project?



Project?

Solution: Platform approach

Reference Architecture

Control of diversity

Standardized process, method, tools





4. Coding

1. Functionnal partitionning

2. Aggregate concept

3. Variability



4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion

Static Architecture : Functional Partitioning

Transverse

Functions

Vehicle

Powertrain

Vehicle Motion

Electric Drive Chassis

Engine - Gasoline or Diesel

Powertrain Management

System ManagerEngine Position &

SpeedAir

Exhaust

Gas

Common Functional Architecture Aggregate Groups

Vehicle

Powertrain

Engine


Transmission

Electric

Power

Body & interior

Basic

ECU

Functions

Communi-cationEngine States FuelEngine Cooling &

Lubrication

Torque Ignition (Gasoline)

Speed Gas

Combustion

Process

Group


Static Architecture : Functional Partitioning

Functional architecture plugged on layered architectureCommon Functional Architecture Aggregate Groups

IntakeIntakeIntakeIntake systemsystemsystemsystem

Air Air Air Air temperaturetemperaturetemperaturetemperature

ChargerChargerChargerCharger

ThrottleThrottleThrottleThrottle

Variable Valve TimingVariable Valve TimingVariable Valve TimingVariable Valve Timing

Variable Valve LiftVariable Valve LiftVariable Valve LiftVariable Valve Lift

Air motion controlAir motion controlAir motion controlAir motion control

ExhaustExhaustExhaustExhaust gasgasgasgas compositioncompositioncompositioncomposition

Lambda controlLambda controlLambda controlLambda control

ExhaustExhaustExhaustExhaust gasgasgasgas treatmenttreatmenttreatmenttreatment

ExhaustExhaustExhaustExhaust gasgasgasgas pressurepressurepressurepressure

ExhaustExhaustExhaustExhaust systsystsystsyst. . . . temptemptemptemp. . . . detdetdetdet. . . .

ExhaustExhaustExhaustExhaust systsystsystsyst. . . . temptemptemptemp. ctrl. ctrl. ctrl. ctrl

CrankshaftCrankshaftCrankshaftCrankshaft starter starter starter starter generatorgeneratorgeneratorgenerator

SteeringSteeringSteeringSteering systemsystemsystemsystem

BrakingBrakingBrakingBraking systemsystemsystemsystem

Suspension systemSuspension systemSuspension systemSuspension system

ErrorErrorErrorError managementmanagementmanagementmanagement

FunctionFunctionFunctionFunction managementmanagementmanagementmanagement

Vehicle

Powertrain

Engine - Gasoline or Diesel

Transverse

FunctionsDriver request Vehicle motion determination Vehicle speed control Vehcle speed limitation Vehicle stability and traction

IntegratedIntegratedIntegratedIntegrated powertrainpowertrainpowertrainpowertrain managementmanagementmanagementmanagement

EngineEngineEngineEngine pos. & speedpos. & speedpos. & speedpos. & speed

EngineEngineEngineEngine speed controlspeed controlspeed controlspeed control

EngineEngineEngineEngine speed limitationspeed limitationspeed limitationspeed limitation

Application SW (control)

Library

Transverse functions

Vehicle control block

Powertrain control block

Engine control blockTransmissioncontrol block

OSEK OSCC block

OSEK COM/NM

Proc. Mon L3

NVMY

S & C Reprog

KWP

Vehicle

Powertrain

Engine


EngineEngineEngineEngine operating stateoperating stateoperating stateoperating state

EngineEngineEngineEngine startstartstartstart and stopand stopand stopand stop

Combustion modesCombustion modesCombustion modesCombustion modes

Lambda Lambda Lambda Lambda setpointsetpointsetpointsetpoint

Fuel Fuel Fuel Fuel supplysupplysupplysupply

Fuel mass Fuel mass Fuel mass Fuel mass setpointsetpointsetpointsetpoint

Injection Injection Injection Injection realisationrealisationrealisationrealisation

CylinderCylinderCylinderCylinder balancingbalancingbalancingbalancing

Air/fuel Air/fuel Air/fuel Air/fuel pathpathpathpath monitoringmonitoringmonitoringmonitoring

Fuel tank Fuel tank Fuel tank Fuel tank levellevellevellevel

EvapEvapEvapEvap. system control. system control. system control. system control

EvapEvapEvapEvap. system monitoring. system monitoring. system monitoring. system monitoring

Alternative fuelAlternative fuelAlternative fuelAlternative fuel

EngineEngineEngineEngine temperaturetemperaturetemperaturetemperature

EngineEngineEngineEngine lubrificationlubrificationlubrificationlubrificationPower Power Power Power supplysupplysupplysupply

DriveabilityDriveabilityDriveabilityDriveability

Torque Torque Torque Torque setpointsetpointsetpointsetpoint

TqTqTqTq determinationdeterminationdeterminationdetermination & real.& real.& real.& real.

Torque Torque Torque Torque losseslosseslosseslosses

Ignition angle Ignition angle Ignition angle Ignition angle setpointsetpointsetpointsetpoint

Ignition Ignition Ignition Ignition realisationrealisationrealisationrealisation

Car bodyCar bodyCar bodyCar body

ImmobilizerImmobilizerImmobilizerImmobilizer

HeatingHeatingHeatingHeating, , , , VentilVentilVentilVentil . & air . & air . & air . & air condcondcondcond....

PassengerPassengerPassengerPassenger protectionprotectionprotectionprotection

ECU proc. monitoring L2ECU proc. monitoring L2ECU proc. monitoring L2ECU proc. monitoring L2

ECU proc. monitoring L3ECU proc. monitoring L3ECU proc. monitoring L3ECU proc. monitoring L3

Air motion controlAir motion controlAir motion controlAir motion control

ExhaustExhaustExhaustExhaust GasGasGasGas RecircRecircRecircRecirc....

CamlessCamlessCamlessCamless valvetrainvalvetrainvalvetrainvalvetrain

ExhaustExhaustExhaustExhaust systsystsystsyst. . . . temptemptemptemp. ctrl. ctrl. ctrl. ctrl

SecondarySecondarySecondarySecondary airairairair

TransmissionTransmissionTransmissionTransmission

PassengerPassengerPassengerPassenger info. & com.info. & com.info. & com.info. & com.

KnockKnockKnockKnock

MisfiringMisfiringMisfiringMisfiring monitoringmonitoringmonitoringmonitoring

CylCylCylCyl. . . . temptemptemptemp. & pressure. & pressure. & pressure. & pressure

Eng. Eng. Eng. Eng. roughnessroughnessroughnessroughness determdetermdetermdeterm....

Eng. Eng. Eng. Eng. roughnessroughnessroughnessroughness controlcontrolcontrolcontrol

Infrastructure SW

Library

Transverse functions

Vehicle control block

UDS

LIN

CCP tun./flash.

XCP

SA

DIP

DO

P

AD

C

DC

M

PIM

PW

M

AS

Y

SP

I

MC

C

CA

N

RA

M

FLS

INT

SIG

TIM

WD

T

PC

S

DB

G

SS

T

IC Handler driver block

Engine P

osition

Ignition

Injection

Knock W

indow

Specializeddriver block

...

IO Platform driver block

TA

TIC

21

TA

TIC

29

TA

TIC

71

TA

TIC

35

...

TA

TIC

39

TA

TIC

42

TA

TIC

63

Group

Aggregate


CompositeManifold

Software overview

Mass Air FlowSensor with Integrated

Temp. Sensor

ExhaustTemperature

Sensor

Dual Cont. Var.Cam Phaser

ElectronicThrottle Control

Exhaust GasRecirculationValve (EGR)

Air Cleaner Box

3-Way Catalyst Lean NOx

Trap Catalyst

CamshaftPosition Sensor

ManifoldAbsolute Pressure

Sensor

Piezo DirectInjection Piezo

Injector

Ignition Coil

Engine position & speed:150 SW-modules

10.000 eloc


High-end ECU:Up to 200 I/OsActive

CarbonCanister

Canister PurgeSolenoid

Fuel Supply Unit High PressureFuel Pump with

Flow Control Valve

Fuel PressureSensor

NOx SensorLinear/BinaryO2 Sensor

Trap Catalyst

Active Crankshaft Position Sensor

Engine Coolant Temperature

Sensor

Knock Sensor

EngineControl Unit


80 Aggregates2.000 ASW SW-C





4. Coding



3. Variability



4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion

Static Architecture : Aggregate Process

The development of an Aggregate follows a defined & formalized process, with planning, milestones, reviews, delivery …

KickKickKickKick----OffOffOffOff ReleaseReleaseReleaseRelease

Architecture

Review

Release Release Release Release 100100100100 P730010


KickKickKickKick----OffOffOffOff-Technical goal

-Economical goal

-Planning

-Resources

-Team

-Pilot project

-...

ReleaseReleaseReleaseRelease

NoteNoteNoteNote-Contents

-Validation status

-Issues

-References

-...

Specification

Review

Software

Release

Software Implementation

SWSYST

6 month for Mainstream, less for Function sample


Static Architecture : Aggregate Process

All facets included in the Aggregate

Function Description

Software Requirement Specification

Supported System Electronics Interface

Software Design

Specification, Code, Validation

SW expertiseEngine function expertise


AggregateAggregateAggregateAggregate

InformationInformationInformationInformation

managed as managed as managed as managed as

one Packageone Packageone Packageone Package

Supported System

Configurations

Calibration Hints

Default Calibration

Simulation Models

Control & Plant

Validation Report

Design Reviews

Component

Specification

Electronics Interface

Specification

HW expertise

Components expertise

Engine function expertiseEngine tuning expertise

Engine function expertise

Engine function expertise






4. Coding



3. Variability



4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion





4. Coding

1. Context / Link vs. Static

2. Scheduling strategy



4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion

3. Integration / Sequencing

4. Data consistency

Context : Mixture of Time and Angle domains

Number of

Cylinders

Recurrence of Top Dead Center

@ 500 rpm @ 6000 rpm

6 40 ms 3.3 ms

CAM CAM CAM

50 60 7061 80TDC 3TDC 2

CRK

GAP

TDCTDC

Angular Events

1 ms

5 ms

10 ms

40 ms

1000 ms

100 ms

Time based Events

2 architectures in one CPU /

one OS


TDC 5 ms 10 ms 1000 ms100 ms

60 %

50 %

40 %

30 %

20 %

10 %

0 %

% of ROM size

Pro

ject

A

Pro

ject

B

Pro

ject

C

Pro

ject

D

80% of SW every 10ms

Angular Events


Project A

Optimized design : Limited HW resources

100ms 1 sectdc

var = interpolation ( n , maf ) x interpolation ( tco , t_ast ) x interpolation (tia)


Dynamic architecture impacted by Core Resources opt imization

CPU Load at 6000 rpm :

Complete calculation at tdc : cpu load = 0,12 %Calculation split between tdc, 100ms, 1s :cpu load = 0,06 %


Optimized coding: Limited HW resources"Good" example

/* O2 sensor diagnosis conditions */if ( n_32 < c_n_max_vls&& maf_kgh < c_maf_kgh_max_vls&& vs < c_vs_max_vls&& maf < c_maf_max_vls&& lv_ls_up_diag&& !LV_CDN_INH_DIAG_VLS_UP && !lv_end_ls_up_diag&& lv_thd_vls_ast&& lv_lscl_cor&& lv_tco_min_cat&& maf > c_maf_min_vls&& n_32 > c_n_min_vls&& maf_kgh > c_maf_kgh_min_vls

"Bad" example

/* O2 sensor diagnosis conditions */if ( lv_ls_up_diag&& !LV_CDN_INH_DIAG_VLS_UP && !lv_end_ls_up_diag&& lv_thd_vls_ast&& lv_lscl_cor&& lv_tco_min_cat&& maf < c_maf_max_vls&& maf > c_maf_min_vls&& n_32 < c_n_max_vls&& n_32 > c_n_min_vls&& maf_kgh > c_maf_kgh_min_vls&& maf_kgh < c_maf_kgh_max_vls&& maf_kgh_mmv_dif < c_maf_max_dif_vls

"Bad" example

/* O2 sensor diagnosis conditions */if ( lv_ls_up_diag&& !LV_CDN_INH_DIAG_VLS_UP && !lv_end_ls_up_diag&& lv_thd_vls_ast&& lv_lscl_cor&& lv_tco_min_cat&& maf < c_maf_max_vls&& maf > c_maf_min_vls&& n_32 < c_n_max_vls&& n_32 > c_n_min_vls&& maf_kgh > c_maf_kgh_min_vls&& maf_kgh < c_maf_kgh_max_vls&& maf_kgh_mmv_dif < c_maf_max_dif_vls


&& maf_kgh > c_maf_kgh_min_vls&& maf_kgh_mmv_dif < c_maf_max_dif_vls&& vs > c_vs_min_vls&& amp >= c_max_dep_vls&& cppwm_cps < c_cppwm_cps_max_ofs&& lv_up_lsh&& ... )

&& maf_kgh_mmv_dif < c_maf_max_dif_vls&& vs > c_vs_min_vls&& vs < c_vs_max_vls&& amp >= c_max_dep_vls&& cppwm_cps < c_cppwm_cps_max_ofs&& lv_up_lsh&& ... )

&& maf_kgh_mmv_dif < c_maf_max_dif_vls&& vs > c_vs_min_vls&& vs < c_vs_max_vls&& amp >= c_max_dep_vls&& cppwm_cps < c_cppwm_cps_max_ofs&& lv_up_lsh&& ... )

Readability of the spec : the tests are grouped

Order of test may be different than spec, to realize directly the condition






4. Coding





4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion


4. Data consistency

Non preemptiveHigh priority task waits until end

of current task

Low priority Task

H Task

H Task activation

High Priority Task waiting

CooperativeHigh priority task interrupts current task at pre-defined

schedule points (every x µs)

Schedule points

H Task

PreemptiveHigh priority task interrupts

current task at any time before end

Low prio. Task suspended

H Task

Large Large Resource

M

H

LScheduling strategy


Large Response Time

Consumption

✪ Controlled Response Time✪ Minimized Resource Consumption

✪ Data Consistency for free✬ Increased Maintenance Effort


Scheduling strategyDeadline defines the scheduling strategy

OSEK is a fixed priority based scheduler: If more than one task is ready to execute, then the task with the highest priority is chosen (+ FIFO)

Priorities fixed at design time according to Deadline monotonic scheduling (DMS)Tasks with shorter deadline have a higher priority

To save resources, tasks with similar deadline get same priority

Priority Deadline < 100 µsActivation


CooperativeEnvironment

Preemption

Interrupts

Background

Priority

Task

s

Deadline < 100 µs

Deadline > 1 s

Activation

readysuspended

Delay

suspended

Response time

Deadline

Task Arunning


Scheduling of EMS Applications on Multi-Cores Practical example for Scheduling: Simulation of Tas k Sets

1 • Differentiation of

calculations to deadlines

2• Priorities corresponding

to deadlines (DMS)

• Schedule points for a 11

12

13

14

15

16

17

18

19

20

21

22

23

response time min

response time avg

Response Time / Deadline

Continental AG

23 / Automotive Summerschool 2012/ Ralph Mader / 20. Sept. 2012 © Continental AG

3• Schedule points for a

defined blocking time

4• Preemption for tasks

with short deadline

0

1

2

3

4

5

6

7

8

9

10

11

Example 0 Example 1 Example 2 Example 3 Example 4

response time avg

response time max

Task Details

Activation Pattern Describes the activation pattern (periodic/aperiodic/sporadic …)

Activation condition(s) Describes necessary conditions for task activation (e.g. engine must be running)

Activated by The module / aggregate that activates the task (if there is one)

Fastest Recurrence Fastest recurrence

Phasing Phasing to other tasks (if any)

Deadline Deadline of this task (if any)

Impact of DL miss Impact if the deadline is missed (e.g. degradation of quality, fatal)


Impact of DL miss Impact if the deadline is missed (e.g. degradation of quality, fatal)

Priority Recommendation for the priority

Multi-Activation Recommended value for multi-activation

Preempt/Cooperative Either P for preemptive or C for cooperative task

Expected Runtime Runtime: expected / max allowed (if known)

Data / Coupling Data exchange / coupling with other tasks (if known)

File File that contains the task body


Offsets bewteen Tasks (load balancing)

In order to avoid load peaks, the time bases are not activated synchronously

5 ms

10 ms

20 ms


5 5 5

+ 20

+ 20

+ 20

5+

100

5 5 5 5 5 5

+ 10

+ 10

+ 10

+ 10

+ 10

+ 10

5 5

+ 40

+ 40

40 ms

100 ms

+ 1000

1000 ms

5


Verification of Scheduling: Missed deadlines

Schedulability analysis

In-situ measurements


Simulation

Response Time/Deadline

0%

20%

40%

60%

80%

100%

CA

M

T0_

10M

S

TD

C

T1_

10M

S

GAP

T2_

10M

S

T1_

5MS

T1_

40M

S

T1_

100M

S

T2_

100M

S

T1_

1000

MS

Dea

dlin

e =

20m

sIn-situ measurements

(instrumentation)






4. Coding





4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion


4. Data consistency

Sequencing / Data life cycle: The real life

Control of Dataflow

Multi-project approach

High number of Runnables


Project 3

Project 2

Project 1

High number of Runnables

0

100

200

300

400

500

600

700

1 2 5 10 20 40 100

200

500

1000

cam crk

knk

seg

Tas

k1

Tas

k2

Tas

k3

Tas

k4

Tas

k5

Tas

k6

Tas

k7

Tas

k8

Tas

k9

Tas

k10

Tas

k11

Tas

k12

Tas

k13

Tas

k14


Sequencing: The solutionPowerSAR Dynamic Architecture

Sort Functions by Alphabetical Order ?

Or by Specification Chapters Order?

Proprietary and confidential. Distribution only by express authority of Continental AG or its subsidiaries.

Calculations for other tasksPre-calculations

&acquisitions

Transitions detection(ecu/engstate/...)

Most criticalactuator outputs

Pre-calculations&

acquisitions

Part B Part CPart AT A S K _ E1 _ S E G

Or following Dynamic Architecture recommendation?

… The answer is … the Phase concept:

29 EMS2-MCR / D.Claraz / May 9th, 2013 © Continental Automotive SAS

Sequencing: Phase ConceptPowerSAR Dynamic Architecture

Detection of System Transition

System transitions detected as soon as possible so that nominal computations benefit from the initialization

Execution sequence

Phases = “Dynamic partitioning”:- Function development: Definition of the Phase of Runnables- Integration: Runnables plugged into the defined Phase- Phases order fixed, standard across SystemEvents & Projects

Acquisitions & related DIagnoses

Acquisitions (& diagnosis) done asap, to get the results for the complete Event.


Data Processing for Next cycle

Data needed for next occurence, or for other Events have no « internal deadline » and are located here. So, they will be displayed with oneoccurence delay.

SYstemVariables computation

System variables are based on ECU inputs, and are used in a high number of functions

Calculation of Basic Setpoints

Basic setpoints are based on system variables and requests

Realisation Of Setpoints

BSW is informed about new ASW data. Basically, piloting of the HW is done here.






4. Coding





4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion


4. Data consistency

Context: Coupling

EGPR

EGCP

LASP

EGTR

EXTC

EXTD

AIRM

ENOS

AIRT

FUSL

IGSP

VVTI

FCTMENTE INSY

SW Components

control


LACO

CHRG

FMSP

INJR

TQDR

TQLO

MISF

ENRD

ERRMIGRE THRO

ECM3

ECM2

ENSD

ECME

KNCK

control

System Components


Data consistency

Active Step Reg. Mem Active Step Reg. Mem Active Step Reg. Mem

counter++;

Low priority task T1

load register from @counterinc registerstore register to @counter

in pseudo assembler:counter++;

High priority preemptive task T2

load register from @counterinc registerstore register to @counter

in pseudo assembler:

Example 1: Counter increment in 2 tasks

32

1


Active Step Reg. Mem.

T1 ... ... ...

T1 Load x→5 5

T1 Inc 5→6 5

T1 Store 6 5→6

T2 Load x→6 6

T2 Inc 6→7 6

T2 Store 7 6→7

Final Result 7


T1 ... ... ...

T2 Load x→5 5

T2 Inc 5→6 5

T2 Store 6 5→6

T1 Load x→6 6

T1 Inc 6→7 6

T1 Store 7 6→7

Final Result 7


T1 ... ... ...

T1 Load x→5 5

T2 Load x→5 5

T2 Inc 5→6 5

T2 Store 6 5→6

T1 Inc 5→6 6

T1 Store 6 6→6

Final Result 6


Data consistency

Example 2: Copying 64 bit data on a 32 bit controller

u64 a;...a = AAAAAAAABBBBBBBBU;...

Low priority task T1

a = 1111111122222222U;

High priority preemptive task T2

Active Step Register a

T1 ... ...

T1 Load upper AAAAAAAA xxxxxxxxxxxxxxxx

Active Step Register a

T1 ... ...




T1 Store upper AAAAAAAA AAAAAAAAxxxxxxxx

T2 Load upper 11111111 AAAAAAAAxxxxxxxx

T2 Store upper 11111111 11111111xxxxxxxx

T2 Load lower 22222222 11111111xxxxxxxx

T2 Store lower 22222222 1111111122222222

T1 Load lower BBBBBBBB 1111111122222222

T1 Store lower BBBBBBBB 11111111BBBBBBBB


T1 Store upper AAAAAAAA AAAAAAAAxxxxxxxx

T1 Load lower BBBBBBBB AAAAAAAAxxxxxxxx

T1 Store lower BBBBBBBB AAAAAAAABBBBBBBB


Data consistency

Example 3: Calculation of average acquisition with reset

/* Calculate the average */if (Counter != 0){average = Sum/Counter;

}/* Reset Sum and Counter */Sum = 0;

Low priority Task T1

Sum += new_acquisition;Counter++;

High priority preemptive Task T2

3

2

1


Counter = 0;

1. Wrong average: Sum new, Counter old (Counter loaded once in register, reused twice)

2. Average ok, but one acquisition of Sum and Counter is lost

3. Wrong next average: Sum incremented, but one Counter is missing






4. Coding



4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion

Why C Coding rules (1)

for(u8_least i=0;i<10;i++) x[i]=(i==0?0:i<=2?1:((i-1)%2?-1:1)+x[i-1]*x[i-1])/x[i-2];

/* write the first 10 Fibonacci numbers into x[] */

/* write the first 10 Fibonacci numbers into x[] *//* �� x = {0, 1, 1, 2, 3, 5, 8, 13, 21, 34} */

Need for correct, readable, and

understandablecode

Embedded


u8_least i;

...

for(i = 0; i < 10; i++){

if (i<2)

x[i] = i;

else

x[i] = x[i-1] + x[i-2];

}

Embedded Systems:

=> The generatedASM code matters !!



near u16 *ptr1;

far u16 *ptr2;

…

u16 *ptr1;

if (lv_a == true)

{

lv_b = (c != 5);

lv_c = false;

}

...

if ( lv_a )

ISO-C Compatibility and plaform independance to be

ensured


u16 *ptr1;

u16 *ptr2;

…

near/far not defined by ISO

"true" not defined by ISO

if ( lv_a )

{

lv_b = (c != 5);

lv_c = 0;

}

...

ensured



s16 x = -32000;u16 y = 2;if ((x / y) < 0)

…

x / y = 16768 on 16 bit systems

s32 x = -32768;s32 y = -0x8000;

if ( x == y ){

a = 1;}else{

if ( -x == y ){

a = 2;

s32 y = -(s32)0x8000U;correct

Portability between different targets to be

ensured


s16 x = -32000;

u16 y = 2;if ((x / (s16)y) < 0)

…

on 16 bit systems

-32000 ≡ 1000 0011 0000 0000x is promoted to u16→ 1000 0011 0000 0000 ≡ 33536→ 33536 / 2 = 16768

a = 1, if 32 Bit platforma = 2, if 16 Bit platform

What is the value of 'a'

What is the value of 'x / y'

a = 2;}else

{a = 3;

}}

ensured



u8 div(u8 val, u8 idx){

return val / a[idx];}

u8 div(u8 val, u8 idx)

{u8 tmp;if (idx < NC_MAX) {

c = 5;...if (c = 4) ...

Good:

c = 5;...

Safe and robust code to be ensured


{if (a[idx] > 0)

return val / a[idx];}

/* division by 0 or index out of range */

return val;}

...if (c == 4)...

Better:c = 5;...if (4 == c)...

ensured


C Coding Rules Basis

The C Coding Rules are based on

ANSI Standard

ISO/IEC 9899:1990 Standard � exceptions are inline functions (based on

ISO/IEC 9899:1999 Standard) and inline "asm"


MISRA-C:2004(Motor Industry Software Reliability Association)

HIS Subset of MISRA (based on MISRA-C 1.0)

AUTOSAR C Implementation Rules


Floating Point: IEEE

The IEEE has standardized the computer representation for binaryfloating-point numbers in IEEE 754.

This standard provides two basic formats –

Single Precision Double Precision


C language : 'float'. C language : 'double'.

Size : 32 bits. Size : 64 bits.

significand (fraction / mantissa) precision of 24 bits (i.e. about 7.22 decimal precision).

significand precision of 53 bits (i.e. about 15.99 decimal precision).


Floating Point: IEEE 754 Format

Single Precision Data (32 bit) Format:

Bit representation of floating point constant in IEEE 754 format

Ex: +10.0 (dec) => +1010.0 (bin) => +1.01 * 23

mantissasign


(-1)sign* 2(exponent – bias)

* (1 + mantissa * 2-23)

(-1)0* 2(130 – 127)

* (1 + 221* 2-23) = 23

* (1 + 2-2) = 8.0 * 1.25 = 10.0f

0 1 01 0 0 0 0 0 0 0 0 01 0 0 0 0 0 0000000000000

exponent

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

1 2 3 4 5 6 7 8


Rounding Errors in Basic Operations

E = (A + B) * (C + D)

F = (A * C) + (A * D) + (B * C) + (B * D)

Where A = 1.1, B = 2.2, C = 3.3, D = 4.4 and

Expected Result is 25.41

IF (E == F) THEN

E equals F

ELSE

E not equal to F

ENDIF

Floating Point: Rounding errors (1)


Obtained Result: 25.4100018 ≠ 25.4099998

Rounding errors during the calculation of the two values being compared.

if (|E-F| < min) better than if (E == F)

Order of evaluation can affect the result.


Adding / Subtracting Values with very Different Mag nitudes

−−

+×

−+

+a

aa

aa

aa

a1111

Floating Point: Rounding errors (2)

= 2a x 2/a

= 4


= 4






4. Coding

1. Motivation / Constraints

2. Elements of solution



4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion

Multi Core SW Architecture MCSAWhy Multi Core

Helps to Resolve Contradicting Requirements

Increasing performance requirements ⇒ classical approach: operating frequency increase

Reduction of power dissipation Pd⇒ classical approach: operating frequency reduction

MultiCore is the new Market Standard


/ R. Mader / 11. Dec. 2012 © Continental AG

10 20 2540

64 180 300

0,0

0,5

1,0

1,5

2,0

2,5

0

50

100

150

200

250

300

1985 1996 2001 2002 2006 20122010

150

2005

Pd_max/Pd

Fcpu / MHz

Crossbar

Core 0 + local RAM

Core 1 + Local RAM

Crossbar

Core 0 + local RAM

Peripherals

Core 1 + local RAM

System RAM

Core 2 + local RAM

Program Flash

Different performance needs

for different application classes require a flexible

Scheduling of EMS Applications on Multi-Cores Scalability of Cores*

Continental AG


Crossbar

Core 0 + local RAM

Peripherals

Program Flash

Single Core

Peripherals

System RAM

Program Flash

Dual Core

Multi Core

*Only cores relevant for running EMS software independently are shown

require a flexible approach in the

controller architecture

●Function calls from one core to another

Synchronous callsAsynchronous calls

●Runnables which are today called in a sequence may run in future in parallel

Low priority tasks can “overtake” high prior on the other coreData consistency issues, update of global data by different producersConcurrent access Spin lock, Wait states, Synchronizations

Multi Core SW Architecture MCSA Technical challenges for Multi Core Software

Continental AG

49 / EMS2-MCR Presentation GSE-Tech / D. Claraz / 31. January 2013 © Continental Automotive SAS

● How to allocate runnables to cores in an efficient way

According to the static software architecture (by SWCs)According to the dynamic software architecture (by Tasks/Processes/Runnables)

● What’s the right approach to distribute the runnables

Statically at software compile timeDynamically at software execution time

● How to prepare existing legacy software (EMS2 ) to be MultiCore Ready





4. Coding

1. Motivation / Constraints

2. Elements of solution

Continental AG

50 / EMS2-MCR Presentation GSE-Tech / D. Claraz / 31. January 2013 © Continental Automotive SAS50 / Denis Claraz / January, 28, 2013 © Continental Automotive SAS

4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion

Scheduling of EMS Applications on Multi-Cores ASW Partitioning

Static Architecture isbased on functional groupingbased on diversity managementbased on data flow encapsulationdesigned on specification levelstarting point for reuse and maintenance

Engine Speed

ENSD Seg

Fuel MassSet point

FMSP SEG

FMSP 10ms

Ignition

IGRE SEG

IGRE 100ms

Injection

INJR SEG

INJR 10ms

INJR 100ms

Intake Model

INSY SEG

INSY 10ms

INSY 100ms

Continental AG


Dynamic Architecture isbased on sequential and priority groupingbased on efficiencybased on robustnesspackaged into OS tasks

ENSD SEG

INSY SEG

FMSP SEG

INJR SEG

IGRE SEG

INSY 10ms

FMSP 10ms

INJR 10ms

INJR 100ms

IGRE 100ms

INSY 100ms …


Core 1Engine Speed

ENSD Seg

Ignition

IGRE SEG

IGRE 100ms

Intake Model

INSY SEG

INSY 10ms

INSY 100ms

Runnable assignment according to Static Architecture

ENSD SEG

INSY SEG

Send Data

Receive Data

IGRE SEG

INSY 10ms …

IGRE 100ms

INSY 100ms …

Calculation sequences

will be broken

Continental AG


Core 2 Fuel MassSet point

FMSP SEG

FMSP 10ms

Injection

INJR SEG

INJR 10ms

INJR 100ms Receive

DataFMSP SEG

INJR SEG

Send Data

FMSP 10ms

INJR 10ms …

INJR 100ms …

Increased communication overhead and possibilities for spin locks are

added


Core 1

ENSD SEG

INSY SEG

FMSP SEG

INJR SEG

IGRE SEG

Runnable assignment according to Dynamic ArchitectureCalculation sequences mostly kept

Continental AG


Core 2

INSY 10ms

FMSP 10ms

INJR 10ms

INJR 100ms

IGRE 100ms

INSY 100ms …

Communication mostly

necessary at task end

Communication during parralel

execution ?

Data Consistency: Single Core Design Patterns not a pplicable !!

Exemple Copy-Until-Consistent (CuC)



Protected(mostly)

What’s that ?





4. Coding



4. Coding

5. Multi-Core

6. AUTOSAR

7. Conclusion

Conclusion (1/2)

High coupling: ES functions control the same physical process

High reuse orientation @ ES: Maybe sometimes too far…

Component Based Development: Projects integrate configurable solutions

Cooperative Scheduling: Trade-off Response Time/Resource consumption/Consistency

Sequence and Consistency key issues: Dependence of Runnables, Independence of Tasks


Sequence and Consistency key issues: Dependence of Runnables, Independence of Tasks

Architecture standardization: Functions designed to fit into Platform Tasks

Use of DMS: Difficulty to evaluate deadlines (cultural problem, robustness margin, …)

Verification of Architecture by static or in-situ measurements, simulation


Conclusion (2/2)

Future challenges:

More openness of Platform (box business)

Multicore

AUTOSAR compatibility (efficiency, support of basic concepts, independence)

Process efficient development & integration


Process efficient development & integration


Automotive SW Architecture: Engine Management Systems · Automotive SW Architecture: Engine...

Documents

Transcript of Automotive SW Architecture: Engine Management Systems · Automotive SW Architecture: Engine...