1. ME 59700 Fall 2014 Introduction to Systems Engineering Session 6 Dr. Dan C. Surber, ESEP © Copyright 2013

2. Lecture Topics Requirements Analysis Requirements Development Requirements Allocation Planning for IV&V Flowing requirements to DESIGN

3. Requirements Analysis RA = understanding the sources of requirements –Market & regulatory constraints –Mission threads for the system –Environments encountered by the system System specification may list sources –Standards –Specifications –System requirements Interfaces Design Constraints Functional Analysis

4. Requirements Development Examine System Level Requirements –Gaps & Conflicts –Direct Flow down, derived flow down Expand functional analysis –Allocate functions to Architecture with reqmts Develop budget allocations –Performance –Error –Constraints (weight, cost, A o, reliability)

5. Requirements Categories Identify the main category for each system level requirement –Cost, schedule, performance, interface, environment, specialty engineering (reliability, safety, supportability, human factors, etc.) –Capture the RATIONALE for each requirement Use these during allocation of Performance requirements to functions Use these when creating the Requirements Verification Matrix (RVM)

6. Concept of Operations & Support MSN SYS WHO WHAT WHERE WHEN HOW WHY SPT SYS WHO WHAT WHERE WHEN HOW WHY MISSION TYPES LEVELS OF MAINTENANCE TRAINING K S A EXISTING SPEC CODES OBSOLETE SEPC CODES NEW SPEC CODES

7. Mission Event Timelines Understand the mission events performed by the Mission System –Operational suitability –Operational effectiveness Understand how the Support System prepares the Mission System for its next mission cycle Orbit the station core Orbit & attach truss with solar panels Orbit air lock module Add on-orbit spares Add science modules & air locks Add remaining truss & solar panels On-orbit assembly of the ISS MS = on-orbit modules SS = space shuttle, robot resupply, ground control

8. Types of System Requirements PERFORMANCE – station shall remain on orbit for at least 20 years. INTERFACE – station shall interface with US Space shuttle and Russian resupply vessels. Future: ESA and JSA vehicles. ENVIRONMENT – station shall survive micro meteorite impacts without loss of pressurization or power for the life of its time on orbit. DESIGN CONSTRAINT – station shall accommodate 99 percentile males and 1 st percentile females. TECHNICAL PERFORMANCE MEASURES ACQUISITION & TECHNICAL –KEY PERFORMANCE PARAMETERS (KPP) MEASURES OF EFFECTIVENESS (MOE) –MEASURES OF PERFORMANCE (MOP) »DATA ELEMENTS –THRESHOLD CRITERIA –OBJECTIVE CRITERIA

9. 9 Functional Block Diagrams Stated as a “verb – noun” construct Hierarchical Grouped logically Not drawn to show any “flow” Number each block Need a “dictionary” to explain the purpose of the function

10. Mission & Context Analysis Go through 1 mission scenario at a time and identify the functions needed for that mission. Identify external system interfaces for that mission. Assess any critical timing behaviors for that mission. After all mission/scenarios are analyzed for functions, interfaces & timing; consolidate the system functions into a hierarchy (FBD). Now use all the above to perform Functional FLOW analysis and block diagrams (FFBD).

11. Functional Flow Block Diagram Use the “Input – Process – Output” construct (IPO) –UML USE CASES can be helpful Identify the “actors” of the system Identify what goes “into” and “out of” the system Use the FBD to begin to understand the “flow” Helps find additional requirements & interfaces –Not all functions will allocate to the “IPO”, as some belong to physical characteristics Grouping functions into “lower tier system elements” can now be started System States & Modes now become evident Ready to map system requirements onto the functions Ensure the external interfaces are all accounted for

12. 12 States and Modes Where do they come from? –Mission analysis, scenarios, timelines, block diagrams & functional flow analysis Every system has at least two states –Off –On Most have three –On –Off –Maintenance Look at the system design mission, phases, and timeline Draw bubbles with directional arrows You want “legal” transitions and prevent illegal transitions.

