Most of this knowledgebase is about whether something will fail. This module is about the other half of the support problem: when it does, what actually happens, who does it, how long they take, and what they need in their hands.
A maintenance task analysis takes one task at a time, decomposes it into steps, and records against each step the time, the crew, the skills, the tools, the spares, the consumables, the facilities and the hazards. It is the least glamorous analysis in the discipline and the most widely consumed: the technical publication, the provisioning list, the support equipment buy, the training plan, the manpower establishment and the level of repair analysis are all built from its output.
Identifying a task and analysing it are two different activities
This is the distinction the specifications are built around, and it is worth getting right before anything else.
| Activity | Question | Where it lives |
|---|---|---|
| Task requirement identification | Does this task need to exist at all? | The failure analysis, the preventive maintenance analysis, the operational analysis |
| Maintenance task analysis | Given that it exists, what does it take? | This module |
ASD/AIA S3000L makes the split architectural. Its earlier issues separated a task-identifying group of analyses from a task-resource group, with maintenance task analysis in the second; later issues carry both aspects in one chapter, covering task requirements and maintenance task analysis together. Task requirements arrive from four directions: failure modes, damage and special events, operational activities, and preventive maintenance task requirements.
The last of those is explicitly not S3000L's own work. Preventive maintenance analysis is performed under S4000P, which develops the preventive task requirements and their intervals. S3000L then takes each requirement it is handed and puts it through the same maintenance task analysis as everything else, which is the cleanest statement of the boundary in the whole S-series: whatever route a task arrived by, it is analysed the same way.
MIL-STD-1388-1A organises the same split as two numbered tasks. Task 301, Functional Requirements Identification, builds the task inventory using three techniques: corrective task requirements from the FMECA, preventive task requirements from an RCM analysis based on FMECA data, and operations, turnaround and transportation tasks from a review of the functional requirements. Task 401, Task Analysis, then analyses the resources needed to perform what Task 301 identified. Task 301 says what; Task 401 says what it costs in hours, people and equipment.
Where it sits
| Programme stage | What the analysis is doing |
|---|---|
| Concept | Rough task times on candidate architectures, to compare support burdens |
| Preliminary design | The task list with first-pass resources; the inputs the level of repair analysis needs |
| Detailed design | Step-level analysis, support equipment identified, provisioning demands quantified |
| Verification | Tasks walked on the article; times and resources corrected against what happened |
| In service | Corrected again by what the maintenance records say the tasks really take |
What it is not
- It is not maintainability prediction. That analysis is about the distribution of repair time, weighted by failure rate, to produce MTTR and its percentiles; this one is about one task in full, including everything the prediction does not need. The two share elemental times and answer different questions, and the maintainability prediction module covers the first.
- It is not the preventive task decision. Whether a scheduled task is worth doing, and at what interval, belongs to the preventive maintenance analysis and to reliability centred maintenance. This analysis takes the task as given and prices it.
- It is not the repair level decision. Where a task is performed is decided by the level of repair analysis, using the task times and resources this analysis produces. Analysing a task at three levels and choosing between them are different steps, done in that order.
- It is not a procedure. The technical publication is written from the analysis, by authors following their own specification. What the analysis owes them is a correct, validated sequence with its resources attached.
Where the discipline comes from
MIL-STD-1388-1A and its data companion MIL-STD-1388-2B are where the modern shape of this work was fixed: the task taxonomy, the subtask decomposition, the requirement that results be recorded in a structured record rather than in prose, and the rule that a task time is derived from its subtask times rather than estimated whole. The task data lives in 2B's C-series tables, from the task inventory through the sequential subtask description to the personnel, support equipment, manual and provisioned-item links.
ASD/AIA S3000L is the international successor most current programmes work to, with S4000P for preventive maintenance analysis alongside it, S1000D consuming the results as technical publications, S2000M as provisioning and S5000F returning in-service data. On the US side the modern replacements for 1388 are TA-STD-0017 for the process and GEIA-STD-0007 for the data.
Two things are worth knowing about the lineage before citing any of it. The specifications are on different clocks: S3000L is revised on its own schedule and is several issues past its first, while the 1388 pair are historical documents that remain the clearest published statement of the method. And the task numbering in 1388-1A is edition-dependent, because the subtask list under Task 401 changed between the 1983 base standard and its later notices, so a citation without an edition is a citation to nothing in particular.