Date post: | 20-Jun-2015 |
Category: |
Technology |
Upload: | nasapmc |
View: | 13,638 times |
Download: | 0 times |
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