INTELLLIGENT SYSTEMS ROADMAP
Topic Area: Integrated System Health Management (ISHM)
Fernando Figueroa, NASA Stennis Space Center, MS 30529, USA
Roles and Capabilities
Description of Capabilities
There are many definitions of ISHM. A definition from Wikipedia states that “Integrated
Vehicle Health Management (IVHM) or Integrated System Health Management (ISHM)
is the unified capability of systems to assess the current or future state of the member
system health and integrate that picture of system health within a framework of available
resources and operational demand.”
The implementation of an integrated system health management (ISHM) capability is
fundamentally linked to the management of data, information, and knowledge (DIaK)
with the purposeful objective of determining the health of all elements of a system.
Management implies storage, distribution, sharing, maintenance, processing, reasoning,
evolution, and presentation. ISHM is akin to having a team of experts who are all
individually and collectively observing and analyzing a complex system, and
communicating effectively with each other in order to arrive at an accurate and reliable
assessment of its health
ISHM is a topic that has been evolving for more than a decade, but it has become better
defined since around 2006. This is a topic that has also come to coalesce an international
body of individuals and organizations. Significant efforts to advance this topic were
supported by AFRL and NASA, beginning on around 2000. AFRL organized a yearly
ISHM Conference, approximately until 2011.
The following entities and activities have been consistently advancing the state of the art
in ISHM:


AIAA Intelligent Systems Technical Committee: ISHM has been a topic of the AIAA
Infotech@Aerospace annual conference for a number of years.
IEEE International Conference on Prognostics and Health Management is held
yearly. Organized by the IEEE Reliability Society. Sponsors for this event include:
1.
2.
3.
4.
5.
6.
7.
IEEE Reliability Society (financial sponsor)
IEEE Product Safety Engineering Society
IEEE Consumer Electronics Society
IEEE Aerospace and Electronic Systems Society
Eastern Washington University - College of Science, Health and Engineering
University of Cincinnati Center for Intelligent Maintenance Systems
CALCE - University of Maryland

The University of Cincinnati Center for Intelligent Maintenance Systems and CALCE
are well established entities that embody some aspects of ISHM.

The Prognostics and Health Management Society is an organization that holds a
yearly conference and also publishes an online journal. This organization embodies a
membership and following of international nature.

