alt="images"/>
Figure 1.17 P4Y Privateer similar to the one that crashed on July 18, 2002 (Library of Congress, Prints & Photographs Division, FSA/OWI Collection, [LC-USE6- D-009930])
All three aircraft were leased by the U.S. Department of Agriculture’s Forest Service for public firefighting flights. However, the aircraft detailed above were originally designed to transport cargo for the U.S. military—not to fight forest fires.
Air Tanker Crashes: Design Capability versus Required Performance
The operational environment and the loads experienced by an aircraft transporting cargo are vastly different from those experienced by an aircraft fighting forest fires. The NTSB report explains that during a fire-fighting mission, an aircraft experiences “frequent and aggressive low-level maneuvers with high acceleration loads and high levels of atmospheric turbulence.” The NTSB report further details that the maintenance programs used for the aircraft were the same that were derived for the aircraft when their mission was transporting cargo for the military. The report states that the aircraft were likely “operating outside the manufacturers’ original design intent.”
In the context of RCM, the required performance of the organization using the air tankers far exceeded the design capability of the aircraft. The structural lives of the aircraft were shortened because of the harsh operating environment and the far more aggressive loads applied to the aircraft during fire-fighting versus transporting cargo. The increased loading accelerated fatigue crack initiation and sped up the crack propagation time. Therefore, the structural inspections that were in place were not accomplished often enough to identify the crack before it caused catastrophic failure. The simple concept of ensuring that an asset is capable of doing what the organization requires was completely overlooked.
Aloha Airlines, Flight 243
On April 28, 1988, Aloha Airlines, Flight 243 took off from Hilo, Hawaii, at 1:25 p.m. Shortly after the aircraft leveled off at 24,000 feet, the aircraft experienced explosive decompression and structural failure that ripped away a large section of the fuselage, as shown in Figure 1.18. One of the flight attendants, Clarabelle Lansing was immediately wrenched from the airplane. The aircraft made an emergency landing at Kahului Airport. The 89 passengers onboard and the remaining 4 crewmembers survived.
This tragedy is another example of required performance being allowed to exceed design capability.
Aloha Airlines: Design Capability versus Required Performance
Aloha Airlines was using its 737s for inter-island Hawaiian flights. According to the NTSB Aircraft Accident Report, those aircraft were accumulating three flight cycles (take-off and landing) for every hour in service. However, Boeing designed the structural inspections for the 737 assuming that the aircraft would accumulate about one and a half cycles per flight hour. Therefore, the aircraft were accumulating flight cycles at twice the rate for which the Boeing Maintenance Planning Data (MPD) was designed. Similar to the air tanker crashes described previously, this use accelerated fatigue crack initiation and increased the crack propagation time. The structural inspections and associated intervals in place were inadequate; they were not accomplished frequently enough to detect the crack before catastrophic failure occurred.
Figure 1.18 Aloha Airlines, Flight 243, April 28, 1988 after landing (Associated Press /Robert Nichols)
The air tanker fatal crashes and the Aloha Airlines’ accident are only two examples that underscore the critical importance of ensuring that an asset’s design capability is capable of meeting organizational requirements. It is a simple concept that is too often overlooked. During an RCM analysis, asset design capability and required performance are carefully analyzed.
The application of True RCM consists of preparing an Operating Context and carrying out the 7 steps of RCM.
1.9 Introduction to the RCM Process
The application of True RCM consists of preparing an Operating Context and carrying out the 7 steps of RCM. Figure 1.19 outlines the RCM process.
Chapters 2 through 8 detail the Operating Context and the seven steps of the RCM process. The following discussion briefly introduces each concept.
Figure 1.19 The RCM Process
Operating Context
An Operating Context is a document that includes relevant technical information such as the scope of analysis, theory of operation, equipment description, and RCM analysis notes. In essence, it is a storybook identification of the system to be analyzed. The Operating Context also documents notes and assumptions regarding analysis decisions. It is an important source of reference for working group and validation team members.
In the interest of time, the Operating Context is typically drafted by the facilitator before the analysis begins and is then reviewed with the working group before the first step in the RCM process (identifying Functions) is accomplished. During this time, the working group reviews and revises the Operating Context, as required. The Operating Context is considered a living document; it is edited as more is learned about the equipment and additional issues come to light during the analysis.
Step 1: Functions
The intention of RCM is to determine what solutions must be put in place to ensure an asset meets the requirements of the organization. The air tanker crashes and the Aloha Airlines disaster detailed previously illustrate how critical it is to understand what is required of an asset so that it can be determined if the asset is capable of fulfilling those requirements. For this reason, the first step in the RCM process is to identify Functions.
Functions and associated performance standards are always written to reflect what the organization requires from the asset rather than what the system is designed to provide. During Function development, it is often noted that the organization’s expectations of the equipment exceed the actual capabilities of the asset. As depicted in Figure 1.20, the Primary Function (the main purpose the system exists) and Secondary Functions (other Functions of the asset) are recorded.
Step 2: Functional Failures
Step 2 in the RCM process is to identify Functional Failures for each Function. Nowlan and Heap define Functional Failure as an unsatisfactory condition. As depicted in Figure 1.21, both Total and Partial Functional Failures are recorded for each Function. A Total Failure means no part of that Function can be performed. Partial Failure describes how the Function is still possible but is performed at an unsatisfactory level.
