Part

1: In-Car Networking

ELECTRONIC CONTROL UNITS (ECUS)

[C2X] Summer 2014

Electronic Control Units (ECUs)

Electronic Control Units (ECUs)

!

Current middle and upper class vehicles carry 80 .. 100 networked

Electronic Control Units (ECUs)

Image: Mitsubishi Electric

[C2X] Summer 2014

Electronic Control Units (ECUs)

Architecture
Communication, Diagnosis

Transceiver

Sensor
Drivers

ECU
Core
( next slide)

Power
Supply

Actor
Drivers

Actors

Sensors

ECU

Images: Mitsubishi Electric

[C2X] Summer 2014

Electronic Control Units (ECUs)

Architecture

ECU Core
Personal Computer
addiKonal external guard hardware (e.g., watchdog)
for safety criKcal applicaKons

Image: Mitsubishi Electric

I/O drivers

watchdog

Microcontroller
(MCU)

ext. memory

( next slide)

address bus

ASIC

...

[C2X] Summer 2014

opt.
Co-Processors,
DSPs,
...

ext. memory

data bus
communication
diagnosis

Electronic Control Units (ECUs)

Architecture

External Bus

Program
Memory

Data
Memory

CPU

DMA
Sys. Timer

Bus Ctrl.

Bus Ctrl.
Interface to
other controllers

Ports
Interfaces
(CAN, serial,
JTAG, ...)

Interrupt
Handler

Serial Bus

Timers

System Ctrl.

A/D
Converter(s)

[C2X] Summer 2014

Electronic Control Units (ECUs)

Architecture

Microcontroller (MCU)

8, 16, 32 Bit
Inneon, Freescale, Fujitsu, ...

Memory

VolaKle memory
SRAM (some kByte)
Typically integrated into microcontroller

Non-volaKle memory
Flash (256 kByte .. some MByte)
Serial EEPROM (some kByte, e.g., for error log)

Power supply

DC/DC converter, e.g., to 5 V or 3.3 V

[C2X] Summer 2014

Electronic Control Units (ECUs)

Architecture

Clock

Quartz Xtal, some 10 MHz ( ECU requires only passive cooling)

External guard hardware

Watchdog
Expects periodic signal from MCU
Resets MCU on Kmeout

ASIC guard
For more complex / criKcal ECUs
ASIC sends quesKon, MCU must send correct answer before Kmeout
Resets (or disables) ECU on Kmeout or error

Internal Buses

Low-cost ECUs can use shared bus for address and data
Parallel

[C2X] Summer 2014

Electronic Control Units (ECUs)

Architecture

Sensor drivers

Actor drivers

ResisKve sensors (e.g., simple potenKometer for length, angle)

CapaciKve, inducKve sensors (e.g., pressure, distance)
AcKve sensors (simple voltage / complex data output)
D/A conversion
High-power ampliers
Bridges

Further requirements

Electro-magneKc interference (EMI) characterisKcs

Mechanical robustness
Water resistance
Thermal resistance
Chemical resistance

[C2X] Summer 2014

Electronic Control Units (ECUs)

Automo;ve Opera;ng Systems

Hardware abstracKon

ApplicaKon Programming Interface (API)

Ofen missing, hardware accessed directly

Recent trends towards operaKng systems

Common for message transmission over external buses

Sofware safeguards

E.g., stack overow

ParKcularly helpful during development

[C2X] Summer 2014

Electronic Control Units (ECUs)

Automo;ve Opera;ng Systems

Process States

running

wait

terminate
preempt

waiting

suspended

start
release

[C2X] Summer 2014

ready

Electronic Control Units (ECUs)

activate

10

Automo;ve Opera;ng Systems

Scheduling

suspended

Set of suspended tasks

Activation
time or event based
ready

Set of ready tasks

Scheduler
Priority

Priority queue of ready tasks

Order

Dispatcher

running
[C2X] Summer 2014

Electronic Control Units (ECUs)

Task executed
11

Automo;ve Opera;ng Systems

Scheduling

The act of assigning an order of acKvaKon,

given a process model, acKvaKon sequence, and deadlines
dynamic: Schedule is calculated at run Kme
sta*c: Schedule is xed, e.g., at compile Kme ( fully determinisKc)

Feasible schedule:
all Kme constraints fullled, no deadline violated
Dispatcher coordinates context switches

Context switches
For one process to change state to running, another process may
need to be preempted
CPU registers etc. will now be occupied by new process,
operaKng system takes care of persisKng informaKon

[C2X] Summer 2014

Electronic Control Units (ECUs)

12

Real Time Proper;es

Latency

Jijer

Time dierence from event to reacKon

Dierence of max and min latency

High importance in feedback control systems

ExecuKon Kme

Time dierence of task start and end

Worst Case ExecuKon Time (WCET)
Dened for program aspects, dependent on plakorm
Considers every possible cause of delay (interrupts, caching, )
Important for guaranteeing determinism

[C2X] Summer 2014

Electronic Control Units (ECUs)

13

Real Time Proper;es

Terminology of Real Time ProperKes

Start

End
Execution Time

Task

Time
Latency (Response Time)

Leeway

Activation

[C2X] Summer 2014

Deadline

Electronic Control Units (ECUs)

14

Real Time Proper;es

Sof deadline
Delivering result afer sof deadline less helpful 1
(reduced benet)
e.g., car speeds up radio gets louder

Firm deadline

Soft

Firm

Deadline

