AL5010- AIRCRAFT SYSTEMS ENGINEERING

UNIT I
INTRODUCTION TO SYSTEMS ENGINEERING

Overview of Systems Engineering- Systems Engineering Concept Map-Systems

Definition-The seven steps Systems Engineering-Conceptual System Design- System
Engineering Process- Requirements and Management-Trade Studies-Integrated
Product And Process Development.
AN INTRODUCTION TO SYSTEMS ENGINEERING
• Systems engineering is the job of integrating the whole, as distinct from the invention and design of its
parts; the creation and analysis of the overall answer to a problem; the breaking down of the total
into a set of harmonious, specified parts; the assurance of compatibility and consistency in the
ensemble; and the relating of that ensemble to the outside world that has originated the need and
that will employ the final result.

• These considerations are present in varying degrees in the production of every piece or group of
equipment, from a chair to a transcontinental railroad. Always some fraction of every engineering
effort has in effect been devoted to this systems engineering.

• The top systems engineer must be a good manager. Furthermore, he must be a good scientist and
engineer with considerable breadth. In each project a large number of specialized fields of
engineering and science are involved.
• The systems engineering task usually involves integration of several fields aerodynamics,
electronics, chemistry, metallurgy, astronomy, and hydraulics; a systems engineering
team must include experts in the scientific fundamentals of these specialized fields.

• The top engineer of each specialty or component field making up the system must be
basically a good systems engineer, even though his major detailed knowledge may be in
the field of his specialty. Below him are the specialists, experts in the different fields that
are a part of the total system.

• The relationship among these experts cannot be smooth and cannot be kept in proper
balance for the good of the system as a whole unless there is at least one expert in each
of the component areas who is basically a systems man.
What Is a System?

• A system is a purposeful aggregation of subsystems which are functionally and sometimes physically interdependent.

• The operation of any subsystem is affected by one, several, or all the other subsystems. For example, an industrial refinery, an automobile
manufacturing plant, a transcontinental railroad, and many other complex industrial activities can be categorized as systems and lend
themselves, especially in their development period.

• A “system” is the combination of elements that function together to produce the capability required to meet a need.

• The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose; that is, all
things required to produce system-level results.

• The results include system-level qualities, properties, characteristics, functions, behavior, and performance. The value added by the system as a
whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are
interconnected.

• It is a way of looking at the “big picture” when making technical decisions. It is a way of achieving stakeholder functional, physical, and
operational performance requirements in the intended use environment over the planned life of the system within cost, schedule, and other
constraints. It is a methodology that supports the containment of the life cycle cost of a system. In other words, systems engineering is a logical
way of thinking.
• Systems engineering is the art and science of developing an operable system capable of meeting requirements
within often opposed constraints.

• Systems engineering is a holistic, integrative discipline, wherein the contributions of structural engineers,
electrical engineers, mechanism designers, power engineers, human factors engineers, and many more disciplines
are evaluated and balanced, one against another, to produce a coherent whole that is not dominated by the
perspective of a single discipline.

• Systems engineering seeks a safe and balanced design in the face of opposing interests and multiple, sometimes
conflicting constraints. The systems engineer should develop the skill for identifying and focusing efforts on
assessments to optimize the overall design and not favor one system/subsystem at the expense of another while
constantly validating that the goals of the operational system will be met. The art is in knowing when and where
to probe. Personnel with these skills are usually tagged as “systems engineers.”

• The exact role and responsibility of the systems engineer may change from project to project depending on the
size and complexity of the project and from phase to phase of the life cycle.
• For large projects, there may be one or more systems engineers. For small
projects, the project manager may sometimes perform these practices. But
whoever assumes those responsibilities, the systems engineering functions
should be performed.
• The actual assignment of the roles and responsibilities of the named systems
engineer may also therefore vary. The lead systems engineer ensures that the
system technically fulfills the defined needs and requirements and that a proper
systems engineering approach is being followed.
• The systems engineer oversees the project’s systems engineering activities as
performed by the technical team and directs, communicates, monitors, and
coordinates tasks.
• The systems engineer reviews and evaluates the technical aspects of the project
to ensure that the systems/subsystems engineering processes are functioning
properly and evolves the system from concept to product. The entire technical
team is involved in the systems engineering process.
• The systems engineer usually plays the key role in leading the development of the concept of operations (ConOps) and resulting system
architecture, defining boundaries, defining and allocating requirements, evaluating design tradeoffs, balancing technical risk between systems,
defining and assessing interfaces, and providing oversight of verification and validation activities, as well as many other tasks.

• The systems engineer typically leads the technical planning effort and has the prime responsibility in documenting many of the technical plans,
requirements and specification documents, verification and validation documents, certification packages, and other technical documentation.

• Systems engineering plays a key role in the project organization. Managing a project consists of three main objectives: managing the technical
aspects of the project, managing the project team, and managing the cost and schedule.

• These three functions are interrelated. Systems engineering is focused on the technical characteristics of decisions including technical, cost,
and schedule and on providing these to the project manager.

• The Project Planning and Control (PP&C) function is responsible for identifying and controlling the cost and schedules of the project.

• The project manager has overall responsibility for managing the project team and ensuring that the project delivers a technically correct
system within cost and schedule.

