Modular Fault Diagnosis Framework for Complex Autonomous Driving Systems

In plain words

A self-driving vehicle is made of many parts: sensors, localization, perception, planning and more. Each part can break in its own way, and a broken sensor can make later parts look broken too. The paper proposes a fault diagnosis system built from small, separate checkers. Each checker watches one part and reports whether that part is fine, degraded, failed, irrelevant right now or unknown.

Those reports are then grouped by component and linked along the dependencies between components. If a component fails, the parts that rely on it are shown as ignored rather than as separately broken, so the person in the vehicle can see where the fault starts. The system also knows the vehicle's current driving state, so parts that are not needed while the vehicle waits at a stop are not flagged. The authors ran this on their research shuttle buses in a set of example faults. They did not measure accuracy or speed.

TL;DR

• A concept for a modular fault diagnosis framework for autonomous driving (AD), with a classification scheme for diagnosis modules §1 §4.2 fig. 2.
• Each module maps its result to one of five states: OK, WARNING, ERROR, IGNORE or UNKNOWN §4.3.
• Aggregators combine module states per component, and dependency edges propagate errors. The driving state also gates Planning and Execution §5.1 §5.2 §6.
• Implemented on FZI AD shuttle buses, with six qualitative fault scenarios and no metrics §5 §6.
• No official code. Several rules are not fully specified; see Pitfalls.

Problem

AD software is built from heterogeneous parts, some rule-based and some learned, that pass data along a chain. Errors therefore spread between parts §1. The authors also argue that the set of components, use cases and vehicle states keeps changing, so a single monolithic diagnosis is hard to maintain §4.1. A safety operator, who may be a non-expert in public transport, needs a comprehensible view of what is wrong and where §5 §5.3.

The paper's stated goals for modularity are scalability, customization, fault isolation, maintenance, and verification and validation §4.1.

Method

The framework has three parts: diagnosis modules, state-aware aggregation and an operator interface. The concept is described in general terms §4. The shuttle implementation is described in §5.

1. Terminology §3. A fault is a state or property of the system, not an event. An error is incorrect output, and a failure is an event where the system can no longer perform its required function. A diagnosis system detects faults and failures. The paper follows standard dependability terms §3.

2. Classification of modules §4.2 fig. 2. Modules are classified along three axes:

1. Diagnosis location: an isolated module watches one component or data stream; a contextual module compares several parts. The paper notes that context helps but can itself be faulty §4.2.
2. Type of information: content (the data itself, such as sensor values or object lists) or meta-information (such as message frequency or latency) §4.2.
3. Data flow: sequential, where data is checked along a chain of components, or parallel, where independent sources are compared §4.2.

3. Diagnostic states §4.3. Every module and group reports one of five states:

1. OK: normal and safe operation.
2. WARNING: abnormal behaviour that is a pre-failure, without immediate loss of function.
3. ERROR: a severe malfunction that affects safety or reliability.
4. IGNORE: the part is irrelevant for the current diagnosis.
5. UNKNOWN: the state cannot be determined.

4. Diagnosis modules §4.4. The paper lists five common kinds of module:

1. Component self-state: the component reports its own quality, such as a localization accuracy estimate §4.4.
2. Message frequency or latency: channel timing and component response times §4.4.
3. Single value: a numeric or boolean value compared with a threshold §4.4.
4. Component watchdog: a reachability probe, for example an ICMP echo request §4.4.
5. Domain-specific diagnosis: a custom check, for example one that validates object detections against a model of object behaviour §4.4.

5. Aggregation §4.5 §5.1. Module states are collected into groups that represent subsystems. A group reports OK only if all its submodules report OK; otherwise it reports WARNING or ERROR §4.5. Aggregators can contain aggregators, so the graph can be nested §5.1. A dependency-aware analyzer adds edges between groups: when a group fails, the error goes to the groups that depend on it. Traversing this graph from the faulty component gives the root cause §5.1.

