SES 405: Exploration Systems Engineering – Class …origins.sese.asu.edu/ses405/Class Notes/Class...

Exploration Systems Engineering: Class Review

SES 405: Exploration Systems Engineering – Class Review

Exploration Systems Engineering: Class Review 2

Requirements — The Basics

♦  Requirements define the problem to be solved and establish the terms by which mission success will be measured.

♦  Requirements are the single biggest problem in development projects so attention to detail in creating good requirements is vital.

♦  The later a problem is discovered the more costly is the recovery.

♦  Requirements are distributed within the system architecture via flow-down, allocation and derivation.

♦  Requirements traceability is a technique of tracking the source and connections between requirements. It is used to assess the consequences of potential requirements changes.

♦  When a system is decomposed into smaller segments, interfaces are created that must be defined and managed.


Writing Requirements

♦  Good requirements Are SMART: Specific, Measurable, Achievable, Relevant and Traceable

♦  It is good practice to capture the rationale and preliminary technique for verification when writing requirements.

♦  Requirement validation is a process of ensuring that the set of requirements is correct, complete, and consistent.

♦  Since the cost of reconciling undefined requirements grows as the project matures, undefined (TBD) and estimated (TBR) requirements should be resolved as early as possible.


The Project Life Cycle

♦  A project is divided into distinct life cycle phases. •  Pre-Phase A: Concept studies •  Phase A: Concept and technology development •  Phase B: Preliminary design and technology completion •  Phase C: Final design and fabrication •  Phase D: System assembly, test and launch (otherwise known as panic

mode) •  Phase E: Operations and sustainment •  Phase F: Closeout or disposal

♦  These phases are separated by control gates - typically associated with a major project review, such as preliminary design review (PDR).

♦  Each project phase has a distinct purpose and set of products.

♦  At the end of each phase a new system baseline — or an agreed-to set of requirements, designs, or documents — is established.

♦  A system baseline is the point of departure for the development work in each new phase.


Major Project Reviews Precede Each Key Decision Point

Key Decision Points

FORMULATION IMPLEMENTATION

Major Reviews

A C

D E

Project Phases

Concept Studies

Concept & Technology Development

Preliminary Design & Technology Completion

Final Design & Fabrication

System Assembly, Test, & Launch

Closeout Operations & Sustainment

A B

B

C

F

D E F Pre-A

Mission Concept Review

Systems Requirements Review

Mission/System Definition Review

Critical Design Review

Systems Integration Review

Operational Readiness Review

Flight Readiness Review Post Launch Assessment Review

Decommissioning

Review

Preliminary Design Review

Independent Cost Estimates


The Engineering Activities in the Project Life Cycle

Time and Project Maturity

Mission Requirements

& Priorities

System Demonstration

& Validation

Develop System Requirements &

System Architecture

Allocate Performance Specs & Build

Verification Plan

Design Components

Integrate System & Verify

Performance Specs

Component Integration & Verification

Verify Component Performance

Fabricate, Assemble, Code &

Procure Parts

System Level

Subsystems

Components

A

D C

E

B


Configuration and Change Management

♦  System baselines capture the complete, current system description.

♦  System baselines are updated periodically at five major milestone reviews - SDR, PDR, CDR, FRR and ORR.

♦  Requirements and configuration changes are inevitable, so a formal process of considering the implications of any changes is mandatory.

♦  It is important to have managed baselines, requirements and configurations so that the entire team is working with the same assumptions of what the current system is, and what it must do.

♦  Systems engineering is responsible for creating and updating the system baseline, assessing the implications of considered changes and disseminating the news of any accepted changes.


Verification

♦  Validation - Did we build the right system? ♦  Verification - Did we build the system correctly? ♦  Requirements validation - Are the requirements complete,

consistent, SMART and do they capture the intent of the system?

♦  Requirements verification is about establishing confidence that the system will perform in its intended environment.

♦  Requirements are verified by test, demonstration, analysis and inspection.

♦  Space systems go through rigorous ground-based tests that simulate the launch and space environment.

♦  Using heritage designs can save development time and money, but any heritage design should be validated and verified as if it represented new hardware.

♦  Simple procedural errors - like borrowing another project’s bolts - can lead to multi-million dollar (or life threatening) accidents.


Technical Reviews

♦  Technical reviews are key development milestones used to measure progress, assess project maturity and to infuse lessons from the past. They… •  Provide confirmation of completed effort and readiness to commit

additional resources for the next phase. •  Encourage and establish project discipline with an integrated

