Article below describes the logic of a disruption report.

Prerequisite

One has to define disruption rules

Disruption rule determines when change in crew roster is perceived as a disruption.

Fields:

Name: self-explanatory

Shortcode: self-explanatory

From: Roster filter that filters out roster activities from the previous version of roster

To: Roster filter that filters out roster activities from succeeding version of roster

Diff Type: defines event by which changes in different versions of roster are calculated; one could choose check-in time (CI), check-out time (CO), both check-in and check-out (CICO), duty start (DS) that is useful when the rule is related to reference activities. Last value is ignore when time event is not relevant. 

Diff value: specifies the tolerance in minutes - if time of roster event (i.e. check-in time) is changed by more than this value in succeeding roster - that would qualify this change as a disruption. When diff type is set to ignore - diff value is not taken into account.

Time span: specifies the time in days - how long before the time of roster event (i.e. check-in time) can the roster be changed in order to avoid disruption. If roster is changed shorter ahead of its actual occurence - that would qualify this change as a disruption

Active: self-explanatory

Valid From: self-explanatory

Valid To: self-explanatory

Example:

Let's analyze simple scenario, where one of flight-related roster activities was changed by the planner. It will be analyzed against the rule presented above. 

• name and shortcode do not affect result
• Roster filters "From" and "To" chosen certainly must be specified separately but for the sake of simplicity let's assume that the name "Flights/SBY" means that this filter would pick up regular flights both from "previous" and "changed" roster - that means they are taken into account and can be evaluated further.
• Diff Type tells us that the event we should be looking at is check-in time - it got changed from 2:30 to 3:30 on the same day - that gives us 60-minute difference
• Diff Value however defines that disruption occurs only if roster got changed by more than 70 minutes - therefore in presented case we do not violate rules - changed roster differs by 60 minutes.
• Even if we are sure that there was no violation due to small check-in time change let us check the Time Span field. Change in roster was introduced on 24AUG17 1419, while roster activity will take place 27AUG17 0230, which means that change was done approximately 2,5 days ahead. Te Time Span field value was 3 days, which means that in terms of this condition - there was a violation.
• Active and Valid From - due to values of those fields this rule is taken into account

Final outcome: there was no disruption on that day for this crew. 

Algorithm:

This kind of assessment is performed for every crew chosen (or all crew that fall into the crew filter) for every day within the range. Such day-crew "cells" are analysed against every active and period-valid rule. If one rule is violated for that "cell" - further processing is stopped and algorithm is proceeding to the next one.

The outcome 

Final report will contain disruption occurences per crew as well as some basic statistics.

• disruption percentage per crew (count of days with disruption occurence divided by analyzed days count expressed in %)
• Total # of crew analyzed
• Total # of crew with disruption in analyzed period (1 occurence is enough for crew to be counted in)
• Overall Disruption Percentage - roster days (crew-day cell) with disruption divided by overall roster days analysed.
  In the example below:
  - 1 crew times 8 days = 8 roster days
  - 2 disrupted days
  In total (2/8)*100% = 25%