• Note that there are areas where the two cornerstones of project management, SE and PP&C, overlap. In these areas, SE provides the technical
aspects or inputs whereas PP&C provides the programmatic, cost, and schedule inputs.
• There are three sets of common technical processes in Systems Engineering Processes and Requirements: system design,
product realization, and technical management.
• The processes of the SE engine are used to develop and realize the end products.
System Design Processes:
• The four system design processes are used to define and baseline stakeholder expectations, generate and baseline technical
requirements, decompose the requirements into logical and behavioral models, and convert the technical requirements into a
design solution that will satisfy the baselined stakeholder expectations.
• These processes are applied to each product of the system structure from the top of the structure to the bottom until the lowest
products in any system structure branch are defined to the point where they can be built, bought, or reused. All other products in
the system structure are realized by implementation or integration.
Product Realization Processes:
• The product realization processes are applied to each operational/ mission product in the system structure starting from the
lowest level product and working up to higher level integrated products.
• These processes are used to create the design solution for each product (through buying, coding, building, or reusing) and to
verify, validate, and transition up to the next hierarchical level those products that satisfy their design solutions and meet
stakeholder expectations as a function of the applicable life cycle phase.
Technical Management Processes:
• The technical management processes are used to establish and evolve technical plans for the project, to manage communication
across interfaces, to assess progress against the plans and requirements for the system products or services, to control technical
execution of the project through to completion, and to aid in the decision-making process.
 The Systems Engineering Process
• The major steps in the completion of a typical systems engineering project are the following:
(1) problem statement;
(2) identification of objectives;
(3) generation of alternatives;
(4) analysis of these alternatives;
(5) selection of one of them;
(6) creation of the system, including decomposition, design, development, integration, verification and validation,
(7) system operation and life cycle disposal.
• Some examples of Systems Engineering Process activities are:
• Defining needs, operational concept, and requirements
• Functional analysis, decomposition, and allocation
• System modeling, systems analysis, and tradeoff studies
• Requirements allocation, traceability, and control
• Prototyping, Integration, and Verification
• System Engineering Product and Process control
• Configuration and Data Management
• Risk Management approaches
11
• Engineering technical reviews and their purposes
Systems Engineering Methodologies

12
Systems Engineering Methodologies

13
Quality Function Deployment
Who Sets the SE Standards?
• Depends on your
customer (MIL-STD,
IEEE STD, Ad Hoc)
• Individual private
programs can be
managed in an ad-
hoc manner
• Government or
large corporate
contracts may
require Mil spec or
other spec to
ensure process
compliance
• INCOSE

15
The Three Types of Systems Engineering
1. Pure systems engineering: cognitive skills, namely thinking, e.g. systems thinking, critical thinking, problem
formulation/solving, and decision making.
2. Applied systems engineering: activities traditionally associated with systems engineering.
3. Domain systems engineering: pertains to fields such as computers, aerospace, transportation and defence in which systems
engineering is performed.
Applied Systems Engineering
• Applied systems engineering are the activities traditionally associated with
systems engineering including:
• Definition of needs/goals/objectives. • Operational scenario analyses. • System requirements analysis.
• System requirements allocation. • Functional analysis. • Functional allocation.
• Specification development. • System and subsystem design. • Trade-off/alternatives evaluation.
• Development of benchmark tests. • Software requirements analysis. • Hardware analysis and recommendations.
• Interface definition and control. • Schedule development. • Lifecycle costing.
• Technical performance measurement (TPM). • Planning. • Organizing.
• Directing junior level personnel. • Program and decision analysis. • Risk analysis.
• Integrated logistics support (ILS). • Transition planning. • Reliability maintainability & availability (RMA).
• System integration. • T&E(Test & Evaluation). • Configuration management.
• Quality assurance. • Training. • Technical writing.
• Installation. • Operations support. • System evaluation and modification.
The Five Types of System Engineers
• Based on the way they approach problems system engineers can be classified into five different types :
• Type I—apprentices: have to be told what to do and how to do it.
• Type II—doers: once told what to do, namely provided with the SEMP(Systems Engg Mgmt Plan) or project plan, Type IIs have
the ability to follow the process (the how to do it).
• Type III—problem solvers: once given a statement of the problem, Type IIIs have the expertise to conceptualize the solution and
to determine how to do it (create the SEMP for realizing the solution).
• Type IV—problem formulators: have the ability to examine the situation and determine what needs to be done about it (define the
problem), but cannot conceptualize how to do it (a solution).
• Type V—masters: combine the abilities of Types III and IV, namely have the ability to examine the situation, define the problem,
conceptualize the solution system and plan and manage the process.
The Three Different Domains of Systems Engineering
• Domain systems engineering can be partitioned into the following three domains:
1. Problem domain.
2. Solution domain.
3. Implementation domain.
• It is tempting to assume that the problem domain and the solution domain are the same, but they are not necessarily so. For example:
• The problem domain may be urban traffic congestion.
• The solution domain may be an underground transport system to relieve that congestion.
• The implementation domain includes tunnelling, temporarily diverting surface traffic, etc.
• Lack of problem domain competency may lead to the identification of the wrong problem, and lack of solution domain competency
may lead to selection of a less than optimal or even an unachievable solution system. For example, risk management is an activity
(process) that requires competency in the problem, solution and implementation domains.
• The implementation domain sets the constraints on both the process and solution system. For example, the development system for a
software system is in the implementation domain.
• Implementation domain knowledge relates to the properties of the compiler as well as the characteristics (especially limitations) of
the development hardware.
• In another environment, the implementation domain might include thermal vacuum chambers and other equipment used to partially
or fully develop and test the solution system.
• Although domain knowledge is critical to understanding the domains and the correctness of decisions, the problem of providing
domain knowledge is the province of education and training in the domain, not that of education and training in systems engineering.
• The ‘A’ and the ‘B’ Paradigms in Systems Engineering

