autoware_diagnostic_graph_aggregator

Overview

The diagnostic graph aggregator node subscribes to diagnostic array and publishes aggregated diagnostic graph. As shown in the diagram below, this node introduces extra diagnostic status for intermediate functional units.

Diagnostic graph structures

The diagnostic graph is actually a set of fault tree analysis (FTA) for each operation mode of Autoware. Since the status of the same node may be referenced by multiple nodes, the overall structure is a directed acyclic graph (DAG). Each node in the diagnostic graph represents the diagnostic status of a specific functional unit, including the input diagnostics. So we define this as “unit”, and call the unit corresponding to the input diagnosis “diag unit” and the others “node unit”.

Every unit has an error level that is the same as DiagnosticStatus, a unit type, and optionally a unit path. In addition, every diag unit has a message, a hardware_id, and values that are the same as DiagnosticStatus. The unit type represents how the unit status is calculated, such as AND or OR. The unit path is any unique string that represents the functionality of the unit.

NOTE: This feature is currently under development. The diagnostic graph also supports “link” because there are cases where connections between units have additional status. For example, it is natural that many functional units will have an error status until initialization is complete.

Operation mode availability

For MRM, this node publishes the status of the top-level functional units in the dedicated message. Therefore, the diagnostic graph must contain functional units with the following names. This feature breaks the generality of the graph and may be changed to a plugin or another node in the future.

• /autoware/operation/stop
• /autoware/operation/autonomous
• /autoware/operation/local
• /autoware/operation/remote
• /autoware/operation/emergency-stop
• /autoware/operation/comfortable-stop
• /autoware/operation/pull-over

Interfaces

Parameters

Examples

This is an example of a diagnostic graph configuration. The configuration can be split into multiple files.

• main.yaml
• module1.yaml
• module2.yaml

ros2 launch autoware_diagnostic_graph_aggregator example-main.launch.xml

If you want to share the same settings with a configuration that is missing some diagnostics due to differences in variations, we recommend that you unify the diagnostics by using dummy_diag_publisher, etc.

Debug tools

• tree
• autoware_diagnostic_graph_utils

Graph file format

• graph
• path
• unit

Changelog for package autoware_diagnostic_graph_aggregator

0.53.0 (2026-09-29)

• Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog

• docs(diagnostic_graph_aggregator): fix evaluation description (#13441) docs(autoware_diagnostic_graph_aggregator): fix evaluation description for [or]{.title-ref} object

• fix: diagnostic graph aggregator remove edit (#13402)

  • throw validation error

  * fix remove process ---------

• fix(design): align the system node designs with the packages they describe (#13338)

  * fix(design): declare the fixed-name interfaces of the system node designs as remap targets The diagnostic graph ports, the diagnostics array publisher and the automatic pose initializer's localization interfaces are pinned with global:, which keeps them out of the design graph: link_manager skips any connection whose target is a global input port and the exporter emits no remap. remap_target: keeps the same fixed topic and service names while letting the ports take part in the graph.

  * feat(autoware_default_adapi_universe): add node designs for the AD API nodes The package builds fifteen AD API components with no design of their own, so a system that composes the AD API from design modules cannot reference them.

  * feat(design): add the diagnostic graph and component state monitor node designs autoware_component_state_monitor and autoware_diagnostic_graph_aggregator build three components with no design of their own: the state monitor that aggregates topic monitor diagnostics into per-component availability, the aggregator that turns /diagnostics into the diagnostic graph, and the converter that derives operation mode availability from it. DiagnosticGraphLogging and ProcessingTimeChecker declare the parameters their launchers pass, which have no package param file to come from. ---------

• feat(autoware_diagnostic_graph_aggregator): enable to remap set initializing (#12757) fix: enable to remap

• feat(diagnostic_graph_aggregator): split available and continuable flags (#13252)

• feat(diagnostic_graph_aggregator): apply [agnocast_wrapper::Node]{.title-ref} to diagnostic_graph_aggregator (#12843)

  • apply agnocast_wrapper::Node
  • use AgnocastOnlyCIE
  • fix service ptr
  • fix
  • apply to driving_mode_mapping

  * refactor: use plain const reference subscription callbacks autoware_agnocast_wrapper now accepts rclcpp-style const MessageT & callbacks (autowarefoundation/autoware_core#1228), so the subscription callbacks no longer need wrapper-specific message pointer types.

  * style(diagnostic_graph_aggregator): add missing <utility> include for std::move ---------Co-authored-by: atsushi yano <<55824710+atsushi421@users.noreply.github.com>> Co-authored-by: atsushi421 <<atsushi.yano.2@tier4.jp>>

• Contributors: Autumn60, Koichi Imai, Ryohsuke Mitsudome, Taekjin LEE, Takagi, Isamu, Tetsuhiro Kawaguchi

0.52.0 (2026-06-30)

• Merge remote-tracking branch 'origin/main' into tmp/bot/bump_version_base

• feat(diagnostic_graph_aggregator): add driving mode interface (#12760)

  • add driving mode interface

  * remove unused variable ---------Co-authored-by: Junya Sasaki <<junya.sasaki@tier4.jp>>

• feat(diagnostic_graph_aggregator): add override feature (#12621)

  • add override level
  • fix override logic

File truncated at 100 lines see the full file