Optiflow - breaks setup

[CAPcargo]

Hi,

If we want to map the old xServer break configuration to the new Optiflow structure, would the following interpretation be correct?

For driving breaks:

• Optiflow/Vehicles/breaks/driving/maximumDrivingDuration

is actually mapped to:

• xServer/Fleet/Driver/configurableWorkingHours/breakRule/maximumDrivingTimeBetweenBreaks

And consequently:

Optiflow/minimumBreakDurations <-- maps to --> xServer/breakTime

with the difference that in Optiflow minimumBreakDurations is an array and the break duration can be split into multiple parts according to the configured sequence.

The same logic would also apply to working time rules in parallel:

• maximumWorkingDuration
• maximumWorkingTimeBetweenBreaks

So, from my understanding, a simple xServer break rule with a single breakTime value would basically map to an Optiflow configuration containing a single-element minimumBreakDurations array.

Is this the intended migration approach, or are there important differences that should be considered?

Thank you in advance.
Marko Arsovski
CAPcargo

[Bernd Welter]

Here's MIRA's feedback:

Your interpretation is correct. Here's a confirmation with the key nuances:

Mapping Validation

xServer (old)	PTV OptiFlow (new)	Match?
breakRule.maximumDrivingTimeBetweenBreaks	breaks.driving[].maximumDrivingDuration
breakRule.breakTime (driving)	breaks.driving[].minimumBreakDurations
breakRule.maximumWorkingTimeBetweenBreaks	breaks.working[].maximumWorkingDuration
breakRule.breakTime (working)	breaks.working[].minimumBreakDurations

Your conclusion is correct: a simple xServer rule with a single breakTime value maps to a single-element array in minimumBreakDurations.

Example migration

xServer → OptiFlow
maximumDrivingTimeBetweenBreaks: 16200 → maximumDrivingDuration: 16200
breakTime: 2700 → minimumBreakDurations: [2700]

Important Differences to Consider

Aspect	xServer	PTV OptiFlow
Break splitting	Separate configuration (if supported)	Built into minimumBreakDurations as array: [900, 1800] = 15 min then 30 min
Multiple rules	Typically one driving + one working rule	Arrays — you can stack multiple driving and/or working rules simultaneously
Counter reset	After break completes	After the last element in minimumBreakDurations is completed, the counter resets and the full sequence starts again
Duration unit	Depends on xServer version (seconds or HH:MM:SS)	Always seconds (integer)
Daily rest / max total driving	Part of configurableWorkingHours	Not available in break settings — use vehicle.workingHours (shift start/end) as a proxy

Migration Checklist

• Simple 1:1 rule → Single-element array. Your mapping is correct.
• Split breaks → If xServer had a split break config (e.g. 15+30 min), migrate to multi-element array: "minimumBreakDurations": [900, 1800]
• Multiple break tiers → If xServer had separate rules for different thresholds (e.g. short break after 4.5h, longer break after 6h), use multiple entries in the working or driving array:
  

  Code: Select all

  "driving": [
    { "maximumDrivingDuration": 16200, "minimumBreakDurations": [2700] }
  ],
  "working": [
    { "maximumWorkingDuration": 21600, "minimumBreakDurations": [1800] },
    { "maximumWorkingDuration": 32400, "minimumBreakDurations": [2700] }
  ]
  

• Daily rest periods → Cannot be migrated to break settings. If xServer enforced daily rest, this must be handled via shift constraints (workingHours.earliestStart / latestEnd).
• Max total driving time → Not enforceable through breaks. The maximumDrivingDuration only controls when a break is triggered, not the total cap.

So in summary: yes, your migration approach is the intended one. The main upgrade is that PTV OptiFlow gives you more flexibility (split breaks, stacked rules) — but loses the daily rest / total driving cap features that would need to be approximated through shift boundaries.