CONOPS-Concept of Operations
The Eight Different Camps of Systems Engineering

• Lifecycle: this camp is one of the earliest camps, articulated as, ‘Despite the difficulties of finding a universally accepted
definition of systems engineering, it is fair to say that the systems engineer is the man† who is generally responsible for
the over-all planning, design, testing, and production of today’s automatic and semi-automatic systems’*

• Process: this camp of system engineers, particularly in the INCOSE and the United States (US) Department of Defense
(DoD), are process-focused (Lake 1994; Eisner 1988) seemingly in accordance with US DoD 5000 Guidebook 4.1.1,
which states, ‘The successful implementation of proven, disciplined system engineering processes results in a total
system solution that is—robust to changing technical, production, and operating environments; adaptive to the needs of
the user; and balanced among the multiple requirements, design considerations, design constraints, and program
budgets’. The focus is on conforming to the process and not on providing an understanding of the undesirable situation.
These campers are often graduates from ‘B’ paradigm systems engineering courses which focus on the process.

• Problem-solving: this camp of system engineers are often old-timers who worked as system engineers before and during
the Apollo program.
• Discipline and meta-discipline: Wymore defined systems engineering as a discipline (Wymore
1994) and systems engineering meets Kline’s requirements for a discipline. However, all the
elements of the current mainstream SETR approach to systems engineering overlap those of
project management and other disciplines which make it difficult to identify systems
engineering as a distinct discipline. The discipline camp tends to account for the overlap by
viewing systems engineering as a meta-discipline incorporating the other disciplines and hold
that systems engineering needs to widen its span to take over the other disciplines

• Systems thinking: this camp of system engineers tend to be system engineers who can view an
issue from more than one perspective.

• Non-systems thinking: this camp of system engineers tend to have a single viewpoint of
systems engineering and generally exhibit the ‘biased jumper’ level of critical thinking
• Domain: this camp of system engineers tags the role of systems engineers to the system being
system engineered. Thus, an engineer working on a Widget System is a widget system engineer.
Examples are network system engineers/engineering, control system engineers/engineering,
communications system engineers/engineering, hydraulic system engineers/engineering,
transportation system engineers/systems engineering, etc. However, the name of the Widget
System is dropped from the role.*

• Enabler: this camp of system engineers evolved from the problems-solving camp. In the
enabler camp, systems engineering is the application of systems thinking and beyond to
problem-solving. Moreover, it can be, and is, used in all disciplines for tackling certain types of
complex and non-complex problems;
The Five Layers of Systems Engineering
• According to the principle of hierarchies, there are differences between systems engineering as performed on products, systems
and large-scale systems.
• Layer 5: socioeconomic, the stuff of regulation and government control.
• Layer 4: industrial systems engineering or engineering of complete supply chains/circles. Many industries make a socio-
economic system. A global wealth creation philosophy. Japan seems to operate most effectively in this layer.
• Layer 3: business systems engineering—many businesses make an industry. In this layer, systems engineering seeks to optimize
performance somewhat independent of other businesses
• Layer 2: project or system layer. Many projects make a business. Western engineer-managers operate at this layer, principally
making complex artefacts.
• Layer 1: product layer. Many products (subsystems) make a system. The tangible artefact layer. Many [systems] engineers and
their institutions consider this to be the only ‘real’ systems engineering.
The Goals of Systems Engineering
• The goal of the system engineering effort is to provide a system that:
• Meets the customer’s requirements as stated when the project starts.
• Meets the customer’s requirements as they exist when the project is delivered.
• Is flexible enough to allow cost effective modifications as the customer’s requirements continue to evolve during the operations
and maintenance state of the SLC(Systems Life Cycle).
Problem Solving and Systems Engineering
• Systems engineering begins with a problematic or undesirable situation because ‘problems do not present themselves as givens;
they must be constructed by someone from problematic situations which are puzzling, troubling and uncertain’ (Schön 1991).
• Perceived from the Big Picture HTP(holistic thinking perspectives), the context for systems engineering (the sequence of activities)
begins with the existence of a problematic or undesirable situation and ends with a solution system which remedies the
undesirable situation.
• Figure 2.6 can be expanded into Figure 2.7 (Kasser 2013, p. 261) which converts the undesirable situation into a solution
system operating in the context of a FCFDS(Feasible Conceptual Future Desired Situation ). From this perspective, the observer becomes
aware of an undesirable situation that is made up of a number of related factors.
• A project is authorized to do something about the undesirable situation. The problem-solver tries to understand the situation,
determine what makes the situation undesirable and then create a vision of a FCFDS.
• The problem then becomes one of how to move from the undesirable situation to the FCFDS.
• Once the problem is identified, the remedial action is taken to create and transition to the solution system which will operate in
the context of the FCFDS. The so-called systems engineering process is a version of the problem-solving process.
From an Undesirable Situation to a Solution System