13. 13 Architecture Block Diagram Architecture is a series of views into the solution space for the system –Physical –Logical –Behavioral –Operational ABD is a block diagram of the decomposed system –Hardware, Software, Data, People (knowledge, skills, abilities) –Tools, Support equipment, Special test equipment (STE) –Facilities, Training, Technical Data (publications)

14. Requirements Allocation Total System WEIGHT < 5 K lbs. Product #3 WEIGHT < 1.5 K lbs. Product #2 WEIGHT < 2 K lbs. Product #1 WEIGHT < 1.5 K lbs. Weight Allocation Reliability Analysis & Allocation Life Cycle Cost Analysis Design-to-Cost Cost Allocation FBD & Mission Event Timelines FFBD & Mission Profile (1 – n) Data Flow & Control Flow Architecture Decomposition Interface Analysis & Decomposition Other Specialty Engineering Analyses

15. 15 Schematic Block Diagram Denotes INTER-FACES & INTRA-FACES Numbered –Blocks –Inter-face & Intra-face lines Fits with the Physical Architecture Block Diagram Uses the “grouped functions” to identify the blocks Works with developing the Product Breakdown Structure Has some of the Specification Tree elements

16. 16 Specification Tree Hierarchy of documents needed to specify the requirements, design and interfaces of the system solution 9 types of specifications See spec tree examples on page 95 and 103, 678 text book

17. Planning for IV&V Requirements decomposition must be TRACEABLE –Top down, parent to child, other attributes –Determine verification method (I, A, D, T, M/S) Describe the basic test case –Who, what, when, where, how, why, integration level –trace to requirements, test procedures & integration –Criteria for pass/fail Gather test cases into test case description or a higher level test plan –System, product, component –Acceptance testing, qualification testing, validation –Audits (Functional & Physical) Test & Evaluation Master Plan (TEMP) –Based upon plan for system integration –Documents ALL THE TESTING needed to verify the system is ready for VAL Master Compliance Matrix (MCM) –Completeness of requirements verification –Qualification of components & products of the system architecture

18. Requirements to Design Requirements Analysis Requirements Development Requirements Allocation To Functions Reqmt-Functn Allocation To Architecture Functional Analysis Functional Flow Analysis Mission Analysis Mission Event Timelines Mission Phases Repeat @ Lower Architecture Interface Analysis Interface Decomposition Interface Allocation

19. System Architecture HardwareSoftwareDataFacilitiesTools & STETrainingPeople Tech Data ISS Destiny & Station Thrusters Attitude Control Position Data (x,y,z) ISS Main Control Station FCC Test Equip Attitude Control Manual Mode FCC Trouble Shooting Fault Trees Station Cmdr Subsystem level 6 Modules Attitude Control CSCIs Position, Voice, Telemetry, Fault Mon Health & Status ISS Main Control Station FCC Test Equip Attitude Control Manual Mode FCC Trouble Shooting Fault Trees Station Comdr Nodes Docking Ports Air Locks Environmt Control CSCI Station Health & Status CSCI TRUSS (P&S) HardwareSoftwareDataFacilitiesTools & STETrainingPeople Tech Data 6 Crew Members

20. ISS REQUIREMENTS 1.The station shall survive (no loss of internal pressure) at least 20 micrometeorite impacts per 24 hr period on orbit after achieving FOC. 2.The station shall operate continuously for 20 years after at least 5 main modules are installed. 3.The station shall provide essential power through solar radiation collection to supply at least 100K Watts per standard earth day. 4.The station shall maintain on orbit position using self-contained propulsion for attitude and altitude control. 5.The station shall maintain a positive pressure, breathable atmosphere of at least 14 PSI. 6.The station shall provide at least 50% of normal power through self- contained, renewable, emergency power. 7.The emergency power shall automatically engage in the event the essential power drops below minimum operational levels. 8.The emergency power shall reports is status continuously to station monitoring and control. 9.The station shall provide essential structural framework and common interfaces for physical connectivity of extensible, modular station elements. 10.The station shall maintain a continuous fire detecting and alarm (audio and visual) capability on both essential and emergency power.

