MBSE ARCHITECTUREMODELING METHODOLOGY

Project Management Challenge 2010

Jeff Robinson

Special thanks to Scott Lukens

Used with Permission

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

2

Agenda

A. OverviewB. Architecture Methodology (Physical)

1. Context Diagram2. Decompose Physical Elements

C. Architecture Methodology (Operational & Functional)1. Architecture Modeling Activities (with examples)

D. Use Models to Help Derive Requirements1. Architecture Methodology Requirement Types2. Characterization List3. Derive Operational and Performance Requirements4. Interface Requirements5. Trace Derived Requirements to Model Elements

E. Model-Based Output

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

3

A. Overview

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

4

Requirements Gathering & Operational Analysis

• Identify Source Material, Operational Context, Use Cases, Scenarios, Information Exchange

• Establish Initial Requirements Set• Establish Design Constraints• Capture Issues / Risks / Decisions

Requirements Model

System ArchitectureAnalysis

• System Structure (i.e., Hierarchy of System Elements)

• Interfaces between System Elements

• Allocate Functional Behavior and Non-Functional Requirements

System Architectures

Functional Behavior Analysis

• Operational Scenarios• Integrated Behavior Models• Derive Functional / Performance

Requirements• Define I/O• Define Effectiveness Measures

Functional Models

Model-Based Systems Engineering (MBSE)

Advantages of MBSE over Document Centric ApproachShows Complete full picture of Architecture/Stakeholder Problem.Generates executable artifacts.Allows requirements conformance and consistency checking to be assessed and validated.Orchestrates understanding of a design in all phases of the development lifecycle.

Document Centric

Approach

MBSE Approach

R1.2.1

R1.1 R1.2

R1

Trade

Issue

F1 F5

F3 F4

F2

Equipment List

System of Systems

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

(6) Decompose Mission Operation

(1) Identify Life Cycle Phase

(2) Identify DRM Mission Phase(ConOps)

(3) Develop Mission Sub-phases

(4) Model Nominal & Off-Nominal Activities (Operational Scenarios)

(7) Develop Top-Level System Functions

Part 1 – Develop Hierarchical Architecture Model

(8) Decompose Functions

(5) Develop Mission Operation for Each Scenario

5

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

yPart 2 – Use Architecture Models to Help

Derive Requirements

Model Characterize Requirement(s)

Operational/ Capability Requirements External Interface Requirements

Complete Model Characterization List for

Each Model Element

1

2

4

3Develop Requirements using Characterization List

Perform Hierarchal Architecture Modeling

Trace/Link Requirements to Model Element

Use Model Element (with linked requirements) to generate Requirements

Document

5

Out

put

Model-Based Systems

Engineering

6

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

7

B. Architecture Methodology (Physical)

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

Develop Boundary (Context) Diagram

The context diagram illustrates the physical elements outside the system.

System Boundaries and External InterfacesKnowing your system boundaries will guide the designer with interfaces to external systems.

8

P-IC-CTN-Cx Interface

P-IC-Cx-CTN Interface

P-IC-Cx-ISS Interface

P-IC-ISS-Cx Interface

P-IC-GPS-Cx Interface

P-IC-Cx-LPRP Interface

P-IC-LPRP-Cx Interface

P-IC-NOAA-Cx Interface

P-IC-Foreign-Cx Interface

P-IC-Cx-Foreign Interface

P-IC-Cx-ER Interface

P-IC-ER-Cx Interface

P-IC-Cx-AFSCN Interface

P-IC-AFSCN-Cx Interface

P-IC-SOMD-Cx Interface

P-IC-Cx-SOMD Interface

P-IC-USSTRATCOM-Cx Interface

P-IC-DDMS-Cx Interface

P-IC-Cx-DDMS Interface

P-IC-Constellation Architecture

P-IC-C&T Network

P-IC-GPS

P-IC-LPRP

P-IC-ISS

P-IC-NOAA

P-IC-SOMD

P-IC-Eastern Range

P-IC-USSTRATCOM

P-IC-DDMS

P-IC-AFSCN

P-IC-Foreign Government Landing and Recovery

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

Decompose Physical Elements

Decompose the physical elements.Include decomposition of external and internal interfaces.

9

P-IC-Cx-ISS Interface

P-IC-ISS-Cx Interface

P-IC-GPS-Cx Interface

