LOG 211 Supportability Analysis

Student Guide

LOG 211 Supportability Analysis

Student Guide

The Maintenance Task Analysis

Content

Slide 91. Lesson 9: The Maintenance Task Analysis

Welcome to Lesson 9 on the Maintenance Task Analysis.

Introduction

Content

Slide 92. Topic 1: Introduction

Content

Comment by PDallosta: Slide 9-3 page 9-3 update to TMRR

Technology Maturation & Risk Reduction

Slide 93. Life Cycle Management Framework:

Where Are You? What Influence Do You Have?

The Defense Acquisition Guidebook (DAG), paragraph 5.2.1.2 states, "Maintenance Task Analysis (MTA) directly links to the system's Reliability and Maintainability characteristics. Maintenance Task Analysis is the opportunity to determine whether the design has met the Supportability requirements defined in the system specification, and provides a feedback loop to the Systems Engineer that is either positive (design has met requirements) or that there is a need for re-evaluation of either the requirement or the design itself."

The MTA spans the Life Cycle Management Framework, from Technology –Maturation and Risk Reduction (TMRR) through Engineering & Manufacturing Development.

The DAG, paragraph 5.4.2.5.1. Supportability Analysis, informs you that during the TMRR Phase, Supportability Analysis focuses on the technology trade-offs in an iterative process. At the beginning of TMRR , analyses consider requirements for key enablers in terms of "what is required." As the phase progresses, the analysis should determine the relative cost vs. benefits of different support strategies. The goal is to "establish affordable and obtainable thresholds and objective to achieve the user requirements in the projected environment within the Concept of Operations. A Maintenance Task Analysis identifies detailed logistics and support resource requirements to sustain system readiness ... [Combined with other Supportability analyses], these practices can increase Materiel Availability and readiness at a reduced cost throughout the life cycle."Comment by PDallosta: Update to TMRRComment by PDallosta: Update to TMRR

Where are you?

While the MTA, like other Supportability analyses, is iterative, during the Engineering & Manufacturing Development Phase it typically occurs after the Reliability and Maintainability (R&M) Allocation, Modeling, Prediction, and Analysis, Failure Mode Effects and Criticality Analysis (FMECA) and Fault Tree Analysis (FTA), and the Reliability Centered Maintenance (RCM) Analysis. The MTA’s outcomes provide a baseline for the Level of Repair Analysis (LORA).

What influence do you have?

During the MTA, the life cycle logistician (LCL) influences designing the support for the system, and supporting the design you help develop. The LCL may also have some influence over the system’s design, should the MTA results lead to a redesign for Maintainability reasons.

Content

Slide 94. ASOE Model

The Affordable System Operational Effectiveness (ASOE) framework incorporates the main Supportability tenets of MTA: capabilities, Reliability, Maintainability, and support. The ASOE Model is a framework in which we can visualize, at a high level, the significant role MTA plays in achieving an affordable and effective system. The MTA incorporates the majority of the model’s branches.

Design Effectiveness: The MTA identifies maintenance level, manpower, and parts and equipment that are consistent with mission requirements from the CDD.

Mission Effectiveness: The MTA validates the Supportability determinations identified in supporting analyses and determinations.

Design Affordability: The MTA provides a baseline Total Ownership Cost based on implementing a maintenance strategy that strictly conforms to the requirements of the Maintenance Concept.

It is not surprising that the MTA is the Supportability Analysis that consumes the majority of the LCL’s time and effort. MTA is where the LCL has the highest degree of involvement, exercises the most ownership, and can make the most significant impact on achieving an affordable and effective system.

Content

Slide 95. MTA Lesson Approach

Content

Slide 96. Topics and Objectives

Supportability Analysis and the MTA

Content

Slide 97. Topic 2: Supportability Analysis and the MTA

Content

Slide 98. Purpose of the MTA.

After the resources available to support the system are verified, the MTA develops and documents detailed task procedures, and identifies the required human and maintenance-related resources for preventive and corrective maintenance, and calibration.

Through the MTA, maintenance task data is incorporated into existing Logistics Product Data (LPD). Part of conducting the MTA is performing quality control of current LPD, and of the information developed and input as part of the MTA.

Additionally, the MTA verifies the appropriate maintenance level, manpower, and parts and equipment for corrective and preventive maintenance tasks. It also validates that the Supportability determinations identified through preceding analyses align with the Maintenance Concept.

Content

Slide 99. The Role of the MTA in Supportability Analysis

Inputs to the MTA include the following:

LPD updated with the resultant determinations from preceding analyses:

Reliability and Maintainability (R&M) Allocation, Modeling, Prediction, and Analysis

Failure Mode Effects and Criticality Analysis (FMECA)

Fault Tree Analysis (FTA)

Reliability Centered Maintenance Analysis/Condition Based Maintenance + (RCM Analysis/CBM+)

Maintenance Concept

The LPD tracks the outputs for preceding analyses and details the Supportability determinations that resulted from them. The MTA evaluates LPD for accuracy and completeness, and to ensure it reflects a maintenance strategy that aligns with the Maintenance Concept and Product Support Strategy.

Content

MTA outcomes include:

Fully populated and validated LPD – The MTA establishes a preliminary Supportability strategy that the LORA then uses as a baseline when evaluating the most economical maintenance approach.

Although the analyses involved in the Supportability Analysis refine one another in an iterative cycle, the LORA and MTA have a particularly close relationship and one often needs inputs from the other to be performed.

Maintainability Demonstration – The MTA is ultimately validated by the Maintainability Demonstration, or “M Demo.” The M Demo evaluates how well tasks, and the system, are designed to identify and correct system faults to restore the system to operational status. Lesson 14 will discuss this in more detail.

The Product Support Analysis (PSA) – The PSA uses standard Logistics Product Data (SAE GEIA-STD-0007) reports. These same standard reports are easily produced, repeatable and verifiable. In fact, some of the reports in the maintenance functional area are used to perform MTA evaluations. Other reports are useful in evaluating the performance of required Supportability analyses to ensure all the appropriate analyses were conducted. Lesson 12 will discuss the standard LPD (SAE GEIA-STD-0007) reports in more detail.Comment by PDallosta: updated

The Product Support Package (PSP) – The PSP documents and presents the findings of the MTA. Lesson 12 will discuss this in more detail.

Technical manual – The final MTA provides details about the most economical Supportability strategy (task allocations to maintenance levels) for documentation in the Life Cycle Sustainment Plan (LCSP) and for the creation of a technical manual.

Content

Slide 910. Maintenance Task Data & the SAE GEIA-STD-0007Comment by PDallosta: Updated

The SAE GEIA-STD-0007 data structure connects R&M, FMECA and RCM Analysis tables directly to maintenance task data. FMECA and RCM Analysis tables provide the failure risk mitigation implementation strategy that is captured and expressed by maintenance task data.Comment by PDallosta: updated

SAE GEIA-STD-0007 table relationships roll up resource requirements (equipment, facility, and technician skill level) to a specific task, as expressed through task codes, and enable standard maintenance reports. If the task consumes parts, this resource requirement is linked to provisioning, which is also a standard report used in the program’s provisioning conference.Comment by PDallosta: updated

Content

Slide 911. Supporting Analyses & the Maintenance Concept

The MTA should ensure that Supportability determinations, as expressed in maintenance task descriptions, accurately reflect:

The system design information revealed by Reliability and Maintainability (R&M) Allocation, Modeling, Prediction, and Analysis

Maintenance tasks required to ensure availability as determined by Reliability Centered Maintenance Analysis/Condition Based Maintenance + (RCM Analysis/CBM+)

System redesigns or component changes that reduce catastrophic failures identified by Failure Mode Effects and Criticality Analysis (FMECA) and Fault Tree Analysis (FTA)

The MTA frames these other analyses, as an extension of the Maintenance Concept, into consistent and effective use of:

Maintenance capabilities at each maintenance level

Manpower

Use of tools and equipment

Task repair times

Provisioning

Calibration requirements

Setting Up the MTA

Content

Slide 912. Topic 3: Setting Up the MTA

Content

Slide 913. MTA Set Up

Like many analyses, the MTA relies on ensuring that the data used to perform its evaluations is accurate and up to date. Therefore, to set up for the MTA, the LCL, in conjunction with the Integrated Project Team (IPT), should:

Identify the preliminary Supportability Environment

Identify approved sources of maintenance task data

From approved sources, gather the LPD that resulted from prior analyses

Content

Slide 914. MTA Process – Set Up

Each stage in the MTA process includes specific activities. Now turn your attention to the activities that take place to set up the MTA.

Content

Slide 915. Maintenance Resources and Policy

To perform the MTA, the LCL must first identify the resources available to perform required tasks and the policy that indicates how those resources must be utilized and allocated. This compilation of available resources and maintenance policy is sometimes referred to as the “Supportability Environment.” The Supportability Environment will be discussed in more detail in the following lesson on the Level of Repair Analysis, where time and cost are also factored into maintenance task allocation.

For the purposes of the MTA, maintenance tasks are allocated to a maintenance level based on the skills and equipment needed to perform the task, and on maintenance policy.

Content

Slide 916. Example Scenario: Maintenance Concept

The Strike Talon’s CDD indicates the following information about maintenance tasks and their allocation:

Two maintenance levels – Organizational and Depot

Troubleshooting and Line-Replaceable Unit (LRU) remove and replace tasks are performed at the Organizational level. Repair and Shop-Replaceable Unit (SRU) remove and repair tasks are performed at the Depot level.

Given the nature of tasks allocated to each maintenance level, it is implied that:

Maintenance performed at the Organizational level will require only apprentice or journeyman skilled technicians

Maintenance performed at the Depot level will require journeyman or possibly master skilled technicians

The majority of maintenance tasks for the Strike Talon shall not require equipment or facilities beyond the standard toolset. For those instances where diagnostic functions cannot be designed into the system, maintenance tasks requiring non-standard equipment may be performed at the Depot level.

Content

To demonstrate how the MTA reflects the Maintenance Concept, use a tool such as powerLOG-J to review the maintenance task information for an example component, such as the ST UAV SAT LRU assembly used for satellite linkup functionality.

Content

Slide 917. Identifying and Assembling Logistics Product Data

