1 I
`
`I
`
`THE HONEYWELL ON-BOARD DIAGNOSTIC & MAINTENANCE SYSTEM FOR THE BOEING 777
`
`Gautham Ramohalli
`
`Aircraft Diagnostics & Monitoring Systems, Honeywell ATSD, Phoenix, AZ, U.S.A.
`
`Abstract
`
`Avionics have exhibited a phenomenal increase in
`complexity over the past twenty years. This increase in
`complexity has brought with it, the unfortunate side effect
`of a significant increase in difficulty of diagnosing the real
`reasons for a multitude of raw symptoms originating from
`these complex subsystems.
`The Integrated Avionics
`Architecture for the Boeing 777 is being designed with an
`unprecedented attention to fault detection and isolation
`capability to address this problem. A key element in this
`effort is an On-Board Diagnostic & Maintenance System
`(OMS) that integrates two diagnostic subsystems into the
`Airplane Information Management System (AIMS) cabinets:
`A Central Maintenance Function (CMF) and an Airplane
`Condition Monitoring Function (ACMF). The CMF diagnoses
`faults that were responsible for flight deck effects that are
`logged by the crew and facilitates rapid turn-around of the
`airplane at the gate. The ACMF captures parameters based
`on pre-<;tefin~d trigger conditions for long term analysis of
`trends m Aircraft Systems and the Flight Crew. The
`Honeywell OMS constitutes another major evolution of
`diagnostic systems directed at reducing the operating
`costs for the airlines.
`
`Introduction
`
`This paper will introduce the On-Board Maintenance System
`(OMS) that Honeywell is building for the Boeing 777
`airplane. Section I of this paper presents a background on
`the evolution of diagnostic systems into an CMF. Section II
`provides a similar background for the ACMF. Section Ill
`presents the OMS implementation in AIMS and the features
`of the Honeywell OMS. Section IV presents an overview of
`the 777 AIMS logistics that includes both line maintenance
`and shop maintenance.
`
`Sectjon I
`Background on the CMF
`
`The Problem on the Flight Line
`
`T_he primary purpose of a CMC is to assist in the analysis of
`flight deck effects and crew complaints from the arriving
`
`flight, diagnose the reasons behind these symptoms
`isolate it to ~he Line Replaceable Modules (LRMs), replac~
`th_en:' and ~nng the airplane back to its full operational state
`w1thm the t1me allocated between flights.
`
`The need for BITE
`
`As airplane systems and the flight deck have progressed
`from mechanical and electro-mechanical instruments to
`software intensive digital computers, a serious problem
`h~s su~aced .. It is no longer possible to perform simple,
`v1sual mspect1ons to determine the reasons for a faulty
`element. Faults are no longer due to stuck mechanics
`cracks, broken or missing linkages, etc. The maintenanc~
`crew is left to deal with a series of 'black boxes' full of
`micro-al~ctronics -- one. or mora of which is no longer
`parformmg properly. Without any information from test
`points in the complex maze of interconnected black boxes
`the_ir actions are red_uced to guesswork and shot-gu~
`mamtanance of raplacmg black boxes and hoping that the
`fault is eliminated.
`
`T~is has been r~sp_onsible for the no-fault-found problems
`w1th modern av1omcs -- on the commercial as well as the
`military side. The ROLM analysis 1 identified that 53% of
`t~a boxes removed from the airplane are later found to
`e1ther re-test OK or cannot duplicate the fault. A similar
`problem exists on the commercial side where over half of
`the boxes removed from the airplane are later found to be
`non-fa~lty. This has a
`large financial impact on airline
`operations due to the need for spares, flight delays, and
`repeated maintenance actions.
`
`BITE (Built-In Test Equipment) can be thought of as no
`more than the monitoring of these test points on a
`continuous basis by the various subsystems themselves
`rather than relying on external test equipment to provid~
`th_es_e
`f!1easureme_nts. An obvious advantage is the
`ehmma~1on of equipment removals to gain access to the
`test pom_ts .. BITE has an additional _significant advantage:
`the momtonng_ occ:urs at the same t1me as the flight deck
`~ffects, . resultm~ m a much better chance of providing
`mformat1?~ that IS. useful to diagnose the problem. Without
`BITE, eff1c1ent maintenance on modern airplanes would be
`an impossible task.
`
`485
`
`0-7803-0820-4/92 $3.00 D 1992 IEEE
`
`BOEING
`Ex. 1024
`
`

`

