SYSTEM ENGINEERING & NETWORKING

Systems engineering is an interdisciplinary approach and

means for enabling the realization and deployment of
successful systems. It focuses on defining customer needs
and required functionality early in the development cycle,
documenting requirements, and then proceeding with design
synthesis and system validation while considering the
complete problem: operations, environment, design,
development, manufacturing, deployment, cost & schedule,
performance, training, maintenance, test, and disposal.
Systems Engineering integrates all of the engineering
disciplines and specialty groups, or ilities, into a unified,
team effort, forming a structured development process that
proceeds from concept to production to operation and, in
some cases, through to termination and disposal. System
Engineering is usually directly responsible for any
engineering function that is not deemed sufficiently
necessary on a project to require a full-time, specialist
engineer, although consultants may be enlisted as needed.
Ideally, Systems Engineering considers both the business
and the technical needs of all customers with the goal of
providing a quality product that meets the user needs.
However, the reality in any very large project is often that
user needs exceed what the sponsor is willing to pay for; and
the schedule to satisfy those needs generally exceeds what
either of them is willing to live with. As a result, 'satisfaction
of all technical requirements' is subject to the usual
constraints of cost, schedule, and producibility.

Overview:
Using a systems engineering approach, large and/or highly
complex engineering projects are often decomposed into
stages and then managed throughout the product or system
lifecycle. This process of managing the system's lifecycle
resembles a series of interconnected engineering projects,
each executed in sequence and drawing upon the results of
preceding or contemporaneous projects, until the desired
end result is achieved.

The systems engineering role may have originated as the

lead or project engineer who was assigned principal
responsibility for orchestrating these large and complex
engineering programs, and/or as the single point of
reference responsible for the entire engineering activity
preferred by the United States Government on its large
programs (especially to be responsible for the huge amount
of extra documentation required of Government programs).
However, systems engineering quickly became synonymous
with the overarching responsibility for development of the
complete end product (hardware, software, services) and
enabling products (e.g., the 'systems' that produce and test
the target system). This role has increasingly expanded, until
the present, when it is also (primarily) responsible for the
interface between the complete device and the user, and
even with the systems eventual disposal. While hardware
engineering typically deals with just hardware and software
engineering with just software, the systems engineer is
responsible for seeing that the software properly operates on
the hardware, and that the system composed of the two
entities is capable of properly interacting with its external
environment, especially the user, while performing its
intended function. As a general proposition, the systems
engineer is especially concerned with the engineering
'ilities.'

Taking an interdisciplinary approach to engineering systems

is inherently complex, since the behavior of and interaction
among system components are not always well defined or
understood (at least at the outset). Defining and
characterizing such systems and subsystems, and the
interactions among them, is the primary aim of systems
engineering. On very large programs, a systems architect
may be designated to serve as an interface between the
user/sponsor and systems engineer.
There are several methods and tools that are frequently
used by systems engineers:

• requirements capture; requirements analysis

• systems architecture and design
• functional analysis
• interface design and specification
• communications protocol design and specification
• simulation and modeling
• verification and validation/acceptance testing
• fault modeling

History:
Rear Admiral Grace Hopper (of the United States Navy
Reserve) has been quoted as saying "Life was simple before
World War II. After that, we had systems."

The first significant systems engineering was performed for

telephone systems. All the different parts of the phone
system have to interoperate reliably. An excellent overview
of the interfaces and logic, with some history, is "Digital
Telephony" by John C. Bellamy. For operational telephony
terms, see Newton's Telecom Dictionary, for example. The
field grew around the time of World War II with the
development of increasingly complex military systems.

In 1990 a professional society for systems engineering, the

National Council on Systems Engineering (NCOSE), was
founded by representatives from a number of US
corporations and organizations. NCOSE was created to
address the need for improvements in systems engineering
practices and education. As a result of growing involvement
from systems engineers outside of the U.S., the name of the
organization was changed to the International Council on
Systems Engineering (INCOSE) in 1995.

Scope:
In recent times, industry in general has begun to accept that
the engineering of systems, both large and small, can lead to
unpredictable behavior and the emergence of unforeseen
system characteristics. Decisions made at the beginning of a
project whose consequences are not clearly understood can
have enormous implications later in the life of a system, and
it is the task of the modern systems engineer to explore
these issues and make critical decisions. There is no method
which guarantees that decisions made today will still be
valid when a system goes into service years or decades after
it is first conceived but there are techniques to support the
process of systems engineering. Examples include the use of
soft systems methodology, Jay Wright Forrester's System
dynamics method and the Unified Modeling Language (UML),
each of which are currently being explored, evaluated and
developed to support the engineering decision making
process.

Systems engineering often involves the modeling or

