Dr' R'Siriram 1

1
Systems Engineering

• MECN 7012
• Session 4
• 14 August 2007

2
System Engineering
Review The System Engineering Process Conceptual
Systems Design
3
Systems Experience
Experience is the hardest kind of teacher. It
gives you the test first and the lesson
afterward
4
The System Perspective Cube
Specific Time and Cost Goals
6
IOC Initial Operational Capability
2
Time Life Cycle Phase
IOC Date
Unit Production Cost
Life Cycle Costs
Development Costs
Development Dates
Deploy/Recycle
Major System
Production
Development
Demonstration
Concept
Sub System Components
Constraining Conditions to Apply
Hardware
Software
4
Documentation
Actions to Perform
People
Tools/Facilities
(Technical)
Hierarchical
5
1
(Analyses)
3
Physical
5
The System Perspective Cube - Example
The Impossible Dream
Not directly impact present mainstream activity
unless easy modification with large UPC reduction
is found
6
IOC Date Jan 1-88
UPC 35K Goal
LCC N/A
Flight Control Computer (FCC)
Dev Costs (54K)
Dev Dates 8/12/88
Major System
Report - 12/25/88
Alternates - 11/88
Baseline - 10/88
Suggestions - 1988
Sub System
Implement - 1989
Plan -9/88
(54K to do this Study)
Constraining Conditions to Apply
Study -8/88
Aircraft
Components
2
Deploy/Recycle
Report 12/25/88
Production
Development
Flight Control Computer
Demonstration
Concept
4
(Technical)
Physical
Physical
3 FCCs
Not directly applicable, but hardware is
indirectly driven by asynchronous software
system (DoD-STD-2167 called out)
1. Study Procurement, Spec SOW, IDC Contract
Hardware
Actions to Perform
Software
Documentation
2. Study our System Spec, Design Dwgs
People
Tools/Facilities
3. Baseline Present UPC Model
5
4. Establish UPC reduction Plan and Methods
867C0003 REV B, 16 April 1988
Green Team - Ray - Maureen - Jack - Customer
(Program Mgr)
5. UPC Suggestion System and Analysis
6. Establish 3 Alternate FCC System
Implementations
7. Provide Recommendations 1 - Mod Present
System 2 - Mod Procurement Spec 3 - Mission
Functional Value Engineered System
Green Bay
6
Mistakes in Perspective

• Success comes from wisdom --
• Wisdom comes from experience --
• Experience comes from Mistakes!

7
The Three Laws of Systems Engineering

• Everything Interacts with Everything Else
• - Decomposition -
• Everything Goes Somewhere
• - Interfaces -
• There is No Such Thing as a Free Lunch
• - Trade Studies / Decision Analysis -

8
Conceptual Design
The beginning is the most important part of
the work
Plato, 4th Century, B.C.
9
Mission Analyses
Conducted to gain an understanding of the System
Requirements
10
Decomposition or Design Criteria
Definition of Need
System Level
Requirements Analysis (Reference Figure 2.4,
Block 0.1)

• Feasibility Analysis
• Operational Requirements
• Maintenance and Support Concept
• Measures of Effectiveness
• (Technical Performance Measures)

Design Evaluation

• Identification of Design-Dependent Parameters
  (DDPs)
• Analysis and Trade-Off Studies
• Synthesis and Evaluation

Sub System Level
Feedback
Requirements Analysis (Reference Figure 2.4,
Blocks 1.1 and 1.2)

• Functional Analysis and Allocation
• Measures of Effectiveness
• (Technical Performance Measures)

Design Evaluation

• Identification of (DDPs)
• Analysis and Trade-Off Studies
• Synthesis and Evaluation

11
Design Consideration Hierarchy
First-Order Consideration
System Value
Economic Factors
Technical Factors
Second-Order Considerations
Life Cycle Cost
System Effectiveness
Revenues

• Performance
• Operation Availability
• Dependability
• Producibility
• Supportability
• Disposability
• Others

• Research and Development Cost
• Production Investment Cost
• Operation/Utilization Cost
• Maintenance and Support Cost
• Retirement and Disposal Cost

