Presentation is loading. Please wait.

Presentation is loading. Please wait.

SRD Development Process Using Model Based Systems Engineering

Similar presentations

Presentation on theme: "SRD Development Process Using Model Based Systems Engineering"— Presentation transcript:

1 SRD Development Process Using Model Based Systems Engineering
Altair Project Integration Robert Bayt - NASA Ann Christian - 3SL Inc. Philip Nerren – Integrated Thought

2 Overview Agenda Introduction Background
Model Based System Engineering Methodology Using CRADLE Example – application to Altair (Lunar Lander Vehicle) Acknowledgements Robert Bayt Ph.D. – Altair Lead System Engineer, NASA JSC Houston Ann Christian – Altair System Requirements Manager, 3SL Inc. Philip Nerren – Project and Systems Integration Office, Integrated Thought Corporation Agenda JIMO – Jovian Ice Moon Orbiter, being developed at JPL with some initial assistance from MSFC.

3 Background Altair (lunar lander) is a key component of the lunar capability for the Constellation Program. Altair project management desired to have a systematic, complete and traceable development of their needed design and operational requirements. A formal requirements development team was formed to create this, including the necessary data infrastructure and tools.

4 Enabling Process Management
3SL Enabling Process Management “A management process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design and operational information throughout its life.” (ANSI/EIA , National Consensus Standard for Configuration Management) Integral Part of the Systems Engineering Process Enables efficient system changes, upgrades and deployments Rapid recovery from failure

5 Processes: Understand and Customize
MBSE Database Structure Depends on the System Engineering Processes Supported. Identify the Database Structure (Item Types, Attributes, and Cross Reference Link Rules) needed to support each of your Project’s Processes.

6 Defining and Managing Relational Data via Model-Based Systems Engineering Approach
Requirements Gathering & Operational Analysis Functional Behavior Analysis System Architecture Analysis Identify Source Material, Operational Context, Use Cases, Scenarios, Information Exchange Establish Initial Requirements Set Establish Design Constraints Capture Issues / Risks / Decisions System Structure (i.e., Hierarchy of System Elements) Interfaces between System Elements Allocate Functional Behavior and Non-Functional Requirements Operational Scenarios Integrated Behavior Models Derive Functional / Performance Requirements Define I/O Define Effectiveness Measures A C Requirements Model B Functional Models System Architectures R1-1 R1 R2 R Issue Risk F1 F5 F2 F3 F4 System of Systems Interfaces Equipment List Product Evaluation & Document Generation Risk Assessment Compliance & Cost Assessment Design Verification & Validation Test Planning Select Design Solution Document Generation Analysis Results Technical Rules, Standards, and Conventions Specifications These Primary Concurrent / Iterative Activities Are Performed For Each Product/System Architecture Design Layer.

7 Requirements Traceability in MBSE Approach
Map requirements into the rest of the project’s engineering information. Source Material Analysis Models Requirements R104.1 R104.3 R104 R104.2 R R R Design Models Issue A Issue B Issue C Issue D Issue E Issue F Issue G Issues Risk A Risk B Risk C Risk D Risk E Risk F Risk G Risks and so on...

8 Traceability Between Models
The System Architecture View at a specific level in the System Hierarchical Structure is created by cross referencing Items in the three kinds of Product Models. This is Horizontal Traceability. Operational Processes Horizontal Traceability Architecture Models Requirements Model Func 1 Data Func 2 Func 4 Func 3 allocated to Satisfies assigned to Equip X.3.1 Science System Ground System Launch System Interface Level 1 Rqmt Level 2Rqmt 1.1 Level 3 Rqmt 1.2.1 Level 3 Rqmt 1.2.2 Level 2 Rqmt 1.2 System Functional Models Traces to Mission 1 Mission 2 Pre - Launch On orbit Operation Scenario #3 Operational Scenario #1 Point Camera Take picture Operational Scenario #2 Store Note:

9 Processes: Data & Model Hierarchy Definition
These System Architecture Design activities are used to: Transform agreed-upon source requirements and constraints into a design solution. With a proper balance between performance, risk, cost, and schedule. Requirements Gathering & Operational Analysis Functional Analysis System Architecture Product Evaluation Document Generation Stakeholder Needs Source Material System Behavior Threads Integrated Model Allocated Interfaces Design Layer “1” Constraints Structure Operational Context, Use Cases, Scenarios Requirements Subsystem Architecture Subsystem “n” in Layers A C B Spec

