Boeing 777 Flight Control System

Engin Uzuncaova
Miguel A. Ayala

SW 4582 Weapons Systems Software Safety

Naval Postgraduate School, Monterey CA

INTRODUCTION
Electronic controls systems have been used in commercial aviation for more than 40
years. With the introduction of the Concorde, the use of electronic systems (with
mechanical backups) to manipulate the hydraulic controls used to fly by wire started the
revolution on flight control. Digital systems were first used in the Airbus 310 where
digital computers controlled flight control surfaces. European experience in Fly-by-Wire
(FBW) application is now some 30 years old. With the entry into service of the A320, a
new standard of FBW was defined in the flight control law and system integration areas.
The United States was lagging in these achievements. The Boeing Company, embarked
in an unprecedented journey to built a totally FBW controlled aircraft and completely
design and integrated by computer. The Boeing 777 is the first commercial aircraft
manufactured by Boeing which employees a FBW Primary Flight Control System.
Not only this aircraft created great challenges in the technological arena but in the
managerial area as well. The policy of open door or all the problems will be shared
represented a challenge. The fact that this aircraft was completely design and integrated
by computer created some challenges in the Systems Engineering as well. The objective
of this paper is to provide an overview of the flight control characteristics and constraints
for the Boeing 777 FBW aircraft.

1
1. SYSTEM OVERVIEW
Conventional primary flight controls systems employ hydraulic actuators and control
valves controlled by cables that are driven by the pilot controls. The cable-controlled
system is heavy and requires periodic maintenance.
In a Flight by Wire (FBW) flight control system, the cable control of the primary flight
control surfaces has been removed. Rather, the actuators are controlled electrically. At
the heart of the FBW system are electronic computers. Because of these changes to the
system, the following design features have been made possible:
• Full-time surface control utilizing advanced control laws. The
aerodynamic surfaces of the 777 have been sized to afford the required
airplane response during critical flight conditions. The reaction time of the
control laws is much faster than that of an alert pilot. Therefore, the size of
the flight control surfaces could be made smaller than those required for a
conventionally controlled airplane. This results in an overall reduction in
the weight of the system.
• Improved system reliability and maintainability.

1.1 Fly-by-wire
Fly-By-Wire (FBW) Primary Flight Controls have been used in military applications
such as fighter jets for a number of years. It has been a rather recent development to
employ them in a commercial transport application. The 777 is the first commercial
transport manufactured by Boeing which employees a FBW Primary Flight Control
System. The Airbus A320 and predecessors is an example of earlier systems developed
in Europe. Many other aircraft were fully electronic with an electro-mechanical or
electro-hydraulic backup.
A FBW flight control system has several advantages over a mechanical system. These
include:
• Overall reduction in airframe weight.
• Integration of several federated systems into a single system.
• Superior airplane handling characteristics.
• Ease of maintenance.

2
 • Ease of manufacture.
• Greater flexibility for including new functionality or changes after initial
design and production.
1.2 Triple-triple redundancy
To meet some demanding performance requirements like a particular component
becoming totally inoperative or a failure which results in some particular component
remaining active but the functionality it provides is in error, a fault-tolerant system
generally uses both types of fault tolerance (hardware and software) and has the
capability for automatic, dynamic reconfiguration of the system. In order to deal with it,
different levels of redundancy (dual, triple, or quadruple) are used, depending on the level
of criticality and, therefore, on the allowable probability of failure and probability.
Redundancy extends to all hardware elements, such as processors, sensors actuators, and
data buses, and to the software. In the 777, for example, there are three PFCs in the
Primary Flight Control System, each with three identical computing "lanes" within each
PFC. This results in nine identical computing channels. Any of the three PFCs
themselves can fail totally due to loss of power or some other failure which affects all
three computing lanes, but the Primary Flight Control System loses no functionality. All
four ACEs will continue to receive all their surface position commands from the
remaining PFCS. Likewise, any single computing lane within a PFC can fail, and that
PFC itself will continue to operate with no loss of functionality.
Because the system is controlled electronically, there is an opportunity to include system
control augmentation and envelope protection features that would have been difficult to
provide in a conventional mechanical system. The 777 Primary Flight Control System
has made full use of the capabilities of this architecture by including such features as:
• Bank angle protection
• Turn compensation
• Stall and over speed protection
• Pitch control and stability augmentation
• Thrust asymmetry compensation
These features are monitored and executed electronically with over ridding option.

