Crew Rostering Software

Skip key takeaways

Updated September 17, 2026

• A rostering system is a legality engine first The scheme is approved configuration, so limits are data the engine reads rather than constants compiled into it.
• Acclimatization is derived, never stored on the crew member The state belongs to a rotation and a reporting instant, and it decides which maximum FDP table applies.
• Cumulative duty limits are rolling windows, not calendar weeks Seven, fourteen and twenty-eight consecutive days plus a calendar year and a rolling twelve months, each evaluated from interval history.
• Discretion is an exception recorded after the fact It belongs on the actual duty with the commander identity, the size of the change and a filing clock, never in the plan.
• Disruption means recomputation, not patched counters Recompute the affected slice of the timeline, short windows first and store every verdict against the roster version it used.

Copy takeaways

Crew rostering software for a European operator is a legality engine before it is a scheduling tool. Every roster it publishes has to survive a rule set that counts hours in several overlapping windows at once, set out in Annex III (Part-ORO) Subpart FTL of Regulation (EU) No 965/2012 and consolidated by EASA as the Easy Access Rules for Air Operations, which states the scope of the Subpart in ORO.FTL.100: "This Subpart establishes the requirements to be met by an air operator and its flight and cabin crew (aircrew) members with regard to flight and duty time limitations and rest requirements for aircrew assigned to commercial air transport (CAT) operations with aeroplanes." That text says what an operator must observe, as limits on duty and floors under rest. How a roster is produced is left open, and the gap is where the software lives.

In short: the engine derives one state before it can read any table, looks the maximum flight duty period up in reference time rather than departure local time, holds all three cumulative duty limits as rolling windows over consecutive days and puts standby and reserve on different counters from duty. Flight time runs the same way over 28 consecutive days and over 12 consecutive calendar months, with a calendar-year total beside them. Extensions and split duty move the ceiling at planning time, while the commander moves it only in operation. Scope is the EU rule for commercial air transport by aeroplane; FAR Part 117, the United States rule, is out of scope. Everything below about building such an engine is ours, and labeled where it appears.

What a crew rostering system has to compute

An operator implements not Subpart FTL but a flight time specification scheme of its own, and ORO.FTL.125 in the Easy Access Rules makes the approval explicit: "Before being implemented, flight time specification schemes, including any related FRM where required, shall be approved by the competent authority." A scheme is the operator's own and is approved as such, so the limits an engine applies are approved configuration. Ours, and a design consequence rather than a requirement: they are data the engine reads, never constants compiled into it.

The same rules run in two contexts. Months ahead a planner builds pairings; hours ahead crew control asks whether one change is legal now. Our position, not a requirement of the Regulation: both share one rule library, and the difference belongs in the inputs, scheduled times for planning and actual times for control. For the systems around the roster, see our aviation software development guide.

The definitions the data model needs

ORO.FTL.105 defines the vocabulary, and the definitions are computational rather than descriptive. A duty period runs from the report the operator requires until the crew member is free of all duties, post-flight duty included, so the stored record is an interval with a reason. A flight duty period is narrower: it "means a period that commences when a crew member is required to report for duty, which includes a sector or a series of sectors" and "finishes when the aircraft finally comes to rest and the engines are shut down, at the end of the last sector on which the crew member acts as an operating crew member", per the Easy Access Rules text of ORO.FTL.105. A sector runs from first movement for take-off to coming to rest after landing, so the count that indexes the FDP table counts planned movements, not legs sold.

Availability states sit apart from duty, and behave differently on every counter. Standby is a pre-notified period of availability with no intervening rest, reserve is the same availability with at least 10 hours of notice, and a rest period is continuous, uninterrupted and free of all duties, standby and reserve, as ORO.FTL.105 puts it. The window of circadian low, defined in the same rule as 02:00 to 05:59 in the time zone to which the crew member is acclimatized, is a time zone question rather than a clock one: an hour that encroaches it for one crew member leaves another untouched.