Third-Order Considerations

• Research Cost
• Design Cost
• Data Cost
• Contractor Cost
• Manufacturing Cost
• Test and Evaluation Cost
• Operating Cost
• Maintenance Cost
• Recycle Cost

• Size, weight, and shape
• Speed of performance
• Reliability
• Maintainability
• Ergonomics
• Safety
• Flexibility (Adaptability)
• Pollutability
• Others

Fourth-Order Considerations

• Accessibility
• Aesthetics
• Control and Displays
• Energy Consumption
• Facilities

• Handling
• Interchangeability
• Inventory Levels
• Labeling
• Logistics Pipeline

• Mounting
• Packaging
• Personnel Skills
• Security
• Serviceability

• Shelf Life/Storage
• Testability/Diagnosis
• Transportability
• Utilities
• Other

Fifth-Order Considerations
12
Design Synthesis, Analysis and Evaluation
0
Need, Functions, and System Requirements
C u s t o m e r
R e s e a r c h and T e c h n o l o g i e s
T e c h n o l o g i e s
Top Down Approach
2
1
Design Team
Design Synthesis
Design Decision Schema
Candidate Design
4
3
Estimation/Prediction
DIPs
Design Evaluation
Bottom Up Approach
DIPs
5
Preferred Candidate
Physical and Economical Databases
Existing Components, Parts and Subsystems
13
Implementing Systems Engineering
Commitment to Technology, Configuration,
Performance, Cost, etc.

100 75 50 25 0
Cost Incurred
System Specific Knowledge
Ease of Change
Conceptual Preliminary Design
N EED
Detail Design and Development
Product Use, Phase-out and Disposal
Production and/or Construction
14
SRA True or False
SRA

• Is done only at the beginning of the project
• Can be applied to buying a house
• Must be applied to all projects
• Must be recorded on all projects by the Systems
  Engineer down to the component level

15
Requirements Definition
Identification of Need
System Feasibility Analysis
Advance System Planning
Research
Technology Development and Application
System Requirements Analysis

• Operational Requirements
• Maintenance and Support Requirements
• Technical Performance Measures (TPMs)
• Functional Analysis and Allocation (System Level)
• Analysis, Synthesis, and Evaluation

System Specification
Conceptual Design Review
Preliminary System Design (Chapter 4)
Fifth-Order Considerations
16
Functional Analysis Activity Diagram
Required Inputs
Activity
Typical Outputs
Functional Hierarchical Diagrams
Life
Functional Analysis
Sortie
Functional Block Diagrams
Mission Analysis
(What are all the actions of persons and things
required to perform the mission?)
Functional Block Diagrams
Problem to Solve
State Diagrams
A Skill Survey
A Specification Tree
A Program
A Program Management Plan (for the Management
Mission)
Feedback
Reviews
17
Functional Analysis - Flow Diagram
Aileron

• Sensors
• Rate (P, R, Y)
• Air Data
• Altitude
• Accel-N
• Position
• Other

• Inputs
• Processing

Processing

• Output
• Processing

Actuators
Rudder
Processing
Elevator

• Modes

• D/A

• Interfaces
• Select Modes
• Override
• Pilot Wheel
• Power
• Propulsion
• Other

Attributes Analysis
Support Functions

• Maint

• WT
• PWR
• MTBF

Feedback

18
Quality Function Deployment (QFD)
A team approach to ensure that the voice of the
customer is reflected in the ultimate design
19
Systems Engineering MECN 7012 Systems Design
Process (Cont.) Session 4 Chapter 3 System
Design -2 Pages 53 - 92
20
MECN 7012

• Complete SRA and Functional Analysis Discussion
• Heuristics in Systems Management and Engineering
  Discussion
• Art of Architecting - Part 1