3
2. REQUIREMENTS ANALYSIS
In general, a top-down approach is followed; from high-level requirements to specific
design decisions which later led to low-level requirement and design specifications. In
some cases where refinement of the requirements revealed some problems resulting in
changes in those requirements, an iterative approach is followed. One of the significant
facts is that Boeing involved potential customers in defining top-level design
requirements throughout the process.

2.1 Requirements Capture

Since there was some experience within the Boeing family (Fly-By-Wire experience
from 757, 767) and Boeing’s competitors in applying FBW technology, a trade study was
launched. There were many sources for the flight control system; FAA, JAA, customer
top-level requirements and lessons learned from other programs are captured in the
Design Requirements & Objectives Document (DR&Q). The recurring cost and weight
also favored FBW. The primary requirements at the early stages of this process were
almost exclusively safety oriented. The result was a preliminary architecture that met the
DR&Q and provided the best compromise in terms of cost, weight and safety. But it
needs to be stated that at the time of first certification by the Federal Aviation
Administration the requirements documents for autopilot system was at a very high level
of revision status. It shows that requirements were not captured in an immediate sense,
but rather evolved in an iterative nature.
During the development phase of Autopilot Flight Director System (AFDS) it was
proposed to use rapid prototyping techniques to show the feasibility of this approach.
Autoland annunciation function was selected for that purpose. Two separate systems
were involved; AFDS and Aircraft Information Management System (AIMS).
Requirements from both systems were modeled using Statemate, which enables system
engineers to create executable models of the requirements. This model was used to
evaluate requirements associated with each system. The annunciation function were six to
eight months in advance of other functions and its requirements were proved to be more
stable during integration testing than that of other components. Required test
development time was reduced and lab activity was minimized.

4
2.2 Requirements Allocation
With the preliminary architecture and airplane level requirements defined, the next step
was to develop the low-level system requirements. Flight Control Coordination Teams
were formed to determine requirements allocation to the various Line Replaceable Units
(LRUs). Separate teams were responsible to write the corresponding detailed
requirements for different areas. As they were developed, the system and component
level requirements are documented in the PFCS and AFDS System Requirements and
Objectives Documents (SR&Qs). In those documents design requirements, objectives,
philosophies, definitions and design decisions for the Flight Control System were
included. System functionality, performance, availability, safety, separation, crew
operation and maintenance issues were addressed by the SR&Qs.

2.3 Requirements Traceability Database

Requirements Traceability Database was evolved from the basic concept of an allocation
table. In this evolution the first step was the addition of the requirements traceability
information and the change log tracking information. With the inclusion of the
verification traceability information, a powerful management tool was being created.
Some further improvements provided easy operation and database integrity. Assessing
the impact of a requirements change accurately was enabled by the tool. By assigning
size and complexity attributes to the requirements and utilizing existing systems and
software metrics, changes could also be sized in terms of resources and schedule required
to implement and test the changes.

2.4 Change Management

Revision D of the AFDS Specification Control Drawing contained approximately 2200
individual requirements while the System Requirements and Implementation Document
contained approximately 1800. There were over 10,000 individual requirements change
from that time to the first AFDS certification (April 1995).Successful management was
critical to the success of the program. The suppliers Engineering Review Board made an
initial evaluation of the requirements changes received from Boeing and determined

5
further expansion or direct hardware/software implementation. Most changes were sent
out for expert analysis prior to the final decision. Once changes were evaluated, they
were logged into the requirements and traceability database. Weekly reports were given
to the responsible groups. Having a well-organized management system made it easy for
the program for traceability of any requirements change from proposal to the
implementation. All this information was also used to support lab testing and flight-
testing.

2.5 Requirements Validation