What the engine computes, rule by rule

Its rule, reference and computation columns come from the Easy Access Rules text cited throughout the page. The last two are ours: the data column is an engineering reading of what each computation needs, and so is the failure column.

Rule (sourced)	Reference	What the engine computes (sourced)	Data needed (editorial)	Common failure (editorial)
Acclimatization state	ORO.FTL.105(1), GM1 ORO.FTL.105(1)	B, D or X at the next duty, from the difference against reference time and the time since reporting	Reference time, local time of each reporting point, the reporting instant	Storing the state on the crew member rather than the rotation
Maximum daily FDP	ORO.FTL.205(b)	A table lookup by start of FDP at reference time against sector count, with separate tables for the unknown state	FDP start in reference time, sector count, whether the scheme carries FRM	Reading the table in departure local time
FDP extensions	ORO.FTL.205(d) and (e), CS FTL.1.205	One hour twice in any 7 consecutive days paid for in rest, or 14 to 17 hours with in-flight rest	Extensions already used, WOCL encroachment, facility class per airframe	Counting the two extensions per calendar week
Split duty	ORO.FTL.220, CS FTL.1.220	Up to 50 percent of a ground break of at least 3 consecutive hours, the break counting in full as FDP	Break start and end, accommodation, WOCL encroachment	Crediting the whole break rather than the part that qualifies
Cumulative duty	ORO.FTL.210(a)	60 duty hours in any 7 consecutive days, 110 in any 14 and 190 in any 28	Every duty period, positioning and the counted share of standby	Implementing a limit over any 7 consecutive days as a fixed week
Cumulative flight time	ORO.FTL.210(b)	100 hours in any 28 consecutive days, 900 in any calendar year and 1,000 in any 12 consecutive calendar months	Flight time per sector per operating crew member	Conflating the calendar year with the rolling twelve months
Standby and reserve	ORO.FTL.225 and ORO.FTL.230, CS FTL.1.225 and CS FTL.1.230	Airport standby in full and other standby at 25 percent against the counters, reserve against neither	Standby type, notified start and end, the reserve day calendar	Treating other standby as free time
Rest	ORO.FTL.235, CS FTL.1.235	The preceding duty period or 12 hours at home base and 10 away, plus recovery rest of 36 hours never more than 168 hours apart	Preceding duty length, local nights at the rest location, the recovery clock	Counting two local nights in UTC
Commander discretion	ORO.FTL.205(f)	An in-operation increase of at most 2 hours, or 3 with an augmented crew, a rest floor of 10 hours, a report to the operator and a copy to the authority within 28 days when the change exceeds 1 hour	Actual times, crew augmentation, the report record and its filing clock	Offering discretion as a planning allowance
Records	ORO.FTL.245	24 months of individual records of flight times, duty periods and FDPs, rest periods and days free of duty	Actual values as well as planned ones	Keeping only the published roster

Acclimatization state and reference time

No crew record says which time zone a pilot is adapted to, so the engine derives it. ORO.FTL.105(1) defines the state: "‘acclimatised’ means a state in which a crew member’s circadian biological clock is synchronised to the time zone where the crew member is." The same paragraph of the Easy Access Rules widens it to a two hour band around the local time at the point of departure, which makes this a band comparison.

Reference time anchors that comparison, and ORO.FTL.105(2) in the same rule defines it as "‘reference time’ means the local time at the reporting point situated in a 2-hour wide time zone band around the local time where a crew member is acclimatised". The result is one of three labels: B for acclimatized to the departure time zone, D for acclimatized where the next duty starts, and X for unknown. That label decides the clock and, for X, the table: B and D read the basic table against different reference times, while X reads the table for an unknown state of acclimatization.

