Data Driven PHM

1

Prognostics and Health Management

A Data-Driven Approach to Supporting the F-35 Lightning II

Mr. Edward R. Brown BAE Systems (North America)

6100 Western Place Ft. Worth, TX 76107

817-762-1487 [email protected]

Dr. Neal N. McCollom Lockheed Martin Aeronautics Company

PO Box 748 Fort Worth, TX 76101


Mrs. Erin-Elaine Moore Lockheed Martin Aeronautics Company

PO Box 748 Fort Worth, TX 76101


Mr. Andy Hess Joint Strike Fighter Program Office

200 12th Street South Arlington, VA 22202-4304


AbstractThe Joint Strike Fighter (JSF) Program has developed an aggressive vision for and has specified a very stringent set of requirements for a comprehensive Prognostics and Health Management (PHM) system. This vision and the associated specified requirements has resulted in the development of perhaps the most advanced and comprehensive set of diagnostic, prognostic, and health management capabilities yet to be applied to an aviation platform. These PHM capabilities are currently being developed and integrated into the JSF Air System design. This paper will provide a top level overview summary of the current PHM concept, design, and architecture; provide a general capabilities description; and discuss overall program status. Some specific examples of system benefits, design trade-off decisions, and system integration challenges will be discussed. Particular examples of some subsystem prognostic capabilities will also be discussed.12

Index TermsAircraft reliability, aircraft maintenance, prognostics

TABLE OF CONTENTS I. INTRODUCTION.......................................................... 1 II. PHM INTERFACE ARCHITECTURE ........................... 4 III. AIR SYSTEM SCENARIO............................................. 4 IV. CONCLUSION............................................................ 10 V. REFERENCES............................................................ 11 VI. AUTHOR BIOGRAPHIES ........................................... 12

Manuscript received December 31, 2006 PIRA AER200701006 1 1-4244-0525-4/07/$20.00 2007 IEEE 2 IEEEAC paper #1597, Version 3, Updated January, 19 2007

I. INTRODUCTION The F-35 Lightning II, also known as the Joint Strike Fighter (JSF), is a triad of highly capable and closely related aircraft variants, serving differing roles and basing needs: Conventional Take-Off and Landing (CTOL), Short Take-Off and Vertical Landing (STOVL), and Carrier Variant (CV). The three variants (see Fig. 1) are designed with a large degree of commonality, enabling an efficient logistics infrastructure and maintenance environment for a highly capable and highly flexible Air Vehicle (AV).

Fig. 1: The JSF has Three Variants Designed with a High Degree of

Commonality

Augmenting the advanced capabilities of the aircraft are a tightly integrated set of advanced and comprehensive diagnostic, prognostic, and health management capabilities that are collectively referred to as Prognostics and Health

2

Management (PHM) on the JSF program. PHM is one of the true differentiators of the JSF F-35 program from other legacy aircraft programs, providing the key to assessing and managing the health of the F-35 aircraft. This article describes how PHM is integrated into the AV and the Autonomic Logistics Global Sustainment (ALGS) systems, and will demonstrate that this PHM integration supports the affordability and maintainability concepts of the Air System in an ALGS operation (See Fig. 2).

The F-35 PHM capabilities are currently being developed with a focus on early incremental development and deployment and a long-term vision for value-driven maturation, capability enhancement, and continuous improvement. However, this article will describe a fully integrated, mature PHM system and how the on-board and off-board create, manage, and distribute PHM data to support the F-35.

This article will demonstrate the overall operation of the PHM elements, by tracing PHM data from the initial finding of a fault within a subsystem on the AV, through the AV architecture to the AL systems and resulting maintenance

actions. This will cover identifying the root cause, including having the subsystem identify the fault; to reasoning about the system within the on-board Knowledge Base (KB); to verifying the fault with a cross-correlation function; to the information flow in the off-board systems to show how the fault is addressed by the maintainer. The description will cover the off-board systems operation including the manpower (Maintainers and Sustaining Engineers) and utilization of certain Autonomic Logistics Information Systems (ALIS) tools to perform the appropriate maintenance:

- Computerized Maintenance Management System (CMMS),

- Customer Relations Manager (CRM), - Force Life Management (FLM), - Knowledge Discovery (KD), and - Anomaly and Failure Resolution System (AFRS)

Fig. 2: PHM is Key to the Support of the JSF by the ALGS

A. Overview The first flight of the first F-35 aircraft was accomplished in December 2006, at the Lockheed Martin Aeronautics facility in Fort Worth, Texas. This important milestone in the development program introduced the inherent

capabilities of this advanced vehicle. It also set the groundwork for the successive deployment and expansion of equally advanced integrated supporting systems, both on- and off-aircraft.

3

