Aircraft diagnosis is a highly complex topic. Many knowledge sources are required and have to be integrated into a diagnosis system. This paper describes the instantiation of a multi-agent system for case-based aircraft diagnosis based on the SEASALT architecture. This system will extend an existing rulebased diagnosis system, to make use of the experience on occurred faults and their solutions. We describe the agents within our diagnosis system and the knowledge modeling for the case-based reasoning systems. In addition we give an overview over the current implementation.
Technical domains can be very complex and the diagnosis of machines belonging to these domains is not easy. In most cases, dozens of relations between individual parts have to be considered and a high number of constraints can have an effect on the measurable symptoms and the diagnoses. An aircraft is one of the most complex machines built by humans and therefore the diagnosis and maintenance of aircraft is very resource consuming. Finding the root cause for an occurred fault may cost several hours, because it can be caused by a single part, the interaction between parts, or even the communication infrastructure between these parts. For example, if a monitor does not display the status of a system, the monsitor could be broken, one ore more parts of the system sending incorrect or no information, or the communication cable to the monitor may be broken. Therefore the use of experience from past faults can be very helpful to get a more precise diagnosis and reducing the time for finding and repairing the root cause. In this paper we describe an approach to use Case-Based Reasoning (CBR) within a decision support system to integrate experience knowledge into the existing diagnosis approach. The decision support system is a multi-agent system (MAS) that contains several CBR systems to provide experience knowledge. In the next section we give an overview of the OMAHA research project and the SEASALT architecture. Section 2 contains related work to our approach and Section 3 describes the multi-agent system for decision support in more detail. The last Section gives a summary and an outlook on ongoing and future work. 1.1
The decision support system is under development in the context of a research project
called OMAHA. The project tries to develop an Overall Management Architecture for
Health Analysis for civilian aircrafts. Several topics are addressed within the project
like diagnosis and prognosis of flight control systems, innovative maintenance
concepts, and effective methods of data processing and transmission. A special challenge
of the OMAHA project is to integrate not only the aircraft and its subsystems, but also
systems and processes in the ground segment like manufacturers, maintenance
facilities, and service partners into the maintenance process. Several enterprises and
academic and industrial research institutes take part in the OMAHA project: the aircraft
manufacturer Airbus, the system manufacturers Diehl Aerospace and Nord-Micro, the
aviation software solutions provider Linova and IT service provider Lufthansa
Industrial Solutions as well as the German Research Center for Artificial Intelligence and the
German Center for Aviation and Space. In addition, several universities are included as
subcontractors. The project started in 2014 and will last until the end of March, 2017.
[
The SEASALT (Shared Experience using an Agent-based System Architecture LayouT)
architecture is a domain-independent architecture for extracting, analyzing, sharing, and
providing experiences [
The aircraft domain is a very complex technical domain. An aircraft consists of hundreds of components (e.g, Communication and Ventilation Control), which consist of dozens of systems (e.g, Cabin Intercommunication System and Air Conditioning), that in turn contain dozens of individual parts (e.g, Flight Attendant Panel and Cabin Air Filter) called Line Replacement Units (LRU). These systems and LRUs are interacting with and rely on each other. Therefore, it is not easy to identify the root cause of an occurred fault, because it can either be found within a single LRU, within the interaction of several components of a system, within the interaction of LRUs of different systems, or even within the communication infrastructure of different LRUs. Finding cross-system root causes is a very difficult and resource expensive task. The existing diagnosis system onboard an aircraft can track root causes based on causal rules defined for the LRUs. These rules are not always unambiguous, because the diagnosis approach is effect-driven. Based on a comprehensible effect (visible, audible, or smellable) in the cockpit, the cabin, or the cargo bay, the diagnosis system tries to determine the system behavior that belongs to the effect and traces the root cause back through the defined rules. Based on the error messages and the identified root causes, so-called PFR items are created. This PFR items contains up to 50 error messages, that are associated with the same root cause. For each error messages up to three LRUs could be accused. This means, a PFR item could contain 150 different LRUs in the worst case. The mechanic at the aircraft has to check the LRUs until he finds the fault. The use of CBR for the diagnosis can help to clear ambiguous diagnosis situations with the help of experience knowledge from successfully solved problems, especially with cross-system root causes. At least CBR could help to ranked the LRUs based on experience. Therefore, we are developing a decision support system based on multiple software agents and CBR systems. The multi-agent system will not replace the existing rule-based system, but will extend the diagnosis approach to confirm or disagree with a diagnosis and the associated root cause.
In the next section we present some related work and compare it to our approach. In Section 3 we describe the problem and the use case of our case-based decision support system (Section 3.1), the instantiation of the multi-agent system based on the SEASALT architecture (Section 3.2), and the case structure and the similarity modeling of our CBR systems (Section 3.3). Finally we give a summary and an outlook on ongoing and future work of the decision support system. 2
Decision support for diagnosis (and maintenance) in the aircraft domain means that a
lot of engineering knowledge is available to support this process. In the past various
diagnostic approaches tried to improve diagnosis and maintenance in this domain: among
others CBR, rule-based reasoning, model-based reasoning, Bayesian belief networks,
Fuzzy inference, neural networks, fault trees, trend analysis, and a lot of combinations.
For OMAHA, that is OMAHA work package 230, the exploitation of available
experiences as supplementation to other already used knowledge sources is of high
priority. See also the work of Reuss et al.[
In addition to other specific characteristics of our approach one property
differentiating it from many other (CBR) approaches is the fact that we develop a multi-agent
system that applies a lot of CBR agents (among other ones). The following approaches
have in common that they also combine a multi-agent system approach with CBR.
Some researchers also dealing with CBR from different perspectives and trying to
combine the specific insights to an improved overall approach are [
In this section we describe our approach to use experience knowledge through CBR systems to enhance the diagnosis and maintenance of aircraft. The decision support system is based on the SEASALT architecture and we present the instantiation of the components in the context of our system. We also describe the problem that should be addressed by our approach and the application use case. In addition, we present the case structure and similarity measures of our CBR systems. 3.1
The current diagnosis approach of Airbus aircraft is effect-driven. A Central Maintenance System (CMS) tries to correlate failure messages from LRUs to effects like red blinking lamps or a displayed message by using causal rules and time data. For every failure message a fault item is generated. The CMS tries to correlate new failure messages and effects to open fault items. If they can not be correlated, a new failure item is created. For each failure item, a root cause is determined. But the rules can determine several different root causes for a given failure item. This way a fault item can have up to ten root causes and for every root cause up to three LRUs can be accused. In the worst case thirty possible cases have to be considered when repairing the fault. The maintenance technician uses his experience to filter the list of root causes and LRUs to identify the most probable starting point. Because not every technician has the same experience, the use of CBR to store and share experience and enhance the diagnosis with this experience could be a viable way to improve diagnosis and maintenance with a decision support system.
Several use cases of the decision support system were discussed in context of the OMAHA project: application in daily operations in the Operations Control Center for diagnosis during flight, application in the Maintenance Control Center to support unscheduled maintenance tasks, and application at Line Maintenance at the aircraft to support the maintenance technician directly. The second use case is identified as a viable use case for application of the system in the project context. The Customer Service of Airbus, as a part of the Maintenance Control Center (MCC), can use the decision support system to recommend maintenance actions based on successfully applied maintenance actions to similar problems in the past. The system will not replace the existing rule-based diagnosis, but will enhance it with experience knowledge to identify a root cause and the responsible LRU quicker and more precisely. 3.2
Our multi-agent decision support system is an instantiation of the SEASALT
architecture. We describe the software agents in the individual components and their tasks
within the decision support workflow. The central component of our system is the
knowledge provision, where the Knowledge Line is located. The Knowledge Line is
responsible for retrieving similar problems for a given fault situation and providing a
diagnosis and the performed maintenance actions. Therefore several software agents
are used to receive a query and retrieve a solution. A communication agent receives
the input from a user and sends it to the coordination agent. The coordination agent is
responsible for distributing the query to the relevant topic agents. Each topic agent has
access to a CBR system, performs a retrieval, and delivers the found cases to the
coordination agent. The knowledge is distributed among the CBR systems of the topic agents
and is discriminated between aircraft types (e.g, A320, A350, or A380) and aircraft
systems (cabin, ventilation control, hydraulic). Each system is identified by the so-called
ATA chapter, a number of four or six digits. This way, one CBR system contains cases
for A320 cabin faults, another CBR system contains cases for A380 ventilation control
faults. The approach of having individual agents for each aircraft type and ATA chapter
is based on the idea to split the knowledge among CBR systems to decrease the
modeling, retrieval, and maintenance effort for each CBR system. The coordination agent
decides which topic agents are required to find a solution for the query. This decision
is based on the aircraft type and the ATA chapter. Nevertheless, the cases in the other
case bases may contain useful information as well. Especially when the primary topic
agents cannot provide a sufficient solution. Therefore the query can be distributed to the
other topic agents as well, because faults and their maintenance recommendations may
be similar in different aircraft types. The last agent in the knowledge provision is the
so-called query analyzer agent. This agent is responsible for analyzing the query and
identifying new concepts, which are not part of the vocabulary of the CBR systems.
If any new concepts are found, a maintenance request is send to a Case Factory[
Based on our initial data analysis at the beginning of the OMAHA project, we decided
to use the structured CBR approach and present the knowledge as attribute-value pairs.
Much knowledge is stored in databases or CSV files and has a unique column-value
correlation. Therefore it can easily be transformed into attribute-value pairs. But during
the progress of the project, knowledge in form of free text became more and more
important, because these free texts contain many relevant experience. A pure textual CBR
approach is not viable, because the structured information is also important for a
diagnosis. Therefore an approach was required that considers the structured information
as well as the free texts. Because the knowledge from the cases in our CBR systems
should be stored in the data warehouse as well, we decided to stay at the structured
CBR approach and try to transform the information of the free text into a structured
representation. We modeled a case structure with 68 attributes and distributed them
among problem description, solution, quality information, and additional information.
The problem description of a case consists of 22 attributes like aircraft type, aircraft
model, ATA chapter, fault code, and engine type. Seven attributes are modeled for the
problem description extracted from free texts: system, function, status, location, time
amount, time unit, and complete description. We use the workflow for knowledge
transformation to analyze a free text and map the found information to the attributes.
Splitting the information over several attributes allows us to reduce the modeling effort for
each attribute, especially the similarity modeling based on taxonomies. All problem
attributes are symbolic attributes and are based on a list of allowed values. These values
are organized in taxonomies that are used to compute the similarity during retrieval. The
current knowledge model contains more than 30.000 different values among all
problem attributes. The solution consists of 10 attributes that contain maintenance actions,
documentation references, root causes, and comments. The quality information is stored
in two attributes that count the number of correct and false retrievals of a case based on
user feedback. The other 34 attributes are used to store additional information that may
be helpful for the operator in the MCC or for the maintenance technician. The current
implementation of the decision support system covers a prototypical multi-agent system
and a stand-alone version of the workflow. An interface was implemented to load the
results from the workflow into the decision support system. The stand-alone version is
used for extensive testing by our project partners and therefore not fully integrated into
the decision support system. The workflow itself is fully implemented, but the single
tasks should be improved. The multi-agent system contains eleven software agents and
seven CBR systems. The multi-agent system and the workflow are implemented with
JADE[
In this paper we describe the instantiation of our multi-agent system for case-based decision support on diagnosis and maintenance. We give an overview of the individual components and describe the case structure and similarity assessment of our CBR system. At the moment, we focus our work on the improvement of the workflow for knowledge transformation to get results with higher quality and thus improving the competence of our decision support system. In addition the workflow will be fully integrated into the decision support system. After the improvement of the workflow, a data set of more than 65.000 cases will be processed. Future work will be the implementation of the Case Factory approach for knowledge maintenance into the decision support system and extending the learning capabilities for similarity improvements. Furthermore we will extend our CBR tool myCBR to improve the usage in the OMAHA project.