21. ISS Functions Support on-orbit human habitat 2.0 Provide pressurized breathable atmosphere 4.2 Maintain orbital attitude 3.0 Provide structural framework for extensible station 4.1 Maintain orbital altitude 5.2 Provide common interfaces 1.0 Protect against micro meteorites 5.1 Provide essential power 2.2 Scrub CO2 2.1 Store & mix breathable gasses 2.3 Recycle atmosphere 4.3 Store & distribute propellant 5.3 Provide emergency power 4.0 Maintain orbital position 5.0 Provide station power

22. Functional Flow 5.3 Provide Emergency Power Store Emergency Power Monitor Essential Power Level Detect Loss of Essential Power Connect Emergency Power Detect Return of Essential Power Disconnect Emergency Power Provide Status of Emergency Power Level AND 5.3.2 5.3.35.3.45.3.5 5.3.65.3.7 5.3.1

23. ISS Interfaces Physical –Main structural connectivity –Docking hardware & Ports –Air locks Fire monitoring, detecting, alarm (audio & visual) Fire suppression Electrical –Essential power –Emergency power –Data paths for monitoring & control of docking Alignment targets Cues and range measurement Communications (digital) for docking signals Logical –Control flow –Data flow –Data storage

24. ISS Schematic Block Diagram LAB Module Nodes 1,2,3 Fuel & attitude propulsion PIRs Docking port DestinyZarya & Zveda Core Modules Port Sections 1 - 6 Stbd Sections 1 - 6 Main Trusses Truss Segments Grnd Control Shuttle Progress & ATV ISS – SOI (on orbit elements) Solar Radiation & Flares Micrometeorites Give EVERY Interface line an ID I-003 I-001I-002 I-004 I-005 I-006 I-007 I-008 I-009I-010

25. ISS REQUIREMENTS - ALLOCATED Reqmt IDReqmt TextFunction IDVERLevel of VERRATIONALE ISS0001The station shall survive (no loss of internal pressure) at least 20 micrometeorite impacts per 24 hr period on orbit after achieving FOC. 1.0 ASystem – at least 4 modules + Trusses 20 hits on single module too extreme ISS0002The station shall operate continuously for 20 years after at least 5 main modules are installed. ASoS with all modules & trusses Full system connectivity needed ISS0003The station shall provide essential power through solar radiation collection to supply at least 100K Watts per standard earth day. 5.1TAnalysis & TPM, test on orbit All trusses installed with full panels ISS0004The station shall maintain on orbit position using self-contained propulsion for attitude and altitude control. 4.0DAnalysis & TPM, prove on orbit Decompose for accuracy of pos ISS0005The station shall maintain a positive pressure, breathable atmosphere of at least 14 PSI. 2.0TModule level, then on orbit full test Each module must satisfy – also ISS ISS0006The station shall provide at least 50% of normal power through self-contained, renewable, emergency power. 5.3 Provide Emergency Power TSubsys - Analysis, power budget TPM Demo a full cross over with all trusses ISS0007The emergency power shall automatically engage in the event the essential power drops below minimum operational levels. 5.3.4 Connect Emergency Power DSubsystemDemo in lab & full ISS mockup ISS0008The emergency power shall reports is status continuously to station monitoring and control. 5.3.7 Provide Status of Emergency Power Level DSubsystemDemo in lab & full ISS mockup ISS0009The station shall provide essential structural framework and common interfaces for physical connectivity of extensible, modular station elements. 3.0AModule Interface ICD Common hardware interface spec ISS0010The station shall maintain a continuous fire detecting and alarm (audio and visual) capability on both essential and emergency power. TSubsystemDemo in lab & full ISS mockup