6. Driving state §5.2 fig. 5. The shuttle runs a state machine over start-up, idling, driving and shut-down §5.2. Until the safety operator logs in, no diagnostics run §5.2. Localization needs manual operator input, and Perception and Prediction start after it §5.2. Planning and Execution start only after a mission and goal are set and the operator has cleared the vehicle §5.2. A Mission component sets the Active flag, which the paper uses to switch Planning and Execution diagnosis on and off fig. 5 §6.

7. Operator interface §5.3 fig. 4 fig. 5. The display shows eight groups: Sensors, Localization, Perception, Prediction, Mission, CAN, Planning and Execution §5.3. Dependent groups are shown in grey with the label "Ignored" when a parent is in ERROR fig. 4.

8. Countermeasures §5.4. On ERROR in a component that the maneuver needs, the vehicle decelerates at 1 m/s² immediately. For a non-vital failure, the maneuver module plans a deceleration that accounts for static and dynamic objects. The operator always sees the current group states. The system keeps up to 30 s of past data for each incident §5.4.

# Collapse module states into one group state  [§4.5] [§6]
# Input:  module_states: list of OK, WARNING, ERROR, IGNORE, UNKNOWN
# Output: one state for the group

def group_state(module_states):
    # Any ERROR makes the group ERROR  [§6]
    if ERROR in module_states:
        return ERROR
    # Any WARNING makes the group WARNING  [§6]
    if WARNING in module_states:
        return WARNING
    # OK only if every module reports OK  [§4.5]
    if all(state == OK for state in module_states):
        return OK
    # A mix of OK with IGNORE or UNKNOWN is not defined  [§4.5]
    raise NotImplementedError

# Dependency- and driving-state-aware display  [§5.1] [§5.2] [§6]
# Input:  group_states: dict group -> state
#         parents: dict group -> groups it depends on
#         active: bool, the driving state flag
# Output: dict group -> state shown to the operator

def display_states(group_states, parents, active):
    shown = dict(group_states)
    # Outside AD mode, Planning and Execution are not diagnosed  [§5.2] [fig. 5]
    if not active:
        for group in ["Planning", "Execution"]:
            shown[group] = IGNORE
    # A group whose parent is in ERROR is shown as IGNORE  [§6] [§5.1]
    for group in group_states:
        for parent in parents[group]:
            if group_states[parent] == ERROR:
                shown[group] = IGNORE
    return shown

# Countermeasure for a group that is WARNING or ERROR  [§5.2] [§5.4]
# Input:  state: group state, vital: bool, needed by the maneuver
# Output: request to the maneuver module

def react(state, vital):
    if state not in (WARNING, ERROR):
        return
    # Vital ERROR: decelerate immediately at 1 m/s^2  [§5.4]
    if vital and state == ERROR:
        request_deceleration(1.0)  # m/s^2
        return
    # Non-vital failure: maneuver plans a safe deceleration  [§5.4]
    # that accounts for static and dynamic objects  [§5.4]
    if not vital:
        request_safe_deceleration()
    # Vital WARNING: the response is not stated  [§5.4]
    # Keep up to 30 s of past data for the incident  [§5.4]
    save_recording(seconds=30)  # s

Hyperparameters

The paper has no trained model and no learning hyperparameters. The table lists the numeric values and rules it states.

Results

Author-reported, qualitative only. Setup: FZI AD shuttle bus; faults induced in the sensors, localization and planner; no baseline, dataset, metric or timing numbers §6. Six scenarios are shown as panels in fig. 6a–fig. 6f. The text numbers scenarios 1 to 6, and panel letters follow the order of the figure's files.

The paper gives no false-alarm rate, detection delay in seconds, coverage over fault types, or comparison with other diagnosis systems. The text says the approach "demonstrates" its capabilities. Those claims rest on these six runs.

Paper vs code

No official code.