-1
Delivering result afer rm deadline useless
(no benet)
e.g., incoming trac bulleKn SatNav powered up

Hard deadline
Delivering result afer hard deadline causes damage or harm
(negaKve benet)
e.g., brake pedal is pushed car decelerates

[C2X] Summer 2014

Electronic Control Units (ECUs)

15

Hard

Real Time Proper;es

Real Kme systems

Internal image of system state in memory

State described by set of variables
Needs conKnuous update of image

Real Kme architecture

Event triggered system

Image update with every change of state

Time triggered system

Image update in xed intervals
internal or global clock (needs synchronizaKon)

[C2X] Summer 2014

Electronic Control Units (ECUs)

16

OSEK/VDX

1993
Founded as OSEK Oene Systeme und deren Schni7stellen fr
die Elektronik im Kra>fahrzeug
BMW, Bosch, Daimler Chrysler, Opel, Siemens, VW, Univ.
Karlsruhe

1994

Merged with VDX Vehicle Distributed Execu*ve

PSA und Renault

Today
More than 50 partners
(Parts) standardized as ISO 17356 series
Standardizes common communicaKons stack, network
management, opera;ng system ( next slides),
Many free implementaKons (freeOSEK, openOSEK, nxtOSEK, )

[C2X] Summer 2014

Electronic Control Units (ECUs)

17

OSEK/VDX
OSEK Operating System
Application
OSEK COM
Interaction Layer

OSEK/VDX
Network
Management

Network Layer

Data Link Layer

Bus Communication Hardware

Bus
[C2X] Summer 2014

Electronic Control Units (ECUs)

18

OSEK/VDX

ProperKes

OperaKng system for single processor

StaKc conguraKon
Tasks
Resources
FuncKons

Can meet requirements of hard deadlines

Programs execute directly from ROM
Very low memory requirements
Standardized system ( OSEK conformant ECUs)

[C2X] Summer 2014

Electronic Control Units (ECUs)

19

OSEK/VDX

ConguraKon

OperaKng system
congured at
compile Kme

CPU OSEK_Demo
{
OSEK_Example_OS
{
MICROCONTROLLER = Intel80x86;

};

OSEK ImplementaKon
Language (OIL)
Scheduling strategy
Task prioriKes

TASK Sample_TASK
{
PRIORITY = 12;
SCHEDULE = FULL;
AUTOSTART = TRUE;
ACTIVATION = 1;
};

};

[C2X] Summer 2014

Electronic Control Units (ECUs)

20

OSEK/VDX

Building of OSEK/VDX rmware

Configurator
*.oil

*.c

*.h

Generator
os.c

os.h
Compiler
*.obj
Linker
os.elf

[C2X] Summer 2014

Electronic Control Units (ECUs)

21

OSEK/VDX

Tasks

StaKc priority
RelaKonships of tasks
SynchronizaKon
Message exchange
Signaling

Support for Kme triggered services

Error management
C macros for deniKon provided

DeclareTask(SampleTask);

TASK(SampleTask) {
/* read sensors, trigger actors */
TerminateTask();
}
[C2X] Summer 2014

Electronic Control Units (ECUs)

22

OSEK/VDX

Scheduling

Scheduler always chooses highest priority task

Congurable modes:

Priority

Non preempKve: Tasks are never preempted

PreempKve: Higher priority tasks always preempt lower priority tasks
Mixed: Individual conguraKon of each task

suspended
running

running
ready

suspended
running

suspended

Task 2
Task 1

preempted by higher priority task

[C2X] Summer 2014

Electronic Control Units (ECUs)

23

AUTOSAR

TradiKonal paradigm:
one funcKon one ECU
(incl. sofware and OS, supplied by OEM)

AUTOSAR (Automo*ve Open System Architecture)

IniKaKve of automobile manufacturers to make sofware
development independent of operaKng system

Mix and match of hardware and sofware

IntegraKon at manufacturer
In-house development of sofware at manufacturer
Independence of/from OEM

[C2X] Summer 2014

Electronic Control Units (ECUs)

24

AUTOSAR

AUTOSAR RunKme Environment (RTE)

Middleware abstracKng away from lower layers

ApplicaKon Sofware Components

Rely on strict interfaces, independent of MCU, Sensors, Actors

Data

Data

Data

Data

Data

Data

Software

Software

Software

Software

Software

Software

AUTOSAR RTE
OS

Services

Comms

Hardware Abstraction

OS

ECU 1

[C2X] Summer 2014

Services

Comms

Hardware Abstraction

ECU 2

Electronic Control Units (ECUs)

25

AUTOSAR
Application Layer
AUTOSAR Runtime Environment

CAN XCP
FlexRay XCP

Generic NM
CAN NM
FlexRay NM

Communication

Gateway

Protocol Data Unit Router

FlexRay
Transport
Protocol

CAN
Transport
Protocol

ECU
Abstraction Layer

FlexRay
Interface

CAN
Interface

Microcontroller
Abstraction Layer

FlexRay
Driver

CAN
Driver

Complex Drivers

XCP
Services

Diagnostic
Comm.
Manager

Microcontroller
[C2X] Summer 2014

Electronic Control Units (ECUs)

26

Main Takeaways

ECUs

OSEK/VDX

Principles
Architecture
Real-Kme properKes (hard, rm, sof deadlines)
MoKvaKon
StaKc conguraKon
Scheduling

AUTOSAR

MoKvaKon
Run Time Environment
Component Principle

[C2X] Summer 2014

Electronic Control Units (ECUs)

27