00 Introduction to Systems Engineering.ppt

Introduction to Systems Engineering

1. Engineering
Management
Module 1
Introduction to Systems Engineering
MSE607B
Systems Engineering

2. Introduction to Systems Engineering
Topics
•Importance of systems engineering in engineering
practice
•Subject of “systems” in general
•Origins of systems engineering

3. Learning Objectives
By the end of this module, you will be able to:
•Explain the need for creating systems and what
requirements they address
•Define some terms and characteristics of systems
•Evaluate systems based on their ability to fulfill specific
needs
•Discuss what activities management perform to
support the system engineering process

4. The Current Environment
Requirements are constantly changing
Greater emphasis on total systems
Structures become more complex
Life cycles of systems are extended; life cycles for
technologies are shorter
Utilize commercial off-the-shelf (COTS) equipment
Increasing globalization
Greater international competition
Increase in outsourcing
Decrease of available manufacturers
Higher overall life cycle costs

5. The Need for Systems Engineering
System engineering addresses various needs to be
more effective and efficient in:
•Development and acquisition of new systems
•Operation and support of systems already in use
Need to consider key concepts and definitions

6. Why Systems Engineering?
Mars Climate Orbiter
•Lost in September 1999
•Root cause of loss was failed
translation of English units into
metric units in a segment of
ground-based, navigation-
relation mission software
•"The problem here was not the
error, it was the failure of
NASA's systems engineering,
and the checks and balances in
our processes to detect the
error. That's why we lost the
spacecraft.“ – Dr. Edward Weiler

7. Definition of System
Generated from the Greek word systēma
•An “organized whole”
Merriam-Webster Dictionary
•A regularly interacting or interdependent group of items
forming a unified whole
Another definition
•Any set of interrelated components working together
with the common objective of fulfilling some designated
need

8. Additional Definitions
International Council on Systems Engineering
(INCOSE)
•An interdisciplinary approach and means to enable the
realization of successful systems
MIL-STD-499
•An interdisciplinary approach that encompasses the
entire technical effort to evolve and verify an integrated
and life cycle balanced set of people, products, and
process solutions that satisfy customer (stakeholder)
needs

9. Additional Definitions (cont.)
General Characteristics
•Complex combination of resources
•Contained within some form of hierarchy
•May be broken down into subsystems and related
components
•Allows for simpler approach and analysis of the system and
its functional requirements
•Must have a purpose
•Functional
•Able to respond to identified need
•Able to achieve its objective
•Cost-effective
•Must respond to an identified functional need

10. Origins of Systems Engineering
Foundation in the Natural and Physical Sciences
Driven by:
•Complex Systems
•Military, Space, Aerospace
•Longer Life Cycles
•Systems Failures

11. Origins of Systems Engineering
(cont.)
Example: Transportation
System
•Physical Features
•Main lanes, ramps,
connectors, and carpool lanes
•Operational controls
•Speed limits, regulatory
restrictions, and management
controls
•All components must work
together to achieve the
common objective

12. Multiple Disciplines
System Engineer
•Responsible for integration of multiple components into
one system
•Must have knowledge in:
•Mechanical
•Electrical
•Computer Science
•Civil
•Chemical Engineering
Cross-functional, multi-discipline engineers

13. Elements of a System
Primary Components
•Physical objects, concepts, processes, feelings, and
beliefs
System Boundary
•Encompasses components that can be directly
influenced or controlled
Environment
•Factors that have influence on the effectiveness of a
system, but cannot be controlled

14. Elements of a System (cont.)
Environment
System Boundary
Main Lanes
Access Roads
Guidance/Navigation
HOV
Enforcement
Operational Control
Ramps and Connectors
Weather/
Season
Vehicle
Characteristics
Driving
Population
Traffic Composition
Origins/Destinations
Example: Freeway System

15. Types of Systems
Natural Systems
•Came into being through natural processes
•Examples: River System and Energy System
Man-Made Systems
•Developed by human beings
Physical and Conceptual Systems
Static and Dynamic Systems
Closed and Open-Loop Systems

16. Costs of New System Development
Cost
Time
100%
80%
60%
40%
20%
0%
Conceptual
& Preliminary
Design
Detailed
Design &
Integration
Construction
or
Production
Use,
Refinement
& Disposal
Cost
Time
100%
80%
60%
40%
20%
0%
Conceptual
& Preliminary
Design
Detailed
Design &
Integration
Construction
or
Production
Use,
Refinement
& Disposal
Cost
Committed
Cost
Incurred

17. When Things Go Wrong
Easy to say “design was
bad”
What is the “right” way to
do it?
•Most systems have to be
modified in order to ensure
better performance
Systems engineering is
about learning from
experience

18. Three Laws of Systems Engineering
Everything interacts with everything else
•Anything done to the system creates impacts that ripple
throughout the system
Everything goes somewhere
•When working with a system, one deals with multiple
interfaces
•Account for interface and follow where it goes
There is no such thing as a free lunch
•Everything comes at a price

