8.1systems Engineering Hand Outs

Introduction to Systems Engineering - Session 2
Introduction to
Systems Engineering
Why do we Need Systems

Engineering ?
Brad Yelland (BEng, Aero)

Systems Engineering Manager,
Missile Programmes,
BAE SYSTEMS Australia
Introduction to Systems Engineering
Simplification of Complex Systems
Control Design Process
Flow down of System Requirements to Component Level
Facilitate Progressive Testing (flow up)
Produceability and cost
ENSURE FINAL PRODUCT MEETS REQUIREMENTS
Part 1: - Definitions
What is Systems Engineering?
Part 1 : - Definitions
Basic concepts and definitions

What do we mean by SYSTEM

A set or assemblage of things connected, associated
or interdependent, so as to form a complex unity; a
whole composed of parts in orderly arrangement
according to some scheme or plan; rarely applied to a
simple or small assemblage of things.
Shorter OED, 3rd Ed.
systems, systems engineering, systems engineers

a brief history and context
System Lifecycle

developing a system
the basic process
why its important
What do we mean by SYSTEM (2)

A system is a composite of people, products and

processes that provide a capability to satisfy stated
needs. A complete system includes the facilities,
equipment (hardware and software), material,
services, data, skilled personnel and techniques
required to achieve, provide and sustain system
effectiveness. (MIL STD 499B)
A system is an aggregate of end products and
enabling products to achieve a given purpose.
(EIA-632)
7
10
Characteristics of a SYSTEM
A complex set of interrelated elements working

together to fulfill some designated need
Sub-systems can be equipment, materials, software,

people, and other systems

11
must be functional and able to respond to that need
A system is contained within some form of hierarchy

Sub-systems are not necessarily technology-based
12
Hierarchy of systems
Unprecedented and Precedented Systems
Transportation System
Precedented system
Unprecedented system
What is unprecedented for one person may be

precedented for another
Vehicular System
Airline System
Railroad System
Booking System
Propulsion System
Airplane System
Baggage Handling System
Fuel System
Maintenance System
Technicians
One for which an experience base exists

One for which no experience base exists
complexity is not an absolute
Supply System
13
What is Systems Engineering?

What is Systems Engineering?(2)

the contractors organised, creative, technical and management
processes for translating a customers need into a clear definition of a
solution, and the production, test, delivery, and integration of
components of that solution (on time, on schedule and within budget).
- Grady, J.O.
Engineering is contriving, designing, inventing

14
things characterised by
Size
and complexity
on diverse technological and nontechnological disciplines
Satisfying a stated need
Dependence
an interdisciplinary approach to evolve and verify an integrated and

life-cycle balanced set of system product and process solutions that
satisfy customer needs. - MIL-STD-499B
integrate related technical parameters and assure compatibility of all
physical, functional and program interfaces in a manner that optimises
the total system design and definition
15
What is Systems Engineering?(3)

What is a Systems Engineer?
The design of the whole as distinct from the design

of the parts Simon Ramo
A structured way of handling complexity
The best way to maximise probability of a successful
outcome
But it is not.

16
A Systems Engineer is a person who engineers

systems
No discipline prefix
The term is used in other ways elsewhere
A silver bullet
A cookbook approach to success
An excuse to stop thinking
17
with the professional engineering dimension

introducing elements of judgement and competence
crosses many disciplines
18
History of systems engineering

1960s

History of systems engineering (2)

1980s
1990
1995
Polaris submarine - AFSCM 375 -5

Apollo - NASA procedures
MIL-STD-499 - 25 pages - validate contractors
process
US Army FM 770-78 - less forms, more
organization

Replace MIL-STD-499 with IEEE-1220 and EIA-IS 632

Interim SE Capability Maturity Model
1996
1999
DSMC handbook
Formal software requirements analysis & design
NCOSE established
1970s
Computer tools start to emerge (RDD-100, etc)
Draft Commonwealth policy on SE

EIA-632, EIA 731
19
20
System lifecycle
Recall the Hierarchy?

Transportation System
Concept
Exploration
System
Definition
Engineering
Development
System
Development
System
Qualification
Operation &
Maintenance
Deployment
Vehicular System
Airline System
Railroad System
Booking System
Airplane System
Baggage Handling System
Propulsion System
Fuel System
Maintenance System
Production
Technicians
Disposal
21
Integrate
Airline
System
Emergent properties - properties

which are not present in any of the
individual
parts,
but which
Contract
Boundary
become apparent as the parts
Design
come together
Maintenance
Design
Fuel
Design Pump
Pressure
Regulator
Design
Fuel
Storage
Fuel
Storage
Integrate
Fuel
Pump
Acquire
Pump
Components
Integrate
Fuel
System
Integrate
Airplane
Prop
u
Sy st lsion
em
Design
Fuel
System
Concept
Definition
Operational
Evaluation
Contract Boundary
Mtce
Sy stem
System
Design
Propulsion
System
Developing Any System
Press
u
Regu re
lator
Design
Airplane
22
Developing the Airplane System

Airline
System
Supply System
System
Design
First Sub-system Tier
Design
Design
Design
Design
Integrate
Integrate
Integrate
Integrate
Implement
Implement
Implement
Implement
Design
Tier n
23
System
Integration
Verification
Integrate
Implement
24
System Decomposition
Whats doesnt the V-diagram show?

There are other perspectives

