1
Engineering Systems: An Aircraft Perspective
Earll M. Murman
Thomas J. Allen
Abstract
Engineering has, in recent decades, taken on the development of systems of
larger and larger scale and increasing complexity. Many examples can be found
in transportation, defense and power generation. Such systems, because of their
size and complexity often have human or social considerations that must be
accounted for, in their design. This paper will treat aircraft as exemplars of
Engineering Systems with the objective of providing a better understanding to
the theoretical underpinnings of this newly developing discipline. The analysis
considers a framework comprising three dimensions - Technical, Social and
Lifecycle - each composed of substructure which characterizes aircraft. An
observation is put forth that interrelationships within and between the
substructures of these dimensions, and among the dimensions, are critical. With
the engineering systems framework in mind, consideration is given to the
aircraft product development process for creation of lifecycle value. A value
creation framework recently presented in Lean Enterprise Value: Insights from
MIT’s Lean Aerospace Initiative (Murman, Allen et.al., 2002) ) is introduced.
The preliminary thinking captured in this paper may serve as a useful starting
point for deeper analysis and study of aircraft engineering systems, and perhaps
other domains.
Introduction.
Engineering has, in recent decades, taken on the development of systems of larger and
larger scale and increasing complexity. Many examples can be found in transportation,
defense and power generation. Such systems, because of their size and complexity often
have human or social considerations that must be accounted for, in their design.
This human/social interface creates a set of boundary conditions that are not normally (or
easily) considered by the engineering science approach that has dominated education for
the past 50 years. This approach, while it has made and continues to make significant
contributions to education and practice, is reductionist in nature and normally ignores or
treats as constant the human/social boundary values of this engineering problem.
This is an issue that has come increasingly to concern engineering educators and
practitioners in recent years. In what has become the traditional manner in engineering,
practice is leading education in this matter. Engineers designing large scale systems have
been forced to go beyond what they learned in school and take account of these factors
in their designs. Educators are now taking cognizance of this and introducing new
courses and programs dealing with engineering systems. In order for these new programs
to be effective, we must now develop an intellectual basis for understanding the nature of
engineering systems. We are presently a long way from that goal.
Murman and Allen
September 2, 2003 Draft
2
In the present paper, the authors hope to provide a small step toward understanding, by
examining one type of complex system, an aircraft, and examining the nature of its
human/social interfaces at different levels of social and technical complexity. It will be
seen how modern aircraft design must be centrally concerned with the human/social
aspects, as these often present the most difficult parts of the design problem.
Engineering Systems Framework
By almost any measure one would choose to examine, e.g. part count, cost, number of
subsystems, product lifetime, etc., aircraft are technically sophisticated, large scale
products. Large organizations comprising many functional areas develop and produce
aircraft, and they have extended enterprises encompassing thousands of suppliers.
Aircraft also have important societal impact, being central to the movement of people and
goods and to national defense. Arguably, they also have significant environmental
impact at both the community level (noise, emissions) and the global level (emissions,
resource consumption). With aircraft lifetimes measured in decades, decisions made early
in their product lifecycle have impact for many years. For these reasons, aircraft
represent an informative example of an engineering system.
Based on the authors' insights, a framework composed of Technical, Social and Lifecycle
dimensions is proposed to characterize engineering systems within the context of aircraft.
The dimension representing the technical realization of the system is comprised of six
levels ranging from individual parts or lines of code to the global environment. The
social dimension embodies all the stakeholders - from individuals to society - again in six
levels. The third dimension called lifecycle represents the time axis of the framework,
from first concept to final disposal of the aircraft. Lifecycle aspects of both the physical
and the social dimensions are important. One might suggest that a dimension
representing economics is also needed. However, the technical dimension encompasses
cost elements and the social dimension encompasses stakeholder value expectations.
Together these represent the important drivers of engineering system economics. It is
therefore suggested that aircraft engineering systems can be mapped into this three
dimensional Technical-Social-Lifecycle space for analysis.
More important than the sheer scale of these dimensions are the interrelationships - the
“inters” - that exist between the dimensions, or between levels within the dimensions.
Interrelationships within the technical dimension are a well known aspect of systems
engineering (e.g. see INCOSE 2000) and will not be dwelt upon in this paper. While it
would be interesting to examine the interrelationships within the social dimension, that
would be a more likely topic for a paper on organizational sociology, per se. In this
paper, we are beginning from a base of a complex technical system and examining the
interrelationships of the technical and lifecycle aspects with the social world.
Murman and Allen
September 2, 2003 Draft
3
An interrelationship is a “mutual or reciprocal relation or relatedness”.1 Interrelationships
are many and varied, and might be characterized by:
• Interconnection: “a state of being connected reciprocally” or Interface: “a surface
forming a common boundary between adjacent regions, bodies, substances, or
phases”
• Interaction: “mutual or reciprocal action or influence”
• Interdependency: “mutual dependence”.
The relationship implied by interdependence is stronger than that by an
interaction/interface or interconnection. For this reason interdependencies will be our
primary, but not sole, focus. It is often suggested that the “inters” are the prime source of
complexity in engineering systems2. For interesting discussions of complexity, see
Sussman (2002) and Mindell (2002).
Another relevant consideration, is the relationship between engineering systems and
systems engineering. Mindell (2002) addresses this topic in depth. Mindell’s paper
contends that systems engineering addresses the internal organization and technical
dynamics, while engineering systems include the broader societal and social contexts.
INCOSE (2000) provides a good discussion of the origins and scope of systems
engineering, noting that it is still evolving, and states:
“Systems engineering is an overarching discipline, providing tradeoffs and
integration between system elements to achieive the overall best product and/or
service. Although there are some important aspects of project management in the
Systems Engineering process, it is still much more of an engineering discipline than a
management discipline. It is a very quantitative discipline, involving tradeoff,
optimization, selection, and integration of the products of many engineering
disciplines.”
This characterization support Mindell’s distinction between engineering systems and
systems engineering. However, it is worth noting that a systems engineering pioneer
Simon Ramo stated (Jackson 2000):
“Systems engineering is a branch of engineering that concentrates on the design and
application of the whole as distinct from the parts.....looking at a problem in its
entirety, taking into account all the facets and all the variables and relating the social
to the technical aspects.”
The distinctions between systems engineering and engineering systems may be more in
how they are practiced and less in how they are defined. Towards the end of this paper
1
Definitions are from http://www.dictionary.com
Integration is an important topic, as are interrelationships, but not considered further in this paper.
Aircraft are highly integrated, both in technical and social metrics. Integrated Product Teams, Integrated
Flight Systems, Integrated Databases and other terms such as these abound in the aircraft field.
2
Murman and Allen
September 2, 2003 Draft
4
we address the topic of stakeholder value and lifecycle value creation. Perhaps the
consideration of the number of stakeholders and their value expectations helps to sharpen
the distinction between system engineering and engineering systems. In this paper, the
authors take the perspective that large scale engineering systems have significant
interaction of the social with the technical and lifecycle dimensions, and this is an
important aspect of engineering systems.
Technical Dimension
Aircraft are physical objects, existing in a physical world consisting of matter and
information - properties that can be quantified, manipulated, and produced. A typical
aircraft has millions of parts and millions of lines of code. Each of these is engineered to
perform a needed function so that the aircraft as a whole can fulfill its expected mission be it civil or military. With several dozen subsystems (fuel, flight control, air data,
payload, weapon, ....) aircraft could be characterized as a system of subsystems. But each
aircraft is only one engineered system within a larger transportation or defense system,
which are often characterized as systems of systems. The technologies embedded in an
aircraft span the full range of those found in a major school of engineering. Indeed, the
majority of engineers in an aircraft company are not aerospace engineers. Electrical,
mechanical, material, computer, civil, chemical, industrial, manufacturing, and other
engineering disciplines are all represented in the design, production, and support of
aircraft. Aircraft certainly represent an interesting example of an engineering system
from a technical viewpoint.
With such a large scale system, it may be helpful to introduce a series of levels
representing the scales of the technical dimension.
Level 0 The physical environment of the world
Level 1 The air transportation system (aircraft, airports, air traffic management ...)
or the air defense system (aircraft, satellites, missiles, ground stations....)
Level 2 The aircraft and/or related systems (trainers, manufacturing systems,
maintenance systems,...)
Level 3 Major aircraft subsystems or subassemblies (radar, flight control, propulsion
hydraulic, power, flap, landing gear....) comprised of both hardware and
software (e.g. Operational Flight Programs)
Level 4 Components (pumps, nacelles, control surfaces, LRUs.....) and major
software units
Level 5 Parts (fittings, fasteners, turbine blades,.....) and lines of code.
Although presented as a hierarchy in scale, the various levels have some analogy to
layers found in software systems. Elements within each level interface directly with the
levels above and below. Interface definitions between levels permit some degree of
interchangeability of elements within the layer. For example, different models of aircraft
can all operate within the air transportation system. An air traffic controller can handle a
large jet or a small general aviation aircraft. Or a given aircraft designer is able to choose
between multiple engines or hydraulic subsystems. However, the layer analogy may not
Murman and Allen
September 2, 2003 Draft
5
hold rigorously and it is best to consider the levels as a hybrid hierarchical and layer
structure.
Although interrelationships within the technical dimension are not the focus of this paper,
a few illustrations are offered for completeness. For example, within Level 3, the wing
and engine are interdependent. The engine is dependent upon the wing structure for
staying aloft, while the wing is dependent upon the engine thrust for staying aloft. And
the performance of each is dependent upon the other through aerodynamic interaction.
To continue, the electrical system is dependent upon the engine for generating power,
while the engine is dependent upon the power system for operation. There are also
interdependencies between levels. For example, the failure of a part at Level 5 can spell
disaster at the aircraft Level 2. This was illustrated by loss of Alaska Airlines flight 261
in January 2000 off the coast of Southern California. It is believed that stripped treads on
a gimbal nut for a jackscrew in the tail of the MD 80 caused loss of elevator control. A
failure to properly lubricate the jackscrew, which was a failure of the interdependent
“Maintenance System”, resulted in the catastrophe. As another example of
interdependence between levels, aircraft propulsion relies on petroleum extracted from
the natural environment. But emissions from individual aircraft engines at Level 3, when
multiplied by the size of the air transportation system of Level 1 can make a measurable
impact on the global environment at Level 0.
Social Dimension
Large, complex engineering systems almost inevitably interact with humans, individually
or collectively. Aircraft are certainly not an exception to this rule. Aircraft are created
through the genius of people and the capability of human organizations, and aircraft are
operated by, and serve the needs of humans. These human stakeholders play out their
roles at different levels of social complexity. There are individual designers, operators
and users. There are design teams, flight crews and cabin crews. There are organizations
that develop, manufacture, operate and support the systems. Finally, there is society
which interacts with this type of system in many ways. These stakeholders for aircraft
systems are many as shown in Figure 1, and their interests vary widely. In particular,
stakeholders have different expectations for the value they will receive from an aircraft a consideration we will return to later in this paper 3.
As with the physical dimension, it is useful to introduce levels of the social dimension
along a scale of social complexity.4:
Level 0
Level 1
3
4
Society, nations, communities, etc.
Extended multi-organization enterprises including partners and suppliers
(could either be extended program enterprise or corporate level multiprogram enterprise with several different business units)
An interesting discussion of aerospace enterprises and stakeholders can be found in (Nightingale, 2002).
The authors acknowledge Alexis Stanke for thoughtful comments on the social levels
Murman and Allen
September 2, 2003 Draft
6
Level 2
Level 3
Level 4
Level 5
Single organizations (could be a division or business unit - may have one
or more programs, projects, etc.)
Organizational units (programs, projects)
Working groups (teams, etc.)
Individuals
Moses (2002) discusses the ways by which engineering system are organized, noting
three basic forms: hierarchies, networks, and layers. This scheme can be applied equally
well to the organizations that produce aircraft systems. In this sense, the levels of
aerospace organizations are a hybrid of the first two. A single aircraft program follows a
basic hierarchy. However the extended enterprise of suppliers is more of a network.
Within a program, an Integrated Product Team is network-like, but the levels within a
program represented by a Work Breakdown Structure are certainly hierarchical. A single
aircraft program involves thousands of suppliers, hundreds of Integrated Product Teams,
tens of thousands of individuals, and many industrial and government organizations. As
with the technical dimension, the scale of the social dimensions for aircraft makes them
interesting examples of engineering systems.
Lifecycle Dimension
Aircraft are characterized by long lifecycles that introduce additional factors adding to
their interest as candidates for engineering systems studies. The lifecycle begins with
conceptual design, progresses through detailed design, and production, testing, into
operation, maintenance and eventually to disposal. Many aircraft models re-enter this
cycle periodically, with upgrade programs. Both commercial and military aircraft are
typically designed for about a 30 year lifetime. But experience shows their lifetimes
exceed this design objective. Military fighters such as the F-14, F-15, F-16 and F/A-18
are being programmed for 40 to 50 year lifetimes. Civilian jet transports are
experiencing similar lifetimes. 85 percent of Boeing 707 models, first introduced in
1957, are still in service as are 67 percent of DC-8 models, a comparable product (Rubel,
2002). On the extreme end, the B-52 is now in middle age. It reached its 50th Birthday on
April 11, 2002 and is projected to be in service until it is 94! Such long lifetimes point to
a number of factors which must be considered when designing engineering aircraft
systems. Let us consider two of these: lifecycle costs and the “ilities”.
A rough characterization is that the costs of operating and maintaining an aircraft are
about twice the cost of purchase (including financing for civilian aircraft). Civilian and
military end users want to minimize total lifecycle costs to provide greater returns on
investments. Figure 2 taken from Fabrycky and Blanchard (1991) illustrates that one has
the greatest leverage to reduce lifecycle costs at the very beginning of a program. By the
end of conceptual design, two-thirds of the lifecycle costs have been determined, even
though only a small fraction has yet been realized. And by the time production starts, 80
percent of the lifecycle costs are locked into the product. The ability to affect substantial
Murman and Allen
September 2, 2003 Draft
7
change in lifecycle costs quickly diminishes with time. Such insights illustrate the
important role of the system architect and preliminary designers who make the critical
decisions determining lifecycle costs, such as number of engines, types of material,
modularity of subsystems, ease of maintenance, etc.. Lifecycle cost represents an
important area of research by those dedicated to the study of engineering systems and an
important topic to include in engineering systems curriculum
Maintainability, supportability, reliability, flexibility, upgradability are but some of the
“ilities” that arise with long lifecycles. Such topics don’t appear in traditional engineering
science subjects. They are part of systems engineering and therefore part of engineering
systems. In fact, the ilities alone could justify considering the lifecycle dimension as
central for engineering systems framework. Consider just one example, the impact of
flexibility and upgradeability on an aircraft such as a B-52. It was originally designed as
a long range, high flying bomber for delivering nuclear bombs. In the Vietnam War, the
B-52 was modified to deliver conventional bombs in controversial carpet bombing
sorties. In Afghanistan it provided close air support at the direction of ground troops
using the smart Joint Direct Attack Munition. What was originally designed to be the
ultimate strategic weapon has now adapted to a very effective tactical role. Such
different missions use a B-52 with the same basic airframe and engines, but with totally
new offensive and defensive electronics and weapons integration - a combination of
flexibility and upgradeability. The example also illustrates the concept of clockspeeds
for different technologies (Fine 1999). Airframe technology evolves much more slowly
than electronics technology, and engines are somewhere in between. Product design
must take this into consideration. Such examples are frequent in aircraft - both civilian
and military.
These two illustrations of lifecycle considerations primarily represent factors of the
technical dimension which evolve with time. Subsequent sections will provide some
illustrations of interrelationships of social factors with the lifecycle dimension.
Technical/Social Interrelationships
Interrelationshipss between the physical and social dimensions are critically significant.
In fact, these lie at the heart of what many, such as Mindell (2002) would hold out as a
defining characteristic of engineering systems. Consider for example the
interdependence between the technical architecture and an individual architect such as
Kelley Johnson who conceived of aircraft such as the U-2 and SR-71. Rechtin (1991)
points out in his book on Systems Architecting that the architect must interact with both
the technical system and multiple levels of the social system. The architect can only
achieve what is possible given the state of technology within the technical dimension. It
is interesting that the product architecture itself can influence the social dimension. In
the military market, the choice of manufacturers for subsystems and components, largely
determined by the modularity of the product, can influence the political support for the
program. The major contractors of the F-22 program (Lockheed Martin, Boeing, Pratt &
Whitney) outsource 60-70% of their product by value to thousands of suppliers in almost
every state of the United States. When the F-22 program funding was seriously
Murman and Allen
September 2, 2003 Draft
8
challenged in Congress, the political support generated through these suppliers was a
major factor in the final vote. Similarly, in the commercial arena, the choice of
international suppliers can significantly influence the likelihood of aircraft purchases.
Taking this to an extreme, we have the question of what are labeled “offsets” connected
with export sales. Aerospace companies, in order to sell their products, often have to
engage in helping potential customers to develop, manufacture or export products that
have absolutely nothing to do with aerospace. Wayne (2003), in a New York Times
report, describes these as simply bribes in a different guise. But they are necessary to do
business in some social systems.
Examining the interrelationships across the technical and social dimensions can go a long
way in helping us to understand and better develop complex systems. In Table I, we can
see a selected set of interrelationships between the two dimensions. This set is far from
exhaustive. It serves to illustrate and suggest of the number and kinds of
interrelationships that can develop between a complex technical system such as an
aircraft and the human/social context in which it operates. It would be interesting to map
out which are interactions and which are interdependencies.
System Components/Individuals. Consideration of interactions at the level of system
components and individual humans is neither new nor proprietary to engineering systems
research and analysis. It is the territory of what has been labeled for many years the
“man-machine interface” or human engineering. Nevertheless, it is an important issue
that must be accounted for in the design of engineering systems. One need only consider
the fatal crash of the A320 aircraft in Strasbourg in 1992 (Carhart, et. al., 1999) to realize
this. The crash is attributed to the misreading of a “Dual Mode” instrument in the
aircraft’s glass cockpit instrument system. The aircraft was in final approach to landing
when the pilots apparently misread the instrument, which could be set to read either glide
slope angle or vertical speed. The two modes had very similar formats and the pilots
apparently confused them. While the cause of the crash was officially classified as “pilot
error” it might better be attributed to a faulty design of the user interface.
Subsystems/Flight Crews. Flight crew dynamics have long been known to be a cause of
difficulty in operating aircraft. Social psychologists have applied the principles of group
dynamics to activities on the flight deck and have had substantial success in developing
training programs based on the resultant increased understanding. Richard Hackman
(1993) did a very interesting series of studies, in which he flew on the flight deck of
several commercial airliners, He, reports on his observations:
“Anyone who has logged much time watching cockpit crews has experienced both
uplifting and depressing feelings. The first officer, who is flying the leg, calls for
retraction of the flaps even as the captain’s hand is moving toward the lever. The
coordination is smooth and seamless. Or the captain, reflecting privately on the
deteriorating weather at the destination muses “Probably we ought to take a look at
the approach plates for the alternate,” and the first officer, without a moment of
hesitation responds “Yes I’ve got them right here…” Watching a great crew operate
Murman and Allen
September 2, 2003 Draft
9
can be as impressive as watching a superb dance company perform a well-rehearsed
ballet.
“Watching other crews can make you wish you were somewhere else. The
captain’s hand moves towards the lever and then stops halfway, waiting, while
the first officer pointedly keeps his eyes outside and his mouth shut. After some
seconds of awkward silence, the first officer announces, “When I’m ready for
flaps I’ll call for them.” And things go downhill from there. Or when a lastminute runway change results in both pilots, heads down, flipping pages
hurriedly to find the new plate while the observer, his eyes alternating between
the gauges and the traffic outside, hopes that one of them finds it soon”.
These are examples of interaction between level 3 of the technical system and level 4 of
the social dimension. These activities may seem to be independent of the technical design
and to some degree they are. That design should, to the degree possible, take account of
these possibilities and try to create an environment supportive of effective teamwork.
This is an instance in which an engineering system perspective and approach to design
can potentially yield great benefit. Without a solid understanding of the social/behavioral
effects, however, the technical designer is working under a handicap.
Responding to human error and group relations on the flight deck, aircraft designers
have incorporated more and more navigational decisions and even approach and
landing decisions into the flight control software. So, as flight control software
becomes more capable, there develops a design tradeoff over how much of the
decision process to automate and how much to leave to humans.
Bowers, et. al., (1993), in an interesting experiment using high fidelity flight
simulators, found that for truly critical decisions less automated systems still
outperformed more automated ones. These results and analyses of the causes of
crashes such as the one in Strasbourg have brought criticism on the degree of
automation incorporated into many modern aircraft. Carhart, et. al. (1999) argue that
“…the plane is so automated that the pilot is for the most part reduced to the role
of system manager, programming in flight paths and such, while the computer
actually flies the plane. With little to do, pilots become complacent.”5
This is an important area that warrants further study and one which should help lay
out guidelines for software improvement.
Turning from commercial passenger aircraft to military, we find, for at least high
performance fighter aircraft, an essential need for an extreme degree of automation.
Flying these high performance aircraft is simply beyond the capability of human beings.
5
A close colleague, who has flown in the jump seat on transpacific flights, tells us that on such flights the
flight crew has little to do but check in by Satcom once per hour.
Murman and Allen
September 2, 2003 Draft
10
The plane has to be flown by computer. The human is along to provide computer inputs
(functioning in other words as a type of complex sensor) and to perform the few
remaining critical decisions. Carried to its extreme, we have the unmanned aerospace
vehicle or UAV such as the Predator which has recently captured the headlines in
Afghanistan and Yemen. Plans go far beyond what we have seen so far, however.
Boeing is now testing a far more advanced unpiloted Reconnaissance/Attack Unmanned
Combat Aircraft, the X-45, and talks of the eventual production of pilotless cargo
aircraft, which would be able to deliver express parcels from New York to Frankfurt with
no one aboard.
Here is an effort to deal with a particularly troubling system interface by eliminating it.
It would seem, however, that as we eliminate interfaces at higher levels (e.g., Levels 4
and 5) of social complexity, we will not only retain those at lower levels but may indeed
complicate them. Eliminating human operators from cargo aircraft will certainly raise
concerns at Level 1 (air traffic system) of the technical dimension over the safety of
people on the ground and in other aircraft that may be flying at the same time. It will
also extend the limits of the engineering system to include an extended ground-based
navigational system and ground-based Non-Pilot Operator personnel6. The technical
interface with Social Levels 4 and 5 may not be entirely eliminated but shifted to a new
location and Level 3 difficulties may be increased. It will be interesting to see how this
develops.
At a still lower level on both the technical and social dimensions, the Hub and Spoke
System of scheduling and routing commercial airline flights (Technical Level 1) has
converted many airports into shopping malls (Social Level 1). Under this system,7 flights
are scheduled to fly between hubs where passengers are discharged and enabled to board
connecting to their eventual destinations. Since there is often a time lapse between the
arrival an departure times, passengers have to spend in the airport. It wasn’t long before
a few enterprising restaurateurs saw this a business opportunity. They were soon
followed by usually up-market shops that saw a good potential market in the swarms of
bored affluent passengers, inhabiting hub airports. This has proven to be a boon to both
the businesses and to the airports that rent them space.
Lifecycle/Social Interrelationships
The elements of the social dimension evolve with time leading to lifecycle/social
interrelationships. One interesting example is knowledge management, an area of high
current interest due to loss of employees through retirements and downsizing. Capturing
and retaining knowledge pertinent to a particular aircraft over a lifecycle span of several
human generations is a major challenge. For engineered products whose lifecycle is
comparable to the design cycle (e.g. personal computers), knowledge is generated and
refreshed in an ongoing fashion. Most engineers look forward to working on a program
6
The potential payoff to this is huge. It is estimated that total unit production cost of an Unmanned
Combat Aerospace Vehicle (UCAV) could be 50 percent of a comparable piloted aircraft and the lifecycle
cost could be reduced by 75 percent, since it is no longer required to train and maintain proficient pilots.
7
Origially developed for package delivery.
Murman and Allen
September 2, 2003 Draft
11
for several years and then advancing to their next career opportunity. But when the
product lives on beyond the original designers or manufacturers, critical knowledge may
be lost. With the wave of consolidations and mergers in the aerospace industry during
the 1990s, a number of organizations started knowledge management activities. Most of
these rely on electronic information systems to capture and categorize the knowledge
residing in higher levels of the social dimension. The success of these is still to be
determined.
One approach which accomplishes the re-generation, capture and transfer of knowledge
is the use of product upgrades. The F-16 program began in the early 1970’s and went
into production in 1977 with the A/B models. Since then, there have been nine major
upgrades, each incorporating many new features. The knowledge embedded in the
current F-16 team at Lockheed Martin is excellent (Stanke, 2002). A similar process
occurs with commercial aircraft products. The Boeing 737 was designed in the 1960’s.
There have been two major upgrades with the 737-300/400/500 and 737600/700/800/900 series. Currently the 737 program is undergoing major production
changes with the incorporation of lean practices, including transition to a moving
production line. Whatever the strategy, capture and retention of engineering knowledge
about a particular aircraft system becomes an important consideration when lifecycles are
long.
As another example representing an interrelationship at the lower level of the social
dimension, products with lifecycle of many generations need to be robust to changes in
society's attitudes and values which generally evolve over time scales measured in
generations. A good example of this for aircraft falls in the environmental area. The
early generations of jet transports had low bypass ratio jet engines which by and large
were very noisy by today’s standards. Although such aircraft as the DC 9 and B-727 are
still fit for operation, they simply don’t meet today’s Stage III noise regulations. The fix
has been to install after market hush-kits to quiet the engines. However, these products
are doomed to disappearance from many countries because society will no long accept
the impact on their community environment. New generations of aircraft must meet
increasingly stringent community noise standards which have led to a reduction of 10 dB
since 1980 and will need to have an additional 6 dB reduction by 2020.
As a final example, consider the effect of individuals hijackers or small groups of
terrorists on aircraft design and operation. D.B. Cooper’s hi-jacking of a B-727 on
November 24, 1971 made rear exit ramps obsolete. Subsequent hijackings led to the
need for the extensive and expensive airport security systems the traveling public is all
too familiar with. And the terrorist incidents of September 11, 2001 turned commercial
airliners into cruise missiles. This is leading to design changes and upgrades to cockpit
access and other features of commercial aircraft. And it may well lead to a new balance
between large scheduled carrier jet transport and smaller charter or fractional ownership
business jets. The lessons learned from these examples indicate that engineering systems
architects and designers need to understand the “expectations” of people who seek to
undermine society as well as the intended users of the products.
Murman and Allen
September 2, 2003 Draft
12
Product Development
Product design and development is certainly the aspect of engineering systems where the
human/social interface is, in many ways, strongest. At an individual level (Level 5) there
are the issues of creativity, problem solving, personnel selection, motivation and rewards
and many other aspects that are for the most part not peculiar to engineering systems. It
is much more at levels 2 and 3 of both the technical and social dimensions that
engineering systems have a different effect on product development. As size and
complexity grow so too does management difficulty and complexity in organizing. We
are no longer dealing with individuals, as individuals. The important social entity now is
the group or the group of groups that we call an organization. The needs of engineering
system developments have stimulated innovation in organizational structure. It was the
development of an engineering system in aerospace that produced the first matrix
organization, for example. So what are the characteristics of engineering systems that
have the greatest effect on organizational structure? One is certainly the high degree of
interdependence inherent in their architecture. Another is the degree of interfunctional
relations that are inherent in large scale aerospace system development. A third is the
difficulty that is often encountered in transferring large systems such as aircraft from
product development and into manufacturing. Let us first focus on two of these issues
together, viz, architectural interdependence and interfunctional interdependence.
The form of group that is most important in product development is the project team.
Both of these lead to a requirement that development work be done in teams or groups.
These are generally labeled “project teams”. A project team is a group of individuals,
mostly engineers, working together to develop a new product, in this case an airplane.
The total project team can be very large and comprise many smaller groups or teams.
The smaller groups are often projects, in themselves, each working to develop some
element or subsystem in the aircraft. Since interdependence among the subsystems
(fuselage, wing, navigational subsystem, communication subsystem, flight deck, etc.) is
very high, the work of the various subgroups is also very interdependent. Therefore, if
these groups are left to reside in separate departments, coordination among them becomes
very difficult, leading to interface problems, errors in design and so on. For this reason,
the project team form of management was developed. It soon turned out that the project
team presented a different set of difficulties. Engineers became too focused on a
particular product development and tended to lose sight of new developments in their
specialty beyond their particular project. They needed to have greater contact with their
disciplinary colleagues back in their “home” department. Thus was born the matrix
organization. It first appeared in the aerospace industry, largely due to the complex
nature of the engineering systems that industry develops (Cf. Allen, 1986).
At the outset, a single individual, the project manager or program manager, managed the
project side of matrix organizations. This is where budget responsibility usually lay and
where the responsibility for coordination across engineering departments also resided.
While this could be made to work within the product development or system
Murman and Allen
September 2, 2003 Draft
13
development function, it contributed little to managing relations with other functions
such as marketing and manufacturing. To address this issue, companies began to create a
joint program management function in which managers from more than one function
shared project responsibility. Motorola was one of the first to adopt this scheme by
giving joint responsibility for developing a product to a pair of managers, one from
product development, the other from marketing. This later expanded to become what are
now called “integrated product teams”, or IPTs, which include managers from
engineering, manufacturing, tooling, marketing and other functions. The next step in this
development was to extend the IPT to include all of the design engineers and others who
would be involved in the development and manufacture of the system. Such teams were
then created at both the system and subsystem levels, resulting in a layered hierarchy of
Integrated Project Teams. Browning (1996) provides data that makes a strong argument
for the effectiveness of IPTs operating at different levels, e.g. subsystem project teams,
system level teams and program level teams (corresponding to Levels 4 and 5 in our
structure). IPTs can perform an effective integrating function within the organization,
provided there is a full commitment and participation on the part of all members. The
difficulty often sets in when team members are too distracted by or overly committed to
activities within their specialized functions.
It is very important to remember that it is the very nature of large, complex engineering
systems that forced the creation of all of these organizational innovations for use in their
development8. Simpler developments, involving fewer technologies and smaller
engineering teams just do not warrant or need the degree of organizational complexity
described here. It wasn’t until engineering encountered the difficulties of large scale
architectural interdependencies and the resulting need for close coordination across many
dynamic technologies that such organizations had to be created.
Another organizational area that is affected by engineering systems development is that
of supply chains. While suppliers of parts, components and entire subsystems are needed
for even the simplest of projects, the scale and complexity of engineering systems
certainly increases the need for and dependence upon suppliers (Fine, 1999). Vertical
integration back along the supply chain is possible but with the diversity of requirements
in a large complex system it becomes very difficult and possibly undesirable to attain.
Ford Motor Company, in fact, recently devolved by spinning off their parts division as a
separate company. (Henry Ford must have rolled over in his grave.) With the growth in
size and complexity and investment requirements, aircraft manufacturers have confronted
a need for greatly increased reliance on suppliers for even very large subassemblies
(fuselage sections, empennage, etc.) and entire subsystems (electrical system, hydraulic
system, flight control system, etc.). Suppliers are now being integrated into customer
IPTs. This is to provide early information to both customer and supplier. Once again, we
see the complex needs of engineering system development fostering creativity in
organizational design.
8
Some of these, such as matrix have been applied much more broadly beyond system development, with at
best mixede results.
Murman and Allen
September 2, 2003 Draft
14
Engineering System development, particularly in aerospace, is responsible for a host of
other management innovations. PERT and the Critical Path Method of project scheduling
and monitoring are obvious examples. The complex requirements of developing such
large complex systems pushed beyond existing managerial knowledge and capabilities
and forced innovation. Many of these innovations are now diffused widely, to the general
benefit of other industries and firms. This is a contribution stemming from the
development of engineering systems that is largely unrecognized.
Value Creation Framework
Given the wide span of the three dimensions introduced above and the interactions and
interdependencies among them, one might ask what approach can be used to successfully
conceive, design and develop such a complex engineering systems as an aircraft. It is an
understatement to say that aircraft and other engineering systems represent an enormous
challenge to engineers. Well established engineering design techniques used in products
of lesser scale would simply fail to address the technical, social and lifecycle issues of an
engineering system. In a recently published book (Murman, Allen, et. al 2002), the value
creation framework shown in Figure 3 was introduced. Although it is relatively new, it is
offered as a useful starting point as a framework for the development and operation of
engineering systems. A short overview is given here, suggesting the interested reader
refer to the book.
The value creation framework has three conceptual phases - value identification, value
proposition, and value delivery - which collectively aim at “doing the right job” and
“doing the job right”. A critical step, indicated earlier in the paper is identifying all the
key stakeholders (Figure 1) and their value expectations. . For an engineering system of
the scope of an aircraft, this is not easy. But it is necessary for a successful system.
Although the phases of Figure 3 are conceptually distinct, in practice they may be applied
iteratively as indicated by the small looping arrows. The value identification and value
proposition phases may be closely coupled. They should definitely precede the value
delivery phase. For the engineering system to adapt to changes in the technical and
social dimensions, the phases need to be periodically revisited throughout the lifecycle,
as indicated by the larger looping arrows. Value expectations of the key stakeholders
may change and the engineering system needs to adapt. A recent example of this is the
post September 11 expectations for commercial air transportation. The applicability of
the value creation framework to programs, corporate or government enterprises, and the
national level is considered in some depth in the Murman, Allen et. al. book.
Murman and Allen
September 2, 2003 Draft
15
Lifecycle Value Creation in Product Development
The value creation framework emerged simultaneously with a research study by Stanke
(2001) that focused on four aircraft programs which had, by some measure, been deemed
successful at product development for lifecycle value creation:
777-300 - a recent upgrade to a large Boeing commercial jet transport
F/A-18E/F - the newest version of the Navy’s multi role tactical aircraft
F-16 C/D - an evolutionary USAF fighter with many international customers
JAS 39 Gripen - a clean sheet Swedish design for a multi-role tactical aircraft
The objective of the research was to identify the practices used by these programs to
achieve lifecycle value creation. Findings showed that many practices were common
among these four programs, and they could be grouped into six categories of value
attributes that span the three phases of the Figure 3 value framework9
•
•
•
•
•
•
Holistic Perspective - both in terms of the entire system and its entire lifecycle.
Organizational Factors - including cross-functional teams, organizational structure,
and enterprise culture.
Requirements and Metrics - developing, allocating, managing, and tracking
requirements.
Tools and Methods - modeling and simulation tools, system engineering and risk
management methods, and other process models for, among others, business practices
and information systems.
Enterprise Relationships - open and honest communication, mutual trust, and respect
amongst the stakeholders.
Leadership and Management - leading the program enterprise and interfacing with
the multi-program and national enterprise, as well as managing program enterprise
people and processes.
These value attributes and practices which support them (Stanke 2002) span the three
dimensions of the engineering systems framework we have been discussing. Based upon
four aircraft programs that have obtained some measure of lifecycle value, they offer
evidence that all three dimensions are important.
Summary
A three-dimensional engineering systems framework based on technical, social and
lifecycle factors has been introduced in this paper. It seems clear that technical and
social dimensions are important to engineering systems. To the authors, it also seems
clear that lifecycle issues are important. An important element of the proposed
engineering systems framework centers on creation of lifecycle value. The engineering
systems framework introduced in this paper emerged from discussions of the need for
greater understanding of the nature and essentials of engineering systems.
9
The reader is referred to Stanke’s thesis for more details.
Murman and Allen
September 2, 2003 Draft
16
References
Allen (1986)
Bowers (1993)
Browning, T., (1996) Multi-team integration: Interdependence and integrative
mechanisms, Proceedings of the Sixth International Symposium of INCOSE, pp 787-794
Carhart, A., K. Chan, A. Hu, A. Kosut and Brian Ku (1999) A Study of Critical Systems
in Military and Commerce, http//cse.stanford.edu/class/cs201/projects-99-00/critical –
systems/index.htm
Fabrycky, W. and Blanchard, B., (1991).Life-cycle Cost and Economic Analysis,
Prentice-Hall
Fine, C. (1999) Clockspeed: Winning Industry Control in the Age of Temporary
Advantage, New York: Perseus
Hackman, J.R. (1993) Teams, leaders and organizations: New directions for creworiented flight training, in E.I. Wiener, B.G. Kanki and R.L. Helmreich, (eds) Cockpit
Resource Management, New York: Academic Press
INCOSE (2000), Systems Engineering Handbook, International Council on Systems
Engineering, Version 2.0
Jackson, S., (1997) Systems Engineering for Commercial Aircraft, Ashgate Publishing
Ltd.
Mindell, D., (May 2002) Three regimes of systems: The history of systems thinking in
engineering, Proceedings of the MIT Engineering Systems Division Internal
Symposium, Cambridge, MA.
Moses, J. (May 2002) The anatomy of large scale systems, Proceedings of the MIT
Engineering Systems Division Internal Symposium, Cambridge, MA.
Murman, E. M., Allen, T.J, et al , (March 2002) Lean Enterprise Value: Insights from
MIT’s Lean Aerospace Initiative, London: Palgrave.
Nightingale, D, (May 2002) Lean enterprises, Proceedings of the MIT Engineering
Systems Division Internal Symposium, Cambridge, MA.
Murman and Allen
September 2, 2003 Draft
17
Rechtin, E. (1991) Systems Architecting: Creating and Building Complex Systems,
Prentice Hall
Rubel. H. (2002), Aerospace and Defense: The Week in Review. Goldman Sachs. April
19.
Stanke, A., A Framework for Achieving Lifecycle Value in Product Development,
MIT SM Thesis, June 2001
Sussman, J. , (May 2002) Views of complexity, Proceedings of the MIT Engineering
Systems Division Internal Symposium, Cambridge, MA.
Wayne (2003)
Murman and Allen
September 2, 2003 Draft
18
Customer
Acquirers
End Users
Consumers
Partners
Shareholders
Enterprise
Employees
Suppliers
Corporation
Society
Unions
Figure 1 - Aircraft Enterprise Stakeholders (Murman, et.al, 2002)
LCC committed
100%
80%
Cost Incurred
66%
Ease of Change
Conceptual/
preliminary
Design
Detail
design/
development
Production
and/or
construction
Product use/
support/
phaseout/dispos al
Figure 2 - Lifecycle cost committed vs incurred (Fabrycky and Blanchard, 1991)
Murman and Allen
September 2, 2003 Draft
20
Value
Identification
Value
Proposition
Find
Stakeholder
Value
Agree to and
develop the
approach
Value
Delivery
Execute
on the
promise
Figure 3 - Value Creation Framework (Murman, et. al 2002)
Table I
A Sampling of the Interrelations That Exist Between the Technical and Social Dimensions of Aircraft
Level
0
1
2
3
4
5
Individual
Group
Organizational
Unit
Organization
MultiOrganization
Enterprises
Supplier
Relations
Society
Instrument/
Pilot
Design
Teams
0
Parts
1
Components
2
Subsystems/
Subassemblies
Flight
Crew
3
Aircraft
Project
Teams
IPTs
4
Air Transport
System
5
World
Environment
Murman and Allen
Supplier
Relations
Integrated
Product
Teams
(IPTs)
Matrix
Organizations
Supplier
Relations
Matrix
Organizations
Noise &
Emissions
Noise &
Emissions
Traffic
Control
& Airport
Malls
Hub/Spoke
System &
Airport Malls
Cumulative
Environmental
Effect
September 2, 2003 Draft