From a PHM perspective, the first flight of a vehicle is an important juncture, but it is the ability to support successive flights and operations of that vehicle that is the measure of success. Reliability of the supporting systems, including PHM capabilities, is no less important than correct and safe operation of the aircraft. Add to this the complexity and criticality of multiple aircraft, multiple aircraft variants, deployed across multiple locations and services and countries, and the need for a highly efficient logistics and maintenance environment becomes clear. The F-35 Lightning II program achieves this by balancing the on-board and off-board capabilities to support better-than-legacy fault detection, fault isolation, false alarm prevention and suppression, life usage, force life management, and condition-based maintenance. Integrating component and subsystem diagnostic capabilities with on-aircraft and off-board enhanced diagnostics and reasoning allows for improved turn-around for maintenance actions; integrating these with extended data collection and analytical tools and techniques allows for efficient resolution of anomalous behaviors, life and performance trend discovery, and for continuous improvement and enhancement of the PHM elements.

Prognostics and Health Management is a combination of on-board and off-board systems and supporting infrastructure. The AV PHM system in conjunction with the AL system enables increased Sortie Generation Rate and reduced Logistic Footprint. In the context of JSF, PHM includes the following capabilities: - Testability/Built-In Test (BIT) capabilities, - Pertinent data acquisition at sensor, component, and

subsystem levels, - Enhanced diagnostics, beyond the legacy

testability/BIT capabilities, through system models, corroboration, correlation, and information fusion,

- Prognostics, including material condition assessment and prediction of the remaining useful life and time to failure of components by modeling fault progression, and

- Health management, including the capabilities to maximize (in conjunction with on-board planners and subsystem managers) system effectiveness in the presence of system anomalies, provide decision support to optimally plan or defer maintenance, and manage component life. [1]

B. AS PHM System Architecture The overarching PHM system design philosophy is to automatically fault isolate when the fault is detected; and perform higher level analysis in the on-board PHM software systems automatically and seamlessly without human intervention. By system design, the need for pilot intervention will be kept to a minimum. Fault detection and fault isolation data will be electronically downlinked on approach to the base as soon as possible and practical in

order to start the ALGS processes to re-launch the aircraft. Fig. 3 shows the PHM System from on-board to off-board

The F-35 PHM solution is based around a balanced distribution of key elements, with PHM data and flight critical elements being active on the aircraft, and those being critical to maintenance or fleet management being off-board. On the aircraft, each major component of each subsystem implements basic fault detection and reporting designed to improve isolation of failures to a single replaceable item. The subsystem reporting data is collected, managed, and filtered by a group of subsystem and system behavioral models, which generate common and corroborated Health Report Codes (HRC) which define significant fault or life events in the vehicle. Additional structural and subsystem life data is concentrated within the vehicle, and stored for later use. Related functions operate in parallel to, but separate from, PHM to report safety critical events and reconfigurations to the pilot. (While these are not strictly PHM capabilities for the JSF program, they do operate using common source data to ensure consistency of safety critical aircraft state reporting to the pilot with the maintenance-centric PHM data.) The on-aircraft data management and models exist within Area Managers, which concentrate functionality by subsystem or by natural integration groupings of subsystems.

All PHM data stored on-aircraft resides in either an Aircraft Memory Device (AMD) or Portable Memory Device (PMD), the latter being removable for use in post-flight debriefs and maintenance data downloads. All PHM data is managed within a highly structured file system, allowing for natural segregation of data for ease of use by the off-board applications. This approach also serves to satisfy program data control constraints and support the business plan of the ALGS operations.

Off-board PHM functions include those functions that are not flight critical and that are more amenable to on-going enhancement and maturation. [2] The off-board functions tend to be grouped by usage rather than by component (as is the case for the on-aircraft elements). From a PHM perspective, they fall into a few basic categories: Air Vehicle Health Management, Failure and Anomaly Resolution, Force Life Management, and Knowledge Discovery. These systems are closely integrated within the Autonomic Logistics Information Systems (ALIS). ALIS is a broad collection of tools and data sets that support the deployed and maintained Air System; from a PHM perspective, one of the closest integrations is with the Maintenance Management (MM) function for the generation and closure of work orders for aircraft repairs or changes. Providing a natural and intuitive human interface to the complex (and large!) sets of aircraft health data ensures that component, aircraft, squadron, and fleet maintenance and management is achieved with less variation, training, and exceptions than legacy platforms.

Collectively, these PHM elements allow for efficient and cost effective maintenance of aircraft faults, support rapid

4

and intuitive management of component and structural life usage, enable Condition Based Maintenance (CBM) in place of legacy time-based replacement or inspection. These PHM elements also provide for on-going data-driven

lifing and failure trend analyses and investigations, and allow for flexibility in maturing and enhancing the PHM capabilities over the operational life of the F-35 Air System.

Air VehicleOn-Board Health Assessment

Air Vehicle/Support SystemInterface

ALGS & Off-Board PHM

Automated Pilot/Maintenance Debrief

Off-Board Troubleshooting Off-Board Prognostics

Trending Life Mgmt Fleet Mgmt

Knowledge Discovery Store/Distribute

PHM Information

Mission Critical

PHM Data

Displays and Controls

.

Portable Maintenance Aid(PMA)