Inputs
from
previous tier
Requirements
Analysis
Requirements Loop
Grand
System Analysis
& Control
Functional
Analysis/Allocation
Verification
Iteration
Text Book Life Cycles

Design Loop

Synthesis
Design (waterfall), Incremental, Evolutionary
Change Process
Documentation View
Configuration Baselines
Cant show everything on one diagram

KISS
All models are wrong; some models are useful
Outputs
to next tier
25
Hard or Soft?
Divide and Conquer
This is great for hard systems

What has to be decided?
When does it have to be decided?
Who does it?
How does one reach a decision?
Societal, Political, Organisational systems

Adaptive, evolving
Soft Systems Methodology, System Dynamics, etc
Creative
Performance of the parts is deterministic and

predictable
Works well for todays technological systems
Not so good for soft systems

26
Not too much, not too little

Not too soon, not too late
The engineer capability continuum
Processes, methods and tools
Understanding Why is more important

than knowing How
Problem Solving, Flood & Jackson (Wiley)

27
Design of Components
Exercise - Design of Components
The design of a Component is not effected by the size or

complexity of the System it is used in.
The design of a component is driven by three requirements;

Form
Physical
Interfacing
Fit
-Size
-Mechanical Interfacing (fixing)
Function
-Shape
-Electrical Interfacing
-Weight
-CG
-Inertia
Consider 2 components from vastly different systems:

System 1. An electronic automatic garage door.
Component: Actuator to open and close the door.
System 2. A Ship Based Theatre Air Defence System
Component: Actuator to move the missile control fins
Q1. What information is required to design or select an appropriate

actuator for each case?
-Communication / Data Interfacing

- Effect of function
What it does &
How it does it
-Performance
-ilities
-Environment
28
Q2. How do you determine that information?
29
30
Part 2 : - Defining the System

During this session we will examine
Part 2: - Defining the System

Where
do needs come from?

needs and implied expectations
Expression of customer needs
The engineering prerequisites for starting system
design
Explicit
Followed by syndicate work

32
First Article
The Systems Engineering Front End
Production
Complete
Characteristics
of system
lifecycle
Proven 95%
Tier 1: System
Operation
and
Maintenance
Design 85%
e
Th
Tier
O: Concept
100
Established 70%
on
Fr
Tier 1
Operational
Evaluation
nd
tE
Concept
Definition
Tier 0
System
Design
60
System
Integration
De
% of Lifecycle
cost
co
m
s
po
on
iti
gr
te
In
Design
Design
Design
Design
Integrate
Integrate
Integrate
Integrate
Implement
Implement
Implement
Implement
Tier 2
80
io
at
40
Life cycle cost

effectively
rendered
unchangeable
for a given
design
Life cycle
cost
actually
expended
20
0
33
Whither Customer needs?
Concept
Exploration
34
System
Definition
Whither customer needs (2)
Engineering
Development
DSTO
Staff
Strategy/
Policy
Reqt
Capability
Development
OCD
Field
Defence
Acquisition
System
Development
Operation &
Maintenance
CTDs,
System
Qualification
Deployment
Studies
DoD
Industry
SOR
Prime
Contractor
Eng Spec
Sub
Contractor(s)
Production
Disposal
35
36
A system, or just shalls?

Capturing the need
Understand the customers problem

Understand the operational concept
Understand the system context
Identify major states and modes of the system
Understand other unstated needs
THEN you can begin to design the system
Understanding the customers problem is the key to

meeting his needs
Technical and personal issues are involved
Understanding customer needs leads to system
designs that will satisfy those needs
Meeting needs is the essence of success
Ultimately much cheaper than just delivering shalls

37
Understanding the Customers problem

The Operational Concept document
Methods as varied as problems and customers

38
Talk to the customer

Which
Market intelligence
Domain knowledge and expertise

Think
Customer version may or may not be released
Contractor may be asked to prepare OCD

Contractor may volunteer its preparation
May
includes all stakeholders in his organisation
Starts
May comprise one or more physical objects
well before contract
like the customer
Expresses users need in user-speak

require further elaboration
Not design solution definition

Evolution must be managed carefully
Aids satisfaction of fitness for purpose obligation
39
40
The Operational Concept document (2)
What is the System Context?
Represents position of system in the greater world

Identifies constraints imposed by that world
Define the system boundary wrt other systems and

organisations
Operation, management and support
Interactions with other systems

physical, functional, environmental, cultural
reduce soft interactions as far as possible
Interfaces with other systems

Identified, characterised
Describes operational scenarios

Use
graphics, pictures, videos, etc

Describe how the system will be used
No shalls
Scenarios identify essential states and modes
Scenarios used as basis for system evaluation
30/03/2001
41
30/03/2001
42
The Context Diagram
Why define the System Context ?

Provides view of system interactions with the external world

high-level, simple, diagrammatic

Interfacing
Systems
Environment
Provides basis for agreement of system boundary and

environment
Identifies all external systems and interfaces
Triggers questions and raises issues concerning user functions
Provides guidance in developing system specifications
System
30/03/2001
43
Organic
System
30/03/2001
44
The Context Diagram
The Context Diagram
Garage
Environment
Automatic
Garage
Door
STAD
System
Target
Operator
30/03/2001
45
30/03/2001
States and Modes
Context diagram(s)
Interface list
Description of transactions for each interface
Initial
data dictionary (for data-oriented systems)

