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

• Electromagnetic environment

• Hydraulic failure

• Structural damage

• Fire

• Electrical faults

• Electrical power failure

• Lightning strike

• Radiation in the atmosphere

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

16

[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