P-IC-C Inter

P-IC-LPRP-Cx Interface

P-IC-Cx-Foreign Interface

P-IC-Cx-ER Interface

P-IC-ER-Cx Interface

P-IC-Cx-AFSCN Interface

P-IC-AFSCN-Cx Interface

P-IC-Orion-Ares Interface

P-IC-Ares-Orion Interface

P-IC-Orion-MS Interface

P-IC-MS-Orion Interface

P-IC-Ares-MS Interface

P-IC-MS-Ares Interface

P-IC-GS Inter

P-IC-GS-Ares Interface

P-IC-Orion-LIDS/APAS Adapter Interface

P-IC-LIDS/APAS Adapter-Orion

Interface

P-IC-Orion-PEPC Interface

P-IC-GPS

P-IC-LPRP

P-IC-Orion

P-IC-Mission

Launch Vehicle

P-IC-LIDS/APAS Adapter

System of System (SoS) Level

Launch Vehicle System Level

Context Diagram

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

10

C. Architecture Methodology (Operational & Functional)

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

(1) Identify Lifecycle Phase

The ‘System Lifecycle Phase’ may be modeled as a Process Flow Diagram (PFD).

11

SoS Level II System Level III Element Level IVIntegrate Operational TestTrainOperate

IntegrateTransportSystem TestTrain

ManufactureTransportComponent TestSustainDispose

Applicable toSoS Level

Applicable toSystem Level

Applicable toElement Level

Input Input

Input Input

AND AND

Integrate- SoS

1

OperationalTest

2

Train -SoS

3

Operate

*4*

Integrate- System

5

Transport- System

6

SystemTest

7

Train -System

8

Manufacture

9

Transport- Element

10

ComponentTest

11

Sustain

12

Dispose

13

Each Lifecycle phase will have a unique set of missions, stakeholders,

interfaces and constraints

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y(2) Identify DRM Mission Phase

(ConOps)The ‘DRM Mission Phase (ConOps)’ PFD is decomposed from the ‘DRM Mission Phase’

12

DRM-1

DRM-2

DRM-3

DRM-4

OR ORISS

1

LunarSurface

*2*

LunarHabitat

3

Mars

4

‘Operate’ Lifecycle Phase

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

(3) Develop Mission Sub-Phases

The ‘Mission Sub-Phase’ PFD is decomposed from the ‘DRM Mission Phase (ConOps)’.

13

Pre-Launch

*1*

Launch

2

Ascent

3

Low EarthOrbit(LEO)

4

TransLunarOrbit

5

Low LunarOrbit

6

LunarDescent

7

LunarSurface

Operations

8

LunarAscent

9

TransEarthOrbit

10

EarthDescent

11

EarthLanding

12

Post-Landing

13

‘Lunar Surface’ Mission Phase

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y(4) Model Nominal & Off-Nominal Activities (Operational Scenarios)

The ‘Nominal & Off-Nominal Activities (Operational Scenarios)’ PFD is decomposed from the ‘Mission Sub-Phase’.

14

Lunar Golf

LS Explore Operations

Scenario 1

Scenario 2

Scenario 3 LS Mining Operations

OR OR

‘Lunar Surface Operations’

Activities modeled for the Scenario

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y(5) Develop Mission Operation for

Each Scenario

The ‘Mission Operations for Each Scenario’ PFD is decomposed from the ‘Nominal & Off-Nominal Activities (Operational Scenarios)’

15

‘Lunar Golf’

Video Feed

CxP

ElementarySchools

AND ANDExit Habitat

Transition to Driving Range

Hit Golf Balls

Return to Habitat

Enter Habitat

StartVideo Feed

Stop Video Feed

Define a Swim Lane (row) for each

system component.

Define Operations for that system

component.

Define the Data Flows (interface

messages) for that system component.

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

Mission Operation Swim Lanes

The Swim Lanes (‘CxP’ and ‘Elementary Schools’) represent the internal or external elements of the Physical Architecture that the PFD operations are associated to for the current level (SoS Level).

16

Vid

CxP

ElementarySchools

AND Exit Habitat

Transition to Driving Range

StartVideo Feed

Crew Equipment

CxP System(s)Elem. Schools(External Sys.) Current Level

Next LevelHabitat EVA RoverCTN

(Comm) CrewMission Systems

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

(6) Decompose Mission Operation