It was the goal in the team to complete requirements validation before equipment was
built. Issues primarily addressed by the validation process were;
• “correctness” of a requirement,
• the need for a requirement,
• compatibility with other requirements, and
• whether the product built to the requirement would accomplish what was
intended.
Understandability, testability, maintainability, cost, and lessons learned played a part in
the process. A continuous feedback was provided from all validation activities through
problem reports and system issues.
During Formal Reviews, representatives from airlines, certification agencies,
manufacturers, suppliers, interfacing airplane/system groups, and peers from other
airplane programs were included at some point. FAA Designated Engineering
Representatives (DERs) who are the “eyes and ears” of the FAA within the engineering
organizations, participated in all stages of review. The major review activities included a
System Design Review (SDR), System Preliminary Design Review (PDR), and System
Critical Design Review (CDR), which were completed in that order. A review of later
changes was accomplished by a Requirements Review Board composed of all groups
affected by the requirement, and appropriate managers. Initial SDR focused on overall
system requirements and architecture, basic design, and plans which would guide the rest
of the program. The PDR presented the detailed system requirements and design. It also
showed how the design would meet the requirements. The CDR covered changes from

6
the PDR and final system reviews including maintainability and accessibility of the
components. In each review, the status of the various analyses for performance and safety
was presented.
A special redundancy management simulation was used to validate requirements
associated with the effects of the systems asynchronous and redundant operation. This
included fault detection, isolation, and transient prevention requirements. Piloted
simulator evaluations were accomplished using a full flight regime-engineering simulator
to validate the requirements and system operation under both normal and failure
conditions.

3. DESIGN
Boeing 777 design approach was focused on the following constraints:
• Common Mode / Common Area Faults
• Separation of FBW Components
• FBW Functional Separation
• Dissimilarity
• FBW Effect on structure

3.1 Common Mode / Common Area Faults

Airline susceptibility to Common Mode / Common Area damage is addressed by
designing the systems both component and functional separation requirements. This also
includes criteria for providing installations resistant to maintenance crew error or
mishandling. Design and installations were developed with the following fault
considerations (to name a few):

• Impact of objects • Electrical faults

• Electromagnetic environment • Electrical power failure
• Hydraulic failure • Lightning strike
• Structural damage • Radiation in the atmosphere
• Fire

7
 • Rough/unsafe installation or
maintenance

These concerns led to the FBW requirements for separation of FBW components and
FBW functional separation.

3.2 Separation of FBW Components

This concept is based on isolation and separation of redundant flight control elements,
such as LRUs, wiring and hydraulic lines. This helps to minimize the possibility of loss
of function caused by common mode / common area faults, and also prevents failures of
other systems from affecting the FBW operation.

3.3 FBW Functional Separation

All triple redundant hardware resources are aligned to the Left, Center and Right. That
concept focuses on the act that for the Left/Center/Right hardware resources there are
three separate data buses and electrical buses. This prevents any power or transmitter
failure from disrupting more than one resource.

3.4 Dissimilarity
Requirements errors, implementation errors, misunderstanding and software design errors
are stated as to be the most likely design errors by Boeing. Design errors can defeat
redundancy strategies and can even result in shutdown of multiple computer channels.
Various combinations of dissimilar hardware, different component manufacturers,
dissimilar control/monitor functions, different hardware/software design teams, and
different compilers are considered. When dealing with redundant hardware and software,
there is the question of whether the redundant elements should be similar or dissimilar.
There are powerful arguments for either choice. Similar redundancy simplifies the
design process and reduces costs and programming and verification activities, but it does
not protect against generic errors. Conversely, dissimilar redundancy makes the design
and the programming and verification activities more complex, lengthy and expensive but
provides what is generally agreed to be a substantial increase in protection against

8
generic faults. Despite the cost and complexity, the dissimilar approach is usually chosen
to further ensure meeting the system-reliability goals.

4. SAFETY ANALYSIS
The target or safety objective was to be able to dispatch the aircraft with one EFCS
computer failed and still meet the following two objectives:

• Complete loss of control: extremely improbable.

• Any significant reduction of handling quality: remote.

