Systems engineering

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, 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 are willing to live with. As a result, 'satisfaction of all technical requirements' is subject to the usual constraints of cost, schedule, and producibility.

"The whole is more than the sum of its parts." Aristotle (384 BCE – 322 BCE)

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 aeroelastic 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 responsibilites 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.

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 (see articles for discussion:and [http://www.sas.com/news/sascom/2004q4/feature_tech.html).

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 (e.g., EEs or SEs) 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-specialities 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 affect on the shaping and reshaping of the tools, methods and processes of SE (e.g., see SysML, CMMI, Object-oriented analysis and design, Requirements engineering, Formal methods and Language theory).

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 (e.g., the Boeing 777 and the various recent Airbuses). 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 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.
"Not surprisingly, eyebrows were raised.
"During the past 25 years, the IRS has twice tried— and twice failed— to modernize."
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."

See also Large Scale Engineering and Evolutionary Change, 2002 by Yaneer Bar-Yam, New England Complex Systems Institute.