Principles of Systems Engineering Introduction

1
Principles of Systems Engineering Introduction
Overview
2
Agenda

• Definitions of system and systems engineer
• The role of a systems engineer
• Systems engineering vs. project management
• Systems engineering functions and processes
• Requirements Development and Management
• Operations Concept
• Decomposition
• Technology Planning
• System analysis and design
• System Integration
• Resource Management
• Quality Control
• Verification and Validation

3
Definitions

• What is a System?
• A System is a set of interrelated components
  which interact with one another in an organized
  fashion toward a common purpose
• NASA Systems Engineering Handbook SP6105

4
Definitions (Continued)

• What is Systems Engineering?
• Systems Engineering is an interdisciplinary
  approach and means to enable the realization of
  successful systems.
• INCOSE Handbook

5
Definitions (Continued)

• Another Definition
• Systems Engineering is a robust approach to
  the design, creation, and operations of systems.
• NASA Systems Engineering Handbook SP-6105

6
Definitions (Continued)

• In simple terms, the systems engineering approach
  consists of
• Identification and quantification of system
  goals,
• Creation of alternative system design concepts,
• Performance of design trades,
• Selection and implementation of the best design,
• Verification that the design is properly built
  and integrated, and
• Post implementation assessment of how well the
  system meets (or met) the goals

7
Definitions (Continued)

• Engineering of Systems
• Anyone involved in engineering a system should
  exercise good systems engineering practices.

8
Twelve Systems Engineering Roles
1. Requirements Owner 2. System Designer 3.
System Analyst 4. Validation and Verification
Engineer 5. Logistics Operations Engineer 6.
Owner of the Glue among subsystems
7. Customer Interface 8. Technical Manager 9.
Information Manager 10. Process
Engineer 11. Coordinator of the Disciplines 12.
Classified Ads Systems Engineer
from Sarah A.Sheard (INCOSE proceedings of 1996)
9
Systems Engineering vs. Project Management
10
Key Systems Engineering Functions
Verification and Validation
Project Objectives and Constraints
Requirements Development and Management
Architecture and Design
Verification and Validation
Verification and Validation
Project Objectives Met, Ready for Operations
Operations Concept
Systems Engineering Management Plan
11
Systems Engineering Process V
Understand User Requirements, Develop System
Concept and Validation Plan
Demonstrate and Validate System to User
Validation Plan
Develop System Performance Specification and
System Verification Plan
Integrate System and Perform System Verification
to Performance Specification
Expand Performance Specifications Into
CI Design-to Specifications and Inspection Plan
Assemble CIs and Perform CI Verification to
CI Design-to Specifications
Integration and Verification Sequence
Evolve Design-to Specifications into Build-to
Documentation and Inspection Plan
Inspect to Build-to Documentation
Decomposition Definition Sequence
Fabricate, Assemble, and Code to
Build-to Documentation
CI Configuration Item
12
Systems Engineering Process V (Continued)

• Developed by Kevin Forsberg and Harold Mooz
• Starts with user needs on the upper left and ends
  with a user-validated system on the upper right
• Adds concurrent risk management
• User involvement
• User approval and in-process validation
• Adds verification problem resolution

Kevin Forsberg and Harold Mooz, "The
Relationship of System Engineering to the Project
Cycle," Proceedings of the First Annual Symposium
of National Council on System Engineering
(NCOSE), Chattanooga, Tennessee, Oct. 1991, pp 57
- 65.
13
Requirements Development

• Collect top-level requirements from customers and
  stakeholders
• Develop an operations concept
• Derive lower-level requirements to support
  top-level requirements and the operations concept
• Writing requirements without a fully understood,
  agreed upon and documented operations concept
  will result in poor and misunderstood
  requirements, cost overruns and schedule slips.

14
Requirements Development (Continued)

• Writing Good Requirements
• Functional Requirements - What needs to be done
• Functional Requirements are generally not
  Verified because Performance Requirements specify
  how good the function needs to be
• Functional Requirements define a logical
  breakdown
• Performance Requirements - How well it needs to
  be done
• Performance Requirements are Verifiable
• Requirements Decomposition and Parent-Child
  Relationship
