Systems Engineering

and
Integration
Technology Transition to Target (T4)

Joseph J. Simpson
April 5th, 2010

© 2010 Joseph J Simpson, System Concepts, LLC 1

 Overview

Definitions
Systems Engineering Approach
Systems Integration Approach
Organizational - People
Program, Project and Process
Technology
Major Systems Engineering Process
Technology Development Activities and Process
Science and Technology Streams of Change
Science and Technology Development
Technology Target Analysis
Technology Transition Example
Rapid Technology Development
Summary

© 2010 Joseph J Simpson, System Concepts, LLC 2

 Systems Engineering - Definition

Systems Engineering (SE) is an interdisciplinary approach

and means to enable the realization of successful systems.

Project

Systems Project Planning

Engineering Task & Control
Definitions
System Risk Project
Architecture Management Planning
Technical Specification Customer Resource
Mgt & Coordination Interaction Allocation
Systems Financial Contract
Integration Management

(Adapted from INCOSE SE Handbook, v. 3.2, January 2010)

© 2010 Joseph J Simpson, System Concepts, LLC 3
 Systems Integration - Definition

*“Systems Integration – is the art and science of facilitating

the marketplace of ideas that connects the many separate
solutions into a system solution.”
Mission Function
Level 1

MF MF

A property of the system

Level 2
Mission:
function that determines MF1
+ MF2
+ MF3 MF
how well the mission
function is performed
Level 3 Explosives
Operational Effectiveness
MF1.1 MF1.2 MF1.3
+ MF2.1 MF2.2
+ MF3.1 MF3.2 MF3.3 MF
Detection
Risk
Level 1
A property of
SF SFthe mission Operational Life Cycle
function, the Suitability Cost
Level 2 system function Properties of the system architecture
SF1 + SF2
+ SF3
and the system
SF
architecture
Level 1 Candidate Systems:
SA SA
Level 3
• Dogs
+ + SF
Level 2

• Technical Sensors
SF1.1 SF1.2 SF1.3 SF2.1 SF2.2 SF3.1 SF3.2 SF3.3

System Function SA1 + SA2

+ SA3 SA

Level 3
• Behavioral
SA1.1 SA1.2 SA1.3
+ SA2.1 SA2.2

System Architecture
+ SA3.1 SA3.2 SA3.3 SA
Observation
• Combination of
*Jeffrey O. Grady, System Integration, 1994
above
© 2010 Joseph J Simpson, System Concepts, LLC 4
 Technology Readiness Levels - Definition

Technology Readiness Levels (TRLs) – provide a scale

composed of nine measures that indicate a program's risk and
potential for success.

Technology metrics are Technology metrics are more

associated only with likely to be associated with the
technology attributes and performance of a given mission
characteristics in a given environment

TRL1 (in laboratory) TRL4 TRL5 (in relevant environment) TRL9

Examples
• Weight (Mass, Vibration) For Μ [Mission Accomplishment]
• Processing capacity on a scale of 0 to 1
• Processing speed
• Volume Μ = ƒ ∑ (Technical Performance Measures)
• Power consumption and is the probability of mission success
• Resolution

© 2010 Joseph J Simpson, System Concepts, LLC 5

 Presentation Point of View and Organization

Cost, Linear and

Metric ($) Additive

Program
Resources
Technical
Linear and Schedule, Linear and
Performance,
Additive Metric (Time) Additive
Metric (TPM)

SME
Ex: Weight (Mass, Vibration)

Subject Matter Experts (SMEs) – are used to convert

nonlinear technical metrics to the required linear and additive
metric for technical performance measure (TPM)
© 2010 Joseph J Simpson, System Concepts, LLC 6
 Systems Engineering Processes

*The systems engineering approach is based on the following:

• Define problems before seeking
solutions
Problem Statement
• Search for solutions that WHAT
examines tradeoffs between INPUT
Constraints Functional
alternative solution sets From External Analysis Tradable
Derived
Environment
Requirements
• Utilize traceable integration
process that verifies that the
product meets requirements and HOW
OUTPUT
performs needed functions Alternatives
Solution / Test
Solutions /
System
Architecture Validate Complete
• Deploy information management /Verify

system that can provide each

team member and the customer
with any information concerning
the system that has been
generated. * Adapted from Brian W. Mar, “Back to Basics,” 1992

© 2010 Joseph J Simpson, System Concepts, LLC 7

 Systems Engineering Processes

