Means for AHS to request a manually re-dispatch for a truck while in the last mile dispatching

[politick]

RFC for the new Last-Mile-Dispatching-Exception message: https://github.com/open-autonomy/spot/blob/ExceptionReachingPlaceV1/specification/LastMileDispatchingExceptionV1.md

One thing that is debatable is whether or not the truck required the last mile dispatching (LMD) to re-send a LMD Occupy Message before resuming. I know that was part of the request that prompted this message (because the trucks "forget" the LDM assignment when it encounters the exception). But there's nothing that would prevent us from placing a "re-issue LMD assignment" button in the UI to perform the same task and not require this message at all.

So a clearer use-case could change or even remove this message entirely.

The truck (AHS) may not need to tell LMD that it has encountered a snag. With the current messages, the LMD can always re-send a new LMD assignment at any time with the addition of a button / workflow. There is no need to the Exception message to come in to trigger that flow, assuming the exception flow can be triggered by other flows, possibly:

• AHS UI that raises the exception (but maybe the customer does not want dispatchers to use an other app ?)
• FMS VehicleDiagnostic

Kind Regards, Martin.

[avahan]

I can see scenario, which I'm not sure will be covered just by one button press Scenario 1: simple re-issue

1. Truck reports exception
2. Some in field actions taken? Something was blocking trajectory and now is cleared?
3. Dispatcher pushes re-issue (no other altering on sport/LM data)
4. Truck continues.

Scenario 2: spot/queue position adjustment

1. Truck reports exception
2. Dispatcher/Dozer/Shovel operator moves spot/queue (IDs stay same, no delete/create - actual move is required)
3. Dispatcher pushes re-issue (same LMD assignment is sent to the truck, although target position is updated)
4. Truck continues.

Scenario 3: Different spot/queue chosen to continue LMD This requires new/modified LMD assignment to be sent - does not work with just "re-issue" button press