The elapsed time branch is what implementations get wrong. GM1 ORO.FTL.105(1) in the consolidated guidance material states that "A crew member remains acclimatised to the local time of his or her reference time during 47 hours 59 minutes after reporting no matter how many time zones" crossed, and the same guidance material states that the maximum daily FDP for acclimatized crew members is determined from table 1 of ORO.FTL.205(b)(1) using the reference time of the point of departure. Acclimatization is therefore a property of a rotation and a reporting instant, not of a person: an engine that stores one current zone on the crew record quietly picks the wrong table on day two of a rotation.

The maximum daily flight duty period

ORO.FTL.205(b)(1) introduces the basic case: "The maximum daily FDP without the use of extensions for acclimatised crew members shall be in accordance with the following table". That table is indexed by the start of the FDP in reference time and by the number of sectors, and the maximum it yields runs from 13 hours in the most generous cell down to 9 hours. The rule text and the table are read from the approved scheme. A lookup runs in three steps: convert the planned report time into reference time as ORO.FTL.105(2) defines it, count the sectors of the planned FDP, then read the cell where that row and that column meet. A crew member acclimatized to the departure time zone, reporting at the most generous start time on the lowest sector count, resolves to the 13 hour ceiling; at the least generous start time on the highest sector count the same lookup yields 9 hours, and the grid between them is not reproduced here. Our design rule: read that table in departure local time and you get the wrong row whenever the crew member's reference time is not the departure zone.

Extensions, in-flight rest and split duty

Each way of raising the ceiling has a price and a counter. Without in-flight rest, "The maximum daily FDP may be extended by up to 1 hour not more than twice in any 7 consecutive days", paid for by two hours added to both the pre-flight and the post-flight rest or four hours added to the post-flight rest alone. The extension is capped by sectors against the circadian window: "The use of the extension shall be planned in advance, and shall be limited to a maximum of: (i) 5 sectors when the WOCL is not encroached; or (ii) 4 sectors, when the WOCL is encroached by 2 hours or less". Both come from ORO.FTL.205(d) in the Easy Access Rules, and the phrase "any 7 consecutive days" decides the data structure: a rolling window, not a weekly allowance that resets on Monday. The same rule forbids combining that extension with in-flight rest or split duty in one duty period, which the engine expresses as mutual exclusion.

With in-flight rest the numbers move into the certification specifications for commercial air transport by aeroplane, scheduled and charter, where CS FTL.1.205(c) allows an FDP "with one additional flight crew member: (A) up to 14 hours with class 3 rest facilities; (B) up to 15 hours with class 2 rest facilities; or (C) up to 16 hours with class 1 rest facilities", an hour more again with two additional members, while limiting such an operation to three sectors with 90 consecutive minutes of rest for each crew member. CS FTL.1 settles a modeling question that otherwise recurs: "All time spent in the rest facility is counted as FDP." In-flight rest never splits the FDP interval, and the price at the other end is a rest at destination of the preceding duty period or 14 hours, whichever is greater.

Split duty is the other way to move the ceiling, and the one most often implemented too generously. ORO.FTL.220 in the Part-ORO text sets two hard rules, that "the break on the ground shall count in full as FDP; (c) split duty shall not follow a reduced rest." The credit itself sits in the certification specifications, where CS FTL.1.220 puts a floor of three consecutive hours on the break and then states it: "The maximum FDP specified in ORO.FTL.205(b) may be increased by up to 50 % of the break." One qualification removes much of that, because CS FTL.1.220(e) states that "any time of the actual break exceeding 6 hours or any time of the break that encroaches the WOCL does not count for the extension of the FDP." An engine that simply halves the raw break over-credits the FDP.

Cumulative limits as rolling windows

