When is a journey queued for re-processing
- When a journey is submitted within the auto start buffer window, the journey will immediately be queued for re-processing, even if the start date is still in the future.
- When a journey is submitted after the scheduled journey departure time, the journey will immediately be queued for re-processing regardless of the start buffer window.
- When a journey is submitted before the start of the buffer window, the journey is not queued for re-processing.
The root cause of approved journeys not re-processing is when an asset is also linked to another journey that is in progress.
When an asset is linked to more than one journey
- The server side rules used to monitor a journey is linked to the asset, not the journey. An asset can therefore not be linked to more than one journey that is in progress.
- If an asset is allocated to both an in progress and approved journey, the approved journey will not start until the in progress journey is completed or cancelled.
- If an asset is allocated to multiple journeys in an approved status, there will be conflicts when journeys overlap, resulting in journeys not recording a journey start.
- Departure and arrival times can therefore not overlap between journeys.
Having two journeys in progress for the same asset is not allowed and when you re-process an approved journey while the relevant asset is in progress on another journey, the re-processing service will exit and log the lead asset as in progress on another journey.
When this occurs, the approved journey will not be re-processed and as a result will also not retrieve the necessary position update to record a journey start.
- The server side rules used to keep track of the stops in the journey will only be created once the journey start is recorded, hence remaining in an approved status.
Solution:
- Do a route change on the in progress journey to remove incomplete stops and update the end location.
- Once the route is updated, the controller needs to ensure that the journey is completed (automatically, reprocessing before the next journey is in progress or manually via MiX Fleet Manager).
- When the original journey that was in progress have been updated and completed, the next journey can be submitted. It is important to note that while the original journey is still in progress for a selected asset, the next journey linked to the asset will not start. This will cause a knock on effect where recurring journeys linked to a selected asset will not start and therefore remain in an approved status.
Note that when a destination waypoint is re-used for multiple journey routes, the rules are tied to only the asset and the waypoint and will be triggered when the asset enters and exist the geofence location. This will result in the stop being recorded on the in progress journey outside of the planned start and end time.
CONCLUSION: The journey must be managed via MiX Fleet Manager and preferably submitted as a draft and dispatched manually to not have conflicts during reprocessing.
The root cause for a journey not starting automatically is overlapping journeys.
This occurs when the start and/or end times of the previous or next journey overlaps with the approved journey. When this happens the re-processing service will log that the asset is allocated to overlapping journeys.
When this occurs, the reprocessing task will complete successfully but the journey start will not be recorded. Because the journey start is not recorded, the server side rules to monitor the stops is also never created as this only takes place after a start. So similar to above, this journey will also stay in approved status.
These scenarios prove that an approved journey is blocked by an in progress journey OR a journey does not start due to an identified overlap between two journeys. This can be aggravated by the fact that journeys are not actively monitored and managed via MiX Fleet Manager to apply amendments in real time and because journeys are created via MiX Integrate with Submit parameter as TRUE.
What if the asset assigned to a journey goes off plan and the journey never auto completes.
All of the above will be resolved if the following is considered:
- Journeys should be monitored in real time via the UI to ensure they are completed according to plans and that exceptions are managed appropriately.
- Updates to in progress journeys must be done via MiX Fleet Manager as either a route update or journey definition update or in instances where approved journeys are amended, a post approval change.
- Journeys should not be created via MiX Integrate with Submit attribute as TRUE to replace approved or in progress journeys unless monitored to ensure conflicting journeys are managed appropriately. This aggravates the perceived re-processing failures as these journey are immediately queued for re-processing and if any conflicts exist at the time, the journeys will not re-process successfully.
- It would be beneficial to create replacement Journeys as DRAFT by default, and have the coaches dispatched by a controller that ensures the correct asset is allocated and not attached to another journey.
- Where replacement journeys are created via MiX Integrate with Submit attribute as TRUE, a controller has ensured that there are no overlapping and/or in progress journeys using the asset in question.
It is important to remember that Journey Management is intended for active monitoring and management of journeys in the UI.