A Holistic Approach to Managing Problems and

Solutions
• The confusion between the ‘systems engineering process’ and the problem-solving process can be resolved by recognizing that
when the problem is:
• Small or non-complex, the sequence of activities in the remedial action is known as the ‘problem solving process’.
• Large or complex, the sequence of activities in the remedial action is known as the ‘systems engineering process’ instead of the
SDP(Systems Development Process). This is in accordance with Jenkins’s definition of systems engineering as, ‘the science of designing
complex systems in their totality to ensure that the component subsystems making up the system are designed, fitted together,
checked and operated in the most efficient way’ (Jenkins 1969).

The SDP and the Problem-Solving Process

The Interdependency and Overlap Between the Systems
Engineering, Project Management and Other Engineering
Activities
• The relationships between the interdependent SETA(Systems
Engineering and Technical Assistance), project management and
engineering activities performed to realize a solution system are
shown in Figure (Kasser and Hitchins 2013).
• The top part of the figure is the problem solving process causal
loop providing the context to the SDP.
• The first iteration of the loop begins when someone with the
appropriate authority associated with the undesirable situation
kicks off the SDP which consists of a set of three streams of
activities performed in series and in parallel (a process) which
produces a solution system designed to remedy the undesirable
situation.
• The interdependent activities in the SDP can be separated where:
• Domain knowledge is the underpinning information used by holistic
thinking in the performance of the activities performed in the SDP. The Relationships between the Activities in the SDP
• Holistic thinking or pure systems engineering is the use of systems in the SETA Paradigm
thinking and beyond conceptual tools that use the knowledge in all
three domains to identify and remedy problems in undesirable
situations (Kasser 2015a).
• Risk management is the set of activities that anticipate, prevent and
mitigate risks in the problem, solution and implementation domains.
• Project management is the set of activities known as planning,
organizing, directing and controlling shown in Fig. (Kasser and
Hitchins 2013). Project management incorporates risk
management to manage process risks.
• Systems engineering (SETA) is the set of activities known as
designing, integrating and testing the overall system/interacting
subsystems shown in 11 (Kasser and Hitchins 2013).
• Engineering is the set of non-SETA engineering activities that
create subsystems.
Project Management in the SDP

Engineering and Systems Engineering in the SDP

• Project management, systems engineering and engineering all perform risk management, as shown in Figure (Kasser and
Hitchins 2013). The complex concept map shown in Figure shows a non-overlapping relationship between SETA, project
management and engineering.
• In Figure engineering activities may ‘provide’ by creating, by building, by purchasing commercial-off-the shelf (COTS)
products, by changing a process, by reorganizing human activities or by a combination of all or some of the above.

The Non-Overlapping Activity Paradigm (SETA)

