1、RESOLUTION OF INSERVICE ANOMALIESTHROUGH ASAPPARINC REPORT 640PUBLISHED: SEPTEMBER 30, 1997AN DOCUMENTPrepared byAIRLINES ELECTRONIC ENGINEERING COMMITTEEPublished byAERONAUTICAL RADIO, INC.2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401This document is based on material submitted by variousparticipants d
2、uring the drafting process. Neither AEEC norARINC has made any determination whether these materialscould be subject to valid claims of patent, copyright or otherproprietary rights by third parties, and no representation orwarranty, express or implied, is made in this regard. Any use ofor reliance o
3、n this document shall constitute an acceptancethereof “as is“ and be subject to this disclaimer.Copyright 1997 byAERONAUTICAL RADIO, INC.2551 Riva RoadAnnapolis, Maryland 24101-7465ARINC REPORT 640 RESOLUTION OF INSERVICE ANOMALIES THROUGH ASAPPPublished: September 30, 1997Prepared by the Airlines E
4、lectronic Engineering CommitteeCharacteristic 640 Adopted by the Airlines Electronic Engineering Committee: August 12, 1997Characteristic 640 Adopted by the Industry: September 30, 1997TABLE OF CONTENTSITEM SUBJECT PAGEiii1.0 INTRODUCTION 11.1 Purpose 11.2 Objective 12.0 DEFINITIONS 23.0 APPROACH AN
5、D RATIONALE 33.1 Process to Detect an Anomaly 33.1.1 Anomalous Behavior Addressed 33.1.2 Detection Mechanism 33.2 Process to Collect Data and Anomalies 33.3 Proc ess to Isolate an Anomaly 33.4 Process to Resolve the Anomaly 44.0 AIRLINES INPUTS TO PROBLEM 54.1 General 54.2 Description of Problem 54.
6、2.1 Airline Data Support Requirements 54.3 Impact on Airline 54.3.1 Airline Priority 55.0 AIRFRAME MANUFACTURERS REQUIREMENTSFOR A SOLUTION 65.1 Participation 65.1.1 Data Analysis 65.1.2 Problem Selection 65.2 Data 65.3 Testing 65.4 Problem Correction 65.5 Interim Procedures 66.0 AIRCRAFT SYSTEMS MA
7、NUFACTURERSREQUIREMENTS FOR A SOLUTION 76.1 Participation 76.2 Data 76.3 Testing 76.4 Problem Correction 76.5 Interim Procedures 77.0 PROCESS TO DETECT AND CORRECT ANOMALIES 87.1 Purpose 87.2 Process Overview 87.3 Anomaly Detection Process 87.3.1 Central Data Base 87.3.1.1 Reporting Format 87.3.1.2
8、Airline Data Reporting Frequency 97.3.1.3 Airline Units Being Reported 97.3.1.4 Establishing Industry NFF Rate 97.3.1.5 Determining a Reported Systems NFF Rate 97.3.2 Reporting Potential Anomalies 97.4 Defining an Anomaly 107.4.1 Airline Internal Review 107.4.1.1 Gathering of Additional Data 107.4.2
9、 Assembling the RT 107.4.2.1 Team Members 107.4.3 Define an Action Plan 107.4.4 Execute the Action Plan 117.4.5 Distribute Results of Tests 117.4.6 Refine the Hypothesis 117.5 Anomaly Correction Phase 117.5.1 Team Makeup 117.5.2 Test Development 117.5.3 Failure Isolation 117.5.4 Anomaly Work-Around
10、127.5.5 Correction Process 127.5.6 Testing and Recertification 12TABLE OF CONTENTSITEM SUBJECT PAGEiv7.5.7 Correction Accomplishment and Final Actions 127.6 Confirmation of NFF Resolution 128.0 COST JUSTIFICATION FOR SOLUTION 138.1 Purpose 138.2 NFF Anomaly Cost Evaluation 138.2.1 Resource Requireme
11、nts8.2.2 CDA Administration and Management 138.3 Correction Process Cost Evaluation and Justification 138.3.1 Cost of Resolution1 13ARINC REPORT 640 - Page 11.0 INTRODUCTION1.1 PurposeThe purpose of this document is to define a generalizedprocess by which anomalies in aircraft systems can bedetected
12、 and to effect a timely isolation and resolution ofthose anomalies.1.2 ObjectiveThe objective of this document is to reduce the costs tothe airlines, airframe manufacturers, and aircraft systemssuppliers by removing anomalous behavior from aircraftsystems in a timely manner.ARINC REPORT 640 - Page 2
13、2.0 DEFINITIONSThe following terms will be used in this document:Aircraft System The sum of all devices andinterconnects which produce auseful function on an aircraft.Anomaly An unexpected andundesirable behavioroccurring during operation ofan aircraft system.Correction Phase The process used to def
14、ine ananomaly in an LRU and toproduce a modification of theunit to eliminate the anomaly.Definition Phase The process used to gatherinformation that will allowisolation of a detected aircraftsystem anomaly to one ormore LRUs.Detection Phase The process used to gatherinformation that will allow adete
15、rmination that ananomaly exists in an aircraftsystem.Process The methodology used tostructure an approach toachieve a solution to aproblem. The execution ofeach step will bring a highlevel of assurance that thesolution is optimum and doesresolve the problem.Responsible Entity The single organization
16、(airline, airframe or aircraftsystems company) who hasresponsibility for execution ofone or more steps in a process.Team A group of technical expertscomposed of personnel fromone or more airlines, anairframe manufacturer andone or more avionicssuppliers.Team Leader The individual (usually arepresent
17、ative of theresponsible entity) who directsand reports the results of oneor more steps in a process.ARINC REPORT 640 - Page 33.0 APPROACH AND RATIONALEThe approach this document takes to reducing the timerequired by industry to detect, isolate and resolveanomalous operation in aircraft systems is ba
18、sed on acooperative effort between the three partners, the airline,the airframe manufacturer and the avionics supplier.Each will work both independently and interactively tomaximize the effectiveness of each phase of the process.COMMENTARYThe process described herein is based on a conceptfirst propo
19、sed by Japan Air Lines. The process theyproposed is called Avionics Software AirlinePositive Participation (ASAPP). The basic premiseof ASAPP is that if the three parts of the industrywork together in a proactive rather than reactiveway to find and eliminate software anomalies, theproblem will be co
20、rrected faster and with less totalexpenditure of resources.One of the basic concepts of the original ASAPPproposal was the formation of teams at introductionof new or upgraded systems and the exchange ofdocumentation to allow each member of the team tobe trained and ready to isolate and correct a so
21、ftwareproblem as it is discovered.3.1 Process to Detect an AnomalyAfter an aircraft has been put into service by airlines, itis not unusual for flight scenarios that were not fullydescribed during design of the system to be encountered.When this occurs, the system may react in an unexpectedway. This
22、 action/reaction cycle is sometimes encounteredonly infrequently during the flight cycles of the systemand can be very difficult to identify in a cause/effectrelationship. The detection process defined here isintended to assist in detection and reporting of suchanomalous behavior in a timely manner
23、so as to allowthe isolation and resolution of the problem more rapidlyand with less impact on the user.3.1.1 Anomalous Behavior AddressedSome unexpected systems behaviors are obvious andrepeatable under real flight conditions. Although thesebehaviors can be classified as anomalies, their detectionan
24、d isolation are self evident. In those situations, theprocess of detection and isolation defined here may notapply. In fact, a resolution process already exists withinthe working relationship of the industry for this class ofproblem. This procedure is designed primarily tooptimize the detection of t
25、he more subtle case, one whichcauses continued no fault found (NFF) removals withoutresolution. The procedures defined here, however, maybe used to advantage for consistency in handling allanomalous behavior of aircraft systems.3.1.2 Detection MechanismThe first step in this process is the reporting
26、 by airlinesof unit removals to a central database agency (CDA).The next step in the process is for the team to collect thedata. Then the CDA will report the NFF systems thatexceed the trigger level. The trigger criteria aredescribed in Section 7.Data that will be needed for successful analysis will
27、include the unit part number, unit serial number, unithardware/software modification status, aircraft type, unitremoval date, and airline identification. More detailedparameters will be necessary to definitively address theNFF issues.Once a potential high NFF is detected, the CDA willinform the affe
28、cted airline(s) so that the airline(s) maybring together a resolution team (RT) consisting ofairlines, aircraft engineers and aircraft system supplierrepresentatives to confirm the anomaly and to plan acourse of action to validate and document the failuremode of the anomaly.3.2 Process to Collect Da
29、ta on AnomaliesOnce a high NFF has been detected, the next processshould be to collect sufficient data to allow the failuremode to be isolated and demonstrated in a repeatablemanner. This process will need the collective experienceof all three parts of the industry to assemble a plan ofaction, execu
30、te the plan and document the results.COMMENTARYAt this point in the process it is unlikely that thecause of the high NFF will be clear. One of the goalsof this phase is to document the failure mode insufficient detail to allow further analyses and apreliminary determination of what systems areinvolv
31、ed. If the suspected systems are softwarebased, further analysis may be necessary to isolatewhether the problem lies in the software or in itshardware operating platform.The investigation plan, under the responsibility of theRT, should include at least:1. Collection of information on procedures used
32、 thatcaused the removal and testing of the suspect systemCOMMENTARYAirlines may recognize, following step 1 of thisprocess, that the removals are caused by an internalprocedure. In this case, the airline may wish tocontinue to problem resolution without forming ateam or by forming a subset of a full
33、 team. Theairline(s) should inform the industry of the solutionchosen.2. Establishment of an RT that may include otherairlines, aircraft manufacturers and avionicssuppliers3. Provision of additional data to the team as neededfor further definition and isolation.3.3 Process to Isolate an AnomalyAfter
34、 a high NFF is detected, the next process should beto isolate the anomaly to its probable cause. To beeffective, the isolation process should be planned toinclude the following steps:ARINC REPORT 640 - Page 43.0 APPROACH AND RATIONALE (contd)3.3 Process to Isolate an Anomaly (contd)1. Preparation by
35、 the assembled RT of a detailedtesting and troubleshooting plan2. Comprehensive data analysis requirements3. Determination of a test plan and contents anddistribution of test results4. Identification of resources needed to accomplish thedata collection process and test process which mayinclude:a. Ne
36、cessary personnel skillsb. Necessary test equipment/test proceduresc. Problem simulation requirementsd. System hardware needse. Time scheduling on aircraftThe output of this process is intended to be identificationof the probable system components correlated with theanomalous behavior.3.4 Process to
37、 Resolve the AnomalyAnomalous system behavior can be caused by any one orsometimes several related failures. This documentintends to limit its coverage specifically to the processrecommended to resolve hardware and softwareanomalies.Resolution entails:1. Identification of a specific cause2. Duplicat
38、ion of the anomalous behavior undercontrolled conditionsCOMMENTARYIn some cases actual duplication of the conditionscausing the anomalous behavior being investigatedis not practical. In such cases appropriate analyticprocedures may be used.3. Identification, approval and release of interim work-arou
39、nd procudures4. Identification, implementation and verification of asolution5. Approval and release of the solution.6. Ongoing monitoring of the involved systems toassure that the NFF is resolved.ARINC REPORT 640 - Page 54.0 AIRLINE INPUTS TO PROBLEM4.1 GeneralAirlines report removal data to the CDA
40、 in order toquickly accumulate sufficient data to detect hardwareand anomalies causing high NFF rates.The removal data is arranged in the agreed format.Airlines that detect an anomaly themselves should reportthe potential anomaly to the CDA.When an anomaly is identified, airlines may need tocollect
41、further data necessary for analysis in accordancewith requirements established by the RT.Airlines also should provide data which the RT can useto determine the priority of the problem.4.2 Description of ProblemIn order to find a potential anomaly, airlines shouldreport removal data as defined to the
42、 CDA.In the case of a self-evident anomaly an airline shouldprovide anomaly information which is accurate, providedquickly, is consistent and is in needed detail.To do so, airlines should understand how the system ismechanized.4.2.1 Airline Data Support RequirementsIn order to support the data colle
43、ction phase to isolate ananomaly an airline should provide data as defined.The airline(s) should be advised by the airframe/vendorwhat data is needed for the investigation.4.3 Impact on AirlineIn order to have a common sense of urgency within theairline/airframe/vendor community, an airline shouldpr
44、ovide data regarding impact on the airline and theproblems relative priority.4.3.1 Airline PriorityBased upon airline impact an airline should propose apriority of the problem as follows:Critical - Safety RelatedUrgent - Serious operational or economic impact or potential of safety impactNormal - Le
45、ss serious economic or operational impact and routine fixesARINC REPORT 640 - Page 65.0 AIRFRAME MANUFACTURERS REQUIREMENTS FOR A SOLUTION5.1 ParticipationThe airframe manufacturer will participate in a problemresolution team. The team will typically be composed ofthe airframe manufacturer, the airc
46、raft systemsmanufacturer, one or more airlines, and manufacturersof interfacing systems as required.5.1.1 Data AnalysisThe airframe manufacturer will have access to the CDAdata base for all problem related data that is eitherassociated with that manufacturers aircraft, orassociated with components t
47、hat may be installed on oneor more models of that manufacturers aircraft. Inaddition, the airframe manufacturer will have access toits customer airlines. The airframe manufacturer mayperform its own analysis of data and identify areasconsidered to be potential anomalous problems. Data,results of ana
48、lysis, and recommendations that affect theindustry should be shared with the CDA and RT.5.1.2 Problem SelectionThe airframe manufacturer should participate in theproblem selection process, and may makerecommendations to the CDA.5.2 DataData provided by the airframe manufacturer to the RTwill be hand
49、led as proprietary. The airframemanufacturer is expected to have data, as appropriate,available for use by the RT during the investigation.5.3 TestingThe airframe manufacturer, with the problem resolutionteam, will develop any required test plan. The airframemanufacturer should be prepared to perform specialtests, field investigations, and/or investigations at anengineering laboratory or simulator.5.4 Problem CorrectionIf the best solution for the problem includes modificationof the aircraft or components, then the airframemanufacturer will be expected to prepare an aircraftrelate