The ‘Mission Operation’ PFD is decomposed from the ‘Mission Operations for Each Scenario’.

17

AND AND

Rover

Crew Enter Rover

Rover Power On

Turn Power On

Drive to Golf Range

Maneuver Rover

Rover Power Off

Rover On Command

Turn Power Off Exit Rover

ManeuverCommands

Rover Off Command

‘Transition to Driving Range’

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

yDecomposed Mission Operation Swim

LanesThe Swim Lanes (‘Crew’ and ‘Rover’) represent the internal and external elements of the Physical Architecture that the PFD operations are associated to at the current level (System Level).

18

Crew Equipment

CxP System(s)Elem. Schools(External Sys.)

Current LevelHabitat EVA RoverCTN

(Comm) CrewMission Systems

AND

Rover

Crew Enter Rover

R C

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y(7) Develop Top-Level System

Functions

The ‘Top-Level System Functions’ enhanced Functional Flow Block Diagram (eFFBD) is decomposed from the ‘Mission Operation’ PFD.

19

ANDDisengage

Brake System

Accelerate Vehicle

Change Vehicle Direction

AND OREngage Brake

SystemOR II

Until Destination Reached

Release Brake

Apply Brake

MoveAccelerator

Pedal

Decelerate Vehicle

MoveBrake Pedal

MoveSteeringSystem

Rover Distance

(Odometer)

‘Maneuver Rover’

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

(8) Decompose Functions

The ‘Decompose Functions” FFBD is decomposed from the Top-Level System Functions’ FFBD.

20

Change Motor RPM

MoveAccelerator

Pedal

Rover Distance

(Odometer)

Translate Rotation to

Wheels

‘Accelerate Vehicle’

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

21

D. Use Models to Help Derive Requirements

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

yArchitecture Methodology

Requirement TypesVarious types of requirements are represented in this architecture methodology.

22

Model No.

Architecture Modeling Activity Requirement Types

System of System (SoS) Level1. Identify Lifecycle Phase Operational/Capability Requirements

External Interface Requirements2. Identify DRM Mission Phase (ConOps)

3. Develop Mission Sub-Phases4. Model Nominal & Off-Nominal

Activities (Operational Scenarios)5. Develop Mission Operation for Each

ScenarioSystem Level

6. Decompose Mission Operation Operational/Capability RequirementsFunctional/Performance RequirementsInternal Interface Requirements (System to System)

7. Develop Top-Level System Functions

Element Level

8. Decompose Functions Functional/Performance RequirementsExternal Interface RequirementsInternal Interface Requirements (Element to Element)

Physical Architecture (All Levels)

~ Define Physical Architecture Physical Interface Requirements

1

2

3

4

5

6

7

8

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

Characterization List

Complete a standard Characterization List for each of the modeled element which assists in developing associated system requirements.

23

For Operational ModelsDescription of each Operation

<Describe the operation for the model element.>

Inputs/Outputs<Identify the operational inputs and outputs for the model element.>

Desired Capability (level across scenarios) <Describe operation capability>

Pre Conditions<Describe condition needed to enter/activate operation.>

Post Conditions<Describe condition when operation complete.>

Operating Context (Environment)<Identify the environmental conditions that the modeled element sees during its operation. >

Off-Nominal Behavior and Recovery<Identify credible off-nominal behaviors or scenarios and suggested recovery operations to mitigate the behavior. Identify a worst case scenario and 2 to 3 lesser severe behaviors.>

For Functional ModelsDescription of each Function

<Describe the model element’s function.>

Inputs/Outputs<Identify the functional inputs and outputs for the model element.>

Desired Performance (level across scenarios) Describe the performance required for the function (rate, time, weight, etc.)>

Pre Conditions<Describe condition needed to enter/activate function.>

Post Conditions<Describe condition when function complete.>

Operating Context (Environment)<Identify the environmental conditions that the modeled element sees during its function. >

Off-Nominal Behavior and Recovery<Identify credible off-nominal behaviors or scenarios and suggested recovery operations to mitigate the behavior. Identify a worst case scenario and 2 to 3 lesser severe behaviors.>

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

(1) Derive Operational Requirements

Example - Derive Operational Requirement using Characterization List for ‘Transition to Driving Range’ operational model element.

24

No. Characterization Item Characterization Text Operational Requirement

