Presentation on theme: "SRD Development Process Using Model Based Systems Engineering Altair Project Integration Robert Bayt - NASA Ann Christian - 3SL Inc. Philip Nerren – Integrated."— Presentation transcript:
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 Robert.L.Bayt@nasa.gov Ann Christian – Altair System Requirements Manager, 3SL Inc. email@example.com www.threesl.com Philip Nerren – Project and Systems Integration Office, Integrated Thought Corporation firstname.lastname@example.org www.ithoughtcorp.com
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.
Enabling Process Management A management process for establishing and maintaining consistency of a products performance, functional, and physical attributes with its requirements, design and operational information throughout its life. (ANSI/EIA 649-1998, National Consensus Standard for Configuration Management) Integral Part of the Systems Engineering Process Enables efficient system changes, upgrades and deployments Rapid recovery from failure
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 Projects Processes.
Defining and Managing Relational Data via Model-Based Systems Engineering Approach Requirements Gathering & Operational Analysis Identify Source Material, Operational Context, Use Cases, Scenarios, Information Exchange Establish Initial Requirements Set Establish Design Constraints Capture Issues / Risks / Decisions Functional Behavior Analysis Operational Scenarios Integrated Behavior Models Derive Functional / Performance Requirements Define I/O Define Effectiveness Measures System Architecture Analysis System Structure (i.e., Hierarchy of System Elements) Interfaces between System Elements Allocate Functional Behavior and Non-Functional Requirements Risk Assessment Compliance & Cost Assessment Design Verification & Validation Product Evaluation & Document Generation Analysis Results Specifications Test Planning Select Design Solution Document Generation Requirements ModelFunctional ModelsSystem Architectures Equipment List Interfaces Technical Rules, Standards, and Conventions R1-1 R1R2 R Issue Risk F1 F5 F2F3 F4 Performed For Each Product/System Architecture Design Layer These Primary Concurrent / Iterative Activities Are Performed For Each Product/System Architecture Design Layer. System of Systems
Requirements Traceability in MBSE Approach Map requirements into the rest of the projects engineering information. R104.1R104.3 R104 R104.2 R104.2.1R104.2.3R104.2.2 Requirements Risk A Risk B Risk C Risk D Risk E Risk F Risk G Risks and so on... Analysis Models Design Models Issue A Issue B Issue C Issue D Issue E Issue F Issue G Issues Source Material
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 Equip X.3.1 Launch System Interface Level 1 Rqmt Level 2Rqmt 1.1 Level 3 Rqmt 1.2.1Level 3 Rqmt 1.2.2 Level 2 Rqmt 1.2 System FunctionalModels Functional Models Traces to Mission 1 Mission 2 Pre-Launch On-orbit Pre-Launch On-orbit Pre-Launch On-orbit Operation Scenario #3 Pre-Launch On-orbit Operational Scenario #1 Pre-Launch On-orbit - Point Camera Take picture Operational Scenario #2 Store picture Traces to Note:
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 FunctionalAnalysis System Architecture Analysis Product Evaluation & Document Generation Stakeholder Needs & Source Material System Behavior Threads Integrated Behavior Model Allocated Behavior Model System Interfaces DesignLayer1 Design Constraints System Structure Operational Context, Use Cases, Scenarios System Requirements FunctionalAnalysis Subsystem Architecture Analysis Product Evaluation & Document Generation Subsystem Behavior Threads Integrated Behavior Model Allocated Behavior Model Subsystem Interfaces DesignLayern Subsystem Structure Operational Context, Use Cases, Scenarios Requirements Gathering & Operational Analysis Subsystem Requirements Design Constraints Design in Layers System Spec Subsystem Spec
10 Architecture Modeling is Key to Process Thermal Meteors Science Data Science Rqmt Desires Meteors Science Data Uplink/Downlink CDS Health Launch and Mission Support Comm Nav ETO Transportation Environmental Regulators Thermal Space Weather Meteors System Health Communication_ Navigation Meteors Regulations Launch & Missile Support Crew Transportation System 1 Cargo Delivery System 2 Ground Support System 3 Robotic Precuser System 4 In Space Support Systems 5 Destination Surface Systems 6 Flight Environment Space Environment Launch Service Provider Science Community Public Lunar Environment Space Environment Space Environment Flight Environment Space Environment System Definition Develop Allocated Architecture Develop Physical Architecture Develop Functional Architecture Manage Process Write Specification &&&& Lift Off Return to Earth 8 LL & LM Earth to LEO 1 LLO Ops 5 LLO to LS 6 Surface Ops 7 LL & LM LEO to LLO 3 AND SM & CEV Earth to LEO 2 CEV & SM LEO to LLO 4 Ground Support System ENV Mission Model Physical Interface Architecture
Processes: Schema Determination Sample schema from MBSE project:
12 traces to performs verified by satisfied by defined by uses config generates causes Studies documents External Programs Doc Section RequirementFunctionEquipment Verification Requirement Verification Event Test Procedure Test Configuration Issue Risk Analysis traces to Data Supported by Trade Option Set Characteristic External Resource Documented by Interface Studies Exhibits Passes Through Sends/ receives joins Initial MBSE System Engineering Schema
Relational Data Across Systems Engineering Process
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 didnt communicate that to all parties Losing productivity when you replace a component with a flawed new version and cant quickly revert to a working state Replacing the wrong component because you couldnt accurately determine which component needed replacing
Why Use a MBSE Tool 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.SystemUpdatesDetailedDesign SystemsDesign ArchitectureModelling Test RequirementManagement Requirement RequirementCapture Acceptance & Signoff SystemBuild DesignEvaluationPerformanceAssessment SystemsAnalysis CustomerInterface
16 Model Based Systems Engineering System Definition Requirements Model Functional Architecture 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 Physical Architecture Physical Architecture Model Candidate Physical Architectures HW, SW, Interfaces Human Operators Allocate Functions to Components Platform Compatibility Assessments System Physical Architecture Definition Validate Performance Requirements Model Update Functional Model Execution via Discrete Event Simulation Timeline Analyses Resource Analyses Quantitative Benefits Analyses Validation of Logic Analysis Model Establish Source/Originating Requirements Structured Hierarchy and Flowdown Managed Traceability Level I to Derived Requirements Requirements to Simulation and Verification Elements Allocated Architecture
ALTAIR (LUNAR LANDER VEHICLE) EXAMPLE APPLICATION
18 Interrelationships Among the System Design Processes as Stated in NASA SE Handbook Mission Objectives & Constraints Operational Objectives Mission Success Criteria (MOEs) Stakeholder Expectations High Level Requirements Functional/ Logical Decomposition Design & Product Breakdown Structure Derived & Allocated Reqs Func Perf Interface Operational Illities CONOPs Trade Studies & Iterative Design Loop (3 Products must be consistent) Functional & Performance Analysis Sufficient Depth? NO Next Level Work? Safe & Reliable? Affordable? YES ReBaseline Requirements ? NO YES Select Baseline YES StartStart Stakeholder Expectation Definition Technical requirements Definition Functional / Logical decomposition Design Solution Design Analysis Altair PFDs Linked to Capabilities Generate Altair OpsCon Hierarchy Defined to meet Requirements Functional Scenarios built thru hierarchy to Validate against Expectations/PFDs Decompose To level where Allocation can occur All -ility Reqs met within budget? If Altair doesnt agree with 3.7.3 Reqs Must pushback to level 2 Developed Activity Models 1. Derive Altair LCAPs 2. Link/Review CARD 3.7.3 Reqs To LCAPs 4. Identify LCAPs gaps 5. derive new Altair reqs 6. categorize Reqs 3.Build Altair eFFBD; 8. Allocate Func/Perf Reqs to Altair System Functions 7. Decompose/ Rebuild to complete system level eFFBD Altair Hierarchy
19 Hierarchy of Product Traceability LSC Phase Model LSC Phase Models Capabilities CARD Requirements in Altair 3.2 Requirements Derived from Capabilities Derived Altair 3.2 Requirements Altair FFBDs (System Level/Hierarchical) DRM Mission Phase Models Phase Models Further Define Phases One or multiple capabilities Linked to LNDR Activity PFDs All types of Requirements Derived, Categorized and Linked to Capabilities Only Functional/Performance Requirements Linked to Altair FFBDs 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) VLO Phase Model LSC DRM Phase Model Activity (Scenarios)Models LNDR Phase Ops Con Descriptions
20 Altair Traceability Process High level Traceability Model shows: 1.The flow of the process to ultimately get to the proper set of requirements to populate SRD doc section 3.2.1 2.The inputs/outputs of the major activities showing how each activity impacts other activities 3.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 Altair Ops Models for Phases LNDR Analysis.1.2 Define Capabilities for Ops Models LNDR Analysis.1.3 Reviewed DRM OCD Reviewed Cx Mission Phase Model Assigned Model Phases for Altair Developed Representative Altair Ops Models Altair LCAPs Derived and Linked Analyze LSC DRM Model to identify in which Phases Altair will operate Read and become familiar with the CxP 70007 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 1.Developed Activity Models 2.Derive Altair LCAPs
22 Lunar Sortie Crew DRM CRADLE V5.6Produced by: RBAYTDate: 03/04/08Page: 1 of 1UNCLASSIFIED ILSCOwner: RBAYTVersn:Dft: ACreated: 28/03/08 PFDDRM: Lunar Sortie CrewBaseline:Last Mod: 30/03/08 OPS Models Developed Stand Alone Operations LSC.1 Integrated Operations LSC.2 Pad Operations LSC.3 Launch LSC.4 Ascent LSC.5 LEO Configuration (Post-Insertion) LSC.6 LEO Loiter LSC.7 RPOD Operations (LEO) LSC.8 TLI Preparation LSC.9 Trans-Lunar Cruise LSC.10 LOI Operations LSC.11 Pre-Surface Operations (LDO) LSC.12 Lunar Lander Descent LSC.13 AND Surface Operations LSC.14 Lunar Orbit Maintenance LSC.15 Lunar Ascent and RPOD Operations (LRO) LSC.16 TEI Operations LSC.17 Trans- Earth Cruise LSC.18 Earth Arrival Operations LSC.19 Re-entry/Entry LSC.20 Descent and Landing LSC.21 Recovery LSC.22 Post - Flight Processing LSC.23 DD250 Transport to Integration Facility Complete MLP Hard Down LCD CTS T - 0 Orbit Insertion MNVR Complete 'Go' for Orbit Ops Initiate Rendezvous Burn Docking Complete TLI Burn Complete Start LOI Burn Prep LOI Burn Complete Pwrd Descent Initiation Burn ATP Initiate Prep Docking Complete TEI Burn Complete Final Entry Prep SM Separation Fwd Bay Cover Jettison Touchdown Arrival Post - Flight Processing Facility Pre-Descent start Update in work OPS Models Complete See RPOD Sub-Phase PFD (next slide)
23 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 CRADLE V5.6Produced by: ACHR_ADate: 09/03/08Page: 1 of 1 UNCLASSIFIED * LSC.8 RPOD Operations (LEO) - 6.5 hours * Initiate Rendezvous Burn Docking Complete LEO Rendezvous Prep RPOD.1 Prox Ops RPOD.2 Post Dock Operations RPOD.3 LEO Rendezvous RPOD.4 Docking Operations RPOD.5 Target Reached - Nav State for LEO Rendezvous Orion Terminal Phase Initiation Target Reached - Nav State for Docking Operations Docking Event * 1 hour * * 3 hours ** 1.5 hours * * 30 minutes *
24 EDS Altair Orion Mission Ops AND Monitor Lander Health and Status LEO_RPREP.9 Relay Altair Data & Comm LEO_RPREP.1 Maintain EDS/Altair LEO Loiter Attitude LEO_RPREP.2 Initiate Rendezvous Burn Target Reached - Nav State for LEO Rendezvous AND Sustain Lander - RPOD Operations (LEO) LEO_RPREP.3 Activate RF Comm LEO_RPREP.4 Prep - 1 hour * Activate Approach Lights LEO_RPREP.5 AND Perform Initial Rendezvous Burn LEO_RPREP.8 Activate Altair RF comm for Cmd Tlm and Ranging LEO_RPREP.6 Activate Altair RF comm command Activate Altair Approach Lights LEO_RPREP.7 Activate Altair approach lights command 1.Develop Altair Activity PFD, derive LCAP(s) for This Diagram The spec for this diagram Will be linked to the LEO Rendezvous Spec contained In the RPOD Operations phase model Altair Activity Model for LEO Rendezvous Prep
25 Workbench View of LEO_P_Dock Specs RPOD Phase Spec LEO_P_Dock Activity Model Spec LEO_P_Dock Activity Linked to phase, RPOD.5 Post Dock Operations
26 Workbench View of RPOD Spec Linked to LNDR OPS CON Item A new Ops Con item Is developed that Contains the Altair RPOD Phase Definition This Ops Con item is Linked to the RPOD Sub-Phase Diagram Spec… This is the RPOD Spec for the phase model
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 Activity Model RPOD Phase Model may be linked to multiple DRM Models LEO Rendezvous Prep RPOD.1 Prox Ops RPOD.2 Post Dock Operations RPOD.3 LEO Rendezvous RPOD.4 Docking Operations RPOD.5 RPOD Operations Shared Systems Activity Models (scenarios) will be developed for a specific phase activity ( LEO Rendezvous) Capabilities will be developed and linked to the Altair Activity Models (scenarios) Specs C LSC RPOD VLO RPOD RLO RPOD ORO RPOD LCAP OCAP ACAP Other systems could also extract capabilities from these models LNDR Phase Ops Con Descriptions Lander OpsCon Phase definitions will be developed as an OpsCon items
28 Link Requirements Review and categorize the CARD 3.7.3 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 3.7.3 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 3.7.3 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 (Steps 2 – 6)
29 LEO Rendezvous Prep RPOD.1 Prox Ops RPOD.2 Post Dock Operations RPOD.3 LEO Rendezvous RPOD.4 Docking Operations RPOD.5 RPOD Phase Model may be linked to multiple DRM Models C LSC RPOD VLO RPOD RLO RPOD ORO RPOD C LSC RPOD VLO RPOD RLO RPOD ORO RPOD C Activity Model LCAP Capabilities will be developed and linked to the Altair Activity Models (scenarios) Specs LCAP RPOD Operations Req 1 Req 3 Req 2 Func/Perf Reqs Drive Functional Arch 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 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 STEPS 2-6
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 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 3.2.1 Altair Performance characteristics in order to generate this SRD draft
33 WHAT Do We Want to Specify? Establish the purpose of the System; Define Functions and Measures that Implement and Quantify achieving the Purpose Transport Command and Control Communication Maneuverability Control Environment Altair Functional Architecture Vehicle Management Treat the Vehicle as a Black Box (Inside and Out) Can it move and follow a trajectory? Can it carry Payload? Can people live out of it? Can it interact with the outside world? Can it assess its own status? Can it take action upon Command?
34 High Level Altair eFFBD (Draft) CRADLE V5.6Produced by: RBAYTDate: 09/03/08Page: 1 of 1 UNCLASSIFIED ILNDROwner: ACHR_AVersn:Dft: ACreated: 07/29/08 BDCarry Crew & Cargo to Lunar SurfaceBaseline:Last Mod: 09/03/08 Function Discrete Item Timeline Data Link Trigger Data Link KEY
35 Command and Control
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? 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. 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)
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/StateCoast StateCrewed Powered Flight Life SupportDormantNormal Thermal½ CapacityNormal Power SystemExternal PowerFull Power PropulsionAttitude Control about Deadband Active MPS GN&CActive
42 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 Sustain Lander Resource Utilization Activate LightsActivate Comm
43 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 Perform Communications LNDR.1 Sustain Altair Environment LNDR.2 Command & Control LNDR.3 Maneuver (Off) LNDR.4 Manage Vehicle Performance LNDR.5 Transport and Habitability LNDR.6 Maneuver (Free Flying Powered Flight) LNDR.4 Maneuver (Shadow) LNDR.4 Sustain Lander - TLI Operations (LEO) Sustain Lander - LOI Operations (LEO) Sustain Lander - Surface Operations (LEO) Maneuver (Integrated Stack Powered Flight) LNDR.4 Phase Mode
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. Sustain Lander - LOI Operations (LEO) Maneuver (Integrated Stack Powered Flight) LNDR.4 Mode Phase Mode Unique Capabilities Perform Integrated Stack Attitude Control Maneuver (Shadow) LNDR.4 Sustain Lander - TLI Operations (LEO) Perform Integrated Stack State Estimation Mode Thread Unique to function Mode Independent Functional Architecture Maneuver LNDR.4 R.EA5290 R.LNDR123 SRD is Developed from Functional Model Threads justify span of performance Reqmnts Question: Do we really need thread models, or can we just hook capabilities to Sustain Ops?
45 Physical Architecture Diagram (PAD) Context Diagram Altair Context Model: Shows External interfacing systems Lines between Altair and external systems illustrate interfaces between
46 Integration of Functional & Physical Models Functional Interfaces Carried by Physical Interfaces Altair Functions are allocated to Altair Equipment spec (system)
47 Transport Command and Control Communication Maneuverability Habitability Vehicle Management Altair Altair Functional Model Crewed Landers Only Common to all Landers The LSAM shall provide a habitable environment for a crew of four for a minimum of 180 (TBR-001-033) 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. Receive Commands on Lander Accept Lander Crew Input Accept Commands from Vehicle Manager The LSAM shall provide an interface for the crew to generate commands for Lunar Sortie and Lunar Outpost crew missions.
48 Command and Control Habitability Altair Functional Model Drives Document Crewed Landers Only Common to all Landers The LSAM shall provide a habitable environment for a crew of four for a minimum of 180 (TBR-001-033) 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. Receive Commands on Lander Accept Lander Crew Input Accept Commands from Vehicle Manager Altair Section 3.2 3.2.1 Common Characteristics 184.108.40.206 Common Performance Characteristics 3.2.2 Crewed Mission Characteristics 220.127.116.11 Crewed Performance Characteristics The LSAM shall execute valid commands which are addressed to the LSAM. The LSAM shall provide an interface for the crew to generate commands for Lunar Sortie and Lunar Outpost crew missions.
49 Altair Operational Model Crewed Landers Only Common to all Landers TLI Prep Activity LOI Burn Ops Activity Crewed OPSCON Item Crewed Mission Description Outpost OPSCON Item Sortie OPSCON Item Outpost Mission Description Sortie Mission Description Cargo Landers Only TLI Prep Activity Cargo OPSCON Item Cargo Mission Description Cargo OPSCON Item
50 Altair Operational Model Crewed Landers Only Common to all Landers TLI Prep Activity LOI Burn Ops Activity Crewed OPSCON Item Crewed Mission Description Outpost OPSCON Item Sortie OPSCON Item Outpost Mission Description Sortie Mission Description Cargo Landers Only TLI Prep Activity Cargo OPSCON Item Cargo Mission Description Cargo OPSCON Item Cargo Mission Description Assign Model and OPSCON Item to Doc Section for Doc Pub 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
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
Conclusion Benefits 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 53