• Requirements flow from higher to lower levels
• Requirements at lower levels (children) must
  trace from a higher level requirement (parent)
• Eliminate any orphan requirements (requirements
  without parents)
• Add rationale or comments to the requirements to
  help trace why that requirement was created

15
Requirements Development (Continued)

• Decompose the requirements in a hierarchical,
  parent-child relationship
• Requirements flow from higher to lower levels
• Requirements at lower levels (children) must
  trace from a higher level requirement (parent)
• Eliminate any orphan requirements (requirements
  without parents)
• Add rationale or comments to the requirements to
  help trace why that requirement was created

16
Requirements Development (Continued)

• Writing the right requirements
• What is necessary to Achieve Full Mission Success
  Criteria?
• Levels of requirements (Level 1, Level 2, etc.)
• Level 1 Generally Highest Level Agreement with
  Ultimate Customer
• Lower Levels up to each Project to choose
• Traceability (Parent, child, orphan, widow, etc.)
• Priorities
• Organizing the requirements
• (templates and guidelines)
• Reviewing Requirements
• Gate keepers
• Formal reviews (SRR, PDR, CDR)
• Verification Plan must addresses
• how each requirement will be verified

17
Requirements Development (Continued)

• Use the word shall when defining requirements
  and only for requirements
• The attitude control system shall point the
  instrument boresight to within 6 arc seconds of
  the commanded attitude.
• Make it clear to the reader exactly what must be
  done.
• Requirements should be
• Measurable
• Avoid vague statements like shall point as
  accurately as possible
• Verifiable
• If no one can demonstrate that a system does or
  does not meet a requirement, then there is no
  requirement shall not exceed 55 kg, but we
  arent going to weigh it
• Document rationale!
• Capture the why while it is fresh.
• Enable future changespeople are afraid to change
  things they dont understand.

18
Requirements Development (Continued)
The Customers Swing The customer requested a
new kind of swing that allowed the customer more
than one way of swinging.
Communication and Understanding is Key!
19
Requirements Management

• Collect top-level requirements from customers and
  stakeholders
• Develop operations concept
• Derive lower-level requirements to support
  top-level requirements and the operations concept
• Choose an appropriate tool to store and manage
  the requirements
• This can range from an Excel spreadsheet for
  simple projects to sophisticated tools such as
  DOORS, Team Center, CORE, etc. for more complex
  projects
• Baseline the requirements at a System
  Requirements Review (SRR)
• Baseline means requirements are signed off and
  put under configuration control
• Control any future changes to requirements
  through a configuration management process

20
Requirements Management (Continued)
21
Operations Concept

• An Operations Concept is a vision (in general
  terms) for what the system is, and a description
  of how the system will be used.
• An Operations Concept consists of a set of
  scenarios describing how the system will be used
  during all of its operational phases.
• The scenarios are often accompanied by
  illustrations of the system operations.
• An Operations Concept
• Serves as a validation reference for the design
  throughout the life cycle
• Describes how the design can accomplish the
  mission described by the objectives
• Key to defining all the requirements
• Evolves into the flight operations plan later in
  the life cycle

22
Operations Concept (Continued)

• Stakeholders participate in the development of
  the Operations Concept
• Trade studies and analyses are used to
  demonstrate that the operations concept will meet
  the mission requirements within cost and schedule
  constraints

23
Operations Concept (Continued)

• Considerations for developing an Operations
  Concept for a Space Mission
• Allocation of functions between ground segment
  and flight segment
• Mission operational modes and configurations
• Time ordered sequence of mission activities
• Identification of facilities, equipment and
  procedures needed to ensure the safe development
  and operation of the system
• Operations team size, staffing and extent of
  automation
• Ground segment functions
• Contingency concepts
• Ground test configurations necessary to
  accomplish verification including GSE, BTE,
  simulators and non-flight articles such as ETUs
• Description of functions that cut across various
  subsystems
• Observation strategy
• Date collection, storage and downlink
• Ground station utilization
• Mission orbit maintenance and maneuvers
• Power and battery management

