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

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

• 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

ISSUEVerification

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

ISSUEVerification

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

ISSUEVerification

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

ISSUEVerification

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

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 Primary Concurrent / Iterative Activities Are Performed For Each

Product/System Architecture Design Layer

Requirements Definition

•Identify Stakeholders and Source Material

•Identify Operational Context and Use cases

•Operational Scenarios, Info Exchange

•Establish Stakeholder Requirements Set

•Establish MOEs, Design Constraints

•Capture Issues / Risks / Decisions

Logical Architecture

Analysis•Develop System Functional Models

•Establish Traceability Between the Functions

and Requirements

•Define Logical I/O

•Allocate Functions to Architecture Entities

•Allocate Logical I/O to Interfaces

Physical Architecture

Analysis•Identify Architecture Structure (i.e.,

Hierarchy of Architecture Entities) and

Physical Interfaces

•Analyze Allocated Functions and I/O

•Allocate Constraining Requirements to

Architecture Entities

•Risk Assessment

•Compliance & Cost Assessment

•Design Verification & Validation

Product Evaluation & Document Generation

Analysis ResultsSpecifications

•Configuration Management

•Test Planning

•Metrics

Functional Models Physical Architecture Views

Architecture Entity List

Technical Rules, 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

ProductEvaluation

&Document Generation

StakeholderNeeds

&Source Material

SystemFunctional

Models

AllocateFunctions to System and next

level

SystemInterfaces

DesignLayer

“1” DesignConstraints

SystemStructure

OperationalContext,

Use Cases,Scenarios

SystemRequirements

Physical Architecture Analysis

ProductEvaluation

&Document Generation

SubsystemFunctional

Models

SubsystemInterfaces

DesignLayer

“n” SubsystemStructure

Requirements Definition

SubsystemRequirements

DesignConstraints

Design in Layers

System

Spec

Subsystem

Spec

AnalyzeAllocatedFunctions

& Interfaces

AllocateFunctions

to Subsystem

and nextlevel

AnalyzeAllocatedFunctions

& Interfaces

OperationalContext,

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 SBS 1.3.3

SBS 1

SBS 1.1 SBS 1.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).

ANDFunction 2

Function 3

Function 4

Data

Sub-Functionof Function 4

Sub-FunctionOf Function 4

Data

Functional System Requirement


Satisfy

Satisfy

Derived Req


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.

System Element System Element

System

INTERFACEDerived

Nonfunctional System Requirements

Derived Functional System

Requirements

Derived Interface System

Requirements

allocate

satisfy

satisfy

allocate

satisfyData

ANDFunction 1 Function 2

Function 3

Function 4

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 Nonfunctional System

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.

System Element System Element

System

INTERFACEDerived

Nonfunctional System Requirements

Derived Functional System

Requirements

Derived Interface System

Requirements

allocate

satisfy

satisfy

allocate

satisfyData

ANDFunction 1 Function 2

Function 3

Function 4

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 6 - System Requirements Analysis & 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 PlanSystem

Requirements

Document (SRD)

System Architecture

Description

Reference

DocumentReference

Document

System

Performance

Requirement

Performance

Requirement

Constraining


Requirement

Cradle

ISSUEVerification

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

ISSUEVerification

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

ISSUEVerification

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

ISSUEVerification

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 [email protected] to discuss MBSE processes

In Summary

mailto:[email protected]