percentage or an absolute value. For each test run a
`complete set of comparsion statistics is generated
`and test points failing the tolerance criteria are
`highlighted.
`In addition, COMPEX produces a file
`containing the test conditions, the respective results
`and the amount out-of-tolerance in the same format
`as the test results and expected results. This file
`format is unique because it allows nearly immediate
`graphical analysis of the data at Interactive Graphics
`and Data Analysis sites located throughout
`the
`company.
`
`The test case inputs, BSP execution output, expected
`results, test results and comparsions are archived in
`summary hardcopies, and in detail on microfiche and
`magnetic tape.
`All previous test points can be
`accessed and reviewed to analyze software changes
`or to re-create previous test conditions. The basic
`flow of data through the performance validation
`system is shown in Figure 4. with the exception of
`operator commands to initiate the individual steps,
`the procedure is fully automated from entry of
`the
`BSP-format
`inputs into the mainframe computing
`system until
`the test
`report
`is ready for
`final
`analysis.
`
`Execution
`Outputs
`
`
`
`
`
`BSPS
`Execution
`
`Expected
`Results
`
`BSP
`InputFHe
`
`PVTS
`BenchTest
`
`
`
`Test
`Results
`
`
`
`
`
`
`
`
`COMPEX
`Execuuon
`
`Figure 4 Test Procedure Flow
`
`Validation testing of the 737-300 Flight Management
`Computer has been at
`least
`a
`six-day-a-week,
`sixteen-hour-a-day effort
`since early in
`l984.
`
`323
`
`BOEING
`
`Ex. 1031, p. 382
`
`Actual operation of the Performance Validation Test
`System is in two steps. The first stage reads the
`Boeing Standard Program-formatted input files and
`produces a command file that describes the test
`conditions in a language familiar to the second stage.
`A PVTS data base maintains information on the name
`and numerical conversions required to translate the
`inputs. This first step is typically accomplished off
`the test bench prior to the actual test session.
`
`The second PVTS stage is executed on one of two
`737-300 FMCS test benches using the previously-
`generated command file.
`Computer Control Unit
`the
`(CCU)
`commands
`set
`appropriate
`program
`counters, breakpoints and test conditions
`in the
`Flight Management Computer for each test procedure.
`The OFP is then executed and the test
`results
`recorded. The memory locations of FMC variables and
`modules are determined from the Lear Siegler symbol
`table routines mentioned previously.
`
`The development of the Performance Validation Test
`System (PVTS) was in three phases to support
`the
`three phases of
`the performance function plan of
`test. Phase I development was designed to execute
`individual data base modules
`and therefore
`is
`specialized for each test procedure that
`tests a
`separate
`operational
`flight
`program
`(OFP)
`computation.
`Phase II of
`the PVTS development
`concentrated on the the flight phase test cases
`where a single module calls the execution of several
`other modules. This required additional PVTS logic
`to
`capture
`and
`interpret
`the
`integration—
`by-integration results of the OFP. The final phase of
`PVTS work required a separate Cockpit Display Unit
`(CDU) keypush driver. The keypush driver enters the
`required flight plan information via the CDU and the
`PVTS captures the mission information as it is built
`in the OFP.
`
` . After the
`test results are obtained from the Performance
`Validation Test System,
`they are transferred via
`tape back to the mainframe computing system where
`the expected results are stored after being generated
`by the Boeing Standard Programs. The test results
`are compared to the BSP expected results by COMPEX.
`COMPEX is a point—by-point comparator and report
`writer program developed as part of
`the 757/767
`BSP project. On a database level, the comparsions
`are one-to-one and required to be exact (allowing
`only for computer round-off errors). For the flight
`phase and mission test cases, COMPEX interpolates
`the more dense expected result file to compare the
`test
`and
`expected
`results
`at
`the
`same
`test
`conditions. Tolerances can be defined as either a
`
`BOEING
`Ex. 1031, p. 382
`
`

`
`Aclsnomtedgments
`
`While it is not possible to thank everyone involved in
`this project, the efforts of B. Blair in developing the
`Boeing Standard Programs, and the efforts of K. Singh
`and J, Weston in Performance Validation Test System
`development must be recognized.
`The author is
`grateful
`to them and the scores of others that
`contributed to the success of
`this program.
`The
`author would also like to thank the FMC vendor, Lear
`Siegler, Inc., for their outstanding support.
`
`Nearly one hundred performance function tests, each
`with about ten separate cases and over one hundred
`test points, have been designed,
`executed,
`and
`analyzed in this period. The sheer volume of testing
`accomplished to date
`clearly demonstrates
`the
`capabilities of the system. But this level of detail
`and test rigor has not come at the expense of scarce
`engineering or laboratory test bench time. While
`nearly a
`third of
`the planned 737-300 Flight
`Management Computer testing is in the performance
`functions,
`less than a tenth of
`the scheduled test
`
`assigned to performance
`been
`bench time has
`function testing. Using the Performance Validation
`Test System,
`the
`complete Flight Management
`Computer performance data base
`(including all
`aerodynamics, propulsion, and atmospheric data) can
`be interrogated in less than eight hours.
`No user
`interaction is required to execute the over fifty
`complete and separate tests designed to rigorously
`exercise the operational flight program performance
`data base software. Often this testing is completely
`unattended and is accomplished between the hours of
`midnight and 8:00 AM, while the test bench would
`normally be unused.
`
`Test analysis has kept pace with the rapid rate and
`high volume of test results. Test reports are nearly
`all complete the week after a series of twenty or
`more tests are run. Further, the test documentation
`is far more detailed and complete than has been
`possible on previous programs. This is expected to
`have a
`large payoff
`in the future in update or
`modification validation efforts.
`
`CQDQJLISIQDS
`
`The above described procedures and testing tools
`have been highly successful
`in the 737-300 Flight
`Management Computer validation program. By taking
`a "user-based" and integrated approach to the test
`system design, validation
`of
`the
`performance
`functions has been transformed from the "most
`
`risky" area of the 737-300 FMCS testing to one of
`the
`"least
`risky."
`Further,
`testing rigor
`and
`documentation have been enhanced while the tester
`
`is freed from the laboratory to concentrate on test
`analysis. More traditional approaches to software
`validation could not have suceeded under the time
`
`the 737-300 program.
`and budget constraints of
`Even without those constraints,
`it
`is unlikely that
`manual testing methods could have provided even a
`small fraction of the results already produced. The
`above described approach has proved to be a very
`efficient and effective technique for the validation
`testing of the 737-300 Flight Management Computer.
`
`324
`
`BOEING
`
`Ex. 1031, p. 383
`
`BOEING
`Ex. 1031, p. 383
`
`