19. Who Does Systems Engineering?
Military/Govt Companies and Agencies
•Raytheon, Eaton, Parker, Boeing, Airbus, NASA
International Council on Systems Engineering
(INCOSE)
•Non-profit membership organization founded in 1990
International Centers for Telecommunication
Technology (ICTT)
•Specializes in solving its clients’ complex systems
problems
All Companies and Engineers

20. Characteristics of a System
Engineer
Big picture person
Focus on the objectives of the end user/stakeholder
Be able to take a broad perspective.
Leave nothing out and pay attention to details
Be able to consider and address all contingencies

21. A Mental Model for Systems
Engineering
Systems engineering is like
peeling an onion
•Outer Layers
•System description more abstract
and contains low level details
•Inner Layers
•System description less abstract
and contains more design
requirements and elements

22. What Systems Engineers Do
Key Foundations
•Systems Design
•Systems Analysis
Tools and Methods
Project Management
High Level Design
Planning, Modeling
Quality and Statistical
Analysis
Decision/Risk
Analysis
Simulation, Testing
Configuration Mgmt
Six Sigma, DFSS

23. Systems Engineering Process
Mechanization
(construction)
Systems
Approach
Problem Definition
(planning)
Analytical Solution
(design)
Verification
(operations)

24. Expertise on the Systems Team
Management
SE
Process
Domain/
Stakeholders
Technology
(Engineering
Disciplines)
Modeling,
Simulation,
Analysis

25. Key Terminology
Life Cycle
Requirements
Functional vs. Physical
Qualification - Verification/Validation
The ‘Ilities’
Risk

26. System Life Cycle
Includes entire spectrum of activity
•Identification of need through system design and
development
•Production and/or construction
•Operational use
•Sustaining maintenance and support
•System retirement
•Material disposal

27. System Life Cycle Stages
1.Development
2.Manufacturing
3.Deployment
4.Training
5.Operations, maintenance, support
6.Refinement
7.Retirement
Autos – 5 to 10 Years
B-52 Bomber – 50 Years

28. Systems Failures
Result from:
•Incorrect assumptions
•Oversights
•Mistakes
Example
•Columbia Space Shuttle
•Miscalculated seriousness of
damage inflicted on isolation
panels of orbiter during lift off

29. Systems Failure Example:
Firestone Tires on Ford Explorer
Low tire air pressure
175 deaths and 700 injuries
20 million tires replaced
Cost of $6 billion
Confluence of events in extreme conditions

30. Systems Failure Example:
Firestone Tires on Ford Explorer (cont.)
Failure Factor Design Mfg Operation Service
Tread Notch Stress●
Rubber ●
Inflation Specification●
Tire pressure ●
Temperature ●
Repair of Punctures ●
Years !!

31. Systems Engineering Process:
“V” Model
Development standard for IT systems of Federal
Republic of Germany
Standardizes activities and products in development
of IT systems
Guarantees
•Improvement in quality
•Curtailment of costs
•Improved communication between customers and
contractors

32. Understand User
Requirements, Develop
System Concept and
Validation Plan
Develop System
Performance Specification
and System
Validation Plan
Expand Performance
Specifications into CI
“Design-to” Specifications
and CI Verification Plan
Evolve “Design-to”
Specifications into
“Build-to” Documentation
and Inspection Plan
Fab, Assemble and
Code to “Build-to”
Documentation
Inspect
“Build-to”
Documentation
Assemble CIs and
Perform CI Verification
to CI “Design-to”
Specifications
Integrate System and
Perform System
Verification to
Performance Specifications
Demonstrate and
Validate System to
User Validation Plan
. . .
Time
Understand User
Requirements, Develop
System Concept and
Validation Plan
Develop System
Performance Specification
and System
Validation Plan
Expand Performance
Specifications into CI
“Design-to” Specifications
and CI Verification Plan
Evolve “Design-to”
Specifications into
“Build-to” Documentation
and Inspection Plan
Fab, Assemble and
Code to “Build-to”
Documentation
Inspect
“Build-to”
Documentation
Assemble CIs and
Perform CI Verification
to CI “Design-to”
Specifications
Integrate System and
Perform System
Verification to
Performance Specifications
Demonstrate and
Validate System to
User Validation Plan
. . .
Time
Design Engineering
Systems Engineering
Requirements,
Documents,
Specifications
Models
Interfaces
Risk,
The Ilities
How
Built Right?
Right System?
Quality
Reliability
Usability
Producibility
Systems Engineering Process:
“V” Model (Cont.)

33. Systems Engineering Process:
“Waterfall” Model (cont.)
Software development model
Standardized, documented
methodology
•Document system concept
•Identify and analyze requirements
•Break the system into pieces
•Design each piece
•Code the system components and test
individually
•Integrate the pieces and test the system
•Deploy the system and operate it
Widely used on large government
systems
Systems
Requirements
Software
Requirements
Preliminary
Design
Detailed
Design
Coding and
Debugging
Integration
and Testing
Operations and
Maintenance

