Getting Started With MBSE

1
Proprietary of SPEC Innovations® June 14, 2023 Lilleigh Stevie

Ask Us Your Questions
2
-Ask us your questions using the panel
on the right.
-This presentation is being recorded
and will be made available to you on
our website and through email.
-Contact us after the webinar through
● support@Innoslate.com
● Call 571.485.7800
● LinkedIn: “Innoslate Users and
Systems Engineers” Group
● Twitter: @specinnovations

Meet Your Host
• Systems Engineer at SPEC
Innovations
• GMU Systems Engineering
Master’s Program Alumna
• Lilleigh.stevie@specinnovations.com
3

Agenda
• Where are you in the lifecycle?
• Case #1: Top-Down
• Case #2: Bottom-Up
• Case #3: Middle-Out
• Combine all three?
• Where do I start with Innoslate?
4

Where are you in the lifecycle?
5
What do we mean by “top-down,” “bottom-up,” and “middle-out?”
• Where you start your MBSE project depends
on what stage you are in the lifecycle
• If you have a great requirements document,
you can start with the classic “top-down”
approach (Case #1)
• If you have a legacy system you want to
replace or you are just documenting a
system, bottom-up works great (Case #2)
• Early in the process “concept” or architecture
will likely have very little information to start
except for policies and procedures, middle-
out is the way to go (Case #3)

The Systems Engineering Process
• Classically, systems engineering
was depicted with this simple
diagram (circa 1980-2010)
• It was from an old DoD draft
standard, MIL-STD-499B, and
later, EIA-632
• It’s a little unclear why it was
dropped for a listing of systems
engineering functions (IEEE
15288)
• But it’s still very useful for
conducting systems engineering
6
Requirements
Analysis
Functional Analysis
and Allocation
Synthesis
System Analysis and
Control
Best Use:
Architecture
Development
(To-Be)
Best Use:
“Classical SE”
Best Use: Reverse
Engineering (As-Is)
Adapted from EIA-632
IEEE 15288 processes
Let’s look at each of our cases.

Case #1: Top-Down
• In “Top-Down,” we start with requirements
documents of some form
• Ideally, someone has performed good
systems engineering to develop these
requirements, but often the first set of
requirements are “user needs,” or perhaps
really “user wishes”
• You may even be at the point where you have
a component specification (box level)
• In this case as the previous diagram shows,
we would begin with a requirements analysis
7
The Requirements Hierarchy
User Needs
Conceptual Requirements
System Requirements
Application/Component
Specifications

Begin with Requirements Analysis Process
• Requirements analysis is a
fundamental part of systems
engineering
• The process we use is shown
• In the IEEE 15288 parlance,
requirements analysis covers
both stakeholder
requirements definition and
requirements analysis
processes
8
Source
Documents
External
Interface
Database
User Needs
Decompose Statements
Critical Issue?
Statement
Verifiable?
Determine Options and
Perform Trade Studies
See System
Analysis and
Control for details
Resolve Issues with
Customer
YES
NO
Coordinate Changes to
Make Statement Verifiable
NO
Review Statements and
Risks with Customer
Update Knowledgebase
YES
Identify Risks and Plan
Mitigation
Updated
Requirements
Traceability Matrix
Preliminary Test
Requirements
Standards
Selected
Change
Requests
SE
Knowledgebase
Trace Requirements to
Actions/Assets/Measures
So how do we do this with tools?

Innoslate’s Requirements Analysis Features
• Document/
Requirement Views
• NLP Quality
Checkers
• Traceability/Suspect
Assists
• Intelligence View
9

Case #2: Bottom-Up
• In bottom-up, we usually have
an existing system with fairly
well-defined subsystems and
components, but the
documentation may be out of
date
• Here we want to capture what
we can from the legacy
system and then abstract the
components to determine
their functions
10

Begin with Synthesis Process
• Here we synthesize a
model of the current
system
• Capture whatever you can
in physical diagrams
• For LML use Asset, Physical
I/O, ICD, and Layer
Diagrams
• For SysML use IBD and BDD
• Then create functional
models of the processes
then systems support
11
SE
Knowledgebase
Identify Component Assets
Optional
Assets?
See System Analysis
and Control for details
Select New Assets in
Coordination with Customer
YES
NO
Review Design and Risks
with Customer
Mitigation
Technology
Insertion
Recommend-
ations
Allocate Assets
Updated SE
Knowledgebase
Functional
Requirements
Document (FRD)
Design Diagrams
See Functional
Analysis and Control
for details
Transition Plan
Link to
programs
Programmatic
Roadmap
Traced
• Statements/Requirements
• VerificationRequirements
• Actions

• LML Diagrams:
• Asset
• Physical I/O
• ICD
• Layer
• SysML Diagrams:
• IBD
• BDD
Innoslate’s Physical Diagrams
12

Case #3: Middle-Out
• In middle-out, we usually have a
high-level concept or statement
of need, but they don’t want to
use the current systems, or they
want to use them in a very
different way
• You can usually find processes or
procedures as a starting point
• We model these processes using
functional analysis
13

Begin with Functional Analysis
• Use the Asset Diagram
to develop the context
diagram
• Develop a set of
scenarios based on the
processes
• Use SPEC’s approach to
build a scenario matrix
• Model all scenarios
using Action Diagrams
14
SE Knowledgebase
Develop/Revise Context
Diagram
See System Analysis and Control
for details
Review Model and Risks with
Customer
Mitigation
Updated SE
Knowledgebase
Develop Series of Scenarios
for Analysis
Create/Update System
Behavior Model
Analyze Behavior Model
Performance
Behavior Model
• Control Flow
• Data Flow (Activity Model)
• Performance Criteria
Allocate Actions to Assets
and Input/Outputs to Conduits
Updated SE
Knowledgebase
Detailed
Operational
Concept
Operational
Requirements
Document (ORD)
Traced
• Statements/Requirements
• Verification Requirements

Innoslate’s Functional Analysis Diagrams
• Context Diagram
• Asset Diagram
• Scenario Models
• Action Diagram
• Using simulators
to ensure that
the scenario
models work
• Add Ansys STK
for geospatial
constraints
15

Combine all three?
• You may find that you
need to do all three
approaches
simultaneously, as
different parts of your
system (which is often
a system of systems)
need different
approaches
• The SPEC approach
does all three
simultaneously
16
5. Develop the Operational Context Diagram
6. Develop Operational Scenarios
1. Capture and Analyze Related Artifacts
4. Capture Constraints (Environment/Drivers)
3. Identify Existing/Planned Systems
2. Identify Assumptions
7. Derive Functional Behavior
8. Derive Assets
9. Allocate Actions to Assets
10. Prepare Interface Diagrams
14. Provide Options
12. Perform Dynamic Analysis
11. Define Resources, Error Detection & Recovery
13. Develop Operational Demonstration Master Plan
16. Generate Operational and System Views, Graphics, Briefings and Reports
15. Conduct Trade-off Analyses
Requirements Analysis
Functional Analysis
Synthesis
System Analysis
and Control
Time

Where do I start with Innoslate?
• Sign up for Innoslate
• View Help Center
• Try out guided tour
• Reach out for help
(support included!)
• Get Training
• Workshop
recommended
17

18
Send in questions using the panel on the right.

Wednesday, July 19th, 2023 at 2:00 PM ET
Issue Tracking
Mark Your
Calendars
19

SPEC Innovations
@SPECInnovations
Innoslate Users Group
Innoslate.com/blog
571.485.7800
innoslate.com
20
Thank you!
Visit cloud.innoslate.com for a trial.

Getting Started With MBSE

Recommended

Recommended

More Related Content

Similar to Getting Started With MBSE

Similar to Getting Started With MBSE (20)

Recently uploaded

Recently uploaded (20)

Getting Started With MBSE