HACKATHON LEVEL - 1
ADAS ECU SIMULATION &
TESTING FOR SUBMISSION
1. ADAS ECU Design Project
Title: ADAS ECU integrating Camera, Radar, and LiDAR for Perception, Sensor Fusion &
Decision Making
1. Problem Statement
Modern vehicles require robust, low-latency perception and decision-making to support
Advanced Driver Assistance Systems (ADAS). Existing single-sensor systems suffer from
occlusion, low-light limitations, and reduced reliability. The goal of this project is to design
an ADAS Electronic Control Unit (ECU) architecture that fuses camera, radar, and LiDAR
inputs to provide reliable object detection, tracking, and driving decisions with safety
mechanisms compliant with automotive functional safety standards.
Objectives:
Design a block diagram and architecture of an ADAS ECU.
Explain signal flow from sensors to decision-making.
Highlight processor architecture, memory hierarchy, and fault-tolerant safety
mechanisms.
Provide a solution methodology, implementation steps, and expected outcomes.
2. College Code & College Name
College Code: 7104
College Name: CHRIST THE KING ENGINEERING COLLEGE
3. Student Team details:
Student Reg. Name of the
[Link] Branch Mobile No. email id
No. Student
710422106015 9342893043 [Link]@[Link]
1 Jones J ECE m
710422106009 9344756113 dineshmurugan418
2 Dinesh M ECE @[Link]
710422106050 8870458997 sudhanff00@gmail.c
3 Sudhan G ECE om
710422106028 9345016258 [Link]@
4 Naveenkumar R ECE [Link]
4. High-level Block Diagram
5. Detailed Signal Flow (Step-by-step)
1. Sensor Acquisition:
o Cameras deliver image frames at 30–60 fps (or higher for ADAS). LiDAR
provides point clouds (10–40 Hz) and Radar provides range/velocity (10–50
Hz). Each sensor timestamped with a synchronized clock (PPS/IEEE-1588 /
PTP).
2. Pre-processing:
o Camera: Image Signal Processor (demosaic, denoise, color correction, HDR).
Outputs rectified images.
o Radar: ADC → FFT → doppler processing → CFAR detection to obtain
range/velocity peaks.
o LiDAR: Filtering, down-sampling, coordinate transform to vehicle frame,
ground-plane removal.
3. Perception Modules (Sensor-specific):
o Camera Perception: CNN-based object detection (e.g., YOLO, Faster R-CNN)
and semantic segmentation networks for lane detection.
o Radar Perception: Doppler-based object detection and velocity estimation;
good for adverse weather.
o LiDAR Perception: Point-based (PointNet/PointPillars) or voxel-based
detection and 3D bounding box estimation.
4. Time Alignment & Synchronization:
o Sensor data aligned by timestamps; buffering and interpolation handle
differing rates. Use hardware timestamping to reduce jitter.
5. Sensor Fusion:
o Early fusion (project LiDAR to image plane) or late fusion (fuse individual
detections). Algorithms: Kalman Filter / Extended Kalman Filter (EKF) for
state fusion, probabilistic occupancy grids, or learned fusion via neural
networks.
6. Tracking & State Estimation:
o Multi-object tracking (MOT) using Kalman Filters or JPDA; data association
via Hungarian algorithm or learned association.
7. Prediction:
o Predict trajectories of dynamic objects using RNNs/Transformers or physics-
based motion models.
8. Planning & Control:
o Generate safe trajectories considering constraints and predicted states. Low-
latency MPC (Model Predictive Control) or rule-based fallback.
o Control commands (steering, throttle, brake) sent over vehicle bus
(CAN/CAN-FD, Ethernet AVB) with monitored actuation.
9. Actuation & Monitoring:
o Actuators execute commands; continuous monitoring for faults and
plausibility checks (sanity checks on commands and vehicle response).
6. Processor Architecture
Suggested SoC Composition:
Multi-core ARM CPUs (e.g., Cortex-A53/A72) — scheduling, middleware, safety
supervisor.
GPU (integrated) or NPU for deep-learning inference (object detection, segmentation,
fusion networks).
DSP or dedicated accelerator for radar/LiDAR signal processing.
FPGA or safety MCU (e.g., ARM Cortex-R) for low-latency deterministic tasks and
redundancy.
Vehicle I/O controllers: CAN, CAN-FD, Ethernet AVB/TSN, LIN, GPIO.
Hardware Partitioning:
Safety Domain: Runs on lockstep or dual-core lockstep MCU executing ASIL-rated
safety-critical code (reduced functionality, watchdogs).
Application Domain: Runs perception, fusion and planning on Linux-based OS with
real-time extensions for scheduling.
Software Stack:
Hypervisor or separation kernel to partition safety-critical tasks from non-critical
tasks.
Middleware: ROS 2 / AUTOSAR Classic or Adaptive, or a custom lightweight
middleware for message passing and health monitoring.
7. Memory Hierarchy
On-chip SRAM / Tightly-coupled memory (TCM): For deterministic, real-time
tasks (trackers, control loops).
DRAM (LPDDR4/5): For bulk data and neural network inference working memory
(images, point clouds, intermediate tensors).
Flash / eMMC / UFS: Non-volatile storage for firmware, maps, models, logs.
Cache (L1/L2/L3): For CPU performance; ECC-protected L2/L3 for safety.
Scratch buffers & DMA: For zero-copy transfers between sensors and accelerators
to minimize latency.
Memory reliability features: ECC in DRAM and caches, wear-leveling and secure storage of
keys in secure element/TPM.
8. Safety Mechanisms & Functional Safety (ISO 26262)
ASIL Decomposition: Isolate safety-critical control tasks into ASIL-rated
components.
Redundancy: Redundant sensors (multiple cameras, radar or lidar redundancy) and
compute paths (primary + secondary path) for cross-checking.
Diverse Algorithms/Hardware: Use different algorithmic approaches (e.g., LiDAR-
based detection + camera-based detection) to avoid common-cause failures.
Watchdogs & Heartbeats: Hardware watchdog timers, task-level watchdogs, and
process heartbeats monitored by a safety supervisor.
Fault Detection & Diagnosis (FDD): Monitor sensor plausibility, compute unit
health, timing violations, and checksum mismatches.
Fail-safe & Graceful Degradation: Define safe states (e.g., slow down, pullover,
handover to driver) and degraded mode behaviors.
Memory Protection: MPU/MMU, ECC, stack canaries, control-flow integrity
checks.
Secure Boot/OTA: Signed firmware, secure boot chain, and authenticated OTA
updates.
Logging & Forensics: Event logs with secure timestamps for post-incident analysis.
9. Solution with Methodology (Implementation Steps)
Phase 1 — Requirements & System Design
1. Gather sensor specs (sampling rates, resolution, fields of view).
2. Define performance targets (detection range, latency budget, throughput).
3. Create system block diagram (done above) and select hardware components.
Phase 2 — Prototyping Hardware & Data Pipeline
1. Set up synchronized sensors (use ROS 2 for time-sync, or PTP/NTP + hardware
triggers).
2. Implement drivers to ingest camera frames, radar detections and LiDAR point clouds
into memory with timestamps.
3. Implement pre-processing modules.
Phase 3 — Perception & Fusion Development
1. Train / integrate object detection models for camera and LiDAR (e.g., YOLOv5 for
camera, PointPillars for LiDAR).
2. Implement radar signal processing and detection algorithms.
3. Develop sensor fusion module (Kalman-based or NN-based fusion).
Phase 4 — Tracking, Prediction, Planning & Control
1. Implement Multi-Object Tracking (MOT) with data association.
2. Implement behavior prediction models.
3. Implement planning (MPC or sampling-based planners) and control loops.
Phase 5 — Safety & Validation
1. Add watchdogs, redundancy checks, and safe fallbacks.
2. Run SIL/HIL tests, fault injection, and performance benchmarking.
3. Validate on recorded datasets and in controlled driving scenarios.
Phase 6 — Optimization & Deployment
1. Quantize and optimize NN models for the NPU/GPU.
2. Implement real-time scheduling, priority inversion avoidance, and CPU/GPU load
balancing.
3. Prepare documentation and ASIL evidence for compliance.
10. Outcomes / Results (Expected & Sample)
Functional outcomes:
Reliable object detection (mAP target: 0.6–0.8 depending on dataset and distance
ranges).
Multi-object tracking with acceptable ID-switch rates (<10% in typical urban
scenarios).
Fusion reduces false positives by X% (measured in validation trials).
End-to-end latency (sensor to actuation) within target budget (example: <100 ms for
emergency braking).
Validation plan:
Offline: Run on KITTI / nuScenes / Waymo datasets and measure detection/tracking
metrics.
SIL (Software-in-the-Loop): Use recorded sensor streams to validate control
outputs.
HIL (Hardware-in-the-Loop): Integrate ECU with vehicle actuators in a test rig.
Vehicle tests: Closed track trials and incremental public-road tests under supervision.
Attachable deliverables:
Trained model files (camera detection, LiDAR detector, fusion net).
Sample recorded dataset and logs (timestamped sensor streams).
Test reports: latency, CPU/GPU utilization, detection/tracking metrics.
11. Example Tables / Figures to Attach
Table 1 — Latency budget sample
Stage Max allowed (ms) Typical (ms)
Sensor acquisition 10 5
Pre-processing 10 8
Perception (inference) 40 30
Fusion & tracking 15 10
Planning & control 15 12
Actuation comms 10 5
Total 100 70
Table 2 — Example compute resources
Component Role
ARM Cortex-A72 quad System services, middleware, logging
Embedded GPU / NPU Neural network inference
DSP Radar FFT & filtering
FPGA Deterministic I/O & HW accel
12. Conclusions & Future Scope
The proposed ADAS ECU architecture leverages multi-sensor fusion and
heterogeneous compute to achieve robust perception and low-latency decision-
making.
Safety mechanisms (redundancy, ECC, watchdogs, secure boot) are essential for
ASIL compliance and real-world deployment.
Future improvements:
Add time-sensitive networking (TSN) for deterministic Ethernet in-vehicle comms.
Use of continual learning for model adaptation to new environments.
Integration with HD-maps and V2X for extended situational awareness.
2. Real-Time Processing & Safety:
Title: ADAS ECU integrating Camera, Radar, and LiDAR for Perception, Sensor Fusion &
Decision Making
1. Problem Statement
Modern vehicles require robust, low-latency perception and decision-making to support
Advanced Driver Assistance Systems (ADAS). Existing single-sensor systems suffer from
occlusion, low-light limitations, and reduced reliability. The goal of this project is to design
an ADAS Electronic Control Unit (ECU) architecture that fuses camera, radar, and LiDAR
inputs to provide reliable object detection, tracking, and driving decisions with safety
mechanisms compliant with automotive functional safety standards.
Objectives:
Design a block diagram and architecture of an ADAS ECU.
Explain signal flow from sensors to decision-making.
Highlight processor architecture, memory hierarchy, and fault-tolerant safety
mechanisms.
Provide a solution methodology, implementation steps, and expected outcomes.
2. High-level Block Diagram
3. Real-Time Processing & Safety
3.1 Timing Constraints in ADAS Features
Real-time operation is critical in ADAS for ensuring timely perception and control decisions.
Each feature has specific latency requirements:
ADAS Function Typical Latency Constraint
Pedestrian Detection ≤ 100 ms end-to-end (camera capture → detection →
control)
Forward Collision Warning ≤ 50–80 ms
(FCW)
Automatic Emergency Braking ≤ 30–50 ms
(AEB)
Lane Departure Warning (LDW) ≤ 150 ms
Adaptive Cruise Control (ACC) Control loop ~10–20 Hz (50–100 ms cycle)
Blind Spot Detection ≤ 200 ms
These constraints ensure that decisions are made within safe reaction times, maintaining
system stability and user safety.
3.2 ISO 26262 Implementation & ASIL Levels
ISO 26262 is the international standard for automotive functional safety. It defines safety
lifecycle processes, hazard analysis, and risk reduction techniques.
Key Automotive Safety Integrity Levels (ASIL):
ASIL Description Typical ADAS Applications
ASIL A Lowest safety Infotainment, simple status displays
criticality
ASIL B Moderate safety Parking sensors, driver alerts
ASIL C High safety Lane-keeping assist, adaptive cruise control
ASIL D Highest safety Emergency braking, steering control, collision
avoidance
In ADAS ECUs, modules are partitioned by ASIL level. For example:
Perception and planning run in ASIL C domain.
Actuation control runs in ASIL D domain with fail-safe redundancy.
Safety is enforced using:
Hardware redundancy (lockstep CPUs, mirrored processing units)
Software diversity (different algorithms verifying results)
Watchdogs and health monitoring for process integrity.
3.3 Watchdog Timers and Redundancy
Watchdog timers (WDTs) ensure system responsiveness:
Monitors CPU and task execution time.
If a task hangs or misses its time window, the WDT resets the ECU or switches to a
safe state.
Redundancy provides resilience:
Sensor redundancy: Multiple sensors of different modalities (camera + radar +
LiDAR) cover failures or environmental limitations.
Compute redundancy: Dual ECUs or dual-core lockstep processors verify outputs.
Power redundancy: Separate regulated power domains for sensors and actuators.
Together, WDTs and redundancy enable fault tolerance and compliance with ISO 26262.
3.4 Validation & Simulation of ADAS Algorithms
Before deploying algorithms to hardware, extensive simulation and validation are
performed.
Stages:
1. Model-in-the-Loop (MiL):
o Algorithms modeled in MATLAB/Simulink or Python.
o Simulated environment (e.g., Carla, PreScan, or LGSVL) provides virtual
sensor data.
2. Software-in-the-Loop (SiL):
o Compiled perception and fusion code tested on PCs.
o Realistic sensor data from datasets like KITTI or nuScenes.
3. Processor-in-the-Loop (PiL):
o Code executed on the target ECU processor to measure execution timing and
memory usage.
4. Hardware-in-the-Loop (HiL):
o ECU connected to a simulator that mimics vehicle dynamics and sensor
inputs.
o Validates timing, safety responses, and actuator commands.
These steps ensure functional correctness, timing compliance, and safety before vehicle
testing.
4. Slution with Methodology
Phase 1 — Requirements & System Design
1. Gather sensor specs (sampling rates, resolution, fields of view).
2. Define performance targets (detection range, latency budget, throughput).
3. Create system block diagram (done above) and select hardware components.
Phase 2 — Prototyping Hardware & Data Pipeline
1. Set up synchronized sensors (use ROS 2 for time-sync, or PTP/NTP + hardware
triggers).
2. Implement drivers to ingest camera frames, radar detections and LiDAR point clouds
into memory with timestamps.
3. Implement pre-processing modules.
Phase 3 — Perception & Fusion Development
1. Train / integrate object detection models for camera and LiDAR (e.g., YOLOv5 for
camera, PointPillars for LiDAR).
2. Implement radar signal processing and detection algorithms.
3. Develop sensor fusion module (Kalman-based or NN-based fusion).
Phase 4 — Tracking, Prediction, Planning & Control
1. Implement Multi-Object Tracking (MOT) with data association.
2. Implement behavior prediction models.
3. Implement planning (MPC or sampling-based planners) and control loops.
Phase 5 — Safety & Validation
1. Add watchdogs, redundancy checks, and safe fallbacks.
2. Run SIL/HIL tests, fault injection, and performance benchmarking.
3. Validate on recorded datasets and in controlled driving scenarios.
Phase 6 — Optimization & Deployment
1. Quantize and optimize NN models for the NPU/GPU.
2. Implement real-time scheduling, priority inversion avoidance, and CPU/GPU load
balancing.
3. Prepare documentation and ASIL evidence for compliance.
5. Outcomes / Results (Expected & Sample)
Functional outcomes:
4. Reliable object detection (mAP target: 0.6–0.8 depending on dataset and distance
ranges).
5. Multi-object tracking with acceptable ID-switch rates (<10% in typical urban
scenarios).
6. Fusion reduces false positives by X% (measured in validation trials).
7. End-to-end latency (sensor to actuation) within target budget (example: <100 ms for
emergency braking).
Validation plan:
Offline: Run on KITTI / nuScenes / Waymo datasets and measure detection/tracking
metrics.
SIL (Software-in-the-Loop): Use recorded sensor streams to validate control
outputs.
HIL (Hardware-in-the-Loop): Integrate ECU with vehicle actuators in a test rig.
Vehicle tests: Closed track trials and incremental public-road tests under supervision.
Attachable deliverables:
Trained model files (camera detection, LiDAR detector, fusion net).
Sample recorded dataset and logs (timestamped sensor streams).
Test reports: latency, CPU/GPU utilization, detection/tracking metrics.
6. Conclusions & Future Scope
The proposed ADAS ECU architecture leverages multi-sensor fusion and
heterogeneous compute to achieve robust perception and low-latency decision-
making.
Safety mechanisms (redundancy, ECC, watchdogs, secure boot) are essential for
ASIL compliance and real-world deployment.
Future improvements:
Add time-sensitive networking (TSN) for deterministic Ethernet in-vehicle comms.
Use of continual learning for model adaptation to new environments.
Integration with HD-maps and V2X for extended situational awareness.
