Loyd Baker: MBSE - connecting the dots process with loyd baker

LOYD BAKER
Model-Based Systems Engineering (MBSE)
Connecting The Dots Process

The presenter,
Loyd Baker, is VP for Technology with 3SL Inc., with extensive
experience teaching automated MBSE methods to major US
corporations and government agencies such as NASA, FAA, and
DoE.
Provides training for Cradle (https://www.threesl.com) the systems
engineering tool selected by NASA as their primary requirements
management tool.
Past president of the Huntsville Chapter of International Council on
Systems Engineering (INCOSE)
NASA Silver Snoopy Award winner for support of the Apollo
missions, including Apollo 13.

Systems Engineers utilize a large number of different “pieces of information”
to design, develop, analysis, and validate a new system or modifications to
an existing system
Examples of the ‘pieces of information’:
• Stakeholder Needs
• Use Cases
• Operational Scenarios
• Stakeholder Requirements
• System Requirements
• Interfaces
• System Architectures
• Verification Objectives
• Test Cases
• etc
Pieces of information

Category Value
Picklist
Image
Binary Frame
Linked Items
Requirement
Statement
Each dot has specific kinds of ‘attributes/properties’ that capture details
such as the requirement statement, type of requirement, etc

Connect the dots together to tell a story, or describe an architecture

A Piece of Information by itself has limited value, but when associated
with one or more other pieces of information via relationships (i.e., cross
reference links), the information has more value to the project
relationship relationship
built from
satisfies
derived req
has test
plan
consist of
has result
verified by has test
Product
(PBS)
1
System
Element
2
System
Requirement
3
Stakeholder
Requirement
4
Test Plan
5
Test Case
6
Test
Result
7
Verification
Objective
10

• System engineers build models to better understand problems, develop
candidate solutions, and validate design decisions.
• Models are used to tell a story or describe a concept
• Models improve communication between team members, and with the
customer.
• Ask me about an actual experence on a DOE/SRS Summer Study
Some Concepts / Stories are best communicated by a Diagram (i.e.,
conceptual model)
Cradle eFFBD

The Problem … In the past, projects would create Documents and
Drawings using the “pieces of information” but failed to keep and
manage the “pieces of information and their connections”.
Problem:
When project information is spread
across multiple documents, the lack
of quick access and consistency
traceability can cause issues when
project data is examined.
Difficult to assess:
• Project Completeness
• Requirement Consistency
• Architecture Integration
• Change Impacts
• Verification
• Validation
• End-to-end traceability
=

Today’s Model-Based Systems Engineering (MBSE) Movement is
promoting Data-Model Centric processes rather than the traditional
Document Centric processes.
Document Centric (past) Model-Based Centric (future)
Reference
DocumentReference
Document
System
Performance
Requirement
Performance
Requirement
Constraining
RequirementConstraining
Requirement
Cradle
ISSUE
Verification
SBS
Trade Study
Mission 1
Mission 2
Pre-Launch Launch On-orbit
Operation Scenario #3Pre-Launch Launch On-orbit
Operational Scenario #1
-Point
Camera
Take
picture
Store
picture
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Analysis
Reference
DocumentReference
Document
System
Performance
Requirement
Performance
Requirement
Constraining
Requirement
Cradle
ISSUE
Verification
SBS
Trade Study
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Analysis
Reference
DocumentReference
Document
System
Performance
Requirement
Performance
Requirement
C
R
Cradle
ISSUE
Verificat
SBS
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Analysis
Reference
DocumentReference
Document
System
Performance
Requirement
Performance
Requirement
C
R
Cradle
ISSUE
Verificat
SBS
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Analysis
Project Information Repository
maintained and possibility
delivered to the customer
The Project’s Systems Engineering Processes identify the data to be captured.

Select the MBSE Process to be used on your project by studying existing
documented processes
Technical Management Processes
• Decision Analysis
• Technical Planning
• Technical Assessment
• Requirements Management
• Architecture Management
• Risk Management
• Configuration Management
• Technical Data Management
• Interface Management
• Traceability Management
Technical Processes
• Requirements Development
• Logical Architecture
• Physical Architecture
• Design Solution
• Implementation
• Integration
• Verification
• Validation
• Transition

Based on your projects SE process, and project deliverables, define the
set of “dots” and their “connections” to be captured for your project. An
example database structure for a large NASA project is as follows.

1. “Foundational Concepts for Model Driven System Design,” white paper, INCOSE Model
Driven System Design Interest Group, International Council on Systems Engineering,
Jul. 15, 2000, by Loyd Baker, Paul Clemente, Bob Cohen, Larry Permenter, Byron
Purves, and Pete Salmon
2. Engineering Complex Systems with Models and Objects, by David W. Oliver, Timothy
P. Kelliher, and James G. Keegan
3. Streamlining Requirements Development through Model-based Systems Engineering,
by Robert Bayt, Ann Christian, Philip Nerren, and Rich DeLoof, NASA PM Challenge
2010
4. A Practical Guide to SysML, by Sanford Friedenthal, Alan Moore, and Rick Steiner
5. SysML Distilled, A Brief Guide To The Systems Modeling Language, by Lenny Delligatti
6. Requirements Definition and Management Using Cradle, by Loyd Baker, 2014,
https://www.threesl.com/pages/news/webletter-November14/REQ-Cradle-white-paper-
v8-1.pdf
Model-Based Systems Engineering References

Features Model-Based System Engineering Document Centered System
Design
Information Repository Models (Data & Diagrams) Documents
Reviews (SDR, PDR,
CDR)
By interrogating data & diagrams
(automated)
Read & interpret text then compare
Verification Implicit, incremental, automated, built
into the process
Human audit process
Communication Reproducible and consistent Answers may depend on readers
perspective
Validation Execute in different contexts (e.g.
customer’s context, end-users context,
etc)
Walk-through, reviews of paper
Traceability Integral Accuracy is labor intensive
•Expressiveness. The ability to express complex information in ways that are easily
understood. Models can achieve this expressive power through logical and physical
representations.
•Rigor. Compared with textual representations, executable models provide clear and
unambiguous definitions of behavior, capability or design.
Benefits of MBSE over document centric approaches accrue from two
essential features of a good model:
This information taken from reference 1 on the previous slide.

These PrimaryConcurrent/Iterative Activities Are Performed ForEach
Product/System Architecture DesignLayer
RequirementsDefinition
•Identify Stakeholders and Source Material
•Identify OperationalContext and Use cases
•OperationalScenarios, Info Exchange
•Establish StakeholderRequirements Set
•Establish MOEs, Design Constraints
•Capture Issues / Risks / Decisions
LogicalArchitecture
Analysis
•Develop System FunctionalModels
•Establish Traceability Between the Functions
and Requirements
•Define Logical I/O
•Allocate Functions to Architecture Entities
•Allocate Logical I/O to Interfaces
PhysicalArchitecture
Analysis
•Identify Architecture Structure (i.e.,
Hierarchy of Architecture Entities) and
PhysicalInterfaces
•Analyze Allocated Functions and I/O
•Allocate Constraining Requirements to
Architecture Entities
•Risk Assessment
•Compliance & Cost Assessment
•Design Verification & Validation
ProductEvaluation & DocumentGeneration
AnalysisResults
Specifications
•Configuration Management
•Test Planning
•Metrics
Functional Models Physical Architecture Views
Architecture Entity List
TechnicalRules,Standards,and Conventions
R1-1
R1 R2
R
Issue
Risk
F1 F5
F2 F3
F4
System of Systems
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Example Model-Based Systems Engineering Process

Apply Project Processes in Layers to Reduce Risk
Product 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 Definition Logical Architecture
Analysis
Physical Architecture
Analysis
Product
Evaluation
&
Document
Generation
Stakeholder
Needs
&
Source
Material
System
Functional
Models
Allocate
Functions
to System
and next
level
System
Interfaces
Design
Layer
“1” Design
Constraints
System
Structure
Operational
Context,
Use Cases,
Scenarios
System
Requirements
Physical Architecture
Analysis
Product
Evaluation
&
Document
Generation
Subsystem
Functional
Models
Subsystem
Interfaces
Design
Layer
“n” Subsystem
Structure
Requirements Definition
Subsystem
Requirements
Design
Constraints
Design
in Layers
System
Spec
Subsystem
Spec
Analyze
Allocated
Functions
&
Interfaces
Allocate
Functions
to
Subsystem
and next
level
Analyze
Allocated
Functions
&
Interfaces
Operational
Context,
Use Cases,
Scenarios
Logical Architecture
Analysis

Integrate Models & Requirements at each Level of the Architecture
Structure
Architecture Level 1 Models
Child Child Child
Requirement
Child Child Child
Requirement
Subsys X.3 Functional Model
System Breakdown Structure (SBS)
Architecture Level 2 Models
Parent
to child
traces
Parent
to child
traces
Horizontal Traceability
Vertical Traceability
Equip X.3
Equip X.3.1 Equip X.3.2 EquipX.3.3
Subsys X.3
Subsys X.3.1 Subsys X.3.2 SubsysX.3.3
SBS 1.3.1 SBS 1.3.2 SBS1.3.3
SBS 1
SBS1.1 SBS1.3SBS 1.2
Child Child Child
Requirement
Child Child Child
Requirement
System X Functional Model
Equip X
Equip X.1 Equip X.2 EquipX.3
System X
Subsys X.1 Subsys X.2 SubsysX.3
operation 1
Data
operation 2operation 1
DataData
operation 2
Operational Scenarios
operation 1
Data
operation 2operation 1
DataData
operation 2
Operational Scenarios

• The Modeling Notations used to support each process activity are identified. The
Cradle systems engineering support tool was used.
• Cradle did not support SysML at the time the project was going on so traditional
eFFBDs (enhanced Function Flow Block Diagrams) and PADs (Physical
Architecture Diagrams) were used. Cradle SysML support will be available in the
1QT 2016 allowing future projects to choose which notations best satisfy their
project needs.
• The project performed timeline analyses of the mission events using the Cradle-
Excel Timeline Analysis Tool.
• The actual NASA Models are not shown because they have not been approved
for public release.
MBSE Activities Used Successfully on one NASA Project are Presented
on the Following Slides

The MBSE activities were grouped into eight stages as shown in the following figure.
The Iterate nodes (circles with embedded I symbol inside) in the above process
diagram indicates that all stages between the two Iterate nodes are repeated for each
level in the system architecture hierarchy.
The Parallel nodes (circles with embedded AND symbol inside) indicate that the
stages (3, 4, and 5) between the two ‘AND’ nodes can be performed concurrently.
MBSE Activities Used Successfully on one NASA Project

Stage 1- Define Concept of Operations & Stakeholder Requirements
The activities in this stage are performed at project start-up to define the project scope, prepare
a concept of operations (ConOps), and then develop the set of stakeholder requirements and
publish in a Stakeholder Requirements Document (SRD).

Cradle Process Flow Diagrams (PFDs) are used to identify the operations needed to
accomplish a use case. These PFDs are known as Operational Scenario Diagrams. The
identified operations aid the user in deriving the necessary stakeholder requirements.
Stage 1- Define Concept of Operations & Stakeholder Requirements :2

The following example Cradle traceability table shows the Stakeholder Requirements derived
from Scenario Operations which describe a specific use case. Scenario Operations were
identified on the PFD shown on the previous slide.
Stage 1- Define Concept of Operations & Stakeholder Requirements :3

Stage 2 - Define System/System Element Context
The activities in this stage will develop a System Context Diagram for a primary system element
to identify all external entities that must interact with the system element and the required
external interfaces. These external interfaces must be identified prior to beginning stages 3
through 7.

Stage 3 - Define System Elements
The activities in this stage are for defining physical characteristics for the specified system
element and then derive the appropriate system requirements for that element, then break-down
the system element into its component parts (one level down the hierarchy), and identify a draft
set of physical characteristics for each subordinate element.
Primary “System Element” for
which Requirements are being
defined during current design
cycle
Always go one level deeper in
hierarchy and identify candidate
draft Child “System Elements”.
Next cycle each Child Element
becomes the primary and the
process is repeated.

A System Element’s Structure (its component parts one level down the hierarchy) are
identified in order to allocate functions and requirements to the component parts. This Cradle
diagram is also known as a Physical Architecture Diagram (PAD).
Stage 3 - Define System Elements :2

Stage 4 - Define Functional Behavior
Identify system functions and their inputs and outputs that satisfy the system element functional
requirements identified in the previous design cycle. These functions, when integrated together,
describe the desired behavior the system element must exhibit. In stage 5, the functions /
interfaces will be allocated to specific system elements (i.e., the things that must perform the
functions).
ANDFunction2
Function3
Function4
Data
Sub-Function
ofFunction4
Sub-Function
Of Function4
Data
Functional
System
Requirement
Functional
System
Requirement
Satisfy
Satisfy
Derived Req
Functional
System
Requirement
Satisfy

The Cradle enhanced Functional Flow Block Diagram (eFFBD) describes the desired behavior
the system element must exhibit. This diagram is also known as a Behavior Diagram. It is
used to define system functions from which Functional Requirements are derived.
Stage 4 - Define Functional Behavior :2

The following Cradle traceability table shows the Functional Requirements derived from the
system functional behavior described on the eFFBD shown on the previous slide.
Stage 4 - Define Functional Behavior :3

Stage 5 -Allocate Functions & Interfaces to System Elements
In this stage, the functions and I/O (identified in stage 4) are assigned to different system
elements and interfaces.
1. Functional allocation assigns desired behavior to the different system elements.
SystemElement SystemElement
System
INTERFACE
Derived
Nonfunctional System
Requirements
Derived
FunctionalSystem
Requirements
Derived
InterfaceSystem
Requirements
allocate
satisfy
satisfy
allocate
satisfy
Data
ANDFunction1 Function2
Function3
Function4
Data
satisfy

Stage 5 -Allocate Functions & Interfaces to System Elements :2
2. Based on the I/O produced and consumed by the functions being allocated to system
elements, candidate physical interfaces between the system elements are identified.
Derived
Requirements
Derived
Interface
Requirements

3. Because each allocated function and interface has traceability links to requirements being
satisfied, those requirements are indirectly being allocated to the system elements and
interfaces.
SystemElement SystemElement
System
INTERFACE
Derived
Requirements
Derived
FunctionalSystem
Requirements
Derived
InterfaceSystem
Requirements
allocate
satisfy
satisfy
allocate
satisfy
Data
ANDFunction1 Function2
Function3
Function4
Data
satisfy

The following Cradle traceability table shows the Functional and Non-Functional Requirements
allocated to the System Elements. (i.e., Equipment items in Cradle).

The following Cradle traceability table shows the Interface Requirements allocated to the Data
Definition (DD) interfaces identified on the Physical Architecture Diagram (PAD).
Stage 5 - Allocate Functions & Interfaces to System Elements :5

Stage 6 - System RequirementsAnalysis & Verification Planning
The system requirements derived in stages 3-5 are analyzed for clarity, completeness,
consistency, traceability to the stakeholder or system requirements baselined at the end of the
previous design cycle. Also, verification and test planning activities should be performed for the
newly created system requirements and appropriate traceability established..
built from
satisfies
derived req
has test
plan
consist of
has result
verified by
identifies
has test
Product
(PBS)
1
System
Element
2
System
Requirement
3
Stakeholder
Requirement
4
Test Plan
5
Test Case
6
Test
Result
7
Use Case
(Specification)
8
Verification
Objective
10

Assign Times (durations and optionally fixed start times) to the Functions and dynamically
execute them. To verify functions are executed in the desired time ordered sequence.
Simulation Times (Days / HH : MM : SS)
Perform TimeLine Analysis of Specified Behavior (i.e., Functional Models)

Download the Cradle functional models into Excel for Timeline Analysis

Timeline Setup Sheet Lists the Functions and Times downloaded from Cradle
These values (Fixed Start Time, Duration, and Fixed End
Time) are read from the function specifications in the Cradle
database associated with the exported models
This Decomposition flag is read from the
Diagram’s Group attribute in the Cradle
database. It is set to 1 in the database to
indicate that the function’s decomposition is to
be included in the analysis

Results of the simulation are displayed on the “Timeline Results Sheet”
Computed Simulation Times (function start and end times)
Verify functions executed in the desired order with correct I/O

Stage 7 - Generate Documentation for System/System Elements
Whether for review and approval, reference documentation, training or other uses; producing
documentation is a vital and often time consuming activity for a project. Cradle’s ability to
produce reports and Word documents in an automated and customized fashion supports the
project’s documentation needs while saving time and ensuring consistency with documentation
formats and standards.
Master Test Plan
System
Requirements
Document (SRD)
System Architecture
Description
Reference
DocumentReference
Document
System
Performance
Requirement
Performance
Requirement
Constraining
Requirement
Cradle
ISSUE
Verification
SBS
Trade Study
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Analysis
Reference
DocumentReference
Document
System
Performance
Requirement
Performance
Requirement
Constraining
Requirement
Cradle
ISSUE
Verification
SBS
Trade Study
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Analysis
Reference
DocumentReference
Document
System
Performance
Requirement
Performance
Requirement
Constraining
Requirement
Cradle
ISSUE
Verification
SBS
Trade Study
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Analysis
Reference
DocumentReference
Document
System
Performance
Requirement
Performance
Requirement
Constraining
Requirement
Cradle
ISSUE
Verification
SBS
Trade Study
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Mission 1
Mission 2
-Point
Camera
Take
picture
Store
picture
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
Data
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Func 1 Func 2
Func 3
Func 4
DataData
Analysis
Cradle Information Repository

Stage 8 – System Verification & Validation (V&V)Traceability
Capture the status of each V&V activity in the database with traceability back to the impacted
requirement and operational scenarios.
• Verification Traceability. The purpose of the Verification Process is to confirm that the specified
design requirements (i.e., System Requirements) are fulfilled by the system.
• Validation Traceability. The purpose of the Validation Process is to provide objective evidence
that the services provided by a system when in use comply with stakeholders’ requirements,
achieving its intended use in its intended operational environment.

Is Model Based Systems Engineering (MBSE) something new? No, MBSE
methods and techniques have been individually practiced by many good
engineers and analyst over the years. The MBSE process presented in this
presentation was about “Connecting the Dots”.
The problem has been that project management has been obsessed with
‘deliverable documents’ rather than delivering an engineering data-model that
can be used to support analyses, end-to-end traceability, and automatically
produce the deliverable documents from the data-model.
• The engineering data-model usually consists of entities, attributes,
relationships, and diagrams that specify the system architecture.
• Remember a diagram (graphical model) is worth a thousand words. These
diagrams aid in communicating ideas/concepts among project personnel and
the customer.
• What is new is the SysML modeling language. It should help with
communication issues by having a common way to describe system
architectures.
Please contact me at loyd.baker@threesl.com to discuss MBSE processes
In Summary

Loyd Baker: MBSE - connecting the dots process with loyd baker

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Loyd Baker: MBSE - connecting the dots process with loyd baker

Similar to Loyd Baker: MBSE - connecting the dots process with loyd baker (20)

More from EnergyTech2015

More from EnergyTech2015 (10)

Recently uploaded

Recently uploaded (20)

Loyd Baker: MBSE - connecting the dots process with loyd baker