Development and Flight Test Experiences with a Flight-Crucial Digital Control System

NASA Technical Paper 2857

1 1988 Development and Flight Test Experiences With a Flight-Crucial Digital Control System

Dale A. Mackall Ames Research Center Dryden Flight Research Facility Edwards, Calgornia

I National Aeronautics I and Space Administration

I Scientific and Technical Information Division I CONTENTS Page

~ SUMMARY ...... 1 I 1 INTRODUCTION . . . . . 1 2 NOMENCLATURE . . 2 3 SYSTEM SPECIFICATION . . 5 3.1 Control Laws and Handling Qualities ...... 5 3.2 Reliability and Fault Tolerance ...... 5 4 DESIGN ...... 6 4.1 System Architecture and Fault Tolerance ...... 6 4.1.1 Digital flight control system architecture ...... 6 4.1.2 Digital flight control system computer hardware ...... 8 4.1.3 Avionics interface ...... 8 4.1.4 Pilot interface ...... 9 4.1.5 Actuator interface ...... 10 4.1.6 Electrical system interface ...... 11 4.1.7 Selector monitor and failure manager ...... 12 4.1.8 Built-in test and memory mode ...... 14 4.2 ControlLaws ...... 15 4.2.1 Control law development process ...... 15 4.2.2 Control law design ...... 15 4.3 Digital Flight Control System Software ...... 17 4.3.1 Software development process ...... 18 4.3.2 Software design ...... 19 5 SYSTEM-SOFTWARE QUALIFICATION AND DESIGN ITERATIONS ...... 19 5.1 Schedule ...... 20 5.2 Software Verification ...... 21 5.2.1 Verification test plan ...... 21 5.2.2 Verification support equipment ...... 22 5.2.3 Verification tests ...... 22 5.2.4 Reverifying the design iterations ...... 24 5.3 System Validation ...... 24 5.3.1 Validation test plan ...... 24 5.3.2 Support equipment ...... 25 5.3.3 Validation tests ...... 25 5.3.4 Revalidation of designs ...... 33 5.4 Qualification Issues ...... 33 6 CONFIGURATION CONTROL . 33 17 FLIGHTTEST ...... 34 I 7.1 General ...... 35 1 7.2 Fault-Tolerant Design ...... 37 I 7.2.1 In-flight experience ...... 37 7.2.2 Ground experience ...... 39 7.2.3 Summary ...... 40 I 7.3 Control Laws ...... 41

I iii i PRECEDING PAGE BLANK NOT FILMED 7.4 Hardware ...... 42 7.5 Software ...... 43 8 OBSERVATIONS AND RECOMMENDATIONS . 44 8.1 Anomaly of Flight 44, A Case Study ...... 44 8.1.1 Specifcation ...... 44 8.1.2 Design ...... 45 8.1.3 Qualification ...... 45 8.2 Observations and Recommendations by development Phase ...... 45 8.2.1 Specification ...... 45 8.2.2 Design ...... 46 8.2.3 Qualification ...... 47 8.2.4 Flight test ...... 48 9 CONCLUDINGREMARKS . 49

APPENDIX -CONTROL LAW VERIFICATION REQUIREMENTS 50

iv SUMMARY 1 INTRODUCTION