The difficulty in factually demonstrating that a momentary loss of all electrical power is
extremely improbable led to the retention of a minimal mechanical backup system. Tests
performed demonstrated that it is possible to maintain safe control in any configuration,
over the entire flight envelope and CG range, by using only the rudder for yaw and roll
and the trimmable horizontal stabilizer (THS) for pitch control.
The safety analysis is performed to cover all significant failures of FBW system
including single failures, latent failures, and failure combinations at the LRU level. It is
remarkable that there is a general classification of failures included in the system: passive
failures (loss of function without significant immediate airplane transient) and active
failures (malfunction with significant immediate airplane transient).
There is a constraint that the PFC should have been organized to comply with the
following non-numerical safety requirements:
• No single fault, including a common mode hardware fault, regardless of
probability of occurrence, should result in an erroneous (assumed active
failures for the worst case) transmission of output signals without failure
indication.
• No single fault, including a common mode hardware fault, regardless of
probability of occurrence, should result in loss of function in more than
one PFC.
And the numerical probability requirements are both 10-10 per flight hour for functional
integrity requirements and functional availability requirements.

9
The analysis shows that the probability of a given failure condition is consistent with its
severity, and that all failure combinations producing a catastrophe are extremely
improbable.

4.1 Fault Tolerance

Tolerance is the ability of a system to continue satisfactory operation in the presence of
one or more non-simultaneously occurring hardware or software faults. It is a term that is
used to define the ability of any system to withstand a single or multiple failures which
results in either no loss of functionality or a known loss of functionality or reduced level
of redundancy while maintaining the required level of safety. Fault tolerance becomes
especially significant when the system performs a flight critical or flight essential as
defined by Federal Aviation Regulation (FAR) Part 25.1309: Equipment, Systems and
Installation or by MIL-F-9490: Flight Control Systems. In brief, FAR 25.1309 specifies
a probability of failure for a flight critical system of < 10-9 per flight hour.
The 777 uses software in lieu of hardware replication to achieve fault tolerance in
analytical redundancy. In the case of a faulty sensor, analytical redundancy combines
data from the remaining functioning sensors with data from other sources in the aircraft
in algorithms that compute the most probable value from the failed sensor. This
computed value is then used in the same ways as a value from a functioning sensor. An
equivalent concept can be applied to flight control actuators and surfaces where, if an
actuator fails or a control surface is lost, the remaining functioning actuators and surfaces
can be combined in a way to offset the loss. Analytical redundancy and its companion
concept for actuators are two of the corner stones of reconfigurable flight control
systems.
The 777 software, working with the operating system, is capable of restarting a given
process within a partition or the entire partition based on predefined parameters
established for each partition type. Using this technique, it executes the fault recovery
approach having the minimum system effect while maximizing the probability of clearing
the fault condition. In the case of frequent transient hardware or software faults or
persistent faults, the software is able to shutdown a specific process in a partition, a

10
specific partition, or an entire Core Processing Modules (CPM) as required by the system
safety analysis.
What about fault detection? It is obvious that before any fault-tolerance scheme can be
invoked, a fault must be detected. There are several approaches to fault detection:
replication (triple or higher) and voting duplication and comparison, and self-checking.
In replication and voting, a highly fault-tolerant voting circuit compares the values from
multiple processors computing the same parameter, and if one of values does not agree
with the others, the value is ignored and the processor that generated the suspect value is
switched off line. Based on the degree of fault tolerance required in the system, a
replacement processor can be brought on line or the system can revert to a lower level of
replication or to the duplication and comparison mode of operation. The failed processor
then execute self-diagnostic check and, if no permanent faults are found, return active
status.
All critical interfaces into the 777 FBW Primary Flight Control System use multiple
inputs, which are compared by a voting plane. By employing methods such as this, it is
assured that the 777 Primary Flight Control System is able to withstand a single or
multiple failures and be able to contained those failures in such a manner that the system
remains.
Flight-critical systems require fault-tolerant software to complement the fault-tolerant
hardware. Many of the concepts for fault-tolerant hardware, such as similar and
dissimilar redundancy and standby sparing, have parallels in fault tolerant software.
Fault-tolerant software falls into three categories: multiversion programming, recovery
blocks, and exception handlers. All of these techniques are subject to error if the
software specification is incorrect. The importance of beginning the software design
process with an accurate and complete software specification cannot be overemphasized.
It is essential that the software engineer review the software specification to verify its
correctness. An error in the software specification will probably produce an error in the
software, one that may not be found, even in exhaustive testing, but may later cause
catastrophic failure of the system. Multiversion, or N-version, programming requires the
development of two or more versions of a program that performs a specific function
described in the software specification. These different program versions should be