Flight Critical

PHM Area Managers

Provides:

In-Flight Maint.Downlink

Joint Technical Data,Consumables, Stores

Off-Board Diagnostics (AFRS)

Health/Service Info

Database

AV-Level Info Mgmt. Cross Correlation Intelligent FD/FI FA Mitigation Auto. Logistics

Enabling/InterfaceAMD/PMD

ALISAV PHM

Area Manager

Fault Accommodation

Status via Integrated Caution,

Advisory, and Warning System Portable Memory Device

(PMD)

Propulsion

MissionSystems

Airframe

VehicleSystems

Maintenance Vehicle Interface

Sensor Fusion Model-Based Reasoning Sub-system Knowledge Bases Tailored Algorithms Systems Specific Logic / Rules Feature Extraction

Methods Used:

Decision Support Maintenance Planning Condition-Based Maint. Affordable Logistics

Results In:Crash DataRecorder

Air VehicleOn-Board Health Assessment

Air Vehicle/Support SystemInterface

ALGS & Off-Board PHM

Automated Pilot/Maintenance Debrief

Off-Board Troubleshooting Off-Board Prognostics

Trending Life Mgmt Fleet Mgmt

Knowledge Discovery Store/Distribute

PHM Information

Mission Critical

PHM Data

Displays and Controls

..

Portable Maintenance Aid(PMA)

Flight Critical

PHM Area Managers

Provides:

In-Flight Maint.Downlink

Joint Technical Data,Consumables, Stores

Off-Board Diagnostics (AFRS)

Health/Service Info

Database

AV-Level Info Mgmt. Cross Correlation Intelligent FD/FI FA Mitigation Auto. Logistics

Enabling/InterfaceAMD/PMD

ALISAV PHM

Area Manager

Fault Accommodation

Status via Integrated Caution,

Advisory, and Warning System Portable Memory Device

(PMD)

Propulsion

MissionSystems

Airframe

VehicleSystems

Maintenance Vehicle Interface

Sensor Fusion Model-Based Reasoning Sub-system Knowledge Bases Tailored Algorithms Systems Specific Logic / Rules Feature Extraction

Methods Used:

Decision Support Maintenance Planning Condition-Based Maint. Affordable Logistics

Results In:Crash DataRecorder

Fig. 3: High-level View of PHM On-board and Off-board Architecture

II. PHM INTERFACE ARCHITECTURE The interface architecture is defined as the interface between the Air Vehicle (AV) and Autonomic Logistics Global Sustainment (ALGS) capabilities. Data interface begins with data transfer from the AV to ALIS. This data transfer may occur in three different ways: via the Maintenance Downlink (a UHF transmission of critical maintenance data), via data transfer from the PMD, or through the AMD via the maintainers Portable Maintenance Aid (PMA) using an ALIS workstation. The AMD is installed in the aircraft and the PMD or brick is a copy of the flight history data that the pilot detaches from the aircraft and takes to the post-flight debriefing. The PMA is the hand-held computer that holds technical data (e.g. maintenance instructions) and maintenance software tools for the maintainer. The PHM data that comes off the aircraft not only updates ALIS and starts the maintenance processes, but it also updates Mission Systems with the results of the sortie. The Maintenance Downlink is used primarily for advanced notification of AV health status prior to AV landing. On the return-to-base portion of the sortie, the pilot initiates the Maintenance Downlink by transmitting current health status to the ALIS Ground Based Communication Unit. At the pilots discretion, another downlink may be initiated after landing to communicate additional information (e.g. the impact of a hard landing or problem indications from on-board sensors) to ALIS.

The current health status in the downlink consists of a minimized data set that includes Health Reporting Codes (HRCs), consumables status, and weapons status. This allows for advanced knowledge on the mission capability (overall health) of the AV and the consumables and weapons needed for re-launching the AV. In a combat situation, this advanced information allows for an assessment of whether the AV is capable of making another sortie or if another aircraft is needed to take its place. Following the completion of a sortie, the pilot removes the PMD from the AV and carries it to an ALIS workstation in order to conduct the operational and maintenance debrief. The PMD and ALIS interface capability is used to transfer PHM files within the off-board mission support to the off-board systems. The files on the PMD contain the same data communicated in the Maintenance Downlink (i.e. the latest status of HRCs, consumables and weapons as captured just prior to AV power down), as well as additional PHM data used for Prognostics, Life Management and Assess Material Condition. As with the Maintenance Downlink, this data is processed by off-board software and sent to Maintenance Management to identify and mobilize the necessary logistical requirements to turn the air vehicle.

III. AIR SYSTEM SCENARIO The scenario in this section describes the flow and usage of data from the on-board systems and processes to the off-board systems and tools. The following describes an on-board scenario where data is generated for analysis while the plane is airborne. This data is then transmitted to the

5

off-board systems and maintenance actions are taken using off-board applications. Although this one example cannot demonstrate all the interactions of all the system elements, it will indicate the flexibility and richness of capability.