24
Operations Concept (Continued)
Satellite Operators
Control Center
Military Planners
Request for Data
Data
Inter -Satellite Link
Data Download
Command Transmission
Image Recording
25
Decomposition

• Many types of decomposition
• Requirements Decomposition
• Functional Decomposition
• Functional Architecture
• Physical Decomposition
• Physical Architecture
• Operational Architecture
• Allocates functions to physical subsystems
• Provides complete description of the system
  design
• Integrates the requirements decomposition with
  the functional and physical architectures

26
Decomposition (Continued)
System Requirement
User Defined
based on content and allocation
non-exhaustive inclusive
Functional Requirement
Performance Requirement
Physical Property Requirement
Interface Requirement
Effectiveness Measure
Imposed Design Requirement
Reference Requirement
27
Technology Planning

• Projects are sometimes initiated with known
  technology shortfalls
• Technology Pull
• Often there are areas for which new technology
  will result in substantial product improvement
• Technology Push
• Technology development can be done in parallel
  with the project evolution and inserted as late
  as the PDR
• Risk mitigation requires a parallel approach that
  is not dependent on the development of new
  technology
• The technology development activity should be
  managed as a critical activity

28
Technology Readiness Levels
29
Systems Analysis and Design
Modeling

• Models are the language of the designer.
• Models are representations of the
  system-to-be-built or as-built.
• Models are a vehicle for communications with
  various stakeholders.
• Models allow reasoning about characteristics of
  the real system.
• Models can be used for verification by analysis.
• All models must themselves be verified.

30
Systems Analysis and Design (Continued)

• There are two basic approaches that are commonly
  used for system design and integration
• Structured Analysis
• Object-oriented Analysis and Design
• It can be shown that either approach can be
  translated into the other.

31
Structured Analysis

• Structured Analysis
• Process Modeling, also known as Data Flow
  Modeling or Functional Decomposition
• IDEF0
• SADT (Structured Analysis Design Technique)
• Data Modeling
• IDEF1x
• Entity-Relationship Diagrams
• Behavior Modeling
• Rules
• State Transition Diagrams
• The IDEF process was developed by the Air Force
  in the early 1970s as part of the ICAM program
  (Integrated Computer Aided Modeling). IDEF
  originally stood for ICAM Definition but NIST
  later changed it to Integration Definition.

32
Structured Analysis (Continued)
IDEF0 Student Registration System
33
Structured Analysis (Continued)
ICOM
Control
Input
Function
Output
Mechanism
34
Structured Analysis (Continued)
Behavior Modeling State Transition Diagram
Ready
Verifying
User ID and Password entered (User_ID, Password)/
accept
start
Do verify user
Do display login page Do wait for login
Invalid user/DisplayAccess Denied
Valid user
Validating Options
Option selected not allowed/ Display error
message Option not allowed
Retrieving
Request for course search
Do display user options Do check option vs
access permission
Do display course search page Do retrieve
course selections
Registration rejected
Request to register (course_nr, user_ID)
Request to generate report (User type)
Request to register (course_nr, user_ID)
Validating Report
Registering
Report not allowed/ Display error message
Option not allowed
Do display report page Do validate user vs
report selected
See superstate diagram
(Report type) Report allowed
No Conflicts (course_nr)
Report printed
Drop request (course_nr)
Generating Report
Updating Schedule
Do send database request (report parameters) Do
format report Do print (report)
Do update student schedule
Updating complete/ University-updated class
roster
35
Structured Analysis (Continued)
IDEF1x DATA MODEL

36
Object-Oriented Analysis and Design

• Object-Oriented Analysis and Design
• The concept of object or object class is the
  result of a long history of software engineering
  design.
• From a programming viewpoint, an object is a
  collection of specialized data packaged with the
  functions (operations and methods) which are
  needed specifically by that specialized data.
• From a systems design viewpoint, an object is a
  system or component which maintains its own
  information and is able to perform some specific
  functions.
• Developed more recently for software engineering,
  object- oriented design is now migrating to
  systems engineering.
• Object-oriented design defines the relationships
  between object classes and the behavior of the
  classes.

37
Unified Modeling Language (UML)