Six numbers govern the long horizon and five of them are rolling windows rather than calendar periods. ORO.FTL.210(a) sets the duty side: "The total duty periods to which a crew member may be assigned shall not exceed: (1) 60 duty hours in any 7 consecutive days; (2) 110 duty hours in any 14 consecutive days; and (3) 190 duty hours in any 28 consecutive days". The flight time side follows in ORO.FTL.210(b), where "The total flight time of the sectors on which an individual crew member is assigned as an operating crew member shall not exceed: (1) 100 hours of flight time in any 28 consecutive days", then "900 hours of flight time in any calendar year; and (3) 1 000 hours of flight time in any 12 consecutive calendar months." Both are quoted from ORO.FTL.210 in the Easy Access Rules. Read as arithmetic, that is rolling windows of 7, 14 and 28 days, one calendar year aggregate and one rolling twelve calendar months. The last two are separate limits with different numbers. Our reading, not the Regulation's: the two are easy to collapse into one counter, and the divergence is widest for crew whose flying straddles a year boundary.

Rest and recurrent extended recovery rest

Rest is computed from the duty before it, not the duty after it. ORO.FTL.235(a)(1) in the Part-ORO text states that "The minimum rest period provided before undertaking an FDP starting at home base shall be at least as long as the preceding duty period, or 12 hours, whichever is greater." Away from base the floor drops to 10 hours on the same basis, with an eight hour sleep opportunity on top of traveling time. Which floor applies follows from the home base assigned under ORO.FTL.200, which is why that one field matters more than its size suggests.

Above the daily floor sits an obligation the scheduler plans rather than discovers. ORO.FTL.235(d) requires that "The minimum recurrent extended recovery rest period shall be 36 hours, including 2 local nights, and in any case the time between the end of one recurrent extended recovery rest period and the start of the next extended recovery rest period shall not be more than 168 hours." It raises that recovery rest to two local days twice every month. Ours, as a modeling rule: count local nights in the time zone of the rest location, and note that the 168 hours run from the end of one recovery rest to the start of the next.

Reduced rest is a scheme option rather than a default. ORO.FTL.235(c) has the scheme specify the minimum reduced rest, the increase of the subsequent rest and the reduction of the following FDP, and CS FTL.1.235 puts floors under it: "The minimum reduced rest periods under reduced rest arrangements are 12 hours at home base and 10 hours out of base." It also caps the frequency at two reduced rest periods between two recovery rests, so a reduced rest consumes an allowance the engine counts rather than merely validates.

Standby and reserve accounting

Standby and reserve look alike in a roster. ORO.FTL.225 in the Easy Access Rules requires standby and any airport duty to be in the roster with start and end notified in advance, it starts airport standby at the moment of reporting, and it settles the airport case outright: "any duty at the airport shall count in full as duty period and the FDP shall count in full from the airport duty reporting time".

The certification specifications supply the arithmetic. On airport standby the maximum FDP is reduced by any standby beyond four hours, and standby plus the assigned FDP is capped at 16 hours. Other standby is capped at 16 hours in itself, procedures keep standby plus FDP inside 18 hours of awake time, and, decisively for the cumulative counters, "25 % of time spent on standby other than airport standby counts as duty time for the purpose of ORO.FTL.210". The figures are from CS FTL.1.225. A standby other than airport standby that produced no flying still adds a quarter of its length to the ORO.FTL.210 totals.

Reserve is accounted differently. On the counters, CS FTL.1.230 is explicit that "Reserve times do not count as duty period for the purpose of ORO.FTL.210 and ORO.FTL.235", and it adds a rostering constraint rather than a limit: an eight hour window per reserve day during which the crew member is not contacted. That window has to exist as a real object in the roster, since an operator that cannot show when it was scheduled cannot show it held.

Where the commander overrides the plan

Commander discretion is the one place a published roster may be wrong, and it is an act by a named party in operation, not a planning allowance. ORO.FTL.205(f)(1) in the Easy Access Rules allows that "the maximum daily FDP which results after applying points (b) and (e) of point ORO.FTL.205 or point ORO.FTL.220 may not be increased by more than 2 hours unless the flight crew has been augmented", in which case the ceiling rises to three hours, and it puts a floor under the consequence, since "the rest period following the FDP may be reduced but can never be less than 10 hours". The commander reports to the operator whenever an FDP is increased or a rest period is reduced at his or her discretion, and where the change exceeds one hour a copy of that report, with the operator comments on it, goes to the competent authority within 28 days.

