Maintenance workbench

The Workbench is the operational-maintenance screen for a given aircraft, available at /fleet/:id/maintenance. It opens as soon as a

WP

is in progress on the aircraft and shows:

  • the applied configuration (CA) tree with inline install / uninstall per employment point;
  • a divergence banner when the CA drifts from the product version’s source decomposition;
  • summary stats (employment points, installed, divergence);
  • the WP’s workshop and a “Terminate maintenance” button.

Two entry points to install/uninstall. The Workbench /fleet/:id/maintenance is the entry point for the enrolment flow. For a maintenance WP (curative / preventive / mixed), the “View current package” button now leads to the WP sheet (/work-packages/:id), centered on Work orders; the same CA tree (install/uninstall) is reachable there via the “Install / uninstall” tab. It is exactly the component described below, reused inside the WP sheet.

Overdue limits computed by the scheduler are consulted from the aircraft sheet and the

Work packages list; they are not displayed directly inside the Workbench.

Open a work package

Four kinds, chosen at WP creation:

  • enrolment — initial decomposition of a brand-new aircraft (install mode create, free-text SN entry that atomically creates the StockItem).
  • curative — reaction to a defect, incident or non-conformity.
  • preventive — planned execution of tasks coming from a PEA.
  • mixed — combination of curative + preventive (large overhaul).

WP creation

  1. Trigger from the aircraft sheet

    Contextual button: “Enrol aircraft” (status to_enrol) or “Start maintenance” (status in_service). The StartMaintenanceDialog modal pre-fills the matching kind.

  2. Fill the WP

    Code, planned dates, workshop (workshopStorage), owner, description. API: POST/work-packages.

  3. Add Work Orders (WOs)

    From the WP detail (/work-packages/:id), “Add a WO” modal → POST POST/work-orders. Each WO carries its operations (work-order-operations).

Install and uninstall in the CA

Installing a component

  1. Pick an employment point

    In the tree, every empty slot offers a picker. In enrolment mode, free SN entry (mode create). In curative/preventive/mixed modes, selection from the workshop’s inventory (mode pick).

  2. Confirm install

    The installation is created atomically along with its origin MeterSnapshot. API: POST/installations.

  3. Uninstall

    On an occupied employment point, “Uninstall” button → DeposeDialog asks for the return storage. API: POST/installations/:id/uninstall.

Business guard-rails before install

Before any install (API or UI), the backend checks four blocking conditions. The InstallDialog modal reflects each one with an error banner that disables the submit button:

  • non-installable part type (PartType.isMountable=false) — tooling, containers and consumables don’t follow the install/uninstall cycle.
  • R2 technical reception pending (StockItem.technicalReceptionStatus='pending') — an airworthiness technician must validate identification + counters before service entry.
  • unsuitable condition (condition ∉ {new, serviceable}) — only new or serviceable components can be installed.
  • expiry date passed (StockItem.expiryDate < today) — EASA Part-145 / EMAR-FR M requirement: an expired component must be removed from service or sent to overhaul before any further use.

Capture counters and technical data

  • Aircraft counters (hours, cycles, calendar): MeterReadingFormModal → POST/aircraft/:aircraftId/meter-readings.
  • Technical data of an installed component (identification, counter snapshots, assigned PEA, documents): TechnicalDataDrawer opened from the CA tree.

See the Maintenance programmes page to learn how the limits that populate preventive WOs are computed.

Close the WP

Once operations are done, the “Terminate maintenance” button moves the WP to completed via

POST/work-packages/:id/transition (payload { to: 'completed' }). Side effects:

  • the aircraft status leaves in_enrolment or maintenance and moves to in_service;
  • a meterSnapshotAtCompletion is frozen on the WP (visible in the detail);
  • the immutable audit log records the event.

Electronic signature compliant with EASA Part-145 (CRS, RFC 3161 timestamping) is part of the regulatory roadmap but is not yet implemented in code. Today’s closure is a completion acknowledgement, not an airworthiness release.