Avionics Maintenance Ontology Building for Failure Diagnosis
Support
Luis Palacios
1,3
, Gaëlle Lortal
1
, Claire Laudy
1
, Christian Sannino
2
, Ludovic Simon
2
,
Giuseppe Fusco
3
, Yue Ma
3
and Chantal Reynaud
3
1
Thales Research & Technologies, Laboratory of Reasoning and Analysis in Complex Systems, Palaiseau, France
2
Thales Avionics, Toulouse, France
3
Laboratoire de Recherche en Informatique (LRI), Université Paris-Sud - CNRS, 91405 Orsay Cedex, France
Keywords: Ontology Building, Ontology Alignment, Evaluation Prototype, Aeronautics, Predictive Maintenance.
Abstract: In the aviation industry, the delay in maintaining or recovering aircrafts heavily impacts the profit of an
airline company. Consequently the maintenance actions identification and planning of aircrafts is crucial.
However, due to the complexity of the domain in terms of data sources, distributed systems and information
availability, it is hard to provide automatic maintenance support. We propose to use semantic technologies
to model the domain at a conceptual level through ontology, thus abstracting from the data sources and the
maintenancers’uses and jobs. In this manner the information relevant for characterizing failures and
maintenance events is encapsulated and provided to end users via an easier access, which otherwise would
be inaccessible or would require expert analysis to obtain. Such a formal model of the domain can
furthermore enable automated reasoning for maintenance discovery and failure causes detection by
integrating a large amount of background contextual information scattering in different resources. In this
paper we provide the rationale of the Avionics Maintenance ontology i.e. how we built it through expert
knowledge and alignment of different sources and an ontology alignment evaluation tool.
1 INTRODUCTION
In order to profit the most out of flights an airline
operates, both the airline companies as well as the
aircraft manufacturers must plan at best the use of
the planes. Aircraft maintenance is one of the most
important topics to deal with, when referring to keep
or to get back an aircraft able to fly as soon as
possible. Whilst planning and optimization are
topics already heavily handled by airlines, there is a
need to assist in the maintenance actions, i.e. the
forecast of a failure and the support to fault
diagnosis. Both forecasting a maintenance task and
isolating faulty components will reduce the time an
aircraft is unavailable, save money and resources. In
this paper we provide a model for characterizing and
explaining these events.
The aviation domain is a rich, complex and
technical one. As such, it involves a diversity of
locations, companies, services and actors with tight
interaction and interdependence. The diversity of
stakeholders and its distributed nature is reflected on
the systems that compose it. To automate and
support actions on the aeronautic domain requires a
shared and formal representation to model the
domain with its interactions. However, a bottom-up
data-based model is hardly possible due to the
heterogeneity and the recurrence of data
(redundancy of data and systems is compulsory in
aeronautics for security reasons). An approach to
solve this need is to provide a model at a conceptual
level (not only at the data level) and then feed this
model. Such a formalization of this complex domain
will enable automatic reasoning to support failure
forecasting and diagnosis support. Once the core
maintenance ontology is designed, we will use
ontology alignment techniques to enrich and validate
the contents of the model, thus providing more
complete and relevant answers to the final users.
We present first in this paper the aeronautics
maintenance field. Then, we present the design
rationale of the aeronautic maintenance ontology
from several sources (operators, documentation,
data, scenario) and supported by ontology alignment
tool. After an overview of existing works on the
field of avionics, ontology alignment and fusion and
204
Palacios, L., Lortal, G., Laudy, C., Sannino, C., Simon, L., Fusco, G., Ma, Y. and Reynaud, C.
Avionics Maintenance Ontology Building for Failure Diagnosis Support.
DOI: 10.5220/0006092002040209
In Proceedings of the 8th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2016) - Volume 2: KEOD, pages 204-209
ISBN: 978-989-758-203-5
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
ontology alignment, and guided by our
requirements, we present a first glance at the
ontology alignment tool supporting our approach.
Next, we present the needs of reasoning over the
model in order to discover and refine knowledge. A
set of scenarios are defined, focused on failure
diagnosis, on which the end users validate the
modelling.
2 AERONAUTICS
MAINTENANCE
Airlines define a flight plan, which describes the
usage of the aircrafts they operate. This plan has to
be coordinated with other operators for shared
resources and need to consider several factors as:
destination demand, number of available aircrafts,
state of the aircraft, maintenance, etc. The goal of
the flight plan is to ensure the most efficient
exploitation of the aircraft.
At the beginning/end of each flight, scheduled
maintenance takes place. This is composed by a set
of procedures defined in the Aircraft Maintenance
Manual (AMM), given for each aircraft type by the
manufacturer. External factors (like a delayed crew,
or weather conditions) as well as failures (a defect in
a component) may prevent the normal operation of
the aircraft. Moreover, a failure will always imply
unscheduled maintenance, although unscheduled
maintenance may not only be caused by a failure.
Our approach focuses on modelling the latter two
situations: explaining failures and unscheduled
maintenance, to assist the process of ensuring the
best possible exploitation for the aircraft. Such
explanations provide a way to answer questions like:
what are the possible causes (set of causes) of these
set of symptoms, what procedures can be applied to
a situation, what are the causes and effects of a
specific failure, or, which undesired situations are
not captured by any maintenance task. As the
causes, effects, symptoms and actions taken are
extensive, and because of complexity of the domain,
it is difficult to establish all the cause-effect relations
between the above mentioned elements.
3 LITERATURE SURVEY
3.1 Avionics & Ontologies
The avionics and avionics maintenance is largely
studied in industrial research field. It is a key
domain for civil as military industry. However,
publication of works in the field is quite private due
to the economic and safety impacts a published work
could create. However, in (Danping et al., 2012),
authors emphasize on the importance of
development of semantic information systems in
avionics. Other key industries in Europe are working
in the same line. They present an approach for
information extraction on the domain of aviation
products in order to handle the interoperability
issues.
In (Putten et al., 2008) a survey on ontologies
oriented toward Traffic Flow Management (TFM) in
aeronautics is presented, as they aim at providing a
Collaborative and multi-agent TFM system.
However, XCALIBR (Marshall and Morris, 2007)
and AIAA Topic Database (Neff et al., 2007) are of
interest for the aviation domain in general.
Unfortunately, these knowledge sources aim at new
development of component architecture and do not
handle the Maintenance part of the avionics works.
For safety and security reasons, avionics domain
mainly rely on international standards and norms. As
the maintenance field should comply with these
requirements, we can base our ontology building on
(ISO/TS 15926-8:2011, 2011) norm. This part is
providing a OWL implementation. Still it deals with
Industrial automation systems and integration, then
on any industrial maintenance, not in avionics.
Another document of the field, which is of
interest is the (NF EN 13306, 2001), giving the
maintenance terminology in three languages. Again,
it represents the maintenance field in any industrial
domain, including maintenance maagement
processes, but not especially with the terminology of
avionics maintenance.
Backed by these different sources, we have to
align these document contents to build an avionics
maintenance ontology fitting to failure forecast and
diagnosis support. For this task, we used expert
knowledge and an automatic alignment tool.
3.2 Ontology Alignment
The problem of establishing the correspondence
between the components of two or more ontologies
is known as the Ontology Alignment or Ontology
Matching problem (Euzenat and Shvaiko, 2007)..
Several techniques and tools have been developed
for solving it. The various techniques focus on
different specific aspects of the ontology. Following
(Otero-Cerdeira et al., 2015) they can be classified
into: lexicographic, structural, instance based and
reasoning based techniques. The techniques provide
Avionics Maintenance Ontology Building for Failure Diagnosis Support
205
correspondences between elements (concepts or
relations) of different ontologies, together with a
degree of confidence and the type of relation
between them. A set of such correspondences is
called an alignment. There can be many possible
resulting alignments and many incorrect
correspondences, depending on the techniques used
and the ontologies to be aligned.
To establish the most relevant techniques, their
weaknesses and their potential, we have developed a
first prototype for evaluating a set of alignment tools
with different characteristics and developed by
different teams. The goal of the prototype is to have
full control over the alignment process to determine
the causes that lead to a(n) (in)correct
correspondence, and then provide solutions or
improvements for the problems found. Several tools
enable (partially or fully-) automatic alignment
among which we consider the following: H-Match
(Castano et al., 2003), S-Match (Giunchiglia et
al.,2012), TaxoMap (Safar and Reynaud, 2009),
Logmap (Jiménez-Ruiz et al., 2012), (Faria et al.,
2013) for the complementary types of alignment
they provide (Otero-Cerdeira et al., 2015).
4 AVIONICS MAINTENANCE
ONTOLOGY BUILDING
4.1 General Approach
It is often the case in complex domains, such as
aviation, that the composing sub-systems are highly
specialized and that the interaction between them is
difficult. As a result, the relevant data differs for
each sub-system, depending on their goals and
needs. Some relevant information might not be
accessible, because it is not considered by the
current systems or the links to the sources of
information do not exist. For instance, a shop
repairing a component might focus only on repairing
the components, but not on establishing the
circumstances under which it has failed. Although a
view on both sides allows to determine the causes
and context of a failure. Additionally, the format,
form and representation of the information might
differ as well (text files, Excel files, XML, relational
databases, etc.) moreover this information might not
only be highly technical, but also the meaning may
differ according to the context, thus expert
knowledge is necessary to understand and evaluate
it. All these factors add to the difficulty of providing
a global view of the domain.
In order to support failure diagnosis, we need to
understand the failure mechanism. That involves
establishing the causes, context, effects and related
events that lead to the failure. To this end we
propose to model failure and maintenance in
avionics using an ontology to provide suggestions on
when and which items and events are related to a
failure. These suggestions, subject to a degree of
confidence, can then be presented to the user for
validation and expert knowledge acquisition. These
authoring process lead to knowledge discovery and
revision for failure diagnosis. Likewise, rare events
not considered by the maintenance procedures can
be isolated and characterized for further analysis,
providing support for weak signal detection. It is at
this point, when an ontology is already available,
that we can profit of ontology alignment techniques.
Given that there exist several other sources of
information (other ontologies related to the domain),
aligning them to the maintenance ontology provides
additional inferences, instances and axioms subject
to the same validation/authoring process by the end
user, thus extending the reach of the model beyond
the data sources initially identified, and providing an
additional mechanism for knowledge revision and
ontology design.
The maintenance ontology, along with the
alignment and revision processes is referred here as
the maintenance ontology framework.
4.2 Avionics Maintenance Ontology
After interviewing experts, analysing manuals,
procedures and documents relevant to the field
(norms among others), an ontology has been
designed to capture, at a conceptual level, the
information relevant to failures and maintenance.
That is, when they occur, why they occur and what
are their consequences. In addition contextual
information has been included into the model.
Once the ontology is designed, we also have to
deal with the process of specifying the sources of
data to populate the ontology. As mentioned before,
some of the information comes from reports made
by hand, others from XML files, manuals, etc. This
process involves several considerations: the content
of the sources of data is meant to be used by experts
on the field, the intended information might not be
found in one, but in several sources, and the
availability of the sources. Regarding the latter
point, this is due to the fact that the sources of data
are property of the airlines, the manufacturers and
the service/maintenance providers. Not only this
information might be subject to privacy policies
KEOD 2016 - 8th International Conference on Knowledge Engineering and Ontology Development
206
(intellectual property) but also might be subject to
security policies. When avionics is tightly related to
military, some of this information might not be
disclosed, and thus cannot be included in the model.
This represents an additional task and challenge for
the approach, but also exemplifies the utility of
providing a conceptual model for a domain to
conciliate different sources of data.
European Standards (ISO/TS 15926-8:2011,
2011) (NF EN 13306, 2001), are used as a upper-
leve ontology for building our ontology, since it
provides the industry with a terminology for
referring to the concepts used in maintenance in the
aviation domain among others. We also use specific
documents as the main sources of data for
populating the ontology, like the Post Flight Report
(PFR) the Flight Deck Effect (FDE) or the
Electronic Log Book (ELB).
The core of our model is a subset we call the
maintenance ontology, where two concepts are of
special interest: Resources and Services. A Resource
is a physical item that can be individually identified.
It can be, but is not restricted to, one of the
following: a hardware component, a shop-
replaceable unit, a line-replaceable unit, or a set of
resources. Whereas a Service is a function in the
aircraft (e.g. heating, satellite communications,
altitude measurement, etc.) that is provided by a
Resource. These elements can present Failures,
which are detected by the corresponding reports. A
ResourceFailure is detected by the
PostFlightReport, whereas a ServiceFailure is
detected by the FunctionReport (FDE). Finally,
because Services are provided by Resources, we
establish that a ServiceFailure can be a Symptom of
a ResourceFailure. These elements and its relations
are captured in the model in figure 1:
We also know the sources of the information for
the reports, which are given by some of the
MonitoringSystems of the Aircraft. The BITE (Built-
in Test) system performs tests in the components of
the aircraft and reports their status. The result of
these tests generates messages, known as
BiteMessages, which are associated to a
PostFlightReport for each Flight. Additionally, the
Aircraft Maintenance Manual (AMM) provides one
or more entries for each BiteMessage, where each
entry is a MaintenanceTask designed to isolate and
solve the failure. These maintenance tasks are not
only related to the BITE messages but also to other
events.
In the case of the Services, the FDE registers the
status of the services during the flight, and if the
interruption of any of them is detected. The absence
Figure 1: Core of the Avionics Maintenance Ontology.
or malfunction of a service can be as well reported
by the crew.
Similarly, for each flight an Electronic Log Book
(ELB) entry is generated that registers the status of
the aircraft, its flight departure and destination, its
identification information and
problems/observations and the actions taken, if any.
It differs from the PFR in that the cause-effect-
solution process is expressed in text (as a written
report) rather than related to a specific component,
with a specific failure message and a specific set of
tasks established for solving/isolating the failure.
Figure 2: Failure sub-part of the Avionics Maintenance
Ontology.
Finally, Maintenance takes place for each
Aircraft in each Flight. Depending on the conditions
this can be a ScheduledMaintenance or
UnscheduledMaintenance. By adding these concepts
to the ontology, we can associate causes, effects and
the situations that lead to UnscheduledMaintenance,
providing a better understanding of it (such as
explanations) and thus supporting the process of
diagnosis.
4.3 Ontology Alignment Tool
The creation of our own ontology for the
maintenance domain is not to replace all existing
Avionics Maintenance Ontology Building for Failure Diagnosis Support
207
ones or other pertinent ontological resources.
Instead, our ontology will be used via integration
with external ontologies, achieved via ontology
alignment techniques, in order to explore deeper and
more complete explanations for maintenance tasks.
To evaluate the alignment process and decide the
relevance, accuracy and usefulness of the different
techniques for our approach, we have developed a
prototype integrating the different tools in a single
alignment process. The process receives two
ontologies in OWL (McGuinness and Van
Harmelen, 2004) format as an input, allows to set the
parameters for each tool, and provides the output of
each tool in a unified XML format, along with the
log information, for further analysis.
Figure 3 shows the workflow of the prototype
and the activities of the user and the system. The
user provides the input ontologies and sets the tools
and respective parameters to be used in the
alignment process. A timeout might also be
established by the user, because an alignment
process could take a long time to be completed, due
to the size of ontologies. The system receives all
these resources and information to first prepare the
execution (loading matchers and set parameters) and
then execute the alignment process. Once the results
are available, they are stored and presented to the
user for validation.
In the validation process the user identifies the
incorrect/missing correspondences in the resulting
alignment and this information is provided as an
input for a subsequent iteration of the process to
refine the alignment.
The goal of the tool is to explain in detail the
generated alignments to discard or validate the
techniques used, backed up by the results. Given the
reasons why the considered techniques and tools do
not capture all desired answers, we can establish
improvements and algorithms to solve these issues,
and validate/discard them by iterating them in the
tool and running the same process.
The alignment tool consists of two components
allowing us to validate the alignment process,
executing them both in series and in parallel
Configuration component: provides operations
to initialize and maintain the correct
configuration of the entire tool;
Process alignment component: provides
operations to create manage and control the
entire alignment process between two
ontologies.
Since ontologies can be large, a tool could take a
long time for completing the alignment process. A
component allowing us to execute the alignment
process remotely was added to the prototype,
exploiting the REST architectural style. Then, it can
be easily replicated on different servers in order to
create a distributed system, therefore to solve, at
least in part, the problem about execution time.
T he alignment tool allows us to test and validate
manually the selected alignment tools. The need for
further extensions is considered in the design,
resources and architecture of the system, providing
an API to interact with the core of the tool.
Validation measures based on Taxonomy Overlap
(Cimiano et al., 2005), Coverage, Novelty, and
ExtraCoverage (Ponzetto and Strube, 2011) are
planned.
4.4 Scenarios
Our experts validated several avionics maintenance
scenarios, which are representative of a potential
ontology use to support diagnosis and forecast
failures.
Figure 3: Alignment Tool Workflow.
KEOD 2016 - 8th International Conference on Knowledge Engineering and Ontology Development
208
A scenario on scheduled maintenance in
hangar;
A scenario on deferred maintenance in line;
A scenario on unscheduled maintenance in line;
A scenario of in shop repair.
These cases picture the following concepts and
processes: un/planned, un/scheduled maintenance,
condition triggering maintenance (hard time, on
condition, soft-time, deferred correction, condition
monitoring), as well as the types of maintenance
occurring: On aircraft (line or hangar maintenance),
In Shop maintenance/repair (of SRU - Shop
Replaceable Unit), and lastly In Shop
maintenance/repair (of LRU Line Replaceable
Unit). These scenarios represent the main tasks and
processes of avionics maintenance.
5 CONCLUSIONS AND FURTHER
WORKS
The aeronautics domain is a large domain, in which
the maintenance is unfortunately considered as a
non-central topic. Then, we had to build our avionics
maintenance ontology and validate it. The building
is based on ontology reuse and then ontology
alignment as well as expert knowledge for
validation. Still we have to work automatic
validation of aligned concepts and automating the
ontology building based on ontology alignment.
The ontology is a basis for further reasoning
works to support maintenance users in diagnosis.
We plan to focus on providing the maintenance
analysts with two capabilities: the discovery of links
between causes and failures and the highlighting of
unexplained failures. In order to provide these
capabilities, we propose to use automatic pattern
matching. A graphical pattern describing the
observed failure is extracted from the populated
maintenance ontology, and completed with generic
graph structures expressing a generic link to a
generic cause. We propose to use a semantic graph
matching approach as in (Laudy, 2015) and relying
on the use of conceptual graphs (Sowa, 1984),
formalism and algorithms (Chein and Mugnier,
2008).
ACKNOWLEDGEMENTS
Part of this work is a PhD funded by the French-
ANRT.
REFERENCES
Castano, S., Ferrara, A., and Montanelli, S. (2003). H-
match: an algorithm for dynamically matching
ontologies in peer-based systems. In Proc.1
st
Int.Conf.
on Semantic Web and DB (pp. 218-237).
Chein, M. and Mugnier, M.-L. (2008). Graph-based
Knowledge Representation: Computational
Foundations of Conceptual Graphs. Springer.
Cimiano, P., Hotho, A., and Staab, S., 2005, Learning
concept hierarchies from text corpora using formal
concept analysis. J. Artif. Int. Res., 24(1):305339.
Danping Z, Youyuan W, Qi Z, Hongsheng J, Xianming D
(2012). The Design of the Aviation Products Semantic
Information System Based on Ontology. 2012 Int.
Workshop on Information and Electronics Engineering
Euzenat, J., and Shvaiko, P. (2007). Ontology matching
(Vol. 18). Heidelberg: Springer.
Faria, D., Pesquita, C., Santos, E., Cruz, I. F., and Couto,
F. M. (2013). Agreement maker light results for OAEI
2013. In Proceedings of the 8th Int. Conf.e on
Ontology Matching-Volume 1111 (pp. 101-108).
Giunchiglia, F., Autayeu, A., and Pane, J. (2012). S-
Match: an open source framework for matching
lightweight ontologies. Semantic Web, 3(3), 307-317.
ISO/TS 15926-8:2011 http://www.iso.org/
catalogue_detail.htm?csnumber=52456
Jiménez-Ruiz, E., Grau, B. C., Zhou, Y., and Horrocks, I.
(2012). Large-scale Interactive Ontology Matching:
Algorithms and Implementation. In ECAI (Vol. 242,
pp. 444-449)
Laudy, C. (2015). Hidden relationships discovery through
high-level information fusion. FUSION 2015: 916-923
Marshall, J. R., and Morris, A. T. (2007). Organization’s
Orderly Interest Exploration: Inception, Development
and Insights of AIAA’s Topics Database. 20pages.
McGuinness, D. L., and Van Harmelen, F. (2004). OWL
web ontology language overview. W3C
recommendation, 10(10), 2004.
Neff, J. M., Some, R., and Lyke, J. (2007). Lessons
Learned in Building a Spacecraft XML Taxonomy and
Ontology. 16 pages.
NF EN 13306, http://maint.t.i.b.free.fr/Files/Other/
NF%20EN%2013306.pdf
Otero-Cerdeira, L., Rodríguez-Martínez, F. J., and
Gómez-Rodríguez, A. (2015). Ontology matching: A
literature review. Expert Sys. App., 42(2), 949-971.
Ponzetto, S. and Strube, M.,. Taxonomy induction based
on a collaboratively built knowledge repository.
volume 9 of 175, pages 17371756. 2011.
Putten van BJ, Wolf SR, Dignum V (2008). An Ontology
for Traffic Flow Management. 26th Congress of
International Council of the Aeronautical Sciences
Safar, B., and Reynaud, C. (2009). Alignement
d'ontologies basé sur des ressources complémentaires :
TaxoMap. TSI, 28(10), 1211-1232.
Sowa, JF (1984) Conceptual Structures - Information
Processing in Mind and Machine. The Systems
Programming Series, Addison-Wesley
Avionics Maintenance Ontology Building for Failure Diagnosis Support
209