A. PAO Modulating Valve Scenario In this scenario, a fault is assumed inside a liquid cooling loop within the aircraft. Liquid cooling on JSF is accomplished with Polyalphaolefin (PAO) eliminating subsystem generated heat, and rejecting that heat into the aircrafts cooling streams. The example will focus on a

PAO modulating valve known as the Radar Restrictor Valve, which regulates coolant (the PAO) to the radar unit on the aircraft. This scenario traces a thread of fault events from the issuance of the command to open the valve to the detection of the fault. The scenario then will describe signal paths into the AMD/PMD and the resulting Maintenance Downlink. A simplified functional schematic of the Power and Thermal Management System (PTMS) is represented in Fig. 4.

CT S/G C PT

Recup-erator

PAO to AirHX

FuelHX

Fuel

S/G

Combustor

Equip

PMG

FDHX

Engine

FWDEquip

EHAControllers

Precooler HX

LoadHX

OBOGS

OBIGGS

Item 11

Item 10

Item 202

Item 120

Item 107

Item 48

Item 13

CT S/G C PT

Recup-erator

PAO to AirHX

FuelHX

Fuel

S/G

Combustor

EquipEquip

PMG

FDHX

Engine

FWDEquipFWDEquip

EHAControllers

EHAControllers

Precooler HX

LoadHX

OBOGS

OBIGGS

Item 11

Item 10

Item 202

Item 120

Item 107

Item 48

Item 13

Fig. 4: PTMS Functional Schematic

The scenario describes a PAO Modulating Valve which has failed in the closed position. The goal of this fault scenario is to trace the failure mode of PAO Modulating Valve Stuck Closed and describe how that fault signal is propagated through the AV and on to the ground-based systems.

As a starting condition, we assume that the AV is a CTOL variant, is airborne and has no other related latent failures. Based on the pilots operational commands, the PTMS will command the valve to open to the desired final position in degrees. The command is received by one of the remote input/output (RIO) devices and translated into a valve direction command in the form of an appropriate increment or decrement in one degree pulses. During the issuance of direction command, the RIO is monitoring the valve position and will continue to pulse the command until the desired position is obtained. The on-board software will set a stuck fault signal when the position of the valve is not within a specified bound of the command with a device-specific persistence.

If all of these conditions are met, the stuck fault signal will be asserted True and an overall status signal will be

asserted to Not Available. At this point in the scenario, there is not enough information to indicate whether the valve is stuck closed, stuck mid-way, or stuck open. The software packs these signals into specific messages and makes them available to the PHM software resident in one of the other computers on the aircraft, which is the Display Management Computer (DMC) in this example. Once the signals arrive in the DMC, the PHM software notices that the signals are asserting a fault (i.e. that the BIT reports a discrepancy for the function including the PAO Modulating Valve) and generates the appropriate HRC. The PHM Software in the DMC sends the HRC to the PHM Area Manager via an internal PHM message. The Area Manager is the PHM software in the DMCs that is responsible for communicating the PHM information to the appropriate on-board systems. The AV PHM Area Manager software notices that the HRCs have been instantiated and routes those signals to the appropriate locations.

Since one failure may generate multiple HRCs, only those that are set as root cause get routed to the pilot for display or to the on-board system for Maintenance Downlink. For example, it is reasonable to believe that the devices that expected the cooling are reporting a discrepancy, or perhaps

6

even parasitic faults, because the cooling was not available at the needed state. The PAO Modulating Valve stuck fault signal is NOT set as roll-up so it does not get sent to the pilot for display or to the Maintenance Downlink. It does get sent to the AMD/PMD for storage and to the ICP for KB analysis. However, the PAO Modulating Valve Status is a roll-up HRC and does get sent to the pilot for display, to the ICP for KB analysis, and to Maintenance Downlink. At this point in the scenario, the PAO Modulating Valve status signal does not indicate whether the valve is stuck open or stuck closed. This signal is only interpreted as valve Not Operational. Once the PAO Modulating Valve status is processing within the PHM Area Manager functions, the on-board KB has access to all the other signals associated with this fault. Concurrently, the KB is monitoring the commanded valve position with the actual valve position. Combined with other AV information, including commands, valve positions, operational signals from the radar, environmental air data, and complex valve characteristic curves, the KB either confirms or denies the PAO Modulating Valve Stuck Fault. For example, if the fault signal is asserted True and the radar is still indicating no overheat condition, the KB may declare this a false alarm or continue searching for the root cause of the fault assertion. If the KB confirms the stuck fault is an actual fault, the KB will determine if the valve is stuck closed or stuck open, and this information will be communicated to the AV Area Manager resident in the ICP. The AV Area Manager will combine the output of the VS PTMS KB with other AV information and set a pre-determined AVPHM HRC. This HRC will be sent to the pilot for display, the AMD/PMD, and to the communications systems for Maintenance Downlink (activated when the aircraft approaches the return base for landing). On one of the screens in the cockpit, the pilot will see an interpretation of the HRC (e.g. Radar Control Valve status = Not Available) and a functional assessment (e.g. Cold Liquid Loop Degraded).

