Task definitions

Task definitions are the templates used to create actual tasks that are performed on applicable inventory items as these items age and accrue usage. The different types of task definitions serve different purposes, and they relate to one another.

You can establish links and dependencies between task definitions. The types of task definitions and the links allow you to model the complex relationships that make up an asset maintenance program.

In the user interface, when you see a button with task definition on it, the action is something that applies to all (or most) types of task definitions, such as activate, initialize, duplicate, delete, move, and obsolete. When you create task definitions, you create a specific type, so the buttons that you see are specific to the following types of task definitions:

Requirements (REQ)

You can use requirement definitions to describe maintenance activities at a high level, and provide scheduling information. This facilitates planning, scheduling, and compliance reporting. Examples of maintenance activities to model as requirements include the following:

  • Maintenance activities that are part of maintenance programs for your assets.
  • Work that must be accomplished to comply with a maintenance program document (MPD) from the equipment manufacturer, a service bulletin (SB), or an airworthiness directive (AD).
  • Replacement activities in which a component is removed from an assembly—so that it can be sent to a shop for maintenance, for example—and replaced with another component.
  • Troubleshooting work to resolve non-routine issues that are encountered regularly.

Requirements contain scheduling information, except for requirements created for replacement activities and corrective actions, which do not require scheduling because they are used only when needed rather than at specific intervals.

Reference Documents (REF)

Reference document definitions are often used to track compliance. In civil aviation for example, use reference documents to represent service bulletins (SB) or airworthiness directives (AD). You can link such reference documents to the requirement definitions that contain the execution information required to comply with the SD or AD, and that break down that information into several job card definitions. You can also create reference documents that are not linked to requirements, such as administrative reference documents for which no maintenance work is needed.

Reference document definitions are not initialized as active actual tasks.

Job Cards (JIC)

Job card definitions describe a unit of work that can be assigned to one or several technicians, and that completes a maintenance function. Job cards are the task definitions that specify the labor skills that are required, the parts and tools needed, the estimated duration of the maintenance task, and the steps and instructions for completing the work. Job cards are also where technicians sign off when the work is completed.

Job cards can be printed so that maintenance personnel can have them on hand as they execute the work.

Using job card definitions is optional; you can include the execution information listed above in requirement definitions—provided you designate these definitions as executable requirements—or create job cards that include some of the execution information and links to an external system that provides the work instructions for technicians.

Master Panel Cards (MPC)

Master panel card definitions list all aircraft panels that must be opened and closed during a maintenance visit. They differ from other types of task definitions in that Maintenix automatically initializes them as actual tasks when you generate the workscope of a work package. When that happens, two job cards are created: one for opening panels and one for closing panels.

Blocks (BLOCK)

You create block definitions to group requirement definitions that have similar deadlines or that represent similar functions, such as overnight checks or heavy maintenance visits. Blocks are used to assist maintenance planners in scheduling a large number of requirements that would be difficult to manage without this type of grouping, such as heavy maintenance visits that can have hundreds of requirements. You can also create block chains that contain several different block segments to execute in order. Blocks contain scheduling information.

Other than follow-on requirements, all classes of requirement definitions can be assigned to blocks.