1. Operation Description Transition two crew members and golf equipment between lunar habitat and lunar golf driving range.

Transition to Driving RangeLunar Rover shall safely secure two crew members and crew equipment for transit between lunar habitat and the lunar golf driving range with a TBD maximum travel distance and a TBD maximum continuous operation time.

2. Inputs ~

3. Outputs ~

4. Pre and Post Conditions Decision authority.

5. Operating Context (Environment)

24 hr weather predicted.

6. Desired Capability(level across scenarios)

TBD maximum travel distance.Safe travel speed of TBD mph.

7. Off-Nominal Behavior Rover fails to operate.

8. Off-Nominal Recovery Don’t not use rover; Attempt to repair rover; Contingency return to habitat (limit rover distance to safe EVA walk).

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

(2) Derive Performance Requirements

Example - Derived Performance Requirement using Characterization List for the ‘Accelerate Vehicle’ functional model element.

25

No. Characterization Item Characterization Text Performance Requirement

1. Function Description Able to change rover acceleration. Change Vehicle AccelerationLunar Rover acceleration changes shall be manually controlled by EVA crew so that associated crew member physical effort does not exceed human factors as defined in TBD document.

2. Inputs Move Accelerator Pedal

3. Outputs ~

4. Pre and Post Conditions Decision authority.

5. Operating Context (Environment)

24 hr weather predicted.

6. Desired Performance (level across scenarios)

TBD maximum rover acceleration.Any crew EVA manual control not to exceed human factors per TBD document.

7. Off-Nominal Behavior (1) Acceleration fails Off.(2) Acceleration fails On

8. Off-Nominal Recovery (1a) Don’t not use rover; (1b) Attempt to repair rover; (2a) Enable contingency acceleration override;(2b) Then purse contingency return to habitat (walk) (limit rover distance to safe EVA walk).

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

(3) Interface Requirements - Example

Identify the interface items in the architecture modelsUse the “Catcher-Pitcher-Ball” approach to develop the interface requirements for each interface.

26

Sample eFFBDFirst Stage Function X

Upper Stage Function Z

Upper Stage Function YH&S

External Interface

Interface Requirement

Set

‘Pitcher’ (Send Data)

‘Ball’ (Data Characteristics)

‘Catcher’ (Receive Data)

Example FS Provides H&S DataThe 1st Stage shall provide H&S data to the US in accordance with US / 1st Stage IRD 10.

10. H&S DataThe H&S message shall consist of Z data across interface 295.

US Receives H&S DataThe US shall receive H&S data from the US in and do something in accordance with US / 1st Stage IRD 10.

Description <Include Interface Requirement in the SRD for the first physical system specifying that data is being provided to the second physical system.>

<Provide the characteristics of the data being sent in the IRDbetween the two physical systems.>

<Include Interface Requirement in the SRD for the second physical system specifying that data is being received from the first physical system.>

The single Interface item in the sample eFFBD reflects a common set of Interface Requirements in the following three documents:

1) First Physical System SRD (Ex.: First Stage)2) Second Physical System SRD (Ex.: Upper Stage)3) Common Interface IRD

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

Functional Model ItemDisengage Brake SystemAccelerate VehicleDecelerate VehicleChange Vehicle DirectionEngage Brake System

Requirement ItemDisengage Brake SystemAccelerate VehicleDecelerate VehicleChange Vehicle DirectionEngage Brake System

Accelerate

Vehicle

Change Vehicle Direction

OR

MoveAccelerator

Pedal

Decelerate Vehicle

MoveBrake Pedal

MoveSteeringSystem

Trace Derived Requirements to Model Elements

Trace/link the derived requirements (operational, functional, interface) back to the associated modeled elements

Use the projects requirements management tool (Cradle, CORE, etc.) for linking.This linking activity close the loop for Model-Based Systems Engineering (MBSE).

27

‘Maneuver Rover’ Top-Level FFBD

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

28

E. Model-Based Output

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

yModel-Based Systems Engineering

(MBSE) OutputGenerate a resulting MBSE requirements document:

Where the SRD (and IRD) document headers are the actual model element names.Where the requirements text traced/linked to that model element are output under the header.

29

ModelsPFD & FFBD Model “Names”become Requirement Document “Section Headers”Diagrams (PFD, FFBD, etc.)

RequirementsRequirement “Text” under each header derived from modeling characterization list.

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

