{//% unless portal.user.is_agent %} Tickets
Welcome
Login Submit a Ticket News {//% endunless %}

EASA Disruption Report

 
Prerequisite
 
One has to define disruption rules
Name
Mandatory
Shortcode
Mandatory
From
Roster filter specifying what was assigned
To
Roster filter specifying what it was changed to.
Diff type
Ignore
Ignore difference valus
CI
Difference to Check In
CO
Difference to Check Out
CICO
Difference to Check In and/or Check Out
DS
Difference to Duty start
DE
Difference to Duty End
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
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
Valid from / to
When the rule is valid
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. The 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%
 
 

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.