project team perspective. •  Identify risks and review mitigation options. •  Describe plans and priorities for the next phase.

♦  There are 11 reviews in the minimum set of technical reviews for a NASA robotic mission. These reviews cover the entire mission life — assessing the concepts and designs early; readiness for test, flight and operations in mid-life and plans for disposal at the mission’s end.

♦  These reviews are held to demonstrate that the appropriate products, accomplishments and plans have been completed before proceeding to the next phase. •  Appropriate products, accomplishments and plans are based on the

lessons of hundreds of past projects (best practices).


Schedule

♦  There are different methods for displaying project schedule information.

♦  Gantt and Milestone charts relate activities to calendar dates in an easily understood format.

♦  Network schedules show the dependencies between activities in a graphical portrayal with activity durations.

♦  Critical Path is the sequence of activities that will take the longest to accomplish. Any delay on this path will delay the project. Activities that are not on the critical path have a certain amount of time that they can be delayed until they, too are on the critical path. This time is called float (or slack).

♦  There is inherent risk in developing schedules. Probabilistic techniques can be used to assess the risk.

♦  For space missions, guidelines exist for determining schedule margin.

♦  Schedule information, such as the accomplishment of milestones or the amount of schedule slack, can be used to report project status/progress (as a form of technical performance measures).


Gantt Chart Format aka Bar Charts

Gantt and milestone charts are best used for displaying the planned activities and events of a project and the progress in meeting them. This makes them very useful for presenting schedule and program status information in a concise simple format at such things as program or activity reviews. Because of its simplicity and ease of interpretation, it is a particularly good tool for communicating to higher management when information must be presented quickly and efficiently.


RRF-2 ISS-1 RRF-3

First Stage

Jun System Engineering & Integration

Gov’t Lead

ATP SRR PDR CDR Del for RRF3

Del ISS1 to KSC Del for

RRF2

Gov’t Lead SRR PDR CDR MPTA Del for RRF3 Del for

US ISS-1 to KSC Del

for RRF2

Dev Eng Needed CDR Del for

ISS-1 MPTA

Del for RRF-1

Jul Nov Apr Fab, Integ & Test Upper Stage

FY05 FY06 FY07 FY08 FY09 FY10 FY11 FY12

Flight Test/ Mission Milestones

FY13

ISS-2 UCM-1 RRF-1

CEV ATP

Contractor 1&2 SRR Del for

RRF-1

SDR PDR CDR

Del for RRF-2

Del for RRF-3

Del for ISS-1

Del for PC-1

Unpressurized payload structure

Program Integration L1 Req

Baseline Review

L2 SRR Complete

Pre-NAR Kickoff

L2 SDR

Pre-NAR Complete

PDR Complete

CDR Complete

CLV SRR

NAR

PC-1 PC-2 ISS-3

Delivery of Crew & Service Module

Delivery of Launch Abort System

Del for RRF-1

Del for RRF-3

Del for RRF-2

Del for ISS-1

Del for RRF3

Del for RRF2

Example Milestone Chart

LAS-1 LAS-2 LAS-3

LAS-4

Del for LAS-1

Del for LAS-2 Del for LAS-2

Del for LAS-3

Del for LAS-4

Del for LAS-1

Del for LAS-2

Del for LAS-3

Del for LAS-4

CEV SRR

Upper Stage Engine (RS-25d/e)

Jul

CDR

Feb

PDR

ATP SRR PDR

Pre-formulation

Phase B

Phase C/D

Phase A Non-Traditional

= 0% Complete

= 100% Complete


Scoping & ConOps

♦  The first step in understanding the mission at hand is defining the scope, where scope is a definition of what is germane to your project.

♦  The scope content involves •  Defining the needs, goals, and objectives •  Identifying stakeholders •  Developing operational concepts •  Understanding constraints

♦  A thorough scoping effort leads to organized and informed mission and system requirements.

♦  A concept of operations (conops) is a description (often pictorial) of how the system will be operated during the mission phases in order to meet stakeholder requirements.

♦  A concept of operations can include many aspects of operations, such as a timeline, a communications strategy, varying operational scenarios, etc.


System Architecture

♦  Creating a system architecture is a systems engineering function that is the first step in translating a defined problem into a solution.

♦  Creating an architecture is a recursive, iterative process that begins with the problem statement, creates some candidate solutions, assesses their merits and chooses one.

♦  Architecture creation is not a deterministic process, but understanding the strengths, weaknesses and adaptability of heritage or analogous systems is a valuable first step.