Because the MTA is iterative, and the analyses whose outputs the MTA relies upon to be accurate and up-to-date are also iterative, it is essential that the LCL and IPT definitively identify the:

Most current and approved sources of LPD

Person or team responsible for giving notice when LPD changes, and the process for such notification

Tools and process required for configuration management

Content

Recall that the MTA uses as inputs the resultant data from preceding analyses, and that part of the MTA is ensuring the LPD is accurate and compliant. Because of this, the MTA:

Ensures all provisioning information and component attributes are current with the system design information revealed by the Reliability and Maintainability (R&M) Allocation, Modeling, Prediction, and Analysis

Ensures system redesigns or component changes are reflected in the LPD

Acts as a safety net by ensuring that all cautions and warnings, as revealed through FMECA and FTA, are present in maintenance task descriptions

Ensures all failures have an appropriate remediation (maintenance action) as determined by FMECA and RCM Analysis

Collects and describes the maintenance determinations made through the RCM Analysis

Content

Slide 918. Example Scenario: Gather Part Data

Understanding the kind of information you need to know about a component and its related task is key to performing the MTA. To demonstrate the inputs into the MTA and where those inputs may be found, or entered, in a tool such as powerLOG-J, review the maintenance task information for an example component—the ST UAV SAT LRU assembly used for satellite linkup functionality.

By reviewing the indenture listing in the LPD, you can identify a component it is allocated as an LRU or SRU, as well as the component’s Logistics Control Number (LCN), Commercial And Government Entity (CAGE) code, and Reference Number.

From the Reliability and Maintainability (R&M) Allocation, Modeling, Prediction, and Analysis output, you determine the following about the ST UAV SAT:

Part Number (LCN) for the ASSEMBLY ST UAV SAT is ACAABA

Part Indenture for the ASSEMBLY ST UAV SAT is

End item is STRIKE TALON UAV

Subsystem is COM/NAV System

Assembly is UHF/SATCOM System

LRU is ASSEMBLY ST UAV SAT

SRU is SPLITTER ANALOG

Content

Slide 919. Example Scenario: Gather Interval Data

You can determine a component or assembly MTBCF by reviewing the Reliability and Maintainability (R&M) Allocation, Modeling, Prediction, and Analysis output. You can identify a task’s maintenance interval, determined through the FMECA and RCM Analysis, by reviewing the Failure Mode Task information in the LPD.

From the R&M Allocation, Modeling, Prediction, and Analysis output, you determine the following about the ST UAV SAT:

Mean Time between Critical Failures (MTBCF) for the ASSEMBLY ST UAV SAT is 4,444 hours. Note that the MTBCF is an estimated design metric and sometimes differs from the Mean Time between Failures (MTBF) calculated in the RCM Analysis, which would be the more accurate MTBF.

From the FMECA and RCM Analysis outputs, you determine the following about the ST UAV SAT:

Maintenance interval for the ASSEMBLY ST UAV SAT is 8 flight hours.

Content

Slide 920. Example Scenario: Gather Task Type Data

You can identify a task’s nature, determined through the FMECA and RCM Analysis, by reviewing the Failure Mode Task information in the LPD. You can also review the first character in the Task Code, which describes the task’s function. You will learn more about task codes later in this lesson.

From the FMECA and RCM Analysis outputs, you determine what failure mitigation (maintenance task) is needed to bring a failed component back to operational status. You determine that for the ST UAV SAT, failure mitigation includes:

On-condition inspection

Hard-time remove and replace

Calibration

Slide 921. Example Scenario: Gather MTTR Data

The Repair Cycle Time information in the LPD provides the average Mean Time to Repair for tasks related to a component. A specific MTTR for tasks related to a component can be identified from discussions with maintenance analysts and reviewing the Subtask Narrative Export. The MTTR is verified through the Maintenance Demo.

From discussions with Systems Engineers and Maintenance Analysts, you determine the following about the ST UAV SAT:

Mean Time to Repair (MTTR) for the ASSEMBLY ST UAV SAT is 4 hours.

Slide 922. Example Scenario: Gather Caution Data

You can identify any cautions or warnings associated with a task, determined through the FMECA and FTA, by reviewing the Subtask Identification organizational under the General information about a subtask in the LPD. You can also review the Subtask Narrative Export, which describes the specific steps in a task’s procedure, including steps to mitigate risks. The nature of the caution or warning should be input into the LPD for the related subtask.

From the FMECA and FTA outputs, you determine the following about the ST UAV SAT:

Caution/Warning of possible electrocution.

Conducting the MTA

Content

Slide 923. Topic 4: Conducting the MTA

Content

Slide 924. MTA Analysis

The analysis part of the MTA includes several activities that evaluate individual tasks and LPD as a whole.

First, the LCL identifies the task’s specific information. This includes determining the steps in the process for performing the required maintenance task, the interval at which the task must be performed, the resources required to perform the task, and at which maintenance level the task should be performed. Doing this effectively populates the LPD relevant to the task.

Once a task’s specific information has been documented, the LCL then evaluates the task for Maintainability. Maintainability describes how well the system design accounted for accessibility, modularity (which comprises packaging and testing, and discreet diagnostics).