simulation of some aspects of the proposed system in order
to validate assumptions or explore theories. For example,
highly complex systems such as aircraft are usually modeled
and simulated before flight. In this way the initial aero elastic
engineering and control equations can be drafted and
improved upon before any physical system is ever
constructed. Since aircraft are often very expensive, this
reduces the expense and difficulty of debugging the controls
and reduces the risk of crashing real aircraft. Careful initial
testing and flight envelope expansion are typically still
required to reach acceptable levels of safety and
performance in advanced aircraft.

The role of the system engineer, together with (perhaps) a

safety engineer, is especially important when systems must
have especially predictable/reliable behavior. For example,
power plants (especially nuclear), medical machinery, and
spacecraft usually consist of many individually engineered
and manufactured parts, by different companies. System
engineering provides the assurance that normal operations
(and even some explicitly defined abnormal operations),
including parts failures, will not provide a hazard for the user
or anyone else in the community. Other high-reliability,
potentially hazardous applications are communications
systems, or commercial systems, such as ATM machines,
where failures can cause serious loss of property or serious
economic or liability exposure. The application of systems
engineering processes may also result in significant cost
savings, as well as providing a reasonable (up-front)
assurance of the eventual success of the project.

Generally, a neat breakdown of roles and responsibilities

among the various types of architects and engineers can't be
done, as there are no neat boundaries, but instead a
continuous overlap— which is program and people specific.
That is, there are no neat boundaries between systems
architecture and systems engineering, or between systems
engineering and software engineering/architecture (or any of
the other "ilities"). Only the hardware engineer still
maintains a (relatively) neat boundary, but even that may be
violated, depending on the people and program. For
example, firmware embedded into a micro-controller is often
assigned to the hardware engineer, but it is essentially a
software development.

On a huge (generally, government) program, there may be

one or more systems architects, systems engineers, software
architects (rarely, since the systems architect usually
assumes this role), and software engineers.

In any case, the specific roles and responsibilities must be

separately negotiated on each program by the
people/engineers involved (hopefully) according to their
capabilities and inclinations.

To make things more confusing (perhaps) is that none of

these roles are to be considered as supervisory or
management roles. Rather, the various roles relate to each
other in order of precedence of input to the program
requirements/specification. The architect roles precede the
engineering roles, and the systems (engineering) role
precedes the other engineering roles, in order of input. Any
disagreements among the players must be negotiated away.
But, generally, on the large programs, there is one Chief
Engineer whose word is law (regardless of what discipline
s/he comes from).

Closely Related Fields:

Many related fields may be considered tightly coupled to
systems engineering. Many of these areas have contributed
to the development of Systems Engineering as a distinct
entity.

Cognitive systems engineering:

Cognitive systems engineering is Systems Engineering with
the human integrated as an explicit part of the system. It
depends on the direct application of centuries of experience
and research in both Cognitive Psychology and Systems
Engineering. Cognitive Systems Engineering focuses on how
man interacts with the environment and attempts to design
systems that explicitly respect how humans think. Cognitive
Systems Engineering works at the intersection of: (1) the
problems imposed by the world, (2) the needs of agents
(human, hardware, and software), and (3) the interaction
among the various systems and technologies that affect
(and/or are affected by) the situation.

Sometimes referred to as Human Engineering or Human

Factors Engineering, this subject also deals with ergonomics
in systems design. But Human Engineering is more properly
viewed as just another engineering specialty that the
systems engineer must deal with.

Control systems design:

The design and implementation of control systems, used
extensively in nearly every industry, is a large sub-field of
Systems Engineering. The cruise control on an automobile
and the guidance system for a ballistic missile are two
examples. Control systems theory is an active field of
applied mathematics involving the investigation of solution
spaces and the development of new methods for the
analysis of the control process.

Interface design:
Interface design and specification are concerned with
assuring that the pieces of a system connect and
interoperate with other parts of the system and with external
systems as necessary. Interface design also includes
assuring that system interfaces be able to accept new
features, including mechanical, electrical, and logical
interfaces, including reserved wires, plug-space, command
codes and bits in communication protocols. This is known as
extensibility. Human-Computer Interaction (HCI) is another
aspect of interface design, and is a critical aspect of modern
Systems Engineering.

Systems engineering principles are applied in the design of

network protocols for local-area networks and wide-area
networks.

Operations research:
Operations research, or OR, is sometimes taught under
departments of Industrial Engineering or Applied
Mathematics, but the tools of OR are also taught in a
Systems Engineering course of study. OR is concerned with
the optimization of an arbitrary process under multiple
constraints.

Reliability engineering:
Reliability engineering is the discipline of ensuring a system
will meet the customer's expectations for performance
throughout its life. Reliability engineering applies to all
aspects of the system. It is closely associated with
maintainability, availability and logistics engineering.
Reliability engineering is always a critical component of
safety engineering, as in failure modes and effects analysis
(FMEA) and hazard fault tree analysis, and of security
engineering. Reliability engineering relies heavily on
statistics, probability theory and reliability theory for its tools
and processes.

