Part

1: In-Car Networking

ELECTRONIC CONTROL UNITS (ECUS)

[C2X] Summer 2014 Electronic Control Units (ECUs) 1

 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) 2

 Architecture
Communication, Diagnosis

ECU Power
Transceiver
Supply

ECU
Sensors

Actors
Sensor Core Actor
Drivers Drivers
( next slide)

Images: Mitsubishi Electric

[C2X] Summer 2014 Electronic Control Units (ECUs) 3

 Architecture

ECU Core
Personal Computer
addiKonal external guard hardware (e.g., watchdog)
for safety criKcal applicaKons
Image: Mitsubishi Electric
I/O drivers

watchdog Microcontroller ext. memory ext. memory

(MCU)

( next slide) address bus

ASIC
opt.
data bus
Co-Processors,
DSPs, communication

... ... diagnosis

[C2X] Summer 2014 Electronic Control Units (ECUs) 4

 Architecture

Program Data
CPU
External Bus Memory Memory

DMA

Sys. Timer Bus Ctrl. Bus Ctrl.

Ports Interface to
other controllers
Interfaces
Interrupt
(CAN, serial, Serial Bus
Handler
JTAG, ...)

A/D
Timers System Ctrl.
Converter(s)

[C2X] Summer 2014 Electronic Control Units (ECUs) 5

 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) 6

 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) 7

 Architecture

Sensor drivers
ResisKve sensors (e.g., simple potenKometer for length, angle)
CapaciKve, inducKve sensors (e.g., pressure, distance)
AcKve sensors (simple voltage / complex data output)
Actor drivers
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) 8

 Automo;ve Opera;ng Systems

Hardware abstracKon
Ofen missing, hardware accessed directly
Recent trends towards operaKng systems

ApplicaKon Programming Interface (API)

Common for message transmission over external buses

Sofware safeguards
E.g., stack overow
ParKcularly helpful during development

[C2X] Summer 2014 Electronic Control Units (ECUs) 9

 Automo;ve Opera;ng Systems

Process States

running
wait terminate
preempt

waiting suspended

start
release activate
ready

[C2X] Summer 2014 Electronic Control Units (ECUs) 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 Task executed

[C2X] Summer 2014 Electronic Control Units (ECUs) 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
Time dierence from event to reacKon

Jijer
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 Deadline

[C2X] Summer 2014 Electronic Control Units (ECUs) 14

 Real Time Proper;es

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

Deadline
Firm deadline
Delivering result afer rm deadline useless -1
(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

 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 CPU OSEK_Demo

OperaKng system {

congured at
OSEK_Example_OS
compile Kme {
MICROCONTROLLER = Intel80x86;

OSEK ImplementaKon };
Language (OIL)
Scheduling strategy TASK Sample_TASK
Task prioriKes {
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:
Non preempKve: Tasks are never preempted
PreempKve: Higher priority tasks always preempt lower priority tasks
Mixed: Individual conguraKon of each task

suspended running suspended Task 2

Priority

running ready running suspended 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

Services Comms Services Comms

OS OS
Hardware Abstraction Hardware Abstraction

ECU 1 ECU 2

[C2X] Summer 2014 Electronic Control Units (ECUs) 25

 AUTOSAR

Application Layer

AUTOSAR Runtime Environment

Diagnostic
Communi-
Comm. Gateway
cation
Manager
XCP
Services Generic NM
CAN NM Protocol Data Unit Router

Complex Drivers
CAN XCP FlexRay NM
FlexRay XCP
FlexRay CAN
Transport Transport
Protocol Protocol

ECU FlexRay CAN

Abstraction Layer Interface Interface

Microcontroller FlexRay CAN

Abstraction Layer Driver Driver

Microcontroller

[C2X] Summer 2014 Electronic Control Units (ECUs) 26

 Main Takeaways

ECUs
Principles
Architecture
Real-Kme properKes (hard, rm, sof deadlines)
OSEK/VDX
MoKvaKon
StaKc conguraKon
Scheduling
AUTOSAR
MoKvaKon
Run Time Environment
Component Principle

[C2X] Summer 2014 Electronic Control Units (ECUs) 27