Safety Mechanisms: Sensor Plausibility Checks and Degraded Modes

The problem

ADAS functions depend on sensor data that can be wrong in many ways: stuck values, noise bursts, offsets, dropouts or disagreement between sensors. ISO 26262 safety mechanisms must detect such faults in time and move the function to a degraded mode that is still safe and useful. Designing checks that catch faults without false alarms is a real engineering trade-off. This project builds and evaluates a set of them.

Objectives

• Define a fault model for radar and camera object data with fault-tolerant time intervals.
• Implement range, rate, cross-sensor and model-based plausibility checks in Simulink.
• Design a degraded-mode manager in Stateflow with defined transitions and driver warnings.
• Run fault-injection campaigns in closed-loop scenarios.
• Measure detection time, false-alarm rate, diagnostic coverage and functional availability.

What you need

Key concepts

Plausibility check

A test of whether a signal value is physically possible and consistent with other information, such as a lead vehicle distance that cannot change faster than the maximum relative speed allows.

Diagnostic coverage

The fraction of faults of a given type that a safety mechanism detects, estimated here from fault-injection results.

Degraded mode

A reduced function, such as ACC with lower maximum deceleration or larger time gap, that stays safe when part of the system is not trusted.

Debouncing

Requiring a condition to persist for several cycles before acting, which reduces false alarms but adds detection delay.

Step-by-step guide

1. 1

   Define the function and fault model

   Choose an ACC with AEB fallback using one front radar and one front camera, starting from an Automated Driving Toolbox example model. List sensor fault types with parameters: stuck-at value, offset, gain error, noise burst, dropout, delayed data and ghost object. For each relevant safety goal, state the fault-tolerant time interval. Write technical safety requirements for detection time and false-alarm limits.

   Checkpoint: A fault model table and a set of numbered safety requirements with timing and false-alarm targets.

2. 2

   Build the fault injection layer

   Insert a fault injection subsystem between sensor models and the fusion input, with a variant or switch per fault type, configurable start time, duration and magnitude driven from workspace parameters. Make it transparent when no fault is active and check this with a regression run. Log the true fault state so detection time can be computed automatically. Add a fault-free reference run to the regression suite so later changes to the layer are checked.

   Checkpoint: A no-fault run identical to the original model, and each fault type visible in logged signals when enabled.

3. 3

   Implement range and rate checks

   For each sensor's lead-object distance, relative speed and azimuth, add range checks against sensor specifications and rate checks against physical limits, for example distance change per cycle bounded by maximum relative speed times cycle time plus margin. Add debounce counters. Tune thresholds on fault-free runs across many scenarios so that no false alarms occur, then record the margin. Keep thresholds as named parameters so they can be tuned later without editing blocks.

   Checkpoint: Zero false alarms across the fault-free scenario set, with documented thresholds and margins.

4. 4

   Implement cross-sensor checks

   Associate radar and camera objects by gating on position, then compare distance and relative speed of the matched lead object. Flag disagreement beyond a tolerance that grows with distance, because camera range accuracy falls with distance. Handle the case where only one sensor sees the object for a short time, such as during a cut-in, without raising an alarm too early.

   Checkpoint: Cross-sensor check flags injected offsets and stays silent during cut-in scenarios without faults.

5. 5

   Implement a model-based check

   Run a constant-acceleration Kalman filter on the fused lead-object track using the Sensor Fusion and Tracking Toolbox, and compute the normalised innovation squared for each new measurement. Flag measurements whose innovation exceeds a chi-square threshold for several cycles. This catches faults that stay within range and rate limits but break motion consistency, such as slow drifts and ghost objects. Record the chosen chi-square threshold and the reasoning behind it.

   Checkpoint: Model-based check detects a slow drift that range and rate checks miss, shown in a comparison plot.

6. 6

   Design the degraded-mode manager

   In Stateflow, define modes: Full (both sensors trusted), RadarOnly and CameraOnly (one sensor trusted, limited deceleration and larger gap), Limited (warning only) and Off (function disabled with driver takeover request). Define transitions from check results, with entry actions for HMI warnings and command ramps to avoid sudden changes. Add recovery rules with hysteresis so modes do not chatter. Check every transition with a short test sequence before connecting the chart to the full model.

   Checkpoint: A Stateflow chart that passes unit tests for every transition, including recovery.

7. 7

   Build closed-loop scenarios

   In Driving Scenario Designer, build scenarios: steady following, lead braking at several levels, cut-in, cut-out revealing a stopped vehicle, curved road and stop-and-go traffic. Parameterise speeds and distances to create a scenario set of at least 50 variants. Run each fault-free to confirm the function works and record baseline time-to-collision margins. Store the scenario variants with their parameters so campaigns can be rerun exactly. Include at least one low-speed urban case.

   Checkpoint: A scenario set with fault-free results showing no collisions and recorded TTC margins.

8. 8

   Run fault-injection campaigns

   Using Simulink Test, run every fault type at several magnitudes and start times across the scenario set. Compute for each run: detected or not, detection time compared with the fault-tolerant time interval, mode reached, collision or minimum TTC, and any false alarms. Use parallel simulation to keep run time manageable, and store results in a table. Keep the raw logs of failed runs so detection delays can be examined in detail.

   Checkpoint: A results table with detection outcome, time and vehicle-level effect for every injected run.

9. 9

   Analyse coverage and trade-offs

   Compute diagnostic coverage per fault type and per check, detection time distributions and false-alarm rate on fault-free runs. Plot how debounce length trades detection time against false alarms. Measure functional availability as the share of time in Full mode across fault-free runs. Identify faults detected too late and propose changes, then rerun to show the improvement. Report results per check as well as combined, so the contribution of each mechanism is visible.

   Checkpoint: Coverage, detection-time and availability results with at least one improvement shown by rerun.

10. 10

    Report

    Present the fault model, checks, degraded-mode design, scenarios, campaign results and trade-off analysis, with traceability from requirements to mechanisms and tests. State that coverage values come from simulated faults on models and are not hardware diagnostic coverage figures. Discuss which faults remain hard to detect, such as common-cause errors affecting both sensors in the same way. Include the requirement-to-test traceability report exported from the toolboxes.

    Checkpoint: A report with traceable mechanisms, quantified results and honest limitations.

Testing & validation

• No false alarms on the fault-free scenario set at chosen thresholds.
• Detection time compared with the fault-tolerant time interval for each fault type.
• Diagnostic coverage per fault type and check from fault injection.
• Vehicle-level outcome (collision, minimum TTC) for every injected fault.
• Functional availability in fault-free operation.

Expected results

A set of plausibility checks and a degraded-mode manager for an ACC/AEB function, verified by fault-injection campaigns with measured detection times, coverage, false alarms and availability.

Take it further

• Generate code for the checks with Embedded Coder and measure execution time on a target.
• Add a learned anomaly detector and compare with the rule-based checks.
• Add environmental conditions that degrade camera performance to study SOTIF effects.
• Formally verify mode-manager properties with Simulink Design Verifier.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.