• UML is a language for visualizing, specifying,
  constructing and documenting the artifacts of
  software-intensive systems, as well as for
  business modeling and other non-software systems.
• UML supports the entire development lifecycle.
• UML is supported by many tools (e.g., IBM
  Rational ROSE, Visio, etc.).
• SysML is the extension of UML to systems
  engineering.

38
(3)
Domain of Interest
contained in
contained in
reference for
built from
C
categorizes
(63)
(5)
System View
Functional Breakdown
(64)
(6)
(7)
System Breakdown
has view
Stakeholder
Environment
Element
exhibits
part of
Physical Breakdown
(1)
(65)
has
(62)
(61)
(4)
(8)
Interacts with
Realization View
Design View
Stakeholder Need
satisfied by
System
(9)
(11)
allocated to
Reference Document
System Requirement
Property
represented by
statement of
reference for
(10)
derived from
(12)
(13)
(14)
verifies
Physical Property
Structure
Behavior
allocated to
budgeted to
39
Unified Modeling Language (UML)
(3)
Domain of Interest
Box means Class or Meta Class (top is name) or
type 2nd box means attributes 3rd box means
Methods or member functions Diamond means
aggregation/decomposition Line means relationship
(words on line describe relationship) (XX) Means
look at Concept semantic dictionary Diamond with
a C in the middle means a Complete
decomposition Loop line with Diamond means
hierarchal decomposition of items of the same
type Arrow/triangle means specialization/generali
zation Depending on direction A number on each
end of a line means multiplicity
(1)
(4)
(22.10)
1
1
From MDSD Workshop 5 Feb 2003
40
UML vs. SysML
41
Concurrent Design
Integrated Mission Design Center (IMDC) at
Goddard Space Flight Center

42
Concurrent Design
Collaborative, Rapid Design Improves Quality of
Conceptual Designs
Preliminary design in one week vs. six months
43
Small Explorers (SMEX) Built at GSFC
Submillimeter Astronomy Satellite (SWAS)
Transition Region And Coronal Explorer (TRACE)
Wide-Field Infrared Explorer (WIRE)
Solar Anomalous and Magnetospheric Particle
Explorer (SAMPEX)
Fast Auroral Snapshot Explorer (FAST)
44
System Integration

• Integration is the process of assembling the
  system from components.
• Integration begins with the elementary pieces or
  configuration items (CIs) of the system.
• After each CI is tested, components comprising
  multiple CIs are tested.
• This process continues until the entire system is
  assembled and tested.
• Interface Specifications and Interface Control
  are critical to a successful system integration.

45
Work and Resource Management

• A Work Breakdown Structure (WBS) is a
  hierarchical breakdown of the work necessary to
  complete a project.
• The WBS should be a product-based, hierarchical
  division of deliverable items and associated
  services.
• The WBS should contain the Product Breakdown
  Structure (PBS).
• At the lowest level are products such as hardware
  items, software items, and information items
  (documents, databases, etc.) for which there is a
  cognizant engineer or manager.
• A project WBS should be carried down to the cost
  account level appropriate to the risks to be
  managed.

46
Work Breakdown Structure (WBS)
47
Product Breakdown Structure (PBS)
48
Technical Resource Management

• Critical mission resources shall be identified,
  allocated and managed
• Acceptable resource margins shall be established
• A margin management philosophy shall be set up
  based on design maturity and time
• Required margins are reduced as the project
  matures
• Margins are assessed based on the fidelity of the
  estimate
• Care must be taken that margins are not added to
  margins
• Stacked margins that do occur simultaneously in
  real life
• Lead systems engineer holds the overall system
  margins
• Subsystem engineers must be allowed to hold some
  margin in order to meet their design requirements
• This hierarchy of margins must be taken into
  account so that the overall system margins do not
  drive the design and the cost

49
Example Technical Resource Margins
Tracking Estimates (Mass)

• Allocations defined at SRR for appropriate total
  margin
• Estimates tracked monthly
• Changes to allocation via CCR
• Estimates over total allocation trigger risk
  reduction activities

50
Specialty Engineering