Finally, when all tasks have been documented, the LCL evaluates LPD for two things: compliance and feasibility. Through a series of evaluations, the LCL can identify tasks that require time, skill, or equipment that exceed Maintenance Concept constraints.

Once compliance has been achieved, the LCL evaluates whether the resources (training, labor, equipment) needed to implement the Supportability strategy exceed what is already available (the current Supportability Environment).

Content

Slide 925. MTA Process – Analysis

Each stage in the MTA process includes specific activities. Now turn your attention to the activities that take place to perform MTA analysis.

Content

Slide 926. Populating LPD Through the MTA

The LCL uses the Maintenance Concept, and works with design engineers and maintenance analysts/technicians, to establish a preliminary Supportability strategy by identifying:

Maintenance levels – the maintenance levels to which tasks may be allocated; for the Strike Talon, Operational and Depot

Nature of tasks performed at maintenance levels – whether tasks are preventive or corrective, and whether the relevant component is classified as an LRU or SRU

Skill level requirements at maintenance levels – what level of skilled technicians are needed to perform allocated tasks at a given level

Equipment requirements at maintenance levels – what a standard toolbox includes and whether non-standard equipment is required to perform allocated tasks at a given level

Content

For each maintenance task, the LCL then documents the steps required to perform the task. Worksheets, such as the sample provided as a resource for this lesson, have often been used to collect the various data points about a component and its related maintenance task(s). Tools, such as powerLOG-J, have matured and now incorporate an input interface that allows the collection of data points similar to those previously captured using worksheets. Capturing and entering this data one time reduces manual re-entry and therefore the possibility of errors, and the data can be reused many times without having to input it manually each time.

Based on the requirements for a repair task, the repair capability of Depot and Organizational facilities, and the maintenance policy outlined in the Maintenance Concept, the LCL determines:

Task allocation to maintenance level – preliminary determination as to whether an LRU/SRU maintenance task is performed at a given level (Organizational or Depot)

Content

Slide 927. Example Scenario: Populating LPD

Recall that we outlined the Supportability strategy indicated by the Strike Talon CDD and gathered the following maintenance task data during MTA set up:

The ST UAV SAT (LCN: ACAABA) is an LRU that is used for satellite link functionality. It has a maintenance interval of 8 flight hours. There is a caution/warning of possible electrocution associated with the ST UAV SAT. Since resolving a failed ST UAV SAT was deemed a non-critical task, the failure mitigation is an inspection and hard-time remove and replace performed upon LRU failure.

In addition to this information, through discussions with systems engineers and maintenance analysts/technicians, you can determine:

What skill level a technician will need to perform the task

If any special equipment is needed to perform the task

What the steps are for performing the task

After discussing the task procedure with maintenance analysts/technicians, you find that journeyman skilled technicians can perform the task and that no special equipment is required. Like the maintenance task data gathered during set up, this new information must be input into the LPD.

Content

Slide 928. Example Scenario: Determining Maintenance Level

To determine a task’s maintenance level, you must know what the CDD says about maintenance level attributes, and what the task’s attributes are. The following table uses shaded blocks to map general task attributes to maintenance levels according to the Maintenance Concept outlined in the Strike Talon CDD:

Data point about item or task related to item

Organizational Maintenance Level

Depot Maintenance Level

LRU Maintenance

shaded

SRU Maintenance

shaded

Troubleshooting Tasks

shaded

Remove and Replace Tasks

shaded

shaded

Repair Tasks

shaded

Master-level Technician

shaded

Journeyman-level Technician

shaded

shaded

Apprentice-level Technician

shaded

Standard Toolbox

shaded

shaded

Special Tools/Equipment

shaded

Content

The following table builds on the previous table by using check marks to map task attributes specific to the ST UAV SAT against the maintenance levels according to the Maintenance Concept outlined in the Strike Talon CDD:

Data point about item or task related to item

Organizational Maintenance Level

Depot Maintenance Level

LRU Maintenance

shaded

SRU Maintenance

shaded

Inspection/Troubleshooting Tasks

shaded

Remove and Replace Tasks

shaded

shaded

Repair Tasks

shaded

Master-level Technician

shaded

Journeyman-level Technician

shaded

shaded

Apprentice-level Technician

shaded

Standard Toolbox

shaded

shaded

Special Tools/Equipment

shaded

According to the CDD, the ST UAV SAT

Is an LRU

Requires inspection /troubleshooting or remove and replace maintenance tasks that

Can be performed by an apprentice-level skilled technician

Use only the equipment included in the standard toolbox

Because of these task attributes, the ST UAV SAT inspection task should be performed at the Organizational level.

As with the maintenance task information you gathered during set up, and the information obtained through discussions with systems engineers and maintenance analysts/technicians, you must input the maintenance level allocation determination into the LPD.

Content

Slide 929. Maintenance Task Codes & Skill Specialty Codes

Each component in the system has associated task codes. Each task code has an associated skill specialty code.

Content

Task codes identify, for a specific item, each operator/maintenance task associated with the item.

Task codes are represented by characters which uniquely identify each maintenance task associated with particular components. The first five characters provide information relative to the performance of the task itself. The final characters differentiate tasks with identical entries for the first five characters. The characters that comprise a task code are described as follows:

Character 1 – Task Function; what action to be performed

Character 2 – Task Interval; when to perform the action

Character 3 – Maintenance Level; at which maintenance level to perform the action

Character 4 – Service Designation; represents the military service or Government agency responsible for the system

Character 5 – Operability code; indicates the status of the system when the action is to be performed

Characters 6 & 7 – Sequence Code; used to differentiate otherwise identical task codes

If the first five fields are unique, the sequence code is “AA”

If the first five fields are identical, the sequence code shall be “AB” followed by the number 1-99 as needed

The following presentation is incomplete; it lists only some of the most common types of task code characters.

Figure 1. Excerpt Task Code Tables

For more information, see SAE GEIA-STD-0007 Data Type Number: 5110; Element Type: task_code_Type.

Content

Skill Specialty codes describe the breadth of tasks under a program. Each code identifies task attributes. Task attributes include the:

Maintenance level at which the task is performed

Organization performing the task or the nature/function of the task

Technician skill level required to perform the task, which has an associated task difficulty level

The program creates business rules to set up the skill specialty code. It is recommended to always try to line the code rules up with actual Military Occupational Specialty Codes so that the sustaining organization’s training component ties to the code naturally.

Table 1. Scenario Skill Specialty Code Table

Skill Specialty

Maintenance Level

Function/

Organization

Skill Level

Task Class

OEMDM01

Depot

OEM

Master

Advanced

TALDM01

Depot

Government Depot

Master

Advanced

TALDJ01

Depot

Government Depot

Journeyman

Intermediate

TALFA01

Organizational

Technician

Apprentice

Basic

TALFA00

Organizational

Non-Technician

Apprentice

Basic

Content

Slide 930. Example Scenario: Task & Skill Specialty Code

Since the ST UAV SAT is an LRU, its maintenance activities include an inspection and removal and replacement of the LRU assembly upon failure. The inspection task’s code indicates the nature of the task as an “inspection” which is performed prior to every flight at the Organizational level by any FAA or Army technician. During this inspection task, the LRU assembly should be full mission capable. This task code is unique.

While the task code specifies that any FAA or Army technician may perform the inspection task, the task’s associated Skill Specialty code more specifically defines the skills required of a technician performing this task. The Skill Specialty code indicates that the technician should be affiliated with the Government (as opposed to a commercial entity), requires apprentice-level skills, and should perform the task at an Organizational level facility.

Content

Slide 931. Evaluating for Maintainability

As each maintenance task is documented during the MTA, it is also examined for Maintainability. One of the best indicators of Maintainability is Mean Time to Repair (MTTR). A high MTTR may be indicative of a failure to design for:

Accessibility – the failed component is too difficult to access in a timely manner due to:

Physical positioning

Complexity as a result of size, weight, or the need for support equipment

Modularity, which has two components:

Packaging: whether the component has a complex series of attachment mechanisms which could be simplified for faster removal and replacement

Testing: whether components are grouped by function in order to facilitate efficient testability

Content

· Testability, which can be assessed through:

BIT Ambiguity – A Built-in-Test (BIT) detects equipment faults and can be mapped to maintenance tasks. A BIT can be implemented in a one to one relationship (one BIT maps to one fault or LRU), or in a one to many relationship (one BIT maps to multiple faults or LRUs). The latter is referred to as BIT ambiguity, which increases troubleshooting complexity and the diagnostic component of MTTR.

Explanation:

· If one BIT measure is mapped to several LRUs (BIT ambiguity), then the probability increases of removing and replacing an operational LRU instead of the actual failed LRU, called a false positive. The No Fault Found rate is the frequency of this occurring.

· MTTR increases if there is ambiguity (one BIT measure mapped to multiple LRUs) because the operational LRUs involved would need to be ruled out as the failed components through manual troubleshooting trees with potentially many decision branches.

· If one BIT measure is mapped one-to-one with a single associated LRU, then no BIT ambiguity exists; the No Fault Found rate and diagnostic component of MTTR would be expected to decrease.

No complex system has perfect BIT fault detection because that would not be cost-effective. The level of BIT implementation is always specified in the design specification. For example, “95% BIT to 1 LRU” means:

· 95% of BIT measures map to no more than 1 LRU

· The other 5% of BIT measures can map to multiple LRUs

Contract language would specify a limit to the BIT ambiguity, such as, “not more than 5 LRUs mapped to one BIT for the remaining 5%.” The LCL's job is to assure that 5% BIT ambiguity is restricted to parts having higher Reliability. If the LCL fails to ensure this, the maintainers will be burdened with complex troubleshooting more often than not and will likely send back operationally effective parts for repair (higher False Positive rate).

No Fault Found is a Technical Performance Measure tracked at the depot level to indicate a false positive – when serviceable LRUs are incorrectly removed and shipped from an organizational level unit to the depot level for repair. If significant, the No Fault Found rate:

· Can create a false demand signal

· Adds to MTTR

· Can indicate inadequate training or troubleshooting procedures

· May indicate Built-in-Test design deficiencies

Content

Slide 932. Example Scenario: Maintainability