21
SRA
Action Function Element
Activity
Inputs
Outputs
(Control Feedback)
22
SRA
PERT
Final Parts Order
All Parts In
Order Long Lead Parts
2 Mo
6
7
2
2 Days
1 Wk
Dwgs Ready
2 Wks
2 Wks
2 Wks
1 Wk
10
11
5
9
3
1
8
2 Wks 1 Mo 2 Mo
Engr SignOff
Start Build
Build Complete, Start Test
Test Complete
Design Review
Write Specification
1 Wk
4
Prototype Test Plans
23
System Requirements Analysis
Quality Function Deployment (QFD)

• May be used as a tool to support SRA and Mission
  Analysis
• Provides a means by which to translate the
  Customers requirements into the appropriate
  technical requirements needed to provide the
  Customers wants (in QFD these are known as
  WHATS)

24
System Requirements Analysis
QFD Goals

• Establish who the customers are and then
  determine what the customers want (WHATS)
• Determine how to satisfy the Customers WHATS.
  (In QFD these are referred to as HOWS)

25
System Requirements Analysis
Basic QFD Matrix
Quality Characteristics (HOWS)
Customer Demands (WHATS)
26
System Requirements Analysis
The QFD Matrix

• Helps put the requirements at the top level and
  attributes of the implementation on a single
  piece of paper
• Correlation analyses can be done
• Attribute balancing and prioritization can be
  done
• Output becomes part of the Development
  Specification