10 Architecture Modeling is Key to Process
Lift Off Return to Earth 8 LL & LM Earth to LEO 1 LLO Ops 5 LLO to LS 6 Surface Ops 7 LEO to LLO 3 AND SM & CEV 2 CEV & SM 4 Ground Support System ENV Mission Model Thermal Meteors Science Data Science Rqmt Desires Uplink/Downlink CDS Health Launch and Mission Support Comm Nav ETO Transportation Environmental Regulators Space Weather System Health Communication_ Navigation Regulations Launch & Missile Crew 1 Cargo Delivery 2 Ground 3 Robotic Precuser 4 In Systems 5 Destination Surface 6 Flight Environment Launch Service Provider Community Public Lunar Physical Interface Architecture System Definition Develop Allocated Architecture Develop Physical Architecture Develop Functional Architecture Manage Process Write Specification & An example. The sequence and concurrency of functions above are allocated onto the components. Tools keep these traceability links for subsequent analyses.

11 Processes: Schema Determination
Sample schema from MBSE project:

12 Initial MBSE System Engineering Schema
Passes Through Interface Data Doc Section Studies Analysis Sends/ receives joins traces to documents Studies traces to performs Requirement Function Equipment Trade Option Set Supported by verified by Exhibits Verification Requirement Characteristic Issue generates External Programs This is the current Exploration Schema – to be used for the development of all of the Exploration Specifications in CRADLE. Note: Requirement has links to Functions, Equipment (i.e., components), Analyses, Trades, Issues, Risks, etc. Each requirment should be linked to a verification Requirement (says how to verify it), which is linked to a verification event (i.e., when). Functions input and output items (data, fluids, commands, power, etc), which “passes through” and interface. Functions, requirements, etc. are included in different “document sections” which are used to build specifications and other project documents. satisfied by causes Risk uses config Verification Event defined by Test Procedure Test Configuration Documented by External Resource

13 Relational Data Across Systems Engineering Process

14 Process/Configuration Management
3SL Process/Configuration Management Process support without configuration management results in extra costs associated with: Figuring out which system components to change when requirements change Re-doing an implementation because you implemented to meet requirements that had changed and you didn’t communicate that to all parties Losing productivity when you replace a component with a flawed new version and can’t quickly revert to a working state Replacing the wrong component because you couldn’t accurately determine which component needed replacing

15 Why Use a MBSE Tool Customer Interface
The Difficulty - Many projects suffer from: Inefficient Sharing of Project Knowledge. Lack of Well-Understood, Well-Documented Processes. The Goal - Projects need the following to provide efficient information sharing and quality products: Qualified people, effective tools and a robust information repository. And a well defined Systems Engineering Process. MBSE was selected by NASA Exploration to aid the project in: The management of complexity. Agency sharing of project knowledge. Developing quality products. System Updates Detailed Design Systems Architecture Modelling Test Requirement Management Capture Acceptance & Signoff Build Evaluation Performance Assessment Analysis Customer Interface

16 Model Based Systems Engineering
System Definition Functional Architecture Requirements Model Functional Model Translate User Operational Capabilities to System Functional Requirements Graphical Analysis Provides Increased Rigor (versus text only) Functions Inputs/Outputs Time Sequence Logic Scenario Development Operational Simulation Establish Source/Originating Requirements Structured Hierarchy and Flowdown Managed Traceability Level I to Derived Requirements Requirements to Simulation and Verification Elements Allocated Architecture Physical Architecture Analysis Model Physical Architecture Model The role of tools like CRADLE is to support the definition of the functional model, and maintain the traceability links between requirements, functions, components, and their requirements. Requirements documents can be generated from this information, as well as a number of analyses. Validate Performance Requirements Model Update Functional Model Execution via Discrete Event Simulation Timeline Analyses Resource Analyses Quantitative Benefits Analyses Validation of Logic Candidate Physical Architectures HW, SW, Interfaces Human Operators Allocate Functions to Components Platform Compatibility Assessments System Physical Architecture Definition

17 ALTAIR (Lunar Lander Vehicle)
Example Application ALTAIR (Lunar Lander Vehicle) Jovian Ice Moon Orbiter project.