A review of the ST UAV SAT maintenance task information reveals that it has a Mean Time to Repair (MTTR) of 4 hours; which is greater than both the preferred 2 hour and acceptable 3 hour repair time thresholds stipulated in the CDD.

To investigate the cause of such a high MTTR, review the steps for performing the ST UAV SAT repair task and inquire with the Maintenance Analyst that assisted in determining the task procedure.

The following accessibility issue is discovered:

In order to remove and reinstall bottom access door #8 to inspect the ST UAV SAT assembly, the maintenance technician must navigate around 2 SRUs from a different assembly. This also affects the technician’s ability to attach a grounding kit to lead point #7. Further, the technician’s ability to use the miniature camera to perform the inspection actions is hindered because the camera must first be navigated around the 2 SRUs before it can view each of the areas requiring assessment.

This finding is an issue that should be reported to the responsible IPT.

Content

Slide 933. Assessing Data and Sustainment

LPD Evaluations

As mentioned earlier, part of conducting the MTA is performing quality control of data already in the database, and of the information developed and entered as part of the MTA.

The MTA validates the LPD by:

Identifying missing required data in the tasks in the LPD

All required parts are accounted for and up-to-date with the current system design

Tools, test and calibration equipment are identified for each task

Caution/mediation for failure modes identified through the FMECA and FTA is documented in the maintenance task [validate that the FMECA and FTA findings are reflected in the tasks]

All human factors, environmental, and safety factors have been considered and incorporated into tasks

Verifying that the Supportability determinations, as reflected in the maintenance tasks input into the LPD database, align with the Maintenance Concept

Task codes are correct

Tasks are assigned to be performed at the correct maintenance level/location

Tasks are assigned to be performed by a technician of appropriate skill level

Tools and test equipment required for tasks at each maintenance level is consistent with the Maintenance Concept

Determine if maintenance type, level, and frequency are appropriate

Assure preventive maintenance frequency (events/year) is reasonable and aligns with correct interval of cycles, hours, or calendar time

Spot-check corrective maintenance frequency at each maintenance level (events/year) – especially if greater than 100 or less than 1

Determine whether the Supportability measures outlined through the MTA are feasible given the Supportability environment, and availability and cost constraints outlined in the Maintenance Concept, in terms of:

Manpower = Task Frequency x Man Hours

Number of systems

Part demand costs = Task Frequency x (Number of Parts Consumed per Task x Item Cost) x Number of systems

Identify any requirements beyond the given Supportability environment or Maintenance Concept constraints and notify the IPT. The IPT will make decisions on how to address the needs the LCL identified.

Content

Slide 934. Data Assessment Methods

The MTA’s contribution to the LPD can be evaluated  by:

Relational MTA Evaluations - extract data into spreadsheet format and create queries with related charts to provide a bird’s eye view of relationships between factors in the Supportability strategy

Allows LCL to review different cross sections of the data to evaluate entire maintenance strategy and view relationships between strategy aspects and how each aspect aligns or fails to align with the Maintenance Concept

Task-by-Task MTA Evaluations - pull reports using a tool, such as powerLOG-J, (discussed in lesson 12) to provide a specific, task-by-task view and review each task for compliance with the maintenance concept

Allows LCL to evaluate individual tasks and ensure they have correct data associated with them, or incorrect data, which would indicate miscoding

Content

Slide 935. Example Task-by-Task Data Assessment

Missing pieces of required data in the tasks in the LPD database may include:

Failure mode mediation tasks and cautions

Here’s how identify missing mediations and cautions:

Divide FMECA failure modes into 3 categories:

Harm to people

Harm to equipment

Other

Review LPD to ensure task descriptions for tasks related to the components involved in each mode include cautionary information

Provisioned items – This should ensure that 1) the correct component is referenced in the task, 2) no task is missing a component and 3) all components have an associated task as appropriate.

Here’s how identify whether provisioned items are accurate:

Create a matrix of organizational-level remove-and-replace tasks that identifies the

Logistics Control Number

Item name

Provisioned Item Name

Ensure that all item names match the provisioned item name

Evaluating sample tasks in the LPD database to verify input accuracy may include:

The variation of MTTR among tasks with differing task density – This should reflect differing MTTRs for each density range and MTTRs should usually be proportionately high or low depending on the task density. If MTTRs are similar to one another or are not proportionate, unrealistic MTTRs may have been input, or a conversion error may have occurred.

Here’s how identify whether provisioned items are accurate:

Export data from the LPD database to Excel and

Determine the mean task density to identify the center-point of the midrange of density

Group tasks by density range – low/medium/high

Identify the average MTTR

Maintenance Review Strategy

While a task-by-task review may be very thorough, it will also be very time-consuming. Some Supportability Analysis tools have limitations on viewing subtasks, requiring the LCL to select one subtask line at a time, with no easy capability to export to excel. Other tools provide all subtasks in a table view with exports to excel that readily facilitate consistency checks. If the LCL has subtask viewing limitations, running standard maintenance reports is a quick way to inspect for data anomalies.

For example, by running Maintenance Summary Reports, the LCL cuts through a significant amount of information in one standard view. The LCL can determine if maintenance tasks are missing, have inappropriate task frequencies or are at the wrong maintenance level. Maintenance Summary Reports also provide information on human resource and special tool requirements.