B. PHM Data in Autonomic Logistics After PHM data is downloaded from the PMD, the off-board system will handle the extraction, storage, and distribution of the PHM data. This downloaded data will include AV HRC data, AV life component performance data, AV performance data, propulsion PHM data, and structural fatigue data. This data is used to provide input to the off-board tools and processes to assist in tracking and measuring the health of the components on the AV.

AV data extraction begins the process of determining AV health. The following health data components have been identified as sources of input that are used for maintenance action work orders or to supplement troubleshooting.

- HRC - This is primarily the output from the PHM reporting system on the AV. It identifies the Logistics Control Number (LCN) of the fault identifying subsystem, the method of detection, and the symptom of failure. The LCN makes it possible to identify safety

critical and mission critical faults. A manually generated HRC, either from a pilot or maintainer, is also processed within the off-board system the same way as a data download. The HRC is mapped to a human readable definition within the CMMS.

- Raw data - This is collected from the systems that are not covered by PHM monitoring from the subsystem directories under the PHM directory structure. This data will be stored and used by Sustaining Engineering within the Knowledge Discovery (KD) off-board application (described in Section I.A.1)).

- Event data - This is the parametric or performance data surrounding an HRC time stamp. It can be any pre-selected data pertaining to the HRC and includes such things as whether valves are open or closed, flow rates of system fluids, air vehicle motion data and any other data the HRC designer regards as relevant. This data provides an event window that covers a short time before and after the HRC occurred, which is used for fault diagnosis and to allow the maintainer to know what was happening with other systems at the time of the HRC generation. This will most likely only be used in the case of an anomaly, where a single specific repair cannot be determined from the event. (Such a case ultimately leads Sustaining Engineering to create new cases for the AFRS tool, an inherent enhancement to the PHM system capability over time. This is described in Section III.C.2.

- Performance information - This is extracted from ALIS for selected systems and areas to provide behavioral operations of AV systems and conditions of use. This data will most likely be used to trigger and refine Assess Material Condition (AMC) criteria and for Force Life Management (FLM) trending purposes.

1) Data Distribution Data Distribution is the final functional area and is a key for many users of data coming on and off the AV. Fig. 5 represents the off-board flow of data. The distribution function ensures all data is stored once and then made available to a wide variety of users/systems many times. Extracted data is distributed to designated data stores so a local repository of algorithms can be systematically applied for analysis and decision support. The stores hold PHM, life usage, structural, fatigue, propulsion and performance files from the AV. As well as receiving data from the AV, there is a need to load data to the AV, which may be handled by the AV Data & Distribution sub-domain. This data upload takes many forms and includes AV files, map images, lifing data, fatigue data, propulsion data, theater data and the Software Data Load. All this data will be transferred from local repositories and loaded to the AV through the PMD or, as a backup, the PMA.

7

AV Data: Manage & Distribute

AV Health Data

HRC Store

AV HealthCompiles AV

Composite Health

AV Health Filters

Duplicates

AV HealthExtracts

AV HealthBuildsWO file

ALIS Maintenance Management

MaintenanceHistory

PMA

MVIAFRS

Data Extraction

AV: PMD

AV: DataLink

AV Health:AMC Algorithms

AV Health:Force Life

Management

CMMS

Comprehensive Off-Board Functions Complement AV Capabilities

Failure Reporting, Analysis, Corrective Action

System

AV Data: Manage & Distribute

AV Health Data

HRC Store

AV HealthCompiles AV

Composite Health

AV Health Filters

Duplicates

AV HealthExtracts

AV HealthBuildsWO file

ALIS Maintenance Management

MaintenanceHistory

PMA

MVIAFRS

Data Extraction

AV: PMD

AV: DataLink

AV Health:AMC Algorithms

AV Health:Force Life

Management

CMMS

Comprehensive Off-Board Functions Complement AV Capabilities

Failure Reporting, Analysis, Corrective Action

System

Fig. 5: Off-board Processing Flow

The Software Data Load will be put through a pre-load check to test for hardware and software compatibility with the as-maintained configuration of the individual air vehicle being loaded. After this compatibility check, a data verification check will be carried out by the AV before the final stage of loading the data to the PMD or PMA file transfer capability. These pre-load compatibility checks are required to ensure any failures or inconsistencies are caught before the actual load to the AV is carried out. This check is performed to reduce errors on the file upload to the AV and minimize impacts to Sortie Generation Rate and AV downtime.

2) Off-Board PHM Support The off-board systems will process the data that is generated from the AV, to include a comparison against open AV discrepancies. The result of the processing will be a minimized list of work order suggestions that MM will turn into WOs. As part of that processing, a decision support mechanism is presented to the user to assist in a decision to ground the AV due to impacts to safety critical failure modes, as well as providing a decision support mechanism to aid the user if a failure impacts the aircrafts current assigned mission. [2]

