16.5 DDS Communication Errors

Go To Top

Return to Exception Handling

DDS communication errors can affect discovery, type generation, participant initialization, publisher creation, subscriber creation, QoS compatibility, Topic communication, and runtime interoperability. The team should handle DDS errors as first-class runtime and validation concerns.

DDS error handling should identify:

1. Missing or invalid DDS environment setup.
2. DDS participant creation failure.
3. Domain or discovery failure.
4. Publisher or subscriber creation failure.
5. Topic registration failure.
6. Type-support or generated-binding failure.
7. QoS incompatibility.
8. Message publication failure.
9. Message reception failure.
10. Liveliness, deadline, or durability-related failures, where applicable.
11. Vendor-specific runtime errors.

When DDS communication fails, the Node or script should log the failure with enough context to identify the DDS product, Configuration source, Topic, type, participant, and operation where practical. If the error affects Node operation, the Node should publish Degraded, Recovering, or Failed status where possible.

If a phase supports multiple DDS products, error handling should preserve product-specific detail without turning vendor-specific behavior into undocumented Baseline behavior. The applicable tool Baseline checklist instance and validation Evidence should identify which DDS products and interoperability combinations the team tested.