The paper names no code repository, project page or artifact link. Its arXiv metadata has no code link [raw/arxiv/2411.09643.json]. The search covered the authors' GitHub organisation (fzi-forschungszentrum-informatik) with queries for diagnosis, diagnostic, aggregator, fault diagnosis and shuttle. The only hit was fzi-forschungszentrum-informatik/diagnostics_display, a ROS diagnostics viewer that lists no licence. The paper does not link it and it does not implement the described aggregation, so it was not used. Broader GitHub searches for "modular fault diagnosis" and "fault diagnosis autonomous driving" returned nothing.

Pitfalls

• No numbers to check. Thresholds, window sizes, timing and detection rates are not stated. An implementer must choose them, and the paper gives no basis for the choice.
• Two aggregation rules. Section 4.5 says a group is OK only if all submodules are OK. The evaluation (§6) aggregates with OR, so a group is ERROR if any module is ERROR and WARNING if any is WARNING. Neither section says how IGNORE and UNKNOWN combine inside a group. The group_state pseudocode leaves that case undefined on purpose.
• Propagation rules are partly defined. The paper says a group whose parent is in ERROR becomes IGNORE §6. It does not say whether this is transitive through several levels, whether the check uses raw or already-ignored parent states, or what happens to a group with two parents in different states.
• Propagation is not instant. In scenario 2, Localization is briefly ERROR before IGNORE, because one submodule detects the fault first §6 fig. 6b. An implementer should expect transient states, not only final ones.
• Dependency graph only partly in text. Dependencies of Planning and Execution and the fan-out of Sensors are described in words §5.1. The full edge list is only in the figure fig. 5, which is not reproduced here.
• Vital WARNING. The paper defines the ERROR response for vital components §5.4. The response to a vital WARNING is not stated. react leaves it open.
• "In any case" recording. The paper says data is recorded for 30 s "in any case" §5.4. The pseudocode reads this as any WARNING or ERROR. The paper does not say whether OK periods are recorded.
• Driving states are incomplete. The text lists start-up, idling, driving and shut-down §5.2 and names the Active switch. It does not define the transition conditions or the shut-down behaviour.
• Modules are not specified. The tf_quality module uses a localization diagnosis from another paper §6 [orf_modeling_2022], which is not described here. The other modules are named but their checks are not described, so the names alone are not enough to implement them.
• Figure numbers. Figure numbers were counted in source order: entry (fig. 1), classification scheme (fig. 2), overview (fig. 3), planner warning (fig. 4), detail (fig. 5), evaluation (fig. 6 with panels a to f). Panel letters are assigned by file order, because the subfigures have no captions.
• Scenario mapping in the text. Line 55 of the evaluation source ties scenario 6 to the panel file scenario_4, while the panel for scenario 6 is scenario_5 §6. The card follows the panel file names.
• Scope of the classification. The three-axis scheme §4.2 is motivated, but it is illustrated with examples only. No module is classified in a table, and no experiment tests the scheme.
• Operator. The design assumes a safety operator in the vehicle who must be able to read the display §5.3. The paper says the framework could be adapted to service robots or control centres, but it gives no design for that §5.1.

Lineage

• Builds on: the authors' earlier conceptual diagnostic system for AD [orf_level_2020], which the paper says forms its basis §2. The localization diagnosis used by the tf_quality module is from the authors' localization-uncertainty work [orf_modeling_2022] §6.
• Related work, compared in §2: an integrated model-based diagnosis and repair architecture on ROS [zaman_integrated_2013]; a robotics fault detection and diagnosis architecture [khalastchi_fault_2019]; an AD framework focused on sensor self-diagnosis [min_fault_2023]; a failure analysis of unmanned ground vehicles, based mainly on causes [carlson_how_2005]. The paper contrasts its scheme with the cause-based classification in [carlson_how_2005].
• Shares the dependability terms of [avizienis_dependability_1992] and [isermann_supervision_2006] §3.
• Superseded by: not stated.