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
edward.r.brown@baesystems.com

Dr. Neal N. McCollom

Lockheed Martin Aeronautics Company
PO Box 748
Fort Worth, TX 76101
817-935-3722
neal.n.mccollom@lmco.com

Mrs. Erin-Elaine Moore

Lockheed Martin Aeronautics Company
PO Box 748
Fort Worth, TX 76101
817-935-4317
erin.e.moore@lmco.com

Mr. Andy Hess

Joint Strike Fighter Program Office
200 12th Street South
Arlington, VA 22202-4304
703-601-5551
andrew.hess@jsf.mil

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

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 TakeOff 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).

Index TermsAircraft reliability, aircraft maintenance,

prognostics
TABLE OF CONTENTS
I.
II.
III.
IV.
V.
VI.

INTRODUCTION .......................................................... 1
PHM INTERFACE ARCHITECTURE ........................... 4
AIR SYSTEM SCENARIO ............................................. 4
CONCLUSION............................................................ 10
REFERENCES ............................................................ 11
AUTHOR BIOGRAPHIES ........................................... 12

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

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

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).

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:

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

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

capabilities of this advanced vehicle. It also set the

groundwork for the successive deployment and expansion
of equally advanced integrated supporting systems, both onand off-aircraft.

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

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 onboard and off-board capabilities to support better-thanlegacy 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 offboard 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.

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 onaircraft data management and models exist within Area
Managers, which concentrate functionality by subsystem
or by natural integration groupings of subsystems.

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:

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.

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,

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.

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

Collectively, these PHM elements allow for efficient and

cost effective maintenance of aircraft faults, support rapid

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 Vehicle
On-Board Health Assessment
Fault
Accommodation
Status via
Integrated
Caution,
Advisory, and
Warning System

PHM Area
Managers

Flight Critical

Air Vehicle/Support System

Interface
Displays and Controls

Crash Data
Recorder

AV-Level Info Mgmt.

Cross Correlation
Intelligent FD/FI
FA Mitigation
Auto. Logistics
Enabling/Interface

Mission Critical
Portable Memory Device
(PMD)
PHM Data

AMD/PMD

In-Flight
Maint.
Downlink

Airframe

Mission
Systems

AV PHM
Area Manager

ALIS

Vehicle
Systems

Methods Used:
Propulsion

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

Results In:
Decision Support
Maintenance Planning
Condition-Based Maint.
Affordable Logistics

Provides:

ALGS &
Off-Board PHM

Maintenance
Vehicle
Interface

Portable Maintenance Aid

(PMA)

Automated Pilot/
Maintenance Debrief
Off-Board Troubleshooting
Off-Board Prognostics
Trending
Life Mgmt
Fleet Mgmt
Knowledge Discovery
Store/Distribute
PHM Information

Health/Service Info
Joint Technical Data,
Consumables, Stores
Off-Board Diagnostics (AFRS)

Database

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

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 offboard 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.

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 onboard sensors) to ALIS.

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 offboard systems and tools. The following describes an onboard scenario where data is generated for analysis while
the plane is airborne. This data is then transmitted to the
4

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.

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.

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

Item 10

Engine

Precooler HX
Item 202

FDHX

S/G

P
M
G

Item 120

Fuel
Fuel
HX

OBIGGS

PAO to Air
HX

Combustor

Item 13

Recuperator
Load
HX

OBOGS

Equip

CT

S/G

PT

Item 11

FWD
Equip

Item 107
Item 48

EHA
Controllers

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.

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 onboard systems. The AV PHM Area Manager software
notices that the HRCs have been instantiated and routes
those signals to the appropriate locations.

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 devicespecific persistence.

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

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

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 predetermined 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).

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.

Event data - This is the parametric or performance data

surrounding an HRC time stamp. It can be any preselected 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.

B. PHM Data in Autonomic Logistics

After PHM data is downloaded from the PMD, the offboard 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.

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)).

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
6

availability is maximized and opportunistic maintenance can

be scheduled for cost or for resource availability reasons.

AV: PMD

Data Extraction

AV: Data
Link
HRC Store

AV Data:
Manage & Distribute
AV Health Data

AV Health:
AMC Algorithms

AV Health
Filters
Duplicates

AV Health:
Force Life
Management

ALIS Maintenance
Management

AFRS
AV Health
Compiles AV
Composite Health

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:

CMMS

AV Health
Builds
WO file

AV Health
Extracts

MVI

PMA

Failure Reporting,
Analysis, Corrective Action
System

Maintenance
History

Comprehensive Off-Board Functions Complement AV Capabilities

Fig. 5: Off-board Processing Flow

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:

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.

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.

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

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

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:

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.

Fuel Consumption per squadron

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.

Fuel Consumption per fleet

Key benefits of AFRS include:

Fuel Consumption per flight

Fuel Consumption per mission type
Fuel Consumption per sub-system
Fuel Consumption per pilot
Fuel Consumption per tail number

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

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

The first is as a result of the AV generating an HRC, the

second is scheduled maintenance activity.

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.

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.

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:

Failure Resolution

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.

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.

Fig. 7: AFRS Interactive PMA Screen

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.

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.

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.

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 offboard 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

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
10

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

improvement for the essential affordability goals of this

large, complex, and critical technology development
program.

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 onboard 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.

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.

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

[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.

11

Baptist University and her MS in Systems Engineering from

Southern Methodist University.

VI. AUTHOR BIOGRAPHIES

Edward R. Brown is Senior Manager for F35 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 XWing to the X-35. Ed has a BS in Mathematics from the
University of Hartford.

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.

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 onaircraft 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

12