srd development process using model based systems engineering altair project integration robert bayt...

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

http://www.threesl.com/

http://www.threesl.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





Related ToLink rule #

2061Related ToLink rule #

2514Related To

Link rule #2512


2510 Related ToLink rule #1


2688


2508


2685


2678


2487


2467


2701


2073


2332

Related ToLink rule #1


2352


2304


980

ISpecRelated ToLink rule #

2069

Related ToLink rule #680PAD To PAD

ESpec Related ToLink rule #

2686







Assigned ToLink rule #2589

Related ToLink rule # 2056

Realted ToLink rule # 2666

Assigned ToLink rule # 2667


TEPOC AssociatedTo <any> Link rule #2591

Stakeholder AssociatedTo <any> Link rule #2668


Assigned ToLink Rule # 2085



Comment ReviewTo <any> Link rule #2390

Assigned To Link rule # 2438


Glossary References

To <any> Link rule #2435



Assigned To Link

rule # 2747

Reference DocumentedTo <any> Link rule #2408



Lv2 DocumentedTo <any>

Link rule #2607


Link rule # 2164


Link rule # 2234

Assigned ToLink

Rule #2162

Assigned ToLink rule #

2290


2232


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



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


connected to

assigned to defined by uses configuration

assigned to assigned to formed by

assigned to built from built from built from

connected to


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


KPP #4.1, SystemCompatibility Verification

Test 1 Procedure, Bradl...

TestProcedure

Lockheed Martin



Test 1 Configuration, Bra...

TestConfiguration

Lockheed Martin


KPP.4.1.BFV.TS.1

KPP #4.1 Test Set 1,Bradley Fighting Vehicle

Component

Lockheed Martin


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


Fighting Vehicle

Component

KPP.4.1.BFV.TS.1.2


Fighting Vehicle

Component

KPP.4.1.BFV.TS.1.2


Fighting Vehicle

Component


1553

Link


28V Discrete

Link

KPP.4.1.BFV.TS.1.2


Fighting Vehicle

Component

KPP.4.1.BFV.TS.1.3


Fighting Vehicle

Component

KPP.4.1.BFV.TS.1.3


Fighting Vehicle

Component


28V Discrete

Link


Test 1, Comanche

VerificationEvent

Lockheed Martin


KPP #4.1, SystemCompatibility VerificationTest 1 Procedure, Com...

TestProcedure

Lockheed Martin


KPP #4.1, SystemCompatibility VerificationTest 1 Configuration, C...

TestConfiguration

Lockheed Martin


KPP.4.1.COM.TS.1

KPP #4.1 Test Set 1,Comanche

Component

Lockheed Martin


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


Component

KPP.4.1.COM.TS.1.2


Component

KPP.4.1.COM.TS.1.2


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


Component

KPP.4.1.COM.TS.1.3


Component

KPP.4.1.COM.TS.1.3


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











SystemsSystemsAnalysisAnalysisCradleCradle











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


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


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


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


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


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


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


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


*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


DockingComplete

TLI Burn

Complete

Post-DockOperations

*LSC.9.1*

LEOPost-Dock

Loiter

*LSC.9.2*



*LSC.9.4*

Transferof


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


Go forpower

transferc/o

Go forLanderIngress


Go forEgressLander

Engresscomplete

Go forTLI burn

preparation

Enginecut-off

Go forTLI burn

maneuver

Start LOIBurn Prep

LOI BurnComplete

LanderPower


*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


*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 OPSCON Item


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*



*LSC.9.4*

Transferof


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


Go forpower

transferc/o

Go forLanderIngress


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


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

srd development process using model based systems engineering altair project integration robert bayt...

Documents

operational requirements

system of systems

science system ground

system engineering processes

scenarios requirements

source requirements

requirements traceability

system architecture