Control and other events
Human and physical interactions
Include timing information (where relevant)
30/03/2001
Other Assets
46
Products of Context Analysis
Ship
Platforms
Environment

47
States are the highest level grouping of alternative

characteristics
Modes are lower level groupings of non-simultaneous
capabilities. Each mode usually may apply to one or more
states.
There is no absolute definition of state or mode
If none are obvious, dont invent them!
30/03/2001
48
Example of States and Modes
Other Needs
The combat system shall have three states as

determined by fault conditions and network
management:

normal operation;
degraded operation;
non-operation
OCD captures customers expressed needs

Fitness for purpose
Prime contractor may have needs
Customers implied needs
Safety
in all likely scenarios

suitability
Economical through-life supportability
Legislative compliance
etc
Whether
or not
they are
in the
contract
Cultural
The weapon system shall operate in automatic or

manual mode in normal operation and only in manual
mode in the event of degraded operation.
30/03/2001
49
50
Part 3: - Requirements Analysis

Now Lets Develop the Systems
This Part will provide an overview of requirements

analysis by presenting:

Part 3: - Requirements Analysis

Why requirements analysis is important

What are requirements
The types of requirements
The attributes of good requirements
Requirements capture
Outputs of requirements analysis
52
System lifecycle
System Development V
Concept
Definition
Concept
Exploration
System
Definition
Engineering
Development
Operational
Evaluation
Contract Boundary
System
Design
System
Integration
Verification
System
Development
Operation &
Maintenance
System
Qualification
Deployment
First Sub-system Tier
Production
Design
Design
Design
Design
Integrate
Integrate
Integrate
Integrate
Implement
Implement
Implement
Implement
Design
Disposal
Tier n
53
Integrate
Implement
54
System Design
Why Requirements Analysis is Important
Inputs
from
previous tier
Requirements
Analysis
Requirements Loop
Verification
System Analysis
& Control
Functional
Analysis/Allocation
Design Loop
Synthesis
Outputs
to next tier
55
Risk Perspective on Requirements

What is a Requirement ?
Customer/Contractor mutual agreement on the

meaning of the requirement
Expenditure on non feasible requirements
Requirements that cannot be proven
Moving goal posts

56
A capability needed by a user to achieve an objective

(IEEE Standard Glossary of Software Engineering terminology)
A positive statement specifying something which is to

be verifiably present in a final product
(Lockheed Space and Missiles Co. Inc. 1991)
new/changing requirements or
new/changing interpretations
Something that governs what, how well, and under

what conditions a product will achieve a given
purpose (EIA-632, 1999)
57
What is Requirements Analysis ?

What is a Black Box Description ?
Requirements analysis transforms the inputs into the

Systems Engineering process into:
58
A black box description of the requirement

The criteria to be used to verify that the requirements
have been met
A Black Box Description is not concerned with the

internal workings
It provides the following types of requirements:
Functional Requirements
Constraints
- What has to be done
It also produces an understanding and consensus of

the need to assist in the remaining activities
Performance Requirements
Constraints
- How well it must be done
Inputs
Desired
Output
- External bounds or limiting factors

59
It does not describe How it is done

60
10
Examples of Types of Requirements

Sources of Requirements
What type of requirement (Functional, Performance or

Constraint) are the following?

The system shall display the target position within 1

second of detection.
The system shall provide wireless data communications
between sites.
All AC power wiring shall conform to AS3000.
The radar system shall detect both fixed and rotary
wing aircraft.
The MTBF shall be greater than 20,000 hours.
Customer Requirements

Derived Requirements

Contract documents and standards

Operational Concept Descriptions (OCD) etc.
To correct ambiguity or incomplete requirements
Implied or transformed from higher-level requirements
Allocated Requirements
Divided or allocated to multiple lower level

requirements
61
Examples of Derived Requirements

62
Examples of Allocated Requirements
What requirements could be derived from the

following?
1 Flight data shall be stored in a database.

2 The supervisor shall be able to access and display
flight data.
3 Flight data shall be be used in the simulator.
4 The trainer shall have a facility to edit all simulator
parameters.
5 The training facility shall be installed in the existing
classroom.
What requirements could be derived from the

following system requirements?
1 The system shall report built in test after power-up.
2 The system shall operate from a single 10A GPO.
3 A LAN shall be used to interconnect all equipment.
Printer
Hardware
Computer
Hardware
Computer
Software
63
Attributes of Good Requirements

Examples of Poor Requirements
A good requirement is

64
Achievable
Verifiable
Unambiguous
Complete
Consistent
Traceable
Expressed in terms of need not solution
Appropriate for the level of system hierarchy
What is wrong with each the following requirements?

65
The ship shall carry enough short range missiles.

The computer shall process and display the radar
information instantly.
The power supply output shall be 28 volts.
The transmitter power shall be adjustable to allow the
antenna side-lobe performance to be met.
The power connector shall conform to RS-232.
The aircraft shall use stainless steel rivets.
66
11
Traceability Requirement
Traceable path to a
Customer need (or
Contract
Requirement)
Traceable path from
test requirements to
source requirements
Minimises redundant
and unnecessary
design activities
User
Need
Requirement Database
Existing
Systems
Operational
Concept

Contract
Documents
Used to capture and manage requirements

Requirement Management tools:

Referenced
Standards
Legal
Obligations
Development
Spec(s)
Test
Spec(s)
Lower Level
Dev Spec(s)
Lower Level
Test Spec(s)
manage and track requirements

