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
Transceiver
Sensor
Drivers
ECU
Core
(⇨ next slide)
Power
Supply
Actor
Drivers
Actors
Sensors
ECU
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
(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) 4 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) 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 ª
ª
ª
²
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 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 ª
ª
²
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 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
[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 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 ª
²
Jijer ª
ª
²
Time difference from event to reacKon 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
[C2X] Summer 2014 Deadline
Electronic Control Units (ECUs) 14 Real Time Proper;es Sof deadline Delivering result afer sof deadline less helpful 1
(reduced benefit) ª  e.g., car speeds up ⇨ radio gets louder ª
0
²
Firm deadline Soft
Firm
Deadline
²
-1
Delivering result afer firm deadline useless (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 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 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 ª
ª
OperaKng system configured 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 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: Priority
§  Non preempKve: Tasks are never preempted §  PreempKve: Higher priority tasks always preempt lower priority tasks §  Mixed: Individual configuraKon 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, firm, sof deadlines) MoKvaKon StaKc configuraKon Scheduling AUTOSAR ª
ª
ª
MoKvaKon Run Time Environment Component Principle [C2X] Summer 2014 Electronic Control Units (ECUs) 27