11
developed by separate software teams and may even be designed to operate on different
processors. Finally, the software engineer must decide whether the versions are to be
executed in parallel or sequentially. Clearly the trade-off here is between minimum
hardware and slower execution (sequentially) or more hardware and maximum (parallel).
Fault containment and isolation of hardware and software faults is implemented on the
777 concurrently monitored hardware processing architecture. Each CPM contains two
identical processors operating in a redundancy checked pair with each processor
monitoring the other processor. Each processor and its associated address, memory and
control hardware is referred to as a processing lane. The state of the address, instruction,
data and control lines in each lane are compared against each other on every processor
clock cycle. This redundant processor operation is referred to as lock step processing.
Any divergence between the two processing lanes operating in lock step is detected on
the actual clock cycle when the failure occurs. This instantaneous detection of the fault
condition allows program execution to be immediately passed to a software fault handler
and prevents corrupted information from being executed. Implementation of the lock step
architecture has facilitated the design of many additional high integrity monitors to check
every aspect about each processor operation. These additional monitors evaluate both
software and hardware fault conditions. The lock step architecture and its associated
monitors have resulted in a system that will detect virtually all hardware faults, transient
or persistent. The probability of an undetected hardware fault 777 CPM lock step
processing architecture is < 10-9 per hour.
Recovery blocks are another concept in fault-tolerant software. Acceptability checks are
made on the results from a primary version of a program. If the results fail the
acceptability checks, an alternate version of the program that is different from the
primary version is invoked, and the process of computation and acceptability checks is
repeated. If no alternate version produces an acceptable result, the software block is
judged to have failed.
Fault containment and isolation is of little value unless an appropriate recovery response
is defined for each type of fault event that can occur. The 777 uses software in lieu of
hardware replication to achieve fault tolerance is analytical redundancy. In the case of a
faulty sensor, analytical redundancy combines data from the remaining functioning

12
sensors with data from other sources in the aircraft in algorithms that compute the most
probable value from the failed sensor. This computed value is then used in the same
ways as a value from a functioning sensor. An equivalent concept can be applied to
flight control actuators and surfaces where, if an actuator fails or a control surface is lost,
the remaining functioning actuators and surfaces can be combined in a way to offset the
loss. Analytical redundancy and its companion concept for actuators are two of the
comer stones of reconfigurable flight control systems.

4.2 Testing
In order to provide the required validation test coverage a number of laboratory facilities
were used. System Level integration testing was conducted at the 777 Flight controls Test
Rig (FCTR), Systems Integration Lab (SIL), and an Engineering Simulator Cab (Cab 2).
The FCTR was primarily used by flight controls and hydraulics for system level tests,
and the SIL and Cab 2 were primarily use for airplane level validation with some flight
controls validation when appropriate.
For requirements compliance testing was also the most desirable method. Analysis is
used to validate system performance, reliability, and safety predictions based upon
system redundancy. Where review of an installation or document was sufficient,
inspection was used as a method. Similarity was also used as a method of validation
when the system implementation was identical or comparable to previous system which
demonstrated satisfactory performance. But similarity was never the sole method,
supported by analyses or tests to show that the previous system meets the current system
requirements. Suppliers also performed various tests and analyses to verify that their
designs meet requirements. Analyses and tests were also performed for supporting
systems outside the responsibility of the Flight Controls Organization.

5. CONCLUSIONS
The Boeing 777 Flight-by-Wire Primary Control System utilizes new technology to
provide significant benefits over that a conventional system. These benefits include a
reduction in the overall weight of the airplane and superior handling characteristics
among others. At the same time, the control of the airplane is accomplished using

