=Paper=
{{Paper
|id=Vol-1300/TUT01
|storemode=property
|title=Introduction to Systems Engineering
|pdfUrl=https://ceur-ws.org/Vol-1300/TUT01.pdf
|volume=Vol-1300
|dblpUrl=https://dblp.org/rec/conf/ciise/Arrichiello14
}}
==Introduction to Systems Engineering==
https://ceur-ws.org/Vol-1300/TUT01.pdf
INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014)
Rome, Italy, November 24 – 25, 2014
Introduction to Systems Engineering
Vincenzo Arrichiello
INCOSE Chapter Italia
vincenzo.arrichiello@incose.org
Copyright © held by the authors.
Abstract. The word “system” is used in many areas (e.g. solar system, telephone system,
nervous system, transportation system, ecological system, etc.) mainly to convey a meaning of
ordering and/or interaction. The systems of interest for Systems Engineering are a specific
subset: Engineered Systems. These are defined as “an integrated set of elements, subsystems,
or assemblies that accomplish a defined objective.” Having delimitated the area of application,
what appears to be worth to be analyzed is if, and how, Systems Engineering differentiates
itself from “Traditional Engineering”.
A useful, and very concise, reference for the description of engineering (design) is the one
from the Royal Academy of Engineering (Royal Academy of Engineering, 1999):
Need - All design begins with a clearly defined need;
Vision - All designs arise from a creative response to a need;
Delivery - All designs result in a system, product or project which meets the need.
That description applies, without any doubt, also to Systems Engineering, so one is left
wondering whence the need for it originated. Looking more in detail, one can observe that
“Traditional” Engineering activities have been typically limited to a definite discipline, with
practitioners very likely to become “experts” in the relevant field. The design approach usually
applied in these conditions is the “Solution-oriented” approach, “in which an initial solution is
proposed, analyzed and then repeatedly modified as the design space and requirements are
explored together” (Wynn and Clarkson, 2005).” This approach is effective when the designer,
thanks to her/his experience, is able to devise an initial solution that is not too far from the
“ideal” final one. On the contrary, when the solution to the problem at hand spans multiple
engineering disciplines (thus making very unlikely that a single person can master all of them)
this approach proves far less effective, if not a true recipe for disaster.
Likely due to the complexity that increasingly tends to be part also of “traditional” engineering
endeavors, the design process has largely evolved to the “Problem-oriented” approach ,” in
which the emphasis is placed upon abstraction and thorough analysis of the problem structure
before generating a range of possible solutions.” (Wynn and Clarkson, 2005) This approach
bears a strong resemblance to the Systems Engineering process, and it is somewhat telling that
it is defined a “Systematic Design Process”.
Systems Engineering thus appears to have somewhat anticipated this trend of
evolution; a survey of the context in which it first appeared may be of help to better understand
its peculiar characteristics. The term “system” referred to engineering activities and products,
makes its first appearance in organizations dealing with electric power distribution and
telephone networks (notably, AT&T and Bell Labs), in the first half of the twentieth century.
Systems Engineering, in the form of the organized interdisciplinary approach as it is known
today, appears in the early fifties of that century. Its emergence can be mainly tracked to the
concurrence of novelties appearing in three contexts: cultural, technological and historic. The
three elements of the cultural context of major relevance to Systems Engineering are: General
Systems Theory, Cybernetics and Operations Research.
Heralding the birth of the systems science, in 1950 Ludwig von Bertalanffy outlined the
“General System Theory” (GST) (Bertalanffy, 1968). He was driven by the observation of the
limits shown by classical scientific methods when dealing with entities (both biological and
technological) consisting of parts characterized by strong, nonlinear interactions. Noting that
such entities cannot be understood by investigating their respective part in isolation,
Bertalanffy introduces the notion of wholeness: the need to think “in terms of systems of
elements in mutual interaction.” Knowing not only the parts, but also the relations, enables to
understand the characteristics of the whole which depend on the relations between its
components, and are not explainable from the sole characteristics of isolated parts; those
characteristics therefore appear as “new” or “emergent.”
Another GST tenet is the concept of Open system (contrasted with the “closed system”
typical of reductionism). An open system cannot be isolated by its environment; on the
contrary this last must be thoroughly taken into account in order to understand the system and
its behavior. Bertalanffy also highlights as fundamental the concept of hierarchic order, which
was further developed by other scholars.In the same years, science was developing new
understandings in the fields of information and automatic control, mainly thanks to the works
of Claude Shannon, Warren Weaver and Norman Wiener.
Applying a broad outlook spanning from technology to biology up to social systems,
Wiener coined the term “Cybernetics” to denote a new field of science devoted to the scientific
study of “Control and Communication in the Animal and the Machine (Wiener, 1948).”
Feedback (defined as “the property of being able to adjust future conduct by past
performance”) (Wiener, 1950) is the central concept of Cybernetics. Wiener classes
communication and control together, and portrays feedback as a two-way exchange of
information between the system and its environment. This way he somewhat extends
Bertalanffy’s open systems concept by seeing the “automata” coupled to the external world,
not merely by a flow of energy, but also by a flow of incoming and outgoing messages.
In a previous work (Rosenblueth, Wiener and Bigelow, 1943) Wiener had defined the
“behavioristic approach”, consisting in the “examination of the output of the object and of the
relations of this output to the input” equally “applicable to both machines and living
organisms.” This, on one side allows to define the term “black box” to indicate an element
performing a definite operation “but for which we do not necessarily have any information of
the structure by which this operation is performed” (Wiener, 1948), as contrasted with a “white
box” in which internal structure is determined and known. On the other side the approach of
treating in the same way machines and living organisms, favored the trend to see systems as a
combination of interconnected elements coordinating together toward a specific purpose (the
“organic analogy”; e.g. depicting an Air Defense System as an “organism” possessing “sensory
components, communication facilities, data analyzing devices, centers of judgment, directors
of action, and effectors, or executing agencies”) (PRADSEC, 1950).
Operations Research originated during World War II as a means to support decisions
about the most effective employment of resources; it proved highly successful and, after the
war, it was applied also in fields other than the military. The same methods of mathematical
modelling and statistical analysis lend themselves well also to evaluate the expected
effectiveness of alternative potential (not yet existing) solutions, hence the approach (now
re-named “Systems Analysis”) was soon developed; it is also applied to the analysis of the
specifications of new systems. The Operations Research groups included, in addition to
mathematicians, physicists and engineers, a variety of representatives of other sciences; thus it
had the additional effect to demonstrate the effectiveness of the “mixed team approach”; as
Weaver (Weaver, 1948) notes “it was found that members of such diverse groups could work
together and could form a unit which was much greater than the mere sum of its parts.”
While Systems Engineering originated somewhat independently, the novel concepts of
systems science had likely some influence on its development and provided an underlying
foundation for its progressive conceptualization.
From the point of view of the technological context, the same years are characterized by
the development of a profusion of novel technologies, either totally new or in fast evolution
(e.g. radar, communications, automatic control, inertial navigation, computing, rocketry, etc.).
The potential new developments that could be made possible by applying and combining the
new technologies proved an enticement hard to resist both for users and technologist, although
it was easy to foresee that difficulties would likely be encountered.
The historical context was marked by the beginning of the cold war and of the related
arm race and space race. This involved the launch of unprecedented, large-scale and high
complexity projects, which combined challenging goals with time pressure. It must be noted
that the same context provided for a strong motivation, as the involved people felt to be
working for a worthy cause.
The quintessential projects marking the origins of Systems Engineering are the
Intercontinental Ballistic Missile (ICBM) and the Semi-Automatic Ground Environment
(SAGE) projects. The ICBM project faced the daunting task to integrate a variety of novel and
heterogeneous technologies (many still under development) to attain challenging performances
under severe constrains in terms of dimensions, weight and severity of the environment. This
not only frequently gave rise to unanticipated adverse consequences, but also required that
experts of diverse discipline worked effectively in large multidisciplinary teams. Progresses
were hampered not only by the substantial technical problems, but also by more mundane
aspects, like: poor communication, lack of planning and coordination, inconsistent
development of components and poor control of the configuration.
Tackling these problems spurred the creative development of management processes;
these represent the first instantiation of the systems engineering methodology (e.g. Systems
Management, Configuration Management, Extensive Testing, Data management and
communications). Further application of these methods for subsequent projects (culminating
with the Apollo program) led to their refinement and eventual formalization into the SE
process. The SAGE project, on its side, mainly anticipated two aspects that were posed to
become of major relevance for modern Systems Engineering: Software development and
Human System Integration.
The first required the development of procedures and approaches for the ordered
development of “computer programs”; the second required both the understanding of the
operational processes to be supported by the system, and the development of human-machine
interfaces enabling an effective integration of the operators with the system. These
methodologies eventually evolved in disciplines (Software Engineering and Human System
Integration) which, although separate, are closely related to Systems Engineering.
The effects of these cultural, technological and historical factors likely concurred in
determining the duality of Systems Engineering; that is, its combination of two complementary
aspects:
Systemic – refers to the holistic appreciation of the problem/system of interest,
considering its context, stakeholders, and the interrelationships and interconnections;
Systematic – refers to taking a structured, orderly approach to solve the problem and to
implement the system.
The Systemic Approach (also referred to as “Systems Approach” and “Systems
Thinking”) is mostly a way of thinking; its foundations can be clearly tracked to the
concepts and principles of the system science:
Wholeness (focus on the parts AND their interactions);
Emergence (characteristics deriving from the interactions between the parts);
Hierarchy (to contain and conceal complexity);
Behavior (focus on the relation between output and input, independent of the structure
and the internal organization – “Black Box” model);
Environment (the system affects and is affected by the environment);
Prediction of performances (through Modelling and Simulation).
This is confirmed by the definition from the SeBoK (SeBoK, 2014): “the systems approach to
engineered systems is a problem-solving paradigm. It is a comprehensive problem
identification and resolution approach based upon the principles, concepts, and tools of
systems thinking and systems science, along with the concepts inherent in engineering
problem-solving. It incorporates a holistic systems view that covers the larger context of the
system, including engineering and operational environments, stakeholders, and the entire life
cycle.”
On its part, the prescriptive methodology that forms the reference for the systematic
approach has its all too apparent roots in the processes and management solutions firstly
developed for the trailblazing projects. A sequence of standards, from the “375 Series” (Air
Force Systems Command) to the ISO/IEC 15288 (ISO/IEC 15288, 2008) documents its
evolution to the present days.
The process that is captured by the more recent standards is well proved and effective,
providing a valuable reference for the practitioner. What must be kept in mind is that a process
can record only the explicit knowledge; a primary role in the discovery and understanding of
needs, the articulation of functions and behaviors, and the devising of suitable architectures is
played by knowledge and skills (intuition, ingenuity, critical thinking) which is very hard to
codify. What can be done is trying to define some “principles” that can provide some guidance
(although not being prescriptive rules suitable for unthinking adherence).
One principle that can help in understanding how Systems Engineering can prove (and
indeed has proven) highly effective in dealing with complex multidisciplinary engineering
problems is the so called “left shift.” The term refers to a specific shape of the resource profile
of a project, which exhibits an earlier peak (positioned more on the left in a diagram with the
horizontal time axis directed to the right, hence the name). This early commitment of resources
can potentially prove beneficial in two main ways. On one side, it can help in anticipating the
discovery of errors and omissions before they manifest themselves in a later stage of
development; it is well known that the cost of fixing problems increases significantly along a
project lifecycle, thus an earlier fixing can reduce the cost of the project (and often saving time,
too). On the other side, a large part of the total cost of a project is committed in the early phases
of its lifecycle (about 70% in the concept phase) (Haskins, 2011); a “frontloading” of resources
in the early phases can enable to proactively build a suitable problem-specific knowledge basis,
and to perform analyses, both of which are needed to enable well-grounded design decisions. If
this is missing, knowledge will be acquired through a trial and error process, for sure not in a
timely way to avoid adverse consequences. It must be evidenced that, due to the probabilistic
nature of the pay-off (costs avoided), this approach must be seen as an investment (Emes,
Smith, James, Whyndham, Leal and Jackson, 2012).
An interesting, and inspiring, collection of “essential ingredients of Systems
Engineering” is presented by Boardman and Sauser (Boardman and Sauser, 2008); one could
even semi-seriously label them the “Seven Pillars” of Systems Engineering:
Life cycle – to carefully consider the entire life-cycle of the system, from conception to
retirement, primarily in the temporal dimension, but also accounting for the evolutions
in the contextual and stakeholder dimensions occurring as the life-cycle unfolds.
Gates - are intended to ensure a safe progression along the project lifecycle; they are
associated with reviews and baselines. Baselines must be defined so they can provide
rock-solid foundations for further work. Reviews offer the opportunity to share views
and to make sense of progress from all angles.
Requirements – are a way to connect and at the same time keep separate the problem
space and the solution space, translating needs into requirements while preserving a
design space as wide as possible. Requirements elicitation and derivation entails a
thorough exploration and understanding of both the problem and the solution spaces.
Perspectives – the diverse stakeholders (persons with a legitimate interest in the
system) must be discovered alongside the viewpoints that each of them has (at least one
each).
Trade-off – design is a matter of decisions (what to do, how to do, who does what); in
any decision, candidates must be identified, criteria formulated, performances
evaluated and a selection made. The duty is to facilitate rational thinking and to report
as rationally as possible when irrational decisions are made.
Modelling and Simulation - Models allow for prediction of effectiveness and
performances, performing experiments without the “real thing”. Since they are
abstraction of reality, they are “all wrong”, but useful if properly built for a specific
purpose.
Operational effectiveness - to provide a high-quality product that will serve the
interests of the customer in terms of both technical and business needs requires a
long-term vision for a project right at its beginnings. In addition to performance,
availability must be assured and complemented by process effectiveness (taking into
account that the system is embedded in a wider system); one last, but not less important,
element in defining Operational Effectiveness is Total Ownership Costs.
References
Royal Academy of Engineering. 1999. Principles of Engineering Design
Wynn D. and Clarkson J., 2005. Models of designing, in Design Process
Improvement: A review of current practice, J.Clarkson and C.Eckert
Bertalanffy, L. von, 1968. An outline of general systems theory, British Journal for
the Philosophy of Science 01/1950 and General System Theory: Foundations,
Development, Applications, Braziller
Wiener N., MIT Press, 1948. Cybernetics: Or Control and Communication in the
Animal and the Machine
Wiener N., 1950. The Human Use of Human Beings
Rosenblueth A., Wiener N. and Bigelow J., 1943. Behavior, Purpose and Teleology,
Philosophy of Science
PRADSEC, 1950. Progress Report of the Air Defense System Engineering Committee
Weaver W., 1948. Science and complexity, American Scientist
SeBoK, 2014. Retrieved on http://www.sebokwiki.org/wiki/Systems_Approach_
Applied_to_ Engineered_Systems
U.S. Air Force Systems Command, AFSCM 375-5 SYSTEM ENGINEERING
MANAGEMENT PROCEDURES, 196
ISO/IEC 15288-2008(E), 2008. Systems and software engineering - System life cycle
processes
Haskins C. ed. 2011, “INCOSE Systems Engineering Handbook v. 3.2.2
Emes, MR; Smith, A; James, AM; Whyndham, MW; Leal, R; Jackson, SC, 2012.
Principles of systems engineering management: Reflections from 45 years of
spacecraft technology research and development at the mullard space science
laboratory. Proc. of the 22nd Annual International Symposium of the
International Council on Systems Engineering (INCOSE)
Boardman J., Sauser B., 2008. Systems thinking : coping with 21st century problems,
Taylor & Francis
Biography
Vincenzo Arrichiello holds a Laurea Degree in Engineering from the University of
Genoa. He has practiced Systems Engineering for about 30 years, covering positions
either in large companies (Defense Contractors) and engineering consulting
Companies (as a co-owner), applying the systems approach across diverse industry
fields (Aerospace& Defense, Robotics, Packaging) He was one of the founders of the
Italia Chapter of INCOSE and is now serving as its President. From 2009 he is head of
the Selex Academy, and directs the relevant Systems Engineering School. He teaches
Systems Engineering courses in the Academy and in some University Masters.