RotorLab logo RotorLabDocs

Maintenance: program, plan and automatic work

This page is part of Maintenance. It covers the recurring tasks each aircraft owes, the forward plan of everything that falls due, and Check for new work, which raises the work an aircraft's own records already justify.

The maintenance program#

The Program tab is the schedule. A task is recurring work on one aircraft: an interval in hours, flights, months or days (any combination; whichever comes first governs), a tolerance, a reference to the manual or maker document, and a task card of steps.

A tolerance left blank is ten percent of the interval on a task you write yourself; on a task that comes from a type's instructions or is a replacement task, a blank tolerance is 0, so it reads overdue at its interval. A tolerance of 0 is zero, which is what a life limit with no grace needs, and a tolerance larger than its interval is refused.

When a task falls due#

Due is computed from the flights on record, never typed: an hours task counts the aircraft's flown hours from the day it was last done (flights on that day count toward the next interval), a flights task counts its flights, and a months or days task counts the calendar from the date it was last done.

A task with no Last done on date reads never completed and counts from new: its hours and flights from zero, its calendar from the aircraft's In service since date on the fleet register (and failing that from the day the task was added). The first 25-hour inspection on a 5-hour aircraft falls due at 25 hours. A never-completed task reads due for one interval from the day it was added (its calendar interval, or 30 days for an hours or flights task), because nothing on record says the work was not done before the aircraft came to RotorLab. After that it reads overdue, which is no go, until it is done or you give its Last done on date.

Give the task its Last done on date and Where that date comes from (a logbook page, a maintenance record, a service center report); a date without its source is refused. The task then counts from that date: leave Aircraft hours when last done blank and the hours and flights are read from the flights on record for that date. Hours typed without a date are refused, because the task would still read never completed.

When a task is completed inside its window (at or past the due point, within the tolerance), the next due counts from the original due point, not from where the work happened to be done: tolerance is grace, not a new interval, so a 25-hour inspection stays a 25-hour inspection. Work done early, work done past the tolerance, and the first completion of a task never completed before move the baseline to where the work was done.

Each task reads in limits, approaching (inside ten percent of the interval or 30 days), due (past the interval, inside the tolerance) or overdue (past the tolerance), and the Forecast column turns the aircraft's flying over the last 90 days into a date. Each forecast reads due now, "on" a calendar date with the days to go, "about" a date at the flying rate, not within 3 years at this rate, or, for an aircraft that has not flown in the last 90 days, that there is no date. The rate it rests on is shown under it, for example "at 4.2 h and 18 flights per 30 days, over the last 90 days of flying". Aircraft hours when last done is kept to the hundredth of an hour.

Applying a shipped program#

Apply a program puts a shipped set of tasks on an aircraft in one step. A task in a shipped program that carries a tolerance says whose it is: none, or RotorLab's starting figure and not the maker's, and the task keeps that sentence in its notes. Three follow the makers' published schedules: DJI Enterprise (Matrice 300 / 350 class, from the Matrice 350 RTK maintenance manual), Skydio X10 (from Skydio's support articles and Notices to Operators) and Autel EVO Max (from the EVO Max 4T maintenance manual). Three are conservative general practice with no maker behind them, and say so: the home-built multirotor, the fixed-wing / VTOL survey aircraft, and the occupied eVTOL placeholder. Every task names the document its interval came from; a task whose reference reads "Operator practice" is a starting point to edit, not a maker's figure. Tasks already on the aircraft with the same title are left alone.

Last inspected on is optional: give the date the aircraft was last inspected, with where that date comes from, and every new task counts from it, at the aircraft's hours and flights on that date from the flights on record. Leave it blank and every new task reads never completed and counts from new, so a task the aircraft is already past reads due now.

Each program is checked against the aircraft first, from its recorded model, its type, or its airframe for the class programs. When the aircraft is recorded as something the program is not written for, RotorLab says so and asks before applying it (Apply anyway), and applying it anyway is kept in the maintenance audit trail with your name. When the aircraft has no model or type recorded, the program is applied and the page says it could not be checked. An aircraft type's instructions for continued airworthiness, when the type carries them, apply to every aircraft of the type the same way. Add a task writes one by hand. A task can be marked Needs an inspection: a record that completes it then names an inspector who countersigns it (see The tech log).