18 Interrelationships Among the System
Design Processes as Stated in NASA SE Handbook Trade Studies & Iterative Design Loop (3 Products must be consistent) Developed Activity Models 1. Derive Altair LCAPs Mission Objectives & Constraints Operational Objectives Mission Success Criteria (MOEs) Stakeholder Expectations 7. Decompose/ Rebuild to complete system level eFFBD Next Level 2. Link/Review CARD Reqs To LCAPs Design & Product Breakdown Structure Derived & Allocated Reqs Func Perf Interface Operational Illities 4. Identify LCAPs gaps 5. derive new Altair reqs 6. categorize Reqs Start High Level Requirements Functional/ Logical Decomposition Altair Hierarchy 3.Build Altair eFFBD; 8. Allocate Func/Perf Reqs to Altair System Functions Hierarchy Defined to meet Requirements Altair PFDs Linked to Capabilities Generate Altair OpsCon CONOPs Stakeholder Expectation Definition Functional & Performance Analysis Sufficient Depth? Technical requirements Definition NO Functional / Logical decomposition Decompose To level where Allocation can occur Functional Scenarios built thru hierarchy to Validate against Expectations/PFDs Design Solution YES NO Design Analysis ReBaseline Requirements? Work? Safe & Reliable? Affordable? NO YES Select Baseline YES If Altair doesn’t agree with Reqs Must pushback to level 2 All -ility Reqs met within budget?

19 Hierarchy of Product Traceability
Rules/Assumptions DRM Phase Models will be developed for all DRMs (LSC, RLO, VLO,ORO, UCL) Phase models with LNDR phase Ops Con descriptions linked will contain the Altair OpsCon mission phase definitions Capabilities may be linked to multiple Activity models, They must have a textual definition developed Capabilities may have multiple types of CARD or Derived requirements linked to them All CARD (allocated to Altair) requirements categorized as functional or performance must be linked to an LCAP All CARD Functional/Performance Requirements linked to LCAPs are grouped to derive the high level Altair FFBD (these will be linked to Altair system functions) LSC Phase Model VLO Phase Model LSC DRM Phase Model DRM Mission Phase Models Phase Models Further Define Phases LSC Phase Models Activity (Scenarios)Models LNDR Phase Ops Con Descriptions Capabilities Capabilities One or multiple capabilities Linked to LNDR Activity PFDs Capabilities Capabilities CARD Requirements in Altair 3.2 Requirements Derived from Capabilities All types of Requirements Derived, Categorized and Linked to Capabilities Derived Altair 3.2 Requirements Altair FFBDs (System Level/Hierarchical) Only Functional/Performance Requirements Linked to Altair FFBDs

20 Altair Traceability Process
Derive Altair Operational PFDs LNDR Analysis.1 Link Requirements LNDR Analysis.2 Build System Functional Architecture LNDR Analysis.3 DRM OCD Cx Mission Phase Model PFD Phase Models Capabilities Linked to CARD 3.7.3 Reqs LCAPs Missing Derived Developed High Level Altair FA eFFBDs Func / Perf Reqs for FA Populated Perf Characteristics 3.2.1 Reqs High level Traceability Model shows: The flow of the process to ultimately get to the proper set of requirements to populate SRD doc section 3.2.1 The inputs/outputs of the major activities showing how each activity impacts other activities Each of these process activities is further decomposed to define the specific tasks to define Altair functionality and Derive functional and performance requirements

21 Derive Altair Operational PFDs
Identify Altair Mission Phases LNDR Analysis.1.1 Develop Ops Models for Phases LNDR Analysis.1.2 Define Capabilities for Ops LNDR Analysis.1.3 Reviewed DRM OCD Cx Phase Model Assigned for Altair Developed Representative Ops Models LCAPs Derived and Linked Analyze LSC DRM Model to identify in which Phases Altair will operate Read and become familiar with the CxP to understand system descriptions and Phase definitions Develop Altair PFD activity models which define how Altair will be operated and identify inter-system comms Derive Capabilities which will ensure or identify gaps or inconsistencies with existing CARD requirements Developed Activity Models Derive Altair LCAPs