capture changes & rationale
control process
67
68
Where does it fit ?

Part 4: - Functional Analysis,
Allocation and Synthesis
Inputs
from
previous tier
Requirements
Analysis
Requirements Loop
Verification
System Analysis
& Control
Functional
Analysis/Allocation
Design Loop
Synthesis
Outputs
to next tier
70
Part 4: - Functional Analysis & Synthesis

Functional Analysis & Synthesis

This part will cover,

processes
But first, lets see where this session fits into the big
picture, by going back and briefly look at,
the
overall system life cycle

development part of the life cycle
alternative (& equivalent) nomenclature
products
the
documentation
standards (briefly)
examples
methods
basic
71
72
12
Concept
Analysis
Development
Customer
Int & Valid
Tier N
Production
System
Definition
Deployment
System
Int & Valid
Operations
Support
Subsystem
Definition
(tier 1)
Subsystem
Int & Valid
(tier 1)
Disposition
Subsystem
Definition
(tier n)
Subsystem
Int & Valid
(tier n)
Subsystem
Implement
73
74
Functional Analysis & Synthesis
White Box Behaviour
How do these processes fit within the bigger picture?

Lets
White box behaviour is defined using the,

Functional
assume that each tier (of the evolving system

design) is described by a black box and white box view.
Consider the Requirements Analysis process as one
which addresses the black box behaviour of a system.
So what process is used to describe the white box
behaviour of a system?
Synthesis
Analysis process
process
Process outputs,
Functional
Synthesis
Analysis output => Functional Model

output => Physical Model
75
76
Black
Box
What is a Black Box and White Box view?
Black
Box
Tier N
Concept
Analysis
Customer
Integration
White
Box
Black Box view,
Black
Box
Black
Box
White
Box
White
Box
System
Integration
System
Definition
description
of the system in response to interactions

with external agents without regard to implementation
details.
White
Box
Black
Box
Subsystem
Definition
(tier 1)
White Box view,
Black
Box
White
Box
White
Box
description
of the systems internal behaviour and

construction in meeting the requirements defined by the
black box view to a level sufficient for further
subsystem identification.
77
Subsystem
Definition
(tier N)
Black
Box
Black
Box
White
Box
White
Box
Subsystem
Integration
(tier 1)
Subsystem
Integration
(tier N)
78
13
Customer
Business
EIA-IS-632
View
Black &
White View
Requirements
Analysis
Black
Box
What &
How View
Tier N
Concept
Analysis
White
Box
Black Box
Description
What
Description
Customer
Customer
Component
(existing)
SYSTEM
(to be acquired)
Customer
Component
(existing)
Customer
Component
(existing)
Black
Box
System
Definition
Contractual Boundary
(in theory)
White
Box
Supplier
Functional
Analysis
White Box
Functional
Description
SUB-SYSTEM
1
SUB-SYSTEM
2
Subsystem
Definition
(tier 1)
How
Description
White Box
Physical
Description
Synthesis
Black
Box
SUB-SYSTEM
N
SUB-SYSTEM
2-1
SUB-SYSTEM
2-2
SW Subsystem
2-2-1
SUB-SYSTEM
2-N
HW Subsystem
2-2-2
White
Box
Black
Box
Subsystem
Definition
(tier N)
White
Box
HW Subsystem
2-2-3
79
Before Functional Analysis & Synthesis
Customer
Business
Black
Box
Tier N
80
Customer
Integration
White
Box
Black
Box
Customer
Component
(existing)
System
Integration
SYSTEM
(to be acquired)
Customer
Component
(existing)
Customer
Component
(existing)
Tip
White
Box
Black
Box
Validate black box

behaviour.
White
Box
SUB-SYSTEM
1
SUB-SYSTEM
N
Black
Box
White
Box
SUB-SYSTEM
2
Subsystem
Integration
(tier 1)
SUB-SYSTEM
2-1
Subsystem
Integration
(tier N)
SUB-SYSTEM
2-2
A detailed elaboration of the requirements should be

concentrated within the Functional Analysis &
Synthesis processes.
Because these processes make use of,
a
relatively well defined graphical notation.

relatively rigorous description language
(having a well defined syntax and semantics).
SUB-SYSTEM
2-N
a
SW Subsystem
2-2-1
HW Subsystem
2-2-2
HW Subsystem
2-2-3
Validate incrementally
integrated white box
elements.
This leads to a more rigorous description of the design

(less risky to understand & verify).
81
82
Functional Analysis & Allocation
Functional Analysis & Allocation (cont)
Process accomplished by,

defining
examine
Whats the & Allocation component ?

It
the functions required

tracing the functions to requirements
defining the I/O for all functions
defining how control operations order the functions
budgeting time durations to functions (if important)
budgeting system accuracy requirements to functions
executing the behaviour to establish correctness
represents the allocation of performance

requirements onto the appropriate functional elements.
time lines, examine magnitude of I/O, ...

83
84
14
Functional Analysis & Allocation (cont)
Synthesis
Ultimately performed or accomplished by,
Process accomplished by,
equipment
defining
personnel
assigning
real world objects subject to design constraints

attributes to the objects
allocating behaviour to the objects
budgeting performance values to attributes
executing the behaviour with the objects
examining the interface traffic between objects
facilities
software
combination
of the above
85
86