FUNCTIONAL
• Perceptions of systems engineering from the Functional HTP included system engineers performing pure engineering functions in the
operational scenarios, such as:
• Problem-solving.
• Systems thinking.
• Analysis.
• Synthesis.
• Decision-making.
• Communicating.
OPERATIONAL
• Perceptions of systems engineering from the Operational HTP included:
• System engineers performing applied systems engineering, namely SETA in the SDP to:
1. Provide value (Weiss 2013) in various scenarios in projects in different domains.
2. Transform an undesirable situation into a situation without the undesirable characteristics, called the desirable situation, using resources
and constrained by rules and regulations.
3. Produce documents.
• System engineers do not produce systems, they transform an operational need into a description of system performance parameters and
a system configuration, assist in the subsystem construction and subsystem tests, perform system integration and system test, but other
personnel actually construct the systems.*
• System engineers continuing their education and sharing their knowledge by reading and contributing to technical journals and
participating and contributing to annual practitioner-oriented conferences.
STRUCTURAL
• Perceptions of systems engineering from the Structural HTP included:
• The standards for systems engineering
• The principle of hierarchies
• A systems engineering competency model
• Internal and external subsystem boundaries.
• Physical and virtual components.
• Effects on the system due to its internal structure.
• The interconnections between physical elements and subsystems.
• The structure of the information in the system.
The Standards for Systems Engineering
• The Standards commonly used in systems engineering cover systems engineering management and the processes for
engineering a system. However, they do not seem to actually apply to systems engineering since:
• Mil-STD-499 covers systems engineering management (MIL-STD-499 1969).
• Mil-STD-499A covers engineering management (MIL-STD-499A 1974), dropping the word ‘systems’ from the title.
• The draft (MIL-STD-499B 1993) and MIL-STD-499C (Pennell and Knight 2005) Standards contain the words ‘systems
engineering’ in their titles but the Standards were never formally approved.
• American National Standards Institute (ANSI)/Electronic Industries Alliance (EIA)-632 covers processes for engineering a
system (ANSI/EIA-632 1999).
• The IEEE 1220 Standard is for the application and management of the systems engineering process (IEEE Std 1220 1998) an
instance of the generic problem-solving process.
• The International Standards Organisation (ISO)/International Electrotechnical Commission (IEC) 15288 Standard (Arnold
2002) lists processes performed by system engineers (Arnold 2002, p. 61). In addition, many of the activities in ISO/IEC 15288
also overlap those of project management.
• While the Standards cited are out of date, they are still readily available on the Internet for free and their replacements (if any)
follow the theme of the original Standard and contain much useful information.
GENERIC
• Perceptions of systems engineering from the Generic HTP included:
• A system is an instance of a class of systems which leads to the realization that a system inherits desired and undesired
functions and properties from the generic class of system.
• The similarities between:
• The system and other systems in the same or other domains.
• Systems engineering and mathematics; two disciplines providing tools used to solve problems in other disciplines.
• Pure and applied systems engineering and pure and applied mathematics.
• Systems engineering is demonstrating the symptoms of a discipline in its early stages. For example, at present systems
engineering has no broadly accepted framework equivalent to:
• Ohm’s law: published in 1827, showed the relationship between voltage and current in electrical engineering which allowed
electrical engineers to predict the behaviour of circuits.
• Maxwell’s equations: published in 1873, allowed electrical engineers to predict the performance of motors.
• The periodic table of elements in chemistry: framed by Mendeleev in 1869, which arranged the elements in order of increasing
atomic weight. By using the table, Mendeleev was able to predict the properties of elements yet to be discovered.
• The focus on process is not unique to systems engineering For example, Drucker wrote, ‘Throughout management science—in
the literature as well as in the work in progress—the emphasis is on techniques rather than principles, on mechanics rather than
decisions, on tools rather than on results, and, above all, on efficiency of the part rather than on performance of the whole’
QUANTITATIVE
• Perceptions of systems engineering from the Quantitative HTP included:
• The five types of system engineers
• The return on investment (ROI) in systems engineering
• The three types of emergent properties
• A way of assessing technology readiness
• The lack of a metric for the goodness of a requirement
The Return on Investment in Systems Engineering
• Honour performed research into the value of systems engineering (SETA). Findings included (Honour 2013):
• Statistically significant relationships between the amount of systems engineering activities and three success measures:*
1. Cost compliance.
2. Schedule compliance.
3. Stakeholder overall success.
• Optimum systems engineering effort for median programs is 14.4% of total program cost.
• The ROI in system engineering is as high as 7:1 for programs with little systems engineering effort and 3.5:1 for median programs.
• If a project is spending nothing, then each $1 re-purposed into systems engineering can reduce a potential overrun by $7. If project spending
conforms to the average program (about 7.5%), then each $1 re-purposed into systems engineering can reduce the project’s potential overrun.
• If the project is already at the optimum of 14.4%, then each $1 re-purposed into systems engineering gets the project no gain at all, it just
increases costs (Honour 2015).
• Systems engineering activities correlate strongly to program success measures, but do not correlate strongly to the technical quality of the
resulting system.
• Honour’s research considered systems engineering to be the total effort expended across eight system-level technical activities
based in descriptions in the systems engineering standards to define and develop a new system.
• The eight system-level technical activities (SETA) are:
1. Mission/purpose definition.
2. Requirements engineering.
3. System architecting.
4. System integration.
5. Verification and validation.
6. Technical analysis.
7. Scope management.
8. Technical leadership/management.
TEMPORAL
• Perceptions of systems engineering from the Temporal HTP included:
• The successes and failures
• The evolution of systems engineering
• The evolution of the role of the systems engineer
The Successes and Failures of Systems Engineering
• Systems engineering successes include:
• The transcontinental (US) television microwave relay system (Hall 1962).
• Landing men on the moon and returning them safely to earth in the 1960s and 1970s.
• The Semiautomatic Ground Environment (SAGE) project, a computer and radar-based air defence systems created in the US in
the 1950s (Hughes 1998, p. 15). SAGE was a massive networked system of radars, anti-aircraft guns and computers.
• The Atlas Inter-Continental Ballistic Missile (ICBM) development of the 1950s, where ‘systems engineering was the
methodology used to manage the problem of scheduling and coordinating hundreds of contractors developing hundreds—even
thousands—of subsystems that eventually would be meshed into a total system’ (Hughes 1998, p. 118).
• The Public Housing System, industrial development and the Air Defence System (ADS) in Singapore (Lui 2007).
• Systems engineering failures include:
• Failed projects particularly in the NASA post-Apollo era and the US DoD, where inadequate systems engineering was
repeatedly cited as a major contributor to the failure (e.g. Evans 1989; Leveson 2004; Welby 2010; Wynne and Schaeffer 2005).
• Failure of systems engineering in the early stages of large projects (Hiremath 2008) and other examples of poor systems
engineering implementation (GAO 2006).
The Evolution of Systems Engineering
• The term ‘systems engineering’ has only been in existence since the middle of the 20th century.
• Research showed that the system engineers of the 1950s and 1960s:Tended to focus on identifying the problem (Wymore 1993)
and finding an optimal solution (Hall 1962; Goode and Machol 1959).
• Was a discipline dealing with complexity over the whole SLC (Jenkins 1969; Chapanis 1960).
• These system engineers were of Type III, Type IV, and Type V, while the system engineers who came later tended to focus on
processes (Type IIs). Back in the ‘good old days’ of systems engineering Type III, Type IV and Type V system engineers
solved/resolved/dissolved the problem in the first problem-solving process addressing the conceptual solution in the needs
identification state of the SDP, then initiated the implementation of the solution, and moved on to the next contract (project),
leaving the Type IIs to continue assisting the development of the solution system in the second problem-solving process.
• There then came a time when there was a lack of new projects and so many of the Type III, Type IV and Type Vs were laid off
and lost to the discipline.
• When the need for system engineers in the US picked up again, in general, only the Type II system engineers were left and they
took over systems engineering. They had missed the activities of the first problem-solving process in the needs identification
state and so their focus was on the SETA in the second problem-solving process; the remaining states in the SDP. They wrote
the Standards used in systems engineering documenting what they were doing in different states of the SDP for other Type II
system engineers to follow.
• IEEE 1220 stated that ‘the systems engineering process is a generic problem-solving process’ .
• IEEE 1220’s replacement of the term ‘the problem-solving process’ by the term ‘the systems engineering process’ seems to
have led to today’s focus on process; specifically, the second problem-solving process because these Standards in turn became
the foundation for educating system engineers.
T he Evolution of the Role of the Systems Engineer