22 Lunar Sortie Crew DRM start See RPOD Sub-Phase PFD (next slide) I LSC
Owner: RBAYT Versn : Dft : A Created: 28/03/08 PFD DRM: Lunar Sortie Crew Baseline: Last Mod: 30/03/08 Update in work Pwrd TLI Burn Start LOI LOI Burn Descent Initiate ATP Pre-Descent Complete Burn Prep Complete Initiation Burn Prep Pre-Surface Lunar Lunar Ascent TLI Trans - Lunar LOI Lander Surface and RPOD Preparation Cruise Operations Operations (LDO) Descent AND Operations AND Operations LSC.9 LSC.10 LSC.11 LSC.12 LSC.13 LSC.14 (LRO) Docking LSC.16 Docking Complete RPOD Lunar Complete Operations See RPOD Sub-Phase PFD (next slide) (LEO) Orbit Maintenance TEI LSC.8 Initiate LSC.15 Operations Rendezvous LSC.17 Burn TEI Burn LEO Loiter Complete LSC.7 'Go' for Earth Trans - Orbit Ops LEO Cruise Final Configuration LSC.18 Entry Prep (Post-Insertion) <EI-12> Orbit LSC.6 Insertion Earth MNVR Arrival Complete Operations Ascent LSC.19 SM LSC.5 Separation T - 0 Re-entry/Entry Launch LSC.20 Fwd Bay LSC.4 Cover Jettison LCD CTS start Stand Descent Pad Integrated Post - Flight Alone Recovery and Operations Operations Operations Processing Landing LSC.3 LSC.2 LSC.1 LSC.23 LSC.22 LSC.21 Arrival OPS Models Developed Transport to MLP Hard Integration Post - Flight Down Facility DD250 Facility Touchdown OPS Models Complete Complete Processing CRADLE V5.6 Produced by: RBAYT Date: 03/04/08 Page: 1 of 1 UNCLASSIFIED

23 Initiate Rendezvous Burn Docking Complete LEO Prep RPOD.1 Prox Ops RPOD.2 Post Dock Operations RPOD.3 RPOD.4 RPOD.5 Target Reached - Nav State for LEO Orion Terminal Phase Initiation for Event * 1 hour * * 3 hours * * 1.5 hours * * 30 minutes * RPOD Phase PFD This Diagram Spec will be linked to LSC.8 RPOD Operations (LEO) Spec This Diagram Spec may be linked to other DRM RPOD Specs, if it applies This Diagram Spec will have an Altair Ops Con Definition written to describe Altair operations during this phase * LSC.8 RPOD Operations (LEO) - 6.5 hours * CRADLE V5.6 Produced by: ACHR_A Date: 09/03/08 Page: 1 of 1 UNCLASSIFIED

24 Altair Activity Model for LEO Rendezvous Prep
Develop Altair Activity PFD, derive LCAP(s) for This Diagram Prep - 1 hour * Relay Altair EDS AND AND Data & Comm AND AND LEO_RPREP.1 Maintain EDS/Altair LEO The spec for this diagram Will be linked to the LEO Rendezvous Spec contained In the RPOD Operations phase model Loiter Attitude LEO_RPREP.2 Sustain Lander - Altair RPOD AND Operations AND (LEO) LEO_RPREP.3 Activate Activate RF Comm Approach Lights LEO_RPREP.4 LEO_RPREP.5 Activate Activate Altair RF Altair comm approach command lights command Activate Altair RF Activate comm for Altair Target Initiate Orion AND Cmd Tlm Approach Reached - Rendezvous and Lights AND Nav State Burn Ranging for LEO LEO_RPREP.7 Rendezvous LEO_RPREP.6 Perform Initial Rendezvous Burn LEO_RPREP.8 Monitor Lander Mission Ops Health and Status LEO_RPREP.9

25 Workbench View of LEO_P_Dock Specs
RPOD Phase Spec LEO_P_Dock Activity Linked to phase , RPOD.5 Post Dock Operations LEO_P_Dock Activity Model Spec

26 Workbench View of RPOD Spec Linked to
LNDR OPS CON Item This is the RPOD Spec for the phase model This Ops Con item is Linked to the RPOD Sub-Phase Diagram Spec… A new Ops Con item Is developed that Contains the Altair RPOD Phase Definition

