Scaling API-first – The story of a global engineering organization
Jeff.robinson
1. MBSE ARCHITECTURE
MODELING METHODOLOGY
Project Management
Challenge 2010
Jeff Robinson
Special thanks to
Scott Lukens
Used with Permission
2. Agenda
A. Overview
Arcitecture Modeling Methodology
B. Architecture Methodology (Physical)
1. Context Diagram
2. Decompose Physical Elements
C. Architecture Methodology (Operational & Functional)
1. Architecture Modeling Activities (with examples)
D. Use Models to Help Derive Requirements
1. Architecture Methodology Requirement Types
2. Characterization List
3. Derive Operational and Performance Requirements
4. Interface Requirements
5. Trace Derived Requirements to Model Elements
E. Model-Based Output
2
4. Model-Based Systems Engineering
(MBSE)
Requirements Gathering & Functional Behavior Analysis System Architecture
Analysis
Arcitecture Modeling Methodology
Operational Analysis
• Identify Source Material, Operational • Operational Scenarios • System Structure (i.e., Hierarchy of
Context, Use Cases, Scenarios, • Integrated Behavior Models System Elements)
Information Exchange • Derive Functional / Performance • Interfaces between System
• Establish Initial Requirements Set Requirements Elements
• Establish Design Constraints • Define I/O • Allocate Functional Behavior and
• Capture Issues / Risks / Decisions • Define Effectiveness Measures Non-Functional Requirements
Requirements Model Functional Models System Architectures
R1
F3 F4 System of Systems
R1.1 R1.2
F1 F5
Trade
F2
R1.2.1
Issue
Equipment List
Advantages of MBSE over Document Centric Approach
Shows Complete full picture of Architecture/Stakeholder Problem.
Generates executable artifacts.
MBSE Allows requirements conformance and consistency checking to be
assessed and validated. Document
Approach Centric
Orchestrates understanding of a design in all phases of the
development lifecycle. Approach
4
5. Part 1 – Develop Hierarchical Architecture
Model
(1) Identify Life (5) Develop
Arcitecture Modeling Methodology
Cycle Phase Mission
Operation for
Each Scenario
(6) Decompose
Mission
(2) Identify DRM Operation
Mission Phase
(ConOps)
(7) Develop Top-
(3) Develop Level System
Mission Sub- Functions
phases
(4) Model Nominal (8) Decompose
& Off-Nominal Functions
Activities
(Operational
Scenarios)
5
6. Part 2 – Use Architecture Models to Help
Derive Requirements
Model Characterize Requirement(s)
Arcitecture Modeling Methodology
Complete Model Develop Requirements
Characterization List for using Characterization List 3
Each Model Element
2
Operational/ Capability
Requirements
External Interface
Perform Hierarchal Requirements
1
Architecture Modeling
Trace/Link
Requirements to
4
Model Element
Use Model Element (with
Output
5 linked requirements) to
generate Requirements Model-Based
Systems
Document Engineering
6
11. (1) Identify Lifecycle Phase
The ‘System Lifecycle Phase’ may be modeled
as a Process Flow Diagram (PFD).
Arcitecture Modeling Methodology
SoS Level II System Level III Element Level IV
Integrate Integrate Manufacture
Each Lifecycle phase will have a Operational Transport Transport
Test System Test Component Test
unique set of missions, stakeholders, Train Sustain
Train
interfaces and constraints Operate Dispose
Applicable to
Integrate Operational Train -
SoS Level - SoS Test SoS Operate
AND AND
*4*
1 2 3
Input Input
Applicable to
Integrate Transport System Train -
System Level - System - System Test System
5 6 7 8
Input Input
Applicable to
Transport Component
Element Level Manufacture Sustain Dispose
- Element Test
9 12 13
10 11
11
12. (2) Identify DRM Mission Phase
(ConOps)
The ‘DRM Mission Phase (ConOps)’ PFD is decomposed
from the ‘DRM Mission Phase’
Arcitecture Modeling Methodology
DRM-1 ISS
OR OR
1
Lunar
DRM-2
Surface
*2*
Lunar
DRM-3 Habitat
3
DRM-4 Mars
4
‘Operate’ Lifecycle Phase
12
14. (4) Model Nominal & Off-Nominal
Activities (Operational Scenarios)
The ‘Nominal & Off-Nominal Activities (Operational
Arcitecture Modeling Methodology
Scenarios)’ PFD is decomposed from the ‘Mission Sub-
Phase’.
Scenario 1 LS Explore
OR OR
Operations
Activities modeled
Scenario 2 for the Scenario
Lunar Golf
Scenario 3 LS Mining
Operations
‘Lunar Surface Operations’
14
15. (5) Develop Mission Operation for
Each Scenario
The ‘Mission Operations for Each Scenario’ PFD is
Arcitecture Modeling Methodology
decomposed from the ‘Nominal & Off-Nominal Activities
(Operational Scenarios)’
Define a Swim Lane
(row) for each
system component.
CxP Exit Transition to Hit Golf Return to Enter
AND AND
Habitat Driving Range Balls Habitat Habitat
Define Operations
for that system
component. Start Stop
Video Feed Video Feed
Elementary
Video Feed
Schools
Define the Data
Flows (interface ‘Lunar Golf’
messages) for that
system component.
15
16. Mission Operation Swim Lanes
The Swim Lanes (‘CxP’ and ‘Elementary Schools’) represent the
internal or external elements of the Physical Architecture that the PFD
Arcitecture Modeling Methodology
operations are associated to for the current level (SoS Level).
Elem. Schools
CxP System(s)
(External Sys.) Current Level
CTN Mission Crew
Habitat EVA Rover Crew
(Comm) Systems Equipment Next Level
CxP Exit Transition to
AND
Habitat Driving Range
Start
Video Feed
Elementary
Vid
Schools
16
17. (6) Decompose Mission Operation
The ‘Mission Operation’ PFD is
Arcitecture Modeling Methodology
decomposed from the ‘Mission
Operations for Each Scenario’.
Crew Enter Turn Power Drive to Golf Turn Power
AND Exit Rover AND
Rover On Range Off
Rover On Maneuver Rover Off
Command Commands Command
Rover Rover Power Maneuver Rover
On Rover Power Off
‘Transition to Driving Range’
17
18. Decomposed Mission Operation Swim
Lanes
The Swim Lanes (‘Crew’ and ‘Rover’) represent the internal and
external elements of the Physical Architecture that the PFD operations
Arcitecture Modeling Methodology
are associated to at the current level (System Level).
Elem. Schools
CxP System(s)
(External Sys.)
CTN Mission Crew
Habitat EVA Rover Crew
(Comm) Systems Equipment Current Level
Crew Enter
AND
Rover
R
C
Rover
18
19. (7) Develop Top-Level System
Functions
The ‘Top-Level System Functions’ enhanced Functional
Arcitecture Modeling Methodology
Flow Block Diagram (eFFBD) is decomposed from the
‘Mission Operation’ PFD.
Until Destination Reached
Disengage Engage
Accelerate
Brake I AND OR OR AND I Brake
Vehicle
System System
Rover Move
Distance Accelerator
Release Apply
(Odometer) Pedal
Brake Brake
Decelerate
Vehicle
Move
Brake Pedal
Change Vehicle
Direction
Move
Steering
System
‘Maneuver Rover’ 19
20. (8) Decompose Functions
The ‘Decompose Functions” FFBD is decomposed from
Arcitecture Modeling Methodology
the Top-Level System Functions’ FFBD.
Translate
Change
Rotation to
Motor RPM
Wheels
Move Rover
Accelerator Distance
Pedal (Odometer)
‘Accelerate Vehicle’
20
22. Architecture Methodology
Requirement Types
Various types of requirements are represented in this
architecture methodology.
Arcitecture Modeling Methodology
Mode Architecture Modeling
l No. Activity Requirement Types
System of System (SoS) Level
1. Identify Lifecycle Phase Operational/Capability Requirements
2. Identify DRM Mission Phase
External Interface Requirements
(ConOps)
3. Develop Mission Sub-Phases
4. Model Nominal & Off-Nominal
Activities (Operational Scenarios)
1 5 5. Develop Mission Operation for Each
Scenario
System Level
2 6 6. Decompose Mission Operation Operational/Capability Requirements
7. Develop Top-Level System Functions
Functional/Performance Requirements
3 7 Internal Interface Requirements (System to
System)
4 8 Element Level
8. Decompose Functions Functional/Performance Requirements
External Interface Requirements
Internal Interface Requirements (Element to
Element)
Physical Architecture (All Levels)
~ Define Physical Architecture Physical Interface Requirements
22
23. Characterization List
Complete a standard Characterization List for each of the modeled
element which assists in developing associated system requirements.
Arcitecture Modeling Methodology
For Operational Models For Functional Models
Description of each Operation Description of each Function
<Describe the operation for the model element.> <Describe the model element’s function.>
Inputs/Outputs Inputs/Outputs
<Identify the operational inputs and outputs for the <Identify the functional inputs and outputs for the
model element.> model element.>
Desired Capability (level across scenarios) Desired Performance (level across scenarios)
<Describe operation capability> Describe the performance required for the function
(rate, time, weight, etc.)>
Pre Conditions
<Describe condition needed to enter/activate Pre Conditions
operation.> <Describe condition needed to enter/activate
function.>
Post Conditions
<Describe condition when operation complete.> Post Conditions
<Describe condition when function complete.>
Operating Context (Environment)
<Identify the environmental conditions that the Operating Context (Environment)
modeled element sees during its operation. > <Identify the environmental conditions that the
modeled element sees during its function. >
Off-Nominal Behavior and Recovery
<Identify credible off-nominal behaviors or scenarios Off-Nominal Behavior and Recovery
and suggested recovery operations to mitigate the <Identify credible off-nominal behaviors or scenarios
behavior. Identify a worst case scenario and 2 to 3 and suggested recovery operations to mitigate the
lesser severe behaviors.> behavior. Identify a worst case scenario and 2 to 3
lesser severe behaviors.>
23
24. (1) Derive Operational Requirements
Example - Derive Operational Requirement using Characterization List
Arcitecture Modeling Methodology
for ‘Transition to Driving Range’ operational model element.
Operational
No. Characterization Item Characterization Text
Requirement
1. Operation Description Transition two crew members and Transition to Driving
golf equipment between lunar Range
habitat and lunar golf driving range. Lunar Rover shall safely
2. Inputs ~ secure two crew members
and crew equipment for
3. Outputs ~ transit between lunar
habitat and the lunar golf
4. Pre and Post Conditions Decision authority.
driving range with a TBD
5. Operating Context 24 hr weather predicted. maximum travel distance
(Environment) and a TBD maximum
Desired Capability(level TBD maximum travel distance. continuous operation time.
6.
across scenarios) 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).
24
25. (2) Derive Performance Requirements
Example - Derived Performance Requirement using Characterization
Arcitecture Modeling Methodology
List for the ‘Accelerate Vehicle’ functional model element.
Performance
No. Characterization Item Characterization Text
Requirement
1. Function Description Able to change rover acceleration. Change Vehicle
Acceleration
2. Inputs Move Accelerator Pedal
Lunar Rover acceleration
Outputs ~ changes shall be manually
3.
controlled by EVA crew so
4. Pre and Post Conditions Decision authority. that associated crew
member physical effort
5. Operating Context 24 hr weather predicted.
does not exceed human
(Environment)
factors as defined in TBD
6. Desired Performance (level TBD maximum rover acceleration. document.
across scenarios) 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).
25
26. (3) Interface Requirements - Example
Identify the interface items in the architecture models
Use the “Catcher-Pitcher-Ball” approach to develop the interface requirements
Arcitecture Modeling Methodology
for each interface.
Interface
‘Pitcher’ ‘Ball’ ‘Catcher’
Requirement
Set (Send Data) (Data Characteristics) (Receive Data)
Example FS Provides H&S Data 10. H&S Data US Receives H&S Data
The 1st Stage shall provide The H&S message shall The US shall receive H&S
H&S data to the US in consist of Z data across data from the US in and do
accordance with US / 1st interface 295. something in accordance with
Stage IRD 10. US / 1st Stage IRD 10.
Description <Include Interface <Provide the <Include Interface Requirement
Requirement in the SRD for characteristics of the data in the SRD for the second
the first physical system being sent in the IRD physical system specifying that
specifying that data is being between the two physical data is being received from the
provided to the second systems.> first physical system.>
physical system.>
The single Interface item in the sample eFFBD Sample eFFBD
reflects a common set of Interface First Stage Upper Stage
Function X Function Z
Requirements in the following three
documents:
1) First Physical System SRD (Ex.: First Stage) Upper Stage
H&S Function Y
2) Second Physical System SRD (Ex.: Upper Stage)
External Interface
3) Common Interface IRD
26
27. Trace Derived Requirements to Model
Elements
Trace/link the derived requirements (operational, functional, interface)
back to the associated modeled elements
Arcitecture Modeling Methodology
Use the projects requirements management tool (Cradle, CORE, etc.) for
linking.
This linking activity close the loop for Model-Based Systems Engineering
(MBSE).
Accelerate
OR
Vehicle
Move
Accelerator
Requirement Item Functional Model Item Pedal
Disengage Brake System Disengage Brake System
Decelerate
Accelerate Vehicle Accelerate Vehicle Vehicle
Decelerate Vehicle Decelerate Vehicle
Change Vehicle Direction Change Vehicle Direction Move
Engage Brake System Engage Brake System Brake Pedal
Change Vehicle
Direction
‘Maneuver Rover’ Top-Level FFBD Move
Steering
System
27
29. Model-Based Systems Engineering
(MBSE) Output
Generate a resulting MBSE
requirements document:
Arcitecture Modeling Methodology
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.
Models
PFD & FFBD Model “Names”
become Requirement Document
“Section Headers”
Diagrams (PFD, FFBD, etc.)
Requirements
Requirement “Text” under each
header derived from modeling
characterization list.
29
32. Benefits of Models (Why?)
Provides Visual representation of system characteristics
Arcitecture Modeling Methodology
(easier to “see” what is going on).
The primary means of communication with
Stakeholders, Users, and Builders
Guiding and recording aggregation and decomposition
of 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.
32
33. Hierarchical Considerations
in Modeling
The of the architect depends upon where you are in
the hierarchy
Arcitecture Modeling Methodology
Stakeholders Mission Scenarios
Level 2
Operational Test
SoS External Interfaces
Operate Operational Needs
Train
System Boundaries
Integrate
Stakeholders
Level 3
System Test Acquisition Decisions
System
Transport Lifecycle Considerations
1
Train Technology Options
Integrate
Stakeholders
Component Test Trade Studies
Level 4
Element
Manufacture 1.1 Risk Mitigations
Sustain Technology Maturity
Transport
Dispose
Each level of the hierarchy follows the same basic process but with a Different Focus
33
34. A Side-Track into Breakdown
Structures
Product System Work
Arcitecture Modeling Methodology
Breakdown Structure Breakdown Structure Breakdown Structure
(PBS) (SBS) (WBS)
An exhaustive, A hierarchical tree A hierarchical tree
hierarchical tree structure structure of PBS structure used for
of components that make components and defining and organizing
up a system, arranged in Implementing systems, the total scope of a
whole-part relationship. arranged in whole-part project.
relationship.
Products PBS + Other Systems PBS + Services
34
35. The Boundary Diagram
-Onion Model-
SBS = PBS + Other Systems WBS = PBS + Services
Arcitecture Modeling Methodology
Training
Transport
System
System
Crew
PBS
Comm Sustain
?
Manufacture System
System
PBS = Products
Test
System Other
Ext
35
36. Swim Lanes Using Onion Model
Onion Model used to help identify PFD Swim Lanes depending on
Project Level and Mission Phase.
Arcitecture Modeling Methodology
SoS Mission Phases System Mission Phases SoS Mission Phases System Mission Phases
NA Operational Test Manufacture
Operate System Test
Integrate Transport
Train Sustain
Swim Lanes
SoS
External
External
36
37. Operation and Physical Element
Association (System Level)
The table below illustrates the association of the System
Level Operations to the applicable System Level Physical
Arcitecture Modeling Methodology
Element(s).
Operation Allocation to System Level
System Level Trans. to Hit Return
Physical Exit Driving Golf To Enter
Element Habitat Range Balls Habitat Habitat
Habitat
Swim Lanes Crew
used for the Rover
“Transition to Crew Equip
Driving Range” EVA
operation CTN (Comms)
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
38. Transition from Operational to
Functional Modeling
The model transition from “Operational” (using PFDs) to
“Functional” (using FFBDs) may vary depending on the
Arcitecture Modeling Methodology
physical element involved.
SoS Level SoS Mission / Operational Model
System to Element Level (see table below) (see table below)
Ground Systems Mission Systems Crew Module Launch System
Operational Operational Operational Operational
System
Functional
Elem SubSys
Operational Operational Functional Functional
Functional Functional Functional Functional
38
39. Decompose Function Until Uniquely
Allocated to a Single Element
The decomposition should continue
Constraints System Performance until the function can be allocated
Arcitecture Modeling Methodology
Function
C1, C2, C3 20 sec uniquely to a single physical element.
Yellow Boxes (Leaf Nodes)
7s
1s 12 s Represent functions that will be used
C1,C2,
C1 C1,C3
C3 to specify Element Requirements
(System 3.7 allocations).
4s 2s 1s 10 s
Gray Boxes
2s Represent interim steps in the
C1,C2 C1 C3 C1,C3
functional analysis.
They DO NOT have associated
3s 1s 3s 4s 3s Element Requirements.
C1,C2 C2 C3 C1,C3 C3 Ensure Performance and Constraints
are properly carried down to leaf
functions.
2s
1s Define Element Interface needs and
C3
allocations.
Deriving Element Functions Stop When Only Leaf Nodes specify requirements
39