`Majotenance Ajds for Accessjnq BITE
`
`•
`
`cccac.
`88~~
`
`itimiE
`CFDIU
`
`•
`
`Ejqure 1 CFQS
`
`Majntenance Ajds for Qjaqnosjs
`
`CFQS CARING 604l
`
`The Honeywell Central Fault Display System (CFDS) on the
`McDonnell Douglas MD-11 aircraft is an implementation of
`the ARINC Specification 604 which provides a convenient
`access to Airplane BITE and enables the maintenance crew
`to execute ground tests in the various sub-systems.
`
`Symptoms from each of the LRUs are manually accessed,
`one at a time, by the cockpit mounted Control and Display
`Units (CDUs) (Figure 1 ).
`
`The Boeing 747-400 CMcs2 took another step forward in
`addressing the problem facing the maintenance crew by
`developing a centralized reasoning system that could
`consolidate the symptoms from multiple LRUs on the
`airplane and provide a diagnosis of the problem. It uses a
`Central Maintenance Computer (CMC) to process airplane
`BITE.
`
`The CMC is similar to a CFDS in that it serves as a common
`collecting point for all aircraft maintenance related
`information. However, the CMC automatically collects the
`symptoms from all of the LRUs. More importantly, it uses
`the information to formulate an airplane view and isolate the
`fault that explains all of the symptoms that are being
`generated on the airplane.
`
`As shown in Figure 2 the CMC collects fault reports from the
`FCS, EMS, Cabin and Autopilot LRUs. It then suppresses
`the secondary symptoms originating from the downstream
`LRUs and concentrates on the primary symptoms that are
`at the input of the LRUs. Finally, it consolidates these
`reports and determines that the power bus is the culprit that
`explains all of the sensors being inactive. A single
`message is presented to the maintenance crew that zeroes
`in on the real problem.
`
`Fjqure 2 Majotenanca interface wjth CMC
`
`Having a Central Maintenance Computer that generates the
`messages to the maintenance crew provides other benefits
`as well. It is a convenient way of suppressing nuisance
`messages generated by individual sub-systems that are
`unaware of airplane conditions that make these messages
`invalid. An additional capability provided by a central
`interpreter on the airplane is the correlation of flight deck
`effects to fault reports from LRUs that could explain them.
`
`Sectjon II
`Backqroyod on the ACME
`
`The Airplane Condition Monitoring System is different from
`the CMCS in that it concentrates on predicting events
`rather than as an aid at the gate in determining the reasons
`behind the event after it has occurred. An example use of
`the ACMS is to determine
`the number of times that a
`particular type of aircraft has exceeded its margins on
`approach to a specific airport. If the airline concludes, after
`detailed analysis, that this needs to be improved, a change
`in approach procedures for that airport would then be
`instituted.
`
`Eyolytjoo from early fljqht recorders
`
`The origin of the ACMS can be traced to Flight Recorders4.
`Starting with early photographic recorders from the 1950s
`used for test flights, the current day magnetic flight
`recorder capabilities have been gradually expanded to
`support research, accident analysis and cassette loaded
`quick-access systems. Airline programmability for the
`that are not mandated by the
`recording of parameters
`regulatory authorities is a more recent evolution.
`
`Typjcal Use of the ACME
`
`The ACMS is used as an aide to long term maintenance of
`aircraft systems. The health of the engine is monitored by
`analyzing engine trends. This is then used to schedule
`maintenance on the engines to prevent significant
`disruption in airline operations as a result of the
`
`486
`
`BOEING
`Ex. 1024
`
`