30

Questions?

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

31

Backup

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

32

Benefits of Models (Why?)

Provides Visual representation of system characteristics (easier to “see” what is going on).The primary means of communication with Stakeholders, Users, and Builders

Guiding and recording aggregation and decompositionof system functions, components, and solution characteristics.Maintenance of system integrity through coordination of design activities.Assisting design by providing templates and recording decisions.Bridges the gap between customers problem space and designers solution space.

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

33

Hierarchical Considerations in Modeling

Each level of the hierarchy follows the same basic process but with a Different Focus

The of the architect depends upon where you are in the hierarchy

System1

StakeholdersSystem TestTransportTrainIntegrate

Acquisition DecisionsLifecycle ConsiderationsTechnology OptionsLe

vel 3

Element 1.1

StakeholdersComponent TestManufactureSustainTransportDispose

Trade StudiesRisk MitigationsTechnology MaturityLe

vel 4

SoSStakeholders

Operational TestOperateTrainIntegrate

Mission ScenariosExternal InterfacesOperational NeedsSystem BoundariesLe

vel 2

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

34

A Side-Track into Breakdown Structures

Product Breakdown Structure

(PBS)

An exhaustive, hierarchical tree structure of components that make up a system, arranged in whole-part relationship.

Products

System Breakdown Structure

(SBS)

A hierarchical tree structure of PBS components and Implementing systems, arranged in whole-part relationship.

PBS + Other Systems

Work Breakdown Structure

(WBS)

A hierarchical tree structure used for defining and organizing the total scope of a project.

PBS + Services

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

35

The Boundary Diagram-Onion Model-

PBS

Comm

Crew

TestSystem

ManufactureSystem

TransportSystem

TrainingSystem

SustainSystem

?

OtherExt

PBS

= P

rodu

cts

SBS

= P

BS

+ O

ther

Sys

tem

sW

BS

= P

BS

+ S

ervi

ces

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

y

36

SoS Mission Phases System Mission Phases

Operate NA

SoS Mission Phases System Mission Phases

Operational TestIntegrateTrain

ManufactureSystem TestTransportSustain

Swim Lanes Using Onion Model

Onion Model used to help identify PFD Swim Lanes depending on Project Level and Mission Phase.

SoS

External

External

Swim Lanes

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

yOperation and Physical Element

Association (System Level)The table below illustrates the association of the System Level Operations to the applicable System Level Physical Element(s).

The “Crew” and “Rover” physical elements are involved in the ‘Transition to Drive Range’ operations, so they become the respective Swim Lanes in the associated Process Flow Diagram.

37

Operation Allocation to System Level

HabitatCrewRoverCrew EquipEVACTN (Comms)

Exit Habitat

Return To

HabitatEnter

Habitat

System Level Physical Element

Trans. to Driving Range

Hit Golf Balls

Swim Lanes used for the “Transition to Driving Range” operation

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

yTransition from Operational to

Functional ModelingThe model transition from “Operational” (using PFDs) to “Functional” (using FFBDs) may vary depending on the physical element involved.

38

Operational Operational Operational

Functional

Operational

Operational Operational Functional Functional

Functional Functional Functional Functional

Ground Systems Mission Systems Crew Module Launch System

Syst

emSu

bSys

Elem

SoS Level SoS Mission / Operational ModelSystem to Element Level (see table below) (see table below)

A r c

it e

c t

u r e

M

o d

e l

in g

M

e t

h o

d o

l o g

yDecompose Function Until Uniquely

Allocated to a Single Element

39

The decomposition should continue until the function can be allocated uniquely to a single physical element.

(Leaf Nodes) Represent functions that will be used to specify Element Requirements(System 3.7 allocations).

Represent interim steps in the functional analysis. They DO NOT have associated Element Requirements.

Ensure Performance and Constraintsare properly carried down to leaf functions.Define Element Interface needs and allocations.

System Function

7 sC1,C2,

C3

1 sC1

12 sC1,C3

4 sC1,C2

2 sC1

1 sC3

10 sC1,C3 2s

3 sC1,C2

1 sC2

3 sC3

4 sC1,C3

3 sC3

2 sC3 1 s

Performance20 sec

ConstraintsC1, C2, C3

Yellow Boxes

Gray Boxes

Deriving Element Functions Stop When Only Leaf Nodes specify requirements