From: AAAI Technical Report SS-99-04. Compilation copyright © 1999, AAAI (www.aaai.org). All rights reserved.
The Integrated Diagnostic System (IDS): Remote Monitoring and Decision
Support for CommercialAircraft - Putting Theory into Practice
Michael Halasz, Franqois Dubr, Bob Orchard
Integrated Reasoning Group
National Research Council of Canada
Institute for Information Technology
M50Montreal Road
Ottawa, Ontario, Canada K1A0R6
[mike.halasz, francois.dube, bob.orchard]@iit.nre.ca
Robert Ferland
Program Leader, Decision Support Systems
Air Canada
PO Box 9000
Saint Laurent, Quebec, H4Y1 C2
rfefland@aircanada.ca
¯ Staff are progressively required to do morewith less with
continual pressure to maximizeequipmentutilization.
¯ Technicians deal with far more equipment diversity than
ever before.
¯ Accessto the right data, knowledgeand expertise at the
right time is necessary to effectively carry out the appropriate repair action.
¯ The increasing amountsof useful data provided by newer
generation equipmentrequire tools whichaid in integration andinterpretation.
¯ Unscheduled("surprise") maintenanceis persistent.
¯ Significant savings can be reaJ~ized through reduction in
no fault found and repeat snagz handling.
¯ Innovative information technology solutions earl improve
the bottomline. Conservativeestimates of savings for the
airline and mining industries are 2-4% and 5-8%of the
3.
total maintenancebudget, respectively
A high level indication of the 1996costs of maintenance
across 11 Canadianindustry sectors is shownin Figure 1. It
indicates that, in addition to every dollar spent on new
machinery, an additional 58 cents is spent on maintaining
existing equipment.This amountsto repair costs of approximately $15 billion per year. Comparingthis with 1990data,
the ratio of moneyspent on maintenancehas risen by about
14%.It is also worthnoting that for somesectors suchas railways and truck transport, maintenance exceeds the cost of
new machinery.
Abstract
TheIntegratedDiagnosticSystem(IDS)is an appliedartificial
intelligence(AI) projectthat deals withremotelymonitoring
fleet of commercial
aircraft and proactivelyalerting maintenancestaff to problemswhichcould disrupt operations. IDS
uses a numberof Al techniquesto analysesituations and provide recommendations.
IDSis very mucha workin progress
andthe researchhas beenadaptedto the needsof an airline operator. Dueto the ongoingworkingrelationship withAir Canada, the systemdeals withmanyairline integrationissues such
as networkcommunications,documentdelivery, technology
transfer, andequipment
dispatchregulations.Theobjectiveof
this paper is to share someof the insights gainedover the
courseof this projectandto highlightpracticalissuesof introducingadvancedinformationtechnologysystemsinto an airline’s environment.
Introduction
In 1992, researchers at the National Research Council of
Canada(NRC)initiated the Integrated Diagnostic System
(IDS) programand solicited the participation of industrial
partners. Thegoals of this effort were to developa platform
to research, develop, integrate, and test advanceddiagnostic
and decision support tools for the maintenanceof complex
equipment. The partners would use this knowledgeto enhance existing products, develop newproducts, improveoperations, and establish newresearch directions. It was felt
that the effort wouldhave benefits for maintenanceoperations in manyapplication areas including aerospace, power
generation, manufacturing,forestry, and transportation.
There were a numberof reasons for choosing the maintenance domainthat continue to be validI. For example:
¯ Improvedinterpretation of an organization’s diverse and
distributed information assets can help the maintenance
mission. Novel AI solutions could be developed and
tested in real life situations.
¯ There is a need for systems which help in time critical,
accurate, and consistent decision making.
IDS Requirements
To develop and test envisioned concepts, a good "laboratory" having the following key attributes was needed:
¯ availability of data,
¯ flee access to systems and personnel, and
¯ a complex,distributed operation with significant impact
of downtime.
2. Anobservedoperationalanomaly.Typicallyreferred to as a "squawk"in USA.
3. Basedon NRC
studies whichattempted~ quantify the economic
benefits of
assessingequipment
problemscorrectly.
1. Recentindustryreports corroboratethis position(e.g. [CanaanGroup1998]).
88
more significant than the diagnostic benefits although
perhapsmoredifficult to achieve technically.
In parallel with the requirementsstudies, an airline market
assessment indicated conservative savings of at least $1.5B
per year for the world’sairlines with morethan 40 aircraft in
their fleet (for improveddiagnostics alone).
Air Canada Operational
2000
Environment
Air Canadacurrently has a fleet of eight different aircraft
types from four airframe manufacturers(160 aircraft). This
is typical of a mediumsized commercialcarrier.
Figure 2 depicts the world within whicha systemsuch as
IDS should operate. Aircraft are continually on the move
around the globe and turn-times at the gate continue to be
shortened to maximizeutilization. This creates manychallenges. A numberof functional groups within the airline can
be involved in maintenance decisions depending upon the
problem. Theyare briefly described below:
¯ Line technicians repair aircrat~ at the gate or on overnight
layover. The prime objective is to safely turn aircraft
around with minimaldisruption.
¯ The MaintenanceControl Centre views the entire fleet
and thus obtain a broad perspective. Theydeal with problems reported by the pilot or on-boardsystems. Theyalso
monitorfleet status, identify trends, deal with persistent/
foreseeable problems, and decide maintenancepolicy.
¯ Engineering looks at specific performance indicators of
the equipmentand will only becomeinvolved with difficult immediate concerns, on an as-required basis. They
typically have the longest decision horizon.
¯ The manufacturersrepresentative can get involved in certain difficult problems.
¯ The personnel in parts stores must ensure that an adequate supply of spares exists from the various production
sources both within and external to the airline.
¯ The goal of System Operations Control is to keep the
entire fleet flying on schedule. They make system wide
decisions on factors such as, disruptions due to weatheror
equipmentfailure, and flight crew readiness.
Modernaircraft have on-board systems which can transmit data to ground stations.l These data consist of routine
performancesnapshots (engine parameters, pressures, altitude, valve positions, temperature...), typed pilot messages,
aircraft generatedfault codes, and limit exceedancereports.
Many databases support maintenance. They contain
descriptions of symptoms and associated maintenance
actions (free formtext), deferred problems,flight schedules
(static and dynamic), weather, componentreliability, check
schedules, and parts location. Thereis also a wealth of useful
information held at the manufacturer, and by people and
information systems in the engineering and maintenance
control departments. This is not widely distributed and thus
not available to the line technician in a timely manner.
Whenaircraft problemsoccur, technicians rely heavily on
professional judgement and knowledge. Additional support
4,000 6,000 8,000 10.000 12.0~0 14.000 16,(1(10
Slwyr
Figure1. repairvs. capital expenditures
(Source: Statistics Canada,1996)
Largecommercial
airlines fit the bill very nicely. In the fall
of 1993, Air Canadabecamea participant in the project and
a four monthrequirements analysis was carried out.
This study was a top-level requirementsanalysis. It concentrated on developinga broad understanding of the equipmentoperator’s maintenanceoperations and the role systems
such as IDS might play within the organization. Quantifying
the benefits from effective use of available data to improve
diagnostic performanceproved to be quite challenging. Nevertheless, a methodologywas developed which attempted to
measurea subset of direct benefits in order to showsufficient
promisefor the idea. Thus, there is justification in assuming
that the benefits of such systems, effectively deployed, are
muchlarger than indicated in the study.
The main highlights of the study were:
¯ IDS wouldcut across manydifferent departments in the
organizationthat did not typically interact.
¯ Anysolution had to deal with all equipmentsystems and
all fleet types. This perspective is at odds with most manufacturers since their goal has traditionally been to
becomesole source suppliers of equipment and associated support tools - a viewnot shared by their customers.
¯ Decision makingis highly distributed. Timelyaccess to
the right data, knowledge,and expertise is necessary to
effectively carry out the maintenance mission. Advice
from the system had to be presented in real-time to a
diversity of users.
¯ Newer generation equipment produces increasing
amountsof potentially useful data. These data are not
optimally utilized due to large volumesand difficult to
detect patterns. Innovative information technology was
requiredto aid in the integration of interpretation of data.
¯ Ideally, systems such as IDS, should have prognostic as
well as "repair management"
capabilities to be truly suecessful. Repair management
provides the ability to recommendthe appropriate course of action given the
broader context within which a problem occurs. Factors
such as, schedules, location, weather, and passenger traffic would be taken into account. A very simple example
wouldbe to automaticallyorder a part and deliver it to an
airport before the aircraft lands in order to avoid a major
disruption.
The addition of these two sets of functions is expected to
generate further tangible benefits which could be much
Aparticularlyinterestingaspectof Air Canada
is the datalinksystemwhichtransmrsaircraft generatedmessages
to a groundbaseddatabase.This permitted
development
of a systemthat wouldconstantlymonitorand interpret these data to
allowfor actionsto takeplacebeforethearrivalof the aircraftat its destination.
89
messages
~C"-~ r- opr=ingI - "p,lot
~d,ions
I
fault messages
~
/tkl/~
~-J~
~
-~.
~ ~
~
~
~
/~. ~/
r
¯ interrelation and potential usefulness of the different
information systems, and
¯ specific diagnostic rules of thumb.
All along it was evident that organizations such as Air
Canadaare in a constant state of flux, thus an evolutionary
protoyping methodology was followed [see, for example,
McConnell1996]. The process involved frequent feedback
from users and an evolving set of requirements.
~P
IIL~. - procedures
NIml~ln’trc"Jblesh°oting
~L.~Jm"~lW’ql-equlpmentlists
Functional Architecture
Figure 3 provides an overviewof the IDS architecture. Not
all of this exists since it incorporatesthe broadervision.
manufacturer
rep.
line technician
maintenance
control
centre
oo
A319
~
A32o ~
Figure2. Current
situation- airline
tools at their disposalare the:
¯ aircraft Built-In Test Equipment(BITE),
¯ MinimumEquipment List (MEL)- a document governing
minimum
equipmentneeds to dispatch aircraft safely,
¯ aircraft log bookwhich provides free form text descriptions of the problemsencountered,
¯ post flight reports (a summaryof the messagesgenerated
by the aircraft for a givenflight leg), and
¯ troubleshooting manuals (migrating to electronic media)
Thus, the decision environmentis characterized by distributed data, information, and knowledgesources. Making
timely and correct decisions is importantand requires access
to various combinationsof these sources.
~ CL~
performance
data
maintenance
histories(scheduled,
unscheduled,
flight
movement
partslocation
Approach
An overriding consideration in conceiving IDS was that it
had to address all aircraft types. Withfew exceptions (i.e.
where fleet economyof scale permits), this is the reality
whichmostline technicians face. A different systemfor each
aircraft type was not going to be accepted and wouldnot be
practical from a deploymentpoint of view. This initial assumptionset the stage and precluded AI techniques such as
in-depth model-basedreasoning or large knowledgebases of
specific rules for certain aircraft types.
The philosophy was very muchtop down.In other words,
a lot of time was spent with technicians analysing howthey
reasoned and exploiting inherent structures in the troubleshooting manualsto generate rule sets automatically. Thus,
as a first cut at the problem,this approachelicited methodologies pertaining to the investigative process and should
extend to other aircraft types.
Once the high level functionality of IDS was def’med,
important decisions were madeconcerning the development
environmentand associated tools. Concurrent with this was
an intensive knowledgeacquisition process. It’s objectives
were to obtain an in-depth understanding of:
¯ business processes associated with Air Canada’s aircraft
maintenanceorganization (Technical Operations),
¯ data (including database structures), information, and
knowledgesources,
B767
:
J
minimum
weather
manuals
~
sch~
a~ed
defects
updates
~
~
manufacturers
Figure3. IDSfunctionalarchitecture
IDSis data driven. The data driving it is stored in a multitude of dispersed databases of various vintages within Air
Canada. Pertinent data are "pushed" to IDS and written to a
database. These data coupled with the interpretive logic
within IDS then triggers certain maintenanceactions. Once
alerts are generatedby IDS, it continues its "investigation"
by requesting subsets of data to refine its recommendations.
In order to be truly effective IDSmustpossess a numberof
basic functionalities. First of all, it musthavereliable inter-
9O
andpresentthemto the user,
faces to various distributed databases and sources of electronic manuals.
Secondly,
it mustmaintain
its owninternal
data sources and case-bases for reasoning. In addition, it
incorporates AI techniquesto interpret text strings and rules,
learn patterns, reason about situations, and build and retrieve
cases. Finally, it mustaddress the delivery of informationto
a global and mobile workforce.
The ultimate vision for IDSincludes a:
¯ reactive componentwhich efficiently helps fred the root
cause of a problem that happenedwithout warning,
¯ proactive componentwhich deals with problems in which
somesort of "trend" or pattern is evolving, and
¯ situational componentwhichtakes into account the larger
context of a problemwhetherit be reactive or proactive.
recall related historical problemsfor the particular aircraft, and
determinethe logical entry point in the electronic manuals
and MELfor instructions on problemrelief.
TABLE
1. Sample flight leg data
Time
13:04:12
13:08:34
13:08:35
13:09:14
13:10:08
13:19:50
13:20:56
Basic Operating Principle
Every time a message is received, IDS determines,
whether or not the messagebelongs to an ongoing problem,
is the start of somethingnew, or can be ignored. The process
exploits manyknowledgesources, some allowing messages
to cluster, others allowingmessages(or clusters) to merge,
modified,or discarded. Theideal result is clear, concise, and
complete descriptions of fault events associating symptoms
and correct repair actions. Oncevalidated, these associations
are addedto a case databasefor future retrieval. Ultimately,
this can lead to automaticcase creation - seen as being highly
useful by airline personnel.
In addition, for a given symptomcluster, IDSdetermines
the impact on aircraft dispatch, and has built-in links to the
appropriate pages in the troubleshooting manuals and the
minimumequipment list (MEL).
A Simple Example
Currently, IDS uses two asynchronously generated data
sources. One is aircraft generated performance and fault
data. The other is snag~loggeddefect information entered by
technicians and flight crews.The latter is very similar to the
free form text entered at car dealers whendescribing problems and associated repairs.
Anexampleof a sequenceof events for a particular flight
is shownin Table 1. For illustration purposes, only the
essence of the messagesare given. At 13:04:12 the aircraft
takes off. Overthe course of the 2 hour flight 22 messages
were processed by IDS. All were generated by on-board systems except for two messages (13:22:41 and 14:47) which
were entered by the pilot and flight crew respectively. The
last messageoccurredafter the flight and wasentered into the
systemat 22:52. It describes the corrective action.
This example shows the snag was first picked up at
13:09:14. At this point IDSalerted groundcrews to a possible dispatch problemuponarrival. At 13:10:08 an associated
message was generated and added to form a symptomcluster. At 13:22:41the pilot confirmsthe situation and IDSadds
this messageto the previous two and assigns a higher alarm
level to the snag.
Whileall this is going on, IDSdoes three morethings. As
the case dynamicallyevolves, it will, whenrequested:
¯ retrieve closest neighbours (previously validated cases)
Phase
Takeoff
Cruise
Cruise
Cruise
Cruise
Cruise
Cruise
Event
NAV
WRN
FLR
WRN
FLR
WRN
FLR
13:22:28 Cruise
13:22:41 Cruise
FLR
SNG
13:41:01 Cruise
13:42:21 Cruise
13:48:02 Cruise
ECR
CPR
FLR
13:48:08
13:48:27
13:55:50
13:59:01
14:01:57
14:37:23
14:47
FLR
FLR
FLR
ECR
FLR
FLR
Snag
Cruise
Cruise
Cruise
Cruise
Cruise
Cruise
Cruise
15:00:34 Cruise
15:08:54 Cruise
15:12:31 At Gate
22:52
WRN
FLR
MPF
Snag
Description
ENG 20VSPD PROT FAULT
HMU(OSG), J7//EIU2FAD
ENG2 COMPRESSOR
VANE
VBVACT, HMUENG2A//EIU2FADEC
SFCS
FLPLH PROXSNSR1 37 CVORLGCIU1//
SFCC1
L FLP DISC PROXSNSR37CV//LGCIU1
ENG2 COMPVANEOCCURRED
AS PWR
ADVTO CLB PWRTHRU17000 FT.
ENGINECRUISE REPORT
CRUISE PERFORMANCE
REPORT
ILS-2 NO DATAFROMCONTROL
SOURCE//
ILS 2
AFS:FMGC2//AFS,RblPI,2OR3
AFS:ILS2//AFS
DME-I TRANSCEIVER//DME
1
ENGINECRUISE REPORT
DMC2:NOFQI2 DATA//EIS2,EIS 1,EIS 3
AFS:ADIRUI/2/3 DISAGREE//AFS
SEATCOVER
AT 3 F NEEDSTO BE
CHANGED
- COVERCHANGED
NAVALTI DISCREPANCY
CHECKVHF-I ANTENNA
CIRCUIT//VHF I
MAINTENANCE
POST FLIGHT REPORT
REPLACEDMASTERBALLSCREW
ACTUATOR
FLEX DRIVE&SPACER,ENG
RUNCARRIEDOUT, ACFTCHECKSSERV
Althougha simple example,it demonstratesthe utility of
such systems. Approximately2 hours before arrival, a significant snag is picked out from all the messagetraffic and
ground personnel are alerted. Parts can be ordered and a
repair can be adeptly carried out with minimaldisruption.
It should be noted that not all messagesproduced during
the flight can be associated with this particular snag. Some
might be generated by the aircraft spuriously or might indicate a newor ongoingsnag. Others, such as the reports generated at 13:41:01, 13:42:21, and 13:59:01 (italics)represent
routine tables of data recordedat certain flight phaseand stability conditions which go into the performancedatabase.
Future versions oflDSwill use these data for prognostics.
Current Situation
Four versions of IDS have been "released", each exhibiting
substantial changes.Since the objective of this paperis to describe the current situation, the fLrSt three are only briefly
outlined with further details foundin [Wylieet al. 1997].
Version0.1. This consisted of a set of interfaces (4 basic
screens). It was partially able to access data providedon tape
by Air Canada.Its mainobjectives were to conf’m’nthe pre-
91
liminaryuser interface design and to pull concrete ideas from
the "clouds"to help set the direction.
Version1.0. This was an off-line prototype which was able
to "playback" and reason with one year’s worth of data
stored in a database. This had the benefit of permitting high
volumesof data (at about 40 times real-time) to be pushed
through IDS for testing purposes.
This version dealt with a subset of aircraft systems(flight
controls and engines) due to unavailability of electronic
manuals. Evaluators at Air Canadacould nowget a better
feel of the system since it could replay conditions over a
selected time period.
Version2.11. This version has been in place at a numberof
sites in the airline since 1996.It interprets live data, is extended to the full aircraft (in this case the AirbusA320),has
full access to the on-line manuals(troubleshooting and minimumequipmentlist), and has a modestcase-base of historical problemresolutions.
After extendedevaluation of this prototypeat selected test
sites, Air Canadamadea decision to further develop and
deploy the system. In addition to supporting this, NRC
wishedto continue towards the larger IDSvision. This meant
dealing with the realities and goals of the two partners. Air
Canadahad to meet the needs of its users and deal with corporate realities such as communicationsinfrastructure,
budgets, manpower,and program standards.
Muchof the effort in producing the v2.11 prototype had
little to do with research. However,
it wasessential to place a
stable and useful system within Air Canada and provide
project credibility. During the next stage, NRChas committed to continued support of IDSv2.11 so that test sites can
remainoperative - includingdata redistribution via a server.
Towards IDS version 3.0
To set the stage for continuingresearch it was clear that the
monolithic systemthat was IDSv2.11 required a redesign. It
wasthe result of the project’s history, variouslimitations, and
changingrequirements. As detailed in Figure 4, each user of
the systemwasrequired to run the full IDSapplication, with
each user application receiving the real-time aircraft messages, performingthe identical reasoning and creating identical database records.
This obviously has a numberof shortcomings:
¯ it does not scale well to large numbersof users,
¯ one cannot easily add modified or new interfaces as differing user needs are determined, and
¯ it does not provide a flexible research infrastructure. New
functionality cannot be introduced without having a
major impact on the existing application.
Thenatural solution wasto distribute the various functions
and services into a numberof co-operating components.In
order to build such a distributed system, commercialmiddleware software was used. Various solutions were examined
for building such n-tier systems. These included Remote
Procedure Call (RPC) based systems, Message Oriented
Middleware (MOM)and Object Request Brokers (ORB).
Ultimately a message oriented middleware solution from
92
receivesand
distributes
datafromAir
Canada
systems
user1
user2
usern
Figure4. IDSversion2.11
Active Software, called ActiveWorks (see [Bracho and
Green] or [PC Week1998]) was chosen. It provides support
for asynchronousdelivery of typed messages(events) using
either a publish/subscribe or a request/reply mechanism.It
supports encryption of messagesand various levels of message persistence to assist with guaranteeddelivery. Messages
are delivered in order and only once. There are also a large
numberof adapters available to facilitate integration with
various languages (C, C++, Java, ActiveX, etc.) and commercial applications such as SAP,Varity, and PeopleSoft.
The central componentin an ActiveWorksdistributed system is a broker, through whichall events pass. There maybe
one or morebrokers used in any application. The brokers and
application componentsmaybe distributed on one, or many
machines.
Figure 5 shows a simplified view of the IDS v3.0 components connectedto a single broker (in practice several brokers on muldplemachinesare used). Briefly the function of
,osJ
controller
SRO
processor
Figure5. IDSversion3.0
each of the componentsofIDS v3.0 is as follows:
¯ MessageServer - receives data/messages from Air Canada systems in real-time; stores these messagesin text
files for archive purposes; maintainslist of connectedIDS
systems; delivers data/messages to connected IDS processes,
¯ Messageparser - receives data/messages from Message
server; parses messages forming ActiveWorks events;
discuss an alternate modelof service delivery which may
overcomesomeof these issues.
publishes these parsed events,
1 processor - subscribes to certain message pub¯ FEO
lished by MessageParser; publishes status of aircraft;
respondsto requests for status of aircraft; responds to
requests for FEOinformation;publishes FEOinformation
at end of flight leg,
¯ SRO2 processor - subscribes to published FEOs;
respondsto requests for case-base searches,
¯ Flight processor - subscribes to messages published by
MessageParser; maintains status of Air Canadaflights;
checks messagesfor accuracy with respect to aircraft and
flight information,
¯ IDScontroller - controls the startup and shutdownof the
various IDSprocesses; monitorsthe state of the IDSprocesses (alive/dead,statistics, etc.), and
¯ IDSclients (users) - the function of these clients will vary
depending on the view required of IDS information; may
request aircraft status, subscribeto aircraft status events,
request FEOdetails, request case-base searches, etc.
This architecture allows us to easily add new or experimentalcomponents
into the application with little or no disturbance of existing components (as long as the new
componentis subscribing to published messagesor requesting an existing service from one of the components). For
example,it is a simple matter to add a componentto monitor
the distribution of messagesand collect statistics or to add an
experimental client componentwith a newuser interface. In
order to satisfy the requirementto maintain support for the
IDS version 2.11 prototype, we modified the MessageServer
of version 2.11 to receive its raw messagesfrom the IDS3.0
MessageServer rather than directly from the Air Canadasystems. Thus, it just becomesanother application that is connected to the IDS3.0 server. This is shownin Figure 6.
Technology Transfer Challenges
The challenges associated with technologytransfer are considerable. One could well argue that they overshadowthe
technical issues. This section discusses practical issues
which must be considered whentaking such systems through
the implementationphase.
It turns out that there is neveran optimaltimeto initiate or
deploy such systems. Even whenprojects such as these are
economicallyjustified, one must overcomea numberof hurdles. The first is finding a strong internal championand, to
ensure that this role is properly transferred to their successors. These key individuals must embrace the vision and
drive it throughall the internal obstacles in order to build
awareness, secure funding, and assemble a project team.
Critical Success Factors. Whenone considers successful
deploymentof systems such as IDSthere are manyfactors to
consider (see Figure 7). Someof the morecritical questions
/.j//’~/
I research
[ issues
IT
infrastructure
J/
~ I AVO0
’,~
It~n~ogy
Figure7. Deployment
considerations
are:
¯
¯
usar2
*I
I systemhnks
I electronicmanual
availability
IDSv3.0
distributed
components
user1
""
@
¯
user n
Figure6. IDS2.11 withIDS3.0
¯
Conclusion
There are two mainissues worth discussing in the context of
putting the theory into practice. Thefirst is to highlight some
of the obstacles facing adoption of this type of technology
within a complexmaintenanceorganization. The secondis to
¯
¯
¯
Can the 1T infrastructure (LAN/WAN
TCP/IP) perform
adequately for "real time" data delivery and response at
user locations? Canit be used to effectively deliver multitier distributed applications?
Will an electronic manualsystem be available on-line at
commonworkstations for IDS to index and reference?
Howwill partially resolved research issues impact? For
example:
¯ an effective techniqueto automaticallygeneratecases (without human
intervention)to offset limited access to appropriate technicians,or
¯ unsupervised
learningtechniquesfor predictingfailures.
Are the required links to legacy systems (e.g. flight movement) available and feasible?
Is there an effective strategy to minimizechangesto business practices? (i.e. evolution not revolution)?
Has a process for data "cloaking" 3been determined?
Is IDSsufficiently reliable, scalable, and maintainable?
Does the core software development team have requisite
skills 4to deal with technologies newto the organization?
3. There is a requirement to temporarily "cloak" data on demandshould one of the
airplanes monitoredbe involved in an incident or accident. This requires compliance with Ministry Of Transport (MOT)regulations and Air CanadaQuality
Department
4. Note: in addition to the AI technologies, IDSalso assumesthe role of introducing
object oriented techniques.
cluster that IDSforms from the messagesthat
I. Fault Event Object: the symptom
are sent bythe aireratt.
2. Snag Rectification Object: an FEOwith the recommended
associated repair
appended
to it - a potential basis for a case.
93
¯ Can the project obtain active user participation? The
nature of the roles users play in the day to day operationis
largely event driven. Users must be freed up to contribute
to the project for uninterrupted periods - a very difficult
exercise. Typical requirements are: requirements def’mition, user documentation,training, and front line support.
allow seamless maintenancesupport between organizations.
Ongoing
and Future
Work
The project is once again evolving towards a longer term focus. Theprototype, along with its infrastructure and data resources provides an excellent platform to test newideas.
Manyimportant issues that require further work or remain
unsolved are:
¯ automate case creation and maintenance. Workis ongoing
to explore more refined ways in which to extract meanings from free form text;
¯ improve upon automated symptomclustering strategies
and indexing of the case-bases;
¯ determine if the diagnostic coverage of the case-based
reasoning paradigmis adequate whenapplied to the collective "experience" of Air Canadaor if another operator’s experienceshould be shared or if it is worthwhileto
explore deeper reasoning techniques;
¯ experiment with model-basedtrend analysis;
¯ provide robust repair managementadvice by extending
IDS to reason about other data sources and knowledge
such as: downline station capability, componentrepair
history/reliability, aircraft repair/maintenance history,
deferred problems, parts location, schedules, and flight
movement(including weather);
¯ extend to other Air Canadaaircraft, such as Airbus 319/
330/340, Canadair CL65, and Boeing 767;
¯ develop and test delivery modesfor a variety of end users
(e.g. Personal Communications Services (PCS), palm
computing, wearable, pen computingsolutions); and
¯ continue work on the Aerospace Data Miner (ADAM)
prototype, a domainspecific system that provides data
mining and monitoring capabilities. Recent results have
discovered very useful patterns from large amounts of
data (text and parametric) to predict componentfailures
and detect abnormalities. Field testing is in progress.
Alternate Service Model
Whenthis project was initially conceived, the focus was on
equipmentoperators. The general idea was for an organization to purchase software from a vendor and acquire upgrades and new functionality as they becameavailable. In
addition, the vendor or another companycould provide integration and customization.
This is still a valid option that dependsuponthe goals and
ambitions of the equipment operator. Equipmentmanufacturers, feeling the pressures of slim (at times nonexistent)
profit margins on sales, have usually relied on parts and
labour billing to recapture margins. Somecompaniesare
nowpursuing another service modelwhich assumes the burden of up-time guarantees - a form of maintenanceoutsourcing. Whereone drawsthe line is difficult to predict. At one
extreme, one could imagine an airline that doesn’t have its
owntechnicians or overhaul staff.
Our opinion is that there will be a spectrumof opportunities for service provision with airlines selecting a mix and
match of service options which makesense for them.
Thuswe believe that there is no right answerfor howsuch
systemsshould be deployedand delivered but it is worthconsidering another modelbeing pursued. Figure 8 showsthree
roles:
¯ Air Canadacontinues as lead user - helps set directions,
providestest sites, reaps benefits, and purchasesservice.
¯ NRCprovides R&Dto mitigate technical risk and help
produce commercialsoftware based on the IDS platform.
¯ The service provision role would be covered by a software developer and system integrator (which could be the
same company):
¯ The developer takes R&Dprototypes and packages them
into a productsuite (could operateremotelyfromthe operator) and developsthe market.
¯ Thesystemintegrator provides7/24 support, maintainsdata
integrity froma varietyof airlines, retrievesdata fromappropriate databases,anddistributes information
backto users.
References
1. Bracho, R.; Green, J.; Understandingthe Integration
Iceberg, http://www.activesw.comfhome.htm.
2. CanaanGroup Limited, Aviation Maintenancein the
Information Age: Cutting Line MaintenanceCosts with
Information Technology, Spring 1998, An Aviation
Industry Commentary.
3. McConnell, S.; Rapid Development: TamingW~ld Software Schedules, 1996, Microsoft Press.
4. PC Week,ActiveWorks 3.0 hides the plumbingof app
integration, letting administrators do their jobs. New
York, 1998, v.15, n.51, p.37, 3p. ISSN0740-1604.
5. Statistics Canada, 1996. Private and Public Investment
in Canada,Investment and Capital Stock Division,
Revised Intentions, catalogue 61-206 Annual.
6. Wylie, R.; Orchard, B.; Halasz, M.; Dubt, F.; IDS:
Improving Aircraft Fleet Maintenance,Innovative
Applicationsof Artificial Intelligence, IAAI-97,July
27-31, 1997, Providence, RhodeIsland.
Figure8. Possibleservice model
Animportant concept is a shared service subscriber casebase which will greatly improve diagnostic coverage. This
avenue is under consideration by Star AllianceI membersto
Consists of: Air Canada, Air NewZealand, All NipponAirways, Ansett Australia, Lutthansa GermanAirlines, SAS- Scandinavian Airlines System, Thai
AirwaysInternational, United Airlines, and VARIG
Brazilian Airlines.
94