Cranfield University Integrated Vehicle Health Management (IVHM) Centre. Is an
entity that has also been at the forefront of advances in this area.
Roles and Example Applications
One of the best known implementations of health management is HUMS (Health and
Usage Monitoring System). HUMS systems were developed early by Goodrich, and now
a few other companies make them (Honeywell being one of them). The importance of
this system is that it established that health management systems were needed to operate
complex systems. However, it is focused mainly on helicopters; and most of the
interpretation, diagnostics, and analysis is done off-line (on the ground). The following
paragraph are excerpts from HUMS products offered by Honeywell, and reflect how
HUMS products support health management.
“HUMS & Vibration Monitoring HUMS products focus on the collection, processing and
interpretation of data generated by the various components or subsystems on the
helicopter, including engines, gearboxes and other dynamic components. Portable
Diagnostics Systems Portable diagnostic systems provides ground based diagnostic
systems for local maintainer use in processing and displaying maintenance data and
corrective actions. Software & Data Analysis Services Software and data analysis
services is software- and web-based systems designed to assist operators to manage
operational costs through planned maintenance events and avoid unanticipated
maintenance events.”
The HUMS systems are commercially available, but they do require still significant
human intervention, and off-line analysis.
Boeing implemented a basic capability for the Space Shuttle Main Engine (SSME). It
was a system based on a long history of engine testing, and monitored for trending
parameters at different stages of flight. The capability was flown and had the authority to
shut down an engine.
NASA has made multiple efforts to implement a credible ISHM capability. However,
these endeavors had two shortcomings: (1) they were not sufficiently well focused on
addressing development of key technologies and their validation, and (2) funds were too
limited. In the past 2 years, NASA has advanced consistently toward achieving a
demonstrator ISHM capability, using the Cryogenics Testbed Laboratory at Kennedy
Space Center as testbed. Achievements to date do provide a pilot implementation that is
credible, which also incorporates autonomous control enabled by ISHM.
In order to achieve credible ISHM capability, technologies in relevant areas must reach a
critical level, and must be integrated in a seamless manner. The integration must be done
according to models that provide the opportunity to analyze in terms of systems of
systems with many types of interactions. The technology areas for ISHM must cover the
following functional capabilities: (1) anomaly detection, (2) diagnostics, (3) prognostics,
(4) user interfaces for integrated awareness by the operator, (4) Software and hardware
architectures that enable integrated knowledge approaches to achieve ISHM, (6) software
environments to capture and make possible the use of knowledge across elements of a
system (7) standards to make integration of all prior technologies possible in a systematic
and affordable manner.
Technical Challenges and Technology Barriers
Technical Challenges
Technical challenges for ISHM have to be evaluated in the context that ISHM is an
intelligent evolutionary capability, because it embodies knowledge, and knowledge
continuously grows and evolves. Furthermore, software and hardware platforms must
make possible management of DIaK and enable inferencing and decision making
according to a wide range of models.
Software architectures for ISHM must be such that “intelligent” paradigms for
inferencing and decision-making must be realizable; where DIaK is compartmentalized in
a distributed manner. The software platform must enable creation of comprehensive
domain-models as knowledge-bases that support process models (physics models,
statistical models, etc.) and approaches to achieve ISHM at high levels of functional
capability. To date, there is perhaps one software platform that provides the tools
necessary. The following are requirements for a platform that supports ISHM
implementation:
Object orientation: object representation of system physical elements and associated process models is the
best way to embed DIaK in a systematic and in an organized manner. Object orientation also embodies reuse of software that is modularized into objects, and allows a more intuitive understanding of the code and
its outcomes.
Distribution of ISHM-DM’s within and across networks: ISHM-DM’s might be distributed among
processors connected to a network, simply because it is necessary to use parallel processing, and/or ISHMDM’s might be created by different people in various geographic locations. As complexity of systems
increase, and/or a large number of process models are used in achieving effective ISHM capability, it is not
reasonable or manageable to do this with a centralized architecture.
Distribution across processing units: Since multiple process models are expected to be running at any given
time, the software environments should support parallel processing.
Inference engine: Many tasks require an inference engine. Reasoning and decision making leading to
anomaly detection, diagnostics, effects, and prognostics; require contextual integrity and cause-effect
analysis using heterogeneous data and information. The inference engine must also allow accurate
representation and automatic execution of failure modes and effects analysis (FMEA).
Integrated management of distributed DIaK: DIaK must be managed in a way to allow embodiment of
systems thinking across elements and subsystems. Often this is enabled by definitions of relationships among
elements of systems that can be physically visible (i.e. attached to, belong to a system); or more abstracted
relationships, as it relates to involvement in process models (e.g. pressure sensors associated to a particular
subsystem, subsystem definitions that change with configuration, etc.).
Definition of dynamic relationships among objects for use in reasoning: Often, the framework for
reasoning and application of process models changes dynamically with configuration changes, stages of
operation, etc. This also means that relationships among objects and processes change dynamically, and must
be represented in the ISHM-DM’s. For example, reasoning to detect leaks in a sealed subsystem requires that
membership of elements to sealed subsystems must change with valve state changes.
Iconic representation of systems objects with visible and virtual links (relationships) used to provide
intuitive representation of reasoning and context: The mix of object orientation and iconic representation
of DIaK provides the ability to intuitively visualize interrelationships and dig deep into details of the ISHM
system. As complexity increases, graphical programming and visualization become essential.
Gateways for real time data streaming: To capture data from systems being monitored.
Real-time engine with a scheduler: This is the real-time operating system for ISHM functionality.
Hardware and software architectures must enable systems with distributed processing, to
share information in such a way that information is available to any element of the
system according to a context and at the right time.
User interfaces that enable integrated awareness by the user, about the health of any
element or process in a system. These user interfaces may be evolved from screens
currently in use by control and instrumentation systems. ISHM screens must be able to
effectively provide access to anomaly, diagnostics, prognostics, sub-system interactions,
models (including anomaly models), FMEA representation and execution, etc.
Standards: Some standards to support ISHM do exist (IEEE 1458 family of standards for
smart sensors and actuators, and OSA-CBM (Open Systems Architecture for ConditionBased Maintenance). Integrated standards to support ISHM are needed that can evolve
from these and other existing standards. Standards will make software tools and even
hardware plug-and-play and interoperable. Figure 1 shows how standards were
implemented in a pilot project by NASA.
Technology Barriers
There are two key technology barriers that are crucial: (1) adequate software
environments are scarce, but clear identification of needs/requirements and development
of standards and a handbook may push industry to invest in this activity; and (2) lack of
integrated standards focused on enabling systematic and affordable ISHM
implementation.
Policy and Regulation Barriers (if any)
(1) Operators are not able to understand or accept the benefits of ISHM capability, it
seems that the only effective way to overcome this barrier is to build pilot
implementations to have people experience the capability. NASA is currently doing this.
(2) Management demands an analysis of ROI, which is difficult to show on paper,
because benefits occur in a broad range of operational activities, and are often difficult to
quantify. But there have been studies of benefits from the HUMS products, and one could
project that ISHM benefits will be much larger than HUMS’.
Figure 1. ISHM Hardware Architecture Showing Use of Standards.
Impact to Aerospace Domains and IS Vision
The two technology barriers identified, if not overcome, will make very difficult
and/or very expensive implementation of ISHM as a capability for intelligent
systems and as an enabler for intelligence and autonomy. However, if leadership
and resources are allocated, these challenges can be met substantially in the short
term, within 5 years.
Research Needs to Overcome Technology Barriers
Research Gaps
Software platforms, architectures, standards, user interfaces, experimental
validation.
Operational Gaps
Educating operators for buy in.
Research Needs and Technical Approaches
Research to address the research gaps. Handbook/guidebook on ISHM systems
implementation.
Prioritization