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  
ª  Infineon,  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  amplifiers  
ª  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  overflow  
ª  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  fixed,  e.g.,  at  compile  Kme  (⇨  fully  determinisKc)  
ª  Feasible  schedule:  
all  Kme  constraints  fulfilled,  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  difference  from  event  to  reacKon  

²  Jijer  
ª  Difference  of  max  and  min  latency  
ª  High  importance  in  feedback  control  systems  

²  ExecuKon  Kme  

ª  Time  difference  of  task  start  and  end  
ª  Worst  Case  ExecuKon  Time  (WCET)  
§  Defined  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  benefit)  
ª  e.g.,  car  speeds  up  ⇨  radio  gets  louder  
0

Deadline
²  Firm  deadline  
ª  Delivering  result  afer  firm  deadline  useless   -1
(no  benefit)  
ª  e.g.,  incoming  traffic  bulleKn  ⇨  SatNav  powered  up  

²  Hard  deadline  

ª  Delivering  result  afer  hard  deadline  causes  damage  or  harm  
(negaKve  benefit)  
ª  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  fixed  intervals  
§  internal  or  global  clock  (needs  synchronizaKon)  

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

 OSEK/VDX  

²  1993  
ª  Founded  as  OSEK  –  “Offene  Systeme  und  deren  Schni7stellen  für  
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  configuraKon  
§  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  

²  ConfiguraKon   CPU OSEK_Demo

ª  OperaKng  system     {

configured  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  firmware  

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  definiKon  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  
ª  Configurable  modes:  
§  Non  preempKve:  Tasks  are  never  preempted  
§  PreempKve:  Higher  priority  tasks  always  preempt  lower  priority  tasks  
§  Mixed:  Individual  configuraKon  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,  firm,  sof  deadlines)  
²  OSEK/VDX  
ª  MoKvaKon  
ª  StaKc  configuraKon  
ª  Scheduling  
²  AUTOSAR  
ª  MoKvaKon  
ª  Run  Time  Environment  
ª  Component  Principle  

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