The associated acceptable means of compliance sets the expected frequency. AMC1 ORO.FTL.205(f), as published in the consolidated acceptable means of compliance, states that "The exercise of commander’s discretion should be considered exceptional and should be avoided at home base and/or company hubs where standby or reserve crew members should be available."

Not a rule of the Regulation but ours: discretion is never an input to the planner. Model it as an annotation on an actual duty carrying the commander identity, the size of the change and a filing clock. Offered as a planning option it turns an exception into a capacity assumption, and the volume of reports is what the authority sees.

Fatigue risk management and the records behind it

Above the hard limits sits a layer that is explicitly not one. ORO.FTL.120 in the Easy Access Rules provides that "When FRM is required by this Subpart or an applicable certification specification, the operator shall establish, implement and maintain a FRM as an integral part of its management system." It names what that process contains: continuous hazard identification and risk assessment, and a mitigation process with prompt remedial action scaled to the operator. ORO.FTL.110(j) adds the point at which the plan itself has to change, requiring an operator to "change a schedule and/or crew arrangements if the actual operation exceeds the maximum flight duty period on more than 33% of the flight duties in that schedule during a scheduled seasonal period." Measuring that needs the achieved FDP held against the planned one across a season. For the software the consequence is that fatigue risk management reads the same duty and rest history the limit checks read. Run it on a separate extract and you get two views of one roster that disagree, found during an audit rather than before.

Records make the same point in storage terms. ORO.FTL.245(a) requires that "An operator shall maintain, for a period of 24 months: (1) individual records for each crew member including: (i) flight times; (ii) start, duration and end of each duty period and FDP; (iii) rest periods and days free of all duties", according to ORO.FTL.245, so 24 months is a retention floor rather than an archiving detail. EASA sets out its understanding of what those records hold in its Air Operations frequently asked questions, stating that "operators need to maintain (for a period of 24 months) records of the actual values of flight times, FDP, rest periods and days free of all duties." It adds that operational robustness is measured through performance indicators showing whether planning is realistic and rosters stable. That page states its own status: the answers are EASA understanding, not a binding limit.

A data model of duties and rest

This section and the next are ours: nothing in the Easy Access Rules or the certification specifications describes software, so what follows is engineering practice, not a requirement. The durable shape is a timeline of typed intervals per crew member, each with a start, an end, a type from the ORO.FTL.105 vocabulary and a link to the operating record behind it. Duties, FDPs, sectors, rest, standby, reserve and days free of duty are one row type with different counter contributions. Every derived value, the acclimatization label included, is computed from that timeline rather than stored beside it, and every interval exists in a planned and an actual version.

Incremental checks and recomputation on disruption

A legality check and an optimizer are different programs, and conflating them is a mistake we design against. The check answers whether one assignment is legal and has to be exact, explainable and fast enough to run on every candidate. The optimizer can be approximate, provided every solution it emits passes the exact check first. When the optimizer carries its own copy of the rules they disagree at the boundaries that matter, and the crew control desk learns to distrust both.

Disruption decides the rest of the design. A delay moves an actual time, then the end of an FDP, then the rest that follows, which can invalidate the next duty and every cumulative window containing it. Make evaluation cheap and stateless over the affected slice, recompute that slice rather than patch counters, and evaluate the short windows first, since almost every real disruption is caught by the 7 day and 28 day checks.

Explainability is a feature here, not a report. Every verdict should carry the rule reference applied, the window evaluated, the inputs used and the margin remaining, so a controller sees why a swap was refused and an auditor can reconstruct a two year old decision. Store it next to the roster version it was computed against: a rule engine whose answers cannot be replayed is, for audit purposes, a system with no answers.

How Pharos Production helps