♦  In working with the stakeholders, the function or performance requirements of the system may be modified to create a better match between the problem statement and the candidate solution.

♦  Like many systems engineering functions, architecting is one of balancing competing factors and choosing a preferred solution with uncertain and sometimes ambiguous information.

♦  No one view captures an architecture. Many views are used to capture the system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors.


Functional Analysis

♦  Functional analysis is a system development tool used to capture required system functions.

♦  Functional analysis also supports functional decomposition - the process of describing the sub-functions that are necessary for each function.

♦  Functional Flow Block Diagrams (FFBDs) are graphical tools used to capture the functional sequence and functional hierarchy of a system.

♦  Time-Line Analysis (TLA) is a tool used to capture the duration, and sequence of system functions. TLA can be used in conjunction with FFBDs.

♦  Functional analysis is implementation independent. In other words, all functions are describes in terms of what must be done (and sometimes how well) not how it will be done. This independence ensures that when subsequent trade studies choose how functions will be performed they will be unbiased.


Planetary Defense Level 1 Functional Flow Block Diagram For Threat Detection

1.10 Decide on Ac-on

1. Detect Threat

or

Ref. 2. Eliminate

Threat

Ref. 3. Reevaluate Threat (b)

Ref. 3. Reevaluate Threat (a)

1.1 Coordinate Assets 1.2 Monitor Sky 1.3 Confirm

Sigh-ng(s)

1.4 Determine Composi-on

1.5 Determine Size

1.6 Determine Velocity

1.7 Determine Orbital Elements

1.8 Run Simula-on(s)

1.9 Establish Level of Threat and and


Time Line Analysis Example for Sub-Function of Launch Readiness

Example shows the time required to perform function 3.1. Its sub-functions are presented on a bar chart showing how the timelines relate. Note: function numbers match the FFBD.


System Design (1/2)

♦  System design produces a physical architecture from the functional architecture.

♦  System design is an iterative process in that many subsystem solutions are considered, and the subsequent system merits are assessed before a baseline is established.

♦  To assess the merits of candidate subsystems, consider their performance, risks, heritage, technical maturity, and limits of their performance.

♦  One way to seek optimal system design is to choose performance and resource allocations to equally stress all subsystems. Share the pain among subsystems.

♦  System requirements define a successful solution. Know when to stop trying to improve a design - better is the enemy of good enough.


System Design (2/2)

♦  Maintain a decision database and formally review it at each project milestone review.

♦  Use performance-resource (utility) curves to identify break points to help develop balanced solutions.

♦  Determine the ‘driving’ requirements. •  Understand which requirements are the toughest to meet

and consider reallocation to manage them. ♦  Subsystems with high cohesion, low complexity and low

connectivity are good. In other words, keep interfaces simple and similar functions together.

♦  In system design decisions, consider robustness — a measure of a system’s sensitivity to environmental or resource variation.


An Approach to System Design - the steps

1.  Begin with the functional architecture, its performance requirements and constraints (from functional analysis).

2.  Allocate (or derive) subsystem performance and resource requirements.

3.  Define physical subsystem alternatives. 4.  Assess technology alternatives and their maturity (heritage etc.) 5.  Define physical interfaces. 6.  Estimate subsystem and system performance of each

combination of alternatives. 7.  Use performance-resource curves (utility curves) to identify

break points. 8.  Determine the driving requirements and consider reallocation. 9.  Select a preferred system design. i.e., the physical architecture

with subsystem implementation plans and functional and performance allocations and system performance estimates.


Trade Studies

♦  Trade studies are common decision-support tools that are used throughout the project lifecycle to capture and help assess alternatives.

♦  The steps in the trade study process are: 1.  Define the objectives of the trade study 2.  Review inputs, including the constraints and assumptions 3.  Choose the evaluation criteria and their relative importance 4.  Identify and select the alternatives 5.  Assess the performance of each option for each criteria 6.  Compare the results and choose an option 7.  Document the trade study process and its results

♦  Trade trees are graphical tools that help manage multi-variable options.


ISRU No ISRU

Inte

rpla

neta

ry

Prop

ulsi

on

(no

hybr

ids

in

Phas

e 1)

Mar

s A

scen

t Pr

opel

lant

M

ars

Cap

ture

Met

hod

Car

go

Dep

loym

ent

Aerocapture Propulsive

ISRU No ISRU ISRU No

ISRU ISRU No ISRU