The Due list#

The Due list at the top of the tab is the working view: overdue, due and approaching tasks, plus anything forecast inside 90 days, worst first. From any task, raise work opens a work order carrying the task card and the task's due date: its calendar due date, today when it is past its hours or flights, or the forecast day. A task that already has an open order shows "work order #N open" with its due date instead, and opening it opens that order. record opens a maintenance record for the task directly.

The maintenance plan#

The Plan tab lists everything that falls due on each aircraft, day by day, over the next 7, 14, 30, 60, 90, 180 or 365 days (the Next picker), for Every aircraft or the one you pick:

  • program tasks, at their calendar date or projected at the aircraft's flying rate over the last 90 days;
  • the first day a deferral no longer covers its defect, when the aircraft reads no go again;
  • component life limits in hours, flights and months, projected the same way;
  • battery cycle ceilings, at the pack's own rate of use;
  • open work with a due date, service bulletins and same-model inspections included;
  • planned work packages, which are the aircraft's planned downtime;
  • registrations that lapse, from the day after they expire;
  • the sorties planned on Dispatch (day, window and aircraft), so the work can be planned around the flying.

Each row names the aircraft, says whether it is overdue, due today, planned or forecast, and says how its day was reached. A row marked no go from this day if not done grounds the aircraft from that day unless the work is done. Work with no due date, and items on an aircraft that is not flying enough to project, are listed under No date to plan by, never dropped. Download as a spreadsheet saves the list for the horizon and aircraft you picked.

A work package planned for a day shows on Dispatch as planned maintenance.

Automatic work: Check for new work#

Press Check for new work and RotorLab shows, per aircraft, what it would raise from the work its own records already justify. Nothing is written yet. Each order reads New order, Added to open order or Already open, with whether it grounds the aircraft and why. Press Raise them to write them, or close the card to write nothing. It looks for:

  • A Fleet Health flag. Severe vibration, motor imbalance, or a crash on the last flight raise a grounding order; high vibration raises urgent; battery sag, rising vibration, motor spread, and similar trends raise soon.
  • A component at or past a life limit. Over the limit raises a grounding order; due soon raises soon.

Findings of one family on one aircraft, which one cause may explain, become one order led by the worst of them: the propulsion family (vibration and motor flags) and the battery family (sag and aging). Closing that order clears each finding it holds. A new finding of the same family joins the open order; a worse one, such as a grounding finding beside an open soon order, is raised on its own so the aircraft still reads no go.

Each automatic order names its origin (health or life) and the flights it was drawn from. For a flag against a line (severe or high vibration, battery sag, motor imbalance or spread, high pack resistance), those are the flights that crossed the line, not every flight that carried the reading. The same finding never raises a second order while one is already open or in progress. Running the sweep repeatedly is safe; if there is nothing new it says "Nothing new: everything already on the board."

The same check runs on an aircraft each time a flight is filed on it, and on every aircraft at least once an hour, so work is raised however the flight arrived: from the logbook, File Flights, a ground station or the API. Work it opens is notified once, when the order opens; further flights filed while the order is still open do not send the same notice again. Work raised by filing imported flight history is not emailed; it is listed on the import under To review from this history.

Work closed, flights changed#

A finding closed by completed work stays closed. Once a work order raised from a flag is closed as done (by a released maintenance record, or by hand for routine work), the flag is read again only from flights flown after the work: flights on a later day than the date of work, or on that day and filed after the record was released. Pressing Check for new work again raises nothing from the flights that raised the first order. When a flight after the work shows the finding again, the new order says which record or order it follows and cites only the flights since.

The same happens when a flight is typed in the logbook or landed from Dispatch. When a flight is voided, moved to another aircraft or has its time or date changed, the work raised from it is looked at again. An open order raised from a flag whose cited flights are all gone is closed as canceled, with the void and its reason in What was done, when the flag no longer shows on the flights on record; when it still shows on other flights, the order stays open and cites those. Either way it is written to the maintenance audit trail.

Work raised for a part past its life limit is read the same way: if the part is no longer past its limit once the flight is gone or moved, the order is closed and says why, and the aircraft stops reading no go for it. On the aircraft a flight moved away from, the order says the flight moved, never that it was voided, and the aircraft it moved to gets its work at once.