`

`unavailability of spares at remote locations away from the
`airline maintenance bases.
`
`The ACMS is also used for life extension of the engines if
`they are determined to be performing well within limits .
`Other uses include the monitoring of fuel consumption to
`support any warranty claims. The ACMS is also an excellent
`mechanism to track down elusive, intermittent problems
`that only occur under certain conditions.
`
`lotegratjon of CME and ACME
`
`ABINC624
`
`The ABINC 624 Report3 provides guidelines for an On(cid:173)
`Board-Maintenance System (OMS) for the next generation
`of Commercial Aircraft. The On-Board-Maintenance
`System (Figure. 3), includes both the Central Maintenance
`System as well as the Airplane Condition Monitoring System
`(ACMS). Some of the advances from the Boeing 747-400
`CMCS are: a new user-friendly graphical user interface
`using Maintenance Access Terminals (MATs) in place of
`CDUs; a new protocol for communication; expanded BITE in
`member systems; an On-Board Maintenance
`Documentation Function and integration of the Airplane
`Condition Monitoring Function.
`
`MAINTENANCE
`ACCESS
`TERMINAL
`
`PRINTER
`
`EVENT
`BUTION
`
`DATA
`UNKS
`
`PORTABLE
`DATA LOADER
`DATA RETRIEVER MATS
`
`{BEHIND
`AND TO
`THE SIDE
`OF PILOl)
`
`LIBRARY
`SYSTEM
`{OMD DATA)
`
`AC.M.S..
`SENSORS
`
`·ENGINES
`-APU
`• ENVIR
`·OTHERS
`
`D
`
`CClCCClCC
`CClCCClCC
`CClCCClCC
`1+---~ CClC CClC C
`CClCCClCC
`
`CENTRAL
`MAINTENANCE
`COMPUTER
`
`BITE
`
`SYSTEM
`B
`
`BITE
`
`SYSTEM
`c
`
`BITE MEMBER SYSTEMS
`
`LAN
`
`D
`
`CClCCClCC
`1+---~g§gg§gg
`CClCCClCC
`CClCCClCC
`
`D
`
`CClCCClCC
`----~CClCCClCC
`CClCCClCC
`CClCCClCC
`(AlP
`CClCCClCC
`MNTNCE
`AREAS:
`e.g.
`BRAKES)
`
`Ejqure 3 The ARINC 624 On-Board Majntenance Archijecture
`
`487
`
`BOEING
`Ex. 1024
`
`

`