ISRU No ISRU


ISRU No ISRU ISRU No

ISRU ISRU No ISRU

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al

NTR

E

lect

ric

Che

mic

al


Pre-Deploy All-up Pre-Deploy All-up

Opposition Class Short Surface Stay

Mis

sion

Ty

pe

Human Exploration Of Mars

Special Case 1-year Round-trip

Top-level Trade Tree-Example for Mars

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

Œ � Ž � � ‘ ’

“ ” � ‚ • • NTR- Nuclear Thermal Rocket Electric= Solar or Nuclear Electric Propulsion

Conjunction Class Long Surface Stay

Œ 1988 “Mars Expedition”�� 1989 “Mars Evolution”�Ž 1990 “90-Day Study”�� 1991 “Synthesis Group” �� 1995 “DRM 1”�‘ 1997 “DRM 3”�’ 1998 “DRM 4”�“ 1999 “Dual Landers”�” 1989 Zubrin, et.al*�• 1994-99 Borowski, et.al � 2000 SERT (SSP) ‚ 2002 NEP Art. Gravity �  2001 DPT/NEXT M1 2005 MSFC MEPT M2 2005 MSFC NTP MSA

M2 M1 M1 M1

M2 M2 M2 M2

ƒ

Decision Package 1 Long vs Short


Technology Readiness

♦  The Technology Readiness Level (TRL) scale is used to assign maturity levels to technology considered for space flight.

♦  Low TRLs, or low technology maturity, correlate with development risk.

♦  Early development of enabling, low maturity technologies can reduce the development risk of a system.

♦  JWST attempted to reduce the system development risk by developing some low maturity technologies before PDR, like the primary mirror segments.


Technology Readiness Levels

Actual system “flight proven” through successful mission operations Actual system completed and “flight qualified” through test and demonstration (Ground or Flight) System prototype demonstration in a space environment System/subsystem model or prototype demonstration in a relevant environment (Ground or Space) Component and/or breadboard validation in relevant environment Component and/or breadboard validation in laboratory environment Analytical and experimental critical function and/or characteristic proof-of-concept Technology concept and/or application formulated

Basic principles observed and reported

Figure 5. Technology Readiness Levels

Basic Technology Research

Research to Prove Feasibility

Technology Development

Technology Demonstration

System/Subsystem Development

System Test, Launch & Operations

Defining TRL = determining what was demonstrated and under what conditions.


System Hierarchy

♦  A product breakdown structure (PBS) captures the hierarchy of the system and is one representation of the system architecture.

♦  Creating a system hierarchy is valuable since it breaks a complex problem into smaller pieces that will be easier to tackle.

♦  But this reductionism, or decomposition has a price: •  New interfaces are created between the pieces (subsystems), so

they must be defined and managed. •  System resources (e.g., mass or power) must allocated to the

subsystems and these allocations must be accounted for; and •  System performance is also allocated to subsystems, so

confidence must be established that if all of the subsystems perform as desired that the system will perform as desired.

♦  The work breakdown structure (WBS) extends the PBS in that it captures all of the work necessary for a project by adding the non-product work necessary for a successful project (e.g., integration, test, logistics support, systems engineering and management).


Example: NASA’s SOFIA Project PBS and WBS

Aircraft Element

Telescope Subsystem Electronics Subsystem

Telescope Element

Airborne Facility Science Instruments

Observatory System

Labs/Offices Facility GSE Mission Planning Simulator

Ground Support System

Sofia Project

Management SystemsEngineering

ProjectIntegration &

Test

Operationsand Logistics

Planning

ScienceSupport

MissionAssurance

ObservatorySystem

GroundSupportSystem

Sofia Project

PBS

WBS


Management

♦  A Project Manager’s roles and responsibilities are different from those of the Project Systems Engineer. The manager is continuously balancing the three project variables of cost, schedule and technical content.

♦  The Project Plan documents the project baseline for implementation. It includes the work breakdown structure, the associated activities, the resources required to accomplish the work, and the planned schedule for completing the work.

♦  The Systems Engineering Management Plan (SEMP) is the project’s guiding technical document. All subordinate technical documents, like a requirements document or test plan, must follow the guidelines of the project SEMP.

♦  Companies and government agencies usually use two different approaches to managing their workforce. In-line management means the responsible workforce directly reports to the project manager. Matrix management means the majority of the workforce is assigned temporarily to a project for a fixed period of time for a specified task.


Analytical Hierarchy Process