• The earliest descriptions of the role were articulated as:

• Problem definition is isolating, possibly quantifying, and relating that set of factors which will define the system
and its environment. Since a problem is an outward expression of an unsatisfied need, the job is to find what the
need really is. This means gathering and analyzing data to describe the operational situation, customer
requirements, economic considerations, policy, possible system inputs and outputs, etc.(HALL)

• Formulating the problem is the determination of requirements, establishing the objectives, goals, and restraints, and
determining the weighting functions to place the proper emphasis on the various system requirements.(Chestnut
1965)

• The role has since evolved to match the devolution of systems engineering.
For example, in 1969 Jenkins listed the following 12 roles of the systems engineer (Jenkins 1969, p.
164):
1. He tries to distinguish the wood from the trees—what’s it all about?
2. He stimulates discussion about objectives—obtains agreement about objectives.
3. He communicates the finally agreed objectives to all concerned so that their co-operation can be
relied upon.
4. He always takes an overall view of the project and sees that techniques are used sensibly.
5. By his overall approach, he ties together the various specializations needed for model building.
6. He decides carefully when an activity stops.
7. He asks for more work to be done in areas which are sensitive to cost.
8. He challenges the assumptions on which the optimization is based.
9. He sees that the project is planned to a schedule, that priorities are decided, tasks allocated, and
above all that the project is finished on time.
10. He takes great pains to explain carefully what the systems project has achieved, and presents a
well-argued and well-documented case for implementation.
11. He ensures that the users of the operational system are properly briefed and well trained.
12. He makes a thorough retrospective analysis of systems performance.
• Seven of these roles of the systems engineer (activities performed by a person with the title systems engineer) overlap the role
of the project manager (activities performed by a person with the title project manager). Almost 20 years later, Sheard
documented the following different 12 systems engineering roles (Sheard 1996):
1. Requirements owner role: requirements owner/requirements manager, allocator, and maintainer/specifications writer or
owner/developer of functional architecture/developer of system and subsystem requirements from customer needs.
2. System designer role: system designer/owner of ‘system’ product/chief engineer/system architect/developer of design
architecture/specialty engineer (some, such as human-computer interface designers), ‘keepers of the holy vision’ (Boehm 1994).
3. System analyst role: system analyst/performance modeller/keeper of technical budgets/system modeller and simulator/risk
modeller/specialty engineer (some, such as electromagnetic compatibility analysts).
4. Validation and verification role: validation and verification engineer/test planner/owner of system test program/system selloff
engineer. Validation and verification engineers plan and implement the system.
5. Logistics and operations role: logistics, operations, maintenance, and disposal engineer/developer of users’ manuals and
operator training materials.
6. Glue role: owner of ‘glue’ among subsystems/system integrator/ owner of internal interfaces/seeker of issues that fall ‘in the
cracks’/risk identifier/’technical conscience of the program’.
7. Customer interface role: customer interface/customer advocate/customer surrogate/customer contact.
8. Technical manager role: technical manager/planner, scheduler, and tracker of technical tasks/owner of risk management
plan/product manager/product engineer.
9. Information manager role: information manager (including configuration management, data management, and metrics).
10. Process engineer role: process engineer/business process re-engineer/business analyst/owner of the systems engineering
process.
11. Coordinator role: coordinator of the disciplines/tiger team* head/head of IPTs/system issue resolver.
12. ‘Classified ads systems engineering’ role: this role was added to the first 11 by Sheard in response to frustration encountered when
scanning the classified ads, looking for the INCOSE-type of systems engineering jobs.
• Some of the evolution in systems engineering can be seen in the very little overlap between the 12 roles documented by Jenkins and the
12 roles documented by Sheard.
• Jenkins’s roles relate to conceiving and planning the solution system in the ‘A’ paradigm while almost 30 years later, few of Sheard’s
roles address the original systems engineering approach to conceiving and planning the solution system.
• Sheard’s set of roles focuses on the ‘B’ paradigm and relates to interpersonal relationships between the practitioners of disparate skills
and disciplines implementing the solution system.
• Furthermore, according to both Jenkins and Sheard the role of system engineers (SETR) overlap activities performed (the roles) by
people from other professions.
SCIENTIFIC
• Inferences of systems engineering from the Scientific HTP included:
1. Frameworks for systems engineering
2. The framework of hierarchies.
3. The HKMF(Hitchins-Kasser-Massie Framework ).
4. The overlapping streams of work.
5. What the Standards seem to have accomplished.
6. Systems engineering is a discipline.
7. The answers to the questions.
8. Seven principles for systems engineered solution systems
Frameworks for Systems Engineering
• A number of frameworks were developed and used in the research into the nature of systems engineering from 1996 to 2019.
Each of these frameworks has been previously published in peer-reviewed journals or conferences. The conclusions from the
research are that the frameworks:
1. Have provided insight into the nature of systems engineering.
2. Have been shown to be useful in the application of systems engineering.
3. Are interdependent.
4. The combination of the frameworks provides a way to state the value of systems engineering as, ‘being a part of the application
of a systemic and systematic holistic approach to remedying complex problems’.
The Hitchins-Kasser-Massie Framework (HKMF )
• The Hitchins-Kasser-Massie Framework (HKMF) shown in Figure was developed when trying to determine the requirements
for what should be taught in postgraduate systems engineering coursework at UniSA (Kasser and Massie 2001).
• The research attempted to develop a body of knowledge of systems engineering based on the SETR paradigm in the different
states of the SLC and in the different Hitchins’ layers.
• In its early days, the framework has:
• Provided one of the reasons why system engineers can’t agree on the nature of systems engineering
• Identified the ‘A’ and ‘B’ paradigms in systems engineering
• Identified that system engineers operating in one layer use a different vocabulary to those operating in another layer. For
example, the term ‘capability’ has different meanings in Layers 1 and 3.
• The more than 40 different definitions of the term ‘systems engineering’ (Kasser 2015b, p. 65) are based on different internal
perspectives of problems from the different areas of the HKMF.
• Identified that SETA is different in the different areas of the HKMF.
• Facilitated traceability of requirements; requirements on a system in Layer 2 can be traced back to the undesirable socio-
economic situation in Layer 5.
• Shown that systems engineering, at least the INCOSE and DoD versions, resides in Layer 2 while operations research resides in
Layer 3, mainly in area 3G.
• Shown that SETA when performed in Layer 5 is known as political science.
• The two dimensions of the framework plot the system or product layer of complexity and process (lifecycle) state on different
axes where:
1. The vertical or product axis: the five layers of systems engineering (Hitchins 2000: Section 2.1.8).
2. The horizontal or timeline axis: the nine states of the SLC.
• The out-of-the-box idea for the HKMF came from the Generic HTP. Mendeleev created a framework, the periodic table of
elements, and populated it with the known elements, leaving gaps which represented unknown elements.
• In a similar manner, the HKMF forms a framework for studying activities in the workplace* in the different layers and states of
a SLC.
The System and Subsystem Design State
• The system and subsystem design state:
• Begins at the close of the SRR(Systems Requirements Review) and ends at the close of the CDR(Critical Design
Review).
• Is the state in which the system and subsystem designs are created.
• Converts the conceptual system documented in the matched set of specifications into a realizable design which remedies
the undesirable situation as it exists at the end of the state (and is robust enough to cope with all foreseen high probability future
changes).
• Is split into two parts:
1. The preliminary system design sub-state (SRR to PDR).
2. The detailed system design sub-state (PDR-CDR).