Black
Box
White Box
Functional Analysis & Synthesis Solutions
F
White
Box
F
F
There may well be multiple architectures,
F
F
This
sets the stage for trade studies.

Trade studies select the most practical solution from
the candidate architectures.
System effectiveness measures are the criteria used to
make the trade study decisions.
F
F
P2
P3
P1
Tier N
Effectiveness
measures are the small subset of reqs that

are so important that the system will fail if they are not
met and will be a huge success if they are met.
Tier N+1
Black
Box
Black
Box
Black
Box
White
Box
White
Box
White
Box
Process repeats for each

subsystem identified in
the tier above.
87
Major O/Ps - Eng Technical Processes

(cont)
Major O/Ps - Eng Technical Processes

Major outputs from the white box stage are a

<reviewed & baselined> version of,
88
Subsystem Integration Results (integration leg)

System Design Description capturing,
Functional
& Physical Models (includes I/Fs)

Measures
Results of Trade Studies & Requirements Assessment
Test results.
Problem reports.
Limitations & deficiencies.
Effectiveness
Subsystem Integration Description capturing,

Phasing
of subsystem integration
per phase
Additional testing requirements
Functionality
89
90
15

Black
Box
White Box
Major O/Ps - Eng Management Processes*
F
White
Box
F
F

(* Just to put things into context)

Major outputs from each stage are an
<updated, reviewed & baselined> version of,

F
F
F
F
P2
Plans
Risk Register (Identification, Remediation)
Milestones
Cost and Time Schedules
Work Breakdown Structure
Work Packages
P3
P1
Tier N
Tier N+1
Black
Box
Black
Box
Black
Box
White
Box
White
Box
White
Box
Process repeats for each

subsystem identified in
the tier above.
91

The non-value adding
approach performs no other
activities except cutting text
from a parent SSS directly
into a subordinate SSS.
The normal value adding
path is by-passed.
92

Black
Box
Where to stop ?
SSS
White
Box
Cut & Paste
How far do you decompose the functional model ?

SSDD
Cut & Paste
Cut
Cut&&Paste
Paste
Tier N
Tier N+1
Black
Box
Black
Box
Black
Box
SSS
SSS
SSS
In summary,

White
Box
White
Box
White
Box
SSDD
SSDD
SSDD
Down to the point where any function can uniquely map

onto a physical subsystem.
If a function cant map uniquely then it must be
decomposed further until it can.
Many functions can map onto a single subsystem.
A single function cannot map onto multiple subsystems.
93

Option A
Target
Introduction
to Systems Engineering
Option B
Track
Target
Position
(3D)
94
Monitor
Missile
Missile
MissileAbort
Track
Target
Position
MissileCharacteristic
TargetReflectedLight
MissileMovement
Track
Missile
MissileGuidance
This system is cued

automatically by the
Command & Control
System using the 3D
position data
established by the
Radar System.
Magnify
& Focus
Light
Track
Target
Position
(x&y)
Track
Target
Position
(z)
LookDirection
Change
Look
Directn
Safe Operating
Envelope/Area
MissileMovement
LookDirection
Guide
Missile
VisibleImage
LookDirection
DeltaPosn
Est
Launch
Posn
Est
Optimal
Image
Position
MissileAway
LaunchPosn
Dispatch
Missile
Wind
Radar
System
A
Radar
System
B
Weapon
Delivery
System
Command
& Control
System
Turns out that this

system tracks the target
in elevation (z plane)
using optical techniques
(which includes the
operator)
Weapon
Delivery
System
External
Env
Organic
System
(Operator)
Command
& Control
System
95
Lens
System
Supports
Gimbal
System
96
16
Introduction to Systems Engineering Radar System

Attributes:MTBF
MTTR
Size
Colour
Weight
RF
PRF
PW
ARP
Ppk
OpMode
Data I/F

: 200 hours
: 2 hours
: 3m x 2m x 2m
: Army Green
: 2 man lift
: radio frequency, 9500MHz
: pulse repetition freq, 800Hz
: pulse width, 2.0usecs
: angular rotation period, 1.4secs
: peak power, 110KWatts
: (Idle, Passive, Radiating)
: RS-422, 9.6Kbits/sec
Concept
Analysis
Customer
Int & Valid
Tier N
System
Definition
System
Int & Valid
Services:TargetCharacteristic
Search
TargetData
Subsystem
Definition
(tier 1)
TargetIllumination
Subsystem
Int & Valid
(tier 1)
Target
IFFResponse
Identify
Tender
Response
Slice of
Development
Stage.
Consumer
TargetIdentity
IFFRequest
Subsystem
Definition
(tier n)
Subsystem
Int & Valid
(tier n)
HealthReply
Subsystem
Implement
Health
Check
HealthRequest
Internal
Subsystems
* Not a complete description.
97
Synthesis - Modular Design

Synthesis - Modular Design (cont)
Desirable attributes of modular system components,

98
Low Coupling
High Cohesion
Definition,
Coupling - a measure of the relative interdependence

between subsystems.
Simple
connectivity among subsystems results in a

system that is easier to understand and less prone to a
ripple effect when errors or changes occur in another
part of the system.
Cohesion - a measure of the relative functional strength

of a subsystem.
A
cohesive subsystem performs a task with little

interaction with other parts of the system.
99
100
Synthesis - Modular Design (cont)
Abstract Example (covering software)

In summary, develop subsystems with,

The following example looks at,

