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

Slides:



Advertisements
Similar presentations
Systems Engineering From a Life Cycle Perspective John Groenenboom Director Engineering – Mesa Boeing Rotorcraft Dec 12, 2007.
Advertisements

Mahmut Ali GÖKÇEIndustrial Systems Engineering Lecture 2 System Identification ISE102 Spring 2007.
System Integration Verification and Validation
S Y S T E M S E N G I N E E R I N G.
Ch 3 System Development Environment
EQUIPMENT VALIDATION.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Systems Analysis and Design Feasibility Study. Introduction The Feasibility Study is the preliminary study that determines whether a proposed systems.
Design Concepts and Principles
Management & Development of Complex Projects Course Code - 706
IEC Substation Configuration Language and Its Impact on the Engineering of Distribution Substation Systems Notes Dr. Alexander Apostolov.
SAE AS9100 Quality Systems - Aerospace Model for Quality Assurance
Development and Use of Architectures in System Engineering Rosalind Lewis USC-CSSE Workshop October 2007 © 2007 The Aerospace Corporation Motivated by.
Lecture 13 Revision IMS Systems Analysis and Design.
Chapter 2 Topics –Context-Level DFD –Entity-Relationship Diagrams.
Nov. 14, 2007 Systems Engineering ä System ä A set or arrangement of things so related as to form a unity or organic whole. ä A set of facts, principles,
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
TECH 101 Product Design and Manufacturing. TECH 1012 System Life-Cycle Engineering 2 Major phases in almost all products and in many cases services –Acquisition.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
Chapter 2 - Overview of the Systems Engineering Design Process1 Aerospace Systems Engineering Chapter 2 - Overview of the Systems Engineering Design Process.
IV&V Facility Model-based Design Verification IVV Annual Workshop September, 2009 Tom Hempler.
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
BAE SYSTEMS Overview of Systems Engineering at BAE SYSTEMS & ALENIA MARCONI SYSTEMS 8/10/2015/MS By Leigh Watton Friday 27th July 2001.
Effective Methods for Software and Systems Integration
Work Breakdown Structure
QUALITY MANAGEMENT SYSTEM ACCORDING TO ISO
Chapter 2: Overview of Essentials ISE 443 / ETM 543 Fall 2013.
S/W Project Management
INFORMATION SYSTEM APPLICATIONS System Development Life Cycle.
Software System Engineering: A tutorial
1 Lecture 5.2a: SEF Ch 8 SE Outputs Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Engineering System Design
Product Development Chapter 6. Definitions needed: Verification: The process of evaluating compliance to regulations, standards, or specifications.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
Space Systems Engineering: Functional Analysis Module Functional Analysis Module Space Systems Engineering, version 1.0.
Large Scale Software Systems Derived from Dr. Fawcett’s Notes Phil Pratt-Szeliga Fall 2010.
SYSTEMS ANALYSIS AND DESIGN LIFE CYCLE
Develop Project Charter
Request for Proposal (RFP)
DPE CSSW Process Model Annex A WP-400 ECSS Case Study.
Over View of CENELC Standards for Signalling Applications
Solar Probe Plus A NASA Mission to Touch the Sun March 2015 Instrument Suite Name Presenter's Name.
Capturing Requirements. Questions to Ask about Requirements 1)Are the requirements correct? 2)Consistent? 3)Unambiguous? 4)Complete? 5)Feasible? 6)Relevant?
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Effective SE Communication through Models and Representations David Long INCOSE Copyright © 2015 by D. Long. Published.
Software Engineering Lecture 10: System Engineering.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
2009 copyright Leslie Munday University Requirements Management and Traceability For IIBA By Leslie Munday.
© 2009 Artisan Software Tools. All rights reserved. Testing Solutions with UML/SysML Andrew Stuart, Matthew Hause.
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
Process Safety Management Soft Skills Programme Nexus Alliance Ltd.
1 ME Spring 2013 Introduction to Systems Engineering Session 3 Dr. Dan C. Surber, ESEP © Copyright 2013.
1 ME Fall 2014 Introduction to Systems Engineering Session 4 Dr. Dan C. Surber, ESEP © Copyright 2013.
CSE784 – Software Studio Jim Fawcett Fall 2002.
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Session 10 Dr. Dan C. Surber, ESEP
Session 2 Dr. Dan C. Surber, ESEP
Session 9 Dr. Dan C. Surber, ESEP
Chapter ? Quality Assessment
IEEE Std 1074: Standard for Software Lifecycle
Systems Analysis and Design
Session 5b Dr. Dan C. Surber, ESEP
CSE784 – Software Studio Jim Fawcett Fall 2006.
Software Requirements
Request for Proposal (RFP)
Analysis Procedures Goal Statement - Purpose of the Analysis
PSS verification and validation
ESHAC #8 Safety Readiness Review Thomas Hansson, ESH
Presentation transcript:

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

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

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

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)

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)

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

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

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 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

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).

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 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 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)

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 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 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

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

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 Lower Architecture Interface Analysis Interface Decomposition Interface Allocation

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

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.

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

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

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

ISS Schematic Block Diagram LAB Module Nodes 1,2,3 Fuel & attitude propulsion PIRs Docking port DestinyZarya & Zveda Core Modules Port Sections Stbd Sections 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

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 Connect Emergency Power DSubsystemDemo in lab & full ISS mockup ISS0008The emergency power shall reports is status continuously to station monitoring and control 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