Using the standard reports as a high level quality assurance tool informs the LCL whether to pursue a more intense review strategy.

The standard reports will also show high MTTR tasks. Spending more review time in these tasks is advised because they are likely more complex, with multiple resource and tool requirements and therefore more room for error. Inspecting extremely low MTTR tasks are also advised as they may have steps missing or have incorrect Mean Minute Elapsed Times (MMET) assigned. MMET roll up to MTTR.

This initial maintenance review strategy will determine whether a more intensive review is warranted.

Evaluating sample tasks in the LPD database to verify input accuracy may include:

· Automated Data Checking: There are automated data checks enabled by GEIA-STD-0007 database integrity rules.

For example, if a character is typed into a numeric field, the record will convert to “ERROR” and not save. If mandatory fields are left blank, a message would appear requiring that field be completed.

Each logistics reporting tool has varying degrees of data integrity checks.

Important data used in calculating task frequency is not automatically checked for realistic outcomes. For example, making a decimal point error in MTBF could lead to a task frequency calculation off by a factor of 10 or 100. These are the types of errors the LCL can significantly impact well ahead of the Maintenance/Logistics Demonstration (M-Demo).

Content

Slide 936. Example Relational Task Data Assessments

Verifying that Supportability determinations, as reflected in the maintenance tasks input into the LPD database, align with the Maintenance Concept may include:

The ratio of CBM+ tasks to RCM Analysis tasks – This should reflect the constraints of the Maintenance Concept. For example CBM+ should comprise 70% of maintenance tasks while the RCM Analysis should comprise the remaining 30%.

Here’s how to evaluate the ratio of preventive to corrective tasks overall:

Export data from LPD database to Excel

Generate a pie chart that depicts

All tasks

The ratio of CBM+ vs. RCM Analysis tasks

The ratio of preventive and corrective tasks within each maintenance level – This should reflect the constraints of the Maintenance Concept. For example preventative and remove-and-replace maintenance tasks should comprise the majority of tasks at the organizational level, while corrective and remove-and-repair tasks should comprise the majority of tasks at the depot level.

Here’s how to evaluate the ratio of preventive to corrective tasks within each maintenance level:

Export data from LPD database to Excel

Generate a pie chart for both the organizational and depot maintenance levels:

To depict all tasks within each maintenance level

To illustrate the ratio of preventive tasks to corrective tasks

The skill level required for tasks within each maintenance level – This will indicate whether a task has been:

Improperly coded for skill level

Allocated to the incorrect maintenance level

You would expect:

Almost all apprentice-level tasks to be performed at the organizational level

Most journeyman-level tasks to be performed at the organizational level with a small percentage performed at the depot level

Most master-level tasks to be performed at the depot level

Here’s how to evaluate appropriate skill level assignation:

Export data from LPD database to Excel

Generate a pie chart for each maintenance level, organizational and depot, that depicts:

All tasks within the maintenance level

The ratio of tasks requiring apprentice, journeyman, or master-level skill to execute

The equipment requirements for tasks within each maintenance level – This should reflect the constraints of the Maintenance Concept. For example, no tasks requiring special tools or equipment should be performed at the organizational level.

Here’s how to evaluate appropriate equipment requirements:

Export data from LPD database to Excel

Generate a pie chart for each maintenance level, organizational and depot, that depicts:

All tasks within the maintenance level

The ratio of tasks requiring standard or non-standard tools or equipment

Content

Slide 937. Sustainment Assessment MRR.

There are many ways to assess Sustainment. One way to assess Sustainment is to evaluate a component’s Maintenance Replacement Rate (MRR).

MRR is the number of expected failures that will require removal and replacement below depot level, per end item, per year.

MRR = Task Frequency x Quantity Per Task

Task Frequency = Annual Operating Requirement divided by the Maintenance Interval

The MRR can be used to calculate a specific component’s Return on Investment (ROI).

Content

Slide 938. Example Wiper Sustainment Assessment.

The RCM Analysis for the windshield wiper maintenance schedule is an input into MTA by:

Updating maintenance interval (hard-time) information

Examining an alternative, high cost, high Reliability wiper

As a result of these MTA updates, students will examine Sustainment impacts through three actions, each of which comprises one to three steps. The three actions are:

1. Update component maintenance interval

Assess impacts on Sustainment

Perform trade-off between Reliability, Initial Investment Cost, and Sustainment Cost

Content

Slide 939. Example: Calculate Number of Wiper Maintenance Events.

ACTION 1, Update Wiper Maintenance Interval, comprises steps one through three:

STEP 1: Calculate Task Frequency.

STEP 2: Calculate wiper Maintenance Replacement Rate (MRR) using Task Frequency.

STEP 3: Calculate total maintenance events for fleet of 100 over 1 year. This calculation provides a baseline for comparing the original windshield wiper’s Reliability with the proposed windshield wiper’s Reliability during the trade-off action.

Content

Slide 940. Example: Calculate Wiper Total Life Cycle Maintenance Cost.

ACTION 2, Assess Impacts on Sustainment, comprises steps four and five:

STEP 4: Calculate wiper total maintenance cost for 1 year.

STEP 5: Calculate wiper total maintenance cost for Fleet Service Life of 5 years.

Content

Slide 941. Example: Investigate Alternative Wiper.

Repeat actions 1 and 2 for the new, proposed windshield wiper. This will allow for comparison with the original windshield wiper in the trade-off action.

Content

Slide 942. Example: Evaluate Wiper ROI Trade-off.

ACTION 3: Perform Trade-off between Reliability, Initial Investment, and Sustainment Cost, comprises of two comparisons (one for Reliability and one for Total Life Cycle Maintenance Cost) in addition to step 6.

Reliability Comparison: The proposed wiper’s lower MRR (2 maintenance events per year vs. the 6 maintenance events per year of the original wiper) indicates the time interval between maintenance events is longer. From this comparison, it is apparent that the proposed wiper provides a significant improvement to Reliability (3 times more reliable) which means fewer parts.

Total Life Cycle Maintenance Cost Comparison: Calculate the difference in cost over the Fleet Service Life between using the original wiper and the new wiper. The proposed wiper costs significantly less to maintain over the 5-year Fleet Service Life, with a savings of $109,000 ($231,000 - $122,000) in Total Life Cycle Maintenance Cost. Fewer maintenance events means not only fewer parts, but also less manpower since fewer maintenance events are needed (and therefore less manpower) to maintain availability. This is your gain from investment.

Content

STEP 6: Calculate the Life Cycle Savings between the original and new, proposed windshield wiper. Then calculate the Return on Investment (ROI) between the original and new, proposed windshield wiper.

Life Cycle Savings Comparison: To determine Return on Investment (ROI), you must evaluate the Investment Delta between the different component’s Initial Investment Cost. In this example, Investment Delta = Investment Cost of New Fan - Investment Cost of Original Fan, or $9,000 - $4,500 = $4,500.

Return on Investment: ROI compares the potential savings with the difference in investment cost between the original and new wiper. In this example, for $4,500 more in Initial Investment Cost, $109,000 in Total Life Cycle Maintenance cost is saved over 5 years. The ROI for using the proposed wiper is greater than 24, which is excellent. Normally an ROI over 2 is considered worth the investment effort.

Reporting on the MTA

Content

Slide 943. Topic 5: Reporting on the MTA.

Content

Slide 944. MTA Report Findings.

Once LPD has been evaluated, any findings should be reported to the appropriate IPT. The IPT will determine the best solution for addressing any concerns revealed through the MTA. The MTA evaluation of LPD can reveal system design, component attributes, or maintenance processes that contribute to failing to meet Availability and Reliability requirements. It can also identify resource shortages.

Content

Slide 945. MTA Process – Report Findings.

Each stage in the MTA process includes specific activities. Now turn your attention to the activities that take place when reporting MTA findings.

Content

Slide 946. IPT Reporting Structure.

Product Support Management IPT – receives LCL’s recommended tasks for insertion into the technical manual because the LPD has been sufficiently refined. If there are any inconsistencies between the Human Systems Integration and Systems Engineering IPTs, the Product Support Management IPT resolves the conflict.

Human Systems Integration IPT – concerned with

Occupational Safety and Health Administration (OSHA) requirements

Man-machine interface issues

Whether FMECA critical failures were designed out

Whether appropriate notes, cautions and warnings are present in LPD task descriptions to mitigate FMEA non-critical failures; this sensitizes operators and maintainers to risks that may pose harm to equipment or people if deviation from procedures occurs

Content

Slide 947. Example Scenario: Reporting.

You discovered that there is a Maintainability issue with how long it takes to access the ST UAV SAT when performing maintenance tasks. This finding should be reported to the responsible IPT.

Content

Slide 948. MTA Exercise Overview.

In the Maintenance Task Analysis (MTA) exercise, you will compare the latest system design regarding the Strike Talon radio cooling fan with the current maintenance task data for the cooling fan and identify any inconsistencies that must be resolved. You will then evaluate the cooling fan’s task code and determine if the Supportability strategy for the cooling fan aligns with the Maintenance Concept.

Equations for Exercise Assessment Calculations

(1) Task Frequency

=

Annual Operating Requirement / Maintenance Interval

(2) Maintenance Replacement Rate

=

Task Frequency x Number of Parts per Task

(3) Total Life Cycle Maintenance Cost

=

(Annual Material cost + Annual Human Capital Cost + Annual Administrative cost) x System Life in years

(4) Life Cycle Savings

=

Total Life Cycle Maintenance Cost for Original Part - Total Life Cycle Maintenance Cost for New Part

(5) Investment Delta

=

Initial Investment Cost for New Part - Initial Investment Cost for Original Part

(6) Return on Investment

=

Life Cycle Savings / Investment

Summary

Content

Slide 949. Topic 6: Summary.

Content

Slide 950. Takeaways.

Content

Slide 951. Lesson 9 Summary

Congratulations! You have completed Lesson 9: The Maintenance Task Analysis.

Example LSAR-003 Maintenance Summary

9-66 of 67

January 2013

Final v1.3

January 2013

Final v1.3

9-67 of 67