27
Advanced Systems Management
Detail Design and Development
Production/ Construction
Operational Use and System Support
Conceptual Design
Preliminary Design
Ret.
Need Identification Requirements Analysis
Operational Requirements Maintenance and Support
Concept Evaluation of Feasible Technology
Applications Selection of Technical Approach
Functional Definition of System System/Program
Planning
Functional Analysis Requirements Allocation
Trade-off Studies Synthesis Preliminary Design
Test and Evaluation of Design Concepts (Early
Prototyping) Acquisition Plans Contracting
Program Implementation Major Suppliers and
Supplier Activities
Subsystem/Component Design Trade-off Studies and
Evaluation of Alternatives Development of
Engineering and Prototype Models Verification of
Manufacturing and Production Processes
Develo0pmental Test and Evaluation Supplier
Activities Production Planning
Production and/or construction of System
components Supplier Production Activities
Acceptance Testing System Distribution and
Operation Developmental/Operational Test and
Evaluation Interim Con- tractor Support System
Assessment
System Operation in the User Environment
Sustaining Maintenance and Logic Support
Operational Testing System Modifications for
Improvement Contractor Support System
Assessment (Field Data Collection and Analysis)
System/Program Milestones
Milestone I
Milestone II
Milestone III
Milestone IV
Functional Baseline
Allocated Baseline
Product Baseline
Updated Product Baseline
R E T I R E M E N T
System Specification (TYPE A)
Development, Process, Product, Material
Specifications (TYPES B, C, D and E)
Process/Product, Material Specifications (TYPES
C to E)
System Management Plan
System Engineering Management Plan (SEMP) Test
and Evaluation Master Plan (TEMP) Conceptual
Design Review (System Requirements Review)
System Design Review
Equipment/Software Design Reviews
Critical Design Review
System Engineering Requirements
N EED
Modifications for Improvement
Modifications for Improvement
System Level
Subsystem Level
Component Level
0.1
1.1
2.1
3.1
4.1
Requirements Analysis
Detailed Design
Proposed Design Modification's)
Proposed Design Modification's)
Refined Functional Analysis
0.2
1.2
2.2
3.2
4.2
Functional Analysis
Detailed Synthesis
Refined Requirements Allocation
Synthesis of Modification
Synthesis of Modification
0.3
2.3
1.3
Requirements Allocation
Evaluation (Prototype Models)
3.3
4.3
0.4
2.4
Detailed Trade-Off Studies
Prototype Modifications
Prototype Modifications
Trade-Off Studies
1.4
0.5
Types B to E Specifications
2.5
3.4
4.4
Synthesis (CI)
Test and Evaluation (Production Model)
Test and Evaluation (Operational Model)
Synthesis
1.5
2.6
0.6
Evaluation (Engineering Models)
3.5
4.5
Design Review's)
feedback
Evaluation
0.7
1.6
Incorporation of Modification's)
Incorporation of Modification's)
Type A Specification
Type B Specification
0.8
1.7
4.6
3.6
Configuration Item Reviews
System Evaluation (Field Assessment
feedback
feedback
Design Review's)
Design Review's)
feedback
feedback
28
Stresses in Systems Engineering
Function System Requirements Performance
Specification Human Needs Complexity New
Technology Top Down Plan Conservative
Design Continuous Evolution Minimal
Interfacing Process Characterization Avoid
Complexity Low Level Decisions Specialized
Manufacturing
Flexible Manufacturing Strict Process
Control Manage Complexity Process
Revolution Tight Integration Product
Stability Risk of Overdesign Bottom Up
Implementation Familiar Technology Simplicity Affo
rdability Strict Acceptance Criteria Environmental
Imperatives Form
Performance
Fit Balance Compromise
Cost and Schedule
29
Designers Tools
Engineers Approach their design problems using
analysis and optimization, powerful and precise
tools derived from the scientific method and
calculus
Architects Approach their qualitative problems
using guideline, abstractions, and pragmatics
generated by lessons learned from experience,
i.e. heuristics
30
Heuristics
Abstractions of experience, trusted, non-analytic
guidelines for treating inherently unbounded,
ill-structured problems
Used as aids to decision making, value judgments,
and assessments
References
The Art of Systems Architecting, Rechtin and
Maier, CRC Press, 1997, pp 23-36 and App A
31
Heuristic Tools

• Dont assume that the original statement of the
  problem is necessarily the best, or even the
  right one
• In partitioning, choose the elements so that they
  are as independent as possible that is, elements
  with low external complexity and high internal
  complexity
• Simplify, Simplify, Simplify
• Build in and maintain options as long as possible
  in the design and implementation of complex
  systems. You will need them

32
Heuristic Tool List (1)
Multitask Heuristics

• Performance, cost, and schedule cannot be
  specified independently. At least one of the
  three must depend on the others
• With few exceptions, schedule delays will be
  accepted grudgingly cost overruns will not

33
Heuristic Tool List (2)

• One persons architecture is another persons
  detail
• In general, each system level provides a context
  for the level(s) below
• Particularly for social systems, its the
  perceptions, not the facts, that count
• In introducing technological and social change,
  how you do it is often more important than what
  you do

34
Heuristic Tool List (3)
Scoping and Planning

• Success is defined by the beholder
• No complex system can be optimum to all parties
  concerned, nor all functions optimized
• The most dangerous assumptions are the unstated
  ones

35
Heuristic As Tools (4)
Modeling

• If you cant analyze it, dont build it
• A model is not reality
• Constants arent and variables dont
• The eye is a fine architect
• A good Solution somehow looks nice

36
Heuristic As Tools (5)
Trades, Options and Choices

• In any resource-limited situation, the true value
  of a given service or product is determined by
  what one is willing to give up to obtain it
• If trade results are inconclusive, then the wrong
  selection criteria were used

37
Heuristic As Tools (6)
Aggregating

• Group elements that are strongly related to each
  other, separate elements that are unrelated
• Choose a configuration with minimal
  communications between the subsystems
• System structure should resemble functional
  structure

38
Heuristic As Tools (7)
Decompositioning

• Do not slice through regions where high rates of
  information exchange are required
• The greatest leverage in architecting is at the
  interfaces
• Organize personnel tasks to minimize the time
  individuals spend interfacing

39
Heuristic As Tools (8)
Integrating

• Relationships among the elements are what give
  systems their added value
• Just as a piece and its template must match, so
  must a system and the resources which make, test,
  and operate it
• Contain excess energy as close to the source as
  possible

40
Heuristic as Tools (9)
System Integrity, Quality, and Vision

• As time to delivery decreases, the threat to
  functionality increases
• Within the same class of products and processes,
  the failure rate of a product is linearly
  proportional to its cost
• Mistakes are understandable, failure to report
  them is inexcusable

41
Heuristic as Tools (10)
Performance, Cost, Schedule and Risk

• If you think your design is perfect, its only
  because you havent shown it to someone else
• Proven and State of the Art are mutually
  exclusive qualities
• The first quick look analyses are often wrong

42
Heuristic as Tools (11)
Evolving, Modifying, and Adapting

• The team that created and built a presently
  successful product is often the best one for its
  evolution - but seldom for creating its
  replacement
• If you dont understand the existing system, you
  cant be sure youre re-architecting a better one

43
System Architecting Topics

• Builder-Architected Systems
• Manufacturing Systems
• Social Systems
• Software Systems

44
Systems Architecting
No system can survive that doesnt serve a
useful purpose - Chief Architect, F-16
Fighter Program
45
Builder-Architected Systems
Form First Paradigm

• An evolution of an existing architecture - a
  natural inclination of successful builders
• A preconceived architecture is maintained with
  few modifications until an essentially completed
  system is presented to potential buyers

46
Builder-Architected Systems
Form First Systems

• Greatest risk are technology driven systems that
  create major qualitative changes in system-level
  behavior, changes in kind rather than degree
  (Example - Douglas vs Boeing)

47
Builder-Architected Systems
Form First Systems

• Second greatest risk is in not recognizing that
  before they are completed, technology - driven
  architectures will require much more than
  replacing, one at a time, components of an older
  technology for those of a newer one
• (Example - Automobile Electronics)

48
Builder-Architected Systems
Uncertainty of End Purpose

• May result in serious error in decisions
  effecting system design, development, and
  production
• Builder-architected systems are often solutions
  looking for a problem

49
Builder-Architected Systems
Reducing the Risks

• Build in and Maintain options
• Use an open architecture. You will need it once
  the market starts to respond
• Pause and Reflect

50
Builder-Architected Systems
Risk Management of System Critical Technologies

• Schedule a series of intermediate goals to be
  reached by precursor or partial configurations
• Do the hard parts first
• The probability of an untimely failure increases
  with the weight of the brass in the area

51
Builder-Architected Systems
The What Next Quandary

• A start-up companys lack of a successor to its
  first product caused by a lack of resources in
  its early, profitless years to support more than
  one research and development effort
• A well established company which had been
  successfully supplying a market valued system was
  unsuccessful in winning contracts for its
  follow-on

52
Builder-Architected Systems
Controlling the Critical Features

• Successful architectures are proprietary, but
  open. Maintain control over the key standards,
  protocols, etc., that characterize them but make
  them available to others who can expand the
  market to everyones gain. Theres nothing like
  being the first success.

53
Builder-Architected Systems
Abandonment of an Obsolete Architecture

• To avoid being superseded architecturally
  requires a strategy to set to one side or
  cannibalize that first architecture (including
  the organization) and to take preemptive action
  to create a new one

54
Builder-Architected Systems
Creating Innovative Teams

• Members should tend toward systematic and
  strategic analysis in solving problems
• - Shared Vision
• - Diversity in Specialization
• - Dedication and Momentum

55
Builder-Architected Systems
Rebasic Research

• New technologies enable new architectures
• New architectures, driven by perceived purposes,
  sponsor more basic research and technology
  development

56
Builder-Architected Systems
Heuristics for Technology-Driven Systems

• An insight is worth a thousand market surveys
• Success is defined by the customer, not the
  architect
• In architecting a new program, all the serious
  mistakes are made in the first day
• The most dangerous assumptions are the unstated
  ones
• The choice between products may well depend upon
  which set of drawbacks the users can handle best
• As time to delivery decreases, the threat to user
  utility decreases

57
Builder-Architected Systems
Heuristics for Technology-Driven Systems
(Continued)

• If you think your design is perfect, its only
  because you havent shown it to someone else
• If you dont understand the existing system, you
  cant be sure you are building a better one
• Do the hard parts first
• Watch out for domain-specific systems. They may
  become traps instead of useful system niches,
  especially in an era of rapidly developing
  technology
• The team that created and built a presently
  successful product may often be the best one for
  its evolution- but seldom for creating its
  replacement