Maintenance programmes
The Maintenance programmes module defines the what and the when of preventive maintenance. Three objects work together:
- The AEP fixes the target structure.
- One or more PEAs gather the maintenance programmes applicable to an aircraft type or a fleet.
- Each PRE defines a precise maintenance cycle: how often, on which component, against which criterion.
Anatomy of a PRE
Components of a maintenance programme
- Scope
Target PN or AEP family. A PRE can apply to a container (“M88 engine”) or to a specific sub-module (“combustion chamber”).
- Trigger criterion
Calendar (every 12 months), counter (every 600 hours, every 200 cycles), or composite (whichever comes first).
- Expected operations
Ordered list of tasks to perform, usually referenced in the manufacturer’s S1000D documentation. Each operation may carry a standard duration (in minutes) entered at the PRE level (manufacturer reference); it is propagated automatically to derived PEAs at instantiation and will serve as the basis for estimating the workload of a work package.
- Tolerance
Margin allowed beyond the limit (e.g. +5 % or +20 hours) before strict block. Past the tolerance, the aircraft is grounded.
The scheduler
A background job recomputes active limits for every aircraft and module. It crosses:
- the current CA;
- counters (hours, cycles, specific measurements);
- PREs relevant to the installed modules.
Overdue limits surface in the work packages list, where they become candidates to be folded into a WP.
PRE lifecycle
PRE lifecycle
- Creation
Initial definition via POST
/maintenance-programmes, in draft. - Validation
Reviewed by the CAMO. A validated PRE triggers the computation of limits across the impacted fleet.
- Evolution
A new version may be published. Active limits follow the transition rules defined in the PRE.
- Retirement
A retired PRE no longer generates new limits. Already open limits remain active until closed via a WP.
Duplicating a PRE into a new revision
Rather than editing a PRE that is in service, you publish a new revision: a full copy you work on, leaving the original revision untouched until the new one is validated.
Create the next revision of a PRE
- 1. Start the duplication
From the PRE list (Duplicate button) or from the PRE detail page (Duplicate button, top right).
- 2. Confirm the revision
The system suggests a “next” revision (A → B, 2024.1 → 2024.2…), which you are free to edit. It must differ from the current revision and must not already exist for that code.
- 3. Work on the copy
The copy carries over code, name, scope, notes and the whole task tree (operations, triggers, materials). It starts in Planned status, with no effective date or authority, and stays linked to the source revision (a “↩ Revision of a previous PRE” link appears on its page).
Duplication does not touch the source PRE nor the PEAs that attach it: it is a new, independent reference programme that you validate and then attach to PEAs once it is ready.
Attaching and syncing a PRE to a PEA
A PEA inherits the content of its attached PREs. On attachment, the system copies the PRE’s tasks (with their operations, triggers and materials) into the PEA. That copy is not live: if you later edit the PRE — for example by adding an operation to one of its tasks — the PEA does not update on its own. This is deliberate: no change to the reference programme should silently alter a plan in production.
To carry the PRE’s additions into the PEA, the user triggers the sync explicitly.
Carry an operation added to a PRE into a PEA
- 1. Open the PEA
Maintenance plans → click the relevant PEA.
- 2. 'Attached PREs' section
At the bottom of the sheet, find the row for the PRE you just edited.
- 3. Click 'Synchronise'
The Synchronise button copies the PRE’s additions into the PEA: new tasks, operations, triggers and materials added on the PRE side. A message confirms the detail (“Sync OK — 1 operation added”).
The sync is additive and non-destructive: it adds what is missing (matched by source identifier) but never overwrites your local PEA edits and never removes items you may have deleted from the PRE. For fine-grained syncing of an operation’s materials (with a diff preview), see PRE → PEA BOM.
“Component” tracking — one or several articles
A task is tracked on the aircraft counters by default. Choosing Tracking: Component makes its due dates run on the counters of each exemplar of the articles it tracks — typical case: tooling under calibration, or equipment with its own cycle.
A single task can track several references (e.g. one identical inspection covering the 20, 50 and 100 Nm torque wrenches): add each article in the “Tracked articles” selector. Due dates remain computed per exemplar — each serial number has its own, on its own counters. The article list is inherited from the PRE when the PEA is instantiated, and stays editable locally on the PEA side. Amendment-based interval overrides remain available: with several tracked references, the proposed amendments are prefixed with their article.
Linked tasks
Two distinct tasks can be linked: completing the first (the parent) must act on the due date of the second (the child). Typical case: “the 600 h check covers the 300 h check” — the 300 h does not need to be done separately if the 600 h was just performed.
A link carries one of these four effects:
| Effect (UI label) | What it does |
|---|---|
| Counts as done | closing the parent also closes the child — a work order is born closed for it, no extra entry needed |
| Suspends | the child disappears from the individual’s (aircraft or component) due list |
| Forces immediately due | the child’s due date is forced to now — overdue status, zero margin |
| Re-periodises | the child’s interval (or deferral) changes |
PRE → PEA. The link is defined at the PRE level — that is the intent. It is copied into every derived PEA — that copy is the one that actually applies — on attachment and, for PEAs already attached, as soon as the link is created on the PRE side. A PEA can also carry its own links, added or removed locally, without touching the PRE.
Limits. A task added directly to the PEA, with no originating PRE task, cannot be targeted by a link: the due-date engine has nothing to trace it back to. Closing a parent task never triggers a cascade: if that task is itself the parent of another child, that child is not automatically closed.
Links and Component tracking. A link cannot connect an “Aircraft” task to a “Component” task (effects apply per individual), and two “Component” tasks can only be linked if they track at least one article in common. On closure against an exemplar, the effect only applies to the child if it tracks that exemplar’s reference — otherwise it is ignored, and the skip is traced in the audit log.
Arbitration. An airworthiness directive (DES) always takes precedence over a parent task: a task already suspended or re-periodised by an applicable directive ignores the effect of a task-to-task link targeting the same trigger or task.
Technician view
On the aircraft sheet, the Limits panel lists every active PRE with its remaining potential (“47 hours until next visit”, “3 cycles until inspection”). See also Maintenance plans for the definition of the expected operations.