1. Truck reports exception
2. Somehow different destination spot is selected
3. Dispatcher pushes re-issue (new LMD assignment is sent (considering current position of vehicle in LM or actual position?)
4. Truck continues.

[politick]

NOTE: Please send more comments, not trying to squash the idea of having the LastMileDispatchingException implemented.

Scenario 1: simple re-issue What if the truck encounters an obstacle while on the haul road ? This is similar to encountering a delay while executing your assignment ( of a regular dispatch ). When stuck, the truck sends a VehicleDiagnosticV2 to alert the dispatcher and to account for the waste of time in the TUM. But we don't tell/interact with the dispatching algorithm and it does not re-send the assignment when the truck gets off the delay, granted a new assignment might be sent if the truck was sitting there for a long period, but that is independent from the delay. It's just the optimization engine thinking that now there's a better thing to do with that truck. My point is that removing the obstacle has to be done outside the LMD, what is the benefit of getting the LMD involved ?

Yes, we do have an FMS "Re-issue assignment to truck" button to recuperate from a software glitch (from either side FMS or AHS). But that's all that is, a fast recover to hide small problems / glitches.

Scenario 2: spot/queue position adjustment Already covered by current infrastructure. There is already a method provided to state that a spot needs its position adjusted, when AHS sets DynamicPathIDV1 with value = 0

"DynamicPathId" | PathId | integernullable | Optionally, but expected, to be set by the AHS when a dynamic path that leads to this place is computed in the free space of the area. Semantic null="Not Set" and is the initial state, 0=”Unreachable” AHS is not able to compute a path, >0 = A path ID and means that AHS was able to find a valid path computed in the free space of the area. The Path is retrievable via the Path service (See Path service specification) -- | -- | -- | --

I don't like multiple method to achieve the same result. Further I find that the message to "set the dynamic path" is more appropriate & specific and the procedure to recuperate can be automated instead of having a person read the text message and then address the exception.

Scenario 3: Different spot/queue chosen to continue LMD Because LMD can change / overwrite the assignment at any time with a new OccupyPlace() message, then why have LMD involved / notified with a LastMileDispatchingException message? Why not extend the "Resend LMD assignment" button to also allow to pick a new spotting chain ?

I'm not saying that there is no use for the LastMileDispatchingException, I just can't find one where a simpler message flow achieves the same result with less interaction from Operators / Dispatchers.

Add one more field Exception Number ? One thing I'm starting to convince myself is that if we keep the Exception message, weprobably want to extend it with also a numerical error message. The only reason I can see value in getting the LMD involved in the exception is that there is an automated way to recuperate the exception using LMD or BenchMananger . The advantage of the number is that it can be extended/defined in the future and add automated exception handling with less human interaction.

[michaelwikstrom]

Scenario 1: Truck is stuck but intends to complete spotting to same spot:

1. AHS: Send LastMileDispatchingExceptionV1
2. AHS: Send VehicleDiagnosticV2
3. Manual intervention
   • Manually open / close spot in FMS UI. (In this case open spot again to retry in FMS UI)
   • Remove exhausted / reserved / full from spot. (In this case remove exhausted, reserved, full in FMS UI)
   • Visualize next spot that will be used in FMS UI. (Visualize using "next" state)
4. FMS: Send OccupyPlace with permission to next places in service chain only from FMS UI.

Scenario 2: Truck is stuck but intends to complete spotting to moved spot:

1. AHS: Send LastMileDispatchingExceptionV1
2. AHS: Send VehicleDiagnosticV2
3. Manual intervention (same as above)
4. FMS: Send PlaceUpdated (Selecting a new position for the spot in FMS UI)
5. Send OccupyPlace with permission to next places in service chain only from FMS UI.

Scenario 3: Truck is stuck but intends to complete spotting to new spot:

1. AHS: Send LastMileDispatchingExceptionV1
2. AHS: Send VehicleDiagnosticV2
3. Manual intervention (same as above)
4. FMS: Send PlaceCreated (Selecting to create a new spot and setting position for the spot in FMS UI)
5. Send OccupyPlace with permission to next places in service chain only from FMS UI.

Scenario 4: Truck is stuck but has not failed in current assignment: (Vehicle internal problem, getting stuck without being able to fail when trying to reach spot)

1. FMS: Send "CancelLastMile" from FMS UI. (Today this is only possible from AHS UI)
2. AHS: Send LastMileDispatchingExceptionV1
3. AHS: Send VehicleDiagnosticV2
4. Manual intervention (same as above)
5. FMS: Send PlaceCreated (if creating) or PlaceUpdated (if updating) or do not send anything if reusing a spot.
6. Send OccupyPlace with permission to next places in service chain only from FMS UI.

Scenario 5: Truck has failed the current assignment: (An error where AHS decides it is not possible to recover LMD)

1. AHS: Send LastMileDispatchingQuitV1
2. FMS: Send New assignment

Other comments:

• Spothandling: Having a tool for changing spot JSON data manually on the server side is very error prone and not secure.
• DynamicPathId: Belongs to future implementation of Path service, we cannot foresee the path today.
• ExceptionId: We can use ExceptionId=1 for all errors in the first implementation to start with and send current text from mission failed/canceled. We do not expect automation of error recovery in the first phase.

[politick]

After an extensive meeting, here are the outcomes and why we'll merge the new message into the main trunk.

Long term requirements

• Customers (miners) do not want to use a different application (the AHS UI) to resolve spotting issues.
• The LMD system should automate / trigger the proper person (Dispatcher or heavy equipment operator) or subsystem depending on the exception sent by AHS to LMD.

Short term requirements (development)

• The current AHS implementation uses LMD-Quit message when it actually wants to continue but just have an exception resolved and not quit. But there is no alternative message for now. Defining this message would help changing the inappropriate LMD-Quit messages to the appropriate LMD-Exception
• User wants to identify that there is a spotting problem and prompt the dispatcher immediately (instead for the truck to quit and wasting more production time). The current top level AHS layer does not know the exact cause why there is an exception so it can't classify them and send it to the LMD service. So the LMD can't automate a flow for now, but it can tell someone.

Granted on the FMS side, during this phase, the process will always be: external & manual so an external UI that allows sending or re-sending an OccupyPlace message would be enough, but not defining the Exception message would delay proper messaging on the AHS side to achieve the long term requirements.

The LastMileDispatchingException message allows to implement the short term requirements and also paves the way to addresses the long term final system behavior.

NOTE: this message is currently "Open-Loop". There is no way for AHS to remove the exception or state that the exception is fixed. My gut is telling me that I always prefer a "Close-loop" message exchange, but I can't find a valid use case for it.

Please Reply/ add notes if I'm missing anything important.