13
traditional flight deck controls, allowing the pilot to fly the airplane without any
specialized training when transferring from a more conventional one.
Besides been a managerial achievement from the Boeing Company, it is a technological
one. The fault-tolerance systems provides good monitoring with a redundancy system in
hardware and software. Fault containment and isolation of hardware and software is
implemented with two identical processors on each CPM operating in redundancy, each
processor monitoring the other. The faults are handled by software fault handler that
prevents corrupted information to be executed. The probability of an undetected
hardware fault is < 10-9 per hour.
Throughout the requirements analysis phase, there are some major points which helped
producing more consistent set of requirements.
Working Together was a Boeing and airline term for concurrent engineering. This
program brought together teams consisting of engineers, key airlines, suppliers,
manufacturers, and customer service organizations. This provided real-world feedback
from real-world users. Having more realistic requirements and design recommendations
had an indirect impact on system safety, but it is quite clear that it is one of the factors
played an important role on overall product.
The joint working meeting method was very effective in reviewing the requirements.
These meetings focused on just one specific area each time and last one to three days.
During these meetings, key engineers from both Boeing and Collins discussed and further
developed the requirements. Ina very complex system like the Boeing 777, it is very
important to have that kind of effective organizational events. This shows the level of
seriousness and consciousness involved from the beginning in the project.
In autoland status assessment, rapid prototyping was used to model the system and test
the requirements. The result was excellent, and very important for a safety critical
system. Because, it is possible to find logic errors early in the system, they found seven,
and go back and correct the requirements. Also, there is the opportunity to see impact of
each individual requirement in the overall system. But, high initial cost of training limited
the use of rapid prototyping to that function only.
Requirements and traceability database had a great efficiency in the requirements phase.
It was derived from basic concept of allocation table which was turned to be very useful

14
tool for engineers. In huge systems where requirements well over reasonable numbers, it
is very important to be able to reach requirements in such an easy way and see the
impact any change in terms of any system stand point.
Even if the Boeing 777 is different from other Boeing airplanes, it can easily be seen that
there is a huge amount of experience involved in every phase of the project. Not only
they use their experience, they also produce some standards which was proved to be
beneficial for the organization. Ada is one of them; in the 777 program it was a goal to
use Ada as a standard language, and it represented nearly 70% of the source line of code
developed for the 777.
The Boeing 777 is a remarkable achievement. With the advancements in digital
computing tasks that seems to be impossible 30 years ago, today area reality; aircrafts
that can perform a landing with the autopilot and some other examples. At this pace,
what would be next?

6. REFERENCES
[1] Storey Neil, (1996) Safety-Critical Computer Systems, Addison Wesley
[2] Raymond E.T.,(1993) Aircraft Flight Control Actuation System Design, Society
Automotive Engineers
[3] Spitzer Cary R., (2001) The Avionics Handbooks, CRC Press
[4] Anderson, Marc C., (1995) Advanced Maintenance Techniques in the Boeing 777,
Aircraft Information Management System, paper presented on The Design and
Maintenance of Complex Systems on Modern Aircraft conference, 6 April 1995,
Heathrow, UK
[5] Tischler Mark B., (1996) Advances in Aircraft Flight Control, Taylor & Francis
[6] H.Buus, R.Mclees, M.Orgun, E.Pazstor, L.Schultz, “777 Flight Controls Validation
Process”, 14th Digital Avionics System Conference, September 1995
[7] Michael J.Gries, “System Engineering for the 777 Autopilot System”, 14th Digital
Avionics System Conference, September 1995
[8] Y.C. (Bob) Yeh, “Triple-Triple Redundant 777 Primary Flight Computer”, Boeing
Commercial Airplane Group, 1996 IEEE

15
[9] Ronald Riter, “Modeling and Testing a Critical Fault Tolerant Multi-Process System”,
Boeing Commercial Airplane Group, 1995 IEEE
[10] Y.C. (Bob) Yeh, “Design Considerations inBoeing 777 Fly-By-Wire Bomputers”,
Boeing Commercial Airplane Group,
[11] Blake A.Andrews, William C.Goeddel,Jr., “Using Rapid Prototypes for Early
Requirements Validation”, Collins Commercial Avionics, 1994 IEEE
[12] Ronald R.Hornish, “777 Autopilot Flight Director System”, Collins Air Transport
Division, 1994 IEEE
[13] Ron J.Pehrson, “Software Development for the Boeing 777”, The Boeing Company,
January 1996
[14] Paul Ebner Gartz, “Commercial Systems Development in a Changed World”,
Boeing Commercial Airplane Group, 1997 IEEE
[15] Guy Norris, “Boeing’s Seventh Wonder”, IEEE Spectrum, October 1995

16