Abstraction Frame (n-1) Abstraction Frame (n) Abstraction Frame (n+1)

Overall
Environment

Δaf n-1 Δaf n Δaf n+1

Example: DARPA large-scale integration

© 2010 Joseph J Simpson, System Concepts, LLC 8

 Systems Engineering Processes

Abstraction Frame (n-1) Abstraction Frame (n) Abstraction Frame (n+1)

Discovery Discovery Discovery

Knowledge Knowledge Knowledge

Design Design Design

Systems
Systems Systems
Systems Systems
Systems

Δaf n-1 Δaf n Δaf n+1

Similar processes; different focus and systems

© 2003 Joseph J. Simpson, All
Rights Reserved
© 2010 Joseph J Simpson, System Concepts, LLC 9
 Systems Engineering Processes
LIFE CYCLE ‘PHASES’ Initialization Implementation Operations

Typical High-Tech Commercial Systems Integrator

Study Period Implementation Period Operations Period
User Reqts Concept System Acq. Source Operations &
Development Verification Deployment Deactivation
Definition Definition Specification Prep. Select. Maintenance
Phase Phase Phase Phase
Phase Phase Phase Phase Phase Phase

Typical High-Tech Commercial Manufacturer

Study Period Implementation Period Operations Period
Product Product Product Engr. Full-Scale Manufacturing,
Internal Test External Deactivation
Requirements Definition Development Model Production Sales &
Phase Test Phase Phase
Phase Phase Phase Phase Phase Support Phase

ISO/IEC 15288

Development Production Utilization Stage Retirement

Concept State
Stage Stage Support Stage Phase

US Department of Defense (DoD) 5000.2

A
A B
B C
C IOC
IOC FOC
FOC
Pre-systems Acquisition Systems Acquisition Sustainment
System Development Production & Operations & Support
Concept and Technology Development & Demonstration Deployment (including Disposal)

US Department of Energy (DOE)

Project Planning Period Project Execution Mission
Preconceptual Conceptual Preliminary Final
Pre-Project Construction Acceptance Operations
Planning Design Design Design

Typical
Decision New Initiative Concept Development Production Operational Deactivation
Gates Approval Approval Approval Approval Approval Approval

Adapted from INCOSE SE Handbook v. 3

© 2010 Joseph J Simpson, System Concepts, LLC 10
 Systems Engineering Processes

• SE Life Cycle Phase processes are based on relatively

stable types of problems, technologies and organizations
• Changes drive technology and system risk higher
• New organizations and organizational controls
• Processes
• Technology frameworks

• Established technology metrics facilitate management of

technology risk
• Operational environments, customer operational needs
and technology interfaces impact the system design,
technology risk and integration processes
This represents an opportunity to develop a set of
system and integration readiness levels that can be
used to reduce program/organizational risk
© 2010 Joseph J Simpson, System Concepts, LLC 11
 Streams of Change

Science Technology Application Product Organization

Stream Stream Stream Stream Stream

lly lly lly lly

