{"id":40916993,"url":"https://github.com/rticommunity/rticonnextdds-usecases-act","last_synced_at":"2026-01-22T03:16:40.633Z","repository":{"id":308185722,"uuid":"1016166325","full_name":"rticommunity/rticonnextdds-usecases-act","owner":"rticommunity","description":"Autonomous Collaborative Teaming(Maritime ISR) Reference","archived":false,"fork":false,"pushed_at":"2026-01-02T23:48:27.000Z","size":7963,"stargazers_count":0,"open_issues_count":1,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2026-01-09T05:42:33.182Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/rticommunity.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-07-08T15:30:47.000Z","updated_at":"2025-12-10T16:00:52.000Z","dependencies_parsed_at":"2025-08-04T19:06:32.042Z","dependency_job_id":"f5465400-9bf3-4fe8-89d8-eb9c02146527","html_url":"https://github.com/rticommunity/rticonnextdds-usecases-act","commit_stats":null,"previous_names":["rticommunity/rticonnextdds-usecases-act"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/rticommunity/rticonnextdds-usecases-act","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rticommunity%2Frticonnextdds-usecases-act","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rticommunity%2Frticonnextdds-usecases-act/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rticommunity%2Frticonnextdds-usecases-act/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rticommunity%2Frticonnextdds-usecases-act/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/rticommunity","download_url":"https://codeload.github.com/rticommunity/rticonnextdds-usecases-act/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rticommunity%2Frticonnextdds-usecases-act/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28652050,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-22T01:17:37.254Z","status":"online","status_checked_at":"2026-01-22T02:00:07.137Z","response_time":144,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-22T03:16:40.560Z","updated_at":"2026-01-22T03:16:40.616Z","avatar_url":"https://github.com/rticommunity.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Overview \nRouting Service architecture for Autonomous Collaborative Teaming use case to  \nmanage message flow between Platforms and C2(Command and Control) stations.\n\nThis use case is centered around a Maritime ISR scenario but can be adopted for  \nother similar needs.\n\n## Use Case Requirements:\n- Platforms must be able to receive select topics from C2 [C2 Events](#c2-events)\n- Platforms must be able to receive *only* commands addressed to a destination [C2 Filtered Commands](#filtered-commands)\n- *Only* any C2 must be able to receive select topics from Platforms [Platform Events](#platform-events)\n- C2 must be able to receive select *downsampled* topics from Platforms [Platform Status](#platform-status) \n- Platforms must be able to receive select topics from other Platforms [Platform to Platform](#platform-to-platform)  \n- All Platforms and C2 have automatic discovery of other Platforms and C2 endpoints\n\n## Network Architecture\nThe system has been separated into 3 DDS domains:\n- Platform (Vehicle or Platform network)\n- WAN (Communications network i.e. Sat, Mesh Radio)\n- C2 (C2 Network- Groundstations etc.)\n\nRouting Service acts as a relay mechanism between the *internal* LAN and  \nthe *external* WAN DDS Domain.\n\nThis allows For Network level isolation of messaging as DDS Domains isolate  \nthrough unique port range allocation.\n\n## Features\nThis infrastructure performs the following roles:\n- Dynamic instantiation of readers/writers based on a regex match filter per *Channel*.\n- Dynamic application of QoS per *Channel*\n- Segmentation of traffic at the network layer(using DDS Domains) between LAN and WAN environments\n- Routing of selected topics between the following per *Channel*:\n  - Platform -\u003e C2\n  - C2 -\u003e Platform\n  - Platform \u003c-\u003e Platform\n- Dynamic discovery of Platforms/C2 systems\n- Dynamic pub/sub architecture of one-to-many/many-to-one between C2 and Platforms\n- Dynamic Partitioning/Grouping of Platforms/C2 nodes for isolation at runtime\n\n\n## Transports\nCurrently the transport over the WAN is configured to use Multicast UDPv4 for discovery and unicast UDPv4  \nfor data flow. This can be changed with XML configuration to use other options such as:\n- Unicast UDPv4 for Discovery (IP addresses, DNS Domain names or a [Discovery Service](https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/addon_products/cloud_discovery_service/index.html))  \n- [TCP](https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/PartTCP.htm)  \n- [UDPv6](https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/Setting_Builtin_Transport_Properties_wit.htm#Table_PropertiesForBuiltinUDPv6Transport)  \n- [Real Time WAN transport for NAT traversal etc.](https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/PartRealtimeWAN.htm)  \n\n\n## Network Settings\nConnext by default will attempt to use all Network Interfaces provided by the OS.  \nHowever as required, interfaces can be constrained with [allow/deny lists](https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/Setting_Builtin_Transport_Properties_wit.htm#Table_PropertiesBuiltinUDPv4Transport) and [prioritized](https://community.rti.com/kb/how-do-i-restrict-and-prioritize-interfaces-rti-connext-use) using max_interfaces_list.  \nConnext also has the ability to [move message fragmentation to the DDS layer](https://community.rti.com/static/documentation/connext-dds/7.5.0/doc/manuals/connext_dds_professional/users_manual/users_manual/LargeData_Fragmentation.htm) in situations where a low MTU size is causing   \nexcessive IP fragment re-assembly errors.\n\n## Directions\nDefault configurations are set at the top of `router_config/routing_service_config.xml`  \nwithin the `\u003cconfiguration_variables\u003e` tag section.\n\nA reference start script `./start_router.sh` has been included to highlight example usage.\n\nAll configurations in the Routing Service config file can be overridden using ENV variables.\n\nAn end user would only need to modify the high level variables in the start script  \nand not even touch the xml file.\n\n\nThe QoS has been setup in `./qos/act_qos_lib.xml` for 2 common patterns of   \n- Status (Periodic data)\n- Events (Aperiodic data i.e. Commands/ContactReports- \"ensure delivery\" [RELIABLE](#reliable-delivery))\n\nSee Block Diagram below:\n![ACT Routing Architecture](/images/act_routing_arch.jpeg)\n\n\n\n\n## RELIABLE delivery\nFor data that is sent Aperiodically such as Commands and Events, we want to ensure  \ndelivery of the message.  \nWe do this by applying a resend mechanism (RELIABILTY QoS: RELIABLE) that we can adjust  \nat the user space level.\n\nThis allows us to control different data \"channels\" behaviour separately as needed.\n\nMore info see [manual](https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/RELIABILITY_QosPolicy.htm#sending_2410472787_2023245).  \n\n## BEST_EFFORT delivery\nFor data that is sent Periodically such as Status updates, we generally aren't  \ntoo concerned if we miss a sample as there will be another one coming along shortly.  \n\nFor this data pattern we set the Reliability QoS to BEST_EFFORT.  \n\nThis allows us to control different data \"channels\" behaviour separately as needed.\n\nMore info see [manual](https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/RELIABILITY_QosPolicy.htm#sending_2410472787_2023245).  \n\n\n## Data \"Channels\"\nIn `./start_router.sh` you will see a section titled \"Data Channels\".  \nThese variables are used to move selected topics from the Platform to C2  \nand apply the appropriate QoS per Data Pattern such a Status(Periodic, [BEST_EFFORT](#best_effort-delivery))  \nand Event(Aperiodic, [RELIABLE](#reliable-delivery)).  \n\nBy using these \"*Channels*\" in the Start Routing script, you can abstract away lower  \nlevel configuration/management and just focus on selecting the right \"*Channel*\" for your  \nTopic to be added into.  \n(REGEX matching is used including wildcards so `*Status` will match with any prefix.)    \n\n### Data Channels Logical View\n![ACT Data Channels Logical View](/images/act_channels.jpeg)\n\n\n## C2 Events\nIn `start_router.sh`, the `C2_EVENT_CHANNEL` [Channel](#data-channels) is used to move topic   \nmessages(i.e.\"ContactReport\") to *only* Platforms.\n\nQoS applied to this [Channel](#data-channels) is `event_qos` configured for Reliability QoS kind:[RELIABLE](#reliable-delivery)  \nwith the assumption the data is being sent aperiodically.\n\n\n### Test:\nIn `start_router.sh`, ensure the `ContactReport` topic is assigned to the  \n`C2_EVENT_CHANNEL` [Channel](#data-channels) .\n\n1. Start Platform-10 sim\n- `source ./platform_10.sh`\n-  `./start_sim.sh`  \n\n2. Start Platform-10 Routing Service\n- `source ./platform_10.sh`\n- `./start_router.sh`  \n\n3. Start a second Platform sim (Platform-11) in a different DDS Domain  \n*NOTE: This isolates this Platform from the other one similar to a VLAN to  \nsimulate physical isolation*\n- `source ./platform_11.sh`\n-  `./start_sim.sh`  \n\n4. Start Platform-11 Routing Service\n- `source ./platform_11.sh`\n- `./start_router.sh`  \n\n5. Start C2-20 sim\n- `source ./c2_20.sh`\n-  `./start_sim.sh`  \n\n6. Start a C2-20 Routing Service\n- `source ./c2_20.sh`\n- `./start_router.sh`  \n\n#### Pass criteria:\n- Ensure the `C2_EVENT_CHANNEL` topics are *only* received on Platforms from C2 source type\n\n\n## Filtered Commands\nIn `start_router.sh`, the `C2_COMMAND_FILTER_CHANNEL` [Channels](#data-channels) is used to move  \nthe \"Command\" topic messages from the C2 to *only* the addressed PLATFORM.\n\nThe QoS applied for this route across the WAN is the `WAN_EVENT_QOS` which sets  \nthe Reliability QoS to kind: [RELIABLE](#reliable-delivery)\n\nA Content Filter has been applied on the `destination` field in  \n`routing_service_config.xml` `wan_to_platform` route.\n\nThis filters at the *writer* side i.e. only the message to the destined PLATFORM is  \nsent and the other PLATFORM's are ignored.\n\nThis example is set up so the `ROUTER_NAME` in `platform_10.sh` matches the destination  \nof `c2_20.sh`\n\n### Test:\nIn `start_router.sh`, ensure the `C2Command` topic is assigned to the \n`C2_COMMAND_FILTER_CHANNEL` [Channel](#data-channels) .\n\n1. Start Platform-10 sim\n- `source ./platform_10.sh`\n-  `./start_sim.sh`  \n\n2. Start Platform-10 Routing Service\n- `source ./platform_10.sh`\n- `./start_router.sh`  \n\n3. Start a second Platform sim (Platform-11) in a different DDS Domain  \n*NOTE: This isolates this Platform from the other one similar to a VLAN to  \nsimulate physical isolation*\n- `source ./platform_11.sh`\n-  `./start_sim.sh`  \n\n4. Start Platform-11 Routing Service\n- `source ./platform_11.sh`\n- `./start_router.sh`  \n\n5. Start C2-20 sim\n- `source ./c2_20.sh`\n-  `./start_sim.sh`  \n\n6. Start a C2-20 Routing Service\n- `source ./c2_20.sh`\n- `./start_router.sh`  \n\n#### Pass criteria:\n- Commands are *only* being received by Platform-10\n\n\n## Platform Events\nIn `start_router.sh`, the `PLATFORM_EVENT_CHANNEL` [Channel](#data-channels) is used to move the  \ndesired \"Event\"(`CommandAck`,`ContactReport` etc.) topics from the Platform to *any* C2 station. \n\nThe QoS applied for this route across the WAN is the `WAN_EVENT_QOS` which sets  \nthe Reliability QoS to kind: [RELIABLE](#reliable-delivery)\n\nAs the `ContactReport` Topic is published and subscribed to by both C2 and PLATFORM,  \n(see `C2_EVENT_CHANNEL`) Partitions have been applied to isolate the data planes.  \n\nThis constrains the data flow so Platforms will *only* receive ContactReports  \nfrom other C2 stations and C2 stations will only receive ContactReports from Platforms. \n\nPartitions can be adjusted with XML as needed.\n\n\n### Test:\nIn `start_router.sh`, ensure the `PlatformCommandAck` and `ContactReport` topics  \nare assigned to the `PLATFORM_EVENT_CHANNEL` [Channel](#data-channels) .\n\n1. Start Platform-10 sim  \n- `source ./platform_10.sh`  \n-  `./start_sim.sh`  \n\n2. Start Platform-10 Routing Service  \n- `source ./platform_10.sh`  \n- `./start_router.sh`  \n\n3. Start a second Platform sim (Platform-11) in a different DDS Domain  \n*NOTE: This isolates this Platform from the other one similar to a VLAN to  \nsimulate physical isolation*  \n- `source ./platform_11.sh`  \n-  `./start_sim.sh`  \n\n4. Start Platform-11 Routing Service  \n- `source ./platform_11.sh`  \n- `./start_router.sh`  \n\n5. Start C2-20 sim  \n- `source ./c2_20.sh`  \n-  `./start_sim.sh`  \n\n6. Start a C2-20 Routing Service  \n- `source ./c2_20.sh`  \n- `./start_router.sh`  \n\n#### Pass criteria:\n- Ensure `PLATFORM_EVENT_CHANNEL` topics are *only* received on C2 from PLATFORM source type\n\n\n## Platform Status\nIn `start_router.sh`, the `PLATFORM_STATUS_\u003cRATE\u003e_CHANNEL` [Channel](#data-channels) is used to move  \nthe desired status topics from the Platform to *any* C2 station.  \n\nTopics can be downsampled to different rates by using the desired filter.\n\nThe QoS applied for this \"Channel\" across the WAN is the `WAN_STATUS_QOS` which sets  \nthe Reliability QoS kind to [BEST_EFFORT](#best_effort-delivery)\n\nThe Routing Service input reader QoS has a different time-based filter QoS applied per chosen channel  \nto downsample the data before it is processed by the Routing Service.\n\nThis minimizes resource usage and optimizes overhead/bandwidth usage across the entire message path.\n\n### Test:\nIn `start_router.sh`, ensure the `PlatformData` topic is assigned to the desired   \n`PLATFORM_STATUS_\u003cRATE\u003e_CHANNEL` [Channel](#data-channels) .\n\n1. Start Platform-10 sim  \n- `source ./platform_10.sh`  \n-  `./start_sim.sh`  \n\n2. Start Platform-10 Routing Service  \n- `source ./platform_10.sh`  \n- `./start_router.sh`  \n\n3. Start C2-20 sim  \n- `source ./c2_20.sh`  \n-  `./start_sim.sh`  \n\n4. Start a C2-20 Routing Service  \n- `source ./c2_20.sh`  \n- `./start_router.sh`  \n\n#### Pass criteria:\n- C2 will be receiving selected `PLATFORM_STATUS_\u003cRATE\u003e_CHANNEL` messages at the  \ndesired downsampled rate\n\n\n\n## Platform to Platform\nIn `start_router.sh`, the `PLATFORM_TO_PLATFORM_CHANNEL` [Channel](#data-channels) is used to move topic  \nmessages(i.e.`PlatformData`) between *only* Platforms.\n\nQoS applied for this [Channel](#data-channels)  is `status_qos` i.e. Reliability QoS kind:[BEST_EFFORT](#best_effort-delivery)  \nwith the assumption that the data is being sent periodically.\n\nThis can be modified in `./routing_service_config.xml` with the `WAN_P2P_QOS` variable to select an event based behavior pattern if desired.    \n\n### Test:\nIn `start_router.sh`, ensure the `PlatformData` topic is assigned to the  \n`PLATFORM_TO_PLATFORM_CHANNEL` [Channel](#data-channels) .\n\n1. Start Platform-10 sim\n- `source ./platform_10.sh`\n-  `./start_sim.sh`  \n\n2. Start Platform-10 Routing Service\n- `source ./platform_10.sh`\n- `./start_router.sh`  \n\n3. Start a second Platform sim (Platform-11) in a different DDS Domain  \n*NOTE: This isolates this Platform from the other one similar to a VLAN to  \nsimulate physical isolation*\n- `source ./platform_11.sh`\n-  `./start_sim.sh`  \n\n4. Start Platform-11 Routing Service\n- `source ./platform_11.sh`\n- `./start_router.sh`  \n\n5. Start C2-20 sim\n- `source ./c2_20.sh`\n-  `./start_sim.sh`  \n\n6. Start a C2-20 Routing Service\n- `source ./c2_20.sh`\n- `./start_router.sh`  \n\n#### Pass criteria:\n- Ensure `PlatformData` topics are *only* received on Platforms\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frticommunity%2Frticonnextdds-usecases-act","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frticommunity%2Frticonnextdds-usecases-act","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frticommunity%2Frticonnextdds-usecases-act/lists"}