srd development process using model based systems engineering altair project integration robert bayt...
TRANSCRIPT
SRD Development Process
Using Model Based Systems Engineering
Altair Project IntegrationRobert Bayt - NASAAnn 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 [email protected]
Ann Christian – Altair System Requirements Manager, 3SL Inc. [email protected] www.threesl.com
Philip Nerren – Project and Systems Integration Office, Integrated Thought Corporation [email protected] 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.
Heavy LiftLaunch Vehicle
Crew Launch Vehicle
Earth DepartureStage
Crew Exploration Vehicle
LunarLander
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 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 Project’s Processes.
Defining and Managing Relational Data via Model-Based Systems Engineering Approach
Requirements Gathering & Requirements Gathering & Operational AnalysisOperational Analysis
• Identify Source Material, Operational Context, Use Cases, Scenarios, Information Exchange
• Establish Initial Requirements Set• Establish Design Constraints• Capture Issues / Risks / Decisions
Functional Behavior Functional Behavior AnalysisAnalysis
• Operational Scenarios• Integrated Behavior Models• Derive Functional / Performance
Requirements• Define I/O• Define Effectiveness Measures
System ArchitectureSystem ArchitectureAnalysisAnalysis
• 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 ResultsSpecifications
• Test Planning• Select Design Solution• Document Generation
Requirements Model Functional Models System Architectures
Equipment List
Interfaces
Technical Rules, Standards, and Conventions
R1-1
R1 R2
R
Issue
Risk
F1 F5
F2 F3
F4
These Primary Concurrent / Iterative Activities Are Performed For Each Performed For Each Product/System Architecture Design LayerProduct/System Architecture Design Layer.
These Primary Concurrent / Iterative Activities Are Performed For Each Performed For Each Product/System Architecture Design LayerProduct/System Architecture Design Layer.
System of Systems
Requirements Traceability in MBSE Approach
Map requirements into the rest of the project’s engineering information.
R104.1 R104.3
R104
R104.2
R104.2.1 R104.2.3R104.2.2
RequirementsRequirements
Risk ARisk B
Risk CRisk D
Risk ERisk F
Risk GRisksand so on...
Analysis Models
Design Models
Issue AIssue B
Issue CIssue D
Issue EIssue F
Issue GIssues
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 ProcessesOperational Processes
Horizontal Traceability
Architecture ModelsRequirements ModelRequirements Model
Func 1
Data
Func 2
Func 4
Func 3
allocated toSatisfies
assigned to
Equip X.3.1Science System
Ground System
Equip X.3.1Launch 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
FunctionalFunctional ModelsModels Traces to
Mission 1Mission 2
Pre-Launch Launch On- orbitPre-Launch Launch On- orbit
Pre- Launch Launch On-orbit
Operation Scenario #3Pre-Launch Launch On- orbit
Operational Scenario #1
Pre-Launch Launch On- orbit-Point
CameraTake
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 GatheringRequirements Gathering &
Operational AnalysisOperational Analysis
FunctionalFunctionalAnalysisAnalysis
SystemSystem Architecture Architecture AnalysisAnalysis Product
Evaluation&
Document Generation
StakeholderNeeds
&Source Material
System BehaviorThreads
IntegratedBehavior
Model
AllocatedBehaviorModel
SystemInterfaces
DesignDesignLayerLayer
““1”1” DesignConstraints
SystemStructure
OperationalContext,
Use Cases,Scenarios
SystemRequirements
FunctionalFunctionalAnalysisAnalysis
SubsystemSubsystem Architecture Architecture AnalysisAnalysis Product
Evaluation&
Document Generation
Subsystem BehaviorThreads
IntegratedBehavior
Model
AllocatedBehaviorModel
SubsystemInterfaces
DesignDesignLayerLayer
““n”n” SubsystemStructure
OperationalContext,
Use Cases,Scenarios
Requirements GatheringRequirements Gathering & &
Operational AnalysisOperational Analysis
SubsystemRequirements
DesignConstraints
Design in Layers
System
Spec
Subsystem
Spec
10
Architecture Modeling is Key to Process
Thermal
Meteors
Science Data
ScienceRqmt Desires
Meteors
Science Data
Uplink/Downlink
CDS Health
Launch andMissionSupport
Comm NavETO
Transportation
EnvironmentalRegulators
Thermal
SpaceWeather
Meteors
SystemHealth
Communication_Navigation
Meteors
Regulations
Launch &MissileSupport
CrewTransportation
System
1
CargoDeliverySystem
2
GroundSupportSystem
3
RoboticPrecuserSystem
4
InSpace
SupportSystems
5
DestinationSurfaceSystems
6
FlightEnvironment
SpaceEnvironment
LaunchServiceProvider
ScienceCommunity
Public
LunarEnvironment
SpaceEnvironment
SpaceEnvironment
FlightEnvironment
SpaceEnvironment
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 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 bysatisfied by
defined byuses config
generates
causes
Studies
documents
External Programs
Doc Section
Requirement Function Equipment
VerificationRequirement
VerificationEvent
Test Procedure
Test Configuration
Issue
Risk
Analysistraces 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
Requirement
Related To Link rule #1
Analysis
Cart
Comment
Data block
Doc Section
Documents Lv2
Documents Lv3
Documents Lv4
DSNE
DVO
Equip Feature
ExternalResource
Functional
Glossary
Interface
Issue
Message
NGO
OpsCon
PBS
Plans
Reference
Result
Risk
SBS
Stakeholder
TEPOC
Test
Test result
Trade
TradeOption Set
Verification
WBS
WorkPackage
REQ-CONST
Cradle Exploration SchemaLink Rules Diagram
1/26/2007
Traces ToLink rule #3
Traces ToLink rule #
2005
Traces ToLink rule # 2662
Traces ToLink rule #3
Traces ToLink rule #3
Traces ToLink rule #3
Traces ToLink rule #3
Related ToLink rule #
2061Related ToLink rule #
2514Related To
Link rule #2512
Related ToLink rule #
2510 Related ToLink rule #1
Related ToLink rule #
2688
Related ToLink rule #
2508
Related ToLink rule #
2685
Related ToLink rule #
2678
Related ToLink rule #
2487
Related ToLink rule #
2467
Related ToLink rule #
2701
Related ToLink rule #
2073
Related ToLink rule #
2332
Related ToLink rule #1
Related ToLink rule #
2352
Related ToLink rule #
2304
Related ToLink rule #
980
ISpecRelated ToLink rule #
2069
Related ToLink rule #680PAD To PAD
ESpec Related ToLink rule #
2686
Related ToLink rule #102
Related ToLink rule #2220
Related ToLink rule #2154
Related ToLink rule #2150
Related ToLink rule #2101
Related ToLink rule #2599
Assigned ToLink rule #2589
Related ToLink rule # 2056
Realted ToLink rule # 2666
Assigned ToLink rule # 2667
Related ToLink rule # 2588
TEPOC AssociatedTo <any> Link rule #2591
Stakeholder AssociatedTo <any> Link rule #2668
Assigned ToLink rule # 2050
Assigned ToLink Rule # 2085
Assigned ToLink rule # 2563
Related ToLink rule # 2048
Comment ReviewTo <any> Link rule #2390
Assigned To Link rule # 2438
Assigned ToLink rule # 2745
Glossary References
To <any> Link rule #2435
Related ToLink rule # 2384
Assigned ToLink rule # 2404
Assigned To Link
rule # 2747
Reference DocumentedTo <any> Link rule #2408
Assigned ToLink rule # 2109
Assigned ToLink rule # 2623
Lv2 DocumentedTo <any>
Link rule #2607
Lv3 DocumentedTo <any>
Link rule # 2164
Lv4 DocumentedTo <any>
Link rule # 2234
Assigned ToLink
Rule #2162
Assigned ToLink rule #
2290
Assigned ToLink rule #
2232
Assigned ToLink rule #
2292
Data Block AssignedTo <any> Link
rule #2567
Studied ByLink rule # 2086
Risk Causes <any> Link rule # 1110
<any> GeneratesIssue Link rule # 2619
Studied ByLink rule # 2060 Assessment
Link rule # 2754
Traces ToLink rule #
2632
GeneratesLink rule
# 7
CausesLink rule
# 9
Assigned ToLink rule
# 11
VerifiesLink rule# 2539
VerifiesLink rule # 2516
Satisified ByLink rule #
2652
Satisfied ByLink rule #2740
GeneratesLink rule# 2656
AssessmentLink rule#2752
ACON# PerformsPAD# Link
Rule #400 Exhibits
Link rule #460
Supported ByLink rule#2470 Uses
Link rule# 2485
Modeled ByLink rule
# 420
Modeled ByLink rule# 2307
REQUIREMENTSDOMAIN
Modeled ByLink rule
# 560
Product ModelLink
Rule #2501
ACON# Related To ACON# Link Rule #
2064ACON# Performs
PAD# Link rule#2065
Supported ByLink Rule
#2474
Satisfied ByLink Rule
#2063
PAD# ExhibitsLink rule
#700
Pad# Satisfied By Link
rule # 2634
ACON# ExhibitsLink rule #2585
ACON# ModeledBy Link rule #
2019Satisfied By
Link rule# 780
ACON# ModeledBy Link rule
# 900
UsesLink rule#2483
Product ModelLink rule#2497
System ModelLink rule #
2499
Traces ToLink rule#2726
Related ToLink rule#2364
Traces toLink rule#1000
Supported ByLink rule#1030
Related ToLink rule# 1090
Studied ByLink rule#2649
Studied ByLink rule # 2305
Generates Link rule#2628
CausesLink rule # 2630
Passes Link rule # 2731
GeneratesLink rule# 2451
CausesLink rule# 2481
Has ResultLink rule #2513
ConstitutesLink rule # 2465
AssociatedLink rule #2722
AssociatedLink rule # 2680
AssociatedLink rule # 2682
AssociatedLink rule # 2690
Achieved ByLink rule # 2489
Designed By Link rule # 2493
Developed By Link rule # 2495
Has Result Link rule # 2697 Tested by
Link rule# 2583
Consists OfLink rule#2758
Consists Of Link rule # 2758Interfaces Link rule # 2761
ARCHITECTUREDOMAIN
PROGRAM MANAGEMENT
DOMAINDOCUMENTDOMAIN
VERIFICATIONDOMAIN
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 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
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.
SystemSystemUpdatesUpdates
DetailedDetailedDesignDesign
SystemsSystemsDesignDesign
ArchitectureArchitectureModellingModelling
TestTestRequirementRequirementManagementManagement
RequirementRequirementCaptureCapture
AcceptanceAcceptance& Signoff& Signoff
SystemSystemBuildBuild
DesignDesignEvaluationEvaluation
PerformancePerformanceAssessmentAssessment
SystemsSystemsAnalysisAnalysis
CustomerCustomerInterfaceInterface
16
Model Based Systems Engineering
System Definition
Requirements Requirements ModelModel
Functional Architecture
Functional ModelFunctional 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 ModelPhysical 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 ModelAnalysis Model10000 100
Maximum Altitude Alert Tactor Indication
00
1
Feel Maximum Altitude Alert Tactor Indication
Minimum Altitude Alert Tactor Indication
Platform Position and Motion Data
00
1
Rx Platform Position and Motion Data
Maximum Altitude Alert Tactor Actuation Signals
00
1
Actuate Maximum Altitude Alert Indication Tactors
Minimum Altitude Alert Tactor Actuation Signals
Determine Altitude Alerts
Generate Maximum Altitude Alert Tactor Actuation Signals
Host Platform Altitude Alert Conditions
00
1
Rx Host Platform Altitude Alert Conditions
Tx Platform Position and Motion Data
Generate Altitude Alert Platform Conditions
Date:11/9/2001
Author:kzook
Number:2.2.2
Name:Perform Altitude Alerts Tactile Situational Awareness
verified by
assigned to satisfied by satisfied by
assigned to defined by uses configuration
assigned to assigned to formed by
assigned to built from built from built from
connected to
connects to connects to
connected to connected to
connects to connects to
connected to
assigned to defined by uses configuration
assigned to assigned to formed by
assigned to built from built from built from
connected to
connects to connects to
connected to connected to
connects to connects to
connected to
KPP.4.1
System Compatibility, Block I
PerformanceIndex
KPP #4.1, EvaluationCriteria, System
Compatibility, Block I
VerificationRequirement
CM Platform Integration IPT
ResponsibleOrganization
KPP #4.1, SystemCompatibility VerificationTest 1, Bradley Fighting...
VerificationEvent
Lockheed Martin
ResponsibleOrganization
KPP #4.1, SystemCompatibility Verification
Test 1 Procedure, Bradl...
TestProcedure
Lockheed Martin
ResponsibleOrganization
KPP #4.1, SystemCompatibility Verification
Test 1 Configuration, Bra...
TestConfiguration
Lockheed Martin
ResponsibleOrganization
KPP.4.1.BFV.TS.1
KPP #4.1 Test Set 1,Bradley Fighting Vehicle
Component
Lockheed Martin
ResponsibleOrganization
KPP.4.1.BFV.TS.1.1
KPP #4.1 Test Set 1,Component 1, Bradley
Fighting Vehicle
Component
KPP #4.1, Test Set 1,Bradley Fighting Vehicle,
1553
Link
KPP.4.1.BFV.TS.1.1
KPP #4.1 Test Set 1,Component 1, Bradley
Fighting Vehicle
Component
KPP.4.1.BFV.TS.1.2
KPP #4.1 Test Set 1,Component 2, Bradley
Fighting Vehicle
Component
KPP.4.1.BFV.TS.1.2
KPP #4.1 Test Set 1,Component 2, Bradley
Fighting Vehicle
Component
KPP #4.1, Test Set 1,Bradley Fighting Vehicle,
1553
Link
KPP #4.1, Test Set 1,Bradley Fighting Vehicle,
28V Discrete
Link
KPP.4.1.BFV.TS.1.2
KPP #4.1 Test Set 1,Component 2, Bradley
Fighting Vehicle
Component
KPP.4.1.BFV.TS.1.3
KPP #4.1 Test Set 1,Component 3, Bradley
Fighting Vehicle
Component
KPP.4.1.BFV.TS.1.3
KPP #4.1 Test Set 1,Component 3, Bradley
Fighting Vehicle
Component
KPP #4.1, Test Set 1,Bradley Fighting Vehicle,
28V Discrete
Link
KPP #4.1, SystemCompatibility Verification
Test 1, Comanche
VerificationEvent
Lockheed Martin
ResponsibleOrganization
KPP #4.1, SystemCompatibility VerificationTest 1 Procedure, Com...
TestProcedure
Lockheed Martin
ResponsibleOrganization
KPP #4.1, SystemCompatibility VerificationTest 1 Configuration, C...
TestConfiguration
Lockheed Martin
ResponsibleOrganization
KPP.4.1.COM.TS.1
KPP #4.1 Test Set 1,Comanche
Component
Lockheed Martin
ResponsibleOrganization
KPP.4.1.COM.TS.1.1
KPP #4.1 Test Set 1,Component 1, Comanche
Component
KPP #4.1, Test Set 1,Comanche, 1553
Link
KPP.4.1.COM.TS.1.1
KPP #4.1 Test Set 1,Component 1, Comanche
Component
KPP.4.1.COM.TS.1.2
KPP #4.1 Test Set 1,Component 2, Comanche
Component
KPP.4.1.COM.TS.1.2
KPP #4.1 Test Set 1,Component 2, Comanche
Component
KPP #4.1, Test Set 1,Comanche, 1553
Link
KPP #4.1, Test Set 1,Comanche, 28V Discrete
Link
KPP.4.1.COM.TS.1.2
KPP #4.1 Test Set 1,Component 2, Comanche
Component
KPP.4.1.COM.TS.1.3
KPP #4.1 Test Set 1,Component 3, Comanche
Component
KPP.4.1.COM.TS.1.3
KPP #4.1 Test Set 1,Component 3, Comanche
Component
KPP #4.1, Test Set 1,Comanche, 28V Discrete
Link
Simulator
Host Computer - TMCS
Host Compuer - TSAS Simulator Terminal
Pilot
0.0
1.0
VCOP
Minimum Altitude
0.0
Maximum Altitude
1.0
0.0
1.0
1
Perform Pre-MissionVCOP Functions
AND
OR
Feel Maximum AltitudeAlert Tactor Indication
Feel Minimum AltitudeAlert Tactor Indication
OR
Rx Platform Position andMotion Data
AND
OR
Actuate MaximumAltitude Alert Indication
Tactors
Actuate MinimumAltitude Alert Indication
Tactors
OR
Determine Altitude Alerts
Generate MaximumAltitude Alert Tactor
Actuation Signals
Generate MinimumAltitude Alert Tactor
Actuation Signals
OR
AND
AND
Rx Host Platform AltitudeAlert Conditions
Tx Platform Position andMotion Data
Generate Alt itude AlertPlatform Conditions
AND
AND
3
Perform Post-MissionVCOP Functions
Maximum Altitude AlertTactor Indication
Minimum Altitude AlertTactor Indication
Platform Position andMotion Data
Host Platform AltitudeAlert Conditions
Maximum Altitude AlertTactor Actuation Signals
Minimum Altitude AlertTactor Actuation Signals
Date:11/9/2001
Author:kzook
Number:2.2.2
Name:Perform Altitude Alerts Tactile Situational Awareness
• Establish Source/Originating Requirements • Structured Hierarchy and Flowdown• Managed Traceability
• Level I to Derived Requirements• Requirements to Simulation and Verification Elements
Ground Mode Active Engagement
Ground Mode Passive Engagement
2.1.1
Determine Ground or AirEngagement Mode
2.1.2.1
Determine Ground ModePassive or Active
Engagement
2.1.2.2
Perform Ground ModePassive Engagement
2.1.2.3
Perform Ground ModeActive Engagement
OR
3
Perform Post-MissionFunctions
Date:Monday, August 27, 2001
Author:kzook
Number:2.1.2
Name:Perform Ground Engagement Mode Functions
Prim
ary
Pow
er; S
imul
ator
- R
etin
al S
cann
ing
Dis
play
(R
SD
)
Primary Power; Simulator - Audio System
Audio; Audio Amp/Mixer - Helmet Audio
Hum
an; P
ilot -
Hel
met
Aud
io C
ontr
ol
Prim
ary
Pow
er; S
imul
ator
- H
ead
Trac
king
Sys
tem
RS-232; Hea...
Syn
c; Im
age
Gen
erat
or -
Hea
d Tr
acke
r
Hum
an; P
ilot -
Aud
io S
ys...
Reflective Memory; Host Computer - Audio Computer
Video; ...
Ethernet; Hos...
Hum
an; P
ilot -
Hea
d Tr
acki
ng S
yste
m
Ref
lect
ive
Mem
ory;
Hos
t Com
pute
r -
Imag
e G
ener
a...
Prim
ary
Pow
er; S
imul
ator
- T
actil
e S
ituat
ion
Aw
aren
ess
Sys
tem
(T
SA
S)
Eth
erne
t; H
ost C
ompu
ter
- F
light
Mod
el C
om...
Hum
an; P
ilot -
Tac
tile
Ves
t
Sof
twar
e; H
ost C
ompu
ter
RP
A/C
DA
- S
imul
ated
...
Eth
erne
t; H
ost C
ompu
ter
- Te
am P
laye
r C
omp.
..
Hum
an; P
ilot -
Hos
t Com
pute
r
Eth
erne
t; H
ost C
ompu
ter
- Im
age
Gen
er...
Hum
an; P
ilot -
Tac
tile
Situ
atio
n A
war
enes
s S
yste
m (
TS
AS
)
Syn
c; Im
age
Gen
erat
or -
Hos
t Com
pu...
Hum
an; P
ilot -
Hel
met
Aud
io
Hum
an; P
ilot -
Ret
inal
Sca
nnin
g D
ispl
ay (
RS
D)
Vis
ual
Audio; Helmet Microphone - Speech Recognition System
Prim
ary
Pow
er; S
imul
ator
- H
ost C
ompu
...
Hum
an; P
ilot -
Hel
met
Mic
roph
one
V.HC
VCOP Host Computer
Component
V.CS
Crew Station
Component
V.AS
Audio System
Component
S
Simulator
Component
P
Pilot
Component
Date:11/8/2001
Author:Administrator
Number:V
Name:VCOP System
Allocated Architecture
SystemSystemUpdatesUpdates
DetailedDetailedDesignDesign
SystemsSystemsDesignDesign
ArchitectureArchitectureModellingModelling
TestTestRequirementRequirementManagementManagement
RequirementRequirementCaptureCapture
AcceptanceAcceptance& Signoff& Signoff
SystemSystemBuildBuild
DesignDesignEvaluationEvaluation
PerformancePerformanceAssessmentAssessment
SystemsSystemsAnalysisAnalysisCradleCradle
SystemSystemUpdatesUpdates
DetailedDetailedDesignDesign
SystemsSystemsDesignDesign
ArchitectureArchitectureModellingModelling
TestTestRequirementRequirementManagementManagement
RequirementRequirementCaptureCapture
AcceptanceAcceptance& Signoff& Signoff
SystemSystemBuildBuild
DesignDesignEvaluationEvaluation
PerformancePerformanceAssessmentAssessment
SystemsSystemsAnalysisAnalysisCradleCradle
ALTAIR (LUNAR LANDER VEHICLE)
EXAMPLE APPLICATION
18
Interrelationships Among the SystemDesign Processes as Stated in NASA SE Handbook
MissionObjectives &Constraints
OperationalObjectives
Mission Success Criteria (MOEs)
Stakeholder Expectations
High LevelRequirements
Functional/Logical
Decomposition
Design &Product
BreakdownStructure
Derived &Allocated Reqs• Func• Perf•Interface•Operational•Illities
CONOPs
Trade Studies & Iterative Design Loop (3 Products must be consistent)
Functional &Performance
AnalysisSufficient
Depth?NO
Next Level
Work?Safe &
Reliable?Affordable?
YES
ReBaselineRequirements?
NO
NO
YES SelectBaseline
YES
Start
Stakeholder Expectation Definition
Technical requirements Definition
Functional / Logical decomposition
Design Solution
Design Analysis
Altair PFDs Linked to CapabilitiesGenerate Altair OpsCon
Hierarchy Defined to meet
Requirements
Functional Scenarios built thru hierarchy to Validate against Expectations/PFDs
DecomposeTo level where Allocation can occur
All -ility Reqs met within budget?
If Altair doesn’t agree with 3.7.3 ReqsMust pushback to level 2
Developed Activity Models
1. Derive Altair LCAPs
2. Link/Review CARD 3.7.3 Reqs
To LCAPs4. Identify LCAPs gaps5. derive new Altair reqs6. categorize Reqs
3.Build Altair eFFBD; 8. Allocate
Func/PerfReqs to
Altair SystemFunctions
7. Decompose/ Rebuild to complete system leveleFFBD
Altair Hierarchy
19
Hierarchy of Product Traceability
LSC Phase Model
LSC Phase Models
CapabilitiesCapabilities
CapabilitiesCapabilities
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 ModelsFurther Define Phases
One or multiple capabilitiesLinked to LNDR Activity PFDs
All types of RequirementsDerived, Categorized and Linked to Capabilities
Only Functional/PerformanceRequirements 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 ModelLSC DRM
Phase Model
Activity (Scenarios)Models
LNDR Phase
Ops Con Descriptions
20
Altair Traceability Process
Derive
Altair
Operational
PFDs
LNDR Analysis.1
Link
Requirements
LNDR Analysis.2
Build
Altair
System
Functional
Architecture
LNDR Analysis.3
DRM OCD
Cx
Mission
Phase
Model
Altair
PFD Phase
Models
Capabilities
Linked to
Models CARD
3.7.3
Reqs
Linked to
LCAPs
Missing
Reqs
Derived
Linked to
LCAPs
Developed
High
Level
Altair FA
eFFBDs
Func /
Perf Reqs
for
Altair
Linked to
FA
Populated
Altair
Perf
Characteristics
3.2.1 Reqs
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.12.The inputs/outputs of the major activities showing how each activity impacts other activities3.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
AltairMission
Phases
LNDR Analysis.1.1
Develop
AltairOps
Models
for Phases
LNDR Analysis.1.2
Define
Capabilitiesfor Ops
Models
LNDR Analysis.1.3
Reviewed
DRM OCD
ReviewedCx
Mission
Phase
Model
AssignedModel
Phases
for Altair
DevelopedRepresentative
Altair
Ops Models
AltairLCAPs
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 Models2. Derive Altair LCAPs
22
Lunar Sortie Crew DRM
CRADLE V5.6 Produced by: RBAYT Date: 03/04/08 Page: 1 of 1 UNCLASSIFIED
I LSC Owner: RBAYT Versn : Dft: A Created: 28/03/08PFD DRM: Lunar Sortie Crew Baseline: Last Mod: 30/03/08
OPS Models Developed
StandAlone
OperationsLSC.1
IntegratedOperations
LSC.2
PadOperations
LSC.3
Launch
LSC.4
Ascent
LSC.5
LEOConfiguration
(Post-Insertion)LSC.6
LEO Loiter
LSC.7
RPODOperations
(LEO)LSC.8
TLIPreparation
LSC.9
Trans -LunarCruiseLSC.10
LOIOperations
LSC.11
Pre-SurfaceOperations
(LDO)LSC.12
LunarLander
DescentLSC.13
AND AND
SurfaceOperations
LSC.14
LunarOrbit
MaintenanceLSC.15
Lunar Ascentand RPODOperations
(LRO)LSC.16
TEIOperations
LSC.17
Trans-Earth
CruiseLSC.18
EarthArrival
OperationsLSC.19
Re-entry/Entry
LSC.20
Descentand
Landing
LSC.21
Recovery
LSC.22
Post - Flight
Processing
LSC.23
DD250
Transport toIntegration
FacilityComplete
MLP HardDown
LCD CTS
T - 0
OrbitInsertionMNVR
Complete
'Go' for
Orbit Ops
InitiateRendezvous
Burn
DockingComplete
TLI BurnComplete
Start LOIBurn Prep
LOI BurnComplete
PwrdDescentInitiation
Burn
ATPInitiate
Prep
DockingComplete
TEI BurnComplete
FinalEntryPrep
<EI-12>
SMSeparation
Fwd BayCover
Jettison
Touchdown
ArrivalPost - Flight
ProcessingFacility
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.6 Produced by: ACHR_A Date: 09/03/08 Page: 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 * * 30 minutes *
24
EDS
Altair
Orion
Mission Ops
AND ANDAND AND
MonitorLanderHealth
and Status
LEO_RPREP.9
RelayAltair
Data &Comm
LEO_RPREP.1 MaintainEDS/Altair
LEOLoiter
Attitude
LEO_RPREP.2
InitiateRendezvous
Burn
TargetReached -Nav Statefor LEO
Rendezvous
AND AND
SustainLander -RPOD
Operations(LEO)
LEO_RPREP.3
ActivateRF Comm
LEO_RPREP.4
Prep - 1 hour *
ActivateApproach
Lights
LEO_RPREP.5
AND AND
PerformInitial
RendezvousBurn
LEO_RPREP.8
ActivateAltair RFcomm forCmd Tlm
andRanging
LEO_RPREP.6
ActivateAltair RF
commcommand
ActivateAltair
ApproachLights
LEO_RPREP.7
ActivateAltair
approachlights
command
1. Develop Altair ActivityPFD, derive LCAP(s) forThis Diagram
The spec for this diagramWill be linked to the LEORendezvous Spec containedIn the RPOD Operationsphase 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 ActivityLinked to phase, RPOD.5Post Dock Operations
26
Workbench View of RPOD Spec Linked to LNDR OPS CON Item
A new Ops Con itemIs developed that Contains the Altair RPOD Phase Definition
This Ops Con item isLinked to the RPODSub-Phase Diagram Spec…
This is the RPOD Specfor the phasemodel
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
ActivityModel
RPOD Phase Model may be linked to multiple DRM Models
LEORendezvous
Prep
RPOD.1
Prox Ops
RPOD.2
Post DockOperations
RPOD.3
LEORendezvous
RPOD.4
DockingOperations
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 theAltair Activity Models (scenarios) Specs
CLSC RPOD
VLO RPOD
RLO RPOD
ORO RPOD
LCAP LCAP 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 /Categorize
CARD3.7.3 Reqs
LNDR Analysis.2.1
IdentifyCARD3.7.3
Functional/PerformanceReqs
LNDR Analysis.2.2
OR OR
Link AllCARD3.7.3
Func/PerfReqs toLCAPs
LNDR Analysis.2.3
Link anyotherCARD3.7.3
Reqs ThatApply toLCAPs
LNDR Analysis.2.4
DeriveAdditional
Functional/PerformanceReqs AsNeeded
LNDR Analysis.2.5
RecommendAdditional
CARD3.7.3
Reqs beDeveloped
LNDR Analysis.2.6
CARD3.7.3
Requirements
CategorizedCARD3.7.3
Requirements
AltairLCAPsDerived
and Linked
LinkedCARD3.7.3
Func/PerfReqs toLCAPs
Func/PerfReqs GapsIdentified
ApplicableReqs
Linked toLCAPs
OtherApplicableReqs GapsIdentified
NewFunc/Perf
ReqsDerived
as LNDRCandidate
Reqs
DevelopedCR for
New CARD3.7.3 Reqs
IdentifiedCARD3.7.3
Func/PerfReqs
All OtherCategorized
CARD3.7.3 Reqs
NewFunc/Perf
ReqsLinked toLCAPs
• 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
CLSC RPOD
VLO RPOD
RLO RPOD
ORO RPOD
CLSC RPOD
VLO RPOD
RLO RPOD
ORO RPOD
CActivityModel
LCAP LCAP LCAPCapabilities will be developed and linked to theAltair Activity Models (scenarios) SpecsLCAP LCAP LCAP
RPODOperations
Req 1
Req 3
Req 2
Func/Perf ReqsDrive 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 AND
PerformCommunications
LNDR.1
SustainAltair
Environment
LNDR.2
Command &Control
LNDR.3
Maneuver
LNDR.4
ManageVehicle
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 RprepFunctional Req Linked to LCAP
Functional Req Drives FA (Linked to Func)
31
Query: Ops to LCAPs to Reqs to FuncTraceability Report
Operational SpecsFrom Activity Models,Phase Models, PhaseModels
LCAPsRequirementsLinked to LCAPs
FunctionsLinked to Requirements
32
Group All
Func/Perf
Reqs into
Functional
Groupings
new.1
Derive
Functions/eFFBD
Based on
Groupings
new.2
Validate
FFBD by
Ensuring
Against
Ops Model
new.3
Link All
Func/Perf
Reqs to
Functions
new.4
Linked
CARD
3.7.3
Func/Perf
Reqs to
LCAPs
New
Func/Perf
Reqs
Linked to
LCAPs
Identified
Functional
Groupings
Functions
Derived
on
Construct/
eFFBD
Developed
Validated
eFFBD
Linked
Reqs to
Functions
Develop
Functional
Threads
new.5
System
eFFBDs
Validated
Functional/Performance
Analysis
AND AND
Decompose
Functions
To System
Allocation
Level
new.6
Allocate
functions
To Altair
Spec
new.7
Allocated
Functions
Link
System
High
Level
FFBD to
SRD
Section
3.2.1
new.8
Populated
Altair
Perf
Characterisitics
3.2.1 Reqs
Derived
Functions
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.6 Produced by: RBAYT Date: 09/03/08 Page: 1 of 1 UNCLASSIFIED
I LNDR Owner: ACHR_A Versn: Dft: A Created: 07/29/08BD Carry Crew & Cargo to Lunar Surface Baseline: Last Mod: 09/03/08
Function
Discrete Item
Timeline
Data Link
Trigger Data Link
KEY
AND AND
PerformCommunications
LNDR.1
SustainAltair
Environment
LNDR.2
PerformCommand &
Control
LNDR.3
Maneuver
LNDR.4
VoiceComms
Commandsto Altair
Data
VoiceComms
RelayedComms
CrewActions
Command_ControlCommsHealth
andStatus ofLander
Systems
ExternalPower
LanderNavigation
Data
LanderGuidance
Data
Healthand
StatusComms
ManageVehicle
Performance
LNDR.5
ProvideTransportation
andHabitability
LNDR.6
Commandsto Cx
Systems
FaultDetectionRecovery
Commands
StateVector
Updates
CommandExecution
Status
ManeuverCommands
CrewIngressed
GroundPersonnelIngressed
CargoMounted
CrewEgressed
CargoOff-Loaded
GroundPersonnelEgressed
EnvironmentalSet Points
35
Command and Control
OR OR
ReceiveCommandson Lander
LNDR.3.1
AcceptLander
Crew Input
LNDR.3.2
CheckCommand
Validity
LNDR.3.4
AND AND
ProvideCommandExecution
Status
LNDR.3.8
OR OR
ExecuteCommand/Command
Sequences
LNDR.3.6Send
Commandsfrom
Lander
LNDR.3.7
PrioritizeCommands
LNDR.3.5
AcceptCommands
fromVehicle
Manager
LNDR.3.3
FaultDetectionRecovery
Commands
CrewActions
Commandsto Altair
CommandExecution
Status
OR OR
ReceiveCommandson Lander
LNDR.3.1
AcceptLander
Crew Input
LNDR.3.2
CheckCommand
Validity
LNDR.3.4
AND AND
ProvideCommandExecution
Status
LNDR.3.8
OR OR
ExecuteCommand/Command
Sequences
LNDR.3.6Send
Commandsfrom
Lander
LNDR.3.7
PrioritizeCommands
LNDR.3.5
AcceptCommands
fromVehicle
Manager
LNDR.3.3
FaultDetectionRecovery
Commands
CrewActions
Commandsto Altair
CommandExecution
Status
36
Requirements linked to Command & Control
LNDR.3.1 Receive Commands on Lander
R.EA3250 SAIR LSAM shall provide interface
The LSAM shall provide an interface for the crew to generate commands for Lunar Sortie and Lunar Outpost crew missions.
In order to perform command and control, the crew will need to be able to initiate the sending of commands.
R.EA5278 LSAM Manual Control
The LSAM shall provide onboard, manual control of flight path, attitude, and attitude rates when the human can operate the system within vehicle margins for Lunar Sortie Crew and Lunar Outpost Crew missions.
This requirement flows down from NPR 8705.2, Human-Rating Requirements for Space Systems, manual control of spacecraft attitude, attitude rate, and flight path provides additional margin for mission success and crew safety.
LNDR.3.3 Accept Commands from Vehicle Manager
LNDR.3.4 Check Command Validity
R.LNDR.017 Command Validity Checking
The Altair shall provide command validity checking.
The Altair may be exposed to hazards or loss of mission (LOM) or loss of vehicle if they are not protected from inadvertent commanding. This is important for all commands, particularly hazardous, inhibit controls, inadvertent and all safety-critical commands. The validity checking is the validation necessary to ensure that an input command contains values that are appropriate for (i.e., command source, prerequisite conditions, parity, values, addresses, sequence) or may be issued to the end-item in its current state or configuration. If the input command fails the validity check, it should be discarded.
LNDR.3.5 Prioritize Commands
R.EA3258 SAIR LSAM execute commands in current state
The LSAM shall execute commands valid in the current state.
The system will execute commands from other systems in order to perform the specified function or operation. This process includes checking if the command has valid data values and can be executed now based on the current state or mode. Updates to the corresponding Health and Status parameters provide the execution end item result.
R.EA3272 SAIR LSAM shall generate commands
The LSAM shall generate commands. To perform command and control, the ground and automated sequences will need to be able to initiate the sending of commands. These commands will be either executed internally or transmitted to another Constellation system to be received and executed.
R.EA5902 Recon FOIT Requirement
The LSAM shall accept reconfiguration of stored commands, sequences and data.
The LSAM needs to accept changes to sequences, commands, and data parameters already stored onboard, when the Ground or Missions systems initiate such reconfiguration actions. Reconfiguration actions may impact procedures, operations time-lines, or onboard algorithms which operate on commandable data items to support mission activities.
R.EA5905 Recon FOIT Requirement
The LSAM shall execute reconfigurable automation sequences valid in the current state.
The system will execute reconfigurable automation sequences based on triggers that may be generated internally or from other systems (by means of commands) in order to perform the specified function or operation. This process includes checking if the sequence has valid data values and can be executed now based on the current state or mode. Results of the execution are provided through updates to the sequencing Health and Status parameters.
LNDR.3.7 Send Commands from Lander
LNDR.3.8 Provide Command Execution Status
R.LNDR.012 Command Execution Status
The Altair shall provide execution status of commands.
Command initiators should know the status of commands for monitoring and awareness of vehicle state. The status along with command history can be provided at various stages of the command execution process, including receipt, cueing, validation, effector initiation, etc., and will be provided to the crew, ground, or command initiator as determined.
LNDR.3 Command & Control
LNDR.3.2 Accept Lander Crew Input
LNDR.3.6 Execute Command/Command Sequences
37
Principles 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” 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 hierarchyFunction – 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/State Coast State Crewed Powered Flight
Life Support Dormant Normal
Thermal ½ Capacity Normal
Power System External Power Full Power
Propulsion Attitude Control about Deadband
Active MPS
GN&C Active Active
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.
EDS
Altair
AND ANDAND AND
RelayAltair
Data &Comm
LNDR.LEO_RPREP.1 MaintainEDS/Altair
LEOLoiter
Attitude
LNDR.LEO_RPREP.2
AND AND
SustainLander -RPOD
Operations(LEO)
LNDR.LEO_RPREP.3
ActivateRF Comm
LNDR.LEO_RPREP.4
Prep - 1 hour *
ActivateApproach
Lights
LNDR.LEO_RPREP.5
Sustain Lander is the state that enables Operations
Sustain Lander
Re
sou
rce
Util
iza
tion
Act
iva
te L
igh
ts
Act
iva
te C
om
m
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
SustainLander -
TLIOperations
(LEO)
SustainLander -
LOIOperations
(LEO)
SustainLander -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.
SustainLander -
LOIOperations
(LEO)
Maneuver (Integrated Stack Powered Flight)
LNDR.4
Mode
Phase
AND AND
Navigate
*LNDR.4.1*
Perform
Translational
Maneuvers
*LNDR.4.2*
Perform
Attitude
Control
*LNDR.4.3*
Perform
Guidance
*LNDR.4.4*
AND AND
Navigate
*LNDR.4.1*
Perform
Translational
Maneuvers
*LNDR.4.2*
Perform
Attitude
Control
*LNDR.4.3*
Perform
Guidance
*LNDR.4.4*
Mode Unique Capabilities
• Perform Integrated Stack Attitude Control
Maneuver(Shadow)
LNDR.4
SustainLander -
TLIOperations
(LEO)
• Perform Integrated Stack State Estimation
AND AND
Navigate
*LNDR.4.1*
Perform
Translational
Maneuvers
*LNDR.4.2*
Perform
Attitude
Control
*LNDR.4.3*
Perform
Guidance
*LNDR.4.4*
AND AND
Navigate
*LNDR.4.1*
Perform
Translational
Maneuvers
*LNDR.4.2*
Perform
Attitude
Control
*LNDR.4.3*
Perform
Guidance
*LNDR.4.4*
Mode Thread Unique to function
Mode Independent Functional Architecture
Maneuver
LNDR.4
AND AND
Navigate
*LNDR.4.1*
Perform
Translational
Maneuvers
*LNDR.4.2*
Perform
Attitude
Control
*LNDR.4.3*
Perform
Guidance
*LNDR.4.4*
AND AND
Navigate
*LNDR.4.1*
Perform
Translational
Maneuvers
*LNDR.4.2*
Perform
Attitude
Control
*LNDR.4.3*
Perform
Guidance
*LNDR.4.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 EVA
Interfaces
EVA Altair
Interfaces
Altair
Ground
Systems
Interfaces
Ground
Systems
Altair
Interfaces
Altair C&TN
Interfaces
C&TN Altair
Interfaces
Altair
Mission
Systems
Interfaces
Mission
Systems
Altair
Interfaces
Orion
AltairInterfaces
Altair
OrionIterfaces
Crew Altair
Interfaces
Altair to
CrewInterfaces
Altair to
Induced
Environment
Interfaces
Natural
Environmentto Altair
Altair
EVA
Ground
Systems
Mission
Systems
Orion
C&TN
Space
Natural
Induced
Environments
Crew
Altair Context Model:• Shows External interfacing systems• Lines between Altair and external systems illustrate interfaces between
46
Altair EVAInterfaces
EVA AltairInterfaces
AltairGround
SystemsInterfaces
GroundSystems
AltairInterfaces
Altair C&TNInterfaces
C&TN AltairInterfaces
AltairMissionSystemsInterfaces
MissionSystems
AltairInterfaces
OrionAltair
Interfaces
AltairOrion
Iterfaces
Crew AltairInterfaces
Altair toCrew
Interfaces
Altair toInduced
EnvironmentInterfaces
NaturalEnvironment
to Altair
Altair
EVA
GroundSystems
MissionSystems
Orion
C&TN
SpaceNatural
InducedEnvironments
Crew
AND AND
PerformCommunications
LNDR.1
SustainAltair
Environment
LNDR.2
Command &Control
LNDR.3
Maneuver
LNDR.4
VoiceComms
Commandsto Altair
Data
VoiceComms
RelayedComms
CrewActions
Command_ControlCommsHealth
andStatus ofLander
Systems
ExternalPower
LanderNavigation
Data
LanderGuidance
Data
Healthand
StatusComms
ManageVehicle
Performance
LNDR.5
Transport
LNDR.6
Commandsto Cx
Systems
FaultDetectionRecovery
Commands
StateVector
Updates
CommandExecution
Status
ManeuverCommands
CrewIngressed
GroundPersonnelIngressed
CargoMounted
CrewEgressed
CargoOff-Loaded
GroundPersonnelEgressed
EnvironmentalSet Points
And Node (Parallel)
Integration of Functional & Physical Models
Functional InterfacesCarried by “Physical”
Interfaces
Altair Functions are allocated toAltair Equipment spec (system)
47
Transport
Command and Control
Communication
Maneuverability
Habitability
Vehicle Management
Altair
Altair Functional Model
Crewed Landers OnlyCommon 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
ManagerThe 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 OnlyCommon 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.23.2.1 Common Characteristics
3.2.1.1 Common Performance Characteristics
3.2.2 Crewed Mission Characteristics 3.2.2.1 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 OnlyCommon to all Landers
DockingComplete
TLI Burn
Complete
Post-DockOperations
*LSC.9.1*
LEOPost-Dock
Loiter
*LSC.9.2*
CheckoutCEV PowerTransfer*LSC.9.3*
"First"LanderIngress
*LSC.9.4*
Transferof
CriticalSupplies*LSC.9.5*
"Final"EgressLander
*LSC.9.6*
EarthOrbitLoiter
*LSC.9.7*
Preparefor TLIBurn
*LSC.9.8*
Preparefor TLIBurn
*LSC.9.8*
PerformTLI Burn
*LSC.9.9*
Post TLIBurn
Operations
*LSC.9.10*
Post-DockOperationsComplete
Go forpower
transferc/o
Go forLanderIngress
Go forsupplytransfer
Go forEgressLander
Engresscomplete
Go forTLI burn
preparation
Enginecut-off
Go forTLI burn
maneuver
Start LOIBurn Prep
LOI BurnComplete
LanderPower
ActivationOperations
*LSC.11.1*
LanderPowered
CoastOperations
*LSC.11.2*
LOI BurnOperations
*LSC.11.3*
Post-LOIBurn
Operations
*LSC.11.4*
Go forLOI Burn
Operations
TerminateBurn -
LOI Burn
'Go' forPowered
Coast
Start LOIBurn Prep
LOI BurnComplete
LanderPower
ActivationOperations
*LSC.11.1*
LanderPowered
CoastOperations
*LSC.11.2*
LOI BurnOperations
*LSC.11.3*
Post-LOIBurn
Operations
*LSC.11.4*
Go forLOI Burn
Operations
TerminateBurn -
LOI Burn
'Go' forPowered
Coast
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
TLI Burn
Complete
Preparefor TLIBurn
*LSC.9.8*
Preparefor TLIBurn
*LSC.9.8*
PerformTLI Burn
*LSC.9.9*
Post TLIBurn
Operations
*LSC.9.10*
Go forTLI burn
preparation
Enginecut-off
Go forTLI burn
maneuver
Cargo OPSCON
Item
Cargo Mission Description
Cargo OPSCON
Item
50
Altair Operational Model
Crewed Landers OnlyCommon to all Landers
DockingComplete
TLI Burn
Complete
Post-DockOperations
*LSC.9.1*
LEOPost-Dock
Loiter
*LSC.9.2*
CheckoutCEV PowerTransfer*LSC.9.3*
"First"LanderIngress
*LSC.9.4*
Transferof
CriticalSupplies*LSC.9.5*
"Final"EgressLander
*LSC.9.6*
EarthOrbitLoiter
*LSC.9.7*
Preparefor TLIBurn
*LSC.9.8*
Preparefor TLIBurn
*LSC.9.8*
PerformTLI Burn
*LSC.9.9*
Post TLIBurn
Operations
*LSC.9.10*
Post-DockOperationsComplete
Go forpower
transferc/o
Go forLanderIngress
Go forsupplytransfer
Go forEgressLander
Engresscomplete
Go forTLI burn
preparation
Enginecut-off
Go forTLI burn
maneuver
Start LOIBurn Prep
LOI BurnComplete
LanderPower
ActivationOperations
*LSC.11.1*
LanderPowered
CoastOperations
*LSC.11.2*
LOI BurnOperations
*LSC.11.3*
Post-LOIBurn
Operations
*LSC.11.4*
Go forLOI Burn
Operations
TerminateBurn -
LOI Burn
'Go' forPowered
Coast
Start LOIBurn Prep
LOI BurnComplete
LanderPower
ActivationOperations
*LSC.11.1*
LanderPowered
CoastOperations
*LSC.11.2*
LOI BurnOperations
*LSC.11.3*
Post-LOIBurn
Operations
*LSC.11.4*
Go forLOI Burn
Operations
TerminateBurn -
LOI Burn
'Go' forPowered
Coast
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
TLI Burn
Complete
Preparefor TLIBurn
*LSC.9.8*
Preparefor TLIBurn
*LSC.9.8*
PerformTLI Burn
*LSC.9.9*
Post TLIBurn
Operations
*LSC.9.10*
Go forTLI burn
preparation
Enginecut-off
Go forTLI burn
maneuver
Cargo OPSCON Item
Cargo Mission Description
Cargo OPSCON Item
Cargo Mission Description
Assign Model and OPSCON Item to Doc Section for Doc Pub
1. Assumptions2. Ops Capability by Phase
2.1 Ground Ops2.2 Launch2.3 LEO Ops2.4 LEO Loiter2.5 LEO Rndz2.6 TLI Prep
2.6.1 Crewed TLI Prep
2.6.2 Cargo TLI Prep
DockingComplete
TLI Burn
Complete
Post-DockOperations
*LSC.9.1*
LEOPost-Dock
Loiter
*LSC.9.2*
CheckoutCEV PowerTransfer*LSC.9.3*
"First"LanderIngress
*LSC.9.4*
Transferof
CriticalSupplies*LSC.9.5*
"Final"EgressLander
*LSC.9.6*
EarthOrbitLoiter
*LSC.9.7*
Preparefor TLIBurn
*LSC.9.8*
Preparefor TLIBurn
*LSC.9.8*
PerformTLI Burn
*LSC.9.9*
Post TLIBurn
Operations
*LSC.9.10*
Post-DockOperationsComplete
Go forpower
transferc/o
Go forLanderIngress
Go forsupplytransfer
Go forEgressLander
Engresscomplete
Go forTLI burn
preparation
Enginecut-off
Go forTLI burn
maneuver
Common Mission Description
TLI Burn
Complete
Preparefor TLIBurn
*LSC.9.8*
Preparefor TLIBurn
*LSC.9.8*
PerformTLI Burn
*LSC.9.9*
Post TLIBurn
Operations
*LSC.9.10*
Go forTLI burn
preparation
Enginecut-off
Go forTLI burn
maneuver
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
Navigation
Control
Guidance
AND AND
EstimateVehicleState
LSCBD.16.7.1.1
EvaluateVehicleState
Relativeto Input
Trajectory
LSCBD.16.7.1.3
InputTrajectory
- LunarAscent
TerminateBurn -LunarAscent
EstimatedVehicleState
AND AND
ControlVehicleAttitude
LSCBD.16.7.1.2ControlVehicleImpulse
LSCBD.16.7.1.4
GuidanceCommands
Navigation
Control
Guidance
AND AND
EstimateVehicleState
LSCBD.16.7.1.1
EvaluateVehicleState
Relativeto Input
Trajectory
LSCBD.16.7.1.3
InputTrajectory
- LunarAscent
TerminateBurn -LunarAscent
EstimatedVehicleState
AND AND
ControlVehicleAttitude
LSCBD.16.7.1.2ControlVehicleImpulse
LSCBD.16.7.1.4
GuidanceCommands
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