Presentation on theme: "SRD Development Process Using Model Based Systems Engineering"— Presentation transcript:
1SRD Development Process Using Model Based Systems Engineering Altair Project IntegrationRobert Bayt - NASAAnn Christian - 3SL Inc.Philip Nerren – Integrated Thought
2Overview Agenda Introduction Background Model Based System Engineering MethodologyUsing CRADLEExample – application to Altair (Lunar Lander Vehicle)AcknowledgementsRobert Bayt Ph.D. – Altair Lead System Engineer,NASA JSC HoustonAnn Christian – Altair System Requirements Manager,3SL Inc.Philip Nerren – Project and Systems Integration Office,Integrated Thought CorporationAgendaJIMO – Jovian Ice Moon Orbiter, being developed at JPL with some initial assistance from MSFC.
3BackgroundAltair (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.
4Enabling Process Management 3SLEnabling 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 ProcessEnables efficient system changes, upgrades and deploymentsRapid recovery from failure
5Processes: 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.
6Defining and Managing Relational Data via Model-Based Systems Engineering Approach Requirements Gathering & Operational AnalysisFunctional Behavior AnalysisSystem ArchitectureAnalysisIdentify Source Material, Operational Context, Use Cases, Scenarios, Information ExchangeEstablish Initial Requirements SetEstablish Design ConstraintsCapture Issues / Risks / DecisionsSystem Structure (i.e., Hierarchy of System Elements)Interfaces between System ElementsAllocate Functional Behavior and Non-Functional RequirementsOperational ScenariosIntegrated Behavior ModelsDerive Functional / Performance RequirementsDefine I/ODefine Effectiveness MeasuresACRequirements ModelBFunctional ModelsSystem ArchitecturesR1-1R1R2RIssueRiskF1F5F2F3F4System of SystemsInterfacesEquipment ListProduct Evaluation & Document GenerationRisk AssessmentCompliance & Cost AssessmentDesign Verification & ValidationTest PlanningSelect Design SolutionDocument GenerationAnalysis ResultsTechnical Rules, Standards, and ConventionsSpecificationsThese Primary Concurrent / Iterative Activities Are Performed For Each Product/System Architecture Design Layer.
7Requirements Traceability in MBSE Approach Map requirements into the rest of the project’s engineering information.Source MaterialAnalysis ModelsRequirementsR104.1R104.3R104R104.2RRRDesign ModelsIssue AIssue BIssue CIssue DIssue EIssue FIssue GIssuesRisk ARisk BRisk CRisk DRisk ERisk FRisk GRisksand so on...
8Traceability 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 ProcessesHorizontal TraceabilityArchitecture ModelsRequirements ModelFunc 1DataFunc 2Func 4Func 3allocated toSatisfiesassigned toEquip X.3.1Science SystemGround SystemLaunch SystemInterfaceLevel 1 RqmtLevel 2Rqmt 1.1Level 3 Rqmt 1.2.1Level 3 Rqmt 1.2.2Level 2 Rqmt 1.2SystemFunctional ModelsTraces toMission 1Mission 2Pre-LaunchOnorbitOperation Scenario #3Operational Scenario #1PointCameraTakepictureOperational Scenario #2StoreNote:
9Processes: 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 AnalysisFunctionalAnalysisSystem ArchitectureProductEvaluationDocumentGenerationStakeholderNeedsSourceMaterialSystemBehaviorThreadsIntegratedModelAllocatedInterfacesDesignLayer“1”ConstraintsStructureOperationalContext,Use Cases,ScenariosRequirementsSubsystem ArchitectureSubsystem“n”in LayersACBSpec
10Architecture Modeling is Key to Process Lift OffReturn toEarth8LL & LMEarth toLEO1LLO Ops5LLO to LS6SurfaceOps7LEO to LLO3ANDSM & CEV2CEV & SM4GroundSupportSystemENVMission ModelThermalMeteorsScience DataScienceRqmt DesiresUplink/DownlinkCDS HealthLaunch andMissionSupportComm NavETOTransportationEnvironmentalRegulatorsSpaceWeatherSystemHealthCommunication_NavigationRegulationsLaunch &MissileCrew1CargoDelivery2Ground3RoboticPrecuser4InSystems5DestinationSurface6FlightEnvironmentLaunchServiceProviderCommunityPublicLunarPhysical Interface ArchitectureSystem DefinitionDevelop Allocated ArchitectureDevelop Physical ArchitectureDevelop Functional ArchitectureManage ProcessWrite Specification&An example. The sequence and concurrency of functions above are allocated onto the components. Tools keep these traceability links for subsequent analyses.
11Processes: Schema Determination Sample schema from MBSE project:
12Initial MBSE System Engineering Schema PassesThroughInterfaceDataDoc SectionStudiesAnalysisSends/receivesjoinstraces todocumentsStudiestraces toperformsRequirementFunctionEquipmentTrade Option SetSupported byverified byExhibitsVerificationRequirementCharacteristicIssuegeneratesExternalProgramsThis 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 bycausesRiskuses configVerificationEventdefined byTest ProcedureTest ConfigurationDocumented byExternalResource
13Relational Data Across Systems Engineering Process
14Process/Configuration Management 3SLProcess/Configuration ManagementProcess support without configuration management results in extra costs associated with:Figuring out which system components to change when requirements changeRe-doing an implementation because you implemented to meet requirements that had changed and you didn’t communicate that to all partiesLosing productivity when you replace a component with a flawed new version and can’t quickly revert to a working stateReplacing the wrong component because you couldn’t accurately determine which component needed replacing
15Why 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.SystemUpdatesDetailedDesignSystemsArchitectureModellingTestRequirementManagementCaptureAcceptance& SignoffBuildEvaluationPerformanceAssessmentAnalysisCustomerInterface
16Model Based Systems Engineering System DefinitionFunctional ArchitectureRequirements ModelFunctional ModelTranslate User Operational Capabilities to System Functional RequirementsGraphical Analysis Provides Increased Rigor (versus text only)FunctionsInputs/OutputsTime SequenceLogicScenario DevelopmentOperationalSimulationEstablish Source/Originating RequirementsStructured Hierarchy and FlowdownManaged TraceabilityLevel I to Derived RequirementsRequirements to Simulation and Verification ElementsAllocated ArchitecturePhysical ArchitectureAnalysis ModelPhysical Architecture ModelThe 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 PerformanceRequirements Model UpdateFunctional Model Execution via Discrete Event SimulationTimeline AnalysesResource AnalysesQuantitative Benefits AnalysesValidation of LogicCandidate Physical ArchitecturesHW, SW, InterfacesHuman OperatorsAllocate Functions to ComponentsPlatform Compatibility AssessmentsSystem Physical Architecture Definition
18Interrelationships Among the System Design Processes as Stated in NASA SE HandbookTrade Studies & Iterative Design Loop(3 Products must be consistent)Developed ActivityModels1. Derive Altair LCAPsMissionObjectives &ConstraintsOperationalObjectivesMission Success Criteria (MOEs)StakeholderExpectations7. Decompose/ Rebuild to complete system leveleFFBDNextLevel2. Link/Review CARD ReqsTo LCAPsDesign &ProductBreakdownStructureDerived &Allocated ReqsFuncPerfInterfaceOperationalIllities4. Identify LCAPs gaps5. derive new Altair reqs6. categorize ReqsStartHigh LevelRequirementsFunctional/LogicalDecompositionAltair Hierarchy3.Build Altair eFFBD;8. AllocateFunc/PerfReqs toAltair SystemFunctionsHierarchy Definedto meet RequirementsAltair PFDs Linkedto CapabilitiesGenerate Altair OpsConCONOPsStakeholder Expectation DefinitionFunctional &PerformanceAnalysisSufficientDepth?Technical requirements DefinitionNOFunctional / Logical decompositionDecomposeTo level whereAllocation can occurFunctional Scenariosbuilt thru hierarchy toValidate againstExpectations/PFDsDesign SolutionYESNODesign AnalysisReBaselineRequirements?Work?Safe & Reliable?Affordable?NOYESSelectBaselineYESIf Altair doesn’t agree with ReqsMust pushback to level 2All -ility Reqs met within budget?
19Hierarchy of Product Traceability Rules/AssumptionsDRM 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 definitionsCapabilities may be linked to multiple Activity models, They must have a textual definition developedCapabilities may have multiple types of CARD or Derived requirements linked to themAll CARD (allocated to Altair) requirements categorized as functional or performance must be linked to an LCAPAll 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 ModelVLO Phase ModelLSC DRM Phase ModelDRM Mission Phase ModelsPhase ModelsFurther Define PhasesLSC Phase ModelsActivity (Scenarios)ModelsLNDR PhaseOps ConDescriptionsCapabilitiesCapabilitiesOne or multiple capabilitiesLinked to LNDR Activity PFDsCapabilitiesCapabilitiesCARD Requirements in Altair 3.2Requirements Derived from CapabilitiesAll types of RequirementsDerived, Categorized and Linkedto CapabilitiesDerived Altair 3.2 RequirementsAltair FFBDs(System Level/Hierarchical)Only Functional/PerformanceRequirements Linked to Altair FFBDs
20Altair Traceability Process DeriveAltairOperationalPFDsLNDR Analysis.1LinkRequirementsLNDR Analysis.2BuildSystemFunctionalArchitectureLNDR Analysis.3DRM OCDCxMissionPhaseModelPFD PhaseModelsCapabilitiesLinked toCARD3.7.3ReqsLCAPsMissingDerivedDevelopedHighLevelAltair FAeFFBDsFunc /Perf ReqsforFAPopulatedPerfCharacteristics3.2.1 ReqsHigh level Traceability Model shows:The flow of the process to ultimately get to theproper set of requirements to populate SRD doc section 3.2.1The inputs/outputs of the major activities showing how eachactivity impacts other activitiesEach of these process activities is further decomposed todefine the specific tasks to define Altair functionality andDerive functional and performance requirements
21Derive Altair Operational PFDs IdentifyAltairMissionPhasesLNDR Analysis.1.1DevelopOpsModelsfor PhasesLNDR Analysis.1.2DefineCapabilitiesfor OpsLNDR Analysis.1.3ReviewedDRM OCDCxPhaseModelAssignedfor AltairDevelopedRepresentativeOps ModelsLCAPsDerivedand LinkedAnalyze LSC DRM Model to identify in which Phases Altair will operateRead and become familiar with the CxP to understand system descriptions and Phase definitionsDevelop Altair PFD activity models which define how Altair will be operated and identify inter-system commsDerive Capabilities which will ensure or identify gaps or inconsistencies with existing CARD requirementsDeveloped Activity ModelsDerive Altair LCAPs
23InitiateRendezvousBurnDockingCompleteLEOPrepRPOD.1Prox OpsRPOD.2Post DockOperationsRPOD.3RPOD.4RPOD.5TargetReached -Nav Statefor LEOOrionTerminalPhaseInitiationforEvent* 1 hour ** 3 hours ** 1.5 hours ** 30 minutes *RPOD Phase PFDThis Diagram Spec will be linked to LSC.8 RPOD Operations (LEO) SpecThis Diagram Spec may be linked to other DRM RPOD Specs, if it appliesThis Diagram Spec will have an Altair Ops Con Definition written todescribe Altair operations during this phase* LSC.8 RPODOperations(LEO) - 6.5hours *CRADLE V5.6Produced by: ACHR_ADate: 09/03/08Page: 1 of 1UNCLASSIFIED
24Altair Activity Model for LEO Rendezvous Prep Develop Altair ActivityPFD, derive LCAP(s) forThis DiagramPrep - 1 hour *RelayAltairEDSANDANDData &CommANDANDLEO_RPREP.1MaintainEDS/AltairLEOThe spec for this diagramWill be linked to the LEORendezvous Spec containedIn the RPOD Operationsphase modelLoiterAttitudeLEO_RPREP.2SustainLander -AltairRPODANDOperationsAND(LEO)LEO_RPREP.3ActivateActivateRF CommApproachLightsLEO_RPREP.4LEO_RPREP.5ActivateActivateAltair RFAltaircommapproachcommandlightscommandActivateAltair RFActivatecomm forAltairTargetInitiateOrionANDCmd TlmApproachReached -RendezvousandLightsANDNav StateBurnRangingfor LEOLEO_RPREP.7RendezvousLEO_RPREP.6PerformInitialRendezvousBurnLEO_RPREP.8MonitorLanderMission OpsHealthand StatusLEO_RPREP.9
25Workbench View of LEO_P_Dock Specs RPOD Phase SpecLEO_P_Dock ActivityLinked to phase, RPOD.5Post Dock OperationsLEO_P_DockActivity ModelSpec
26Workbench View of RPOD Spec Linked to LNDR OPS CON ItemThis is theRPOD Specfor the phasemodelThis Ops Con item isLinked to the RPODSub-Phase Diagram Spec…A new Ops Con itemIs developed thatContains the AltairRPOD Phase Definition
27DRM 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 LanderShow how scenarios will be used to address different DRMsCLSCRPODVLORPODRLORPODORORPODRPOD Phase Model may belinked to multiple DRM ModelsLEORendezvousPrepRPOD.1Prox OpsRPOD.2Post DockOperationsRPOD.3RPOD.4DockingRPOD.5RPODLNDR PhaseOps ConDescriptionsShared Systems Activity Models(scenarios) will be developed fora specific phase activity( LEO Rendezvous)OCAPActivityModelACAPLander OpsCon Phase definitions willbe developed as an OpsCon itemsOther systems could also extract capabilities from these modelsLCAPLCAPLCAPCapabilities will be developed and linked to theAltair Activity Models (scenarios) Specs
28Functional/Performance Link RequirementsReview /CategorizeCARD3.7.3 ReqsLNDR Analysis.2.1Identify3.7.3Functional/PerformanceReqsLNDR Analysis.2.2ORLink AllFunc/PerfReqs toLCAPsLNDR Analysis.2.3Link anyotherReqs ThatApply toLNDR Analysis.2.4DeriveAdditionalReqs AsNeededLNDR Analysis.2.5RecommendReqs beDevelopedLNDR Analysis.2.6RequirementsCategorizedAltairDerivedand LinkedLinkedReqs GapsIdentifiedApplicableLinked toOtherNewas LNDRCandidateCR forNew CARDAll Other(Steps 2 – 6)Review and categorize the CARD Requirements (approximately 108 requirements) (Step 6)Consensus on categorization by technical team accomplishedIdentify functional and performance requirements, these must be linked to LCAPs, thesewill drive the Functional Architecture to achieve defined operations (approx 57 identified, 28 linked)Identify possible unachievable CARD functional/performance requirementsIdentify 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 reqsderived to dateLink 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
29STEPS 2-6 C C RPOD Phase Model may be linked to multiple DRM Models LSCRPODVLORLOORORPOD Phase Model may belinked to multiple DRM ModelsRPODOperationsLEOLEODockingPost DockRendezvousProx OpsRendezvousOperationsOperationsPrepRPOD.2RPOD.4RPOD.5RPOD.3RPOD.1CActivityModelCapabilities will be developed and linked to theAltair Activity Models (scenarios) SpecsLCAPLCAPLCAPLCAPLCAPLCAPANDPerformCommunicationsLNDR.1SustainAltairEnvironmentLNDR.2Command &ControlLNDR.3ManeuverLNDR.4ManageVehiclePerformanceLNDR.5TransportLNDR.6Each LCAP must have a Req linked to it, if no CARD Req is applicable gap is identifiedReqs 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 / constrainingDerive new Req if Gap is identified for LCAPReq 3Req 2Req 1Func/Perf ReqsDrive Functional Arch
30LSC DRM Trace To Altair Functional Architecture LSC DRM PhaseRPOD PhaseRPOD ActivityAltair Activity Model SpecCapability Derived for Altair LEO RprepFunctional Req Linked to LCAPFunctional Req Drives FA(Linked to Func)
31Query: Ops to LCAPs to Reqs to Func Traceability ReportOperational SpecsFrom Activity Models,Phase Models, PhaseModelsLCAPsRequirementsLinked to LCAPsFunctionsLinked toRequirements
32Build Altair Functional Architecture Group AllFunc/PerfReqs intoFunctionalGroupingsnew.1DeriveFunctions/eFFBDBased onnew.2ValidateFFBD byEnsuringAgainstOps Modelnew.3Link AllReqs toFunctionsnew.4LinkedCARD3.7.3LCAPsNewReqsLinked toIdentifiedDerivedonConstruct/eFFBDDevelopedValidatedDevelopThreadsnew.5SystemeFFBDsFunctional/PerformanceAnalysisANDDecomposeTo SystemAllocationLevelnew.6AllocatefunctionsTo AltairSpecnew.7AllocatedLinkHighFFBD toSRDSection3.2.1new.8PopulatedAltairPerfCharacterisitics3.2.1 ReqsGroup all the designated and newly derived functional and performance requirements into functional groupingsDraft an eFFBD based on groupings, identifying high level Altair functions Step 3Validate that eFFBD defined the functionality at the highest level to meet operational needs derived in PFDsStep 7Link all functional and performance requirements to capabilities and system level functions (may be at lowerlevel in system eFFBDs) Step 8Allocate all functions in system level eFFBDs to the Altair shared equipment specDevelop top level functional thread scenarios that support system operations to ensure system functionalitysupports operational needs developed in the PFDs and derived capabilitiesOnce the eFFBDs are agreed to by team, the highest level system eFFBD will be linked to the LNDR_SRDdoc section Altair Performance characteristics in order to generate this SRD draft
33WHAT Do We Want to Specify? Control EnvironmentTreat the Vehicle as a Black Box (Inside and Out)CommunicationCan people live out of it?Can it interact with the outside world?TransportCan it carry Payload?Command and ControlCan it take action upon Command?Vehicle ManagementCan it move and follow a trajectory?ManeuverabilityAltair Functional ArchitectureCan it assess its own status?Establish the purpose of the System; Define Functions and Measures that Implement and Quantify achieving the Purpose
35Command and Control OR Receive Commands on Lander LNDR.3.1 Accept Crew InputLNDR.3.2CheckCommandValidityLNDR.3.4ANDProvideExecutionStatusLNDR.3.8ExecuteCommand/CommandSequencesLNDR.3.6SendfromLNDR.3.7PrioritizeLNDR.3.5VehicleManagerLNDR.3.3FaultDetectionRecoveryCrewActionsto Altair
37Principles of eFFBDseFFBD – 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” thesystem is to do it (this is the purpose of eFFBDs)High level Functions – represent complex functions, as design proceedslower levels are reached, these high level functions providethe basis of all lower level functional definition. Numbers areused to label the function blocks and placement of the functionswithin the hierarchyFunction – Accepts inputs then transforms them to outputs, functions are statedwith action verbs preceding the “what”; example: Operate Tool.Functions consume inputs and produce outputs.Functional Requirement - should specify the required behavior of the entityand should include applicable parameters such as response times,sequencing, accuracy, capacities (how much/how many), priorities, continuousoperation requirements, and allowable deviations based on operating conditions.
38Recap Of Functional Analysis Functional Architecture (FA) is originates from:Operational Analysis (OpsCon Models)Developed Capabilities from modelsCARD Driving requirements linked to capabilitiesHigh Level Functional eFFBD developed in a Parallel Construct showingthat in this level functions occur simultaneouslyFunctions are leveled by the allocation that is made, only to system due tofact specific allocations cannot be made based on level of requirements linkedFunctions are stated with action verb, defining the What, example: “Perform”Functions must have input(s) or stimulus and output(s) or repsonse, withoutperforming a process, not need for functionCARD requirements that drive FA are categorized as functional or performancerequirements
39Altair eFFBD Specs to Reqs User Type Query Called: LNDR FFBD Specs to Reqs
40How 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 operationsNeed to capture Operational Capabilities of the ‘Vehicle as a Whole’ that would be required in ALL ScenariosPrimary Mission (All DRMs)AbortsGround ProcessingDisposalNeed to establish what Actions the user can take, and what data they need to make decisions/take actionNeed to capture the attributes of these capabilities and to what performance levelCommon attributes that apply to all systemsUnique attributes that require more than one system to achieveThe 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.
41States and ModesState: 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 variablesMode: 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, TrainingProposal: 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 FlightLife SupportDormantNormalThermal½ CapacityPower SystemExternal PowerFull PowerPropulsionAttitude Control about DeadbandActive MPSGN&CActive
42Sustain Lander is the state that enables Operations ModesModes 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 phaseIn parallel, a sustainment function should capture the functions that enable these activities.Sustain Lander is the state that enables OperationsActivate CommActivate LightsResource UtilizationSustain Lander42
43Transport and Habitability Modeling SustainmentSustainment functions will be Functional Threads of the basic Architectural ActivitiesNeed to Model the various Modes of the Primary FunctionsModes should capture capabilities, not set pointsCabin regulates between 7 and 12 psi, not cabin is set to 10.8 psiLink modes to various PhasesShould only have to model a handful of modes per FunctionCan copy the Architecture to each thread and elaborate only the unique capabilitiesThreads will generate capabilitiesSustainLander -TLIOperations(LEO)SustainLander -LOIOperations(LEO)SustainLander -SurfaceOperations(LEO)PhasePerformCommunicationsLNDR.1SustainAltairEnvironmentLNDR.2Command &ControlLNDR.3Maneuver(Off)LNDR.4Maneuver(Free FlyingPowered Flight)LNDR.4Maneuver(Shadow)LNDR.4Maneuver(Integrated StackPowered Flight)LNDR.4ModeManageVehiclePerformanceLNDR.5Transport and HabitabilityLNDR.643
44Modeling Sustainment Capabilities should be written against the Modes The capabilities are then linked to Requirements in the Functional ArchitectureThis 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 ArchitectureSustainLander -TLIOperations(LEO)SustainLander -LOIOperations(LEO)ManeuverLNDR.4PhaseR.LNDR123Maneuver(Integrated StackPowered Flight)LNDR.4Maneuver(Shadow)LNDR.4ModeR.EA5290Mode Thread Unique to functionSRD is Developed from Functional ModelThreads justify span of performance ReqmntsMode Unique CapabilitiesPerform Integrated Stack Attitude ControlPerform Integrated Stack State Estimation44
47Altair Functional Model HabitabilityThe 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 ManagerCommunicationAltairAccept Lander Crew InputTransportThe LSAM shall provide an interface for the crew to generate commands for Lunar Sortie and Lunar Outpost crew missions.Receive Commands on LanderCommand and ControlVehicle ManagementManeuverabilityCommon to all LandersCrewed Landers Only
48Functional Model Drives Document HabitabilityThe 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 ManagerAltairAccept Lander Crew InputThe LSAM shall provide an interface for the crew to generate commands for Lunar Sortie and Lunar Outpost crew missions.Receive Commands on LanderCommand and ControlThe LSAM shall execute valid commands which are addressed to the LSAM.Altair Section 220.127.116.11 Common CharacteristicsCommon Performance Characteristics3.2.2 Crewed Mission CharacteristicsCommon to all LandersCrewed Landers OnlyCrewed Performance Characteristics
49Altair Operational Model LOI Burn Ops ActivityOutpost OPSCON ItemSortie OPSCON ItemCargo OPSCON ItemOutpost Mission DescriptionSortie Mission DescriptionTLI Prep ActivityTLI Prep ActivityCargo OPSCON ItemCargo Mission DescriptionCrewed OPSCON ItemCommon to all LandersCrewed Mission DescriptionCrewed Landers OnlyCargo Landers Only
50Altair Operational Model Assign Model and OPSCON Item to Doc Section for Doc PubTLI Prep Activity1. Assumptions2. Ops Capability by Phase2.1 Ground Ops2.2 Launch2.3 LEO Ops2.4 LEO Loiter2.5 LEO Rndz2.6 TLI Prep2.6.1 Crewed TLI Prep2.6.2 Cargo TLI PrepCommon Mission DescriptionCargo Mission DescriptionCrewed Mission DescriptionCrewed OPSCON ItemCargo Mission DescriptionTLI Prep ActivityCargo OPSCON ItemLOI Burn Ops ActivityCargo OPSCON ItemOutpost OPSCON ItemSortie OPSCON ItemCargo Mission DescriptionCommon to all LandersCrewed Landers OnlyOutpost Mission DescriptionSortie Mission DescriptionCargo Landers Only
51Thread AnalysisThread Analysis is used to show how various sub-functions interaction in order develop a higher-level capability.Capabilities can be derived from the threadRequirements in Functional Architecture linked to threadsPowered FlightNew capabilities:Altair requires state estimation to X m SEP to accomplish sufficient maneuver controlAltair requires Impulse control to Y Ns to achieve target accuracy.
52Possible Abort Maneuver Thread (Example)Access BDs in ToolsetLABORT is the thread developed showing an Example systemlevel Functional Thread for Altair Abort FunctionalityWhen building a functional thread only functions that will be performedto accomplish the “operation” should be includedOnce FFBDs are developed with inputs and outputs, only thoseinputs and outputs that provide the flow of comms, decisions, etcthat accomplish the operation are includedThis process of doing functional analysis modeling exercises the validityof the functional architecture and may provides a way to generate possibletest procedures to verify linked functional and performance requirements
53Conclusion Benefits Observations Traceability from Stakeholder Operational NeedFunctional BehaviorArchitectural System AffectivityRationale for justifying why functionality is in the systemIntegrated, Comprehensive, and CompleteCollaborative Interface Development and ManagementRelational Database Extensible UtilityImpact Analysis/AwarenessObservationsCultural issuesMBSE has many interpretationsEarly in implementationWorkforce trainingModeling is a mind set not experience