autoware_generic_service_divider

Purpose

Autoware can be deployed in a redundant configuration, where the same set of nodes runs more than once, typically in separate ROS 2 domains (for example a main ECU and a sub ECU) so that one side can take over when the other fails.

Service calls do not fan out on their own. A topic publisher reaches every subscriber, but a service client talks to exactly one server. That is a problem for the control-plane services that must be applied to both sides at the same time, such as changing the operation mode, requesting a control mode, or resetting the diagnostic graph. Without a fan-out mechanism every caller would have to know how many redundant instances exist, hold one client per instance, call them all, and then decide what to answer when only some of them succeed.

This node advertises a single input service, forwards each incoming request to N configured output services, waits for all of them, and returns one aggregated response to the original caller. Callers stay unaware of the redundancy, and the fan-out policy is concentrated in one place.

                          +---------------------------------------+
                          |        generic_service_divider        |
 caller --request--> /system/operation_mode/change_operation_mode  |
                          |            |                          |
                          |            +--> /main/system/operation_mode/change_operation_mode
                          |            |         (primary, timeout 200 ms)
                          |            +--> /sub/system/operation_mode/change_operation_mode
                          |            |         (timeout 500 ms)
 caller <--response-- aggregated result |                          |
                          +---------------------------------------+

Inner-workings / Algorithms

Architecture

The node itself contains no service-specific logic. Everything is driven by divider plugins loaded through pluginlib.

Because the request payload is handled as std::shared_ptr<void>, message allocation and initialization are resolved at runtime from the type string (for example autoware_system_msgs/srv/ChangeOperationMode) through rosidl_typesupport_introspection_cpp. Adding support for a new service type therefore does not require any change to the fan-out logic.

Startup gating (fail-closed)

setup_service_division() creates one GenericClient per output service and then calls try_start_input_service().

The input service is advertised only after every output service server is available. While any output server is missing, the node

• does not advertise the input service, so callers see “service not available” instead of a request that silently reaches only a subset of the outputs,
• retries every 500 ms with a wall timer,
• logs Service divider: waiting for output service servers before advertising '<input>' (ready=k/n, waiting=[...]) at most once per 5 s, and
• reports ERROR on the diagnostic status.

Once every output server is ready, the input service is advertised, the retry timer is cancelled, and the node logs Service divider: <input> -> <n> outputs (type: <service type>).

Request forwarding

For each incoming request the base class

1. creates a pending division and registers it under an incrementing id that appears in every related log line as Service divider[<id>],
2. forwards the unmodified request to every output service concurrently, and
3. arms a per-output wall timer with that output’s timeout_ms.

Each output client is placed in its own MutuallyExclusive callback group, and the input service is placed in a Reentrant callback group, so concurrent input calls are tracked independently. The node executable runs on a MultiThreadedExecutor.

Whichever comes first, the response callback or the timeout timer, marks the output as completed through mark_output_completed(); the loser of that race returns without touching the state. When the last output completes, the timers are cancelled and the response is finalized.

Response aggregation

Success is judged per service type by the plugin through is_response_success(), for example response.status.success or response.success. Error responses are built by the plugin through create_error_response(); for service types that carry autoware_common_msgs/msg/ResponseStatus, the code is set to ResponseStatus::SERVICE_TIMEOUT.

Inputs / Outputs

The service names below are the defaults in config/generic_service_divider.param.yaml. All of them are configurable, and a service pair exists only when its plugin is listed in the plugins parameter.

Input / Output services

Diagnostics

The node publishes the diagnostic status service_startup_readiness with the hardware id generic_service_divider, and forces an update at 1 Hz.

| Key | Value | | ———————————— | —————————————————————- |

File truncated at 100 lines see the full file

Changelog for package autoware_generic_service_divider

0.53.0 (2026-09-29)

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

• feat: add autoware generic service divider (#12745)

  • feat: add node
  • style(pre-commit): autofix
  • feat: add ekf trigger node
  • fix(generic_service_divider): add log and fix trigger_node name
  • style(pre-commit): autofix
  • feat(generic_service_divider): wait all server
  • feat(generic_service_divider): add diag
  • feat(generic_service_divider): add control mode request plugins
  • style(pre-commit): autofix
  • fix: pre-commit
  • fix: refactor
  • feat: add README.md
  • fix(autoware_generic_service_divider): fix response finalization race and document known limits (#12)

  * fix(autoware_generic_service_divider): fix response finalization race and request registration order Four fixes found while reviewing the package:

  * [try_finalize_response()]{.title-ref} decided whether the division was complete from [awaiting_count]{.title-ref} alone. [mark_output_completed()]{.title-ref} releases [pending->mutex]{.title-ref} before its caller re-acquires it in [try_finalize_response()]{.title-ref}, so when the last two outputs complete on different threads both can observe [awaiting_count == 0]{.title-ref} and finalize the same request, sending a second response for the same [rmw_request_id_t]{.title-ref}. Add a [finalized]{.title-ref} flag guarded by [pending->mutex]{.title-ref} so finalization runs exactly once. This also covers the [catch]{.title-ref} path in [forward_request()]{.title-ref}, which called [try_finalize_response()]{.title-ref} without checking the [mark_output_completed()]{.title-ref} return value.

  * [GenericClient::async_send_request()]{.title-ref} called [rcl_send_request()]{.title-ref} outside [pending_requests_mutex_]{.title-ref} and only then inserted the pending entry, so a response arriving before the insert was dropped by [handle_response()]{.title-ref} and the division could only end through the timeout path. Hold the mutex across both, matching upstream [rclcpp::GenericClient]{.title-ref}.

  * Rename the [trigger_node]{.title-ref} configuration block to [ekf_trigger_node]{.title-ref}, the prefix [EkfTriggerNodeDivider]{.title-ref} actually reads. Enabling that plugin with the old block name produced a divider with no outputs, which still advertises its input service but never sends any response.

  * Align the hardcoded default for [reset_redundancy_switcher.input_service]{.title-ref} with the shipped configuration and the README. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>

  * docs(autoware_generic_service_divider): document configuration pitfalls and future work Extend "Assumptions / Known limits":

  * [primaries]{.title-ref} is not validated: omitting it, or marking no output primary, makes every call return "Primary service did not respond" even when all outputs succeeded, with no startup warning.

  * A plugin whose configuration block is missing or misnamed falls back to an empty output list, advertises its input service and then never replies.

  * Output service names must be unique within a plugin, otherwise the outstanding-response counter never reaches zero and the caller hangs.

  * A total plugin load failure is reported as OK by [service_startup_readiness]{.title-ref}, so [plugin_count]{.title-ref} has to be checked against the configured list. Drop the note about the unused [trigger_node]{.title-ref} block, which is now renamed. Add a "Future work" section covering the stale entries in [GenericClient::pending_requests_]{.title-ref} and the fail-open startup diagnostics. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>> ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> ---------Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com> Co-authored-by: Makoto Kurihara <<mkuri8m@gmail.com>> Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>

• Contributors: Ryohsuke Mitsudome, Tetsuhiro Kawaguchi