Replacement requirements

You use replacement requirement definitions to model the replacement of a tracked component that is installed on an aircraft or another assembly.

Replacement requirements can be executable requirements, which contain all the instructions, and part requirements for the work, or they can contain job card definitions that contain the detailed instructions.

Regardless of the reason for the replacement—a component reaches its life limit and must be discarded, or is in need of an overhaul—the instructions and resources required to remove and install a component are the same each time it is replaced. The replacement requirement definition for a component can be re-used in any situation that requires the component to be removed. A single replacement requirement definition per component is more convenient than embedding the replacement instructions in every task definition that applies to the component.

When component tasks are initialized that require that the components be removed from an assembly, Maintenix automatically creates the necessary replacement tasks, using the replacement requirement definitions. You can also create replacement tasks manually. Replacement requirements do not include scheduling information. The deadline of the component task, which drives the need for the replacement task, is copied to the replacement task, and you cannot change it.

You create a replacement requirement definition for the configuration slot of the component to be replaced. When a replacement task is initialized, Maintenix associates the task with the parent configuration slot of the component, because that is where the replacement is done. Also, this allows the job card subtasks to remain on the parent component or assembly after the component is removed. This is important to ensure that if a component was removed, another component is installed in its place. The component task that drives the replacement, such as overhaul and discard tasks, are created on the component's configuration slot. Replacement requirement definitions are listed in the Config Slot Details page for both the configuration slot where the replacement work is required, and the configuration slot where the component is located.

In the event that an off-wing task for a component is canceled and that task has a link to the replacement task, then the replacement task is canceled, but only if work was not started on any of the replacement task's job cards. If any job cards are in COMPLETE, IN WORK, or PAUSE status, the replacement task is not canceled. This ensures that you can't remove a component on a replacement task without installing another one in its place at some time.

The following diagram depicts that Maintenix associates the replacement requirements and their job card subtasks to the parent configuration slot (21-22), and the component task definitions to tracked sub-configuration slots (BE580 and BE1578).

Figure: Replacement Tasks in the Configuration Hierarchy



Best practice is to create a replacement requirement definition for every tracked and sub-assembly configuration slot. However, if a task is initialized that requires the replacement of a component for which there is no replacement definition, Maintenix creates an ad hoc replacement task that contains the component as a part requirement, but that is otherwise empty; it does not include labor requirements, tool requirements or instructions.

For configuration slots that have multiple positions, Maintenix uses the single replacement requirement definition assigned to the configuration slot, but creates a replacement task for each position. The details shown for the replacement tasks, the job card subtasks, and the part requirements, display the configuration slot position, appended to the configuration slot name.

Job card definition subtasks

Using job card definitions to specify the instructions, parts, and labor resources that are needed to replace a component provides production planning personnel with improved visibility of the resources required. For replacements that are done only in line maintenance, and for which the removal and the installation are done within a short period of time, you can use a single job card. For the following however, consider splitting the removal and installation of a component into separate job card definitions:

  • Complex replacement tasks such as the removal of an engine.
  • Tasks in heavy maintenance visits for which the component removal occurs near the beginning of the visit, and the installation near the end.

With separate job cards, the resource needed for each task are more visible and can be managed more efficiently. When all the resources needed are specified on a single job card, knowing which resources are needed for the removal and which ones are needed for the installation is not as obvious as with multiple job card definitions. You can use the job card classes RMVL and INST for the removal job card and the installation job card, respectively. If more job cards are needed in the replacement requirement definition—for example, for a functional check to do after the installation—use any other suitable job card class.

If the instructions for performing the replacement work are different between variants of the same aircraft or assembly, you create different job card definitions as subtasks of the same replacement requirement, and specify the applicability ranges or applicability rules in the job card definitions. When a replacement task is initialized, only the job cards that apply to the aircraft or assembly are created in the replacement task.