INTRODUCTION

System Overview
System Engineering for the 777
The 777 Autopilot Flight Director System (AFDS)
Autopilot System is comprised of a mode control panel (MCP),
which provides the primary system interface for the
flight crew; three AFDCs, which provide triplex
computations for the autopilot and flight director
commands, maintenance, and backdrive functions; and
MICHAEL J. GRIES six backdrive control actuators (BCA), which provide
Rockwell International
visual and tactile feedback to the flight crew through
dual redundant control of the column, wheel, and
pedals. The AFDS provides multichannel automatic
This paper describes the systems engineering process cruise control as well as the system configuration for
used in developing the 777 Autopilot Flight Director System fail-operational automatic approach and autoland. The
(AFDS). It includes discussions regarding requirements capture, system has been certified to a IrrB autoland
requirements allocation to hardware and software, system capability [ 11.
architecture considerations (including the architectural impact
of safety requirements), change management, requirements and Systems Engineering Process Overview
verification traceability, and requirements-based verification.
Additionally, the organizational structure employed and its Fig. 1, represents a block diagram of the systems
interaction with the systems engineering process are also engineering approach used by Collins. Requirements
reviewed. Finally, the results from a recent joint (Boeing and are allocated downward within the system hierarchy
Collins) lessons learned exercise are summarized. using three basic activities: requirements analysis,
functional analysis, and synthesis. Functions are
integrated upward with the system hierarchy using
three basic activities: integration, verification, and
validation. The overlapping of the RFS-IVV activities
shown in Fig. 1, indicates there is an iterative nature
and logical flow dependency between the individual
activities.

S p t h d (S) Integration0

Fig. 1. Systems approach.

The RFS-IVV process is applied iteratively. For

example, to do requirements analysis properly some
amount of functional analysis must be done to validate
the previous requirements analysis. At any point in
the progression through the process, as more detail
is discovered, it may be necessary to go back and
Manuscript received September 15, 1995. repeat some of the previous activities. This approach
IEEE Log NO. T-AES1331212103172. encompasses the entire development process with
This paper was originally presented at DASC’95 a recognition that the documentation and system
(0-7803-3050-1195) and is being reprinted with this group of papers engineering activities control the flow of the project
at the specific request of INCOSE. through the RFS-IVV activities.
Author’s address: Rockwell International, Collins Air Transport The remainder of this paper explores how the 777
Division, 400 Collins Road NE, Cedar Rapids, IA 52948. AFDS engineering team navigated their way through
many of the activities associated with the RFS-IVV
0018-9251/971$10.00 @ 1997 IEEE systems approach.

IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 33, NO. 2 APRIL 1997 649
REQUl REMENTS CAPTURE excellent results and served to develop better working
relationships between Boeing and Collins.
Requirements Documents

The tomlevel reauirements document for the Requirements Analysis Tools

AFDS was the Boeing supplied Specification Control The 777 AFDS team experimented with using
Drawing (SCD). Initially, Collins participated in Statemate as a requirements analysis tool. There were
the development of this document by authoring or both successes and failures with this experiment.
coauthoring several of the functional area sections. The first application of Statemate was development
After the first release of the SCD, Collins engineering of a data dictionary for the SRID. This was to be
began focusing on expanding, where necessary, the
accomplished by having each system engineer enter
higher level requirements contained in the SCD. data flow diagrams for their respective functional
The vehicle for this expansion was the second areas. These diagrams would then be integrated at
primary requirements document, the Collins derived the top level with the result being an automated data
Sysems Requirements and Implementation Document dictionary. Using Statemate in this application proved to
(SRID). The SCD and SRID formed the basis for be a failure and the data dicti
approximately 85% of the system level AFDS via manual means. The prim
requirements. Three other documents contributed was a fundamental m
the remaining requirements: the Directed Message Statemate was also used to si
Protocol, which governed maintenance and data portions of AFDC
load communication with the Airplane Information of the tool proved to
Management System (AIMS); the Data Load User example of this was a
Requirements, which contained additional data the Autoland Status A
load requirements; and the General Technical the then existing r
Requirements, which contained general hardware developed a Statemate
design requirements. that simulated the
At the time of first aircraft certification the SCD various status mes
was at revision status G and the SRID was at revision what were thought to be mature requirements, the
status H. This serves to highlight that the requirements model uncovered seven logic errors. Using this rapid
for the 777 AFDS were not captured in the immediate prototype capability accelerated the detection and
sense of that word, but rather were evolved. As correction of these errors six to eight months prior
discussed in the previous section, this evolution stems to the availability of hardware and software in the
from and is controlled by the iterative nature of the integration lab [2].
process.
REQUIREMENTS ALLOCATION
Working Meetings
Hardware and software requirements for the 777
The most effective method utilized for establishing A F D S came from two primary sources, the SCD
good requirements was the joint working meeting. and the SRID. However, the document structure that
These meetings would generally focus on one was employed was not purely hierarchical. Starting
functional area with the key engineers from both with the SCD, requirements could be allocated to
Boeing and Collins participating. Typically, the the SRID if further detail or expansion was needed.
meeting would last one to three days. During that If, on the other hand, an SCD requirement contained
time period, the participants were required to be sufficient detail, it was allocated directly to hardware
totally focused on the task at hand, which was to or software for implementation, as shown in Fig. 2.
review and further develop the requirements. Meeting SRID requirements were also typically allocated to
minutes were taken and action items were assigned either hardware or software, after expansion.
at these working sessions. Actions usually involved The Allocation Table, sho
the assignment of a more detailed analysis or a integral portion of a requireme
requirements change. data base tool that was created
Since these meetings were usually always held requirements. The Allocation
face to face, the requirement of one party to travel requirement (by requirement
added a further measure of seriousness to the the SCD and the SRID a
discussions. The traveling party was away from requirement is allocated.
their home work environment and therefore was AFDC software, AFDC
not likely to be distracted. Likewise, the host party MCP hardware. Further
felt an obligation to make the meeting productive required. For example,
and not allow distractions. These meetings produced could be broken down to a particular processor.

650 IEEE TRANSACTIONS ON AEROSPACE AND ELE(3TRONIC SYSTEMS VOL. 33, NO. 2 APRIL 1997
 TA- 1 testability provisions were included to assure that
effective monitoring and detection of random failures
could be achieved. This philosophy of design for
verifiability was utilized for much of the system and
proved very valuable in assembling the verification
documentation necessary to achieve certification.

LtEd
Fig. 2. Requirements allocation.
Experience was also a key to the successful
architectural design of the 777 AFDS. The Collins Air
Transport Division’s Flight Control Department has
over twenty years of experience in designing Category
IIIB autoland systems, dating back to the Lockheed
L- 1011. Many of the same engineers have worked on
the L-1011, the Fokker F-100 and F-70, the Boeing
757,767, 747-400, and now the Boeing 777.
Trade studies were used to combine the mix

-
of requirements, experience, and new technology
into a slate of viable architecture alternatives. These
alternatives were evaluated against not only the
overriding safety requirements and objectives, but
Fig. 3 . Architecture design process. also against the other top-level system requirements.
Promising alternatives were “fleshed-out’’ in order
SYSTEM ARCHITECTURE to achieve more detailed comparisons. A prototype
design was built and tested in the initial Blue Label
An overview of the system architecture design phase of the program. Two important changes were
process used for the 777 AFDS is shown in Fig. 3. made between the Blue Label design and what would
This process was started very early in the development become the production design. The AFDC was
cycle. changed from passive cooling to active cooling, and
The primary requirements that are considered at the AFDC internal inter-processor bus architecture
the early stages of this process are almost exclusively was changed to a more flexible design. The change
safety oriented. The 777 AFDS was required to from passive to active cooling was an aircraft level
meet some very stringent safety numbers. The most decision and the bus architecture change was a
critical of these requirements were: the probability capability and efficiency decision.
of backdrive system hardover or oscillatory failures It is valid at this point to again stress the iterative
shall be less than l.O(lO)-’o per hour; the probability nature of the process. The above-described system
of autopilot disconnect below the alert height from a architecture process fits well within the overall
LAND3 configuration shall be less than 2.5(10)-” RFS-IW process that governs all aspects of the
per autoland; and the probability of the AFDS development.
issuing pitch or roll hardover commands from two
or more AFDCs shall be less than l.O(lO)-’o per CHANGE MANAGEMENT
autoland. Safety requirements for the 777 AFDS
drove the top level architecture design. Once the The number one challenge on the 777 AFDS
top level architecture was defined to meet the safety program was dealing with the magnitude of change
requirements, other important requirements, such that was experienced. Revision D of the SCD
as availability, reliability, maintainability, testability, contained approximately 2200 individual requirements
performance, and cost, were considered. while revision D of the SRID contained approximately
Two additional concerns that were addressed 1800 individual requirements. There were over
throughout the process were verifiability and 10,000 individual requirements changes to these two
ultimately certificability. This was demonstrated, in documents from their revision D statuses (January
part, by Collins choice of an internally developed 1993), to the initial AFDS certification (April 1995).
processor for use in the AFDC. The FCP-2000 The successful management of this high level of
(flight control processor) was developed specifically change was critical to the success of the program.
for high-integrity flight control functions, with the Fig. 4 shows a simplified overview of the Collins
first application being the 777 AFDS. A rigorous change management process. The process is described
development and verification process, analogous to in its final form, but it should be noted that it evolved
DO-178, was employed to ensure that the processor over the life of the project.
could be considered truly “verified” rather than merely SCD requirements changes were received
well tested. In addition to verification considerations, from Boeing on coordination memos. The Collins

GRIES: SYSTEM ENGINEERING FOR THE 777 AUTOPILOT SYSTEM 65 1

 I SCD I engineering. The objective of functional test is to
provide hardwarehoftware integration testing with
test coverage for every
objectives are intended
testing at a systems level.
Functional testing is
contains all AFDS hard
environment (including
systems, and displays.)
mounted in a servo loader
the 777 feel system. Each
be interrogated via spe
that are capable of directly accessing
each microprocessor. A monitor
a MicroVAX controls acces
is used to develop tes
Collins-developed mo
Fig. 4. Change management process.
Process
Engineering Review Board (ERB) made an initial
All SCD requirements that were designated
evaluation of these changes and determined whether
be verified via functional test were reviewed an
the change required further expansion in the SRID
partitioned into functionally related grou
or could be given directly to either hardware or
group formed the basis for an individual
software for implementation. Most changes were sent
test. This method of allocating requirem
out for expert analysis prior to the ERB making its
tests prior to the test development was a new
e ERB also retained cognizance of the
used on the 777 AFDS. The previous functio
software build plans and determined
methodology was to assign areas of functionality
when particular changes would be incorporated.
to test team members. The test e
Once changes were evaluated by the ERB the
individual requirements ges were logged into
the requirements and tra lity data base. Weekly
reports of these changes given to the systems,
hardware, and software groups, which used the
with many require
reports to aid in tracking and to assure all changes
The 777 approach
were implemented. The reports were also used to
of over-coverage an
provide traceability inputs back to the data base
manager. Changes that were assigned to the systems
previous Boeing autopilot
group were often followed by a corresponding
requirements change in the SRID. These changes
greater.
flowed back through the requirements and traceability
data base and then to either hardware and software for
written at a very detailed
implementation.
the intention of avoiding
Build plans governed when changes were
implemented. The build plans were maintained by
However, these highly detaile
Collins. However, the date and the content of a
a problem for functional tests
particular software build or hardware flight change
were jointly established by Boeing and Collins to
cases, the detailed requ
support critical lab testing or flig
reverse engineered to g

VERI F ICATI 0N

Background
more detailed tests are valid i
Requirements-based verification (i.e., functional insight as to top-level system
test) is one of the primary tasks of systems suboptimized.

652 IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 33,

 ~

TRACEABI LI N

Boeing document D6-3507 1-1, BCAG Avionics

Computer Software Technical Standard, requires that
each requirement in the SCD be traced to the source
code module where it is implemented. It further
requires that each requirement in the SCD be traced I Data BPK Fills
I
to the test procedure which verifies the requirement.
With thousands of requirements and tens of thousands
of requirements changes, the task of traceability was
nontrivial.

I I
Process
Fig. 5. Requirements and traceability data base.
The requirements allocation process outlined
earlier was the basis for accomplishing the traceability complexity attributes to the requirements and utilizing
task. Each group (systems, hardware, and software), existing systems and software metrics, changes could
was responsible for completing traceability for the also be accurately sized in terms of resources and
requirements that were allocated to them. The task schedule required to implement and test the change.
of organizing the inputs and creating the overall report
was handled by the systems group.
PROJECT ORGANIZATION
SRID traceability back to the SCD was
accomplished by inserting traceability "tags" into Leadership
the document following every requirement. These
tags were then extracted from the document and Fig. 6 shows the project organization that was
converted to the appropriate data base format. This in place for much of the 777 AFDS program. The
served to increase the utility of the SRID as well as Technical Director (TD) and the Program Manager
accomplishing the traceability task. Hardware and formed a leadership team. The primary responsibility
software provided their traceability feedback through of the TD was to lead the engineering development
a modified form of the allocation reports that they team and to manage the nonrecurring cost aspects
received on a weekly basis. of the development. The program manager was the
primary interface to the Boeing material organization
and managed the sales and recurring cost aspects of
Requirements and Traceability Data Base
the program. Two equipment managers reported to the
The requirements and traceability data base TD. Their job was to coordinate the production and
evolved from the basic concept of an allocation table delivery aspects of the products.
to a management tool that has become an integral
part of the day-to-day operations of the 777 AFDS Skill and Task Groups
program (Fig. 5). The first step in this evolution
was the addition of the requirements traceability Under the TD, the project team was organized
information and the change log tracking information. into six primary skill groups: AFDC systems, MCP
This allowed accurate traceability in the midst of systems, AFDC hardware, MCP hardware, AFDC
large quantities of change. With the inclusion of the software, and MCP software. In addition to the skill
verification traceability information, the realization groups, there were two large task groups, functional
was made that a powerful change management tool test and structural test. Each skill group and task
was being created. group was lead by an engineer that reported to the
Several user interface programs were written to TD. Although the engineering staff reported through
allow easy access to the vast amount of information the project organization to the TD, administratively
that existed. This enabled the engineers to interrogate they reported to skill-based managers that may or may
the data base without having to be a data base expert. not have had direct involvement with the 777 AFDS.
It also protected the integrity of the information This skills-based matrix organization was in place at
by controlling access to the raw data. The ability Collins Air Transport Division during much of the
to quickly and accurately assess the impact of a 777 AFDS project.
requirements change was probably the most powerful
aspect of the tool. In a matter of minutes, the impact Chief Engineers
of a change could be presented in terms of the
SRID sections affected, functional tests affected, and The project also utilized two chief engineers that
source code modules affected. By assigning size and reported to the TD. These were highly experienced

GRIES: SYSTEM ENGINEERING FOR THE 777 AUTOPILOT SYSTEM 653

 Fig. 6. 777 AFDS project organization.

individuals that had worked on several prior autopilot participate equally in the requirements capture phase
programs. The role of the chief engineer was to and should colocate the teams to obtain maximum
provide technical advice to both the TD and to the benefit.
skill group leaders. They also served to provide
continuity across the skill groups and the interfacing Detail Trap
subsystems (AFDC, MCP, and Backdrive Actuators.)
The chief engineer also acted as a “tie breaker” The Boeing SCD contained very detailed
when conflicting technical opinions could not be
requirements in many areas. This level of detail served
resolved.
to remove ambiguity; however, it inhibited insight
into the desired system level behavior. This at times
Process/O rganization Synergy preconstrained the imple
increased the verification tas
The process and the project organization definition in itself was not the issue, rather that detail
fit together very well for the most part. One should only be added after the d
of the main reasons for this was the fact that system behavior is fully unders
although the lead engineers may have carried a This was at times lacking in both the SCD and the
systems/hardware/software title, these individuals
SRID. The lesson, therefore, is to not rush into
possessed a great deal of systems expertise. This
developing detailed implementation be
was also true of the TD and the chief engineers.
top-level system is well defined and U
This effect served to nullify many of the adverse
affects that the skills-based matrix organization all participating organizations.
had on the project. The primary negative impact
that the skills-based organization presented was a Cost is Important Too!
lack of communication between the various skill
departments. The 777 AFDS project organization Due to different requirements, perspectives, and
was able to effectively deal with these organizational areas of emphasis, the engineering teams treated
inefficiencies.

LESSONS LEARNED
Immediately following the completion of the
development activity for the first certification the
Boeing and Collins engineering teams held a series
of video conferences on the subject of lessons
learned. The highlights of these results are given
below.

Requirements Capture understand that outside fac

cost impacts and necessitat
Both teams felt that requirements capture could 3) to increase the visibility
Rave been better. While Collins did participate in
developing the first SCD, this participation was not
enough. The lesson is that Boeing and Collins should design decisions.

654 IEEE TRANSACTIONS ON AEROSPACE AND ELECTRONIC SYSTEMS VOL. 33, NO. 2 APRIL 1997
ACKNOWLEDGMENTS REFERENCES
[1] Hornish, R. R.(1994)
Special thanks to Ron Hornish, Mark Feifar, Mark 777 autopilot flight director system.
Kovalan, and Steve Piller for their inputs and help in In 13th DASC,1994, 151-156.
the preparation of this paper. [2] Andrews, B. A., and Goeddel, W. C. (1994)
Using rapid prototypes for early requirements validation.
In 13th DASC, 1994, 70-75.

Michael Gries received a B.S. in aerospace engineering from Iowa State

University, Ames, in 1987 and an M.B.A. from the University of Iowa, Iowa City,
in 1995.
Mr. Gries has been a systems engineer with Rockwell-Collins Air Transport
Division for six years. During this time he performed systems verification for
the 747/757/767 AFDS, contributed to the systems design for the 777 AFDS,
and was the systems verification lead on the 777 AFDS program. Currently, he
is serving as the Technical Director for the 777 AF’DS program. Prior to joining
Rockwell, Mr. Gries worked at Northrop in flight control systems research and at
McDonnell Douglas on the A- 12 autothrottle design.

GRIES: SYSTEM ENGINEERING FOR THE 777 AUTOPILOT SYSTEM 655