As we have seen in the earlier article, Adaptive Cruise Control represents one of the earliest and most widely deployed ADAS features in production vehicles today. Unlike conventional cruise control, which simply holds a driver-set speed, ACC actively monitors the road ahead, detects vehicles in the same lane, and automatically adjusts the host vehicle's speed to maintain a safe following distance.

What makes ACC engineering-interesting is that it sits precisely at the boundary between comfort and safety. A poorly designed ACC that brakes unexpectedly or accelerates into a closing gap is not just annoying, it is dangerous. This places meaningful ASIL requirements on the system and demands tight coordination between the ACC ECU and several other vehicle systems including the engine, brakes, and instrument cluster.

With the rapid progression toward higher SAE autonomy levels, ACC is also the springboard for more advanced functions, Traffic Jam Assist, Highway Pilot, and ultimately hands-free highway driving. Understanding ACC's ECU architecture is therefore foundational to understanding how the vehicle's longitudinal control stack is built.

This article covers the hardware and software architecture focussing on safety requirements, design challenges, and future evolution of the ACC ECU.


Functional safety in Hardware Architecture

Governing Standards: ISO 15622 defines the performance and test requirements for ACC systems. UNECE Regulation 131 governs Advanced Emergency Braking (which shares hardware infrastructure with ACC). ISO 26262 applies for functional safety, typically targeting ASIL B at the system level.

Microcontroller

ACC ECUs in production vehicles typically run on an Infineon AURIX TC3xx or Renesas RH850/U2A family microcontroller. These are chosen for their lockstep dual-core architecture (supporting ASIL B decomposition), integrated hardware security modules, and extensive automotive qualification pedigree. Clock speeds in the 200–300 MHz range are common. The availability of hardware floating-point units matters here because the control algorithms involve significant real-time matrix computation. Some of the considerations include

  • Dual-core lockstep configuration with cycle-accurate comparison
  • Hardware watchdog with independent clock source
  • Voltage monitoring on all supply rails
  • Built-In Self Test (BIST) executed at startup covering CPU registers, RAM, and Flash CRC

Software Architecture

AUTOSAR or Bare-Metal?

ACC ECUs in production are almost universally built on AUTOSAR Classic, with the application layer decomposed into well-defined Software Components (SWCs) connected through the RTE. Adaptive AUTOSAR is emerging for next-generation centralised ADAS compute platforms, but Classic remains dominant for standalone ACC ECUs today.

Relevant BSW Modules

  • AUTOSAR BSW Module- Role in ACC
  • CAN Driver / CanIf / Com- Vehicle bus receive/transmit
  • ADC Driver- Analog sensor conditioning
  • WdgManager-Watchdog supervision
  • DiagEventManager (Dem) - DTC storage and management
  • DCM - UDS diagnostic services for tester
  • NvM - Non-volatile storage of calibrations and DTCs
  • Os (OSEK/AUTOSAR OS) - Task scheduling — typically rate-monotonic

Application SWCs

Application SWCs​
Application SWCs

Object Detection & Tracking SWC: Receives the radar object list (range, range rate, azimuth for each detected object). Applies a Kalman filter to smooth object position and velocity estimates across measurement cycles. Maintains a track list of up to N objects, assigning confidence scores and predicting future positions between radar scan cycles (typically 50–100 ms).

Target Selection SWC: From the tracked object list, selects the Most Relevant Object (MRO) — the vehicle directly ahead in the host lane. Uses steering angle and yaw rate to project the host vehicle's future path and identify which tracked object lies within it. Camera lane data provides additional lane assignment confidence.

Longitudinal Control SWC: Implements the core control law, typically a Model Predictive Control (MPC) or cascaded PID loop, that calculates the required longitudinal acceleration to achieve the target gap or set speed. Outputs a signed acceleration demand (positive for throttle, negative for brake). Applies jerk limiting (rate-of-change of acceleration) to ensure smooth, non-startling responses.

Arbitration SWC: Interfaces with the torque/brake request signals from other vehicle systems (driver pedal, ESC, etc.) and manages priority. The driver always overrides. ESC emergency braking always overrides. ACC operates in the space beneath these.

HMI SWC: Translates internal ACC state into signals consumed by the cluster or HUD, target lock symbol, set speed display, gap setting indicator, warning chime trigger.

The time gap (headway) maintained by ACC is expressed in seconds, a 1.5-second gap at 100 km/h corresponds to approximately 41 metres of following distance. The control law continuously computes the gap error and gap rate error and applies weighted corrections to the acceleration demand. Calibration of these weights is a significant validation activity requiring test track time.