Certain damage assessment (AV outer damage impacting aircraft surfaces) is also performed. The pilot and/or maintainer notes on the PMA any indicated or observed damage to the AV; the system determines the WO necessary to repair the AV to restore capability, and the Off-Board Mission Support Environment determines which mission types are unsupported if repairs are not performed. This information is provided to other components of ALIS that assess the impact to follow-on missions and update the status of all affected assets. The integrated ALIS performs maintenance schedule processing like any other maintenance activity. If this AV can still support other missions, ALIS may recommend postponing the maintenance if it could be used as a substituted asset for a previously scheduled mission. In this way, aircraft mission

availability is maximized and opportunistic maintenance can be scheduled for cost or for resource availability reasons.

C. OBPHM Tools 1) Force Life Management (FLM) The FLM toolset provides decision support to the maintenance supervisor by providing a composite view of the health of the jet. The composite view includes:

- Current hard failures - Impending failures (FLM AMC modules and

prognostic algorithms) - Time dependent maintenance activities (Reliability

Centered Maintainability Analysis (RCMA) or equivalent based)

Usage data is accrued during AV operation and total fleet life to increase the total system availability, performance and affordability. Such increases are enabled by:

- Accurately identifying AV condition - Improving efficient planning of necessary AV

maintenance - Providing the information necessary for refinement of

maintenance planning by better tracking of life consumption and accurately predicting time to failure

- Trending actual usage vs. nominal design data, identifying impacts on AV health status

The FLM tool will use trending information in conjunction with AV PHM system models (results), failure records, operational information (mission profiles), and environmental changes to determine the rate at which usage and life is being consumed. [3] Air vehicle integrity, build configuration and all changes and repairs identified and made to the AV will be analyzed to provide extensive background justification to the figures provided to the end users. The FLM application will also have the ability to store current lifing information and manipulate this information to simulate results that would be generated should different sortie, environment, or pilot flying profile be calculated. Tolerance management will be used to provide quantified warnings and cautions as to how the systems are being operated.

The screenshot in Fig. 6 shows a graphical representation of how operational data mapped to specific aircraft can be formatted to provide performance related information. In this case, it is an analysis of fuel consumption with respect to different dependent variables.

This specific aircraft information can be used to quickly identify trends and usage patterns relating to differing variables that relate to the aircrafts past, current and future health status. [4] Although fuel consumption is a consumable, monitoring the consumption rate helps determine the operational usage and explore deterioration relating to the aircrafts systems and subsystems. The FLM

8

system will be configured to produce automatic reports to show consumption figures and the variables that affect the

values.

Fig. 6: Example of FLM Drill-down - Fuel Usage Rate by Mission Type and Pilot

The diagram shows average consumption values per pilot, mission type and aircraft type, however the system shall be tailored to show historic values (trending), actual values (per aircraft download data) and expected values rates (prognostic extrapolation) to enable forecasting features to be activated. Examples of information monitoring include: - Fuel Consumption per flight - Fuel Consumption per mission type - Fuel Consumption per sub-system - Fuel Consumption per pilot - Fuel Consumption per tail number - Fuel Consumption per squadron - Fuel Consumption per fleet Providing the data in these types of reports provides users direct access to the type of information that allows them to make rapid business and operational decisions. The FLM systems allow the users to transition from using segmented data parameters with additional analysis timescales to instantaneous information reporting functions. In addition to static data trending, the system will provide notification relating to rapid consumption rates and exceedances from

the nominal usage curve. The system will be configured to create an automatic processing functionality to the maintenance and sustainment groups when the predefined data trends are detected, reducing the need for data analysis to be conducted away from the operational arena.

2) Anomaly and Failure Resolution System (AFRS) The Anomaly and Failure Resolution System consists of a suite of capabilities whose collective goal is to support field maintainers and system experts, including field engineers, in the resolution of JSF aircraft failure scenarios. AFRS will be available at the point of maintenance and at the main ALIS site. The primary capabilities of the toolset are failure resolution, anomaly resolution, knowledge base management, reporting and notification.

Key benefits of AFRS include:

- Available 24/7 - Supports failure & anomaly resolution - Captures lessons learned across the JSF fleet - No dependency on an individuals knowledge - Accessible at squadron level maintenance via ALIS - Configurable solution search

9

- Case-based reasoning - AFRS interacts with MM during the resolution of

failures The AFRS tool is an interactive tool that leads the maintainer through a series of questions to obtain a solution. Over time, the maturation of AFRS is accomplished by real feedback from the field and consolidation into a fleet-wide knowledge base. Fig. 7 shows a typical interactive user screen on the PMA. In this case, it is troubleshooting the PAO subsystem.

As an example, PHM has isolated the failed components or projected a pending failure or condition and recommended maintenance. For those pending or prognostic items, the expected time to failure or maintenance is given. The following scenarios depict the different ways the maintainer can employ the AFRS tool:

- Regular Maintenance This is the "business as usual" process where the maintainer performs maintenance on the AV as instructed through the PMA. Work orders can be generated in one of two ways.

The first is as a result of the AV generating an HRC, the second is scheduled maintenance activity.

- Failure Resolution If the regular maintenance procedure fails and a HRC is known, the maintainer invokes AFRS from the PMA attempt to resolve the problem. If no HRC is available, the maintainer immediately logs the anomaly with 24/7 Technical Support. In these situations, the Failure Resolution process is not applicable and the Anomaly Resolution process is invoked.

- Anomaly Resolution When the failure resolution process fails, the maintainer enters an anomaly service ticket in the Customer Relations Manager (CRM) system within ALIS. CRM routes the service ticket to Sustaining Engineering at the main ALIS installation site. Sustaining Engineering works with the maintainer to resolve the anomaly using CRM and AFRS. The AFRS master is then updated with the results which will allow all maintainers access to the solution.

Fig. 7: AFRS Interactive PMA Screen

10

3) Knowledge Discovery The Knowledge Discovery (KD) capability is designed to discover and report knowledge embedded within aircraft and population PHM/flight/repair history data. The KD process uses a collection of techniques that can handle large amounts of data to detect relationships between events otherwise not revealed or revealed at large expense and human effort. KD provides configurable automation for reporting and distribution of relationships that are found. It facilitates the enhancement of diagnostics, prognostics, and performance tracking for data domains. KD provides two processes: a background process and an interactive use-mode. The background process discovers and reports associations between various variables without intervention of a human operator. The interactive use-mode aids the engineer in rapid and cost-effective model development in support of resolving difficult failure scenarios. In general, KD follows the following four iteratively applied steps: 1. A mining question is formulated. This question

specifies what kind of information is being sought. In general, a mining question is formulated together with domain experts.

2. The data that may be used in order to resolve the mining question is selected and analyzed.

3. A mining algorithm is selected or developed to search for the appropriate answers.

4. The results of the search process are presented to experts in a way that they can understand and evaluate them.

KD will be used to find opportunities for improvement to maintenance effectiveness in the maturation of the AFRS and FLM tools, and the analyses of maintenance, part usage, and repair data.

D. Maintenance Processes The AV with the stuck open PAO valve has downlinked that information along with other aircraft status to ALIS. ALIS processes the data and the CMMS application presents a work order file to the maintenance planner. The maintenance planner accesses the FLM tool to determine mission impacts and decides if the following missions are dependent on this fault being fixed. This allows the maintenance planner to determine if the work is to be started now or delayed for operational or mission reasons. The maintenance planner sends the draft WOs to the appropriate maintenance supervisor who will assign maintainer(s) to the tasks. CMMS alerts the maintainer that a WO has been assigned to him if he is logged into CMMS, or the maintenance supervisor may also verbally alert the maintainer.

The assigned maintainer checks out a PMA and docks it into ALIS, which then passes the work order information to the PMA. The maintainer activates AFRS and is presented a ranked solution set for addressing the HRC. Once a

solution is selected, the work order information on the PMA identifies the additional support equipment, parts and maintenance tasks necessary to execute the maintenance task. Synchronizing the PMA at this point automatically generates a material request for the replacement valve to supply. The maintainer verbally coordinates with their maintenance supervisor as needed. The maintainer checks out the necessary support equipment, is issued the part, and proceeds to the maintenance facility at the base to meet the aircraft.

When the maintainer arrives at the aircraft, the work order is activated on the PMA and displays the applicable technical order data to start the task. The maintainer performs aircraft safe for maintenance task as directed by technical order data and begins the radar maintenance tasks to access and remove the valve. In addition, any servicing for consumables or re-arming necessary for the aircraft is also authorized by work order(s) and performed by a maintainer (Fig. 8). The maintainer responsible for the repair removes the bad valve and scans the bar code of the new part into CMMS so that the specific part is tracked with the specific plane for historical (as-maintained data) and analysis purposes. The maintainer then installs the new valve, closes up the aircraft according to the maintenance instructions, performs any required test to verify the repair, and closes the work order on the PMA. The work order completion is either wirelessly communicated to ALIS or physically communicated when the PMA is docked into ALIS by the maintainer.

Fig. 8: Maintainers Repairing and Servicing the Aircraft

IV. CONCLUSION The F-35 Lightning II is a highly reliable, intelligent, and data rich aircraft. The on-board fault detection and fault isolation is built into the systems, subsystems and the hierarchy of knowledge bases and area managers. When a fault is not isolated on-board, the off-board systems and tools will find the problem and provide the appropriate information to the maintainer to correct the problem and get the aircraft back into the sky. If an engineering or research effort is needed to break an ambiguity group to isolate the fault, that information and process is recorded into the off-board systems for future use across the fleet. The off-board data and algorithms are used for prognostics and trending so that problems are anticipated and solved before there is a

11

hard failure. These systems and processes are all part of the Prognostics and Health Management approach for the F-35.