`Sectjon Ill
`OMS implementation jn AIMS
`
`The Honevwel! OMS Implementation
`
`The OMS is implemented as two of the functions in AIMS
`as shown in Figure 4.
`
`Displays
`
`ACMS
`
`CMC
`
`FMC
`
`Fjqure 4 Honeywell OMS jn AIMS
`
`The Honeywell OMS is a model based implementation
`which uses an avionics model to diagnose the problem.
`This is different from using thousands of logic equations to
`anticipate
`the potential scenarios and determine a
`mapping of possible symptoms to faults.
`
`An engineering tool called SAIFR (System Aide for
`Integration and Fault Reporting) is utilized to capture
`individual subsystem models of Fault Response Behavior.
`SAIFR then analyzes these models and determines any
`inconsistencies or inadequacies in BITE coverage for
`correction. Once these are rectified, it then generates an
`airplane level diagnostic model that is used by the airborne
`CMF algorithm to map symptoms to faults.
`
`The model based approach (Figure 5) in combination with
`an integrated systems approach to maintenance provides
`significant advantages over existing systems.
`
`777SYSTEM
`INTERCONNECT
`
`INFORMATION -
`
`777 FMS MODEL
`
`n71RSMODEL
`
`777 DISPLAYS MODEL ~-rw==WlFl
`I
`11--tt
`777 FCS MODEL
`n---4-
`g--.1.
`L - SAIFR -I
`
`1n
`DIAGNOSTIC
`MODEL
`
`:-~
`
`REMOVE
`CASCADE
`EFFECTS
`
`FAULTS
`
`DECK
`EFFECTS
`
`Figure 5 Model Based Piagnostjcs
`
`488
`
`BOEING
`Ex. 1024
`
`

`

`Gajnjnq Majntenance Crew Credjbjlijy
`
`User Interface desjgned for the maintenance crew
`
`Getting the maintenance personnel to trust a CMF rather
`than replacing boxes is probably the biggest challenge and
`the most significant contribution that we can make in
`reducing the no fault found problem.
`
`The use of SAIFR allows us to determine the inadequacies
`before introduction to airline service and a specific step in
`the new technique suppresses nuisance messages that
`are responsible for loss of credibility.
`
`Staodardjzatjoo of BITE
`
`Lack of BITE standardization is a significant problem that
`produces inconsistent symptoms and results in erroneous
`diagnosis.
`
`We have put the mdchanisms in place that include
`infrastructure and organization as well as tools such as
`SAIFR that will enforce standardization of fault reporting
`and BITE in next generation Honeywell LRMs.
`In addition
`SAIFR is being provided to Boeing in order to extend this
`consistency across the airplane.
`
`1 00% trackjnq of Fljqht Peck effects
`
`We take advantage of the integration of the Displays
`function with the OMS in AIMS to ensure that every flight
`deck effect that is generated by the Displays Function has
`a oorresponding OMS Fault Message that is correlated with
`it.
`
`Separatjon of Hardware Fauns from Software Errors
`
`Software has taken on an increasing burden of the
`functional requirements in avionics. While the reliability of
`hardware has steadily increased resulting in very high
`MTBF (Mean Time Between Failure), the MTBUR (Mean
`Time Between Unconfirmed Removals) has not kept pace.
`A primary reason is the replacement of a good (hardware)
`box on the airplane with another good (hardware) box in the
`hopes that the problem will go away.
`In reality, software
`errors or design errors that did not anticipate flight
`conditions under which
`these symptoms exhibit
`themselves are the real cause of the problem. The
`software in the box that came off the airplane is identical to
`the one in the new box that went in, resulting in a recurring
`problem.
`
`AIMS has built-in features that isolates hardware faults
`from software errors. Unlike systems that have promised
`this capability in the past by adding monitoring to existing
`designs, a new self-checking concept is used that
`incorporates this capability as a fundamental element in
`the basic design.
`
`A new graphical user interface is being developed using X(cid:173)
`windows. This will eliminate the cryptic messages that are
`a result of the limited screen space and capability of CDUs.
`The maintenance crew is presented with plain English
`explanations of the diagnosis.
`
`ACMF lmplementatjon
`
`Airborne Component
`
`The airborne element of the ACMS monitors parameters
`that have been programmed using the Ground Based
`Software Tool (GBST). Upon the satisfaction of pre(cid:173)
`defined trigger conditions, parameters are collected,
`processed and stored in memory.
`
`As is shown in Figure 6, a large portion of the airborne
`software is generated by the GBST and uploaded for
`execution with the resident software in the unit.
`
`Ground Based Software Tool
`
`LOGIC UNITS, MAT LAYOUT.
`REPORT FORMATS
`
`AN11ne Tool b' crl98ton or ACMF applicatons
`
`Ejqure 6 ACMS
`
`Ground Based Software Tool IGBSTl
`
`The GBST is used to set up the trigger conditions for event
`recording, determine the action to be taken upon the
`trigger event and generate report formats. The tool then
`generates applications that are executed on the airplane.
`
`The ACMF on the 777 continues the evolution with a more
`powerful GBST and more
`features
`for airline
`programmability.
`
`Sectjon IV
`
`Majntenance Loqjstjcs for the 777 AIMS
`
`The intent of the Honeywell AIMS design is to isolate faults
`at the flight line to the proper module and minimize the need
`for test equipment and airline maintenance shops. The unit
`
`489
`
`BOEING
`Ex. 1024
`
`

`

