Maintenance programs for aircraft and assemblies

A maintenance program is a collection of requirements and reference documents for a particular aircraft or assembly such as an engine or APU. The same maintenance program can be used by one or more operators.

When a maintenance program is applied to an operator, it is applied to all of the operator's applicable aircraft and assemblies.

Maintenance programs are version-controlled in the same way as task definitions. If the program is assigned to only one operator, the revision status is straight forward. You have one active revision, one in revision status, and there can be multiple superseded revisions.

The typical life cycle for a maintenance program is as follows:

Create the maintenance program for an operator.
Assign requirements to the maintenance program.
Lock the maintenance program and request approval.
Activate the maintenance program.
Revise the maintenance program for an operator then lock, get approval, and activate.
For more urgently required changes, issue a temporary revision of a requirement to an active program.

Creating maintenance programs

When you create a maintenance program it's in Build status and you can assign requirement definitions and reference document definitions to the program. REQ and REF are the only classes of task definitions that you can assign to maintenance programs. When you assign a definition to a maintenance program, the active revision of the definition is what's assigned. (You can also add definitions that are still in BUILD status.)

A requirement can be assigned to only one maintenance program.

You can use group codes to bundle several requirements and related reference documents which serve a common purpose such as responding to a regulatory obligation. A maintenance program can have more than one group code. You can label each requirement and reference document with a group code as you add it to a maintenance program and afterwards, filter by group code on the Maintenance Program page, Requirements tab.

You can move individual requirements, and related reference documents, in and out of maintenance programs or groups as you revise a maintenance program.

From the Maintenance Program page, Requirements tab, you can see which revision of a requirement is assigned to the program. You can filter the list of requirements and reference documents by group code and configuration slot, and you can choose to show only definitions that have a revision in REVISION status, or definitions that are applicable to the assembly.

Locking and printing the program

By default, maintenance programs in build or revision status are unlocked. You can edit the program, assign or assign requirements or make other changes, and requirements are automatically updated to their latest revisions.

Locking a maintenance program prevents manual changes and automatic updates.

While building or revising a maintenance program, you can lock and unlock it as required. The lock history is displayed on the Maintenance Program Details page, Details tab.

After you are done building or revising a maintenance program, you lock it to prevent any changes to the program while the maintenance program is being validated and approved by the regulatory authorities. To ensure that the program isn't altered, leave it locked until it's activated. If you unlock an approved program prior to activating it, the assigned task definitions will be updated to their latest revision, which might invalidate the approval.

When you are ready to send the maintenance program for approval, or as you develop the program, you can print the following reports:

Maintenance Program Report: lists all the requirements in the program and is available for maintenance programs in any status.
Maintenance Program Impact Report: lists all active tasks whose deadlines will change if the maintenance program was activated. The report shows the current task deadlines and the new deadlines that would be in effect. This report is available for maintenance programs in build or revision status.
Maintenance Program Differences Report: lists the differences between one revision and another revision of the same maintenance program.

Activating maintenance programs

Activating a maintenance program triggers baseline synchronization and initializes tasks for the maintenance program. The tasks that are created are based on the revisions of the task definitions that were active when the maintenance program was locked. (If the program wasn't locked prior to requesting approval, then tasks are based on the revisions of task definitions that were active when the maintenance program was activated.) If new revisions of the task definitions are later activated, they are not updated in the active maintenance program until you revise the maintenance program.

When the program is active, you can't make any changes to it, except to issue temporary revisions of requirements.

When the maintenance program requirements are initialized, they are only initialized for the applicable aircraft. In the following diagram, a maintenance program is assigned to an operator who owns Aircraft A and Aircraft B. REQ1 is applicable to both aircraft, but REQ4 is applicable to neither aircraft. Maintenix initializes the tasks based on their applicability of each aircraft.

When you activate a revision, Maintenix creates another revision with the REVISION status. This is the revision you will use when you need to modify the maintenance program.

Multiple operators sharing the same maintenance program

If your instance of Maintenix includes multiple operators, the same maintenance program can be used by multiple operators that have the same type of aircraft, but slightly different maintenance needs or processes. When you create a maintenance program, you can only select one operator, but after the program is activated for one operator and there is now another revision in REVISION status, you can assign the new revision to the different operator.

When the revision that's assigned to a different operator is activated, the status of an earlier revision assigned to another operator shows as superseded - but it isn't necessarily. The latest revision, that isn't in REVISION status, for any one operator is active for that operator. The maintenance program revision history shows both the maintenance program revisions and the revisions for each operator. The following figure shows the history for a maintenance program with different revisions assigned to two different operators. (The revision record you are currently viewing is listed in bold, red font).

Rev 4 is in revision
Rev 3 is activated
Revs 1 and 2 are superseded

Although the revision status of Rev 1 is superseded, tasks for OTA are initialized based on the definitions in Rev 1. Tasks for ECA are initialized based on the definitions in Rev 3.

The tasks created for the applicable inventory of one operator are based on the revisions of the task definitions that are in the latest (not including the revision that's in REVISION) maintenance program revision for that operator. Changes to one operator's revision don't affect another operator's revision.

Revising maintenance programs

When you retrieve and view the task definitions in the REVISION status revision of a maintenance program, the task definitions listed are the active revisions. With the updated requirements as a starting point, you can then add new requirements, unassign requirements, or create revisions of task definitions in the program and assign the revised definitions to the program.

If there are multiple operators using the same maintenance program, you must assign the maintenance program revision to the operator whose program you want to update.

When you are working with an in REVISION maintenance program, an Unassign Requirement button is available. However, if the requirement you want to unassign is used in another operator's latest revision of the maintenance program, you can't unassign the requirement directly. This restriction is also true if the requirement was temporarily assigned to another operator's revision of the maintenance program. To unassign a requirement that is in use by one or more other operator revisions of the maintenance program, you create a revision of the requirement, add an applicability rule that specifies which operators the requirement applies to, and activate the requirement. The requirement is then visible in the maintenance programs of all operators, but it is applicable or not – and tasks are created in the operator's revision of the maintenance program or not – according to the rule you created.

When you're done revising a maintenance program, you lock the program, get it approved, then activate it. Baseline synchronization initializes tasks for the program based on the task definitions that are in this latest revision.

When working with a revision status maintenance program (that's unlocked), if you want to delete all the changes you've made, you can use the Revert to Previous Revision button.

Temporary revisions to active maintenance programs

Revising a maintenance program is typically a lengthy process. If you need a change to take effect before the revised maintenance program is approved and activated, you can issue a temporary revision of a requirement to one or more operator revisions of an active, approved maintenance program. To issue a temporary revision of a requirement to an active maintenance program, the revised requirement must already be assigned, unassigned or revised in the REVISION version of the maintenance program. In other words, you can't make a temporary change that you're not planning to make in the next revision of the maintenance program. You might issue temporary revisions of requirements for the following reasons:

Reasons for issuing temporary revisions of requirements
Reason for revision	Result of issuing temporary revision
A brand new requirement definition	New tasks based on the requirement are added to the maintenance program.
A newer revision of an existing requirement definition that is already in the maintenance program	Existing tasks are updated to the newer revision of the requirement, except for tasks in a work package that's committed or in work.
A requirement definition was made obsolete	The requirement is marked as obsolete in the maintenance program. Existing tasks based on the now obsolete requirement are terminated, except for tasks in a work package that's committed or in work.