34. Systems Engineering Process:
“Spiral” Model

35. Systems Engineering Process:
“Spiral” Model (Cont.)
Advantages
•Estimates (budget
and schedule) get
more realistic as work
progresses.
•More able to cope
with the (nearly
inevitable) changes
that software
development
generally entails
Disadvantages
•Estimates (budget
and schedule) are
harder at the outset

36. The Stakeholder
Internal or external customer
Member of a group who will be involved with
the system
•Users, purchasers, maintainers, administrators
Relevant Stakeholder
•Describes people or roles designated in the
plan for stakeholder involvement

37. Requirements
Key activity in system development
Define
•Needs and wants of the stakeholders
•What the system must do
Condition or capability
•To solve a problem
•To satisfy a contract, standard, specification
Most complex and crucial part in system
development
Bridge between application demands and solutions

38. Requirements (cont.)
Four Categories
•Input/Output
•Interface between the system and other systems/components
•Technology/System Wide
•Technology being used throughout the system and its
components
•Trade Offs
•Solution options and the selections made
•Qualification
•What demonstrates compliance of the system to the
requirements

39. Requirements (cont.)
Typical Requirements Analysis
•Identify source material
•Identify stakeholder needs
•Identify initial set of requirements (top-level functional,
non-functional, performance and interface
requirements)
•Establish design constraints
•Define effectiveness measures
•Capture issues/risks/decisions

40. Functional Models
Transforms inputs into outputs
Describes what happens
•Problem defined by the requirements analysis in
clearer detail
Identify and describe the desired functional behavior
of each system element or process
Typically performed without consideration of a
specific design solution

41. Functional Analysis
Define operational scenarios
Derive system behavior model
•Reflect control and function sequencing, data flow and
input/output definition
Derive functional and performance requirements
•Allocate to behavior model
Define functional failure modes and effects

42. Interfaces
Functions connect to other functions and systems via
interfaces
Standards of Interfaces
•Used in commercial applications
System failures often occur at an interface

43. Architectures
Gives the functionality,
connectivity, and structure
of the system
Used to identify the
interfaces
Provide the basis for the
system integration process
Operational
Concept
Functional
Architectu
re
Operational
Architecture
Interface
Architecture
Physical
Architectu
re

44. Qualification
Demonstrates that system requirements have been
met
Covers the system requirements
•System/subsystem specifications
•Associated interface requirements specifications
Verification of a system ensures that:
•Right system was built right
•Conformance to the system specifications
Validation of a system ensures that:
•Right system was built
•Stakeholder acceptance

45. The “ilities”
System design
•Meets requirements
•Achieved desired
outcomes
Reliability
Quality
Usability
Upgradeability
Flexibility
Manufacturability
Availability
Serviceability
Maintainability
Interoperability

46. Reliability
Construction of a model that represents the times-to-
failure of the entire system
•Based on the life distributions of the components from
which it is composed
Example
•Expressed in terms of means hours between failure
•System Reliability is 500 hrs Mean Time Between
Failure (MTBF)
•If MTBF changes to 300 hrs, then:
•More spare parts needed
•More service people needed
•More service tools and space needed

47. Risk Analysis
Analyzing and quantifying risk in:
•Technology
•Experience, Knowledge base
•Project Schedule
•Project Budget
Undesirable events are identified and then analyzed
separately
For each undesirable event, possible improvements
are formulated

48. Summary
Importance of systems engineering in engineering
practice
Subject of “systems” in general
Origins of systems engineering

49. Interactive Workshop
A system is a:
a)Group of dependent but related elements
comprising a unified whole
b)Group of independent but interrelated elements
comprising a unified whole
c)Group of elements
d)Group of components

50. “Systems Engineering” is:
a)The process of defining, developing and integrating
quality systems.
b)The process of defining and developing quality
systems.
c)The application of engineering to solutions of a
complete problem
d)The set of activities controlling overall design and
integration of interacting components to meet the
needs of stakeholders.
Interactive Workshop

51. Systems engineering requirements:
a)Stems from the Greek word requēma
b)Last activity in system development
c)Define the needs and wants of the stakeholders
d)Define the needs and wants of the engineers
Interactive Workshop

52. A “life cycle” is the entire spectrum of activity:
a)From system design and development through
retirement and material disposal.
b)From system operations through retirement and
material disposal.
c)From system design through operation and material
disposal.
d)From system development through material disposal.
Interactive Workshop

53. A “stakeholder” is a:
a)A person or group who studies systems
b)A member of a group involved with the system in
some way
c)A member of a group involved with Engineers in
some way
d)None of the above
Interactive Workshop

54. Homework Assignment
Page 44 problems
•2
•3
•4
•9
Use homework format provided in course
website
Read Chapter 2
•Pages 46-107

55. Questions? Comments?