Engineers and scientists in the advanced The advanced fighter technology integra- fighter technology integration (AFTI) tion (AFT11 F-16 program provided the F-16 program investigated the integra- opportunity to investigate the bene- tion of emerging technologies into an fits and complexities of integrating advanced fighter aircraft. AFTI'S three advanced aircraft technologies into a major technologies included (1 ) flight- fighter aircraft. The study was a crucial digital control, (2) decoupled joint National Aeronautics and Space aircraft flight control, and (3) inte- Administration (NASA), U.S. Air Force, gration of avionics, flight control, and and U.S. Navy program and was managed pilot displays. In addition to investi- by the Air Force Flight Dynamics Labo- gating improvements in fighter perform- ratory. NASA goals were to ensure ance, researchers studied the generic safety during flight testing and to problems confronting the designers of provide an independent assessment of highly integrated f light-crucial digital the advanced technologies. control systems. The primary subject of this report The author provides an overview of is the digital flight control system both the advantages and problems of in- (DFCS) and its integration with the tegrated digital control systems. An avionics and pilot displays. An intro- examination of the specification, de- duction to the history, rationale, and sign, qualification, and flight test nomenclature of digital flight control life-cycle phase is provided. An over- systems can be found in Szalai (1978). view is given of the fault-tolerant The AFTI F-16 DFCS development objec- design, multimoded decoupled flight tives included assessment of a triplex control laws, and integrated avionics dual-fail operate architecture, integra- design. The approach to qualifying the tion of avionics and pilot displays with software and system designs is discussed, the DFCS, and development of mission- and the effects of design choices on specific decoupled flight control modes. system qualification are highlighted. Operating a DFCS without mission AFTI F-16 flight test results are impairment after any two failures summarized for the fault-tolerant, de- required a minimum of four channels of coupled flight control, hardware, and redundancy in previously designed sys- software requirements. The effects of tems. If a triplex system could cor- design choices and qualification proce- rectly choose between the remaining dures on flight test operations are de- two channels when the second failure tailed, based on AFTI flight experience. occurred, acquisition and maintenance costs for the flight control system Observations and recommendations are could be reduced. Reducing pilot work- given for each development phase - speci- load and increasing weapon effectiveness fication, design, qualification, and were the goals of integrating the DFCS flight test. and its mission-specific decoupled control modes with the avionics system and pilot displays. In previously designed A/S airspeed systems, the flight controls did not have specific modes for the different ASB air-to-surface bombing missions. The pilot was required to individually configure each avionic ASG air-to-surface gunnery system for a mission. ATP acceptance test procedure This report includes an historical review of the development and flight lateral acceleration, ft/sec2 test of this integrated DFCS program. AY The historical review is structured to ac alternating current provide an adequate background of the development process and the resulting alpha angle of attack, deg design needed to comprehend the flight test results. The author addresses each an normal acceleration, ft/sec2 of the development phases - specification, design, qualification, and flight BIT built-in test test. Important lessons learned are illustrated with examples from flight beta angle of sideslip, deg test experience. CADC central air data computer The increasing use of system integration to increase aircraft ccv control configured vehicle performance, and the flight crucial nature of these systems, dictates a CHGR charger, battery thorough assessment of this integrated DFCS program. CPC computer program component

CPDS computer program development 2 NOMENCLATURE specification

CPPS computer program product AAG air-to-air gunnery specification ~

ACK acknowledge CPU central processing unit i ( A-D analog to dig1tal c.g. center of gravity, percentage

mean aerodynamic chord I AD I atti tude directional i indicator D-A digital to analog I AFT1 advanced fighter tech- DAAG decoupled air-to-air gunnery 1 nology integration DASB decoupled air-to-surface I AGL above ground level, ft bombing I I AIU actuator interface unit DASG decoupled air-to-surface I gunnery ALT altimeter I

DFCS digital flight control system ~ AMUX avionics multiplex bus

2 DGFT dog fight HS I horizontal situation indicator DN down HUD head-up display DNRM decoupled normal HZ hertz DST device status table hr hours dc direct current I BU independent back-up unit degrees I FFC integrated flight fire control deg/sec degrees per second ILS instrument landing system EMIC electromagnetic interference and compatibility INU inertial navigation unit

EPU emergency power unit I oc input-output controller

ETSE engineering test support I SA integrated servoactuator equipment KCAS knots calibrated airspeed FCC fire control computers k thousand FCR fire control radar LARAP low-altitude radar autopilot FDIR fault detection, indentifica- tion, and reconfiguration LAT-DIR lateral-directional

FLCC flight control computer LCND left canard

FM failure manager, a software LEF leading-edge flap component L FLP left trailing edge flap FMET failure modes and effects testing LH left hand

FPME f lightpath maneuver L HT left horizontal tail enhancement LOC location in memory flt flight LQS linear quadratic synthesis ft feet LRU line replaceable unit good channel average lb pounds G command M Mach longitudinal acceleration, g MAX maximum afterburner power

3 MHz mi1 lion hertz RCND right canard

MIL military power RFLP right flap

MPD multipurpose display RH right hand

MSL median select log C RHT right horizontal tail

MSOV missile override RM redundance managment

msec millisecond ROM read only memory

NX longitudinal load factor, g RUD rudder

NY lateral load factor, g rad radian

NZ normal load factor, g rad/sec radians per second

OFP operational flight program recon reconfiguration

P roll rate, deg/sec rPm revolutions per minute

0 SAAG standard air-to-air gunnery P roll acceleration, deg/sec2 SASB standard air-to-surface PDG programmable display bombing generator 1 SASG standard air-to-surface I PLA power lever angle, deg gunnery I PMG permanent magnet generator S/M selector monitor PRME pitch rate maneuver S MS stores management set enhancement

PS pressure system S/N serial number i ! I SNRM standard normal mode PSA pneumatic sensor assembly sow statement of work PS static pressure SP pitch stick lb/f t2 pounds per square foot SR roll stick Q pitch rate, deg/sec

SV1,2,3 servovalues 1 I 2 I 3 Qc impact pressure sec second R yaw rate, deg/sec T throttle twist RAM random-access memory

4 TCO total computed output or modified, that was required to accom- plish AFT1 objectives. The following TEF trailing edge flaps, deg paragraphs in section 3 will address the specifications only as they apply to the TR transformer rectifier digital flight control system.

V velocity vector 3.1 Control Laws and Handling Qualities

V and V verification and validation The SOW specified the requirements for the unique decoupled control modes VA vo 1t-amps ( table 1 1 and the airframe stability and flying qualities requirements. v ac volts, ac Decoupled control requirements included direct lift and sideforce, fuselage VCRI verification cross reference pointing independent of flight path, ver- index tical and lateral translation, and wings level steering. The stability and fly- V dc volts, dc ing qualities requirements were based on MIL-F-8785C (U.S. Department of Defense, VID video 1980). From the SOW, the contractor provided the detailed requirements for air- w frequency, rad/sec craft stability and flying qualities. Requirements included short-period damping ratio limits, short-period 3 SYSTEM SPECIFICATION frequency requirements, dutch roll frequency and damping, and force gradient limits for controllers. In the system specification phase, operational requirements are detailed to a 3.2 Reliability and Fault Tolerance level the designers can use. The reliability and fault tolerance re- The first step in specifying the quirements from the SOW are shown in AFTI F-16 (fig. 1) system design was table 2. These include reliability, the statement of work (SOW) released fail-operational, switching and fail- on November 16, 1978 by the Air Force ure transients, and cooling require- Wright Aeronautical Laboratories, Wright ments. A requirement was a 95-percent Patterson Air Force Base, Ohio. This chance of being fully operational for document specified the requirements for a second failure of a similar device. decoupled control, weapon line pointing, MIL-F-9490D (U.S. Department of De- aerodynamic vehicle modifications, digi- f ense, 1975) provided the requirements tal flight control system, and pilot- for DFCS development. vehicle interface. These general requirements were then detailed in the Software requirements stated that following categories: air vehicle, sys- the contractor develop, validate, and tems engineering, test and evaluation. maintain the software in accordance with The contractor, General Dynamics, in a software development and management Fort Worth, Texas, was responsible for plan prepared by the contractor. It the second step in specifying the sys- identified the procedures and methodol- tem. After the contractor generated the ogies for verification and validation, system specification, an entire tree of documentation, and control of software. specifications grew for each system, new The requirement for an independent

5 backup unit (IBU) for the DFCS was and fault tolerance aspects, (2) control identified. The IBU provided an analog laws, and (3) software. backup to the primary DFCS that is independent of the DFCS software. Level 3 4.1 System Architecture and Fault flying qualities (U.S. Department of Tolerance Defense, 1980) throughout the flight test envelope and level 2 flying qual- System architecture and fault tolerance ities in landing were specified for are closely associated. The multi- the IBU. channel architecture is a direct result of the need for fault tolerance. The electrical system was required Because a large portion of the fault- to provide power to support DFCS reli- tolerant design is in software, the ability requirements. System level and software aspects of the fault-tolerant DFCS specifications from the contractor design are also covered in section 4.3. restated the requirements of the SOW, Additional information can be found in identified quality assurance provisions, Yousey and others (1984). and provided a comprehensive design criterion for the DFCS and its components, 4.1 .1 Digital Flight Control System redundancy levels, and their fail- Architecture operational capabilities (table 3). The requirements for the DFCS archi- The quality assurance section of tecture (fig. 2) were derived directly the specifications provides a table that from the SOW and system specification. cross-referenced system requirements to This derivation consisted of identifying verification methods (table 4 1. The re- specific design requirements for each liability aspects are shown to be veri- numbered item in the SOW and system spec- I fied through analysis only (items 3.2.3.1 ification. For each design require- and 3.2.3.2 of table 4). In nonredun- ment, hardware and software resources I dant systems that consist of hardware were then allocated to ensure that the I I only, analysis techniques, such as fault design requirements were met. trees, are sufficient. However, in re- I dundant, software-driven systems, ground For example, the design requirement I test and demonstrations are also needed for six-degree-of-freedom control was I to verify reliability. Hence, extensive achieved using the standard F-16 sensors, the triplex computer set, and the 1 failure modes and effects testing were 1 developed (section 5). standard F-16 control surf aces plus the canards. Reliability requirements were Documents that specify the software satisfied by having computer mean-time- i development are identified in the speci- between-failure rates and redundancy I fications by title only. All relevant consistent with those needed to meet I military standards are identified. probability requirements. Figure 3 1 shows the reliability of a single- I I channel design and a triplex-channel I 4 DESIGN design. The failure probability for the triplex-channel system of 1 x per i 1 flight hr includes the IBU. The major I This section contains the DFCS design causes of loss of control are discussed and provides an overview of the methods in Price and others (1984). Concerns I used to obtain it. The design issues for software reliability were addressed I I addressed are (1 ) system architecture with the inclusion of the IBU. Figure 4 I 6 ~

shows the IBU and its relation to the mands to improve the system's fault tol- primary DFCS. The IBU can be engaged erance in that axis. Space limitations either manually by the pilot or automa- in the computer prohibited output selec- tically if proper operation is lost by tors for all surface commands. The per- the three digital processors. formance issue was of constant interest, and the modifications to improve IBU per- A significant architectural aspect formance continued into flight test. of the DFCS was that the operations of The design of the IBU can be found in the three computers were not synchro- Price and others (1984) and in section 4. nized. This choice was made by the con- The IBU modifications included tuning tractor because computer syncronization the pitch rate path and providing dif- was believed to introduce a single-point ferential horizontal-tail commands when failure caused by electromagnetic inter- in manual pitch override (stalls). ference (EMI) and lightning effects. The IBU was engaged either manually To obtain the detailed DFCS archi- or automatically. IBU tracking of the tecture, engineering studies and reli- primary system for engagement purposes ability analysis of hardware components was rejected owing to the need for inde- were performed; no formal or structured pendence, because a failure in the pri- tool was used. Architectural design mary system could not be allowed to issues included (1 ) the design of the affect the IBU's operation. However, IBU and (2) the analog sensor interface. the digital system did track the IBU to minimize reengagement transients to the The IBU trade study addressed (1 digital system. This was easily accom- how reliable the IBU should be, what re- plished since the digital system moni- dundancy level was needed, and if output tored the IBU surface commands for in- command voting would be required; (2) flight failure detection and built-in what flight control performance was retest (BIT) purposes. quired of the IBU (requirements were for level 3 handling qualities throughout Issues addressed for the sensor the flight envelope except for level 2 interface included (1 ) the use of digi- at landing); (3) what the engagement tal rather than analog cross-strapping method should be for the IBU; and (4) of information (fig. 51, and (2) how to minimize transients on engagement required sensor sampling rates to min- and disengagement of the IBU, These imize differences introduced by the issues were further complicated by the asynchronous computer operation. Analog disagreement between the procuring and cross-strapping was first thought to be flight test agencies regarding flight required to meet data latency and reli- test of the IBU. The flight test agen- ability requirements. However, as cies' position to flight test the IBU detailed analysis showed this was not prevailed and this directly influenced true, digital cross-strapping was chosen the performance issue and the need for because it required less wiring. Digi- manual IBU engagement and disengagement tal cross-strapping was accomplished by the pilot. using two dedicated serial transmission lines for each computer. To minimize A triple redundancy level was chosen differences introduced by asynchronous for the IBU with a portion of one flight operation, sensors were sampled at four computer card in each of the three DFCS times the basic flight control rate of boxes dedicated to the IBU. An output 64 Hz. This was of particular concern selector, which can select valid com- for pilot inputs from the force stick, mands after a single failure, was which can have higher input rates than included for the horizontal-tail com- the aircraft sensors. An assumed worst

7 case input to maximum command was ana- 4.1.3 Avionics Interface lyzed at 100 percent in 0.1 sec, or 1000 percent/sec (fig. 6). The The items that determined the DFCS increased sampling rate reduced the interface with the avionics were inte- interchannel differences to less than gration of the pilot station with the 4 percent for a prefilter break fre- DFCS to reduce pilot workload, instru- quency w of 50 rad/sec. This analysis mentation of the DFCS, and the use of was also the first to recognize the information from other avionic subsys- effect of asynchronous sampling errors. tems. The primary avionics systems The sampling errors introduced differ- (fig. 8) included a fire control com- ences between computer channels for each puter (FCC), stores management set computer-calculated surface command. (sMS), inertial navigation unit (INU), fire control radar (FCR), central air 4.1.2 Digital Flight Control System data computer (CADC), two multipurpose

I Computer Hardware displays (MPD) , instrumentation system, and a head-up display (HUD). The avi- The flight control computers (FLCC) onics were interfaced through a MIL-STD- used were the Bendix (The Bendix Corpor- 1553B data bus controlled by the fire ation, Teterboro, New Jersey) BDX-930 control computer. computers (fig. 7). The basic computer included a central processing unit The types of avionics information (CPU), based on a 16-bit, bit-sliced involved in the DFCS interface and the microprocessor and solid-state memory avionics systems that pass the infor- (6K words of random-access memory (RAM) mation are shown in table 6. Pilot mode and 24K words of programmable read-only selection and status information repre- l memory). The CPU did not have floating- sented the most safety critical data of point capability and was programmed in the avionics interface. Details on the assembly language. The CPU was supple- pilot-vehicle interface are given in

I mented with an input-output controller subsection 4.1.4. Parameters were sup- that performed all input and output plied to the DFCS from the INU, includ- data conversion with a single command ing roll attitude, pitch attitude, and from the processor. This allowed the velocity. The parameters were used in processor to compute flight control the decoupled control modes to assist algorithms without being burdened by the pilot during rolling maneuvers. inputting and outputting discrete and analog signals. The ability to instrument and mon-

I itor internal DFCS parameters was essen- I Additional functions in the flight tial for thorough testing, both in the control computers included a MIL-STD- laboratory and during flight test. The 1553B multiplex data bus interface, design approach was to have the FCC send failure logic, the IBU, and serial data the DFCS a list of internal DFCS memory links to and from each of the other two locations to be sent to instrumentation; computers. Failure logic was special this list was sent following the running circuitry that allowed two computers to of a BIT. The DFCS did not store its fail another; this logic was required own list because the FCC used nonvoli- to provide the dual-f ail-operate capa- tive core memory and changes to the list bility. A description of the analog and could be made more easily. However, discrete inputs and outputs is provided this proved not to be true and during in table 5. The FLCC represented a flight test, the design was changed to state-of-the-art computer in terms of have the DFCS store its own parameter technology used, throughput, and memory. lists. The DFCS could output 64 parameters at a 50-Hz rate.

8 The MIL-STD-1553B data bus is a dual controller commands is shown in fig- redundant (one active and one backup) ure 11. Note how the decoupled motion 1 1-MHz serial bus controlled by the fire obtained by the rudder pedal and twist 1 control computer. The 1553B data bus grip command changes for different I performs parity checks and polling tests modes. Descriptions of the decoupled l when transmitting to the other avionics control options are shown in figure 12. systems. Failure of these tests causes the bus controller to retry the infor- Discrete switches in the cockpit I mation exchange on the backup bus. If were kept to a minimum. They included ' the FCC failed, the stores management aircraft trim, decoupled mode selec- 1 set took over bus control. tion, a normal acceleration limit I I engagement switch, IBU switch, and 4.1.4 Pilot Interface failure resets. Several switches used by other aircraft systems, but related to the flight control system, include speed brake switch and throttle at military and idle positions.

Flight control modes were selected in several different ways. Decoupled mode and IBU were selected using switches on the right-hand control stick. Selection of the different mission control modes - air to air and air to ground -were made in conjunction with avionic and weapon system changes through the HUD panel (fig. 9) or a switch on the throttle (air to air only). Selection of mission specific flight control modes, independent of the other aircraft systems, could be made through the MPDs. In all cases mission specific control modes were selected through the SMS. The SMS sends control mode requests to the DFCS over the 1553B multiplex bus. The mode selection data flow is summarized in figure 13.

The status of the DFCS was presented to the pilot in three ways -warning and failure resets. lights, MPD messages, and HUD displays. The dedicated failure lights warned the pilot of failures detected by the DFCS; the pilot would then use the MPDs to determine the exact failures detected. The HUD information was primarily related to control of the aircraft, but also provided some information on failure aspects of the DFCS.

The MPDs were designed to be the primary interface between the pilot and

9 the DFCS. The MPD functions, HUD indi- has the failed angle-of-attack sensor. cations, and failure lights are listed Although some of this detailed infor- and briefly described in table 7. Fig- mation was meant for engineering analy- ure 14 shows the DFCS base page and the sis only, pilot attempts to decode the selection of the DFCS test page. displays lead to confusion.

There were two major concerns with 4.1.5 Actuator Interface the pilot interface to the DFCS. The first concern was the lack of redundancy Considerable preliminary design work in the command path for mission-specific was spent on refining the interface of control mode selection. This concern the triplex flight control system to the for redundancy in the pilot's control surface actuators, which were previously mode selection proved to be valid, as an driven by the F-16 quadruplex analog in-flight anomaly showed during flight flight control system. A system inte- test (see section 7.2.1). The second gration memo investigated seven possible concern was for the method used to dis- reconfigurations using the triplex sys- play pilot fault information. The fault tem, in terms of the reliability of display complexity is best demonstrated each. In addition to having a reli- with tables from the pilot's manual and able actuator interface, the DFCS was an example. A list of the levels, required to detect failures in the com- types, and classes of fault nmemonics mands to the actuators before the actu- for the DFSC is given in table 8, and ators reconfigured for the failure con- the fault nmemonics for each of the dition. Additional test data on the three categories are described in actuators, which determined fault table 9. Armed with this informa- levels, allowed for an initial DFCS tion, and the ability to decode the fault detection design. However, the hexidecimal numbers into binary num- fault levels dictated by the actuator I bers, the pilot could determine from a characteristics were small enough that I fault display (fig. 15) what the DFCS asynchronous sampling errors would cause 1 had declared failed. This fault dis- nuisance failures. After several design play tells the pilot that a 1st failure iterations, the actuator interface I has occurred to an input used in the requirements were finally met, illus- pitch axis control of the aircraft. trating that fault detection designs I Below the English description of the can require considerable effort and fault, is a two-digit number and three are dependent on device characteris- I 1 single digits (see fig. 15). The first tics which may normally not be obvious. number can be decoded using table 10, indicating that an angle-of-attack sen- The remainder of section 4.1.5 sor had failed. Table 10 also gives the describes the ISA and the DFCS interface failure words displayed for each of the to the ISA; further detail can be found categories shown in table 8. The three in Price and others (1984). Each of digits (fig. 15) identify what each com- the seven integrated servoactuators puter believes is the failed channel. (ISAS) accepts electrical commands from Each number represents a computer chan- the flight control computers in three nel - A, B, and C - left to right. A electrohydraulic servovalves (fig. 16). two implies that the channel repre- It converts these commands into a power- sented in that column has failed; a four ram position, which then positions the implies that the channel to the left has respective control surface. Several failed; and a one implies that the chan- significant functional characteristics nel to the right has failed. In this are embodied in the design of each ISA: case the 1st channel, termed channel A,

10 I I I I 1. A unique mechanical position the actuator interface to operate after I and rate feedback scheme combines the two failures. I feedbacks into a single input to each servovalve. In the case of a dual failure, a model of the actuator was run to detect I 2. Three servovalves (SV1,2,3) are any failures. If a failure was de- provided for redundancy; SV1 and SV2 tected, the DFCS would send a signal normally share control of actuator posi- to center the actuator, preventing a I tion, while SV3 is held in standby. hardover command and subsequent loss of aircraft control. 3. Servovalve failure is I detected by comparing servovalve The reliability of the DFCS and of I f irst-s tage pressures. its interface to the actuators was significantly better than the hydraulic and I 4. Self-contained hydromechanical actuation system itself. Design of the I failure detection and correction logic interface to the actuators required is incorporated for first failures of information about the actuators which, the servovalves or for the hydraulic at the time, was not available. system. A first failure of SV1 or SV2 I will transfer control to the standby 4.1.6 Electrical System Interface SV3. A first failure of SV3 will lock the servoactuator on SV1 and Electrical power is required for ! Sv2 control. aircraft control, since the aircraft has I a full-authority DFCS. Reliability re- I 5. Hydraulic system failure correc- quirements of the DFCS were also applied I i tion is given precedence over all servo- to the electrical system. Electrical valve failures. Servovalves SV1 and SV2 power from five sources provides the operate on one hydraulic system, and SV3 redundancy needed to ensure DFCS opera- operates on the other hydraulic system. tion. The preliminary design for the electrical system is shown in figure 17. 6. Fail-safe capability is incor- The DFCS only required 28 V dc power for porated to allow the ISA to center operation. The five sources of power mechanically upon receipt of an elec- were provided by the 40 kVA primary I trical command to the fail-safe sole- generator and the 5 kVA emergency noids from an external electronic model generator through ac to dc converters, I or monitor unit. a 500 VA permanent magnet generator 1 (PMG) on the emergency generator, and I Each servovalve can be driven by two batteries. either its primary or secondary coil. The primary coil of each servovalve is In normal operation the primary driven by a corresponding FLCC channel. generator provides 28 V dc power to the In the event of an FLCC failure, the flight computers and maintains a charge secondary coil is driven through the on the two batteries. Loss of the i backup amp by one of the remaining good engine or the primary generator will I I computers. As discussed earlier, fault switch on the emergency generator. The I detection of the ISA required a complex PMG provides a limited 28 V dc through set of fault detection logic in the DFCS the 500 VA transformer rectifier (TR) I computers to monitor computer failures, unit for certain failures of the emergency generator. The power from the I failures in electrical commands to the servovalves, and the pressure of the PMG TR and the batteries was supplied I hydraulic systems. The monitors allowed through three current switches to the

11 DFCS. The purpose of the current switch tics of the hardware (sensors, control- is to limit the output current so that lers, actuators) being monitored. I short circuits in one channel would not have called this hardware-software de- affect others. sign the fault-tolerant design. Redun- dancy management and fault detection, The major difference between the identification, and reconfiguration preliminary design and the design for (FDIR) is also a common name. A part flight test (fig. 18) was the inclusion of the fault-tolerant design - built-in of voltage detectors on any FLCC power test- is discussed separately. line being fed by the emergency generator, including the PMG. During this No formal tools were used to develop time, it was found that emergency power or analyze the fault-tolerant design, failures on F-16 aircraft resulted in a although analytical studies were per- failure mode which caused an overvoltage formed to evaluate different algorithms. condition. The overvoltage condition The S/M provided selection and fault inhibited proper flight control sys- detection for (1) input discretes (ta- tem operation. ble ll), (2) analog inputs (table 121, (3) digital commands for each control When the AFT1 design detected an surface, and (4) the actuator and its overvoltage condition, the aircraft electronic interface. The input dis- began operating on batteries. Bat- cretes fall into two categories based tery size was increased to provide on the amount of switch bounce. The two about 30 minutes of flight time. categories are labeled by the settling time required by the discrete input. A unique operating condition during flight test caused the PMG output to The basic S/M approach was to use overvoltage. The cause and implica- cross-channel information for signal se- I tions of this anomaly are discussed lection and monitoring. After a channel in section 7.2.1. had sampled its values, the information was sent in digital form to the other 4.1.7 Selector-Monitor and Failure two channels for comparison (fig. 19). mnager The majority of analog signal values I The names selector-monitor (S/M) and was obtained using a good-channel-average I I failure manager (FM) are derived from (GCA) algorithm with selection of dis- I the two software components in which crete values by a majority vote. The GCA I they are implemented. The S/M provides algorithm is summarized in figure 20. for: (1) signal selection, (2) fault Any value which differs from the other 1 detection, and (3) reconfiguration for two by a preset threshold is declared I discretes, sensors, controllers, output failed. The f ault-de tection algorithms surface commands, and the actuator allowed for setting unique failure interface. The S/M software component thresholds and persistence times for each works closely with the FM software for of the inputs. In certain failure cases, recording and analyzing failures. such as dual failures, a model was run to I provide the needed information to resolve I i The FM records and analyzes informa- failures. Actuator and leading edge flap I tion provided by the S/M and provides (LEF) models were both used to resolve for pilot resetting of failures. The dual failures. designs of the S/M and FM were dependent 1 on system architecture, asynchronous The most complex aspect of the S/M ! operation, and the unique characteris- is the actuator interface and LEF fault

12 i detection algorithms. Multiple moni- failure, was four iterations or about tors were needed to provide proper 62 msec. Owing to command errors intro- selection and fault detection of the duced during dynamic maneuvers, the unique hardware. Included are wrap- failure thresholds had to be increased. around, output electronics, lock, and A variable threshold was used, with the centering monitors. rate of change of the surface command added to the 15-percent baseline. If The failure manager component pro- the surface moved 5 percent of full- vides much of the intelligence behind scale in the previous iteration, the the dual-fail-operate design aspects. failure threshold would be 20 percent. Using a hierarchical structure (ta- Failure thresholds were independently ble 13 l, the failure manager would calculated in each channel. Channel analyze individual failures and fail signal selection for output surface com- higher or lower level devices accord- mands was a function of channel and ingly. For example, a failire of the hydraulic failures. In the nonfailed analog-to-digital converter would result state all three channels used channel in logically failing all devices below B's value. This was required to mini- it (see 2.1 through 2.4, table 13). In mize the errors between asynchronous another example, if a pitch rate sensor channel commands which would otherwise failed first in channel A and an in- be detected by the actuators. verter failed second in channel B, the FM would attribute a second detected The fault-tolerant design for failure of a pitch rate sensor to the detecting failures of individual com- failed inverter - and not to a disagree- puters is summarized in figure 21. The ment between the two sensors. There- three methods for failing the entire fore, all three computers would use the computer processor and input-output last pitch rate sensor from channel C. controller include watchdog timer, con- If the second failure of the same type sensus of other two channels, or self- sensor cannot be resolved, the control test failure when it is run to resolve laws will be reconfigured so that the second failures. In the case where sensor information is not needed. three or more surface calculations fail, the computational portion is failed but I The S/M used on the digital commands the input-output controller runs inde- 1 for each control surface (the result of pendently, supplying sensor information 1 the control law computations) deserves to the remaining two channels. 1 special attention. This software i detected partial failures of computers Tools to study the effects of dif- 1 that resulted in wrong computations of a ferent fault-tolerant designs are lack- l given surface command. Individual coming. Different selection and fault- putation failures were allowed for each detection algorithms were designed and 1 of the seven surface commands. Failure analyzed using analytical studies. 1 of three or more surface computations Simulation or emulation of the fault- resulted in the FM declaring an entire tolerant design was not available to i channel failed, if not already detected determine the effects on reliability or by hardware monitors. interaction with control law algorithms.

I Failure thresholds for the surface The hierarchical structure used to commands were originally set at 15 per- improve fault tolerance by resolving cent of the full-scale command. Persis- second failures is a novel design. tence time, the time required for the Failure modes and effects testing error to persist before declaring a demonstrated that this approach is a

13 valid method to increase fault toler- The triple system appeared as a single ance. The hierarchical structure pro- system with one channel controlling the vides designed-in knowledge of the aircraft within the failure thresholds. system. This knowledge provides the information needed to resolve high- 4.1.8 Built-In Test and Memory Mode and low-level failures. The built-in test (BIT) is run prior Memory parity checking was included to each flight to ensure the integrity in the computer hardware. A parity of the DFCS. The BIT is also used in error interrupt occurred when bad par- maintenance procedures to isolate faults ity was detected. However, the fault- to the line replaceable unit (LRU) tolerant design did not consider parity level. Memory mode was another pilot errors. The interrupt and memory option available only on the ground. It address were saved and processing con- allowed the pilot to give the flight continued. This approach of ignoring hard- trol system a memory address and obtain ware failure indications, unless they a readout of the three computers' corre- resulted in output command failures, sponding values. raised concerns about latent failures. The effect on system reliability when The BIT consisted of four major test this type of latent fault is allowed categories: (1 1 input, (2) computation, was not modeled. (3) output, and (4) failure logic. The three channels had to be synchronized to The fault- tolerant design was get valid BIT results. impacted heavily by the asynchronous computer operation. Errors between Input testing ensured proper opera- channels in the input sensors and tion of sensor and input conversion controller, owing to time-skewed hardware. Null failures, which would sampling and dynamic conditions, remain latent until aircraft motion caused two main problems: allowed for fault detection, were detected by BIT. Hardware input signal 1. Errors between channels forced conversion failures were separated from the failure thresholds higher. The sensor failures by injecting input sig- 15 percent of full-scale plus rate value nal biases into the hardware under BIT allowed large failure transients. Hori- software control (fig. 22). Passing zontal tail transients corresponding to this test, BIT would then torque the the 15-percent failure transient are sensors to test for faults. Tests for 3.75O. At low altitude, high-speed con- the avionics multiplex bus (AMUX) and ditions, the aircraft's normal accelera- cross-channel data link, both serial tion transient would exceed 3 g, well digital buses, were also performed. beyond that called out in the specifications (table 27). Computational tests include those for the CPU, RAM, and read-only memory (ROM). 2. Errors between the channel in- Output tests are run by BIT for the seven puts were passed through the control law actuators, LEF, and output conversion calculations to the outputs. In order hardware (digital to analog). Testing for the actuators to accept the commands also included detecting null or passive without having the hydraulic system vot- failures of components that are used only ing, an output command selection method in the event of failures. Testing the was needed. The method required all ability to center an actuator is an three channels to choose one value - example, even though it was required channel B's value is used in the non- only when multiple failures occurred. failed case - to drive the actuators.

14 The BIT requirements for testing the trol mode. The control laws are de- failure logic is similar to the actuator scribed to provide the reader with an centering example. Although the failure overview of the system. logic is only used when single or multiple channel failures occur, latent fail- The control law designs provide €or ures in this logic circuitry could prove mission specific flight modes and stand- catastrophic. The BIT checked for pas- ard and decoupled aircraft control sive failures not detectable by the in- (fig. 23). Mission specific modes are flight fault-detection routines. standard normal (SNRM is for takeoff, refueling, and landing), standard air- The BIT operation suspends all con- to-air guns (SAAG) , standard air-to- trol law and fault-detection routines surface guns (SASG), and standard air- required for flight. Therefore, two to-surface bombs (SASB). A decoupled lockout methods were used to ensure BIT version of each standard mode is and memory mode would not operate in available through the decoupled mode flight. The weight on wheels switch selection switch on the right-hand and lack of main wheel spin-up (less controller. Pilot control is through than 28 knots) were required to allow the side stick, force stick, and the activation of the modes. Both lockouts rudder pedals, and decoupled pitch axis had triple signal redundancy. control is through a modified throttle controller that twists. The BIT and memory mode were acti- vated through the multipurpose displays 4.2.1 Control Law Development (fig. 14). The DFCS test page display Process provided BIT and memory mode initiation and display. The BIT required two and The control laws were developed a half minutes to complete. The memory using four different, and progressively option allowed for displaying memory more detailed, methods. The initial values of all three computers and was design was obtained using linear con- used for troubleshooting BIT failures. tinuous models. The longitudinal axis Communication to the DFCS to initiate used linear quadratic synthesis for its BIT was over the AMUX bus to one DFCS initial design. The second design method channel. The cross-channel data link included discrete sampling effects of the was used to inform the other two chan- digital system with the linear models. nels. The time of BIT initiation varied Criteria for natural frequency, damping, in three channels owing to asynchronous and phase and gain margins were used to operation and was a function of com- evaluate the designs. Nonlinearities puter skew. were included in the third design method which used a nonreal-time batch simula- The BIT design is a comprehensive, tion. The final design evaluations used structured set of tests that ensure man-in-the-loop real-time simulations. hardware integrity prior to takeoff. Evaluations were centered on handling- The mechanization document to the soft- qualities criteria, tracking tasks, and ware group contains over 180 pages in weapon delivery accuracy. Anderson and the BIT section. Memory mode proved to Frank (1984) provide additional infor- be a valuable troubleshooting tool. mation on the control law developments. I 1 4.2 Control Laws 4.2.2 Control Law Design 1 I i This section includes an overview of the The eight mission specific stand- methods used to develop the control laws ard and decourled control modes are and the features designed into each con- I I

15 implemented in five longitudinal con- pitch rate system with the normal accel- trol structures and three lateral- eration or angle-of-attack value set directional structures. An overview to zero. of each control law, the mission specific modes applicable, and primary Because the airplane is statically design features is given. unstable, pitch rate reconfiguration required estimating pitch rate based on Features of all the longitudinal elevator command. The complete failure control laws are as follows: of air data used to schedule control system gains resulted in standby gains. 1. Neutral speed stability, The standby gains were a predetermined set of gain values that provide adequate 2. Drag modulation, stability and control throughout the envelope, and only change as a function 3. Near constant stick force per g, of the landing gear position.

4. Departure prevention, The third longitudinal control law was used in the SAAG and SASG modes. 5. Angle of attack and lead fac- The major difference from the SNRM mode tor limiting, was that pitch rate is used as the main feedback, providing for better tracking, 6. Optimal flap scheduling on angle improved flightpath control, and reduced of attack, tracking errors in turbulence.

7. Maneuvering flaps, and The fourth longitudinal control law was used in the SASB mode. This mode a. Structural filters. was similar to the SNRM. The SNRM gains are changed as a function of Mach num- The first longitudinal control law ber and altitude to give SASB mode structure is used only in the SNRM. The (fig. 24). In order to improve flight- SNRM provides aircraft control for take- path response, the maneuvering flap gain off, in-flight refueling, formation is increased. flying, and landing. If SNRM was not previously selected for landing, it is The final longitudinal control law automatically selected when the land- was used by all the decoupled modes. ing gear handle is lowered. The SNRM Three types of decoupled longitudinal control laws implement a pitch rate controls were available - pointing, system gear down and a G-command (GCMD) translation, and direct lift. Pointing system gear up. generated pitch rate without generating normal acceleration; translation gener- The second longitudinal control ated normal acceleration without gener- structure is used when sensor failures ating pitch rate; direct lift generated force reconfiguration of the control a combination of pitch rate and normal structure to account for loss of a feed- acceleration without changing angle back. Termed the reconfiguration mode, of attack. it allows for operation with complete loss of pitch rate, normal acceleration, Flightpath maneuver enhancement angle of attack or air data sensors. (FPME) and pitch rate maneuver enhance- Multiple reconfigurations are not accep- ment (PRME) were two coupled (conven- table. Normal acceleration and angle- tional) control features commanded with of-attack reconf igurations used the SNRM the sidestick. These were the only

16 features available on the right side- the one control structure through the stick, and they operate independently use of software. The switches, nearly or simultaneously with throttle-twist 20 in this control law structure, create decoupled mode inputs. The FPME was the required submode structures that tailored for the cruise and bombing represent each decoupled option. tasks because the mode provided a re- sponsive deadbeat normal-acceleration The LAT-DIR control modes operated response. The PRME was tailored for at two iteration rates. Control inputs, air-to-air tracking and air-to-ground roll stick, and pedals were shaped and strafing because this mode required filtered at 32 Hz. Feedback paths and deadbeat pitch rate response. All interconnects operated at a 64-Hz itera- longitudinal modes operated at a 64 Hz tion rate. iteration rate. The number of control modes and the The first lateral-directional (LAT- decoupled capabilities required resulted DIR) control law was used in the SNRM in a complex set of control structures. only. Features include In the longitudinal modes, where the linear quadratic synthesis (LQS) design 1. Roll rate command prefilter methodology was used, gain schedules which was quicker for stopping roll requiring double interpolations were rates than when initiating them, needed (fig. 25). Gain N1, the stick feed forward gain, requires interpo- 2. Lateral acceleration, roll rate, lation of altitude and Mach number. and yaw rate feedbacks, From a system engineering viewpoint, 3. An aileron-rudder interconnect, the complex control structures were a boiling pot of ingredients. These 4. A roll-rate and angle-of-attack ingredients included outputs from the interconnect , selector monitor and submode switches based on pilot selections and aircraft 5. Gun-firing compensation, and configuration. Besides these inputs to the control structures, the control 6. Structural filters. structures themselves provided surface commands to the output fault detection The second LAT-DIR mode was the routines. The control law design pre- reconfiguration mode, which is based on sented a formidable task in qualifying the SNRM. Roll rate, lateral accelera- the system. tion, yaw rate, and air data reconfigurations were included. 4.3 Digital Flight Control System Software The last LAT-DIR mode was used by SAAG, SASG, SASB, and all the decoupled The process used to obtain the software modes. Three decoupled control options design and an overview of the software were available in this control law design itself are presented in this structure - direct sideforce, pointing, section. A discussion of the test ap- and translation. In all three standard proach used for the software is given modes, direct sideforce was commanded in section 5. via the rudder pedals. The relationship of decoupled modes to decoupled control The process used in obtaining the options is shown in figure 23. The dif- design is summarized in terms of the ferent control options were switched in supporting documents, the configuration

17 control process, the software support are given in Z-transform representa- tools used, and the implementation lan- tion. This level of detailed :infor- guage for the flight computers. The mation was required before sof .tware method and parameters used to track the design could begin. progress of software design are given, and a brief description of the struc- An overview of the software design ture and content of the software design process is shown in figure 28. It shows is presented. the software development activity from design to release of the software to the 4.3.1 Software Development Process test team. Depending on the type of error or redesign required, the mechani- The process used to develop the DFCS zation document (not shown) would also software was based on MIL-STD-483 (U.S. be updated. Department of Defense, 1985a) and MIL- STD-490 (U.S. Department of Defense, The FLCC were programmed in assembly 1985b). Documentation included the com- language. The instruction set was sim- puter program development specification ple, having just over 80 instructions. (CPDS), computer program product speci- The program was controlled using jump fication (CPPS), and an assortment of and skip instructions. Only three jump test plans and procedures. instructions were available, with all conditional control (for example, less The complexity of the DFCS, coupled than, equal to zero) being achieved by with the need to state clearly the func- the use of the 24 skip instructions. tional design requirements, control The instruction set was unique and did laws, fault-tolerant design, and timing not represent any standard microproc- constraints, resulted in an additional essor instruction sets. All calcula- document. The software mechanization tions were done in single or double document, not required by military precision fixed-point formats. The standards, provided the interface be- programmer can enable a unique hardware tween the system designers and the soft- function called saturation arithmetic. ware development team. In addition to This did not allow overflows to occur describing the seven top-level software but saturated the value at its maximum structures (fig. 26 1, the document in- scaled limit. cluded a section on the software needed to test the DFCS and a description of The first milestone in developing the hardware. the software was the critical design review. The purpose of this design A few examples will help one under- review was to show how the functional stand the role this document played in system design for the control laws and software development. Table 14 shows fault-tolerant design were to be imple- the detail provided in the mechanization mented. However, an iterative cycle document for describing the selection developed as the functional system and monitoring of analog input signals design was implemented into the soft- when all three inputs are valid. Infor- ware. Real-time and memory constraints mation is provided for all nine failure of the software implementation forced conditions, how to increment or decre- changes in the functional system design. ment persistence counters, and which Changes of the fault-tolerant design in signal selection to use. Figure 27 the areas of the output selector moni- shows the software mechanization for tor and the ISA fault detection were a typical control law module from over required. All totaled, a 4-month sche- 50 such modules. Note that filters

18 I i

dule slip was incurred before the criti- required to update it. The first com- II cal design review could be held. plete CPPS was released at the critical design review and required eight 3-in. i A schedule showing the critical path binders. The next complete release I for the software development first of the CPPS was not available until appeared at the critical design review. 2 years later. The percentage completed and the scheduled date for completion were given for The software mechanization document i (1) software mechanization, (2) software was required. It helped the designers design, (3) software code, (4) integra- and users to understand the design. The I tion with hardware, (5) unit and module mechanization document used a combina- I test, (6) stand-alone verification, and tion of English, if-then-else psuedo I (7)integrated system validation. language, tables, and graphs. Like Software real-time and memory use were the CPPS, the requirements in the mech- a Is0 tracked. anization document used no formal method to determine their completeness or cor- 4.3.2 Software Design rectness; that was the job of the I design reviews. A top-down structured approach was used for the software. The highest 1 software structure was the computer pro- 5 SYSTEM-SOFTWARE QUALIFICATION AND gram component, followed by the module DESIGN ITERATIONS and the unit (fig. 29). The data base i was also a structured design (fig. 30). I I Most of the software components - sys- The qualification of the design presented tem monitor, selector monitor, failure in section 4 is discussed in this sec- I I manager, start-up and restart, and AMUX tion. System-software qualification processor -provide the software por- refers to the testing of the design I tion of the fault-tolerant design (see following implementation. Errors or fig. 26). The remaining two software discrepancies found during test are components are the control laws and corrected with a new design and the the executive. cycle begins again.

The detailed software description Qualification of the DFCS as a sys- document required by the Air Force tem and the testing and redesign of the I U.S. is the computer program product specifi- software are emphasized. Qualification cation (CPPS), containing the software of the hardware in terms of environ- I design. It was used to translate the mental testing is not covered. The system design into a format appropriate methods and problems encountered when for the programming team. The CPPS, integrating functional requirements although essential for the software (such as control laws and fault toler- designers, was of little value to sys- ance 1 with the system architecture (such , tem designers and users. Even with the as asynchronous computers) are high- addition of the software mechanization lighted. The three areas discussed in I document, following a design requirement the preliminary design section - system I through the mechanization and CPPS docu- architecture, control laws, and fault I ments was difficult for technical mana- tolerance - all go through the qualifi- I gers and system users, and only a few cation and design iteration process. I talented engineers could track it. Since the major points deal with the I Another problem with the CPPS was its process as a whole rather than how it size and the arduous manual method applies to each of the three functional

19 1 areas, this section is structured in 5.1 Schedule terms of the qualification activities. Before discussing the qualification proc- An overview of the iterative process, a review of the schedule and the ess, design documentation updates, test- parameters tracked for the qualification ing performed, and environment for the task will be helpful. testing is shown in figure 31. The first verification test is performed by The schedule for qualifying the AFT1 the programming team and ensures that system is shown in figure 32. The re- the software is implemented per its de- lease of the software package, after sign specification. Configuration con- unit verification by the software devel- trol is maintained by the software team opment team, was scheduled for November at this design iteration level. The 1980, only 2 months after the critical second verification test is done by a design review. Verification by an inde- group independent of the software team, pendent test group was scheduled for using the mechanization document. This February 1981. System validation was is the first test with an entire soft- scheduled for completion by April 1981, ware package operating in a test en- with the first flight in July 1981. vironment with the triplex flight con- The qualification process required an trol hardware. Configuration control additional year to complete beyond the was handled by a board that included original schedule. disciplinary engineers - control law designers, fault-tolerant designers, and A history, taken from the program's hardware and software designers. This status reports for each of the three configuration control process was also qualification phases, is shown in fig- used to resolve system validation dis- ures 33, 34, 35. crepancies. The last iteration cycle results from validation testing, which The percentage of completion and the ensures that the system design is cor- predicted amount of schedule slip were 1 rect, not if the software follows the obtained from contractor status reports, specification. The system software is Software coding and unit test were the validated with all the flight control only tests to show 1 00-percent comple- hardware operating in real time, with tion. Software verification reached i an aerodynamic simulation. Special pro- 90-percent and system validation 30- I I visions to induce failures into the sys- percent completion in the last status 1 tem, such as sensor failures, are in- report which tracked them. All testing I I cluded for failure modes and effects did reach 100 percent at the actual com- ~ testing (FMET). A mockup of the cockpit pletion date shown on the figures. The with flight controllers and displays is original and actual completion date is used to support flying-quality evalua- shown for each test. Once the previous tions. Some validation testing requires testing was completed and its discrepan- the actual airframe. Structure coupling cies corrected, the next testing phase II and electromagnetic interference and began to succeed. compatibility (EMIC) were tested with i I the aircraft. Additional details on The primary issue regarding the I the system-software qualification can schedule was its optimism. The main 1 be found in Gordoa and others (1984). flaw in estimating the schedule was a 1 i I I I I

20 belief that once released from the soft- The term stand-alone testing was used by ware group, verification and validation the contractor because of the configura- testing of the software package would be tion of the DFCS. The DFCS stands alone completed nearly error free. The itera- from the avionics systems, cockpit tive nature of testing and redesign was interface, and the simulation, for not acknowledged. The iterative nature this testing. is shown by the number of software ver- sions released, 14, and the number of A general description of the verifi- mechanization change notices, over 600, cation test environment includes required to achieve a software release acceptable for first flight. 1 . Complete software package (including unique test software), Estimating schedules for software- driven systems of a research nature is 2. Triplex flight computers, and difficult. A few of the parameters that affect schedules include 3. Test support equipment.

1 . Systern complexity, 5 2 1 Verification Test Plan

2. Programming language and methods, A preliminary test plan was released in March 1980 for government review. 3. Development tools, After several review cycles and coordination meetings, the final plan was 4. Software program size, released in August 1980. The review cycle provided an excellent interchange 5. Staff experience, where the majority of government and contractor concerns were resolved. 6. !Pes ting requirements, and Contents of the verification test 7. Required documentation. plan section are shown in table 15. This test plan represented a thorough All the foregoing items will affect description of the purpose, the system the number of errors in the design and under test, qualification requirements, therefore the number of design itera- success criteria, test implementation, tions. For flight or life critical and configuration control. applications, testing must be thorough. Thorough testing of a design is time The purpose of verification testing consuming, testing multiple designs was to even more so. Documentation is a large effort and cannot be overlooked 1. Verify the software independent when determining schedules. of the software development group,

5.2 Software Verification 2. Detect errors in the software interface to the computer hardware, The methods and tools used for software verification after its release by the 3. Detect errors with the software software development team are dis- operating in a triplex hardware config- cussed in this section. Verification uration, and is defined as the testing performed to ensure the software is implemented with 4. Provide a solid software package respect to the mechanization document. to support system validation testing.

21 Although not an objective of verifi- 1. Provides two-way communications cation testing, system design errors between DFCS and other systems for data were found and corrected. input and output;

A separate verification document 2. Provides cross-linking of data contained detailed testing procedures from the receiving FLCC to the other used by the testers. This document was two ncc; formally published in October 1981. During this time, several preliminary 3. Allows data transfer over either software releases were made. Prelimi- AMUX A bus or AMUX B bus while retaining nary verification testing began in March data consistency; 1981 and went through October. This testing detected errors while allowing 4. Maintains information on current for the development of the test proce- data and location of the new data. dures used during formal verification. Nearly 150 discrepancies were found 5.2.3.2 Gain scheduler test. The and corrected during this prelimi- gain scheduler test verifies that all nary testing. scheduled gains (for all flight control modes) that are a function of slow- 5.2.2 Verification Support moving air data are computed 4 times Equipment per sec.

The support equipment used €or veri- Some gains are also a function of fication testing is shown in figure 36. aircraft configuration, that is, gear The primary equipment is the engineer- down. Testing €or these conditions was ing test support equipment (ETSE) test also included. Unlikely, but physically complex furnished with the flight com- possible conditions, such as negative puters. To provide improved test docu- static pressure, were also tested, I mentation and some automation of the uncovering some unique errors. 1 redundancy management testing process, test facilities were upgraded to allow 5.2.3.3 Control law frequency test. ~ for an ETSE real-time memory monitoring The control law frequency response test of the flight computers, and a redun- verifies that the open-loop response dancy management test signal generator provides the required system gain and i1 was implemented. An on-line capability phase margins. 1 for recording MIL-STD-1553 multiplex bus I data was also available. This test was actually a validation test and did not completely verify the 5.2.3 Verification Tests correctness of the code. Testing of I limiters, signal shapers, and logic I The 13 verification tests are listed conditions was not covered by this I in section 4 of the Test Plan, table 15. approach. Control law verification I became a test a The unique characteristics of each test issue as black box I are discussed briefly. approach was used rather than a detailed test of each control law function. This I 5.2.3.1 Avionics nultiplex bus data is discussed in section 8. I interface test. The avionics multiplex I bus (AMUX) data interface test verifies 5.2.3.4 Control mode selection and i that the software performs the follow- transition response test. This test ing functions: verifies the open-loop control mode

22 and submode switching and transition put commands to the dual LEF drive sys- response characteristics of the DFCS. tem in the presence of computational and electronic failures. Verification test- 5.2.3.5 Analog input selector and ing includes the corrective action, monitor test. This redundancy manage- fault recording and reporting functions ment test verifies the capability of the of failure management, and the capabil- DFCS to monitor and select the control ity to lock the LEF drive(s1 and failure law input data in the presence of single reset under appropriate conditions. and multiple input failures. Verifica- tion included that for fault analysis, 5.2.3.9 Long power outage test. fault recording and reporting, and re- This test verifies that the DFCS configuration and reset functions of restores the FLCC to normal operation failure management. A large portion after a long power outage (>50 msec). of the S/M testing was automated. 5.2.3.10 Short power outage test. 5.2.3.6 Discrete input selector This test verifies that the DFCS OFP monitor operation. This redundancy restores the FLCC to normal operation management test verifies the capability after a short power outage (<50 msec). of the DFCS to monitor and select discrete input data for control law com- 5.2.3.11 Memory and duty cycle putations in the presence of single and reserve test. This test verifies that dual input failures. Verification the software provides 30-percent memory includes handling of discrete input reserve and 25-percent duty cycle inconsistencies and the fault analysis, reserve. In addition, timing data were fault recording and reporting, and obtained with regard to completion of reconfiguration and reset functions of cyclic tasks and ISA subframe monitor- failure management. ing to determine the adequacy of frame reserve time and the software executive Simultaneous nose up and nose down scheduling of tasks. trim conditions are types of inconsistencies resolved by the software. 5.2.3.12 Built-in test. The built- in test (BIT) verifies that the DFCS 5.2.3.7 Integrated servoactuator provides the capability for verification test. This redundancy management test of system integrity (no hardware fail- verifies that the integrated servo- ures) prior to flight, and fault isola- actuator (ISA) subframe and frame cyclic tion to the line replaceable unit level monitors of the DFCS provide valid out- during maintenance operations. The orig- put commands to each of the primary air- inal approach to insert hardware failures frame control surfaces in the presence to test the BIT software was abandoned of computational and electronic drive owing to scheduling constraints. BIT failures. Verification testing includes was tested by patching the software to the corrective action, fault recording indicate failed conditions. and reporting functions of failure management. Tests also include verifica- 5.2.3.13 Flyable hardware retest. tion of ISA centering and failure reset Flyable hardware retesting was a major under appropriate conditions. issue during planning but became a moot point. Originally, the software, in 5.2.3.8 Leading edge flap test. following its schedule, was well ahead This redundancy management test verifies of the hardware development. It was that the leading edge flap (LEF) cyclic believed that only breadboarded com- monitor of the DFCS provides valid out- puters would be available for test-

23 ing. However, the DFCS software release ance is usually not specified to the slip allowed time for flyable hardware detail needed. In the stability and delivery. Testing on the flyable hard- control discipline, the performance is ware was the best approach and was specified with more detail than in other probably the only good result of the disciplines. For example, flying-quality software slip. criteria exist, such as the allowable time constant of the spiral mode. How- 5.2.4 Reverifying the Design ever, detailed criteria for other areas, Iterations such as the fault-tolerant design, is almost nonexistent. All aspects of the The tough question for verification system validation process, including is how much retesting is required to planning, test environment, and valida- verify that the change does only what tion test and retesting, are discussed it is supposed to do? Testing what a in this section. change is supposed to do is fairly straightforward, but how much addi- 5.3.1 Validation Test Plan tional testing of other software components is needed? The types of validation testing were spelled out in seven separate documents. AS mentioned earlier in section Some of the test plans were written by 5.2.1, preliminary verification began the DFCS test group, others by the simu- in March 1981 and formal verification lation group. The test plans were began in November 1981. From the start to end of formal verification, June 1982, 1. Integrated system testing of the 14 software releases were made, a rate DFCS software (DFCS test group), of nearly 2 per mo. Although the last releases had considerable testing, no 2. Controls and displays test plan I single release had every test run on it. (simulation), I

The approach for retesting the final 3. Flying-qualities test plan , release prior to flight test, and also (simulation), those releases during flight test, was to test each change made and then run 4. Failure modes and effects test a software acceptance test procedure plan (simulation), (ATP). Reverification procedures contained a variety of tests for each of 5. Flight control system ground i the software components (table 16). Two test plan (on aircraft tests), I other considerations are worth noting: I (1) structured and controlled coding 6. Electrical system test plan (on techniques help to reduce errors, and aircraft tests) , and (2) the follow-on system validation testing helped to detect errors caused 7. Electromagnetic compatibility 1I by redesign. test (on aircraft test) . I 5.3 System Validation The last three items are validation tests performed on the aircraft and are I The system validation test demonstrates listed for completeness. They will not that the system, as a whole, performs as all be addressed in detail. Flight test i expected in the user's environment. For is the final validation test and is cov- I the most part the desired system perform- ered in section 7. I

I The test planning effort was useful. wind-tunnel tests and also with F-16 In many cases the testing and test docu- flight-test data. ments required by the U.S. Air Force were redundant, and owing to a general Maximizing use of the real avionics misunderstanding of what validation subsystems helped to provide the actual testing is, many duplicate tests were environment. Using the avionics hard- created. This duplication occurred ware also provided an opportunity to re- most often in areas least understood, solve the subsystem interfacing problems such as the fault-tolerant design. The that occur during validation testing. test planning effort helped to reduce the overlap in testing. It provided an 5 .3 .3 Validation tests excellent interchange between the government and contractor. A detailed look at the validation tests performed on the DFCS is under- 5.3.2 Support Equipment taken in this section. Areas of overlap and secondary benefits from the testing The validation test support equip- are discussed. ment includes all the equipment used for verification testing. Additional test 5.3.3.1 Integrated system testing equipment included the aircraft simula- of the DFCS software. Integrated system tion, visual system, and the avionics testing, which included testing of more interface (fig. 37). than just the software, was handled by the flight control system test team. The aircraft simulator was comprised The tests are shown in table 17. A of digital models for the aircraft's brief description of the goal for each aerodynamic characteristics, an engine test follows. model, and models of the actuators. The actuators were also modeled using analog The BIT validated that the DFCS pro- circuitry; these analog models were usu- vided the capability for verification of ally used during testing. system integrity (no hardware failures) prior to flight and fault isolation to The primary visual display was a 4- the LRU level during maintenance opera- by 4-ft projected display. The display tions. The verification test consisted and mock-up cockpit were housed in an of loading software drivers that made 18-ft dome structure. Visual displays BIT think hardware failures occurred. for air to air, air to ground, and take The validation test for BIT consisted off and landing task were available. of running it prior to each day's opera- The air-to-air target could be set up tions. This only validated BIT to the with several preplanned maneuvers. The extent that BIT did not falsely detect avionics equipment included an FCC, SMS, errors and correctly detected the few and PDG used to provide multipurpose failures which did occur. BIT is dis- display information in the cockpit. cussed further in section 7.

Since validation testing is designed The mode selection and display test to show proper system operation, the validated the DFCS, FCC, SMS, AMUX and environment in which the system is used MPD interfaces required for pilot mode must be modeled in detail. The aero- selection and display. Additionally, dynamic model used is based on the F-16 the test validated the pilot's capabil- wind-tunnel data which was improved with ity to communicate with the DFCS through canard and dorsal fairing effects from the MPD and applicable cockpit switches.

25 This testing addressed controls and The analog dual-like failure toler- displays in detail- one area where ance test validated that the DFCS pro- testing overlapped - in the simula- vided safe recovery and landing capabil- tion test plan. ity from dual-like analog input sensor failures during high-performance maneu- The control law frequency response vers. The test also validated the test validated that the DFCS provided capability of the pilot to reset tran- satisfactory closed-loop frequency sient failures that did not persist be- response characteristics. The test pro- yond seven iterations and that he was vided validation of closed-loop phase unable to reset permanent failures. A and gain margins. A frequency generator landing in the applicable reconfigured and X-Y plotter were used. The phase mode was included. and gain margins were read from the X-Y plots generated.

The step response test validated that the DFCS control laws and executive control of tasks provided satisfactory multimode transient response characteristics, owing to pilot controller inputs at 1-g and trimmed elevated-g conditions over the entire flight envelope. The tests included switching transient tests from standard to decoupled modes and vice versa. Test inputs for the pilot controllers were computer generated with the aircraft response compared to results obtained by the batch simulation. The batch simulation I used independently modeled control laws. under appropriate conditions and land The flight scenario test validated the aircraft safely. that the DFCS provided satisfactory control law performance during takeoff, climb, acceleration, and landing conditions. The test profiles were performed with and without stores, drag modulation, and optimum flap schedule. This type of testing was also covered in the flying-qualities simulation tests. I The analog input, single failure tolerance test validated the ability of the DFCS to maintain full operational capability during transient and latched single failures of analog inputs. This test also validated the ability of the pilot to reset failures, and that the resultant failure and failure reset transients were within acceptable levels.

26 performed at flight conditions as close faces closed loop. This test was run to the 1-9 flight envelope boundaries as for each control mode at a flight con- possible (fig. 38). Phase 2 consisted dition of Mach 0.9 and sea level. of performing coupled pitch-roll-yaw Pass-fail criteria were based on those maneuvers while flying a high- speed obtained from linear analysis. Gain loop which encompassed the entire Mach- increases were made by increasing sur- altitude range of the vehicle (fig. 39). face effectiveness in the simulation. In phase 3, several landings and take- offs were made under extreme conditions. 5.3.3.2 Controls and displays Phase 4 consisted of a sequence of HUD validation. The controls and displays mission phase switch closures executed test is a simulation test developed in in a rapid manner at one flight condi- part by the human factors engineers. tion while the vehicle was being exter- Four tests were performed with project nally forced in all three axes by a pilots to evaluate the cockpit control- sinusoid stick input. lers and displays.

The power outage-restart test vali- The interior lighting evaluation dated that the software restored the test was the first test conducted as FLCCs to normal operation after a short part of the controls and displays test. power outage and a long power outage. The objective of this test was to deter- This testing is also addressed in FMET. mine how well the MPDs, HUD, and mis- The objectives of the test also included sion phase lights meet operational the following: requirements under various levels of ambient illumination. 1. FLCC without power is voted off- line. A qualitative assessment of the utility of the MPDs, HUD, and mis- 2. IBU is automatically engaged sion phase lights was made by the when all three FLCCs incur a simul- pilots for high and low levels of taneous power outage. ambient illumination.

3. Pilot can reset a failed FLCC The controls test had the pilots after power is resumed. perform a single-axis tracking task of an air-to-air target with a fixed pipper 4. In case of power failures in using a single controller, either the two FLCCs, the remaining FLCC controls twist throttle, rudder pedals, or side the aircraft. stick controller. They were required to fly the fixed reticle on the head-up 5. Correct fault recording in non- display to the target represented by the volitive memory and annunciation on MPD target designator box, also on the head- is achieved. up display. The duration of each trial was 30 seconds, and five trails were run 6. Manual engagement of IBU for each of the flight control modes. is permitted. This test concentrated on the human factors aspects of the cockpit controllers The control law gain margin test rather than the aircraft's flying quali- validated that the DFCS provided the ties data discussed earlier. required gain margin with the flap, elevator, and rudder loops individually The head-up display (HUD) is the open at the actuator and the other sur- pilot's primary flight instrument. The

27 AFTI's HUD is an improved version over 8. Mission phase selection the F-16 fleet. The field of view (dis- and status, play size) was larger and included system status information in addition to 9. Warnings, aircraft state displays (altitude, heading, and airspeed). The HUD sym- 10. Threat warning enunciation bology displayed changes as a function and display, of aircraft mission and subsystem modes. 11. Pitch limit operation, con- The HUD symbology was evaluated by trol, and display, each of the program pilots by flying seven different flight-mission phases 12. CCV engagement, disengage- in both coupled and decoupled modes. ment, and display, The different flight-mission phases and flight control modes provided the 13. Manual pitch override opera- conditions for using or viewing the tion procedure, and various HUD symbologies. 14. IBU status, manual and automatic The objective of the integrated engagement, and manual disengagement. cockpit test was to validate the cockpit design in a dynamic situation. 5.3.3.3 Flying qualities. Before This task was structured to analyze discussing the flying-qualities valida- the pilot's ability to maintain spe- tion test, it is worth reviewing the cific flight parameters and complete history of this testing as used in the various mission related tasks. The AFT1 development. Note, that this vali- following aspects of the pilot-vehicle dation test was used not only at the end interface were examined: of the development, but throughout the development, allowing early detection of I 1. Logic, legibility and operation design errors as shown by poor flying of the MPDs, qualities. The flying qualities validation test is documented in more detail 1 2. Pilot manual and visual access in Anderson and Frank (1 984). to cockpit controls and displays, Three flying-qualities demonstra- 3. Side stick as a controller for tions were held before the final valida- coupled and decoupled flight, tion test. These demonstrations were requested by the flight test team before 4. Linear throttle as a thrust each major program review. The control

I controller, laws evaluated were modeled in FORTRAN and run with the digitally modeled air- 5. Throttle movement for cross craft dynamics. Visual displays and a coupling with the decoupled flight mock-up cockpit were part of the simula- control system, tion. An example of the type of tasks and the modes evaluated is shown in 6. Switches on the stick and table 18. throttle for cross coupling with the flight modes, The first two prevalidation tests allowed for the early detection of de- 7. Trim controls on the flight sign errors. Since the test environ- control panel,

28 ment did not include DFCS hardware and 2. Demonstrates satisfactory -y- software, the tests cannot be classi- ing qualities in the task tailored modes fied as true system validation tests. (SAAG, SASG, SASB), However, the following benefits must be recognized: 3. Demonstrates satisfactory flying qualities in the decoupled modes 1. Early detection of design errors (DNRM, DAAG, DASG, DASB), provides an improved product, perhaps at a lower cost; 4. Determines that no deficiencies in flying qualities or handling quali- 2. Provides critical user and ties limit flight safety or the capabil- flight test pilot feedback to ity to perform the intended missions, designers; and 5. Develops flight test predic- 3. Provides visibility into control tion data, law design for all program participants. 6. Examines DFCS modes and flight Also, because of the test environment conditions that will not be flight and the inherent limitations of flight tested but could be entered by improper simulations, some pitfalls must be pilot mode selection, recognized and avoided, including the following: 7. Determines the level of resistance to departures from con- 1. Modeling errors can give indi- trolled flight, cations of design errors which do not actually exist. Control law modifica- 8. Demonstrates proper operation tions to correct these phantom errors of angle of attack and g-limiter, can adversely affect flight test. Exam- ples include time delays, both real sys- 9. Determines maneuver limit bound- tem displays and those perceived by the aries if required to prevent unwanted pilot because of display cues, and the departures from controlled flight, lack of nonlinearities, such as those in the actuation system. 10. Demonstrates satisfactory flying qualities in the reconfiguration 2. As a pilot evaluation without modes, and the safety implications and stress sit- uations of actual flight, certain tasks, 11. Demonstrates satisfactory fly- such as landing, may not provide cre- ing qualities in IBU mode. dible results. The specific items evaluated were The third flying-qualities valida- derived from the system specification tion test was held before the flight and include static stability, stick readiness review. This flying-qualities forces, turn coordination, control test used flight hardware and completely harmony, and stall characteristics. verified software. The flying qualities A total of 40 flying-quality require- test is summarized as follows: ments were identified.

1. Evaluates flying qualities in Six general test types were used to SNRM mode, evaluate the flying qualities:

29 1. Preliminary mode checkout flight. Any flight tested in other consisting of doublet, rolls, and modes would have required retest after a windup turn. the problems were corrected.

2. Stability and control tests, 2. Flat turn performance was including maneuvers mentioned above slightly impure, in other words the in item (l), were done at trimmed for sideslips were not zero. level flight and elevated load factor; decoupled control inputs were included. 3. Pitch maneuvering response Other tests are mode switching, decou- was sluggish. pled control limits, splits, and handling qualities during tracking. Two 4. Elevator rate-limit cycling mission tasks of air-to-surface gun occurred in decoupled normal mode. tracking and air-to-surface bombing were performed. 5. The IBU and all reconfiguration modes except pitch rate reconfiguration 3. High angle-of-attack testing mode were accepted for flight test. The validated the flight control system fault-tolerant design was sensitive to at high angles of attack, loo to 30°. the pitch rate reconf iguration transi- Doublets, rolls, and mode switching tion. On occasion, depending on compu- are some of the maneuvers. ter skews and aircraft state, the digital system would fail to the IBU during 4. A special section was dedicated the transition to pitch rate reconfigu- to testing the flying qualities of the ration mode. As the IBU needs pitch analog backup unit. rate feedback to control the aircraft, this failure sequence would result in 5. The approach of handling dual loss of the aircraft. This was the only (complete) loss of an aircraft feed- problem corrected before flight test. back sensor such as pitch rate, by use of reconfiguring the control laws, 5.3.3.4 Failure modes and effects was evaluated. testing (FMET). FMET validates the fault-tolerant design to a level defined 6. The final set of tests evaluated by the type of failures induced and the the control system outside the design extent to which the system response is envelope of a given mode. This test measured. To define an optimum set of was performed because certain modes, test cases, FMET requires a functional mainly the decoupled modes, had oper- breakdown of the DFCS and of the soft- ational envelopes which were smaller ware fault-detection system. FMET is than other modes. Inadvertent pilot performed on the simulator to provide action could result in operation out- the environment that best approximates side a design envelope. flight. In addition to providing essential engineering knowledge, FMET fur- The results of the flying-qualities nishes information on failure effects test are summarized as follows: and interactions, failure transients, and flying qualities of degraded modes, 1. The flying qualities of all the as well as providing pilot experience flight control modes were satisfactory in fault isolation and the use of emer- except for the following items. Because gency procedures. of problems in the advanced modes, only the SNRM was available for the first

30 Because a major objective of the Part of the problem was determining what AFTI program was to provide a dual-fail the correct system response should be. operate capability, FMET required a This was partially owing to the lack of matrix of single and dual failures. The detailed validation requirements. How- matrix is composed of first and second ever, the major problem results from the failures of the components listed in nature of integrated validation testing. table 19. A list of each failure type, This is the first opportunity for the the failure mode, and its effect is fault-tolerant design, the system archi- shown in table 20. A matrix of nearly tecture (asynchronous computers), and 1000 failure combinations would be nec- the control law design to operate as essary to test every dual failure. For one system. This integration testing this type of testing, a reduction of the detected numerous design errors as the failure matrix required careful consid- separately developed components were eration of the objectives. A primary required to operate together. purpose of FMET was to show that the I expected results of a failure are cor- A few of the major discrepancies rect; hence any compromise in the fail- that were identified during the AFTI ure matrix compromises the ability to F-16 FMET and resulted in modifications ensure safe and proper operation fol- to the flight control system included lowing failures. the following:

FMET was performed in two stages - 1. Power failures of a single com- (1) evaluation test and (2) demonstra- puter channel resulted in a complete tion test. Evaluation test covered all loss of the triplex digital system and the tests identified by an "X" in the transfer to the analog backup; dual failure matrix (fig. 40). The three additional tests identified in 2. A dual failure of pitch rate table 19 were added at a later date. information while in power approach An evaluation test was performed by resulted in an uncontrollable pitch- the contractor, and testing did not down motion; include government participation. The demonstration test was accom- 3. Single failures of an analog-to- plished using government pilots and digital converter resulted in the loss engineering support. of the triplex digital system and rever- sion to the analog backup system. Unlike flying qualities, the detail requirements for the fault-tolerant All totaled, over 40 discrepancies design were not specified in early docu- were identified during the 5-mo period ments. Though 40 specific flying- in which FMET took place. As can be qualities requirements were given in the seen, failure modes and effects analysis system specification, only one fault- is no substitute for failure modes and tolerant design requirement was given. effects testing. The complex interac- It was expressed as (1) dual fail oper- tions created between hardware elements ate and (2) loss of control probability because of software actions could only of 1 x lom7 in a 1-hr flight. be found with the actual hardware and software systems. Completing the FMET demonstration required two attempts. The first 5.3.3.5 On-aircraft testing. attempt at the FMET demonstration was Several on-aircraf t tests were per- not successful because the DFCS'S formed to validate that the flight response to failures was incorrect. control system operated properly.

31 Besides the installation and structural mode test was performed to functional tests, three special uncover any flight control-structural tests included coupling. The test identified a pitch axis resonance in the 100 rad/sec range. 1. Structural coupling, A correction to the software (control law design) solved the problem using a 2. Electromagnetic interference- complex double notch filter. Subsequent compatibility, and testing just prior to first flight found no discrepancies. 3. Gunfire tests. 5.3.3.7 Electromagnetic interf er All tests were performed using the ence and compatibility (EMIC). The EMIC airframe with the flight control and test was performed just prior to flight avionics systems operating. A brief test. The test was extensive, requiring description and the results of each several weeks to complete. All elec- test follow. tronic devices were installed and operational for the test. The test ensured 5.3.3.6 Structural coupling. The that a given electronic component's structural coupling test was -performed operation did not adversely affect ano- to show that the response of the flight ther's operation. Both interference control sensors to structural vibra- of, and compatibility between, compo- tion does not form a sustained closed- nents were tested. Tests were run loop oscillation. using ground power, main generators, and the emergency power unit. A diagram of the test setup is shown in figure 41. Both open-loop All tests were completed success- and closed-loop tests were performed. fully. No changes were required before flight operations. The open-loop test was a frequency response test with the flight control 5.3.3.8 Gunfire test A requirement system command to the actuator discon- to fire the gun during flight test led nected. The actuator was driven with to a ground gunfire with the flight con- an external frequency sweep and the trol system operational. There was a flight control actuator command was then concern that the vibration environment recorded. The input and output com- generated by the gunfire, coupled with mands were then compared and plotted asynchronous sampling and high-feedback as a function of frequency. A mini- gains, would result in failure declara- mum 6-dB gain margin was required. tions. To test the highest gain conditions required an extensive test setup The closed-loop configuration was to get the correct flight control mode tested by inserting a variable gain be- and air data conditions (Mach number tween the DFCS and the actuators. The and altitude). gain was slowly increased, with step impulses given to each actuator. The The test results confirmed the fears response to each impulse was measured of the previously described interactions to determine frequency and damping. A between the gun firing and flight con- 100-percent increase in gain was made trol system. The lateral acceleration for each axis to verify gain margins. feedback path to the rudder command was the culprit causing a computer failure Once a complete DFCS software indication after several successful gun- release was available, a preliminary fire bursts. The high frequency, large-

32 scale motions of the rudder command dif- standards and tools for achieving and fered in the three computers. This dif- measuring completeness. ference was owing to errors introduced in the asynchronous sampling of the lat- In the introduction to the valida- eral accelerometers. The three lateral tion section, validation testing was accelerometers and rudder commands, be- described as testing to see that the fore and after the software fix, are system as a whole performs as expected. shown in figure 42. A reduction in The completeness issue can be viewed in feedback gain corrected the problem terms of the completeness of the sys- with no effect on flying qualities. tem specification and how well testing ensures proper operation to that speci- 5.3.4 Revalidation of Designs fication. This issue applies to both the software for verification and the The types of validation testing are system for validation. wide ranging and the retesting must be designed to cover as many of the speci- The cost associated with verifica- fic areas as possible in each test. tion and validation is the cost of both Validation retesting must show that people and tools to perform the job. corrections to deficiencies do not The tools needed to perform the test and I adversely affect other operations. model the flight environment are costly, The seven specific tests performed especially for validation. The simula- to revalidate the system are shown tion is a primary cost. Secondly, the in table 21. Test number six is a people cost is high because all the pre- good example where flying qualities, vious activities required to design and failure modes, and pilot-vehicle implement a change are needed to correct interface are combined in one test. discrepancies. All life-cycle operations must be repeated (see fig. 31), The revalidation testing was done increasing cost. This is a rather well- in addition to tests which specifically known and published fact (Brooks, 1979). validate a given change. The revalida- Two suggestions to reduce the cost of tion tests were termed acceptance test verification and validation are procedures. The tests were performed prior to first flight and after each new 1. To improve the requirement, software release during flight test. design, and test methodology to identify and correct errors as early as possible 5.4 Qualification Issues in the design phase, and

The issues involved with system valida- 2. To provide an information tool tion are similar to those of verifica- to the designers and testers which can tion. This isn't surprising in that improve the understanding of the design. both are testing the implementation of See section 8 for further discussions on a design, one for the software and one this topic. for the system, and both are for an aircraft. The two main issues for system verification and validation are com- 6 CONFIGURATION CONTROL pleteness and cost.

Completeness is the primary issue of The design of any life-critical system verification and validation because it requires a method for resolving discrep- has a direct effect on safety and cost. ancies and controlling system configu- Currently there is a serious lack of ration. Configuration control can be

33 defined as knowing what you have and New requirements enter the change proc- when you have it. A good configuration ess in much the same manner as discrep- control process for ensuring safety ancies and follow the same configura- should contain tion control process. Most of the new requirements on the AFT1 F-16 system 1. Visibility of changes across all were classified as improvements. These involved engineering disciplines, improvements came in the latter stages of system development and were intended 2. Identification of the impacts of to reduce requirements €or computer mem- a change on requalification, including ory and real time. designed-in testability needed for the changes, 7 FLIGHT TEST 3. Identification of the effects of a change on system performance and limitations, and Flight test assessed the decoupled flight control, integrated pilot vehi- 4. Identification of the effects of cle interface, and to a lesser extent a change on operational characteristics the dual-fail-operate capability of the and procedures. triplex system. It also provided an assessment of the method and tools used The general flow of the configura- to develop and qualify the DFCS design. tion control process is shown in figure 43. Discrepancy reports, which For example, the yaw departure of 1 contribute most significantly to con- flight 36 and the resulting data iden-

figuration changes, are written any time tifying a single failure, which could I the system does not perform as expected result in the triplex system failing to I

or fails to meet a specification. The the analog backup, are both instances I cause of the discrepancy is classified where the qualification methods for the as hardware, software, or system fail- flight control law and fault-tolerant ure (hardware and software combination). design failed. The report identifies the discrepancy, gives the cause and any possible methods It is natural to expect difficulties !I of working around the problem, and de- when pushing the state-of-the-art in a ( tails any system limits or operational flight research program. However, it I impacts. The discrepancy report can is also necessary to understand how only be resolved when a satisfactory the methods can be improved so that the ! fix is implemented, documented, risks involved in future flight research I and retested. can be minimized. I I Changes are controlled through the The results are broken into five 1 configuration control board, which pro- sections - General, Fault-Tolerant De- vides the forum for disciplinary and sign, Control Laws, Software, and Hard- flight test engineers to discuss the ware. The results of flight test with changes and their impacts, identify regard to the program's goals are sum- I retest requirements, and determine marized in the General section that I the effect on operational procedures. follows. Considerable published data I can be found on this and is included I Aside from discrepancy reports, con- in Ford and others (19841, Ishmael and I figuration changes arise from new soft- others ( 1 984 1, Joyner ( 1 983 1, and ware, hardware, or system requirements. Mackall ( 1983). I

I Both ground and flight operations system during flight test. Software are discussed in the Fault-Tolerant De- changes were made to correct discrep- sign section. Lessons learned and a ancies and to provide improvements in unique flight test discrepancy are sum- flying qualities, fault-tolerant opera- marized in the Control Laws section. tion, and structural-load-limit items. An efficient software change process was The hardware and software represent required to provide safe, timely changes the medium in which the fault-tolerant needed to meet flight test objectives. design and control laws are implemented. The Hardware and Software sections will The specification for the probabil- address the failures and errors which ity of loss of control for the AFTI F-16 occurred in both areas and the implica- was 1 x per flight hr. This spec- tions to system reliability. ification addressed only hardware reliability, not software reliability, 1 7.1 General and assumed accurate detection of fail-

1 ures. The fact that there were no con- 1 Flight test results with regard to the firmed flight control computer hardware program's goals are summarized in this failures indicated an excellent reli- section. Program goals were to demon- ability rate based on the number of 1 strate and evaluate the following: flights completed.

1. A dual-fail-operate, triplex Avionics and the flight control i digital flight control system, system were integrated satisfactorily. However, one failure occurred to a crit- if 2. Task-tailored nhltimode control, ical nonredundant avionics system which adversely affected DFCS operation (see I 3. Decoupled control, section 7.2).

I 4. Integration of flight control Built-in test is a highly automated and avionics, and test sequence that ensures the digital flight control system is free of hard- 5. Pilot vehicle interface improve- ware failures prior to takeoff. The BIT ment of multipurpose displays, head-up is run prior to each flight and takes approximately 2.5 min. Two failures of the hardware were detected by BIT during preflight testing. The first was a failure of a surface actuator, and the second involved memory chips which didn't meet timing specifications at cooler temperatures. Nuisance failures of BIT occurred a number of times. The cause was believed to be due to electro- attack, flight at Mach numbers up to magnetic interference. 1.2, combat mission evaluations of decoupled control, and structural load Faults were detected in-flight by comparing the three channels' values for tracking across the different channels. The only real failure was an input signal which was traced to a pushed- back pin in the aircraft wiring. Fif- teen false failures occurred owing to

35 design deficiencies rather than actual thermore, the relaxed static stability hardware failures (table 22). The de- characteristic requires a certain level sign deficiencies caused both temporary of augmentation. The simplified rever- (resettable) and permanent loss of sion mode used on AFTI provided get-home flight control redundancy. These design capability and level two flying quali- deficiencies resulted from the coupling ties for landing as specified. However, of unique computer skews with character- simulation and flight test indicated a istics of the flight environment, such more capable IBU is needed to cover as sensor noise. Undetected during transitions at the envelope extremes qualification, these in-flight failures possible to reach with the digital con- resulted in envelope and flight control trol system (Ishmael and others, 1984). mode limitations until they were corrected by software changes. The flight test results for the control laws and flying qualities are sum- The asynchronous computer architec- marized in the following paragraphs with ture affected a wide range of develop- additional information available in Ford mental activities including design, and others (1984). software-system qualification, and flight test operations. The DFCS qual- A primary objective of the AFTI F-16 ification was complicated by the depen- program was the evaluation of a multi- dence of failure modes on computer skew. mode, task-tailored digital flight con- Testing at predetermined worst case com- trol system with decoupled aircraft puter skew improved testing results; control. The six different decoupled however, some deficiencies still escaped options and right-hand control options detection. Ground operations during were evaluated with’ the decoupled fea- aircraft preflight were also impacted by ture best suited for a given task being the asynchronous computer architecture. identified. The task-tailored approach The most common problem was DFCS fail- provided improved handling qualities for ure, requiring reset by the pilot or the tasks evaluated. cycling of aircraft electrical power. The AFTI F-16 control laws that The 13 flight test software re- showed the most improvement relative to leases, in which design, coding, and the production F-16 were all pitch rate test were performed at General Dynamics, command systems. In all cases this Fort worth, supported the needed changes control law structure was demonstrated of flight test. The first four releases to have good open-loop stability charac- provided full envelope capability for teristics, good dynamic response charac- the AFTI vehicle in all flight control teristics, and an attitude hold feature modes. The remaining nine releases mod- (auto-trim) that reduced pilot workload. ified the control laws to improve flying qualities and provided corrections to The adaptive control law, which used the fault-detection design deficiencies. pitch rate error to optimize performance for gross acquisition and fine tracking, Although the IBU was never engaged was shown to be the best option for the as a result of a digital system failure, air-to-air combat task. The adaptive flight test experience indicates that gain control law was implemented using IBUs are needed. The complexity of the the right-hand controller; decoupled IBU became a primary issue; a simple IBU pointing with the pedals and twist grip could not provide protection at envelope showed no significant improvement for extremes which are possible to reach the air-to-air task. with the primary digital system. Fur-

36 .

I I I I The best features for the air-to- electrical system resulting in flight I ground task were improved flight path control operation on batteries con- stability and ride smoothness in tur- cludes this section. I bulence in the pitch axis. Direct side- I force or flat turn, which is commanded 7.2.1.1 Anomaly of flight 15. The through the rudder pedals, improved the stores management system (SMS) sends task and reduced pilot workload for pilot requests for mode changes to the obtaining lateral axis solutions. DFCS via the avionics multiplex bus I (fig. 13). A failure of the SMS - it Problems with roll ratcheting is not known whether in the hardware or affected all the modes except stand- software - resulted in DFCS mode change t ard normal. Prefilter tuning was not requests at 50 times per sec. The DFCS sufficient to resolve completely the responded at a rate of 5 mode changes ratcheting problem. per sec. The pilot was not maneuvering at the time of the failure. The standard normal mode improved I I the pilot's workload for the power The rapid mode changes were iden- approach task. Using more of a pitch tified in the ground control room and rate command system rather than the the SMS was powered off by the pilot, i normal acceleration command system on stopping the mode changes. The pilot the production F-16s, improvements in commented that the aircraft felt like flight path and angle-of-attack stabil- it was in rough air, owing to the dif- ity were made. ferent surface trim positions corre- I sponding to the various flight control I 7.2 Fault-Tolerant Design modes. The flight was aborted and the I aircraft landed safely. The in-flight, preflight BIT, and ground test anomalies of the fault-tolerant Analysis of the anomaly was con- design are discussed in this section. ducted using the DFCS hardware in the loop simulation. Results of the in- 7 .2.1 In-Flight Experience vestigation indicated that if the pilot had been manuvering, a com- The flight test results for the plete failure of the DFCS to the fault-tolerant aspects of the DFCS are analog back-up would have occurred. I summarized in table 22. The cause "sys- Maneuvering would increase the dif- tem integration" indicates that the ference between surface positions for 1 failure was caused by a design oversight the control modes. The difference which was discovered when separately would be interpreted as a failure. I designed systems were required to work together. For example, in most of the Flight test continued after a I cases where the correction was to vote software modification was made to I software switches, the cause was owing improve the DFCS's immunity to this I to the integration of asynchronous com- failure mode. puters, control laws, and the fault- tolerant design. 7.2.1.2 Anomaly of flight 44. I I Prior to flight 44, three occurrences of The most critical anomalies occurred failure indications for a single branch I on flights 15 and 44 and are summarized had occurred (flights 23 and 28 of table below. The anomaly involving a roll 22). Concerns that random computer skew axis software switch is also dis- between the three computers would lead cussed. A design oversite in the to multiple channel failures had been

37 accepted as an allowable risk. On decoupling and was based on the size of flight 44, a control law software roll stick and rudder pedal commands. switching mechanization coupled with unique flight conditions to produce a To correct the problem, a software divergence of output commands in the change was made. The software switch three computer channels. The diver- action was voted to ensure that all gence resulted in what appeared to be channels had the same switch position dual, simultaneous computer failures. and control paths. Extensive simula- The failures were caused by slightly tion testing was performed to show that different air data valves in the three the voting of the switch kept the con- channels initializing integrators with trol paths the same in all channels. different values. This caused output All software coding and simulation command divergence between channels. testing was passed successfully, indi- The fault detection logic was such that cating that the voting of the switch each channel of the DFCS declared the action was correct. other two channels as failed. In this situation the design was supposed to The first flight test attempt to result in the analog back-up mode, how- repeat the test point, which had induced ever this did not occur. Another design this failure, resulted in another fail- oversight in the redundancy management ure indication. Analysis of the repeat software kept the analog back-up from anomaly found that although the switch being selected automatically. Dual action was voted, the old, unvoted value simultaneous failures had been ruled was still being used to control switch out as not possible, therefore the position. An error in the software i design did not account for them. The coding had occurred and passed through 1 system could not be reset by the pilot, the verification and validation testing. I even though no actual hardware failure This was the only case of a software had occurred. The aircraft was safely error being found in flight. landed with only one of the DFCS channels controlling the aircraft. When the exact conditions which identified the design oversight were 7.2.1.3 Anomaly of the roll axis known, the random nature of asynchronous so€tware switch. Another example from operation, coupled with lack of modeling flight test illustrates how the asyn- for sensor noise, allowed the error to chronous system design and the lack of pass testing undetected. This example modeling sensor noise during the test- graphically shows why the failure indi- 1 ing phase can affect flight test opera- cations of table 22 occurred. It is tions. A failure indication in flight easy to see why some design errors I was traced to a software switch in the passed through testing and were only I roll axis command path. The software found during flight test. Prior to a switches controlled the paths through failure, the exact flight conditions and the control laws. If a switch was to aircraft configuration which uncover a change condition in one channel and not design flaw are not known. the others, an output miscompare would be detected and perceived as a hardware 7.2.1.4 The electrical system anom- failure. A schematic of the software aly. This in-flight anomaly gives an 1 switch, a function of note N, is shown example of a design oversight which sur- in figure 45. The note N logic con- faced in the electrical system. The I 1 ditions are fairly complex and are not in-flight anomaly caused the flight I shown. Note N logic controlled a for- control system to operate off battery i power, although no actual electrical I ward integrator used for steady state I I system failure had occurred. The mis- PMG, and the overvoltage protection sion was aborted with the aircraft relays caused primary electrical system I landing safely. disconnect. Although all the components were operating within their specifica- As discussed in section 4.1.6, the tions, it required the unique condition AFT1 electrical system included over- of EPU.operation at high engine rpm to voltage detection relays to protect the reveal the design oversight. flight control system from overvoltage failures of the emergency generator. 7.2.2 Ground Experience Figure 18 shows the electrical system schematic. The overvoltage detectors Problems encountered during ground monitor both essential dc busses and the operations were associated with two output of the emergency converter. The separate operating modes. First is emergency converter provides power to the BIT operation, and second is the the flight control system in case of memory mode operation. The BIT and power loss from (1) the main generator, memory mode operations are described (2) the emergency generator, and (3) in section 4.1.8, both batteries. The emergency converter derives its power from the permanent 7.2.2.1 Built-in tests. The BIT magnet generator (PMG), a portion of the operational experiences are summarized emergency generator. The PMG will pro- in tables 23, 24, and 25. vide a small amount of power for certain classes of emergency generator failures. The BIT detected four actual hardware The PMG-emergency converter would only faults - two where solid-state compon- be needed in the rare case when all ents, one a relay, and one actuator other power sources had failed. failure. The most elusive failure was the solid-state random-access memory In-flight the pilot was practicing (RAM), which failed at temperatures be- a simulated engine flame-out maneuver low 40'F. Once the problem was identi- which calls for turning on the emergency fied, all memory chips were screened and power unit (EPU) that drives the emer- several replaced. gency generator and PMG (fig. 46). when the EPU was energized with the high One software error was detected by engine rpm, the energy surge caused the BIT. The error was in the BIT software PMG voltage through the emergency con- itself. The BIT would not pass on the verter to peak at 36 V. Previous ground aircraft and therefore that software test had been performed at lower engine release was never flown. The error was rpm. The overvoltage detectors, set at the result of simple oversight. An 35 V, disconnected the emergency con- improvement of BIT to test for parity verter and the essential dc busses from errors as a final check detected the the flight control system. With the parity error it had purposely set in a protection relays open, the unloaded previous test. PMG voltage through the emergency converter went to 40 V, keeping the relays Numerous bit failures occurred for latched. The flight control system was which the reason was never resolved being powered by the aircraft batteries. (table 24). The majority of the failures were believed due to EMIC, Ground test with engine rpm that however this was never confirmed. matched the flight condition confirmed the cause of the anomaly. The interac- The BIT failures owing to system tions of the EPU, emergency generator's integration weLe the most interesting

39 (table 25). In these cases a lack of The second memory mode anomaly understanding of the system operation, occurred when the engine was started at times combined with incorrect proce- with the control system in the memory dures, induced BIT failures. mode, which does not have the power-up and restart routine of the in-flight Item number 2 (table 25) provides a software. The power transfer , caused good example of how the integration of by the aircraft generator coming on at systems caused problems with BIT. In engine start, failed the DFCS computers. this case BIT failed a test of the avi- Unfortunately the failure mode resulted onics multiplex bus, and the communica- in a canard hardover, damaging the nose tion from the multipurpose displays to gear door. the DFCS was lost. This caused a lockup of the system which required cycling of 7.2.3 Summary DFCS power to correct. The problem was caused by one side of the dual SMS fail- The criticality and number of anoma- ing to pass information between the DFCS lies discovered in flight and ground and the MPDs. The BIT design did not tests owing to design oversights are more allow for switching to the other side significant than those anomalies caused of the communication bus for this fail- by actual hardware failures or software ure as the in-flight software does. errors. The two design oversights discussed above, and identified as being It can be seen by comparing the num- caused by a lack of understanding of the ber of actual faults detected, five, to system or a system integration problem, the number of nonrepeatable and system can only be avoided in the system quali- integration faults that EMI, system fication and design life cycle phases. complexity, and the resulting lack of detailed insight caused as many prob- Although the failure indications lems as the hardware itself. were of computer hardware, testing of the hardware alone will not find the 7.2.2.2 Memory Mode. The memory error because the failure indication is mode option was an excellent test tool declared by the software. Testing of for determining DFCS state. It was very the software alone would not detect the valuable when troubleshooting system error because the software was imple- failures. when in memory mode, only mented correctly, per its specification. available on the ground, all normal DFCS flight computations are halted. Only during system qualification Two unique anomalies occurred with when the hardware and software system memory mode operations (table 26). Both are operating in an environment which is cases are examples of system integration nearly equivalent to the flight environ- problems. The first was a failure of a ment can design flaws such as these be DFCS channel when entering memory mode found and corrected. with rudder pedal input. It occurred during taxi when the pilot was using the Qualification of such a complex sys- rudder pedals for nose wheel steering. tem as this, to some given level of re- The asynchronous operation of the com- liability, is difficult for two reasons. puters resulted in entering and exiting First, there is no established method of the memory mode at different times in identifing system level requirements and the different computers. With dynamic relating them to the needed system level pilot inputs, memory mode selection testing. Secondly, as discussed in sec- would cause DFCS channels to believe tion 5.3.3.4 on system qualification, they had failed. the number of test conditions becomes so

40 large that conventional testing meth ds de step and hold input. Mi sion rules would require a decade for completion. limited the maximum sideslip to 10'. The fault-tolerant design can also Practicing this sideslip maneuver on affect overall system reliability by the simulation showed that the 10' being made too complex and by adding limit would not be exceeded. characteristics which are random in nature, creating an untestable design. In flight test, the maneuver resulted in a temporary sideslip excursion to As the operational requirements of 14'; from there a rapid departure from avionics systems increase, complexity controlled flight occurred. The air- increases. Reducing complexity appears craft departure was of a short duration, to be more of an art than a science and approximately 3 sec, but resulted in requires an experience base not yet some extreme conditions and flight available. If the complexity is control system failure indications. required, a method to make system designs more understandable, more During the departure the sideslip visible, is needed. exceeded 20' and normal acceleration exceeded -4 g, then +7 g (fig. 47). The asynchronous design of the tri- The aircraft rolled 360°, angle of plex DFCS introduced a random, unpre- attack went to -10' then to +20°, and dictable characteristic into the system. all control surfaces were operating at The system became untestable in that rate limits. The departure was quite testing for each of the possible time severe aerodynamically, resulting in the relationships between the computers was vertical tail exceeding its design load impossible. This random time relation- limits. Flight control system failure ship was a major contributor to the indications included hydraulic system flight test anomalies. Adversely failure for both canard actuators and affecting testability and having only an air data failure. The failures were postulated benefits, asynchronous opera- transient and were reset after control tion of the DFCS demonstrated the need was regained by the pilot. to avoid random, unpredictable, and uncompensated design characteristics. After analyzing the problem with the simulation, the following reason for the 7.3 Control Laws departure and its subsequent failure indications was found. The aerodynamic As described previously, the task- model used to develop the control laws tailored control mode options provide and used in the real-time simulator was a uniquely tuned control law for a given insufficient for the conditions of the task. Designing the control mode for a discrepancy. The lateral directional specific task instead of one general derivatives were a function of sideslip, control mode for all tasks improved the but only modeled to lt10'. Secondly, the aircraft's performance. The following nonlinear nature of the derivatives as discussions will address the most a function of sideslip was not modeled. interesting anomaly involving the The wind tunnel data were modeled as control laws. a straight-line function, giving the simulation more restoring force than The yaw departure on flight 36 was the aircraft. the most significant control law anomaly. A review will provide insight into The problem was corrected by remov- its cause. The yaw departure occurred ing the canards from the command path so in the SNRM mode during a maximum rud- that the aircraft could not obtain 10'

41 of sideslip. The horizontal tail struc- 2. The aircraft must be considered ture was examined and found to be undam- a system consisting of highly related aged, and a structural modification was disciplines and functions. The control made to the vertical tail to increase law design error caused by the modeling its load limit for future flights. error revealed design errors in the hydraulic system and DFCS fault detection The hydraulic vote in the canard logic. The aircraft structure became actuators was owing to a drop in hydrau- involved due to control law design error. lic pressure as a result of all control surfaces being at the command rate lim- 3. To thoroughly qualify an aircraft its. The air data failure, although with these types of systems, one must appearing to be straightforward, proved to be quite interesting. The air data A. model dissimilar sensors com- failure was a transient failure caused pletely, including sideslip effects; by the side-mounted probe which was blanked by the fuselage at the high- B. test with the aircraft in the sideslip angles. A detailed review of loop with the simulation, thereby in- the three computers' surface commands cluding the actuation system; showed a mistracking during this failure. Analysis showed the S/M technique C. test failure modes other than passed the side probes error through hardover failures; and until the failure threshold was reached (fig. 48). The air data information is D. have a complete under- used to determine flight control law standing of the DFCS design and gains asynchronously at 4 times per sec. its interrelationships. The air data failure transient, shown in figure 49, caused changes to the control 7.4 Hardware law gains, giving different control sur- f ace commands in the three channels. The DFCS hardware includes the F-16 baseline sensors and controllers and Fortunately, at the flight condition the AFT1 flight control computers and of the departure, the gain changes did actuator interface unit. Based on not produce differences which would repeatable, isolated failures, the cause failure declarations of the com- reliability of the hardware was excel- puters. For several areas of the flight lent. In the 175 hr of in-flight test, envelope, particularly at high angles of an electrical connector was the only attack, this single air data failure hardware failure. In the 6200 hr of would result in failure of the DFCS ground time, including time prior to to the analog backup. This increased flight test, only three failures were risk was accepted until the software documented in the computers. To deter- was modified. mine computer reliability, the time must be multiplied by three, for the three Several points should be noted from computers used in the system. This this flight incident: gives a 6200-hr mean-time-between failures compared to a predicted 1200 hr. 1. Any simplification in the modeling of the aerodynamics must ensure that The most significant problem to it is conservative with respect to its address lies in the number of nonre- effects on the aircraft as a whole.

I peatable failures and failure indica- The first error in the software re- tions listed in table 22 and discussed sulted from a change to the BIT soft- in section 7.2. Depending on one's ware. The change was to cause BIT to operating rules, these failures can fail if it detected a parity error in result in considerable equipment changes the hardware. One function of BIT was and loss of aircraft availability. to read a memory location with known bad parity and to check for parity error 7.5 Software detection by the hardware. The software used to detect unintentional parity The use of a DFCS enables changes to the errors also detected the purposeful one, systems' characteristics, such as flying causing the BIT to fail erroneously. qualities, by reprogramming the software. Efficient and safe flight test The second software error involved requires a thorough method for eval- the structural limit for the vertical uating, implementing, and testing tail. The structural load was limited software .changes. by restricting the rudder command as a function of impact pressure and flight In the 1 yr of flight testing, 129 control mode (fig. 51). During flight software changes were made in 13 sepa- test, it was found that the vertical rate releases (fig. 50). A software tail loads were exceeding those desired release is a package of changes pro- with the rudder limit implemented. Sev- vided in one update. eral options to correct the problem were engineered and evaluated with the The process of changing the software hardware-in-the-loop simulation. The is described in section 6. The majority best option was identified and included of the evaluation, implementation, and in the next flight release. Unfortu- testing occurred at the contractor's nately, one of the other options being facility. The Joint Test Force, consis- evaluated was accidentally left in the ting of the Air Force Flight Test Center software. The error was found during and NASA, played two major roles in the ground testing which checked the instal- software process. First, it identified lation of the new software into the air- changes that were needed and their tim- craft. Tests showed that the rudder was ing for release, and second it provided being limited to smaller deflections an independent audit of the changes. than those expected. The software error The audit included independent valida- gave a conservative limit for vertical tion testing at the contractor's facil- tail loads, but resulted in unnecessary ity and review of supporting software operational limits. A decision was made products, such as the documentation. to use the software release until it could be corrected in the next update. Three errors were found in the software releases after they had been The last software error was dis- approved for flight test. All resulted cussed in section 7.2. It involved a from changes, and none were latent er- change to the software, voting a soft- rors which existed for several releases. ware switch, causing all three computers Two of the errors were found in ground simultaneously to use the same control preflight tests, and one was detected law paths. Although extensively tested during flight. prior to flight with software unit tests and hardware-in-the-loop tests, the A software error is defined as the anomaly was not detected until flight software not operating in accordance test. The software error was one of with its specification. correctly voting the three computers'

43 determination to toggle a software 8.1 Anomaly of Flight 44, A Case Study switch, but then not using that voted value for the actual switching action. The anomaly of flight 44, discussed in The previous method was still in effect, section 7, provides a good example to that is, each computer channel deter- illustrate how activities of the pre- mined its own switching. Flight tests vious life-cycle phases contributed to under the conditions that would allow a flight-test anomaly. The anomaly was this error to occur, which were a func- owing to a design oversight and required tion of control mode, were prohibited several unique conditions, which are until the next software release. outlined as follows (fig. 52):

1. Standard combat or a decoupled 8 OBSERVATIONS AND RECOMMENDATIONS flight control mode had to be active.

2. The pilot had to have full rud- Each of the four life-cycle phases der pedals, flying at 170 knots cali- are pulled together in this section to brated airspeed (KCAS). examine how they affect one another. The approach in this section is to 3. Sensor noise coupled with com- first give a detailed case study, then puter skew had to give a 3-knot dif- to summarize each of the development ference in the impact pressure values phases. Emphasis will be on how the in the three computer channels. flight test phase was affected by the previous three phases - specification, In the flight control modes identi- design, and test. Comments are also fied, a rudder fader, schedule D69, given which only refer to a single life- removes pilot commands below 170 KCAS, cycle phase, such as recommendations for controllability reasons. The dif- that would provide for a more efficient ference in the perceived airspeed for qualification. After completing the the three different channels allowed case study, a review of the previous different amounts of the full-rudder- three development phases gives three pedal commands to pass through schedule perspectives on how anomalies can be D69. The three different pedal commands avoided and how to maximize the bene- initialized each channel's integrator, fits of flight testing. Looking at resulting in a divergence of the output system-sof tware qualification, we see commands to the canard surfaces. Each that more complete and efficient test- of the three computer channels declared ing is needed. Looking at design, we the other two as failed. The aircraft see that operational benefits can be was landed effectively with a single achieved by improving system architec- string flight control system. ture. Finally, when considering the system specification, we see that if 8 .1 .1 Specification sufficient detail exists to identify exactly what is desired, then a cor- Clearly, it is not desirable to rect design is more likely. The case have a system design that can cause study from flight test will help to loss of system redundancy when no clarify each of these concepts. Fol- failure exists. However, there is lowing the case study, recommendations nothing in the specifications which for each life cycle are summarized. addresses incorrect failure detection.

44 Reliability requirements simply address However, the amount of impact pres- component failures. Once you specify sure error in the different channels was that incorrect failure detection is not never enough to cause the problem to acceptable, criteria are needed to en- appear during ground testing. Sensor sure it. This has been a matter of noise and computer skew were two param- engineering judgment to date. eters which were not controlled, nor were the exact triplex values known Recommenda ti on during the ground testing.

Incorrect fault detection, resulting Recommendations in inappropriate loss of system redundancy, is unacceptable. The criteria 1. Fault-tolerant system design for ensuring proper operation should must be evaluated for sensitivity to be to test voted-compared values with sensor noise. inputs that represent the physical limits of the device-system in question. 2. A computerized description of The physical limits to consider include the flight control system is needed to . rate of change, minimum and maximum identify conditions, control modes, and values, maximum frequency response, flight conditions for doing sensor noise and noise, as examples. sensitivity tests. The computerized system description would accept user 8.1.2 Design inputs, such as flight conditions and control modes, and return active com- The design change needed to avoid mand paths appropriate for sensor sen- this anomaly is one ensuring that the sitivity tests. same value of a sensor is used in all redundant channels. Simultaneous sen- 3. Random unmeasured system param- sor sampling and proper sensor selec- eters such as computer skew must be tion routines would ensure congruent limited. If they can't be limited, sensor values. additional testing is needed to get a statistical base for predicting its Recommenda tion effect on system operations.

Redundant system designs which use 8.2 Observations and Recommendations by voting and cross-channel comparisons to Development Phase detect faults must operate on congruent input data sets to avoid incorrect To minimize the detailed discussions failure detection. needed to review every flight anomaly and the analysis used to arrive at each 8 .1 .3 Qualification recommendation, we will briefly describe the observations and recommendations as For the system-software qualifi- they apply to each development phase. cation activity, several generalized techniques should be used to detect the 8.2.1. Specification anomaly of flight 44 prior to flight test. Testing the control mode con- The primary observation concern- dition for the anomaly is easily done, ing the specifications is the lack of in fact these control modes were tested detailed specifications for reliability for months using the hot bench simula- and fault tolerance. "he majority of tion. The rudder fader, likewise, was the specifications is concerned with tested numerous times. stability and control requirements for

45 conventional, nondecoupled control dynamic failure transient requirements, system designs. which vary with mission. At certain conditions, such as high-impact pres- Recommendations sures, a surface transient can result in structural damage with little aero- 1. In addition to the loss of con- dynamic transient. Table 28 shows a trol and abort specifications, failure possible specification for structural probabilities should be given for the transients by giving flight condition different mission phases and the func- and surface transient allowable, thereby tions performed by the flight control implying flight loads. The conditions system. By specifying abort probabil- would be derived from calculations which ities for different missions, such as determine excess structural loads. air-to-air intercept and air-to-surface bombing, the designer can avoid either 8.2.2. Design over- or underdesigning the system. The reliability of functions, such as pilot Some observations and generic recom- displays and controls, should likewise mendations for designing fault-tolerant be given reliability values. control systems are presented in this section. The major theme of the recom- 2. Reliability requirements need to mendations is based on the life criti- address the software by identifying the cality of the control system and han- testing methods and tools to be used and dling the complexity imposed by by clearly stating the requirements of redundant systems . any independent backup, whether hardware or software in nature. The key to soft- Reviewing the methods used to I ware reliability is not found in a fail- develop the system architecture, soft- ure rate, but in the examination of the ware, and control law designs shows that method and tools used to ensure proper both the method used to specify the con- functionality. The software's life trol laws and the tools available to cycle of specification, design, and test develop them are more mature than for must be specified so that testing is the other two. Whereas, some software traceable to the requirements, and tools are available for the software proper functionality is shown. The ap- development process, tools to assist pendix provides some detailed testing in specifying and performing tradeoff examples for control law functions. studies are needed. Tools do not exist for the system architecture and fault- Requirements for an independent tolerant design task. backup should include (1) method for detecting the need for a transition to There is no integration of tools for I I the backup, whether manual or automatic, the three disciplines. For example, (2) allowable transition periods and DIGIKON, used to develop the control transients, and (3) functional require- laws, has a data base which describes ments of backup, such as operating enve- the control laws. DIGIKON is not tied lope and reliability. If the backup is to any of the software development going to be flight tested, reengagement tools. A laborious handmade descrip- of the primary system must be addressed. tion of the control law design had to be written for the software mechaniza- I 3. Failure transients should be tion document. specified in terms of the resulting I aerodynamic and structural effects. If a system made of these three Table 27 is an example of maximum aero- elements is to work as a whole, devel-

46 opment and integration of design and 4. A fault-tolerant system, which development tools are needed. uses cross-channel voting to detect failures , should avoid random, unmeas- Recommendations urable design characteristics, such as asynchronous channel operation. This 1. An integrated design tool, which helps to keep failure thresholds at low addresses control laws, fault tolerance, levels and minimizes unexpected interac- hardware, and software, is needed for tions that can result from incongruent fault-tolerant control systems. A few data sets. of the capabilities needed in such a tool include the following: The fault-tolerant design should also be transparent to the control law A. Documentation of the system functions. The control laws should not design in a computer data base which have to be tailored to the system's relates the different functional redundancy leve1. areas. The data base would be quer- ied to find possible interactions, 8.2.3 Qualification such as sensor noise, affecting command paths in the control laws. The leading issue in qualifying or testing complex DFCSs are completeness B. Evaluation of the system and cost. Test completeness is an issue design for fault tolerance, control with any software-driven system, but laws, and software execution prior becomes a major item when the system has to actual system build. The ability full authority control of a piloted air- to analyze the design and make cor- craft. Determining some level of test rections prior to building hardware completeness is also difficult because and software code would reduce rede- of the complexity - number of dependent sign during qualification. inputs and number of operating modes. The appendix provides some suggestions 2. When designing interfaces to a for complete testing of control laws. redundant flight control system, one must carefully consider the criticality Cost, the other leading issue, re- of the information being passed and the sults directly from the effort needed failure modes that are possible. This to completely test complex systems to requires a detailed understanding of the a reasonable level. Rather than achiev- items being interfaced. A case in point ing a measurable level of test complete- was the ISA and flight control system ness or by meeting established criteria, interface. Additional testing of the the amount of testing performed often ISA was needed to design its interface. becomes limited by cost.

3. The avionics interface is an Recommendations example where no redundancy existed for many of the failure modes possible. The 1. System-software qualification information passed from the avionics was testing must be performed to ensure im- critical enough to have caused a failure plementation of the requirements, and of the DFCS. The redundancy required in that each requirement is tested to meet an interface must be based on the criti- an established criterion. For example, cality of the information and the pos- a system requirement for decoupled con- sible failure modes. trol would result in a corresponding

47 software requirement, identifying spe- 8.2.4 Flight Test cific control law components, such as those given in the appendix. By far, the best thing that can hap pen to a flight test program is to have Testing must be identified for both thorough specifications, a good design, the system and the detailed software and a complete and efficient qualifica- requirements. The testing must be com- tion. The fact that more anomalies and plete enough to verify the requirements flight test time were lost owing to are met at both levels. A tool or design oversights than actual compo- method is needed to ensure test cov- nent failures attests to the need for erage of all software components. improving the development cycles.

2. Tools that support automation of Some specific recommendations from the verification task should be used. flight test follow. Automated test stimulus, data recording, and analysis can provide for more thor- Recommenda tions ough tests, better test documentation, and more efficient use of personnel. 1. To ensure the best system con- The use of qualitative pass-fail cri- figuration for retesting of changes and teria, such as reasonable transients corrections during flight test and to and acceptable differences, should minimize downtime to resolve flight be avoided. anomalies, it is recommended that the aircraft design include the capability Test automation will require real- of closing the aerodynamic loop around time instrumentation of internal soft- the aircraft with the flight avionics ware calculations. The system design installed. This configuration minimizes will need to support the special test the number of unknowns involved when requirements for providing visibility testing. Unexpected interactions which into the system. have not been modeled can be detected.

3. A computerized on-line descrip- 2. A computerized data base de- tion of the system (see recommendation scribing the aircraft's flight system 1, section 8.2.2) should be available would greatly help flight test. Used as to test engineers. This data base of an educational tool €or new engineers, design information will assist the it could reduce the learning curve. As tester in determining test conditions , during the system qualification, it functional interactions, and param- would be valuable for troubleshooting eters to record for assessing proper flight test discrepancies. test results. The data base would also be valuable for determining the cause 3. Increased visibility into the of discrepancies. digital system requires instrumentation of intermediate software calculations. 4. System testing must consider the To effectively analyze system perform- operating environment in which it is ance and resolve anomalies, data from going to be used. vibration and tem- internal calculations are required at perature effects on sensor values used the frame rate they are being calculated. by the control system must be modeled. The aircraft flight instrumentation sys- These effects can easily be implemented tem and postflight analysis systems will by imposing biases and noise on the sim- need to support the increased data flow 1 ulated sensor values. imposed by this requirement. I

48 9 CONCLUDING REMARKS For the testing phase, several recommendations are given to help reduce cost and flight test risk. The flight test program on the AFTI F-16 Automated software testing is one validated the concepts of decoupled approach proposed. flight control and the integration of avionics functions in the cockpit to The benefits shown during flight reduce pilot workload. Just as impor- test of the decoupled control modes are tant, it provided a chance to evaluate presented, showing the advantages of the tools and methods used in its devel- commanding direct sideforce. The anoma- opment. The performance capabilities lies discovered in flight testing are demonstrated by the AFTI F-16 required explained in detail, with reflections a new, higher level of avionics com- on how they might have been avoided. plexity. Flight testing provided the environment and conditions to uncover Overall, the integrated digital con- the design advantages and oversights. trol system provided many operational benefits. The hardware reliability of To minimize the oversights that came the complex system was excellent. How- from working at the leading edge of ever, the complexity of the system, cou- technology, recommendations are given pled with the wide range of disciplinary to improve all the development phases. engineers involved, caused numerous For the specification phase, allowable design oversights. failure transients are presented which specify the aircraft motion and structural loads permitted owing to a flight control system failure. National Aeronautics and The asynchronous digital control Space Administration system design is reviewed and the prob- Ames Research Center lems of using this approach examined. Dryden Flight Research Facility Creating a computerized description of Edwards, California, January 13, 1986 the system design is proposed to help evaluate designs prior to committing to bui Id.

49 APPENDIX - VERIFICATION REQUIREMENTS quired. A list of dynamic and special CONTROL LAW tests which need to be performed for each function follows.

One required level which flight-critical Variable Gains Scheduled on Air Data control laws must be tested to is spec- and Other Parameters ified in this appendix. This testing is performed in the actual hardware Sweep through the full range of the environment with all software operat- scheduling parameters while recording ing to show #at the control laws oper- the gain values. An input against out- ate properly with, and in the presence put cross-plot routine will provide data of, all other software routines. This for comparison to the specification. method for testing complex control law software is based on a divide and con- Fixed Gain quer philosophy. Modify the gain and rerun the sta- The control laws are broken down tic check. This checks the gain's posi- into individual blocks for which there tion in the control law loop and proper is one input and one output. These scaling effect. individual blocks are tested, and inter- connections between the blocks are Dynamic Elements, Filters, checked. Static checks should be done Integrators first, followed by the required dynamic tests. After the lower levels are Step inputs are applied to the tested, end-to-end checks for compar- input with resulting output time his- ison to equivalent FORTRAN-implemented tory responses recorded. Comparisons control laws are done. The following to independently implemented elements will address the method in which lower are made to show identical time his- levels can be tested in the actual tory responses. hardware environment with all software present. Nonlinear Elements, Stick Shaping, Limiters, Deadband Step 1 These elements require full-range Break down the control laws into input sweeps with outputs recorded. individual blocks. Figures 53 and 54 Cross-plots of input against output are lateral-directional control law can be compared to design data. diagrams. One section of this diagram has been broken down into modules and Multipliers is shown in figure 55. This breakdown needs to be refined to provide functions Multipliers are checked in the sta- with one input and one output. Fig- tic checks; full-range positive and neg- ure 56 shows the breakdown to individ- ative values should be checked. Proper ual blocks. Blocks can be combined for system response to overflow conditions testing provided proper implementation must be tested. can still be shown. Summing Junctions Step 2 Summing junctions are also checked Identify types of functional blocks in static tests; full-range positive and to be tested and the type of tests re- negative inputs are required.

50 Switching Functions 1. Inputs and outputs of blocks must be made accessible for external The switch connection and the func- recording and plotting by storing these tions which cause the switching action intermediate values in memory for output are tested. Do not attempt to toggle to a recorder. the switch by fooling a memory location; set up actual input conditions which 2. In order to carry out dynamic cause the switching action. tests of internal blocks, a test program to produce a step input is required. Block Interconnects This function needs

In the static checks, the output of (a) Step size and duration, each block is checked for proper connection to other block inputs. (b) Input location of step, and

Scheduled Dynamic Elements, Filters (c) External method of starting Scheduled on Air Data step function.

This type of software function is This step program can be patched in impossible to test completely. The for software testing and then be dis- scheduled value must be tested like abled for flight. With this function the variable gains. Several values and by disabling the store instruction must be chosen for the variable with for the output of the previous block, step responses measured. worst case dynamic tests can be performed. and extreme values should be used. 3. A general purpose digital-to- Rate Checks, Rate Limiters analog converter output program is useful and would allow putting out any Rate checks must be tested just memory location on a spare digital-to- below and just above the rate check analog converter (DAC) channel. Infor- level. The signal should be passed mation needed by the program includes unaltered below the level. Above the rate check or limit, flagging or limit- (a) Location for output, ing should occur. (b) Scale factor, Other Possible Digital Functions - ‘Delays and Decrements (c) Bias correction, and

Any other unique functions must be (d) DAC channel for output. examined and proper static and dynamic tests determined to show correct imple- This program can also be a test mentation. Emphasis should be on worst patch. If a test patch is not used case and extreme values as well as show- and this software will remain for ing proper implementation. flight, proper lockouts must be included and verified. Step 3 Step 4 Determine design requirements and modifications required to test Since time on the hardware system is the software. usually at a premium, post-test analysis

51 of data is needed. Post-test anlysis REFERENCES requires that recordings of data be made and that a method for plotting the data be available. Cross-plots and time history plots are both needed (see tests for functions in step 2). Recordings of digital data from the computer's memory provide the best flexibility.

Digital control laws are often dependent on external conditions, such as landing gear up or down or a given angle of attack for the alpha limiter. When testing control law functions, these external input conditions should be set by placing the conditions on the input analog and digital signals. In this way, the software system interactions can be tested. Falsely setting internal flags will not allow control law software to interact with the rest of the software structure.

The use of the simulation in a static mode, or by adding some special capabilities into the simulation, can provide the necessary input conditions. Since the simulation has all the inputs required to drive the control laws, test conditions can be set easily by using a cathode ray tube terminal tied to the simulator.

Special simulator capabilities to augment testing could include

1. Ramp function, that is, sweep alpha from -5O to +50° in 10 sec,

2. Step and sine functions, and Center, Hampton, Virginia, Oct. 25-27, 3. Predetermined logic or flight 1983, Beasley, G.P., compiler, 1983. conditions . Price, W.T.; Grandia, M.J.; Boulware, J.M.; Jones, J.O.; and Yousey, W.J.: Caution must be used in any support Configuration Design. AFTI/F-16 software for testing flight-critical Development and Integration Program, systems. The support software must be tested sufficiently so that no errors appear that would mask errors in the critical software system under test.

52 Szalai, K.J.; Jarvis, C.R.; Krier, G.E.; Equipment, Munitions, and Computer Megna, V.A.; Brock, L.D.; and O'Don- Programs. Military Standard MIL- nell, R.N.: Digital Fly-By-Wire STD-483A, 1985a. Flight Control Validation Experience. U.S. Department of Defense: Specifica- NASA TM-72860, 1978. tion Practices. Military Standard U.S. Department of Defense: Flight Con- MIL-STD-490A, 1985b. trol Systems - Design, Installation Yousey, W.J.; Schindler, T.M.; Johnson, and Test of Piloted Aircraft. Mili- A.M.; and Toles, R.D.: System Design tary Specification MIL-F-9490D, 1975. and Analysis for Redundancy Management. U.S. Department of Defense: Flying AFTI/F-16 Development and Integration Qualities of Piloted Airplanes. Mili- Program, DFCS Phase Final Technical Re- tary Specification MIL-F-8785C. port, vole 3, pt. 2, AFWAL-TR-84-3008, Wright-Patterson Air Force Base, Air Force Flight Dynamics Labora- Ohio, 1980. tory, 1984. U.S. Department of Defense: Configura- tion Management Practices for Systems,

TABLE 1. - DECOUPLED CONTROL REQUIREMENTS

Fuselage pointing control Pitch pointing, deg f2.5 f2.0 Azimuth pointing, deg f3.0 k3.0 Direct force control Lift force control, g 1 .o 1.5 Side force control, g 0.5 0.8

aFlight condition 1: 1- and 4-g maneuvering load conditions at Mach 0.6 at 5,000 ft. bFlight condition 2: 1- and 4-g maneuvering load conditions at Mach 0.9 at 20,000 ft.

53 TABLE 2. - RELIABILITY AND FAULT-TOLERANCE REQUIREMENTS

Reliability requirements

DFCS failure rate resulting in 1 in lo7 flight hr, excluding power loss of control actuators hydraulics and independent backup unit DFCS abort rate 1 in lo5 flight hr

Fail-operational requirements

First failure Fully operational Second failure of At least safe flight (Operational State similar device 111, MIL-F-9490D; U.S. Department of Defense, 1975); probability of 0.95 of fully operational

Swi tc hing

Mode switching Hands-on positive switching required to return to normal mode I Air-to-air mode switching Hands on

Transients

Switching transients Negligible Failure transients Magnitude and duration of DFCS transients shall not introduce unsafe transient vehicle responses

Cooling requirements

Flight control computers Capable of sustained reliable operation without reliance on forced air cooling

54 TABLE 3. - DFCS COMPONENTS, REDUNDANCY, AND FAIL-OPERATIONAL CAPABILITY

~~ Function or component Redundancy Capability

1. Stability and command Triple Two fail-operative with augmentation electronics successful self-test

2. Integrated servoactuator Dual hydraulic Fail-operative, fail-safe and triple elec- with computer interface trical input

3. DFCS hydraulics Dual Fai 1-operative

4. Mode select DFCS status Dua 1 Fai 1- ope ra ti ve , fai 1-s a f e

5. Trim (A) Switches Quadruple Two fail-operative (B) Electronics Triple Two fail-operative with successful self-test

6. Air data sensors (A) Static and impact Triple Fail-operative, fail-safe pressures with standby gains (B) Angle of attack Triple Fail-operative, fail-safe with reconfiguration (C) Angle of sideslip Triple Fail-operative, fail-safe with reconfiguration

7. Central air data computer Single

8. Leading-edge flap (A) Maneuver computation Triple Two fail-operative with successful self-test (B) Command servo Dual Fail-operative at half rate (C) Flap drive single Asymmetry detection and shutoff

9. Stick sensors Triple outputs Two fail-operative with with fourth active standby active standby

10. Pitch, roll, and yaw Triple Fail-operative, fail-safe rate sensors with reconfiguration

11. Accelerometers Triple Fail-operative, fail-safe with reconfiguration

55 TABLE 4. - VERIFICATION CROSS-REFERENCE INDEX USED IN SYSTEM SPECIFICATION

Section 3 requirement reference Verification methods

NA 1 2 3 4 5 3.1 Item definition X 3.1 .1 Interface diagram X 3.1 -2 Interface definition X 3.1.2.1 Sys tem interface X 3.1 -2.2 Digital-fly-by-wire system interface X 3.1 e2.3 Pilot-vehicle interface X 3.1 e3 Major components list X 3.1.4 Government furnished property list X 3.2 Cha rac te r i s tics 3.2.1 Performance characteristics 3.2.1 .1 General X 3.2.1.2 Specific X X X 3.2.1 e2.1 Direct force control X X 3.2.1 -2.2 Weapon line-pointing X X 3.2.1 e3 Stability and flying qualities X X X 3.2.1 -3.1 Normal mode X X X 3.2.1 m3.2 Departure and spin recovery X X 3.2.1.3.3 Limitations X X 3.2.1 -3.4 Task-tailored flight modes X 3.2.1 m3.5 Gain and phase margins X 3.2.1 -3.6 Decoupled operations X X 3.2.1 e4 Control law mechanization X 3.2.1 e4.1 Multimode control X 3.2.1 e4.2 Reconfiguration X 3.2.1 -5 Redundancy management X 3.2.2 Physical characteris tics 3.2.2.1 System functional character X X 3.2.2.2 Flight control computer c omp 1ex X 3.2.2.3 DFCS power supplies X X 3.2.2.4 DFCS sensors X X 3.2.2.5 Aircraft sideslip sensing X 3.2.2.6 Pilot controllers X X 3.2.2.6.1 Controller characteristics X X X

~~~ ~~~~ NA - not applicable; verification methods: 1 - inspection, 2 - analysis, 3 -demonstration, 4 - ground test, 5 - flight test.

I 56 TABLE 4. - CONTINUED

Section 3 requirement reference Verification methods

NA 1 2 3 45 3.2.2.6-2 Primary controller X X 3 e2.2 -6.3 Secondary controller X X 3.2.2.7 Trim X X 3.2.2.8 DFCS caution and warning annuncia tion X 3.2.2.9 System weight X 3.2.2.10 Controlled surface actuators X X 3.2.2.11 Independent backup X X 3.2.2.1 2 DFCS software X 3.2.3 Reliability 3.2.3.1 Failure rate, loss of control X 3.2.3.2 DFCS abort rate X 3.2.4 Maintainability X 3.2.5 Environmental conditions X 3.2.6 Power requirements 3.2.6.1 Electrical X X 3.2.6.2 Hydraulic X X 3.2.7 Transportability X 3.3 Design and construction X 3.3.1 Parts, materials, processes X 3.3.2 Electromagnetic interference and compatibility 3.3.2.1 General X X 3.3.2.2 Design requirements X X 3.3.2.3 Installation and integration requirements X 3.3.2.4 Electrical bonding requirements X 3.3.2.5 Lightning protection X 3.3.3 Nameplates and product marking X 3.3.4 Workmanship X 3.3.5 Interchangeability X 3.3.6 Safety X 3.3.6.1 Safety, descending order of precedence X 3.3.6-2 Health and safety criteria X 3.3.6.2.1 Toxicity X 3.3 -6.2.2 Electrical equipment hazard X

NA - not applicable; verification methods: 1 - inspection, 2 - analysis, 3 - demonstration, 4 - ground test, 5 - flight test.

57 TABLE 4. - CONCLUDED

Section 3 requirement reference Verification methods

NA 1 2 3 4 5 3.3.6.2.3 Personnel hazard and safety X 3.3.7 Human performance and human engineering X 3.4 Documentation X 3.5 Logis tics X 3.6 Precedence X 3.6.1 Precedence of documents X 3.6.2 Application of prior quality X

NA - not applicable; verification methods: 1 - inspection, 2 - analysis, 3 - demonstration, 4 - ground test, 5 - flight test.

TABLE 5. - ANALOG AND DISCRETE INPUTS AND OUTPUTS i Analog inputs I 1 Azimuth error Left angle of attack Azimuth error rate Left canard position Beta aft Left f laperon position I Beta delta pressure Left horizontal tail position Beta fore Left main landing gear tachometer Data age Normal accelerometer Demodulated left canard position Pitch rate gyro Demodulated left flaperon position Pitch rate gyro speed detect Demodulated left horizontal Pitch stick command tail position Pitch stick fourth transducer Demodulated right canard position Redundancy management test input Demodulated right flaperon position Right angle of attack I Demodulated right horizontal Right canard position tail position Right f laperon position Demodulated rudder position Right horizontal tai1 position Elevation error Right main landing gear tachometer Elevation error rate Roll rate amplified 1 I Impact pressure ( Qc Roll rate gyro 1 Indicated side-mounted angle of attack Roll rate gyro speed detect La tera 1 accelerometer Roll stick command 1 Leading edge flap position Roll stick fourth transducer I Leading edge flap tachometer no. 1 Rudder pedal command I Leading edge flap tachometer no. 2 Rudder pedal fourth transducer 1

58 TABLE 5. - CONTINUED I I I Analog inputs Rudder position Throttle controller command Spare dc input no. 1 Yaw rate gyro Static pressure (PSI Yaw rate gyro speed detect

Analog outputs

Angle-of-attack side mount, instrumen- Left horizontal tail command, primary tation servo valves Beta delta pressure, instrumentation Left horizontal tail command, secondary Demodulated pitch rate output servo valves Demodulated roll rate output Right angle-of-attack output Demodulated yaw rate output Right canard command, primary servo FLCC temperature, instrumentation valves Leading edge flap command Right canard command, secondary servo Leading edge flap actuator command valves nos. 1 and 2 Right flaperon command, primary servo Left angle-of-attack output valves Left canard command, primary servo Right flaperon command, secondary servo valves valves Left canard command, secondary servo Right horizontal tail command, primary valves servo valves Left flaperon command, primary servo Right horizontal tail command, secondary valves servo valves Left flaperon command, secondary servo Rudder command, primary servo valves valves Rudder command, secondary servo valves

Discrete inputs

Aerial refuel door Left flaperon ISA fail no. 2 (PS no. 2) Alternate flap switch Left horizontal tail ISA fail no. 1 CADC good (PS no. 1) CCV engage switch Left horizontal tail ISA fail no. 2 Electrical reset (PS no. 2) Gun firing logic Main landing gear weight on wheels Identity discrete no. 1, FLCC C Manual pitch override engage switch Indentity discrete no. 2, FLCC B Nose landing gear door Identity parity, FLCC A Nose landing gear weight on wheels IFFC analog data valid PLA (military power) IFFC engage switch PLA (power idle) Independent backup select switch Right canard ISA fail no. 1 (PS no. 1) Landing gear handle position Right canard ISA fail no. 2 (PS no. 2 Leading edge flap asymmetry brake Right flaperon ISA fail no. 1 (PS no. 1) LEF asymmetry brake power Right flaperon ISA fail no. 2 (PS no. 2) Left canard ISA fail no. 1 (PS no. 1) Right horizontal tail ISA fail no. 1 Left canard ISA fail no. 2 (PS no. 2) (PS no. 1) Left flaperon ISA fail no. 1 (PS no. 1)

59 TABLE 5. - CONCLUDED

Discrete inputs

Right horizontal tail ISA fail no. 2 Trim left wing down stick (PS no. 2) Trim nose down panel Rudder ISA fail no. 1 (PS no. 1) Trim nose down stick Rudder ISA fail No. 2 (PS no. 2) Trim nose left panel Servo reset Trim nose right panel Speed brake extend Trim nose up panel Speed brake retract Trim nose up stick Stick trim select switch Trim right wing down panel Trim left wing down panel Trim right wing down stick

Discrete outputs

Analog test LHT centering (low) CADC reset LFLAP centering (high) CADC test LFLAP centering (low) Dual DFCS faiL no. 1 (high) Normal accelerometer torque Dual DFCS fail no. 2 (high) Pitch rate gyro torque DFCS fail (high) PSA test DFCS ready PSA test enable IBU engage Right flap centering (high) Input discrete BIT test one Right flap centering (low) Input discrete BIT test zero RHT centering (high) ISA reset (high) RHT centering (low) ISA reset (low) Right canard centering (high) Lateral accelerometer torque Right canard centering (low) LEF lock no. 1 Roll rate gyro torque LEF lock no. 2 Rudder centering (high) Left canard centering (high) Rudder centering (low) Left canard centering (low) S ta11 warning LHT centering (high) Yaw rate gyro torque

60 TABLE 6. - TYPES OF AVIONICS INFORMATION

Type Description From Through To

Pilot-DFCS parameters

Mode requests Allowed selection of dif- MPD SMS DFCS ferent control modes

BIT Allowed pilot to initiate MPD SMS DFCS preflight BIT

Memory Ground only option to read MPD SMS DFCS computer memories for diagnostic purposes

Fault display Allowed pilot to obtain MPD SMS DFCS detailed information about failure lights

DFCS mode Indication of actual DFCS DFCS SMS MPD mode engaged

Miscellaneous data BIT, memory and fault data DFCS SMS MPD requested by the pilot

Control law parameters

Pitch and roll Inputs to a G-bias func- INU -- DFCS attitude tion that assisted the pilot during rolls

Aircraft velocity INU -- DFCS

Instrumentation parameters

Parameter location Identifies 64 DFCS param- FCC -- DFCS eters for output from the DFCS to the instrumentation system

Instrumentation DFCS -- Instrumenta- parameters tion system

61 I TABLE 7. - SUMMARY OF DFCS DISPLAYS IN THE COCKPIT

Name Description

Dedicated failure lights

FCS fail Indicates a failure involving one level of redundancy

Dual fail A failure involving two levels of redundancy

I BU The IBU is engaged

HUD indications

ccv Control configured vehicle - indicates decoupled control modes are active

G-limit Indicates that the preselected normal acceleration limit is active

Multipurpose displays

Base page Allowed €or control mode selection and access to the fault, data, test, preset, and authority pages

Fault page Allowed display and reset of DFCS failures

Data page The data page has the same functions as the base page with additional data displays

Te s t page Provided ability to read DFCS memory and initiate BIT, ground operation only

Preset page Allowed changing the default relationship of pilot controllers to control functions

Authority page Allowed pilot to set a normal acceleration limit, for flight- test purposes

62 TABLE 8. -MNEMONICS FOR MJ?Da I

Level Type Class

I Recon All IBU 1 st Pitch Ac tua tor 2nd Roll Branch Lock Yaw output A/B LHT Compute A RHT Input B L FLP "Blank 'I Center R FLP "Blank" L CND R CND Rudder LEF Air data Switch

'I Blank"

aLevel, type, and class are defined in table 9.

TABLE 9. -DESCRIPTION OF FAULT MNEMONICS

Level

1st A 1st failure of a particular type and class has occurred 2nd A 2nd like failure of a particular type and class has occurred Recon Control law reconfiguration (recon) has occurred; will only appear if a 2nd like failure of a particular type and class can't be isolated Lock The leading edge flaps are locked A The secondary hydraulic system has failed B The primary hydraulic system has failed A/B A 2nd like hydraulic failure has occurred Center The displayed control surface has been centered

All All inputs or outputs of a particular class are affected Pitch Pitch axis inputs have failed Roll Roll axis inputs have failed Yaw Yaw axis inputs have failed LHT Left horizontal tail RHT Right horizontal tail LFLP Left trailing edge flap

63 ~ ~

TABLE 9. - CONCLUDED

RFLP Right trailing edge flap LCND Left canard RCND Right canard Rudder Rudder LEF Leading edge flap Air data Impact or static sensor has failed Switch A cockpit or aircraft switch has failed

Class

I BU Independent backup flight control system has failed Actuator An integrated servoactuator (ISA) has failed Branch All computer inputs and outputs in one flight control computer have failed output There has been an output electronics failure in a flight control computer Compute There has been a computational failure in a flight control computer Input A sensor or controller has failed

TABLE 10. -NUMERIC CODES FOR FAULT DISPLAYS

~~ Device identif i- cation number Failure Leve 1 Type Class (DID)

1 FLCC lst, 2nd A11 Branch 2 D-A converter lst, 2nd A11 output 3 LHT total computed output lst, 2nd LHT Compute 4 LHT coil wraparound lst, 2nd LHT output 5 RHT total computed output lst, 2nd RHT Compute 6 RHT coil wraparound lst, 2nd RHT output 7 LFLP total computed output lst, 2nd LFLP Compute 8 LFLP coil wraparound lst, 2nd LFLP output 9 RFLP tota 1 computed output lst, 2nd RFLP Compute 10 RFLP coil wraparound lst, 2nd RFLP output 11 Rudder total computed output lst, 2nd Rudder output 12 Rudder coil wraparound lst, 2nd Rudder output 13 LCND total computed output lst, 2nd LCND Compute 14 LCND coil wraparound lst, 2nd LCND output 15 RCND total computed output lst, 2nd RCND Compute 16 RCND coil wraparound lst, 2nd LEF output 17 LEF total computed output lst, 2nd LEF Compute 18 LEF hardware status lst, 2nd LEF output 19 A-D converter lst, 2nd A11 Input

64 TABLE 10. - CONCLUDED

Device identif i- cation number Failure Le ve 1 Type Class (DID)

20 800-Hz power supply lst, 2nd A11 Input (inverter) 21 Pitch rate sensor lst, 2nd Pitch Input recon 22 Spare 23 Roll rate sensor lst, 2nd Roll Input recon 24 Yaw rate sensor lst, 2nd Yaw Input recon 25 Angle-of-attack sensor lst, 2nd Pitch Input recon 26 Spare 27 LEF pot wraparound 1st Pitch Input 28 Pitch stick lst, 2nd Pitch Input 29 Roll stick lst, 2nd Roll Input 30 Rudder pedal lst, 2nd Yaw Input 31 Throttle twist lst, 2nd Pitch Input recon 32 Normal acceleration sensor lst, 2nd Pitch Input recon 33 Lateral directional accel- lst, 2nd Yaw Input eration sensor recon 34 Spare 35 Static or impact lst, 2nd Air Input sensor pressure recon data 36 Discrete IOC lst, 2nd Switch Input 37 Discretes lst, 2nd Switch Input 38 IBU pitch wraparound lst, 2nd Pitch I BU 39 IBU lateral directional lst, 2nd Roll I BU wraparound 40 LHT ISA pressure A, B, A-B, LHT Actuator system center 41 RHT ISA pressure A, B, A-B, RHT Actuator systern center 42 LFLAP ISA pressure A, B, A-B, LFLP Actuator s ystern center 43 RFLAP ISA pressure A, B, A-B, RFLP Actuator s ystem center 44 Rudder ISA pressure A, B, A-B, Rudder Actuator s ystern center 45 LCND ISA pressure A, B, A-B, LCND Actuator s ystern center 46 R~DISA pressure A, B, A-B, RCND Actuator system center

65 TABLE 11. - DISCRETE INPUTS PROCESSED BY THE DISCRETE SELECTOR-MONITOR

Description

Group 1: Requires 5 msec settling time

Nose landing gear door Pitch integrator inhibit Landing gear handle Right flap PS no. 1 Right horizontal tail PS no. 1 Right flap PS no. 2 Right horizontal tail PS no. 2 Speed break retract Stick trim right wing down Air refuel door open CADC valid LEF brake power Left flap PS no. 1 PLA idle Left flap PS no. 2 Stick trim left wing down Rudder PS no. 1 Stick trim nose up Rudder PS no. 2 Speed break extend Right canard PS no. 1 Stick trim nose down Gun firing Weight on nose landing gear CCV engage PLA at military power Right canard PS no. 2 LARAP engage request IFFC engage LARAP disengage request IBU select Left horizontal tail PS no. 2 Alternate flap switch Left canard PS no. 1 Left horizontal tail PS no. 1 Left canard PS no. 2 LEF assymetry brake IFFC good

Group 2: Requires 80 msec settling time

Electrical reset Panel trim nose down Servo reset Panel trim nose left Panel trim nose up Panel trim nose right Manual pitch override engage Stick trim disconnect Panel trim left wing down weight on main landing gear Panel trim right wing down

66 VI r

4 44 4 IC ZICICICICICIC ZZPZ

p: . 0 P H c -d zH k 0 0 F p: 0 IC 2ICICICICICIC ICICICIC I3 uw 4 w 4J rn 7 w X 2 H .d * m 5k n 5 w 0 rn W rn 4 uw 0 'm k I un 0 l3 Iw rn P H c 3 4 I k PI L.4 0 IC45 al 4J rnwal .d w alm c u k- 0 2 E al 3 d dz I a . m mm rmmmmmm m vvmv (v v- w lil E5 c 0

m 4J aal al mm 4J 4J 4 al w 4J 0 a k al d d alp)@ a,ala,alal b d 4J4J4J 4J4J4J4J4J c 0 000 00000 4 p: zzz zzzzz

67 TABLE 13. - HIERARCHICAL STRUCTURE OF SYSTEM USED BY FAILURE MANAGER

~~ ~ ~ ~ ~~~~ 1 FLCC (flight control computer) 1 .l Digital-to-analog (D-A) converter 1 .l .l Left horizontal tail coil wraparound 1.1.2 Right horizontal tail coil wraparound 1.1.3 Left flap coil wraparound 1.1.4 Right flap coil wraparound 1.1.5 Rudder coil wraparound 1.1.6 Left canard coil wraparound 1.1.7 Right canard coil wraparound 1.1.8 Leading edge flap (LEF) total computed output (TCO) 1 .1.8 .1 LEF hardware 1.2 Left horizontal tail TCO 1.3 Right horizontal tail TCO 1.4 Left flap TCO 1.5 Right flap TCO 1.6 Rudder TCO 1.7 Left canard TCO 1.8 Right canard TCO

2 Analog-to-digital (A-D) converter 2.1 Inverter (800-Hz power supply) 2.1.1 Pitch rate sensor 2.1.2 Roll rate sensor (normal or amplified) 2.1.3 Yaw rate sensor 2.1.4 Angle-of-attack sensor 2.1.5 Beta (yaw) sensor (at present not monitored) 2.1.6 LEF pot wraparound 2.1.7 Pitch stick 2.1 .% Roll stick 2.1.9 Rudder pedal 2.1 .l 0 Throttle twist 2.2 Normal acceleration sensor 2.3 Lateral directional acceleration sensor 2.4 Impact pressure (Qc) sensor or static pressure (P,) sensor

3 Discrete IOC 3.1 Individual discretes (switches) IBU pitch wraparound IBU lateral directional wraparound Left horizontal tail ISA Right horizontal tail ISA Left flap ISA Right flap ISA Rudder ISA I Left canard ISA Right canard ISA

68 TABLE 14. - SOFTWARE MECHANIZATION FOR GOOD-CHANNEL-AVERAGE SELECTOR MONITOR, NO PRIOR FAILURES

Values Failure conditions

ABS (L-S) > E NNYYYNNYYY ABS (S-R) > E NYNNNYYYYY ABS (L-R) > E -NNYYYYNNY LPC = first fail limit-1 - - - N Y - - - - - SPC = first fail limit-1 ------NY- RPC = first fail limit-1 - - - - - NY--- Required action 1223456789

Actions :

1. Decrement LPC if LPC > 0 SPC if SPC > 0 RPC if RPC > 0 6. Decrement LPC if LPC > 0 Select (L + S + R)/3 SPC if SPC > 0 Increment RPC and TPC 2. Select (L + S + R)/3 Invoke failure manager Select based on DST MS 3. Decrement SPC if SPC > 0 RPC if RPC > 0 7. Decrement LPC if LPC > 0 Increment LPC and TPC RPC if RPC > 0 Select (S + R)/2 Increment SPC and TPC Select (L + R)/2 4. Decrement SPC if SPC > 0 RPC if RPC > 0 8. Decrement LPC if LPC > 0 Increment LPC and TPC RPC if RPC > 0 Invoke failure manager Increment SPC and TPC Select based on DST MS Invoke failure manager Select based on DST MS 5. Decrement LPC if LPC > 0 SPC if SPC > 0 9. Increment TPC Increment RPC and TPC Select (L + S + R)/3

Notes:

In all cases the selected output is 0 if the reconfiguration flag (RECF) is set.

L left XPC persis tance counters, number of iterations S self a failure has been present, where X is L, R right S, R, or T T total E fault detection level ABS absolute value DST device status table MS monitor state

69 TABLE 15. - VERIFICATION TEST PLAN SUMMARY

Section

1 Purpose

2 Applicable documents 2.1 Government documents 2.2 Nongovernment documents

3 Test concepts 3.1 Definition of terms 3.2 Description of program under test 3.2.1 System operational characteristics 3.2.2 DFCS OFP functions 3.3 Test philosophy

4 Qualif icaiton requirements and criteria 4.1 Stand-alone testing 4.1.1 AMUX data interface test 4.1.2 Gain scheduler test 4.1.3 Control law frequency response test 4.1.4 Control mode selection and transition response test 4.1.5 Analog input S/M operation test 4.1.6 Discrete input S/M operation 4.1.7 ISA monitor operation test 4.1.8 LEF monitor operation test 4.1.9 Long power outage test 4.1.10 Short power outage test 4.1.1 1 Memory and duty cycle reserve test 4.1 .12 Built-in test 4.1 .13 Flyable hardware retest

5 Test implementation 5.1 Location and schedule 5.2 Limitations and general comments 5.3 Preparation of input 5.4 Conduct of tests 5.5 Analysis of results 5.6 Summary of equipment 5.7 Special test software 5.8 Summary of personnel requirements

6 Control and reporting procedures 6.1 Configuration control and documentation maintenance 6.2 Test failure analysis, repair and retesting

7 Requirements cross-reference

70 TABLE 16. - REVERIFICATION ACCEPTANCE TESTS

Test

Verify AMUX input-output interface -Static SASB control law end-to-end calculations at Mach 0.9, sea level -MUX input-output words

Verify end-to-end control law frequency response -Discrete sinusoidal inputs (1, 5, and 12 Hz) for all control modes -Pitch and yaw feedback sensor inputs

Verify multiple single fail-fault annunciation -Verify single fail device status entries for all monitoring planes in standard normal mode (SNRM) for analog inputs, discrete inputs, actuator inputs, ISA and LEF outputs

Verify first fail frequency response -Verifies SNRM first fail performance is same as no-fail performance (repeat test 2 for SNRM)

Verify single FLCC long outage restart performance -Satisfactory restart performance -Proper reconstruction of device status table fault history from non- volitive memory using test 3 faults

Verify restarted FLCC frequency response -Verify FLCC performance unaffected by a long power outage using test 2 for SNRM

Verify multiple dual fail and graceful degradation to one FLCC -Dual fail device status entries and AMUX fault annunciation in all monitoring planes -Insert parity error in one FLCC

Verify single FLCC frequency response test -Verifies remaining FLCC from test 7 has approximately same performance as nominal triplex system using test 2 for SNRM

71 TABLE 17. - INTEGRATED SYSTEM TESTS

Bui 1t- in test Mode selection and display test Control law frequency response Step response test Flight scenario test Analog input single failure tolerance Analog dual-like failure tolerance ISA and LEF monitor failure tolerance Analog multiple unlike input failure test Stress test Power outage-restart test Control law gain margin test

TABLE 18. - FLYING QUALITIES TASKS AND CONTROL MODES

Task Subtest Mode number , ”

1 Takeoff SNRM 2 Air- to-ai r handling qualities AAG 3 Air-to-air tracking AAG 4 Decoupled air-to-air handling qualities D AAG 5 Decoupled air-to-air tracking DAAG 6 Air-to-surface tracking (bombs 1 ASB 7 Decoupled air-to-surface tracking (bombs) DASB 8 Air-to-surface tracking (guns 1 ASG 9 Decoupled air-to-surf ace tracking (guns) DASG 10 Power approach and landing SNRM SNRM 11 Mode transients A11 12 a limiter SNRM AAG DAAG

72 I I

~ I I I TABLE 19. - COMPONENTS CONSIDERED IN FAILURE MODES AND EFFECTS TESTING j

1. Engine failure 17. ISA primary coil signal failure iI 2. Emergency power unit (EPU) failure 18. ISA secondary coil signal failure 3. Main generator failure 19. Leading-edge flap command failure 4. System A hydraulic failure 20. Input discrete section failure 5. Any ISA servovalve SV1 or 21. System input discrete failure 1I SV2 failure 22. Wraparound input discrete failure 6. System B hydraulic failure 23 Output discrete section failure iI 7. Any ISA servovalve SV3 failure 24 ISA output discrete , 8. ISA solenoid valve failure 25. Failure annunciation output dis- 9. FLCC power supply failure crete failure 10. Central processing unit 26 BIT output discrete failure It ( CPU 1 f ailure 27. Data link transmitter failure I I 11. Input-output controller 28 Data link receiver failure )I ( IOC ) failure 29. Avionics multiplex bus failure 12. Analog-to-digital (A-D) converter 30 IBU failure failure 31 LEF command servo 13. 800 Hz power failure 32 Runaway trim 14. Sensors-controllers 33. Avionics failures 15. External 215 V dc power failure 34. Digital value of actuator commands 16. Digital-to-analog (D-A) con- I verter failure t

~~ ~~~~ ~~~ _____ ~~ ~ I

TABLE 20. - FAILURE MODES AND THEIR EFFECTS

Component Failure mode Failure effect

~~ Note: The first eight components were not considered to be DFCS components.

9. FLCC power Turn-of f power Branch failure including loss of supply one set of inputs, one CPU, and 1~ one set of outputs plus switching of one set of servovalve coils to the secondary coils II 10. Central proc- Halt CPU Branch failure including loss of essing unit CPU and one set of outputs plus ( CPU ) switching of one set of servovalve coils to the secondary coils I

73 TABLE 20. - CONTINUED

Component Failure mode Failure effect

11. Input-ou tput Halt IOC Branch failure including loss of controller one set of inputs, one CPU, and (IOC) one set of outputs plus switching of one set of servovalve coils to the seccondary coils

12. A-D converter Hard-over A-D inputs Ripple A-D and D-A failure trees

13. 20 V ac 800 HZ Turn-off power by Ripple the inverter resulting in power pulling breaker to loss of one set of 800 Hz inputs a branch inverter

14. Sensor and con- Turn-off any sensor or Loss of a single input; other two troller inputs pilot controller input inputs are monitored to obtain a valid signal

15. External f15 V a. Ground +I5 V dc from a. Ripple A-D failure tree in dc power one F'LCC one E'LCC b. Ground -1 5 V dc from b. Ripple A-D failure tree in one FLCC one FLCC

16. D-A converter Hard-over D-A outputs Ripple D-A resulting in loss of one set of outputs plus switching of one set of servovalve coils to the secondary coils

17. ISA primary Open coil current Coil current failure; switch to coil wraparound backup servoamplifier for driv- ing secondary coil of one ISA

18. ISA secondary Open backup coil cur- Backup servo amplifier failure coi1 rent wraparound

19. LEF command Hard-over command on LEF output electronic failure plus FLCC C switching LEF drive to FLCC B

20. IOC input dis- Simultaneous failure of Individual discretes failure in crete section all system and wrap- one FLCC each time a discrete around discrete inputs input is changed by the pilot to no change

21. System input Fail all system input Discrete failure resulting in loss discretes discretes of one FLCC of a partial set of system to undriven bus input discre tes

22. Wraparound Incorporated in compo- Not applicable (w/A) input nent no. 20 discretes TABLE 20. - CONTINUED

~ ~~ ~~ ~ ~~ ~ Component Failure mode Failure effect

23. IOC output dis- Fail all BIT, ISA and Undetected first failure Crete section failure annunciation output discretes of one l?LCC to no change

24. ISA output Incorporated in compo- Not applicable discretes nent no. 23

25. Failure Incorporated in compo- Not applicable annunciation nent no. 23 discretes

26. BIT output a. Landing gear handle a. Lateral-directional IBU fail- discre tes discrete BIT in- ure on landing ject b. Analog input BIT b. ‘Ripple A-D failure tree, plus inject switching to backup coils hardware in one FLCC C. IBU integrator BIT C. Pitch IBU failure inject

27. Data link Open both data link Branch failure including loss of transmi t ter lines from FLCC B one set of inputs, one CPU, and one set of outputs plus switching of one set of servovalve coils to the secondary coils

28. Data link Fail one receiver of Branch failure including loss of receiver FLCC B to status one set of inputs, one CPU, and good, data bad one set of outputs plus switching of one set of servovalve coils to the secondary coils

29. AMUX a. Status good, data a. Loss of AMUX plus command to bad on one bus ASB mode b. Good data on both b. Loss of AMUX and possibly buses one FLCC C. Bus contention C. Indeterminate, possible FLCC loss d. Accepting any ter- d. Indeterminate, possible minal address FLCC loss

30. IBU Incorporated in compo- Not applicable nent no. 26

31. LEF command Kill power to one motor Lock one motor drive servo TABLE 20. - CONCLUDED

Component Failure mode Failure effect

32. Runaway trim a. Nose-up Failure of stick trim switches b. Nose-down C. Right wing down d. Left wing down

33. Avionic a. FCC fail a. Force control of AMUX to SMS failures b. SMS fail b. Loss of MPD

34. Digital value a. Ramp on output of a. Simulated software error of actuator single surface causes TCO miscompare commands output command, channel B Hard-over output of b. Simulated generic software surface output error requiring manual commands by all selection of the IBU computers

TABLE 21. - REVALIDATION TESTS

Test 1 Verify DFCS and simulation interfaces pass preflight BIT 2 Verify mode selection and other base page options -MPD mode menu and CCV switches -DGFT/MSOV/CCV switches -HUD mission phase mode and CCV switch -Optimum flap-no scheduled flap -Drag modulation-drag conventional -Flatturn decoupled-flatturn coupled 3 Verify fault annunciation of DFCS inputs -Controller input failures -Switch failures -Sensor input failures (first and second like) 4 Verify preset decoupled options -Preselected pedal, stick, throttle options for decoupled ASG modes -Mode option changeability 5 Verify pilot input discrete -Landing gear up-down -Panel trim -Nose gear door open-closed -Stick trim 6 Validate take-off and landing performance -Stores-clean (standard normal) -Pitch rate reconfiguration (landing only) -Standby gains (landing only) -1BU (landing only) 7 High-performance maneuvers -Coupled maximum stick-rudder pedal-throttle twist commands (select modes) -Maximum altitude-speed loops (all modes)

76 TABLE 22. - IN-FLIGHT FAILURE INDICATIONS

F1i gh Number Description Cause Correction number

7 1 Indication of leading edge flap System Vote software failure on touch and go integration switches

15 2 Avionics forces rapid mode changes System inte- Avionics and in flight control system gration (not flight control rese ttable) immunity increased

23 3 Indication of one of three DFCS System Vote software branches failed; resettable integra tion switches by pilot

23 4 Indication that one branch had Not None failed to calculate horizontal repea table tail commands correctly; resettable by pilot

28 5 Indication that one branch had System Vote software failed to calculate left and integration switch right canard commands; resettable by pilot

36 6 Yaw departure results in failure System Air data rate indications for left and right integration of change canard actuators and air data; limited resettable by pilot. Investiga- tion on air data failure mode identifies single failure that can cause loss of DFCS analog backup

44 7 Dual branch failure of DFCS, air- System Vote software craft landed with single string integration switch control; failure not resettable

54 8 Failure indication that one branch System Vote software had failed to calculate its com- integration switch mand to the flaperons; resettable by the pilot.

66 9 Dual failure of an input discrete, Hardware Yes traced to loose contacts in a connector

82 10 Failure indication of left and System Discrete soft- right canard command in one integra tion ware switch branch; resettable by pilot

77 TABLE 22. - CONCLUDED

Flight Number Description Cause Correction number

~~~ ~~~~ 85 11 Indication of one of three Systern Vote software DFCS branches failed; integration switch resettable by pilot

91 12 Indication of one of three Unknown None DFCS branches failed; resettable by pilot; occurred during aircraft refueling

Various flights 13 Failure indications that an Unknown None

~ from flight 72 input discrete had failed; to flight 100 rese ttable by pilot; occurred five times

Various flights 14 Failure indication that Switch None I an input switch faded, design occurred upon activation of a cockpit switch; resettable by pilot; occurred many times

95 15 Failure indication of angle- Dissimiliar None of-attack sensor after angle-of - flying through wake of attack sensors another aircraft; resettable by pilot

TABLE 23. - BIT DETECTED FAILURES OF HARDWARE AND SOFTWARE

Number Description

1 BIT detected a faulty relay used in switching commands to the leading edge flaps 2 BIT detected failures of semiconductor random access memory at approximately 40°F 3 BIT detected failure of a semiconductor discrete drive used in logic that detects second failures of the computers 4 BIT detected a failure of a hydraulic actuator 5 BIT detected a parity error and would not finish BIT test; the parity error indication resulted from a software error in the BIT test for parity errors TABLE 24. - UNRESOLVED BIT FAILURE INDICATIONS

Number Description

1 One of the three computers failed during BIT; suspect cause was loss of power to channe 1 2 BIT failed numerous times while testing various DFCS components; EM1 was believed to be the cause

TABLE 25. - BIT FAILURES DUE TO SYSTEMS INTEGRATION

Number Description

~ 1 After tests to check battery power to the DFCS, BIT would detect failures of all input sensors 2 BIT software was unable to use back-up avionics bus in the event of a failure; resulted in pilot unable to monitor or operate BIT; system locked up 3 Accidental 2nd activation of BIT failed because of an unknown timing con- straint for BIT operations 4 BIT detects leading edge flap lock and input failures because of improper procedures 5 BIT indicated failures because of noise induced from running actuator tests, numerous accounts 6 A procedure error causes BIT to be run with failures present; resulted in BIT locking up 7 BIT fails to detect a fault in the IBU after a modification to the IBU was made; hardware modification did not have corresponding change in BIT test

TABLE 26. -ANOMALIES WITH MEMORY MODE OPERATION

1. One of three computers failed because of entering memory mode with control inputs; fault detection upon exit of memory mode causes interchannel differences 2. Engine start in the memory mode caused complete DFCS failure and hard-over canards to impinge on nose wheel door

79 r-. r-. r- b d 0 a 4J VI .4 [I) 6 0 H a cn $* 02 m k N m a, 3 h3 0 V I: a, 3 k 5 m * E . . 0 m .3 k 3 W z $* a cn w cn 5 3 a, 2 b F 3 ;17 P r- F mmomr-0 . 2 F c 0 0 0 z uw 0, H go2z u 3H z cnB 3 m m 4 F m m Glu . . OH 4 0 0 &F BH 2 zu uPlow cn cn zh 8B w cnz H ow mmmmmm PlH mmmcnmm m m ocn e..... 5 m. m. 000000 0 0 q w IB & . 3 co ai N 300300 d a,ooo)oo w dOOd00 2 4 c- a aooaoo-- 4J 4 a,-*aIrw W 4J h L .w cn cn iz mo tD 00 .O >( 00 00 a 0 0 xo' 4 N "Ln' I r-. N a, V w a I4 W a k k .4 5 2 a [I) 0 0 4J 4J k k -4 4 4

80 Figure 1. The AFTI F16 airplane.

Flight control panel switches Caution, warning, and stick_/trim :yrt rlrladvisory indication Triplex electrical commands

1 7 Aircraft -w /* -B DFCS complex RH horizontal ISA power Dual 28-V dc essential buses r---* Sensor power no. 1 no. 2 no. 3 j LH horizontal ISA Pilot inp- I 800 Hz I Three identical FLCC Triplex force sensors b One AIU :--RH flaperon ISA Signal selecting, voting, I monitoring Triplex rate sensors Multimode control laws Gain scheduling I I Stall-spin prevention Accelerations Triplex accelerometers Power monitors I Rudder ISA I-- - -* - Aileron-rudder I interconnect I Dual airflow sensors Structural filters

I I Air data Pneumatic sensor assembly I

LEF power drive Central air data computer LEF command servo

Aircraft dual Mode selection, hydraulic system Avionics -failure annunciation, -subsystems inertial references 7278

Figure 2. Digital flight control system architecture.

ORIGINAL PAGE BLACK AND W,HITE P,WTOGRAP.H 81 Single-channel design

Sensors Flight Actuator and - control interface controllers computer unit

J A -- Sensors - Flight - Actuator and I- control I- interface controllers computer unit

II I I ,I

Figure 3. Reliability requirements force redundancy.

Independent backup unit ,

I Primary DFCS I I

Figure 4. Independent back-up unit interface to the digital flight control system.

82 ‘haAnnelL Sensors and controllers A Flight control computer

Flight control computer

Chynel I Sensm1-4 Fligot control computer t \ \ \ .\ Chagnnel I Sensors anGoq-9 Flight control computer ,>-Serial, digital ,’ data links

ChannelSensors and controllers Flight control computer C I 1-4 t 7281

Figure 5. Architectural comparison of analog cross-strapping compared to digital cross-strapping .

From right channel

From left channel o Prefilter = - s+o s is a variable used - in a Laplace transform 20 / 50 radlsec 18 w = Central processor, 16 -Y 14 Military standard 15538 interface Failure logic 12 I Interchannel difference, 10 Input-output percent lntercomputer controller 8 I data links 6 Analog and Analog and 4 discrete output 4 Sensor sample discrete input and conversion and conversion sample period period 2

0 2 4 6 8 10 12 14 16 18 20 Independent Actuator kSample period, msec backup unit interface unit - 7282 - 7283

Figure 6. Interchannel difference for Figure 7. Flight control computer block 1000 percent/sec ramp. diagram.

83 00000 oooon

Multipurpose

? Programmable Programmable di s pI a y di s pI a y generator generator

Fire control computer Dual-redundant - HUD - stores management set Inertial navigation Head-up mode Primary control central interface unit unit display bus control Backup bus control - 1 1 7 1- - Avionics multiplex bus --- - 1 - r------I 1FC-b Control surface I Instrumentation DFCS complex Fire control - actuators (ISAS) radar Controllers I I Triply redundant I I Side stick digital FLCCs Leading-edge flap Pedals - actuators I I * Throttle Actuator interface unit I 1: I I Inertial Navigation Redundant inverters I I Rate gyros - Accelerometers I I I

Figure 8. Digital flight control system and interface with avionics.

84 ,- Wide-field

IBU

TRIM LYAW LWINGON

RYAW RWINGON up

7205

Figure 9. AFTI cockpit.

85 2

Pilot’s side-stick controller 1. Weapons release 5. Record-laser-gun 2. Trim (pitch and roll) 6. CCV 3. Designate or return to search or 7. IFFC (DFCS stick helmet-mountedsite limiting) 4. Nose wheel steering-air refueling 8. IBU disconnect-missile step

Functions common to F-16 and AFT1 F-16 Weapons release button Nose wheel steering-air Trim button (pitch and roll) refuel disconnect-mean Designate or return to search sea level step Camera-gun trigger

Additional functions peculiar to AFT1 F-16 CCVengage IBU engage IFFCengage

7286

Figure 10. Right-hand controller.

86 Mission specific modes

Pilot controller 7- Normal acceleration Normal acceleration Blended command Blended command Pitch stick command command

Roll stick I Roll rate command 1 Roll rate command I Roll rate command Roll rate command Decoupled Rudder pedals Rudder deflection Direct side force Direct side force Direct side force mode selection Throttle twist None None None None

Maneuver Maneuver Maneuver Maneuver Pitch stick enhancement enhancement enhancement enhancement

Roll stick Roll rate Roll rate Roll rate Roll rate

Lateral Rudder pedals Direct side force Yaw pointing Yaw pointing translation

Throttle twist Vertical Direct lift Pitch pointing Pitch pointing translation

7287

Figure 11. Control modes and controller commands.

87 (a) Vertical translation: ver- (d) Lateral translation: lateral tical velocity control at constant velocity control at constant yaw pitch attitude. attitude.

V y\ ,

(b) Direct lift: vertical (e) Direct sideforce: direc- flightpath control at constant tional flightpath control at zero angle of attack. sideslip angle.

7288

(c) Pitch pointing: pitch atti- (f) Yaw pointing: directional tude control at constant flight- attitude control at constant path angle. f1 ightpath angle.

Figure 12. Decoupled control descriptions.

88 HUD panel DFCS and avionics mode selection All mission-specific standard control modes

Left MPD Right MPD Independent DFCS mode selection Independent DFCS mode selection All mission-specific standard control All mission.specific standard control modes modes Stores - I management I Right-hand controller Avionics 1 Decoupled mode multiplex selection Throttle IBU selection Dogfight switch (discrete inputs) DFCS and avionics mode selection Air to air only Digital flight control system 7289

Figure 13. Flight control mode selection.

Action selects test page

f F FAULT DATA TEST PRSET AUTH FAULT OATA PRSET AUTH t NORM NONE GCMD MEMORY C0 N T EN T LOC RUD xxxx xxxx xxxx xxxx

FLAP BIT OPTIMUM

AUTO DRAG STORES MODUL

FCS FCS

FCS base page

PRSET preset RUD rudder AUTH authority MODUL modulation NORM normal LOC location GCMD G. command FCS flight control system (normal acceleration)

Figure 14. Multipurpose displays of digital flight control system base and test pages.

89 II FCS VID I II

PRSET preset AUTH authority ACK acknowledge VID video INU inertial navigation unit GBIAS G (normal acceleration) bias 7291

Figure 15. Multipurpose fault display.

90 Inter- computer data links

7292

Figure 16. Actuator interface to digital flight control system.

91 - tE E rI- I-

-f L

3 d 1 1 r

I I I I

92 I E

%I '1 1ur 1 4 u 'e b '1v 0 U

93 11-1

" Serial receiver Channel A Scratchpad sensors memory

ii'Processor Serial receiver I Channel B I I ,, I Scratchpad sensors Serial receiver f - FLCC B 1 I I 1 174Processor - - Serial receiver Channel C Scratchpad sensors memory Serial receiver

Figure 19. Cross-channel monitoring uses information sent on digital links.

C-3- 94 Central processing Input-output H unit (CPU) t controller and memory Input A i

Input B Fault detection Fail Fail Fault detection method method Input C /f-i-- Failurethreshold ; 1. Three or more + 1. Watchdog L Selected A + timer digital surface value 3 commands fail (good channel f- LAverage Of 4 2. Consensus of average) remaining good persistance I -A+B other two channels time - -2 channels frames=1/; I I 3. Self-test failure I declared (only used to I failed resolve failure w when two channels remain) 7297

Figure 20. Overview of good-channel- Figure 21. Logic used to determine average selection. a channel failure.

Sensor Analog multiplexer --c 1 -

Analog- CPU Digital- to operating to- digital built-in-test analog converter software converter - 2 - Sensor w 2 r . . I . BIT bias injection signals rlqSensor 1 7298

Figure 22. Bias injection to resolve sensor and input circuitry faults.

95 - Controllers - SP-pitch stick - SR-roll stick Decoupled Decoupled air- Decoupled air- Decoupled air- normal to-air gun to-surface gun to-surface bomb - P-pedals SP-FPME - T-throttle twist SP-FPME SP-FPMEIPRME SP-PRME SR-roll rate SR-roll rate SR-roll rate SR-roll rate - CCV.control configured P-pointing P-pointing P-flat turn vehicle T-translation T-pointing T-pointing T-direct lift - FPME-flightpath maneuver enhancement - PRME-pitchrate maneuver tt lever enhancement t t .c Standard Reconfiguration Standard air. normal Standard air- Standard air- Normal to-surf ace bomb SP-normal to-air gun to-surface gun acceleration SP-normal acceleration SP-pitch rate SP-pitch rate Pitch rate acceleration SR-roll rate SR-roll rate SR-roll rate Angle of attack SR-roll rate P-rudder P-flat turn P-flat turn Roll rate P-flat turn deflect T-none T-none Yaw rate T-none T-none - Landing

I I Independent backup unit (from any digital mode) 7299

Figure 23. Standard and decoupled mission specific control structure.

0SNRM gains EBlTransition region from bombs mode gains to normal mode gains nSASB mode optimal gains 50 -

40 N1 Mach number 10.00 ' I I 30 1 10.2) I Altitude, 5) I I ~ 7.50 1000 ft 6.90 20 5.83 4.60 4.60 4.01 4.14 3.45 10 2.00 3.10 1.67 1.10 n" 50,000 30,000 10,000 Sea 0 .2 .4 .6 .8 1.0 1.2 1.4 level Mach number 7300 Altitude, ft 7301

Figure 24. Bombing mode flight envelope Figure 25. Longitudinal feed forward and gain changes. gain N1 requiring double interpolation.

96 0Software components 0 Data base partitions - Component relations *--Data base relations ------I I I I 1 Executive data files

3 4' 51 Control System Selector ! AMUX I laws monitor monitor processor 1 [ I I I I AA A I I -_I 4'II 1 !.). I1 I II I I- ' I II ;; I I1 61 711 1 ll I Startup and Failure 1 ; ; ; I I I I I I I I restart 7- manager I I I III I_ I ;I j 1; I 4-L--L-l I L; I ------,------I ----- J I I_- J L A r

I 7302

Figure 26. Digital flight control system software structure.

I I Module PO4 I! I I ; PO401 I I I II ., I I I I I Note B I I -1,II L or I I Note W I or I A,,, recon I Note C I I :I +I I PO303 I P04V1 ; PO402 I c I I I I I I or I I 6-1 A, recon I I I I I I

I I I Filter I I I PO601 ! I I 7303 I

97 CPPS -Computer program product specification CPC -Computer program component OFP -Operational flight program V and V -Verification and validation Independent review I ,I r A I Module H stz:i~dH design through programming I 1

Code-unit Release to module test

4A Preliminary through Functional requirements are allocated to lcpcll pq computer program components (CPC) CPC-OFP update integration Functionally related 1 tasks comprise each module

Release to Logically distinct system level specific tasks V and V define each unit 7304 7305

Figure 28. Software design process. Figure 29. Top-down software structure.

Partitions are functionally related components

Components are functionally ( related segments ) (compynt) . ( 1 A 1 Segmentsphysically are related logically elements or (-) (Segment) . . . [)

Angroup element of words is a word or (-) (-) ("T""') ' (-) A offield bits is a bit or group (-) (ZT) (-)

Figure 30. Software data base structure.

I 98 Software design Test environment System Preliminary Unit specification design program Emulation of documentation product flight computer on software (mechanization specification gramming software development document) team package station Retest

r . Software

Triplex flight test to the Mechanization computer complex (updated)

Complete flight Discrepancy causes remechanization specification validation: control hardware (updated) FMET and with aerodynamic simulation FMET failure modes and effects testing FQ flying qualities testing

Flight qualified system 7307

Figure 31. System-software qualification and design iterations.

First flight AScheduled Actual A

Integrated A Scheduled Actual A system test (validation) complete 100 Stand-alone A Scheduled A Actual test 80 - complete - Complete, 60 First DFCS A A Actual percent - software Scheduled 40 release J I1 I I I I I I I I I I I I I I I I 11 11) 20 ONDJFMAMJJ ASONDJ FMAMJ J A I I 1981 1982 0 1234567a910 Time, mo Months from test initiation 7309 7308

Figure 32. Qualification schedule. Figure 33. History of software coding and testing .

99 100 - Originally

80 -/EzRePqEn scheduled date 100 - completion 60- 80- 7 Complete, Actual percent 60- 40- Complete, completion percent 40- 20- 20- Ill I Ill *

Figure 34. History of Software Figure 35. History of system verification. validation.

I Computer control I Strip-chart .t I- unit (CCU) AIU I recorder - + OFP loading FLCC A I - - I Strip-chart + OFP patching I- recorder FLCC monitoring FLCC B I - - I FLCC control I FLCC C Recording - - I FLCC interface ETSE input-output I malfunction fault I insertion panel t test panel I. Multiplex Redundant input I Redundant input interface bus simulation and output FLCC ahd output simulation interface simulation - Test voltages Bias test voltages - Transmit and - Multiplex Failure mode Failure mode receive single +. I analyzer Simulation - simulation I I message I Bus control Switch from I ttt -- Bus monitor FLCC A I I RM test to FLCC B I 4 - I signal Single word I generator d is p Ia y I Manual control I Avionics I multiplex bus I I

7312

Figure 36. Support equipment for verification testing.

I 100 L Programmable Stores Fire control FCC display management computer generator (PDG) - support set (SMS) (FCC) t4 44- 941 AMUX * interface -Strip-chart recorders Cockpit ETSE- FLCC FLCC interface Patch panel Computer system FLCC interface malfunction and cockpit MPDs, HUD interface - monitor fault insertion - interface Dual mainframe Stick panel panel - - computer with Pedals peripherals Throttle twist tw 4 Relative geometry Linear throttle INU, radar ADI, HSI Simulated analog ISAs Air-to-air target Rpm indicator FLCC A Left horizontal tail Altimeter Air-tomground target Right horizontal tail Real-time scoring Mach-airspeed m Left trailing-edge flap Data acquisition Angle-of -attack Right trailing-edge flap indicator Data display Angle-of-attack Left canard Initialization Right canard Visual system drives indexer - Rudder Interface software t Video

Visual system Scan converter (525 line) Light projector Target projection system - 1 Earth-sky-horizon projector picture SMS and PDG Visual interface system - emulator 7313 Figure 37. Validation support equipment.

101 1.6150,OOO) (1.2150,OOO)

Pressure altitude, 30 (1.6130,OOO) 1000 ft 40i

(1.411 0,000) 2ol:10 1 0 0

Mach number 7314

Figure 38. Phase 1 stress test conditions.

Point A Mach 1.2 at 500 ft, maximum g, 90' pitch up Point B Perform desired maneuver from table Point C Pitch over to -90" pitch attitude Point D Perform desired maneuver from table Point E 11,000 ft begin maximum g pullout Point F Mach 1.215000 ft, reset Note: Throttle set at maximum afterburner power throughout test trajectory for phase 2

50,000

40,000

Pressure 30,000 altitude, ft 20,000 B

10,000

500 - Downrange 7315

Figure 39. Stress test, inside loop.

102 103 Aircraft sensors laws T I Airframe I 7311

Figure 41. Setup for structural coup1 ing tests.

Lateral Rudder commands Rudder commands accelerations before fix after fix 30 1.2 r deg 0 deg 0 A

-1.2 u - 30 - 30 30 30

r FLCC deg 0 B

-1.2 I- 30 -30 w

30 30-

l.* r FLCC deg 0 C

- 30 -1.2 u - 30 u b I Time 7318

Figure 42. Gunfire test data.

104 Design change required -,

New Analysis Hardware Inspection hardware + and -c modlflcatlon system update design or fabrication requirement * asgs",$&

Discrepancy Discrepancy noted + report - analysis

New Analysis Documen- Assemble Vehicle software c and tatlon new 4 preflight - test test system design update release requirement - *

Software Validation Flight change test test notice - 7319

Figure 43. Configuration control process.

I I I I I I Delay 1 I I T12 I 30 TXX Software I 0.0 -t B 1 I - 0 I release no. 1-1 - 21.5 I 1 I Limiter I i?i I 20 I To Flights I control Per I surfaces mo. 10 - G--I T3 - i 1 T4 I T7 Proportional + integral 1 .J 0 0 7 4 9 0 20 14 27- steady-state decoupling JASONDJFMAMJJ 1982 1903 I From 1 dback 7320 sensors 7321

Figure 44. Flight test sunmary. Figure 45. Example of a software switch used in the control laws.

105 28 v Power Regulated 28 V sources emergency generator output * -Engine Emergency Unregulated permanent bleed air power magnet generator Overvoltage unit ac voltage detected 1___ Hydrazine 1 and 1 \ [YE'- /*------turbine generator converter - Normal operation 80-percent throttle

Time 7322

Figure 46. Overview of electrical system overvoltage shutdown.

Air data sensor A, nose boom Air data sensor B. nose boom

Selected air data Normal , acceleration, f Scales 9 -2 1 sec Random in are not Computer A, gain update -4 time due to -6 relative Computer B, gain update asynchronous Computer C, gain update I j operation -20 - -15 - -10 - ComDuter A. surface command -5 - Computer B, surface command- Sideslip, 0 - Cornouter C. surface command I deg 5- 10 - I 15 - 20 - - 25 to + 0.25 sec to + 1.0 sec Time 7324

Figure 47. Normal acceleration and Figure 48. How an air data failure sideslip of flight 36 yaw departure. causes errors in surface commands.

106 Digital 20 -Channel A commands for right flaps, deg -20

Channel C Digital 20 r- commands for right flaps, deg -20 *

Selected 640 r- Average of 37 rAverageOf

value of 1 sec dynamic 400 pressure, 350 -

Figure 49. Air data transients and effects on surface commands.

1982 1983 I - s- s- Rpr Ma) -uric ware relec Flights 1-9 I '02 Not flown A TO3 Flights 10.15 c Flights 16-25 I

Flights 26-35

Flights 36-39 Flights 40-48 '08 Flights 49-56 rn n To9 Flights 57-77 I- I '10 Flights 78-86 I a- Flights 87-96 m

Flights 97.101 13 Flights 102.118

7326

Figure 50. Software release sumnary.

107 D64 Rudder structural breakout limits 25.0

D64

Rudder 14.0 command, 12.5 deg 9.0 7.0 5.0 2.5

qc, lb/ft2 7327

Figure 51. Rudder limit used to implement vertical tail load limiting.

I ClO! I D69 I c Rudder pedal 20 - 20 x 2.5 - -10 command input = 20 Ib S I I - I I S - fault I I I Airspeed inputs I Channel = knots tional'bl&ks I A 175 I B 172 I I Channel A I Channel A I C 170 2.6 -1 Channel A I I I Normalized Channel B 32 O Canard jl). I outputs command, 2.6i I to canard Channel C Channel B Channel B I 52'1 surface deg 1.0 I 20O I 1 I I I Channel C .8O Channel C 0 Pool I -1 D69 output values I Outputs after I 01234 I for corresponding integrator Frames (time) airspeed inputs I I I I Output values sent to fault detectlon routines 7328

Figure 52. Summary of conditions causing flight 44 anomaly.

108 ORIGINAL PAGE IS OF POOR QUALtTY

A-

I I I I I I I I I I I I I I I I I I I I I I I I -- - i------I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I- I I I ++-I-, I I I I I I I I I I I I I I I I I I I r-- I I I IZ I I I I I I I I I I; I I *I I I I I I I I ;f€lf I I I I I: I L----- . ------I

109 r I E;I -

h z-- I 1

110 I Y07K3 I I I I I I I I I Y07K1 Y07V1 I I I I I I I I I I I I I I I I I I I Absolute Positive I I value value I I

Figure 55. Angle-of-attack gain to aileron-rudder interconnect.

PO701

Limiter I Fixed Y07K3 gain

Y07V1 Variable l- gain'171 Absolute I Positive value Y07K1 value 7332

Figure 56. Control law module broken into individual blocks.

111 Report Documentation Page

1. Report No. 2. Government Accession No. 3. Recipient's Catalog No. NASA TP-2857

5. Report Oate November 1988

6. Performing Organization Code

8. Performing Organization Report No. H-1344

10. Work Unit No. RTOP-999-12-08

11. Contract or Grant No.

13. Type of Report and Period Covered Technical Paper

14. Sponsoring Agency Code

16. Abstract

I Engineers and scientists in the advanced fighter technology integration (AFTI) F-16 program investigated the integration of emerging technologies into an advanced fighter aircraft. AFTI's three major technologies included (1) flight-crucial digital control, (2) decoupled aircraft flight control, and (3) integration of avionics, flight control, and pilot displays. In addition to investigating improvements in fighter performance, researchers studied the generic problems confronting the designers of highly integrated flight-crucial digital control. The author provides an overview of both the advantages and problems of integration digital control systems. An examination of the specification, design, qualification, and flight test life-cycle phase is provided. An overview is given of the fault-tolerant design, multimcded decoupled flight control laws, and integrated avionics design. The approach to qualifying the software and system designs is discussed, and the effects of design choices on system qualification are highlighted.

17. Key Words (Suggested by Author(s1) 18. Distribution Statement Flight control I Unclassified - Unlimited Flight test validation ve r i f ic a t ion Subject category 08

19. Security Classif. (of this report) 20. Security Classif. (of this page) 21. No. of pages 22. Price unclassified unclassified 116 A0 6

NASA FORM 1628 OCT 88 *For sale by the National Technical Information Service, Springfield, Virginia 22161

NASA-Langley, 198