n ta al) n ta al) n ta al) n ta al)
e ic e ic e ic e ic
a m rad a m rad a m rad a m rad
( ( ( (
nd w nd w nd w nd w
Fu ne Fu ne Fu ne Fu ne
New New Product Organization
Application
Science Technology (System) (System)

Incremental Incremental Incremental Incremental

t (sustaining) (sustaining) (sustaining) (sustaining)

Example: BMW parts obsolescence; standard interfaces

© 2010 Joseph J Simpson, System Concepts, LLC 12

 Impact of Change on Systems Development
Abstraction Frames Over Time
(n – 1) (n) (n + 1)

Impacts of
Change

Organi-
zation

Technology
Readiness
Product Levels

≈ TRL8

Appli-
cation

TRL6

New
Tech
TRL1 →
TRL5
New Fundamentally New, Radical
Science
Incremental, Sustaining
Streams of Change in the Environment

New science/technology NOT impacted by change in customers;

Specific applications ARE impacted by changes in customers
© 2010 Joseph J Simpson, System Concepts, LLC 13
 Impact of System and Technology Changes

• Change impact is structured based on the customer mission

• Changes can be addressed by new technology, applications
and/or systems
• Cost impacts are minimized when the new systems and
technology solutions are compatible with existing systems
and/or system standards and frameworks
• Attributes of organizational support and the deployed
environment must be effectively handled to reduce total
system life cycle cost
• Often lifecycle support and operational costs are much greater
than the initial capital system cost

© 2010 Joseph J Simpson, System Concepts, LLC 14

 Technology Transition To Target

Given the domain of a sensor technology, what is a target?

A target is defined as a specific sensor technology developed for
a specific customer and deployed in a specific environment.
Target customer attributes and characteristics:
- Technology acquisition process
- Technology support and operation processes
Target environmental attributes and characteristics:
- Temperature range of operation
- Vibration range of operation
- Electromagnetic interference range of operation
All aspects of the target must be considered for a successful
technology deployment

© 2010 Joseph J Simpson, System Concepts, LLC 15

 Technology Transition Requirements

Given a specific target, how are the requirements

determined?
The target customer requirements are determined from:
- Customer systems engineering process
- Customer logistics
- Operational support concepts

The target environmental requirements are determined from:

- Customer system operational profile
- Assigned area of operation
- Similar existing system solutions
- Operational standards
The system functional requirements are determined from the
customer system technology request and/or specification.
© 2010 Joseph J Simpson, System Concepts, LLC 16
 Technology Transition Example
Integration, Initialization, and Checkout

Given a bio-chemical reactor design that was designed,

manufactured and shipped to an installation site
• Three reactor sections: batch reactor, power, and control sections
• Assembled system (integration); initialized system; system failed…
• Started trouble shooting programmable logic controller and system
sensors (for oxygen, CO2, and dissolved oxygen)
• Sensor reading variability was greatly reduced by placing the
sensors in a temperature controlled environment (small refrigerator)
• Strip chart variations were traced to proximity and schedule of diesel
electric trains. When a diesel electric locomotive passed the
installation, the chart needles would literally “go off the chart”
• Attention to the relevant environmental factors at the installation site
provided the key to creating an effective operational system`

© 2010 Joseph J Simpson, System Concepts, LLC 17

 Technology Transition Example

Given a ground vehicle with the requirement to locate, identify

and classify specific types of physical objects at a given
range with a given probability of success
• First the system level (vehicle level) requirement must be
evaluated, decomposed and assigned to system segments and
then to subsystems and components.
• A technical budget must be designed to specifically allocate the
controlling technical performance measures to each of the
components and subsystems. The technical budget also includes a
technical measure reserve or margin amount that is available for
allocation as necessary at the system level.
• If all of the technical budget (including margin) is allocated to the
sensor component then total system cost may be increased
because of segment and system level considerations.

© 2010 Joseph J Simpson, System Concepts, LLC 18

 Technology Transition Example

Given the selection of a optical sensor that uses mature optics

technology, analog electric circuits and propriety software
• Mass and weight associated with optical sensors creates the need
to suppress and isolate vibrations in the operational environment
• Analog circuits create the need for a digital to analog interface
• Propriety software drives the need for a new software to interface
with the existing software.
A sensor solution that employed less weight, direct digital
circuits and open software architecture would reduce the total
system design and operation cost. All aspects of the system,
process integration, logistical support, and operational
effectiveness must be considered in the transition of
technology to any given target.

© 2010 Joseph J Simpson, System Concepts, LLC 19

 Rapid Technology Development

Need an organizational level plan and process to address

technology development and packaging for specific targets:
• Understand the customer SE process needs
• Understand the customer logistics and operational needs
• Establish techniques that create the necessary design and
support artifacts
• Understand the operational environments
• Create an adaptable technology ‘packaging’ capability

Recognize that different organizations need different types

of support
Recognize that different operational environments need
different technology ‘packaging’ techniques

© 2010 Joseph J Simpson, System Concepts, LLC 20

 Summary

Systems Engineering and Integration are organizational level

activities that, while closely connected, vary in detail and
application from organization to organization.
Technology Readiness Levels are a useful general metric,
but must be tailored for specific application in any given
context.
Connecting Technology Readiness Levels with a specific
Systems Engineering project activity creates operational
tension because the two process are focused on different
aspects of technology and systems development
Development and application of an adaptive technology
production process will increase the probability of the
development and deployment of successful systems.

© 2010 Joseph J Simpson, System Concepts, LLC 21

 Questions?

1- Good Question

2- Excellent Question

3- Interesting Question

© 2010 Joseph J Simpson, System Concepts, LLC 22

 Backup

© 2010 Joseph J Simpson, System Concepts, LLC 23

 Systems Engineering - Definition

Systems Engineering (SE) is an interdisciplinary approach

and means to enable the realization of successful systems.
It focuses on defining customer needs and required
functionality early in the development cycle, documenting
requirements, and then proceeding with design synthesis
and system validation while considering the complete
problem: operations, cost and scheduling, performance,
training and support, test, manufacturing, and disposal.
SE considers both the business and technical needs of all
customers with the goal of providing a quality product that
meets the user needs.

(INCOSE SE Handbook, v. 3.2, January 2010)

© 2010 Joseph J Simpson, System Concepts, LLC 24
 Systems Integration - Definition

“Systems Integration – is the art and science of

facilitating the marketplace of ideas that connects the
many separate solutions into a system solution. Systems
integration is a component of the systems engineering
process that unifies the product components and the
process components into a whole. It ensures that the
hardware, software, and human system components will
interact to achieve the system purpose or satisfy the
customer's need.”

(Jeffrey O. Grady, System Integration, 1994)

© 2010 Joseph J Simpson, System Concepts, LLC 25

 Technology Readiness Levels - Definition

Technology Readiness Levels (TRLs) – provide a scale

composed of nine measures that indicate a program's risk and
potential for success. These nine levels are:
TRL1: Basic principles observed and reported
TRL2: Technology concept and/or application formulated
TRL3: Analytical and experimental critical function proof-of-concept
TRL4: Component, breadboard validation in laboratory environment
TRL5: Component and/or breadboard validation in relevant
environment
TRL6: System model, prototype demonstrated in a relevant
environment.
TRL7: System prototype demonstration in a relevant environment.
TRL8: System completed and qualified through test and
demonstration
TRL9: System verified through successful mission operations
© 2010 Joseph J Simpson, System Concepts, LLC 26
 Presentation Point of View and Organization

These observations provide a point of view based on:

• The type of technology development performed at PNNL
• The general tension between technology development
and major systems acquisition and engineering activities
• The assumption that PNNL will develop a technology
product that will be deployed to different customer types
• The assumption that the technology product will be
deployed in a variety of environments by the same or
different customers

© 2010 Joseph J Simpson, System Concepts, LLC 27

 Systems Engineering Approach

The systems engineering approach is based on the following:

1) A structured and disciplined process that defines problems
before seeking solutions
2) A systematic search for solutions that examines tradeoffs
between alternative solution sets
3) A traceable and disciplined integration process that verifies
that the product system meets the original requirements and
performs the needed functions
4) An effective information management system that can
provide each team member and the customer with any
information concerning the system that has been generated.

(Brian W. Mar, “Back to Basics,” 1992)

© 2010 Joseph J Simpson, System Concepts, LLC 28
 Validation and Verification

System validation confirms that the system, as built (or as it will be

built), satisfies customer’s needs (i.e., “you built the right thing”).
System verification addresses whether the system, its elements, and
its interfaces satisfy their requirements (i.e., “you built it right”).
Basic verification activities are:
Inspection: an examination of the item against applicable documentation to
confirm compliance with requirements.
Analysis: use of analytical data or simulations under defined conditions to show
theoretical compliance.
Demonstration: a qualitative exhibition of functional performance, usually
accomplished with no or minimal instrumentation.
Test: an action by which the operability, supportability, or performance capability
of an item is verified when subjected to controlled conditions that are real or
simulated.
Certification: verification against legal or industrial standards by an outside
authority without direction to that authority as to how the requirements are to be
verified.
Adapted from INCOSE SE Handbook v. 3
© 2010 Joseph J Simpson, System Concepts, LLC 29
 Verification Activity Design

Design of the verification activity involves choosing the most cost-

effective mix of simulations and physical testing, and integrating
test results to avoid unnecessary redundancy
Four basic test categories are:
Development Test: Conducted on new items to demonstrate proof of concept
or feasibility
Qualification Test: Conducted to prove the design on the first article produced,
has a predetermined margin above expected operating conditions, for instance
by using elevated environmental conditions for hardware
Acceptance Test: Conducted prior to transition such that the customer can
decide that the system is ready to change ownership status from supplier to
acquirer
Operational Test: Conducted to verify that the item meets its specification
requirements when subjected to the actual operational environment

Adapted from INCOSE SE Handbook v. 3

© 2010 Joseph J Simpson, System Concepts, LLC 30