• The systems engineer also provides the project manager with updates to the CRIP(Categorized Requirements in Process ) charts.

THE PRELIMINARY SYSTEM DESIGN SUB-STATE (SRR-PDR)

• The preliminary system design sub-state:
• Begins at the close of the SRR and ends at the close of the PDR(Preliminary Design Review).
• Is the sub-state in which several conceptual designs are created but only one is selected in accordance with the problem-
solving process.
The Problem Posed by the Preliminary System Design Sub-State
• The problem posed by the preliminary system design sub-state (SRR to PDR) can be framed in the problem formulation
template as follows:
1. The undesirable situation: at the end of the SRR is the lack of preliminary designs for the solution system that meets the
matched set of specifications accepted at SRR.
2. The assumptions:
a. Consensus that the matched set of requirements specified a system that when operating in its context will remedy the
undesirable situation as it exists at the SRR. Note the undesirable situation may have evolved since the SDP began.
b. Authorization to proceed with the SDP(System Development Process) has been received.
c. The FCFDS(Feasible Conceptual Future Desirable Situation): is consensus that that a feasible preliminary design for the
solution system:
• Meets the matched set of specifications accepted at SRR.
• Remedies the original and evolved undesirable situation.
d. The problem: is to create the FCFDS by:
• Converting the matched set of specifications to a preliminary design.
• Gaining the consensus that that the preliminary design represents a system that will meet the need of remedying the evolved
undesirable situation at the time of the PDR.
e. The solution: the creation, presentation and acceptance of the preliminary design at the PDR by following an appropriately
customized version of the problem-solving process.
THE DETAILED SYSTEM DESIGN SUB-STATE (PDR-CDR)
• The detailed system design sub-state:
• Begins immediately after authorization to proceed has been received at the end
of the PDR and ends at the CDR.
• Follows the problem-solving process to convert the preliminary design into the
final design that will be created during the remainder of the SDP.
The Problem Posed by the Detailed System Design Sub-State
• The problem posed by the detailed system design sub-state (PDR to CDR) can be framed as the problem formulation
template follows:
1. The undesirable situation: at the end of the PDR is the lack of a final design for the solution system that meets the
matched set of specifications accepted at SRR.
2. The assumptions:
a. Consensus that that the preliminary design represents a system that will meet the need of remedying the evolved
undesirable situation at the time of the PDR.
b. Authorization to proceed with to the CDR has been received.
3. The FCFDS: is consensus that that a final design for the solution system:
• Meets the matched set of specifications accepted at SRR and updated during the state.
• Remedies the original and evolved undesirable situation.
• Is feasible.
4. The problem: is to create the FCFDS by:
• Converting the preliminary design to the feasible documented critical or final design.
• Gaining the consensus that the design represents a system that will meet the need of remedying the evolved
undesirable situation at the time of the CDR.
5. The solution: the creation, presentation and acceptance of the final design at the CDR by following the appropriate
customized version of the problem-solving process.
THE THREE VERSIONS OF THE SYSTEM DESIGN