Safety engineering:
The techniques of safety engineering may be applied by non-
specialist engineers in designing complex systems to
minimize the probability of safety-critical failures. The
System Safety Engineering function helps to identify safety
hazards in emerging designs, and may assist with
techniques to mitigate the effects of (potentially) hazardous
conditions that cannot be designed out of systems.

Security engineering:
Security engineering can be viewed as an interdisciplinary
field that integrates the community of practice for control
systems design, reliability, safety and systems engineering.
It may involve such sub-specialties as authentication of
system users, system targets, and others: people, objects,
and processes.

Software engineering:
From its beginnings, Software engineering has shaped
modern SE practice to a great degree. The techniques used
in the handling of complexes of large software-intensive
systems has had a major effect on the shaping and
reshaping of the tools, methods and processes of SE.

Outstanding SE Successes and Failures:

The Successes:
Systems engineering (SE) practices were used during the
critical period of ballistic missile development, both at NASA
and the United States Department of Defense. The initial
U.S. failures of booster programs following Sputnik were
overcome, resulting in the spectacular success of the Project
Apollo moon-landing program. Systems engineering
successes in the design and development of the Polaris
ballistic missile system led to unqualified successes of the
submarine-based intercontinental ballistic missile systems
that have culminated in the Trident missile D5 system.
Similar successes were realized in the development of land-
based missiles and in the development of military and
commercial aircraft. In addition, virtually all major weapons
systems acquired by the U.S. military since the 1970s have
been acquired using system engineering techniques.

Partly as the result of this long history of SE development in

the military, military weapons use subsequent to Vietnam
have generally proved to be spectacularly successful, with
little unexpected failure of (even complex) weapons
systems.

In addition, the major advances of the telecommunications

industry in recent years were largely made possible using
systems engineering techniques, resulting in the successes
of the industry as we know it today.

SE has played a major role in producing many recent

'revolutions' in technology development.

The Failures:
When Systems Engineering Fails — Toward Complex Systems
Engineering
"The images of success in the Manhattan and Space Projects
remain with us. What really happens with large scale
engineering projects is much less satisfactory. Many projects
end up as failed and abandoned. This is true despite the
tremendous investments that [have been] made…"

The failure of the Federal Aviation Administration's Advanced

Automation System has been reasonably well documented.
(See above citation.) Indeed, this represented such a
complete failure, that the prime contractor sold the entire
division hosting the project, over a year prior to the
dénouement!

Nevertheless, the failure was not primarily a SE failure. The

principal failing was that, for all of the people involved,
government and contractor, managers and engineers, the
AAS Program represented at least an order of magnitude
larger and many magnitudes more complex than any they
had ever experienced or even envisioned. And, there were
entirely too many players and not enough workers. There are
many valuable lessons that could be learned from it, but
unlike civil engineers (whose failures usually involve civil
liability), SEs rarely get an opportunity to dig deeply into
their failures.

Report of the Inquiry Into The London Ambulance Service

(February 1993)
"In the autumn of 1990, following the abandonment of the
previous attempt to computerise the LAS Command and
Control system, work commenced on the preparation of a
requirements specification which would lead towards the
implementation of a 'state of the art' Command and Control
system. It should be noted that the previous system was
abandoned after load testing revealed that it would not cope
with the demands likely to be placed upon it…"

In the end, the new 'state of the art' system was abandoned
after a cost of $2.5M and perhaps 20 lives. The LAS was
reduced to the following coda: "The fact is that of the 26
cases considered by coroners' courts since November 1991,
we are advised that not a single one has concluded that the
LAS can be blamed for the death of a patient."

The Ongoing Saga of the U.S. IRS Tax Modernization Effort

The Taxman's burden, CIO Mag., 1 April 2001 "IN JANUARY,
just three months before the internal revenue service
planned to field a new call center application, its first system
upgrade in a $10 billion modernization project, its CIO of
almost three years, Paul Cosgrave, quit.
GOVExec, 1 August 2001
But hope springs eternal…
GOVExec, 15 April 2005 "Todd Grams, Chief Information
Officer at the Internal Revenue Service believes in second
chances. In the simplest terms, he believes the IRS failed in
the past because it bit off more than it could chew. The sheer
scope of the program 'exceeded our collective capacity to
manage it,' Grams concedes candidly."

Systems engineering education:

There are many universities that now offer systems
engineering programs, and many other engineering
programs are changing towards systems approaches to
analysis, design, and testing. Most systems engineering
programs are offered at the masters-degree level, reflecting
the industry attitude that engineering students need a
thorough background in practical, real-world experience
before attempting the more abstract systems engineering
subject matter. Undergraduate university programs in
systems engineering are much rarer, but several institutions
do offer them. INCOSE maintains a continuously updated
Directory of Systems Engineering Academic Programs.

NETWORKING CARD