GitLab

• Decide on topic structure project.operator.vehicleType.vehicleID.[send|receive].messageType

• Decide on operator names or abbreviations to be used in the topic; E.g. planet ocean is po or planet_ocean

• Make decision

• Update docs with decision

changed milestone to %SoAR-2023W07

changed the description

Alvaro suggested we replace project with campaign.deployment to allow us to easily differentiate between different trials.

This is incorrect using our Metadata definitions. To differentiate between different trials you only need project and campaign. If you want to differentiate between different deployments of a platform on the campaign (trial) then you can use deployment.

I suggest: <project>.<campaign>.<platform_type>.<platform_serial>.<message_type>.<send|receive> e.g soar.plymouth1.autosub.ah1.potato.send

If you want to differentiate between different deployments of a platform on the campaign (trial) then you can use deployment

We can keep project as well but I think what we were talking about is this bit - differentiating between the different attempts when we're in Plymouth.

@ashmorr how would that suggestion capture 4 different deployments of AH1 in the same campaign?

I suggest: <project>.<campaign>.<operator>.<platform_type>.<platform_serial>.<message_type>.<send|receive> e.g soar.plymouth1.noc.autosub.ah1.potato.send

We need to define what we mean by send/receive. I'm assuming send is to the platform and receive is from the platform.

I had send/receive before messageType on the grounds that it should be a broader category.

So receive.* would get you receive.platform_status receive.observation receive.survey

It doesn't really matter because you can wildcard anywhere. Although I would assume that like a regex static.prefix.# will be more efficient than word1.*.word3.*

My thinking in sticking to initials in the examples was just byte saving.

added Priority::High Weight::1 labels

assigned to @danjon

added Status::In Progress label

This didn't have a status on it so I'd not noticed (remembered?) that it got assigned to me.

Structure:

<prefix>.<operator>.<platform_type>.<platform_identifier>.<from_platform|to_platform>.<message_type>

e.g

• soar.noc.autosub.ah1.from_platform.platform_status
• soar.planet-ocean.ecosub.eco1.to_platform.mission_plan
• soar.hydrosurv.reav.reav1.to_platform.mission_plan

Terms:

The header.destination field contains the topic that messages will be published to.

This is not the intended recipient of those messages.

The autonomy engine/frontend/c2s are not represented in the topic.

The topic describes what the message relates to.

The client subscription will define which clients receive a message.

• prefix - an agreed hard-coded/config setting prefix shared by all adapters and client subscriptions eg soar
• operator - human readable organisation name for the platform operator one of [noc|planet-ocean|hydrosurv]
• platform_type - one of [autosub|ecosub|reav?]
• platform_identifier - human readable identifier for the platform eg ah1, eco1, reav1
• to_platform|from_platform - eg ..to_platform.mission_plan, ..from_platform.platform_status
• message_type - one of [acknowledgement|mission_plan|observation|planning_configuration|platform_status...]

Subscriptions:

Subscriptions may contain multiword wildcards (#) or single word wildcards (*) eg

• soar.# - everything
• soar.planet-ocean.# - anything relating to the planet-ocean operator
• soar.*.*.*.from_platform.* - all messages inbound from platforms (autonomy engine)
• soar.*.slocum.# - all messages relating to a slocum platform type
• soar.*.*.*.to_platform.* - all messages outbound to platforms (hermes)

added Status::In Review label and removed Status::In Progress label

changed milestone to %SoAR-2023W09

Shared with partners for comment.

Over the last couple of days pretty much everyone agrees that send|receive is really unintuitive and confusing but it is a useful way of segmenting the traffic for the autonomy engine and hermes so it may be that something like to_platform|from_platform makes it clearer.

The topic structure also doesn't work for the planning_configuration message but the answer to that may be to broadcast the message rather than publish it. If the partners don't want to do anything with the message they can choose to ignore it.

Actually this doesn't quite work for the hermes box. Using this model the hermes box would receive the uncompiled plan from the autonomy engine and the compiled plan from NOC C2. Hermes can ignore the first message but it's wasted bandwidth.

If the hermes box and ecosub C2 are 2 instances of the same device then it probably doesn't make sense to process it on the shore and then resend it via hermes if the hermes box on the hydrosurv is capable of compiling the mission itself.

In that case the hermes would want to receive the uncompiled missions for the ecosubs and so we might have to accept that it receives and discards the uncompiled mission for AH-1.

I've not had any pushback on the change from send|receive to to_platform|from_platform.

I think the only remaining question is how we accommodate the planning_configuration message which doesn't relate to platforms. We could implement multiple subscriptions per client or we could just deal with this as-is by broadcasting the message or making up a largely meaningless topic that matches the autonomy engine's subscription eg soar.all.all.all.from_platform.planning_configuration.

I think for now we can call this done.

changed the description

changed milestone to %SoAR-2023W11

removed Status::In Review label

added Status::In Progress label

created merge request !17 (merged) to address this issue

mentioned in merge request !17 (merged)

marked the task Update docs with decision as completed

removed Status::In Progress label

added Status::In Review label

mentioned in commit 1980868f

closed via merge request !17 (merged)