• Specialty engineers support the systems
  engineering process by applying specific
  knowledge and analytic methods from a variety of
  engineering specialty disciplines to ensure that
  the resulting system is actually able to perform
  its mission in its operational environment.
• For space systems these specialty areas often
  include
• Quality Assurance
• Reliability
• Maintainability
• Producibility
• Logistics
• Safety
• Environment (e.g., radiation, atomic oxygen,
  atmospheric density, etc.)
• Contamination
• Parts Engineering

51
Quality Assurance
Performance
Providing confidence that the system actually
produced and delivered is in accordance with its
functional, performance, and design requirements.
Quality
Cost
Time
52
Reliability

• The Bathtub Curve
• For many systems, the failure rate function
  looks like the classic "bathtub curve"
  illustrated in the graph below.

Failures
Random Failures
Burn-in Period
Useful Life Period
Wear-out Period
Time
53
Maintainability

• Maintainability is that system design
  characteristic associated with the ease and
  rapidity with which the system can be retained in
  operational status, or safely and economically
  restored to operational status following a
  failure.

54
Verification

• Verification Did I build the System Right?
• Each requirement must be verified
• Verification Methods Test, Analysis, Inspection
  and Demonstration
• Rule 1 Test wherever possible
• Perform Analysis and Inspection, where Test is
  not possible
• Pay careful attention to validity of simulators
  and models
• Rule 2 Test the way you fly, fly the way you
  test
• Identify what is not tested in flight
  configuration
• Careful review to assure items are properly
  verified by a combination of Analysis, Inspection
  or Test.
• Review of the assumptions and interfaces of
  element verified in pieces
• Attention to validity of simulators and
  simulations
• Careful review to assure these items are properly
  verified by a combination of Analysis, Inspection
  or Test.

55
Verification (Continued)

• Rule 3 Test the system end-to-end
• Carefully review the assumptions and interfaces
  of any elements verified in pieces
• Rule 4 Verify Off-Nominal Conditions
• Verify Redundancy and Graceful Degradation Modes
  along with On Board Fault Protection and Ground
  Contingency Procedures
• Stress Testing and Negative Testing to find
  Latent Flaws

56
Validation

• Validation Did I design or build the Right
  System?
• Validation shows that the Design when used
  according to the Operations Concept meets the
  Requirements and the Customers Goals and
  Objectives and can be produced within the Cost,
  Schedule and Risk constraints
• Validation Methods Analysis, Predictions, Trade
  Studies, Test
• The requirements flow is also validated to show
  that Parent requirements have valid Child
  requirements and that Orphan requirements are
  not driving the system design or implementation.
• Initial Validation during Phase A and B is
  critical to proceeding into Phase C where detail
  design occurs
• Otherwise the detail design proceeds on the
  Wrong system
• Validation also occurs in parallel with
  verification where End to End Tests, Mission
  Simulations show that the Right System has been
  built

57
Summary

• Systems Engineering addresses the total program
  lifecycle
• Largely a communications activity
• Consistent Requirements, Design, and Operations
  Concept
• Time Phased Crawl Before You Walk, Walk Before
  You Run
• No Cookbooks or Magic Recipes
• Multilayered Review, Inspection and Test Process
• It is the Project Team, the People, that makes
  projects successful

58
Some Key References

• Andrew P. Sage and William B. Rouse, Handbook of
  Systems Engineering and Management, 2nd edition,
  John Wiley, 2009
• ISO/IEC 15288, Systems engineering System life
  cycle processes, 2002
• Dennis M. Buede, The Engineering Design of
  Systems Models and Methods, Wiley, 2000
• ANSI/EIA-632-1998, Processes for Engineering a
  System, Electronic Industries Alliance, 1999
• IEEE 1220, Management of the Systems Engineering
  Process
• INCOSE-TP-2003-002-03.1, INCOSE Systems
  Engineering Handbook v3.1, 2007
• SP-2007-6105, NASA Systems Engineering Handbook

59
Homework Assignment

1. In a brief paragraph describe a system of your
   choosing
2. In another paragraph describe its operation
   (operations concept)
3. Draw a high-level product breakdown structure
   (PBS) for that system