Automatic Emergency Braking as a vehicle-level system.
An engineering dependency map for reasoning from road scene to brake response—and from a symptom back to the evidence still needed.
Engineering question
What must work together before an AEB intervention can occur?
AEB is often described as a sensor detecting danger and applying the brakes. That description is useful for a driver, but incomplete for engineering work.
A vehicle-level view reveals a dependency chain: the road scene must be observable; measurements must become trustworthy estimates; the host vehicle’s state must be known; the threat must be assessed; a response must be authorized; and the braking system must convert a request into vehicle deceleration. Context, communication, supervision, diagnostics, and driver interaction surround the entire chain.
Original dependency map
From scene observation to vehicle response
This conceptual map was created for Project VISION ADAS. It is product-neutral: actual sensor sets, module boundaries, signal paths, thresholds, and response strategies vary by vehicle.
Road geometry · target behavior · illumination · weather · visibility · surface friction · driver behavior
- 01Sense
Observe the scene
Forward sensors produce measurements within their field of view, physical condition, mounting geometry, and environmental limits.
- 02Context
Know the host vehicle
Vehicle speed, yaw, steering, brake state, stability-control availability, and other design-dependent signals establish motion and readiness.
- 03Estimate
Build object tracks
Processing turns measurements into objects, lanes or paths, relative motion, confidence, and uncertainty over time.
- 04Assess
Evaluate the threat
The system considers path relevance, closing behavior, available response time, driver action, and the braking demand indicated by its model.
- 05Decide
Authorize a response
Supervisory logic applies functional state, inhibit conditions, escalation rules, arbitration, and the vehicle-specific response strategy.
- 06Act
Execute braking
A brake request must travel through control and actuation before tire–road forces can change the vehicle’s motion.
- 07Report
Inform and record
Warnings, status messages, DTCs, scan data, and service records support investigation—but no single record proves full system performance.
Power · grounds · networks · time synchronization · configuration · component health
Warnings · DTCs · scan data · event timing · repair history · calibration records · verification results
How to read the map
A chain is only as useful as the questions it creates.
1. Sensing is an input—not a conclusion
A forward sensor can measure part of the external scene, but its output is not yet a braking decision. Visibility, occlusion, target characteristics, mounting, contamination, and environmental conditions can influence what information is available. The applicable vehicle design determines which sensors contribute and how their inputs are used.
2. The system must understand its own motion
Closing risk cannot be interpreted from an external object alone. The function also needs design-dependent information about the host vehicle: speed, direction, yaw, steering, braking, and system availability. A plausible object estimate combined with incoherent vehicle-state information is not a sound basis for intervention.
3. Threat assessment is not the same as detection
An object can be detected without being relevant to the vehicle’s path. Engineering logic must estimate motion, determine path relationship, preserve uncertainty, and consider the remaining opportunity for a safe response. This is why a detection count or a single screenshot cannot verify the behavior of the full feature.
4. A decision still requires execution
Even after supervisory logic requests braking, the request must reach the appropriate control system and become tire force at the road. Brake-system state, stability functions, tire condition, surface friction, and vehicle dynamics influence the actual response. The intervention is therefore a vehicle outcome, not only a perception output.
Dependency-to-evidence matrix
Move from “What failed?” to “What evidence would distinguish the possibilities?”
What did the sensors have an opportunity to observe?
Sensor-area condition, mounting, field of view, DTCs, data quality, environmental conditions
Did the feature receive coherent host-vehicle motion and driver-input information?
Speed, yaw, steering, brake input, stability-control state, signal plausibility
Did the required information arrive with the expected integrity and timing?
Network faults, timeouts, timestamps, message freshness, module status
Was the sensor-to-vehicle relationship suitable for the applicable design?
Repair history, mounting condition, alignment information, calibration records, current OEM requirements
Was the function available, and were any design-specific inhibit conditions active?
Feature status, driver settings, warnings, related faults, operating conditions
Could the requested deceleration be produced at the vehicle and road interface?
Brake-system state, tire condition, road friction, stability-control information, test evidence
Synthetic reasoning case
“The sensor looks clean, but AEB is unavailable.”
Educational example · not a diagnosisAn AEB-unavailable message is present. The visible forward sensor areas appear clean. No performance conclusion has been established.
- A sensor or related component fault
- Power, network, timing, or configuration concern
- Mounting or geometric relationship concern
- An unmet feature precondition or active inhibit
- A temporary environmental limitation
- A concern elsewhere in the brake or stability system
- Exact message, time, mileage, and operating context
- Vehicle-specific service information
- Complete scan and relevant live/status data
- Repair, alignment, and calibration history
- Physical inspection within authorized scope
- Applicable OEM verification procedure and results
The clean surface removes one obvious observation from concern; it does not close the case. The next action is to collect vehicle-specific evidence, not to declare the feature healthy or failed from appearance alone.
Two safety lenses
Malfunction and performance limitation are different questions.
Did an electrical or electronic element behave incorrectly?
Examples may include missing signals, implausible data, power interruption, network timeout, internal module faults, or loss of actuator availability. ISO 26262 provides a functional-safety framework for safety-related electrical and electronic systems. [2]
Could the feature be limited even without a component fault?
Low contrast, occlusion, unusual targets, difficult geometry, or other challenging conditions may expose limitations in sensing or interpretation. ISO 21448 addresses safety concerns connected to intended-function insufficiencies and foreseeable use. [3]
This note uses these standards only as public conceptual references. It does not reproduce their requirements or claim that this model demonstrates compliance.
Verification thinking
“The warning disappeared” is not a complete test result.
Define the objective
State which function, behavior, or fault hypothesis is being evaluated.
Control the conditions
Record vehicle state, environment, setup, target, and other conditions required by the authorized procedure.
Select measurements
Use objective signals, records, timing, and outcomes—not only the absence of a message.
Use valid criteria
Apply the current vehicle-specific procedure or defined engineering acceptance criteria.
Preserve limitations
Document what was not tested, what remained uncertain, and what conclusions the evidence cannot support.
Engineering takeaway
Do not stop at the component. Follow the function.
NHTSA classifies AEB as a collision-intervention technology that may initiate braking when it judges a forward impact to be imminent. [1] For engineering analysis, that vehicle-level outcome should be traced backward through execution, decision, threat assessment, estimation, vehicle state, sensing, and operating context.
The practical discipline is simple: document the observation, map the affected dependencies, develop more than one hypothesis, collect discriminating evidence, and limit the conclusion to what that evidence supports.
“A warning identifies a condition to investigate. A dependency map identifies where the investigation must remain open.”
References
Revision record
Initial public release of the conceptual dependency map, evidence matrix, synthetic reasoning case, and scope statement.
The wording, organization, dependency model, figure, evidence matrix, and synthetic case on this page were created specifically for Project VISION ADAS. Public sources are used for factual context and are cited above. No OEM diagram, paid service information, proprietary architecture, or third-party illustration is reproduced.
This independent educational note is not an OEM procedure, diagnosis, repair instruction, calibration specification, legal requirement, completed validation report, or certification of system performance. Actual vehicle architectures and requirements vary. Current manufacturer information and qualified professional judgment control vehicle-specific decisions.