Our aviation software development practice takes on this layer inside an existing crew system or alongside one, holding the approved scheme as configuration rather than code and keeping every verdict replayable against the roster version behind it.

Sources: EASA, Easy Access Rules for Air Operations, Revision 24, March 2026, online publication: Annex III (Part-ORO) Subpart FTL with its AMC and GM, and CS FTL.1 for commercial air transport by aeroplane; EASA Air Operations frequently asked questions, ORO.FTL category, non-binding by its own statement. Read on 16 September 2026. Engineering guidance, not legal advice.

FAQ

Last updated: September 17, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• Which operations does ORO.FTL.100 reach?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  The scope provision names an air operator and its flight and cabin crew members assigned to commercial air transport operations with aeroplanes, so an engine built to these limits is built for that envelope. The certification specifications the numbers on this page come from narrow it further, to commercial air transport by aeroplane, scheduled and charter.

  Operations outside that envelope sit under other specifications, and a figure quoted here does not transfer to them: check the applicability rules of the Subpart and of the specifications the operator's own scheme is approved against. The approved scheme, not the Subpart alone, is what an implementation has to satisfy.

• Why does acclimatization change the maximum flight duty period?

  Copy link Copies a direct link to this answer to your clipboard.

  Because the daily table is indexed by the start of the flight duty period expressed in reference time, and reference time depends on which zone the crew member is adapted to. A crew member acclimatized to the departure time zone reads one table, a crew member acclimatized where the next duty starts reads the same table against a different clock, and one in an unknown state reads a separate table.

  The state is derived from the time difference against reference time and the time elapsed since reporting, so it belongs to a rotation and a reporting instant rather than to the person.

• What is the difference between standby and reserve on the counters?

  Copy link Copies a direct link to this answer to your clipboard.

  Both are availability, and they behave differently in every count. Standby is pre-notified availability with no intervening rest period; reserve is availability for an assignment notified at least 10 hours in advance.

  Any duty at the airport counts in full as duty and the flight duty period runs in full from the airport duty reporting time, while a quarter of any standby other than airport standby counts as duty time for the cumulative limits. Reserve time counts towards neither those cumulative limits nor rest, and each reserve day carries a rostered window during which the crew member is not contacted. One roster row, three different counter contributions.

• How should an engine resolve the Subpart, the approved scheme and a collective agreement that binds tighter?

  Copy link Copies a direct link to this answer to your clipboard.

  Ours, as a design rule rather than a regulatory one: evaluate each rule set independently against the same timeline, then let the strictest applicable limit decide the verdict. Collapsing them into one merged number is where implementations lose their explanation, because the merged limit no longer names anything a controller can look up.

  Keep them separate and every refusal can state which rule set bound and by what margin, which is also what makes a later audit answerable. The same shape handles a scheme that is stricter than the Subpart in one place and silent in another.

• How is a rule library proven correct before cutover?

  Copy link Copies a direct link to this answer to your clipboard.

  Not from the Regulation but ours, as engineering practice: three things in order. A scenario regression corpus, where each case states inputs, the expected verdict and the rule that produces it, so a change that moves an answer fails loudly.

  A replay of historical rosters, which surfaces the cases a hand-written corpus never imagines. Then a period of dual running against the system being replaced, comparing verdict for verdict rather than roster for roster, since two engines can publish the same roster while disagreeing about why it is legal. Differences found in dual running are the specification the corpus was missing.

• When is it worth building the rule library rather than taking it from an existing crew system?

  Copy link Copies a direct link to this answer to your clipboard.

  Ours, as a build-or-extend judgment: the deciding question is whether the verdicts have to be explainable and replayable inside your own product. If the existing system already produces verdicts an operator can audit and a roster only needs to be read, extend it and keep one source of legality.

  Build the library when legality has to run inside planning, disruption handling or a customer-facing flow at a latency the existing system cannot serve, when the approved scheme changes faster than that system can be reconfigured, or when the same rules have to be evaluated against hypothetical rosters that never reach it.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.