`is then removed from the airplane at the flight line and sent
`to Honeywell support centers. Airlines are then offered two
`choices:
`
`1. An exchange of the defective module;
`2. Repair of the defective module.
`
`Retrieval of the information that has been captured in the
`module on the airplane and stored in the module's non(cid:173)
`volatile memory is a vital element in the overall strategy to
`minimize the no-fault-found (NFF) problems plaguing
`current generation avionics. This information will be
`consolidated in a Honeywell database and analyzed to
`implement continuous improvements to AIMS .
`
`The loss of such information that would result if the
`modules are disassembled in airline shops in an attempt to
`isolate the problems to an individual card or circuit
`element, is the primary reason behind Honeywell's policy
`on AIMS maintenance for the airlines.
`
`Another fundamental difference from current generation
`avionics logistics is that dedicated repair shops for level 3
`maintenance are no longer envisioned. Cards are sent
`back to a central location where they are repaired and get
`back into the spare pool.
`
`Two reasons are primarily responsible for this:
`
`1. The reliability of the modules are very high and this is
`expected to significantly reduce the frequency with which
`such repairs are needed.
`
`2. Equipment that is required to repair the cards is very
`expensive and it is no longer cost effective to gear up each
`support center to repair cards.
`
`AIMS features for shop maintenance
`
`faults with
`ARINC 624 provides guidelines for tagging
`additional information that could help in isolating the fault
`to the failed element.
`
`AIMS follows the guidelines of ARINC 624 and captures
`information on two types of faults: line relevant faults that
`need to be detected and reported to the CMF; shop
`relevant faults that need to be detected and logged within
`the LRU/LRM but can be consolidated into a single fault
`report and reported to the CMF as an internal fault.
`
`AIMS modules are currently being designed to tag internal
`shop relevant faults with:
`Flight Leg
`Flight Number
`Date
`Airplane ID
`LRU position (center, left, right)
`Software Part Number
`
`Selected Options
`Fault Code
`Hard or intermittent classification
`Temperature of the module
`Number of times fault occurred per flight leg
`Right Phase and UTC when fault first occurred
`
`This information should provide significant benefits in the
`shop in reducing the no-fault-found problems.
`
`Conclusjon
`
`The Honeywell model-based implementation of the next
`generation OMS for the Boeing 777 is an integrated
`systems approach to maintenance that considers all
`phases of the avionics life cycle. It is the result of a
`determined effort to understand the specific concerns of
`the airlines with present generation avionics maintenance
`and the comprehensive application of
`technologies to
`address each of them.
`
`Background on the Aythor
`
`Gautham Ramohalli is the Manager of the Aircraft
`Diagnostics & Monitoring Systems (ADMS) Department at
`the Air Transport Systems Division of Honeywell. He is
`currently leading the development of the On-Board
`Maintenance System for the Boeing 777 Airplane. He has
`an undergraduate degree in Systems Science
`from the
`University of California, San Diego and a graduate degree
`in Aeronautical Engineering from M.I.T. He can be reached
`by e-mail at gautham@oms01.cfsat.honeywell.com
`
`References
`
`1. ROLM Air Development : Study on Causes of
`Unnecessarv Removals TRS-83-2. 1983
`
`2. Matt Aslin and Lynn Cole: Central Maintenance
`Compyter System-"a bold step forward on the 747-400"
`AIAAIIEEE 8th Digital Avionics Systems Conference
`Proceedings. October 17-20, 1988. San Jose, California.
`
`3. ARINC Report 624: Published August 26th 1991.
`Aeronautical Radio, Inc. 2551 Riva Road, Annapolis,
`Maryland 21401
`
`4. British Airways ACMS Presentation to Honeywell Jim
`Prior
`and Mike Nebylowitsch
`June
`92.
`
`490
`
`BOEING
`Ex. 1024
`
`