♦  Many decisions are made early in the project life cycle. The decision maker must always choose based on some implicit or explicit evaluation criteria.

♦  The basic steps in the decision making process include: 1.  Establish evaluation criteria

2.  Establish relative importance of evaluation criteria

3.  Develop alternative concepts that meet objectives and top-level requirements

4.  Evaluate alternatives relative to the established evaluation criteria

5.  The alternative that best satisfies the evaluation criteria represents the tentative concept choice.

♦  Figures of Merit (FOM) is a metric by which a stakeholder’s expectations will be judged in assessing satisfaction with a product or system.

♦  The Analytical Hierarchy Process (AHP) is a methodology that determines “best” through a series of pair-wise comparisons. It can be used to determine attribute weightings as well as alternative scores. •  One of the benefits of AHP is the use of a standardized process by which to

compare alternatives. It can be used with both quantitative and qualitative data.


Interfaces and N2 Diagrams

♦  System external interfaces are defined, distributed and managed like other system requirements.

♦  Internal interfaces, since they are created as the system is decomposed, can be optimized by the development team.

♦  In developing interfaces group like functions, keep them simple and consider the use of standard interfaces.

♦  Since all interfaces run the risk of being ignored as development teams focus on their subsystem responsibilities, explicitly identify the owners of all interfaces.

♦  N-squared diagrams the most common interface identification and management tool. They are are used to: •  Capture the existence and nature of an interface •  Highlight input and output assumptions and requirements •  Demonstrate where there are feedback loops between subsystems •  Identify candidate functional allocations to subsystems


I = Input O = Output

O 1 2 I

O 1 3 I

O 2 3 I

O 1 4 I

O 2 4 I

O 3 4 I

O 2

1 I

O 3

2 I

O 3

1 I

O 4

2 I

O 4

1 I

O 4

3 I

Generic N-squared Diagram as an Interface Artifact

N2 diagram rules: •  Items or functions are on

the diagonal

•  Items or functions have input and outputs

•  Item or function outputs are contained in rows; inputs are contained in columns

Item or

Function 4

Item or

Function 3

Item or

Function 2

Item or

Function 1

External Input (to Item or Function 2)

External Output