27 DRM Analysis Recap DRM Models will be developed for each DRM
LSC, VLO – Visiting Lunar Outpost, RLO – Resident Lunar Outpost, ORO – Outpost remote Operations, UCL – Uncrewed Cargo Lander Show how scenarios will be used to address different DRMs C LSC RPOD VLO RPOD RLO RPOD ORO RPOD RPOD Phase Model may be linked to multiple DRM Models LEO Rendezvous Prep RPOD.1 Prox Ops RPOD.2 Post Dock Operations RPOD.3 RPOD.4 Docking RPOD.5 RPOD LNDR Phase Ops Con Descriptions Shared Systems Activity Models (scenarios) will be developed for a specific phase activity ( LEO Rendezvous) OCAP Activity Model ACAP Lander OpsCon Phase definitions will be developed as an OpsCon items Other systems could also extract capabilities from these models LCAP LCAP LCAP Capabilities will be developed and linked to the Altair Activity Models (scenarios) Specs

28 Functional/Performance
Link Requirements Review / Categorize CARD 3.7.3 Reqs LNDR Analysis.2.1 Identify 3.7.3 Functional/Performance Reqs LNDR Analysis.2.2 OR Link All Func/Perf Reqs to LCAPs LNDR Analysis.2.3 Link any other Reqs That Apply to LNDR Analysis.2.4 Derive Additional Reqs As Needed LNDR Analysis.2.5 Recommend Reqs be Developed LNDR Analysis.2.6 Requirements Categorized Altair Derived and Linked Linked Reqs Gaps Identified Applicable Linked to Other New as LNDR Candidate CR for New CARD All Other (Steps 2 – 6) Review and categorize the CARD Requirements (approximately 108 requirements) (Step 6) Consensus on categorization by technical team accomplished Identify functional and performance requirements, these must be linked to LCAPs, these will drive the Functional Architecture to achieve defined operations (approx 57 identified, 28 linked) Identify possible unachievable CARD functional/performance requirements Identify CARD requirements gaps, concentrate on functional performance gaps (Step 4) Derive new LNDR requirements that fill identified gaps identify those that will become (Step 5) new CARD Requirements (these will be identified as R.LNDR* as candidate Status) (11 new reqs derived to date Link all requirements that fulfill the derived LCAPs to LCAPs (Step 2) Develop CARD CR to have new requirements reviewed and copied as R.EA requirements

29 STEPS 2-6 C C RPOD Phase Model may be linked to multiple DRM Models
LSC RPOD VLO RLO ORO RPOD Phase Model may be linked to multiple DRM Models RPOD Operations LEO LEO Docking Post Dock Rendezvous Prox Ops Rendezvous Operations Operations Prep RPOD.2 RPOD.4 RPOD.5 RPOD.3 RPOD.1 C Activity Model Capabilities will be developed and linked to the Altair Activity Models (scenarios) Specs LCAP LCAP LCAP LCAP LCAP LCAP AND Perform Communications LNDR.1 Sustain Altair Environment LNDR.2 Command & Control LNDR.3 Maneuver LNDR.4 Manage Vehicle Performance LNDR.5 Transport LNDR.6 Each LCAP must have a Req linked to it, if no CARD Req is applicable gap is identified Reqs linked to LCAPs will be categorized (must have a func or perf Req linked to an LCAP) REQ Types will be identified, for now identify func / perf / constraining Derive new Req if Gap is identified for LCAP Req 3 Req 2 Req 1 Func/Perf Reqs Drive Functional Arch

30 LSC DRM Trace To Altair Functional Architecture
LSC DRM Phase RPOD Phase RPOD Activity Altair Activity Model Spec Capability Derived for Altair LEO Rprep Functional Req Linked to LCAP Functional Req Drives FA (Linked to Func)

31 Query: Ops to LCAPs to Reqs to Func
Traceability Report Operational Specs From Activity Models, Phase Models, Phase Models LCAPs Requirements Linked to LCAPs Functions Linked to Requirements

32 Build Altair Functional Architecture
Group All Func/Perf Reqs into Functional Groupings new.1 Derive Functions/eFFBD Based on new.2 Validate FFBD by Ensuring Against Ops Model new.3 Link All Reqs to Functions new.4 Linked CARD 3.7.3 LCAPs New Reqs Linked to Identified Derived on Construct/ eFFBD Developed Validated Develop Threads new.5 System eFFBDs Functional/Performance Analysis AND Decompose To System Allocation Level new.6 Allocate functions To Altair Spec new.7 Allocated Link High FFBD to SRD Section 3.2.1 new.8 Populated Altair Perf Characterisitics 3.2.1 Reqs Group all the designated and newly derived functional and performance requirements into functional groupings Draft an eFFBD based on groupings, identifying high level Altair functions Step 3 Validate that eFFBD defined the functionality at the highest level to meet operational needs derived in PFDs Step 7 Link all functional and performance requirements to capabilities and system level functions (may be at lower level in system eFFBDs) Step 8 Allocate all functions in system level eFFBDs to the Altair shared equipment spec Develop top level functional thread scenarios that support system operations to ensure system functionality supports operational needs developed in the PFDs and derived capabilities Once the eFFBDs are agreed to by team, the highest level system eFFBD will be linked to the LNDR_SRD doc section Altair Performance characteristics in order to generate this SRD draft

33 WHAT Do We Want to Specify?
Control Environment Treat the Vehicle as a Black Box (Inside and Out) Communication Can people live out of it? Can it interact with the outside world? Transport Can it carry Payload? Command and Control Can it take action upon Command? Vehicle Management Can it move and follow a trajectory? Maneuverability Altair Functional Architecture Can it assess its own status? Establish the purpose of the System; Define Functions and Measures that Implement and Quantify achieving the Purpose

34 High Level Altair eFFBD (Draft)
LNDR Owner: ACHR_A Versn: Dft: A Created: 07/29/08 BD Carry Crew & Cargo to Lunar Surface Baseline: Last Mod: 09/03/08 AND Perform Communications LNDR.1 Sustain Altair Environment LNDR.2 Command & Control LNDR.3 Maneuver LNDR.4 Voice Comms Commands to Altair Data Relayed Crew Actions Command_ Health and Status of Lander Systems External Power Navigation Guidance Status Manage Vehicle Performance LNDR.5 Provide Transportation Habitability LNDR.6 to Cx Fault Detection Recovery State Vector Updates Command Execution Ingressed Ground Personnel Cargo Mounted Egressed Off-Loaded Environmental Set Points KEY Function Discrete Item Timeline Data Link Trigger Data Link CRADLE V5.6 Produced by: RBAYT Date: 09/03/08 Page: 1 of 1 UNCLASSIFIED

35 Command and Control OR Receive Commands on Lander LNDR.3.1 Accept
Crew Input LNDR.3.2 Check Command Validity LNDR.3.4 AND Provide Execution Status LNDR.3.8 Execute Command/Command Sequences LNDR.3.6 Send from LNDR.3.7 Prioritize LNDR.3.5 Vehicle Manager LNDR.3.3 Fault Detection Recovery Crew Actions to Altair

36 Requirements linked to Command & Control

37 Principles of eFFBDs eFFBD – enhanced Functional Flow Block diagram, showing functions, their ordering, their inputs (stimuli) and their outputs (responses), control operators (and, or), and their composition (definitions) Behavior – Describes “what” a system is to do, independent of “how” the system is to do it (this is the purpose of eFFBDs) High level Functions – represent complex functions, as design proceeds lower levels are reached, these high level functions provide the basis of all lower level functional definition. Numbers are used to label the function blocks and placement of the functions within the hierarchy Function – Accepts inputs then transforms them to outputs, functions are stated with action verbs preceding the “what”; example: Operate Tool. Functions consume inputs and produce outputs. Functional Requirement - should specify the required behavior of the entity and should include applicable parameters such as response times, sequencing, accuracy, capacities (how much/how many), priorities, continuous operation requirements, and allowable deviations based on operating conditions.

38 Recap Of Functional Analysis
Functional Architecture (FA) is originates from: Operational Analysis (OpsCon Models) Developed Capabilities from models CARD Driving requirements linked to capabilities High Level Functional eFFBD developed in a Parallel Construct showing that in this level functions occur simultaneously Functions are leveled by the allocation that is made, only to system due to fact specific allocations cannot be made based on level of requirements linked Functions are stated with action verb, defining the What, example: “Perform” Functions must have input(s) or stimulus and output(s) or repsonse, without performing a process, not need for function CARD requirements that drive FA are categorized as functional or performance requirements

39 Altair eFFBD Specs to Reqs
User Type Query Called: LNDR FFBD Specs to Reqs

40 How Detailed do we want to Specify it?
NASA will be the Owner/Operator of the vehicle, and needs to provide enough detail to ensure the operation and maintenance complies with our concept of operations Need to capture Operational Capabilities of the ‘Vehicle as a Whole’ that would be required in ALL Scenarios Primary Mission (All DRMs) Aborts Ground Processing Disposal Need to establish what Actions the user can take, and what data they need to make decisions/take action Need to capture the attributes of these capabilities and to what performance level Common attributes that apply to all systems Unique attributes that require more than one system to achieve The requirements need to be a level of detail that ensures NASA can assess compliance or perform a Qualification test (i.e. Verify the Design) The SRD must capture the finish line for the vehicle. If it is not specified, there is no guarantee you will get what you need.

41 States and Modes State: The condition of a system or subsystem when specific modes or capabilities (or functions) are valid. Defined by the values of a set of state variables Mode: The condition of a system or subsystem in a certain state when specific capabilities (or functions) are valid. Each mode may have different capabilities defined. Types of Modes: Normal, Emergency, Start-up, Training Proposal: The State of the Vehicle will be mode setting of each function. States can have properties that prevent certain modes from occurring simultaneously (e.g. Training and Powered Flight modes) Subsystem/State Coast State Crewed Powered Flight Life Support Dormant Normal Thermal ½ Capacity Power System External Power Full Power Propulsion Attitude Control about Deadband Active MPS GN&C Active

42 Sustain Lander is the state that enables Operations
Modes Modes enable capabilities. They bring the subsystem to a point that it is ready to execute Phase-specific tasks. Activity Models should describe Operations Unique to accomplishing that phase In parallel, a sustainment function should capture the functions that enable these activities. Sustain Lander is the state that enables Operations Activate Comm Activate Lights Resource Utilization Sustain Lander 42

43 Transport and Habitability
Modeling Sustainment Sustainment functions will be Functional Threads of the basic Architectural Activities Need to Model the various Modes of the Primary Functions Modes should capture capabilities, not set points Cabin regulates between 7 and 12 psi, not cabin is set to 10.8 psi Link modes to various Phases Should only have to model a handful of modes per Function Can copy the Architecture to each thread and elaborate only the unique capabilities Threads will generate capabilities Sustain Lander - TLI Operations (LEO) Sustain Lander - LOI Operations (LEO) Sustain Lander - Surface Operations (LEO) Phase Perform Communications LNDR.1 Sustain Altair Environment LNDR.2 Command & Control LNDR.3 Maneuver (Off) LNDR.4 Maneuver (Free Flying Powered Flight) LNDR.4 Maneuver (Shadow) LNDR.4 Maneuver (Integrated Stack Powered Flight) LNDR.4 Mode Manage Vehicle Performance LNDR.5 Transport and Habitability LNDR.6 43

44 Modeling Sustainment Capabilities should be written against the Modes
The capabilities are then linked to Requirements in the Functional Architecture This linkage justifies why the range of performance requirements are set. Question: Do we really need thread models, or can we just hook capabilities to Sustain Ops? Mode Independent Functional Architecture Sustain Lander - TLI Operations (LEO) Sustain Lander - LOI Operations (LEO) Maneuver LNDR.4 Phase R.LNDR123 Maneuver (Integrated Stack Powered Flight) LNDR.4 Maneuver (Shadow) LNDR.4 Mode R.EA5290 Mode Thread Unique to function SRD is Developed from Functional Model Threads justify span of performance Reqmnts Mode Unique Capabilities Perform Integrated Stack Attitude Control Perform Integrated Stack State Estimation 44

45 Physical Architecture Diagram (PAD)
Context Diagram Altair Context Model: Shows External interfacing systems Lines between Altair and external systems illustrate interfaces between Altair EVA Interfaces EVA Altair Altair Ground Systems Altair C&TN C&TN Altair Mission Orion Iterfaces Crew Altair Altair to Crew Induced Environment Natural to Altair EVA C&TN Space Environments

46 Integration of Functional & Physical Models
Altair EVA Interfaces EVA Altair Altair Ground Systems Altair C&TN C&TN Altair Mission Orion Iterfaces Crew Altair Altair to Crew Induced Environment Natural to Altair EVA C&TN Space Environments Functional Interfaces Carried by “Physical” Interfaces AND Perform Communications LNDR.1 Sustain Altair Environment LNDR.2 Command & Control LNDR.3 Maneuver LNDR.4 Voice Comms Commands to Altair Data Relayed Crew Actions Command_ Health and Status of Lander Systems External Power Navigation Guidance Status Manage Vehicle Performance LNDR.5 Transport LNDR.6 to Cx Fault Detection Recovery State Vector Updates Command Execution Ingressed Ground Personnel Cargo Mounted Egressed Off-Loaded Environmental Set Points And Node (Parallel) Altair Functions are allocated to Altair Equipment spec (system)

47 Altair Functional Model
Habitability The LSAM shall provide a habitable environment for a crew of four for a minimum of 180 (TBR ) hours during each lunar mission, beginning prior to separation from Orion in lunar destination orbit up to initiation of ascent from the lunar surface for Lunar Sortie and Lunar Outpost crew missions. Accept Commands from Vehicle Manager Communication Altair Accept Lander Crew Input Transport The LSAM shall provide an interface for the crew to generate commands for Lunar Sortie and Lunar Outpost crew missions. Receive Commands on Lander Command and Control Vehicle Management Maneuverability Common to all Landers Crewed Landers Only

48 Functional Model Drives Document
Habitability The LSAM shall provide a habitable environment for a crew of four for a minimum of 180 (TBR ) hours during each lunar mission, beginning prior to separation from Orion in lunar destination orbit up to initiation of ascent from the lunar surface for Lunar Sortie and Lunar Outpost crew missions. Accept Commands from Vehicle Manager Altair Accept Lander Crew Input The LSAM shall provide an interface for the crew to generate commands for Lunar Sortie and Lunar Outpost crew missions. Receive Commands on Lander Command and Control The LSAM shall execute valid commands which are addressed to the LSAM. Altair Section 3.2 3.2.1 Common Characteristics Common Performance Characteristics 3.2.2 Crewed Mission Characteristics Common to all Landers Crewed Landers Only Crewed Performance Characteristics

49 Altair Operational Model
LOI Burn Ops Activity Outpost OPSCON Item Sortie OPSCON Item Cargo OPSCON Item Outpost Mission Description Sortie Mission Description TLI Prep Activity TLI Prep Activity Cargo OPSCON Item Cargo Mission Description Crewed OPSCON Item Common to all Landers Crewed Mission Description Crewed Landers Only Cargo Landers Only

50 Altair Operational Model
Assign Model and OPSCON Item to Doc Section for Doc Pub TLI Prep Activity 1. Assumptions 2. Ops Capability by Phase 2.1 Ground Ops 2.2 Launch 2.3 LEO Ops 2.4 LEO Loiter 2.5 LEO Rndz 2.6 TLI Prep 2.6.1 Crewed TLI Prep 2.6.2 Cargo TLI Prep Common Mission Description Cargo Mission Description Crewed Mission Description Crewed OPSCON Item Cargo Mission Description TLI Prep Activity Cargo OPSCON Item LOI Burn Ops Activity Cargo OPSCON Item Outpost OPSCON Item Sortie OPSCON Item Cargo Mission Description Common to all Landers Crewed Landers Only Outpost Mission Description Sortie Mission Description Cargo Landers Only

51 Thread Analysis Thread Analysis is used to show how various sub-functions interaction in order develop a higher-level capability. Capabilities can be derived from the thread Requirements in Functional Architecture linked to threads Powered Flight New capabilities: Altair requires state estimation to X m SEP to accomplish sufficient maneuver control Altair requires Impulse control to Y Ns to achieve target accuracy.

52 Possible Abort Maneuver Thread
(Example) Access BDs in Toolset LABORT is the thread developed showing an Example system level Functional Thread for Altair Abort Functionality When building a functional thread only functions that will be performed to accomplish the “operation” should be included Once FFBDs are developed with inputs and outputs, only those inputs and outputs that provide the flow of comms, decisions, etc that accomplish the operation are included This process of doing functional analysis modeling exercises the validity of the functional architecture and may provides a way to generate possible test procedures to verify linked functional and performance requirements

53 Conclusion Benefits Observations Traceability from Stakeholder
Operational Need Functional Behavior Architectural System Affectivity Rationale for justifying why functionality is in the system Integrated, Comprehensive, and Complete Collaborative Interface Development and Management Relational Database Extensible Utility Impact Analysis/Awareness Observations Cultural issues MBSE has many interpretations Early in implementation Workforce training Modeling is a mind set not experience

Download ppt "SRD Development Process Using Model Based Systems Engineering"

Similar presentations

Ads by Google