Although the JSF PHM solution is still early in its development and maturation life cycle, its benefits have already been seen. The operation of on-board elements has been modeled and tested, and initial operations have already been developed and tested for deployment during the extensive flight test cycles. Ongoing subsystem and PHM product improvements have been identified and assigned, even prior to the first flight of the first F-35 aircraft. This is well ahead of legacy programs. The close integration of on-board and off-board systems has allowed for balanced and beneficial design and initial development, with fewer interface or interoperation issues. Early work in the expected volume of data per aircraft, coupled with the projected operational rates of a very large, and steadily growing, total deployed fleet, allows the ALIS environment to provide balanced and flexible data access and availability based on the needs of the various types of users.

In short, the early and incremental development of the F-35 Lightning II PHM system is providing benefits in the beginning stages of the aircraft development and flight test program, and is poised to enable continuous operational

improvement for the essential affordability goals of this large, complex, and critical technology development program.

V. REFERENCES [1] Engel S, Gilmartin B, Bongort K, Hess A., Prognostics, The Real Issues Associated With Predicting Life Remaining, March 2000 IEEE Conference [2] Calvello G., Dabney T., Hess A. PHM a Key Enabler for the JSF Autonomic Logistics Support Concept, paper # 1601, 2004 IEEE Conference, March 2004. [3] Hess A. and Fila L. Prognostics, from the Need to Reality from the Fleet Users and PHM System Designer / Developers Perspectives, paper #116, 2002 IEEE Conference, March 2002. [4] Hess A., Frith P., Calvello G. Challenges, Issues, and Lessons Learned Chasing the Big P: Real Prognostics Part 1, paper # 1595, 2005 IEEE Conference, March 2005.

12

VI. AUTHOR BIOGRAPHIES Edward R. Brown is Senior Manager for F-35 Lightning II Prognostics and Health Management, responsible for PHM product development and integration for all F-35 aircraft systems, across the JSF Lockheed Martin / Northrop Grumman / BAE SYSTEMS team. Ed, an employee of BAE SYSTEMS Inc., has held leadership roles in the JSF program since the contract was awarded in October 2001, and prior to that was part of the Collier Award winning X-35 STOVL Propulsion Lift System team. He has worked aviation control and diagnostic systems since the early 1980s, including commercial and military Digital Engine Controls, V-22 and C-17 Flight Control Systems, and rotary and fixed wing research and experimental vehicle control systems from X-Wing to the X-35. Ed has a BS in Mathematics from the University of Hartford.

Dr. Neal N. McCollom has been the PHM Integrator for the F-35 Autonomic Logistics Global Sustainment organization since shortly after contract award. His main task is to provide an interface between the ALGS development and the on-aircraft PHM development to ensure that the on-aircraft capabilities are properly integrated into the ALGS processes and products. Neal developed the criteria for the selection of prognostic items for ALGS based on specific criteria aimed at maximizing the benefit to the support of the F-35. He has many years of experience in software/systems development, knowledge-based systems, and manufacturing shop floor systems. Neal received his PhD in Industrial Engineering from Texas A&M University, a BS and MIE in Industrial Engineering and Management from Oklahoma State University, and is a registered Professional Engineer.

Erin E. Moore has first been with Lockheed Martin Missiles and Fire Control and is currently employed by Lockheed Martin Aeronautics. She works PHM in the F-35 Autonomic Logistics Global Sustainment organization. Erin was instrumental in developing the Autonomic Logistics PHM Data Architecture and the Air System PHM Concept of Operations. She also uses simulation to model prognostic items to determine their impact on an ALGS operation. Mrs. Moore received her BS in Mathematics from Dallas

Baptist University and her MS in Systems Engineering from Southern Methodist University. Andy Hess is a graduate of both the University of Virginia and the U. S. Navy Test Pilot School. Andy is world renowned for his work in fixed and rotary wing health monitoring and is recognized as the father of naval aviation propulsion diagnostics. Beginning with the A-7E engine health monitoring program of the early 70s, Andy has been a leading advocate for health monitoring in the Navy and has been instrumental in the development of every Navy aircraft application since the A-7E through the F/A-18 and V-22. His efforts have largely led to the successful transition of a development program (HIDS) into production (IMD HUMS) for all H-60, H-53, and AH-1 aircraft. More recently, Andy has been a strong advocate of prognostic capabilities and has been involved in many efforts advancing the development of these predictive capabilities for many aircraft systems and their subsystem component elements. To this end, Andy has been acting on the advisory Red Team for the ongoing DARPA Prognostic programs for Propulsion and Structures; and has been aggressively pursuing the advancement of electronics prognostic technologies. Recently, Andy has been hard at work leading and managing the development and integration the Prognostic and Health Management (PHM) system for the Joint Strike Fighter program and is a frequent participant in the international technical community. Andy is a NAVAIR Senior Engineering Fellow and has written many sundry papers on engine health monitoring, diagnostics, prognostics, and new logistic concepts.

Data Driven PHM

Documents

Transcript of Data Driven PHM