(from Item or Function 3


Use of Block Diagrams

32

ISIM COMMC&DH

Omni

HGA

MIRI FPE

Ka-Band Modulator

( x2)

Ka-Band TWTA (x 2)

Switches

OTE

EPS

ACS

Reaction Wheels

(x 6)

Propulsion (Bi-Prop )

SecondaryCombustionAugmented

Thrusters(x 4)

MRE -4 STMs(x 8)

Region 1 Region 2 Region 3

Legends :

ISIM 1553 B-I

Spacewire Discrete -pt to pt

Region 1-(within Si /OA ) Region 2-(within IEC )Region 3-(within spacecraft

bus)

WingDeployment Acts

(x 2) &Latch Acts (x8)

Primary Mirror

Secondary Mirror

Tertiary Mirror

photons

Hexapod(6 DOF)

Hexapod(7 DOF )

x18

Primary Power

Fine Sun Sensors (x2)

Wheel Drive Electronics (x6)

Command Telemetry Processor

NIRSpec

FGS

NIRCam

Sunshield

40 Ah NiH 2

Battery

Coarse Sun Sensors (x4)

Valve Drive Electronics (x 2)

Inertial Reference Unit (1)Tower

Actuators

SMSS Deploy

ActActuator

Drive Unit

SunshieldAct (x6)

RS422

Cold Junction

Box

Solid State Recoder

S/C -ISIM 1553 B-SI

Solar Array

Regulators (x2)

Solar Array (3 panels )

(x2)

S/ C 1553 B-S

Telemetry Acquisition

Unit

M otor Switching Relay

Region 3

Analog /Bilevel

Compressor Assembly

Cooling Lines

Radiator Heat Switches

Contn Ctrl Htrs

Cryo Tem p Sensors

MIRI

FGS Guiders FPE /ICE

FGS TF FPE /ICE /TCE

CCE -JT(x2)

CCE -PC(x2)

ISIM Command

& Data Handling

(x2)

IRSU

NIRSpec FPE /ICE /MCE

Star Trackers ( x3)

Solar Array

Act (x2)

High Gain Antenna Act (x2)

Mechanical I /F

DIT CE ( x2)

FSM Act

LVDS

Power Control Unit

S-Band Transponder (x2)

Orientation Drive Electronics with Resolver (x2)

NIRCam FPEs /ICE

MIRI FPE /ICE


Margins and Contingency

♦  Contingency is the difference between the current best estimate of a resource and its maximum expected value.

♦  A margin is the difference between the maximum possible value of a resource and its maximum expected value, but in some sense is unknowable.

♦  Estimated resource use for a system in development grows as the design matures. Contingency is used to account for this growth, so the project can predict maximum expected values for each resource.

♦  The amount of recommended contingency for a resource is based on historically demonstrated trends and decreases as the design matures.


Technical Performance Measures ♦  TPMs are measures of the system technical performance that

were chosen because they are indicators of system success.

♦  The trends of past, successful projects are used to create contingency guidelines for new projects.

♦  Tracking TPMs and comparing them against typical resource growth provides an early warning system designed to detect deficiencies or excesses.

♦  TPMs that violate their contingency allocations or have trends that do not meet the final performance should trigger action by the systems engineer.

♦  The final, delivered system value can be estimated by extending the TPM trend line and using the recommended contingency values for each project phase.

♦  There is a balance between contingency for risk management and allocation for design flexibility. This balance is apparent since contingency allocations shrink as designs mature.


Cost Estimating

♦  Methods for estimating mission costs include parametric cost models, analogy, and grassroots (or bottoms-up). Certain methods are appropriate based on where the project is in its life cycle.

♦  Parametric cost models rely on databases of historical mission and spacecraft data. Model inputs, such as mass, are used to construct cost estimating relationships (CERs).

♦  Complexity factors are used as an adjustment to a CER to compensate for a project’s unique features, not accounted for in the CER historical data.

♦  Learning curve is based on the concept that resources required to produce each additional unit decline as the total number of units produced increases.

♦  Uncertainty in parametric cost models can be estimated using probability distributions that are summed via Monte Carlo simulation. The S curve is the cumulative probability distribution coming out of the statistical summing process.

♦  Cost phasing (or spreading) takes the point-estimate derived from a parametric cost model and spreads it over the project’s schedule, resulting in the project’s annual phasing requirements. Most cost phasing tools use a beta curve.


Risk

♦  Risk is inevitable, so risks can be reduced but not eliminated.

♦  Risk management is a proactive systematic approach to assessing risks, generating alternatives and reducing cumulative project risk.

♦  Fault Tree Analysis is both a design and a diagnostic tool that estimates failure probabilities of initiators to estimate the failure of the pre-determined, undesirable, ‘top’ event.

♦  Failure Mode Effects Analysis is a design tool for identifying risk in the system design, with the intent of mitigating those risks with design changes.


A 5x5 Risk Matrix Provides a Quick Visual Comparison of All Project Risks

High risks – mission success jeopardized - immediate action required Medium risk – review regularly – contingent action if does not improve Low risk – watch and review periodically


Fault tree analysis is a graphical representation of the combination of faults that will result in the occurrence of some (undesired) top event. In the construction of a fault tree, successive subordinate failure events are identified and logically linked to the top event. The linked events form a tree structure connected by symbols called gates.

Fault Tree Analysis


Reliability

♦  Reliability is a key attribute of space systems, influencing systems engineering activities such as design, trade studies, modeling, and test.

♦  The reliability function, R(t), is determined from the probability that a system will be successful for at least some specified time.

♦  The Bathtub curve expresses the failure rate as it depends on the age of the system. Early and late in life of the system (similar to the human body) significantly higher failure rates occur called “infant mortality” and “old age” regions. Between these regions normally lies an extended period of approximately constant failure rate. The reliability of systems operating in this region can be simply characterized by an exponential function.

♦  Ways to achieve reliability include fault tolerance, functional redundancy and fault avoidance.

♦  Block diagrams and event trees are useful tools in calculating reliability. An understanding of probability basics is required.


General Observations

♦  Requirements, Requirements, Requirements! •  Get them right early •  Don’t change them

♦  Oversight and Management of Contractors ♦  Human Factors:

•  Overwork •  The ability to say no •  Hopeless optimism

♦  The impact of outside politics ♦  Understand Interfaces, early and often ♦  Never assume anything about heritage ♦  Never underestimate vendors’ greed ♦  Mistakes will happen – be prepared to ‘fess up – it will ensure

mission success

40

SES 405: Exploration Systems Engineering – Class …origins.sese.asu.edu/ses405/Class Notes/Class...

Documents

Transcript of SES 405: Exploration Systems Engineering – Class …origins.sese.asu.edu/ses405/Class Notes/Class...