`
`A METHOD FOR TESTING A
`DIGITAL FLIGHT CONTROL SYSTEM WITHOUT
`THE USE OF GROUND SUPPORT EQUIPMENT
`
`84-2664
`
`H. E. HANSEN, LEAD ENGINEER, ELECTRONICS
`MCDONNELL DOUGLAS CORP.
`ST. LOUIS, MO.
`
`Suflace
`Commands
`CYBER
`
`
`- Equafions
`of Motion
`
`
`
`
`Suck
`_ Rudder
`Dome, ’ ’ and Power
`
`Cockpn
`- Pnm
`
`\
`
`and
`‘~___Rwdm
`
`
`
`GP-13 D648 3 Fl
`
`Figure 1
`Block Diagram Man-In-Loop Simulator
`
`limited research project would have been too costly
`and time consuming. Nevertheless, it was extremely
`important
`to verify proper integration of
`the DFCS
`and the input signals.
`
`During lab testing, a Digital Development Set
`(DDS) was used to interrogate memory to check the
`input signals.
`The DDS consisted of a computer
`(PDP 11/34), a Keyboard to input commands, software
`(operating system)
`to process those commands, an
`output device (CRT)
`to observe the contents of
`memory and a link (data bus) between the computer
`and the DFCS.
`The F-15 test bed had a computer
`the Central Computer
`(CC). Functionally,
`the DDS
`could have been used for DFCS checkout at the
`aircraft. However,
`the DDS consisted basically of
`commercial equipment designed for a laboratory
`environment.
`To ruggedize this equipment for
`flight line use would have been too costly and time
`consuming. Consequently it was necessary to use a
`different approach.
`
`the standard F-15
`It was observed that
`equipment could be adapted to serve as the controls
`and displays to a self-contained DDS;
`the
`Navigation Control Indicator (NCI) panel could
`serve as a keyboard and the Vertical Situation
`Display (VSD) could serve as an output device,
`while the MIL-STD-1553A multiplex bus was
`the data
`link between the CC and the DFCS.
`The only missing
`element was
`the software which could use this
`equipment
`to verify the integration of
`the DFCS
`with the aircraft. This paper describes how,
`through use of standard F-15 equipment and the
`addition of
`the proper software,
`the F-15 test
`aircrft was transformed into its own self-tester.
`The software that uses the resident equipment
`to
`convert
`the airplane into a self-tester is referred
`to as "Maintenance BIT" and "Preflight BIT". That
`software will be described in detail.
`
`BOHNG
`
`Ex.1031,p.384
`
`ABSTRACT
`
`On 26 May 1983, a McDonnell Douglas F-15 Eagle
`fighter became the first to fly with a Digital
`Flight Control System (DFCS) programmed in a higher
`order language.
`The topic of this paper is the
`testing of
`the F-15 DFCS prior to that historic
`flight. Laboratory testing procedures and test
`equipment are described. Testing at the airplane
`is the major emphasis, describing the equipment
`resident on the airplane and the software, dubbed
`Maintenance BIT,
`that was used to transform the
`airplane into its own self-tester. Also covered
`are actual examples of how Maintenance BIT was used
`to solve problems at the airplane that might have
`been difficult or impossible with special
`test
`equipment. Other accomplishments resulting from
`this approach are also enumerated.
`
`Introduction
`
`technological
`Recognizing a number of
`advancements were occurring which could importantly
`affect the direction of digital flight control
`system (DFCS) design in the near future,
`the
`McDonnell Aircraft Company initiated an Independent
`Research and Development
`(IRAD) program in the
`summer of 1981 designed to assess advancements in
`the following technology areas: microprocessors,
`higher order languages (HOL's), floating point
`arithmetic, and parallel processing.
`1
`
`The particular hardware configuration that
`served as the supporting system for technology
`evaluation is built around the present F-l5 Eagle
`Dual Control Augmentation System (CAS). This was
`done for two reasons:
`the electronic portion of
`the
`CAS could be modified at minimum cost/time to
`provide all of
`the required digital features; and,
`the system could be flight tested with minimum
`aircraft modification.
`
`the DFCS included
`The software testing of
`static gain checks,
`frequency responses,
`integration in the F-15 hydraulics lab and
`evaluation by experienced F-15 test pilots in a
`simulator. This latter test, depicted in Figure 1,
`allows the pilot - should he suspect an anomaly in
`the DFCS -
`to immediately make a comparison with
`the production flight control system. These tests
`demonstrated that an F-15 with the DFCS would
`perform exactly like production F-15's that have
`analog Flight Control Computers, if the DFCS
`performed in the aircraft as it had during testing.
`This could happen only if the more than 100
`discrete and analog signals were brought into the
`DFCS in the memory locations expected by the
`Software.
`
`Traditionally, special support equipment has
`bfen used to check for proper operation at the
`aircraft. Developing such equipment for this
`
`C0Pyrigh! © American Institute of Aeronautics and
`Astronautics. Inc.. 1984. All rights reserved.
`
`325
`
`BOEING
`Ex. 1031, p. 384
`
`

`
`System Description
`
`The flight control hardware configuration that
`served as the supporting system for this project is
`built around the present F-15 Eagle Dual Control
`Augmentation System (CA5).
`The present production
`F-15 control system is shown in Figure 2.
`The CAS
`Computers have been modified by replacing the
`existing dual analog computers in each Line
`Replaceable Unit (LRU) with two digital processors
`(Z8002 microprocessors)2, associated memory (24K)
`of PROM, 2K of RAM and 1K of Non-Volatile Memory
`(NVM)) and converters.
`The
`modifications were carried out by the Astronics
`Division of Lear Siegler Corporation, Santa Monica,
`and are described in detail in Reference (3).
`
`is designed so that software in
`1553A Multiplex Bus
`the CC and firmware in the DFCS control
`the flow of
`data between the DFCS and the CC. Therefore the
`DFCS software can communicate with the CC merely by
`putting data into and removing data from predefined
`buffers in the DFCS memory.
`
`The Navigation Control Indicator (NCI) Panel
`is pictured in Figure 4.
`Information consisting of
`up to five digit numbers may be entered thru the
`North (N) and East
`(E) windows from the NCI Panel
`into the CC.
`By selecting the proper Mode, Data
`Select and Dest Data switches these data may be
`interpreted as commands for the CC and DFCS much as
`typical computer operating systems - UNIX, RSXllM,
`etc.
`- do.
`The principal difference is the
`
`
`I
`'
`
`..j Eieriv-rm
`Mernan-/al
`Auemn rul11ur .nrevr"nne l
`Am
`cssac
`Conlml SIACH boost and D'|r:h
`FRAD
`Pllch tall
`:m;u=.I dew»
`Pilrn mm controller
`PYC
`mu val n aawsl OEVVCE
`mam
`Valve
`AF1
`Aclualrr
`Ele-unnpnaul : um:
`Env
`Conlruviugmehlmliv-n vsicm
`
`'>r|'\DelVLJlOV
`
`Voting Plane B
`
`_ _, »—\
`l“’\~ .
`
`|,._
`
`Cenler
`Stick
`
`r— ’$ ‘ '7
`V
`
`[
`
`C. rs,
`l
`
`\g
`
`__.
`
`__
`
`V L
`
`ateral
`Accel
`
`Acceleration
`
`Unit
`
`'
`Voting Plane A
`Votmg
`ane
`GP43-0648-7-R
`
`
`P]
`
`B
`
`Figure 2
`F-15 Present Mechanical and Dual Command Augmentation Flight Control System
`
`The resulting system is a parallel processing
`system with the Operational Flight Program (OFP)
`partitioned by control axesh.
`Two processors
`operate on the pitch axis software and two operate
`concurrently on the roll/yaw software.
`The two
`pitch processors are frame synchronized, as are the
`roll/yaw processors;
`the pitch processors, however,
`are unsynchronized with respect to the roll/yaw
`processors.
`The dual processors in the pitch and
`roll/yaw axes are consistent with the dual
`(fail-safe) nature of
`the F-15 production CAS.
`
`The DFCS is connected to the F-15 CC via the
`1553A Mux Bus and the NCI and VSD are connected to
`the CC via the H009 bus as shown in Figure 3.
`The
`
`the commands in
`the hardware, i.e.,
`constraints of
`this case must be numbers instead of acronyms.
`This has not been any real encumbrance in the use
`of Maintenance BIT.
`The two NCI windows may be
`used for commands or for a command and for data
`read out from the CC. This function will be
`covered in more detail
`in the discussion of
`Maintenance BIT software.
`
`The Vertical Situation Display depicted in
`Figure 5 has an 18 character alpha numeric buffer
`and serves to read out
`in edited format information
`from the DFCS. This along with the NCI
`(which can
`only read out unedited data) forms the system's
`display units.
`
`326
`
`BOHNG
`
`Ex.1031,p.385
`
`BOEING
`Ex. 1031, p. 385
`
`

`
`- Z8002 Microprocessors (4)
`- PASCAL OFP
`
`CAS Sensors
`
`Pitch AFCC
`
`Stabilator
`Actuators
`
`
`HUD
`
`H009 Bus
`
`Central
`Computer
`(CC)
`
`
`
`VSD
`
`NCI
`
`
`
`
`
`Rudder
`
`Acmators
`
`GP43-0648»B»R
`
`Roll and
`Yaw B
`
`1553A Bus
`
`CA8 Sensors
`
`Instrumentation
`System
`('8)
`
`
`
`Figure 3
`
`._.
`Description of Maintenance BIT
`
`The general features of Maintenance BIT are
`illustrated in Figure 6.
`The major features are
`identified by the following level numbers.
`
`Level 1: This level of maintenance BIT
`consists only of software changes to the Central
`Computer (CC).
`In the normal cycling of
`the
`Control Laws
`(CL)
`in the Digital Flight Control
`Computer
`(DFCC), various measurand data are
`continuously sent across the MIL-STD-l553A
`
`engineering units that are easily read on the VSD.
`The parameters are divided into several lists.
`the
`Each list of data can be selected from one of
`four DFCS computers.
`A list has approximately 10
`parameters in it.
`The parameters in each list are
`displayed successively on the VSD.
`Each parameter
`in the list is displayed for about
`three seconds
`until
`the next parameter is cycled onto the VSD.
`The list repeats itself until
`the option is
`To
`disengaged or a different list is called up.
`choose a parameter list, a code is entered through
`
`Code
`
`Data Displayed on VSD
`
`5
`a
`
`
`
`DATA SELECT
`
`ALIGNj|-—NAV
`Ema GC ms
`O srav
`A/D
`OFF
`L
`“$3,
`TEST
`
`’[:ST
`O5
`
`5
`
`5
`
`5
`
`5
`
`5
`5
`
`5
`
`5
`
`1
`
`2
`
`3
`
`4
`
`1
`2
`
`3
`
`4
`
`0
`
`0
`
`0
`
`0
`
`1
`1
`
`1
`
`1
`1
`
`Navigator Control Indicator
`
`'
`Figure 4
`Maintenance BIT
`Code for Level 1
`
`Variables From Pitch Channel A
`
`Variables From Pitch Channel B
`
`Variables From Roll/Yaw Channel A
`
`Variables From Roll/Yaw Channel B
`
`Discretes From Pitch Channel A
`Discretes From Pitch Channel B
`
`Discretes From Ro|lIYaw Channel A
`
`Discretes From Roll/Yaw Channel B
`Menu
`Channel
`VSD Display
`
`GP43-0648-6-R
`
`multiplex bus for instrumentation purposes. With
`this feature of Maintenance BIT,
`the CC takes
`selected measurand data and displays it on the
`Vertical Situation Display (VSD) as shown in Figure
`5-
`The CC receives the data and transforms it into
`
`The CC receives the code from the
`the NCI panel.
`NCI over the H009 Multiplex Bus.
`The NCI panel
`with an example code is shown in Figure 4. This
`feature of BIT doesn't affect the cycling of the
`control
`laws in any manner,
`so it can be used
`
`327
`
`BOEING
`
`Ex. 1031, p. 386
`
`BOEING
`Ex. 1031, p. 386
`
`

`
`in-flight as well as on the ground to monitor the
`flight control parameters in the measurand list.
`
`Level 2: This feature of Maintenance BIT
`allows the operator to position aircraft control
`surfaces to selected positions to check the
`computer/control surface interface.
`The surface
`positions can be moved with a resolution of
`two
`
`the DFCS channels is entered
`location in one of
`the
`The CC takes the contents of
`through the NCI.
`The
`address location and displays it on the VSD.
`data is updated at 20 Hz so that changing numbers
`can be tracked.
`
`Unacceptable or illegal commands present no
`problems to the user: Maintenance BIT merely waits
`_ _ _ _ _ _ _ _ . . . __.
`
`AmhaNumenc
`Dmpmy
`
`I
`Ir LonStkF=10|bAft
`_ _ _ _ _ _ — — — — — ——-I
`L
`
`OOO
`
`r - ’ — ‘ ‘ - “ ' “ ' ’ "1
`ILSmb%s=wdwUpI
`_ _ _ _ — _ — — — — — —--l
`L
`
`oIO
`
`
`
`r — - * - ‘ ‘ ’ ' ‘ - — "1
`IRStabPos=15degUpI
`_ — — — — — — — — — — ——"
`L
`
`oOO
`
`r — - - - - - - - - - - --N
`I MwhRme=0demwc
`I
`— — — — — — — — — — — —-—-J
`L
`
`oOO
`
`r — - — - ' ‘ ' * “ ' " ““‘
`I
`AOA=-+17deg
`I
`L _ _ _ _ _ _ — — — — — --4
`
`Vertical
`Snuafion
`D(iVS§||3ay
`)
`
`onro
`CNatV !
`Indicator
`(NCD
`
`Central
`C°(rg%L;ter
`
`DigHa|FHght
`Control Computers (DFCCS)
`Lon Stk F
`L Stab Pos
`R Stab Pos
`Pitch Rate
`
`GP43-0648-SR
`
`! i J
`
`Figure 5
`Maintenance BIT
`LeveI1
`
`Surface position is entered
`percent of full scale.
`through the NCI.
`The CC takes the data via the
`H009 multiplex bus and sends the commanded position
`over
`the MIL-STD-1553A multiplex bus to the DFCS.
`Level 2 can only be initiated on the ground when
`the aircraft is weight—on-wheels and the BIT
`consent switch is on.
`
`Level 3: with this feature any memory address
`in any of
`the DFCS channels can be read out.
`The
`address and desired DFCS channel are entered into
`the NCI.
`The CC takes the address and requests the
`particular DFCS channel
`to send the contents of
`the
`location to the CC over the MIL-STD-1553A multiplex
`bus.
`The CC takes the address contents and
`displays it on the VSD.
`The NVM contains various
`test routines and data logs.
`For quick changes in
`the NVM this feature of BIT allows the contents of
`NVM to be changed. Thus, changes in various test
`routines can be made without having to remove the
`memory boards to the flight controls lab.
`
`Level 4:
`This feature allows a memory
`The address of a
`location to be read in real
`time.
`
`for an acceptable one. Also it should be pointed
`out
`that non—passive commands, such as alter
`Non-Volatile Memory, require special acceptance
`procedures thus ensuring that they are not invoked
`accidentally. Maintenance BIT is very closely
`associated with and complements Preflight BIT in
`the flight testing phase of
`the program.
`The
`general features of
`the Preflight BIT used on the
`DFCS program are illustrated in Figure 7.
`Description of Preflight BIT
`
`Preflight BIT is designed to test various
`safety monitors in the Digital Flight Control
`System (DFCS). Preflight BIT is implemented
`interactively by an operator in the cockpit using
`the CAS Control Panel.
`
`F-l5 Flight Control System (FCS) consists of a
`mechanical system and the CAS.
`The CAS is fail-
`safe.
`Should the CAS shut down, meaning the
`surface commands are centered,
`the mechanical
`system is still in operation.
`The production CAS
`is implemented in a dual channels per axis
`
`328
`
`BOHNG
`
`Ex.1031,p.387
`
`BOEING
`Ex. 1031, p. 387
`
`

`
`Examples of failures that
`and shut down the CAS.
`could prevent normal program cycling are a memory
`alteration sending the CPU into an invalid region
`of memory resulting in the CPU halting or looping
`infinitely.
`The CPU could also have a failure
`which halts the CPU. Here again the WT will
`quickly shut
`the CAS down.
`
`There is a known sequence of CAS shutdowns and
`resets that occur during the running of Preflight
`BIT. After the last reset the CAS will remain
`engaged and begin cycling the Control Laws.
`Preflight BIT indicates a problem if the exact
`sequence of CAS shutdowns and resets cannot be
`completed.
`
`Interaction of Preflight BIT and Maintenance BIT
`
`If a problem is discovered by Preflight BIT
`then Maintenance BIT needs to be invoked and
`An
`extensive trouble shooting can be performed.
`example of such a problem occurred in the lab with
`the arrival of a new DFCS.
`On running Preflight
`BIT, a problem with the Stabilator shutdown in
`tests
`voting plane A was observed. Stabilator fail
`using Maintenance BIT were performed, and it was
`noted that
`the left stabilator could go full
`
`- Test ls Intended Primary for Use by Pilot andlor Ground Crew as a
`Pre-Flight Check of Proper Operation of Fail-Sale Features
`
`- Tests Hardware Associated With Fail-Safe Monitors in FCS
`
`— Checks Circuitry Associated With Control Law CAS Shutdown
`— Checks Ability of Watchdog Timer to Shut Down CAS
`— Tests Hardware Monitoring at Actuator Level
`
`- Test is a Series of Apparent CAS Shutdowns With Associated
`Resets
`
`0 Entire Procedure Takes About 1 min and Uses Only Reset
`Switches on the CAS Control Panel and Lights on the Warning
`Light Panel
`GP43-D648-2-Fl
`
`Figure 7
`Overview of Pre-Flight BIT
`
`authority down while the right stabilator remained
`in neutral and no shutdown occurred. With this
`analysis in hand the problem was very quickly
`traced to a grounded wire leading to the Pilot
`Reset Switch (Figure 8).
`Thus the CAS was
`continuously being reset before the disengage logic
`in the hardware could shutdown the CAS.
`
`Other Examples of Maintenance BIT
`
`the DFCS into the
`After the installation of
`aircraft, but prior to the first flight, a constant
`rudder oscillation was noticed whenever
`the DFCS
`was
`turned on.
`The oscillation was judged too
`serious to fly with. After watching the inputs
`from various A/D's into the yaw channels, it was
`surmised that
`the problem might be caused by noise
`on an A/D.
`Since the A/D's were multiplexed,
`the
`noise on all yaw inputs should be the same (there
`were only two bits of noise anyway)
`- it was
`suspected that one or more of the paths in the Yaw
`axis could not tolerate any noise at all.
`A
`procedure was set up using Maintenance BIT that
`would allow selective removal of noise from any or
`all inputs in any desired combination.
`By this
`procedure it was determined that yaw rate was
`the
`
`329
`
`BOHNG
`
`Ex.1031,p.388
`
`
`
`Level 1
`- Allows Selected instrumentation Parameters Sent on 1553A MUX
`Bus to be Displayed on Aircraft Vertical Situation Display (VSD)
`- Parameter Menus Are Entered Through the Navigation Control
`Indicator (NCI)
`- Functions While Control Laws Are Cycling
`- Used on Ground to Check Sensor Inputs and Sensors-to-Control
`Surface Steady-State Operation and Gains
`0 Can Be Used in Flight to Monitor Control Parameters
`
`Level 2
`
`- Can Position Control Surfaces by Selected and
`Controlled Amounts
`
`- Can Fully Exercise the Watchdog Timer
`0 Initiated Only While Aircraft is on the Ground
`- Entry Made Through NCI
`- Used on Ground to Check Computer-to-Surface
`Actuator lnterface
`
`Level 3
`
`0 Allows Reading Any Memory Location in the DFCCS
`0 Allows Changing Values in Non-Volatile Memory (NVM) on
`the Aircraft
`
`- Allows the History of Airplane Power Fluctuations, CAS
`Failureslshut Downs Etc., to Be Sent to the VSD After
`the Flight.
`0 Memory Addresses and New contents Are Entered Through
`the NCI
`
`- Memory Address Contents Are Displayed on the VSD
`
`Level 4
`
`- Allows Continuous Monitoring of Any Memory Location in
`the DFCCs
`
`- Memory Addresses Are Entered Through the NCI
`0 The Address Contents Are Displayed in Real-Time on the VSD
`0 Operates While Control Laws Are Cycling
`
`GP43-0648-1-R
`
`Figure 6
`Main Features of Maintenance BIT
`
`The channels monitor each other
`configuration.
`continuously at voting planes A in the Control Laws
`(CL) and voting plane B downstream from the CL in
`the hardware. These voting planes are illustrated
`in Figure 2.
`Should a differential between the
`channels occur at either of
`these voting planes,
`the CAS will be shut down and control of
`the air-
`plane reverts solely to the mechanical system.
`Voting planes A and B have been retained in the FCS
`used in the DFCS. Voting plane B has been
`completely unaffected by any changes made for the
`DFCS. However, voting plane A is now mechanized in
`software.
`
`In addition to the fail-safe features carried
`over from the standard production CAS, an
`additional safety feature has been added due to the
`unique nature of the digital FCS. This is the
`Watchdog Timer
`(WT).
`The WT is a countdown clock
`in hardware.
`Should the WT countout it will cause
`the CAS to be disconnected.
`To prevent
`the WT from
`counting out and disconnecting the CAS, it has to
`be updated during each cycle through the control
`laws.
`Should the normal program cycling stop and
`the WT not be updated,
`the WT will quickly countout
`
`BOEING
`Ex. 1031, p. 388
`
`

`
`'90 emu
`
`@®
`
`
`
`@
`@ AYTITUDE
`% i
`
`°:;'g";,';
`Panel
`
`
`
`Alter BIT Initiation (W.0.W. and BIT Consent):
`Soltware Sets Pitch CAS Fail Discrete in Channel A to Failed Condition
`
`1. Pitch (P) and Roll (R) Llghls Come on (Test ol Vntmq Plane A)
`
`2. Reset P and R on CAS Control Panel
`Sollware Sets Pitch CAS Fall Discrete in Channel 8 to Failed Condition
`After Approximately 3 sec.
`
`3. P and R Liqhts Come on (Test 01 Votlnq Plane A)
`
`R and Y Uqhls Come on(TestolVVDTin R/Y ChannelB)
`P3
`24 Resetand R and Y
`
`- Pre-Flight Bll
`
`is Now Complete
`
`Figure 8
`Control Panels Used by Pre-Flight BIT
`
`6 P430648-4~R
`
`The solution was to bring yaw rate into
`culprit.
`the yaw channels via two A/D's, as coarse and fine
`yaw rate.
`
`Aliasing Problem
`
`It is always desirable from a computer usage
`perspective to compute the control
`laws at the
`lowest iteration rate possible so more functions
`may be included. Preliminary analysis indicated
`that
`the yaw control
`laws could be iterated at 40
`hertz instead of 80 hertz at which the pitch and
`roll control
`laws are iterated. But confirmation
`by the simulator or actual
`test flight was highly
`desirable.
`So two OFP's, one with yaw iterated at
`A0 hertz and one with yaw iterated at 80 hertz were
`prepared for evaluation at the simulator.5
`Comparison of two versions of
`the OFF at the
`simulator requires only replacing the memory cards
`in the Roll-Yaw channels of
`the DFCS. Both
`versions were flown. Unfortunately,
`the pilot
`after flying in the simulator was unable to make a
`definitive statement as to the viability of
`the 40
`hertz yaw iteration rate. Plans were then made for
`a test flight using a dual mode,
`i. e. flying for a
`while with a 40 hertz iteration rate and switching
`
`to an 80 hertz iteration rate during the flight.
`This could be done using Maintenance BIT.
`An OFF
`was developed with both an 80 hertz yaw rate and a
`40 hertz yaw rate with the pilot keying thru the
`NCI panel his choice during the actual flight.
`This would have given inflight evaluation of
`two
`0FP's with different flight characteristics.
`How-
`ever, ground vibration testing prior to that flight
`detected an aliasing problem using the A0 hertz OFP
`thus obviating the above exercise. Nevertheless
`the utility of a system such as Maintenance BIT is
`clearly demonstrated.
`For otherwise two distinct
`flights would have had to have been flown.
`And
`besides the costs and program delay, parameters —
`weather conditions, different pilots etc.
`- change,
`making multiple flight evaluation less desirable
`Also one can see the potential for very easily
`customizing the flight characteristics of
`the
`airplane for various pilots, conditions and
`missions.
`
`Summary and Conclusions
`
`A method for converting the test bed aircraft
`into a self-tester has been described.
`It has been
`shown that special software can be developed that
`
`330
`
`BOHNG
`
`Ex.1031,p.389
`
`
`
`
`—
`
`ljd
`
`474:
`
`
`
`BOEING
`Ex. 1031, p. 389
`
`

`
`V
`
`can utilize equipment resident on the aircraft to
`turn the aitetaft 1“t° 3 5e1f‘te5ter-
`Advantages Of
`the 591f'tE5teT 3PPr°aeh °Ver
`Speeial P“rP°Se test equipment are’
`1)
`External test equipment does not have the same
`re5P°“5e time as the reel system °“ the
`airplane and therefore, due to different
`sampling rates and inherent lags, gives a
`false impression of how the flight control
`system works.
`Simultaneous surges to both
`pitch channels induced by test equipment
`in
`the lab,
`for example, may cause a pitch CAS
`shutdown. This is not the way the system
`works. Maintenance BIT does not have this
`Pr°b1em as it is Part °f ‘he System’
`2) Maintenance BIT is always on the airplane,
`therefore no time consuming search for and
`attaching of special ground equipment is
`needed and after the maintenance, analysis, or
`checkout is completed there is no concern that
`damage to the system (bent pins etc.) has
`°°°“red 35 there is with special
`test
`€q“1Pme“t-
`Unlike special test equipment, one can perform
`3 test flight with°“t disengaging Mai“te“a“°e
`BIT, and continue testing in flight. Also the
`airplane may be at a remote site, anywhere, at
`any time, and will have its own test equipment
`with it‘
`
`3)
`
`4)
`
`5)
`
`1.
`
`2_
`
`3.
`
`4.
`
`5.
`
`since only changes to software are required,
`the self-tester can be easily modified or
`expanded to meet changing program needs.
`The
`success and utility of this method is
`demonstrated by the fact
`that it or a
`variation of it have been or are being used on
`several subsequent test flight Programs with
`no consideration given to additional test
`equipment at the airplane_
`with the trend toward more CRTIS in the
`Cockpit,
`this method will become even more
`attractive in the future_
`REFERENCES
`"""""
`T.F. Westermeier, H.E. Hansen, "Recent Digital
`Technology Advancements and Their Impact on
`Digital Flight Control Design", NAECON,
`May 1983_
`Zilog 1nc_, "Z8000 CPU Technical Manual",
`January 1983_
`(Astronics Division), "F-15
`Lear Siegler, Inc.
`DEFCS Hardware and Interface Description",
`Report No. ADR—843/1, dated 27 July 1982.
`T.F. Westermeier, "Parallel Processing Applied
`to Digital Flight Control Systems;
`some
`perspectives", NAECON’ May 1g81_
`T.F. Westermeier, H.E. Hansen, "The Use of
`High Order Languages In Digital Flight Control
`Systems":,
`IEEE/AIAA 5th Digital Avionics
`System Conference, November 1983.
`
`331
`
`BOHNG
`
`Ex.1031,p.390
`
`BOEING
`Ex. 1031, p. 390
`
`

`
`84-2666
`
`REAL TIME DATA PROCESSING FOR AVIONICS TESTING ON THE A-6E
`
`Paul T. Richards, P.E.
`Manager, Engineering Analysis
`
`James Lehmann
`Senior Programmer Analyst
`
`Grumman Data Systems
`11933
`Calverton, New York
`
`Abstract
`
`Many of the nation's aircraft manufac-
`turers have accelerated their flight develop-
`ment programs by producing flight test results
`while the aircraft is airborne, rather than
`waiting for results after the aircraft has
`landed. This is called real
`time flight
`testing.
`The major portion of real
`time
`testing today is limited to airframe testing;
`avionics testing uses post flight data analy-
`sis.
`Some recent work at Grumman expands
`real
`time testing to the avionics development
`area.
`
`A groundbased computer system is des-
`cribed here. This system receives digital
`data from the A-6E's onboard computer and
`processes it to give test results while
`the aircraft is airborne. Experience with
`this system indicates that it embodies a
`viable approach to rapid development of
`embedded avionics software.
`
`Introduction
`
`Since the early 1970s Grumman Aerospace
`Corporation has conducted its airframe flight
`test programs using a computer facility
`called the Autom