single-minded function.
an aversion to excessive interaction with other
subsystems.
101
A Subsystem model.
A CSCI model - one element of the subsystem model is
a software item.
A Hardware architecture - defining the solution for the
Subsystem and CSCI models.
102
17
CSCI Functional Model
Subsystem Functional Model

Introduction to Systems
Engineering
(white box)

(white box)
F2
F2
F3
F3
F4
F4
F1
External
Agent 1
F1
External
Agent 1
SW
DS1
External
Agent 2
External
Agent 2
DS1
F6
F8
F5
F6
F9
F5
F7
F7
F8
DS1
SW
DS2
Subsystem Physical Model

(white box)
If using a multitasking, message

passing executive
then this interface
becomes a message
CSCI Physical Model

(white box)
CSC 2
=F3 +F4
HWCI 1
=F2 +F3
External
Agent 1
External
Agent 1
CSC 1
=F1 +F2
+F5
HWCI 3
(derived)
External
Agent 2
CSCI 1
=F1 +F5
+F4 +F8
+DS1
HWCI 2
=F6 +F7
+DS2
103
High Speed Bus
If using a multitasking, message

passing executive
then a CSC
becomes a task.
CSC 3
=F6 +F8
CSC 4
=F7 +F9
External
Agent 2
This CSC is a
DataStore Manager.
Its derived (exists as
part of the design). 104
Processor 2
HWCI 3
+ CSCI 1
Methods
HWCI 1
=CSC2
Processor 1
COMMON BUS
=CSC1 +CSC3
CSC 5
(derived)
=SW-DS1
+SW-DS2
There are many different Methods/Tools that can be

employed to assist with step.
HARD DISK
I/O CARD
Processor 3
=SW-DS1
+SW-DS2
= external
interfaces
=CSC4 +CSC5
HWCI 2

Structured Analysis
Structured English
Object Oriented Methods
Functional Flow Block Diagrams
Schematic Block Diagrams
External Agent 1
External Agent 2
105
Methods Summary
At the End of the Day
Methods required to support the following (white box)

processes,
Functional Modelling
Physical Modelling
Static
Static
106
& Dynamic descriptions
There are no silver bullets, no panaceas, and no

miracle cures that will automatically increase an
engineers effective productivity by a factor of 10.
Even knowing all the theory, Engineering is still,
& Dynamic descriptions
Simulation
Its an advantage to understand all of the theory,

107
95% hard work

5% inspiration
Just so you can go back and break it,
*BUT* with the full understanding of the risk involved.
Living with risk is a fact of life.
108
18
Exercise - Design of Components
Further Reading
System
Engineering Fundamentals, October 1999,

Defense Systems Management College (DSMC).
Consider 2 components from vastly different systems:

System 1. An electronic automatic garage door.
Component: Actuator to open and close the door.
a
more mature version of the traditional systems

engineering approach
method sections need significant updating & expanding
to bring it up to speed
words are enlightening; worth a read
System 2. A Ship Based Theatre Ballistic Missile Air Defence System

Component: Actuator to move the missile control fins
Q1. What information is required to design or select an appropriate

actuator for each case?
System
Engineering Handbook, rel 1.0, Jan 1998,

INCOSE.
Q2. How do you determine that information?
a
monster
bedtime reading
definite
109
110
Further Reading (cont)

IEEE
Std 1220, Trial-Use Standard for Application and

Management of the Systems Engineering Process.

MIL-STD-499B,
BAeA
Systems Engineering, Draft, Sept 1993
never officially seen the light of day.
EIA-IS-632,
Systems Engineering, Dec 1994.
originally just 499B in disguise

(mil speak and shalls removed)
official release has been watered down
Systems Thinking Guidebook, Issue H, Nov99

same philosophy as this presentation (~250 pgs).
111
Part 5: - Integration, Verification and

Validation
Definitions
This Part will examine the integration activities of a

system and the associated verification:

Part 5: - Integration, Verification and

Validation
has been around since about 1994

last half describes processes in reasonable detail
The implementation side of the V model

How verification fits in with integration
Verification vs validation
The inputs required for success
Integration: The merger or combining of two or more lower

level elements into a functioning or unified higher level element
with the logical and physical interfaces satisfied. (EIA/IS 632)
Verification: Confirmation by examination and provision of

objective evidence that the specified requirements to which an
end product is built, coded or assembled have been fulfilled.
(EIA 632)
113
Validation: Confirmation by examination and provision of

objective evidence that the specified intended use of an end
product or aggregation of end products is accomplished in an
intended usage environment. (EIA 632)
114
19
The Implementation Leg
Design for Integration

Require men ts
Anal ysis
System
Verification
Verification
Criteria
Fu ncti ona l Ana l ysis/

Allocatio n
Syn thes is
Integrate
Correct
ig
Des
Verification
Criteria

Fu ncti
ona l Ana
Allocatio
n l ysis/
Allocatio n
Sub-system
Verification
Syn thes is
Syn thes is
Integrate
Correct
Require men ts
Require
men ts
Anal ysis
Require
men ts
Anal ysis
Require
men ts
Anal ysis
Anal ysis

Fu ncti
ona l Ana
Allocatio
n l ysis/
Fu ncti
ona l Ana
Allocatio
n l ysis/
Fu ncti
ona l Ana
Allocatio
n l ysis/
Allocatio n
Syn thes is
Syn thes is
Syn thes is
Syn thes is
Verification
Criteria
Unit
Verification
Integrate
Correct
Imp
lem
ent
Require men ts
Require
men ts
Anal ysis
Anal ysis
Multiple levels of integration and verification