• There are three versions of the system design as follows:

1. The conceptual design: the earliest version created in the needs identification state. It is generally a
view of the system from the Operational and Functional HTPs, namely a concept describing the
functions the system will perform in its operational context.

2. The preliminary design: introduces the Structural HTP(Holistic Thinking Perspective). The
preliminary design tends to be a hybrid conceptual design with some physical parts depending on the
nature of the system. The system level functions are allocated to system level components and the
interfaces between the components are developed. The feasibility of the design within the constraints
placed on the development project is verified. The preliminary design is generally presented at the PDR.

3. The final design: is the preliminary design converted into something that can actually be constructed.
The final design is generally presented at the CDR.
DESIGNING FOR INTEGRATION
• The subsystems must be designed for integration. For example, a subsystem
generally has connectors carrying signals and power. The connectors must be
positioned on the subsystem to facilitate access once the subsystem is installed in
the system.
• This might mean:
• Placing all the connectors on the same side of the unit.
• Placing connectors to minimize cable lengths of high-frequency signals.
• Not placing heat producing subsystems near another subsystem that needs to
remain cool.
• Placing subsystems so that cooling air flow is not blocked by some other
system opponent.
• Using compatible connectors at both ends of the cable to facilitate testing the
cables and minimizing the number of different parts in the system.
DESIGNING SELF-REGULATING SUBSYSTEMS
• Subsystems should be designed to perform their tasks in a self-regulating
manner (homeostatis). The rules for (minimizing) coupling and (maximizing)
cohesion must be observed. The subsystem transmits status information about
itself, and receives command instructions from other subsystems. This
approach, has many variations.
For example, consider the following examples (Kasser 1999):
• Spacecraft or missile control: in an early implementation of a family of
spacecraft for communications or observations, System A is on the spacecraft and
System B is on the ground. System B performs complex control and monitoring
functions that System A cannot. Some System B functions may be even be
performed by human operators and analysts. As technology matures, or new
technology becomes available, some System B functions are migrated into
System A.
The advantages of this approach include:
• Most of the requirements for later generations are known, algorithms have
been developed and tested code and requirements may be reused for replacement
and later generation spacecraft.
• Faster control responses. In case of an onboard malfunction of the
migrated functions, System B is still available on the ground to take over.
Teams: military, commercial, sports teams are all designed complete their
mission if they lose communications with their controller.
THE SYSTEMS APPROACH TO DETAILED DESIGN DECISIONS
• The systems approach to detailed design decisions includes designing to allow for requirements changes
DESIGNING CONSISTENCY ACROSS SUBSYSTEMS
• The role of the systems engineer is to ensure consistency across subsystems. For example:
• In software: to ensure uniformity in messages to provide the same look and feel to the user interface.
• In hardware: to use the same parts for same functions to simplify maintenance and spares.
THE PROBLEM POSED BY THE SUBSYSTEM CONSTRUCTION STATE
• The problem posed by the subsystem construction state can be framed in the problem formulation template as follows:
1. The undesirable situation at the start of the state is the need to construct each subsystem, often in isolation, according to the
final design approved at the CDR.
2. The assumptions: the design specifications are feasible within the cost and schedule constraints.
3. The FCFDS is each subsystem, constructed in isolation, operating according to the final design approved at the CDR.
4. The problem is to construct each subsystem in isolation according to the final design approved at CDR in such a manner that the
subsystem should meet all its specifications when integrated and tested.
5. The solution: follow the SDP.
Each subsystem passes through its own individual SDP in parallel to all the others.
• The role of the systems engineer is:
• To facilitate communication between subsystem development teams.
• To stay in touch with the SDP of each subsystem.
• To ensure that each subsystem meets its functional and non-functional requirements.
• To perform system-level trade-offs between the subsystems if a subsystem cannot meet its budget.
• The systems engineer represents or accompanies the customer for the subsystems and accordingly:
• Attends the milestone reviews of the subsystems to monitor the formal process progress of the subsystems.
• Attends informal reviews and periodic status meetings.
• Lets it be known that problems that may not be remedied in one subsystem may be remedied in another subsystem and not
impact the entire system as long as each subsystem system engineer cooperates.
• Guides design decisions in each subsystem to optimize the system,