Module decomposition

Decomposition captures the hierarchy of modules and sub-modules actually installed on an aircraft. It is the physical projection of the CA at a given instant.

Model: container vs employment point

Two kinds of slots live in the tree:

Employment Point

Functional slot defined by the aircraft’s

AEP

. Example: pilot station 1, left avionics bay, right engine attach point. An employment point accepts modules whose PN is part of its eligibility list.

Container

Module that hosts further sub-modules. Example: an M88-2 engine contains a fan module, a combustion chamber, a FADEC computer. The container defines its own internal employment points.

The “Decompose” drawer of a slot automatically picks the right context depending on whether the target is an employment point or a container sub-slot.

Searching the tree

On a heavily equipped aircraft the tree can hold dozens of employment points. The “Filter by employment point, RA:CE or S/N…” field at the top of the decomposition narrows the display on the fly. The search is case-insensitive and matches:

• the employment point: internal code (MOT-DR), label, or ATA-CSN key (72-31-00);
• the mounted equipment’s RA:CE (part reference + NCAGE code, e.g. PT0714A00:F4957), as well as the PN or the part name;
• the serial number (S/N) of the installed instance.

When an employment point matches, its whole subtree is kept for context; when a deep sub-component matches, the parent branch stays visible and expands automatically. The “✕” button clears the filter.

Install a sub-module into a container

Note: a sub-module installed inside a container has no independent stock location — its position is derived from the container, and its quantity is forced to 1 (serialised component).

Remove a module

Which articles can be fitted?

Not every catalogue PartNumber can be fitted — Envergure relies on a flag PartType.isMountable to distinguish what can be physically installed on an equipment or an aircraft from what cannot.

The guard is enforced in two places:

1. Declaring a candidate on an EmploymentPoint: the decomposition admin can only declare as candidate on an EP a PartNumber whose PartType is isMountable=true. The picker filters on the UI, and the backend rejects with 400 otherwise.
2. Effective install of a StockItem (POST /stock-items/:stockItemId/install): a StockItem whose PartType is not isMountable can’t be installed — rejected with 400 and an explicit message.

The three dimensions of a PartType

A PartType is defined by three orthogonal flags. They describe what the article can do, not its business role — a single PartType can combine several capabilities.

Orthogonality is intentional: isMountable and isContainer can coexist in a business reading — for example an avionics rack bolted to the structure. See below.

Special case: equipment that is mountable AND a container (avionics rack, modular engine)

An avionics rack bolted in the avionics bay is both mountable (bolted to the airframe) and holds modular cards in internal slots. Likewise, an M88 engine is installed on the aircraft and itself contains 8 major modules (FAN, HPC, CC…).

Envergure models such equipment via two complementary mechanisms:

Key point. The « can contain sub-modules in typed slots » capability of an onboard equipment is NOT carried by partType.isContainer — it is carried by a nested ApplicableConfiguration (see the CFG-RACK-AVIO-A seed). The isContainer flag stays dedicated to transport crates (pure logistics model, see the PartNumberContainerCompatibility relation). The assertContainerValid service accepts both mechanisms.

Counter propagation

On every install and uninstall, Envergure captures a MeterSnapshot: current value of every relevant counter (hours, cycles, specific measurements). This lets us:

• compute how long an instance was used at a given position;
• split wear between parent containers and sub-modules;
• correctly trigger PREs that rely on inherited counters.

Conditional mountability of a part

Beyond “is this PN a candidate on this employment point?”, Envergure lets you condition the mountability of a specific candidate part on the aircraft’s actual state at install time. You attach one or more mountability conditions to an eligibility line (the employment point × PN pair), from the eligibility editor of an applicable configuration.

Two condition kinds exist:

“MOD” condition

Mountability depends on a modification’s application state. Example: tyre GGH812:F6137 is only mountable if MOD MOD-REID-18804 is applied. The expected state is applied or not applied; it is evaluated either on the carrier aircraft or on the parent component (for a sub-module housed inside an equipment).

“Ancestor RA:CE” condition

Mountability depends on the RA:CE actually installed on an employment point higher up the tree. Example: if landing gear RACE1 is installed, then only wheel RACE4 is mountable. The polarity is must be among or must not be among the allowed list.

Multiple conditions combine with AND: all must be satisfied. Each condition carries an enforcement level:

Difference from employment-point availability (below). Conditional mountability targets a specific candidate part on an employment point (“this PN is only mountable if…”). Availability locks the whole employment point regardless of the part (“this point only exists if…”). The two mechanisms are complementary.

MOD-conditioned employment points

An employment point can be conditioned by the application state of a modification (MOD): it is only usable if a given MOD is applied — or, conversely, as long as a MOD is NOT applied. Example: the Head-Up Display position (40-00-01-001) only physically exists once the HUD MOD has been applied to the aircraft.

These conditions are declared on the EmploymentPoint (Availability tab). Multiple conditions combine with AND: all must be satisfied for the point to be available. Evaluation is done live against the aircraft’s current compliance state.

In the decomposition tree, a point whose condition is not met stays visible (it is part of the structure) but flags its state:

Why the point stays visible. A locked point is never hidden: it belongs to the aircraft’s theoretical structure. Hiding it would suggest it does not exist; we prefer to show it dimmed with the reason, for traceability.

At install time the rule is hardened: trying to install a component on a locked point is rejected (400, MOD condition not met). Conversely, a component already installed on a point that becomes locked (because a MOD changed state) is not removed — it is only flagged as non-compliant.

See also

• Work packages — act on the tree through WPs.
• Stocks — Stock Items and storage types.
• Fleet — overview of aircraft and their configuration.