Each level corresponds to the design hierarchy
The interfaces between all components must be
defined
The interfaces between the system and external
systems must be defined
Engineering models and prototypes can assist the
design and implementation process
Component Implementation
115
Verification
Verification Methods
Verification requirements result from requirements

analysis

Functional Performance Physical -
116

Does it do what it has to do

Does it do it as well as it has to
Does it meet the constraints and
external interfaces

Test
Demonstration
Analysis
Inspection
117
Examples of Verification Methods

Golden Rules for Verification
What verification methods could be used for the

following?

118

The system shall display the target position within 1

second of detection.
The system shall provide wireless data communications
between sites.
All AC power wiring shall conform to AS3000.
The radar system shall detect both winged and rotor
aircraft.
The MTBF shall be less than 20,000 hours.
119

Verify at as low a level as possible

Verify as early as possible
Balance verification by analysis with testing
Address problems as soon as possible
Ensure design is testable
Verify test and simulation tools
Success is highly dependent on the effort applied during

the design process
120
20
Design and Product Verification

Design verification ensures that the design meets the

requirements if manufactured correctly

Integration and Verification Problems
Full functional and performance verification

Detects non-conformance between the product and its
specification
Product verification ensures that the system has been

manufactured correctly

Plans must cover what to do if integration problems or

verification failures occur
Corrected at the next level down or design where
necessary
Dealing with COTS

Inspection
Production controls
Acceptance testing

Undocumented features
Not developed for the environment
Defined behaviour and interfaces
Support
121
122
Installation and Validation

Installation into the operational environment

Interfaces to external systems may require simulation
Uncontrolled environment - validate in phases
May involve user training
Validation of user manuals
May be used to verify operational requirements such
as availability
Must be well planned
Part 6: - System Analysis and Control
123
Objectives of this Session

Requirements
Analysis
Requirements Loop
Verification
Functional
Analysis/Allocation
This Session provide an overview of the management

of the Systems Engineering process:
System Analysis
System
Analysis
& Control
& Control
(Balance)

(Balance)
Design Loop

Synthesis
125
Technical reviews and audits

Trade studies
Technical performance measures
Specialty engineering integration
Decision database
Management of risk, requirements, configuration and
data
126
21
Technical Reviews and Audits

Conducting Reviews
Used to measure design progress and maturity

Key development milestones
Confirmation of completed effort and readiness to
proceed
Depth of review based on complexity of system, subsystem or CI being reviewed

Event driven
Be well prepared - there shouldnt be any surprises
Establish success criteria beforehand
Review material includes:
specifications, drawings, design and test data, trade

studies, risk analysis, schedules, engineering models,
mock ups and prototypes ...
Follow up review actions quickly
127
Types of Reviews and Audits

128
Analysing Alternatives
System Requirements Review (SRR)

System Design Review (SDR or SFR)
Software Specification Review (SSR)
Preliminary Design Review (PDR)
Critical Design Review (CDR)
Test Readiness Review (TRR)
Production Readiness Review (PRR or PAR)
Functional Configuration Audit (FCA or SVR)
Physical Configuration Audit (PCA)

Alternative solutions always exist to every decision

Identify the alternatives
Select the alternative that is best for the system
Best can be defined in terms of measures of
effectiveness for the system
129
Trade Studies

130
Trade Study Basics
Required to support design decisions

Supports functional analysis and allocation
Evaluate alternative functional and physical
architectures
Document make/buy and material selection decisions
Evaluate environmental factors
Establish the study problem:
Review inputs:
- Develop a problem statement

- Identify requirements and constraints
- Establish analysis level of detail
- Check requirements and constraints for

completeness and conflicts
-Develop customer-teamcommunication
Select and setup methodology:

-Choosetrade-offmethodology
- Develop and quantify criteria, including
weights where appropriate
Analyseresults:
- Calculate relative value based on
chosen methodology
-Evaluatealternatives
-Perform sensitivity analysis
- Selectpreferred alternative
-Re-evaluate results
Taken from the DSMC Systems
Engineering Handbook
131
Identify and select alternatives:

- Identifyalternatives
- Select viable candidates for study
Measure performance:
- Developmodels and measurements of
merit
- Develop values for viable candidates
Document process and results

132
22
Typical Trade Studies

System design alternatives:

Technical Performance Measures

Solar power vs mains power

Valve vs solid state transmitters

Planned
Profile
Technical
Parameter
Values
Trades one system performance measure against

another:
Parameters of critical importance or risk

Provides early warning of design deficiency or excess
eg. MTBF
ToleranceBand
Achievement
to date
Contract
Completion
Current
Estimate
Cost/weight
Cost/power consumption
Reliability/life cycle cost
Redundancy/life cycle cost
BIT/level of support
Variation
Threshold
Planned
Value
Milestones
133
Specialty Engineering

134
Specialty Disciplines
Identify specialty requirements in the system

Assign specialty requirements responsibility
Specialty engineers help the Systems Engineer
understand the requirements
Assists with the ilities

Human factors
Survivability
Reliability/maintainability/availability
Supportability
Electromagnetic compatibility
Producability
Safety engineering
Value/cost engineering
Logistics engineering ...
135
Decision Database
Engineering Management
The decision database is all of the documentation and