Diagnostic Layer

ACC ECUs support UDS (ISO 14229) diagnostics via the vehicle CAN. Key DTC categories include radar blockage detection, camera unavailability, internal ECU faults, and communication timeouts from peer ECUs. In the event of a fault, the ECU transitions to a safe state (typically: ACC standby, driver alert via cluster) and logs the relevant DTC.


Safety and Compliance Considerations

ASIL Rating: At the system level, ACC is typically rated ASIL B, reflecting the fact that the driver retains full override authority at all times, reducing controllability severity compared to steering or braking-only systems. Specific safety goals (e.g., "ACC shall not command braking exceeding X g without driver awareness") are derived during HARA.


Key Safety Mechanisms:

  • Radar plausibility checks (cross-validation with camera object list)
  • Maximum deceleration demand capping in ACC-commanded braking
  • Timeout monitoring on all input CAN signals — loss of wheel speed → ACC standby
  • End-of-line calibration for radar mounting angle (boresight error exceeding threshold → DTC + disable)

ISO 21434 Relevance: ACC ECUs are in-scope for automotive cybersecurity given their CAN-bus interfaces and potential for spoofed radar object injection. Threat modeling should include the attack scenario of a crafted CAN message commanding maximum deceleration.


Design Challenges

1. Object Selection in Complex Traffic: Multi-lane highways, merging vehicles, and curved roads all create scenarios where selecting the wrong Most Relevant Object causes nuisance braking or failure to brake. Robust path prediction using yaw rate integration and camera lane data is essential but hard to calibrate across all edge cases.

2. Radar and Camera Calibration Drift: Mounting angle errors as small as 0.5° in the radar can cause the MRO to be misidentified. Production end-of-line calibration and in-service monitoring (using stationary guardrail returns as reference) are both required.

3. Latency Budget Management: From radar return to brake actuation, the total system latency budget is typically under 200 ms. Each processing stage, radar DSP, object list transmission, ACC algorithm cycle, CAN transmission, ESC response, consumes a slice of this budget. Task scheduling and CAN message timing must be co-designed.

4. Jerk and Comfort Calibration: Technically correct braking that feels abrupt will cause drivers to disable ACC permanently. The comfort calibration, jerk limits, gap distance defaults, hysteresis bands, is as important as the control law itself and requires extensive subjective evaluation alongside objective metrics.

5. Stop-and-Go Extension: Extending ACC to full stop (0 km/h) requires integration with the electric parking brake or brake hold function, plus a pull-away logic that waits for driver intent confirmation before resuming following, a significant state machine complexity addition.


Trends and Future Outlook

ACC is rapidly being absorbed into broader Highway Driving Assist (HDA) and Traffic Jam Assist (TJA) feature stacks, which combine longitudinal control (ACC) with lateral control (Lane Keeping Assist) into a unified domain controller. On centralised compute platforms, ACC's object tracking and control algorithms run as software partitions on an ADAS SoC (Qualcomm SA8775P, Renesas R-Car V4H) rather than on a dedicated ECU.

Radar technology is simultaneously moving from single-chip 77 GHz transceivers to 4D imaging radar, which adds elevation data to the traditional range-velocity-azimuth output, dramatically improving object classification and reducing false positives in complex scenarios.

Regulatory pressure is also increasing. Euro NCAP's 2025+ ratings now include ACC performance in real-world testing scenarios, creating a direct commercial incentive for OEMs to improve system robustness beyond minimum compliance.


Conclusion

Thus ACC forms a crucial part of modern automotive. The design to the ECU calls for careful consideration across hardware, software and functional safety domains. Embien has hands-on experience in developing and integrating ECU software for longitudinal control systems, AUTOSAR Classic-based application SWCs, and CAN/CAN FD communication stacks across multiple OEM programs. Our RAPIDSEA suite includes production-ready CAN FD and UDS protocol stacks that significantly reduce integration time on ACC and ADAS-adjacent programs. We have worked with Renesas RH850 and NXP S32K silicon families in safety-relevant ECU developments and can support ASIL B programs from concept through validation.

To discuss your ACC or ADAS ECU development requirements, reach out to the Embien team.


Related Content

Automotive EE architecture - The backbone of vehicle electronics
insight image

Electrical/electronic architecture, also known as EE architecture, is the intricate system that manages the flow of electrical and electronic signals within a vehicle.

Read More


Subscribe to our Insights