data that supports the design solution:

136
Trade studies and analyses

Requirements traceability
Models and simulations
Alternative solutions
Supporting data

137
Risk management
Configuration management
Data management
Requirements management
Technical personnel management
Cost and schedule management
Technical review and audit program management
138
23

Part 7: - Conclusion
This Session provides an overview of the planning

that supports the System Engineering process:
Importance of Planning

System Engineering Management Plan (SEMP)

Test & Evaluation Master Plan (TEMP)
Technical Review and Audit Plan (TRAP)
Configuration Management Plan (CMP)
Work Breakdown Structure (WBS)
Wrap up of the course
140
Why Plan
SEMP
Why is Systems Engineering planning so important?:

Agreement with customer

Documents how the BAeA processes will be applied
Breaks the work into comprehendible packages
Provides guidance to the project team
Early warning of problems
Systems Engineering Management Plan (SEMP)

Documents the SE methods and organisation to be
applied to the project
Living document reflecting the current stage of the
design life-cycle
DID provided in MIL-STD-499B, IEEE 1220, and
EIA/IS 632
Must be in accordance with BAeA standard
procedures
141
TEMP

TRAP
Test and Evaluation Master Plan (TEMP)

Documents the planning of all test and trials activities

142
Where, when, how and with what resources

Establishes the verification methods for customer
agreement
Identifies long lead resources such as specialised test
equipment and test houses
Establishes customer involvement for supply of GFE
and witnesses
References subcontractor and Software Test Plan(s)
where necessary
143

Technical Review and Audit Plan (TRAP)

Documents the technical reviews and audits to be
applied to the project:

Applicability
Scheduling
Entry and completion criteria
Standards to be used
Often incorporated into the SEMP
144
24
CMP

WBS
Configuration Management Plan (CMP)

Documents the standards and techniques to be use
to manage the configuration of all project data
Applies to internal documents as well as deliverable
documents, hardware and software
Fully defines the change control process

Work Breakdown Structure (WBS)

Documents all activities required to complete the
contracted requirements
Links directly to cost and schedule management
Breaks the work into manageable pieces
145
System Engineering Dos and Donts

146
Further Reading
Do:
Ensure Common Approach
Make Maximum Use of Tools
Tailor the SE approach to optimize the effort versus
benefit equation

Dont
Forget the broader picture
Ignore the cascade effect of change
Spend all your effort on SE
Put off the SE effort
147
EIA 632 - Process for Engineering a System Electronic Industries Alliance

IEEE Std 1220 - Trial-use Standard for Application and
Management of the Systems Engineering Process
System Engineering Handbook - INCOSE 1998
BAeA Systems Thinking Guidebook, Issue H Nov 99
148
Further Reading cont.

System Engineering Fundamentals - Defense Systems

management College (DSMC), 1999
Systems Engineering - coping with complexity, Stevens
et al, 1998
Creative Problem Solving - Total Systems Intervention,
Flood & Jackson, 1991
149
25

8.1systems Engineering Hand Outs

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

8.1systems Engineering Hand Outs

Uploaded by

Copyright:

Available Formats

Introduction to Systems Engineering - Session 2

Why do we Need Systems

Brad Yelland (BEng, Aero)

Introduction to Systems Engineering

Simplification of Complex Systems

Control Design Process

Flow down of System Requirements to Component Level

Facilitate Progressive Testing (flow up)

Produceability and cost

ENSURE FINAL PRODUCT MEETS REQUIREMENTS

Introduction to Systems Engineering

Introduction to Systems Engineering

Basic concepts and definitions

What do we mean by SYSTEM

systems, systems engineering, systems engineers

Introduction to Systems Engineering - Session 2

Introduction to Systems Engineering

Introduction to Systems Engineering

What do we mean by SYSTEM (2)

A system is a composite of people, products and

Introduction to Systems Engineering

Introduction to Systems Engineering

Introduction to Systems Engineering

Introduction to Systems Engineering

A complex set of interrelated elements working

Sub-systems can be equipment, materials, software,

must be functional and able to respond to that need

A system is contained within some form of hierarchy

Introduction to Systems Engineering - Session 2

Introduction to Systems Engineering

Introduction to Systems Engineering

Unprecedented and Precedented Systems

What is unprecedented for one person may be

Baggage Handling System

One for which an experience base exists

complexity is not an absolute

Introduction to Systems Engineering

Introduction to Systems Engineering

What is Systems Engineering?

What is Systems Engineering?(2)

Engineering is contriving, designing, inventing

an interdisciplinary approach to evolve and verify an integrated and

Introduction to Systems Engineering

Introduction to Systems Engineering

What is Systems Engineering?(3)

What is a Systems Engineer?

The design of the whole as distinct from the design

A Systems Engineer is a person who engineers

The term is used in other ways elsewhere

with the professional engineering dimension

Introduction to Systems Engineering - Session 2

Introduction to Systems Engineering

Introduction to Systems Engineering

History of systems engineering

History of systems engineering (2)

Polaris submarine - AFSCM 375 -5

Replace MIL-STD-499 with IEEE-1220 and EIA-IS 632

Computer tools start to emerge (RDD-100, etc)

Draft Commonwealth policy on SE

Introduction to Systems Engineering

Introduction to Systems Engineering

Recall the Hierarchy?

Baggage Handling System