Dr. Steve Dam will walk you through the process of using Innoslate’s modeling and simulation capabilities while applying a MBSE methodology. At its core, Innoslate is a full model-based systems engineering tool. Within Innoslate, system models are formalized and capable of simulation to derive cost, schedule, and performance data. Your webinar will cover: Functional modeling Functional modeling is at the heart of how Innoslate derives new requirements and ensures logical accuracy. Physical modeling We can describe synthesizing the physical model in Innoslate with eight different diagrams, including the Asset Diagram, Layer Diagram, Block Definition Diagram, and Internal Block Diagram. Executing a model Innoslate includes a ‘Discrete Event Simulator’ to verify functional diagram’s logic, calculate cost, compute time, and quantify performance. Relating Requirements to Diagrams Requirements traceability ensures that the lifecycle and origin of a requirement is fully tracked. Innoslate includes relationship matrices to represent traceability relationships between entities in tabular view. Requirements Generation After modeling the system, often an engineer will derive textual requirements from the models by hand. Innoslate includes an automatic facility that generates requirements documents in a standard format (as outlined in “The Engineering Design of Systems: Models and Methods“).

2. Asks Us Questions
2WEBINAR: USING INNOSLATE FOR MBSE

3. Meet Your Host
President and Founder of SPEC Innovations
Participated in the development of C4ISR and the DoDAF
Expert Systems Engineering Professionals Certificate
steven.dam@specinnovations.com
@stevenhdam
3WEBINAR: USING INNOSLATE FOR MBSE

4. Agenda
What Do We Mean by MBSE?
Why this Question?
History of Systems Engineering
What Do We Need that We Are Missing?
Why Isn’t SysML Enough?
How Will Technology Improvements Enable Better SE?
Why Do We Have to Wait 10 Years?
How is Innoslate the Future of MBSE
WEBINAR: USING INNOSLATE FOR MBSE 4

5. What Do We Mean by MBSE?
A model:
◦ represents reality
◦ By only “representing reality” it means that we are simplifying reality as it would take the Universe to model the Universe
completely
◦ “Essentially, all models are wrong, some models are useful” George Edward Pelham Box (1919-2013)
MBSE according to INCOSE:
◦ “Model-based systems engineering (MBSE) is the formalized application of modeling to support system
requirements, design, analysis, verification and validation, beginning in the conceptual design phase
and continuing throughout development and later life cycle phases.”
◦ From this definition, MBSE has been around a long time!
WEBINAR: USING INNOSLATE FOR MBSE 5
But what does this really mean to us?

6. What Do We Mean by MBSE?
The key to MBSE is “Concordance”
◦ the ability to represent a single entity such that data in one view, or level of abstraction, matches the
data in another view, or level of abstraction, when talking about the exact same thing
The new DoD Digital Engineering Strategy calls this the “single source of truth”
From this model, the goal is to generate all the products needed to design and document
systems throughout the lifecycle
Recently, many have pushed the Systems Modeling Language (SysML) as the basis for MBSE
But is SysML the “Future of Systems Engineering?”
6WEBINAR: USING INNOSLATE FOR MBSE

7. Why this Question?
In a Spring 2018 Systems Engineering Forum, held by The Aerospace Corporation, one
questioner stated,
◦ “SysML is the current systems engineering, but 10 years from now it’s likely to be something else.”
That begs the question, “What is the future of systems engineering?” and others …
◦ What do we need that we are missing?
◦ Why isn’t SysML enough?
◦ How will technology improvements enable better SE?
◦ Why do we have to wait 10 years?
◦ How can we predict the future?
It’s easy to predict the future when we have lived it so many times in the past!
7WEBINAR: USING INNOSLATE FOR MBSE

8. History of Systems Engineering
Some believe systems
engineering can be traced
back thousands of years
◦ Wonders of the world could
only have been designed and
built systematically
Slide from SYST 505 Course at GMU by Peggy Brouse, Ph.D.
8WEBINAR: USING INNOSLATE FOR MBSE

9. History of SE(continued)
Others trace it
back to the
“Machine Age”
◦ Clearly the
industrial
revolution and
the assembly
lines require
systems
thinking
Slide from SYST 505 Course at GMU by Peggy Brouse, Ph.D.
9WEBINAR: USING INNOSLATE FOR MBSE

10. History of SE(continued)
But by the “Space Age” systems
engineering as we know it was
clearly born
◦ Millions of parts, clearly “systems of
systems” thinking was required by
this time
Slide from SYST 505 Course at GMU by Peggy Brouse, Ph.D.
10WEBINAR: USING INNOSLATE FOR MBSE

11. History of SE(continued)
Today, complexity is going out of
sight
We no longer talk about Gigabytes
of information, its now Zettabytes
(1 x 1021 bytes)
How can we deal with this much
data?
Slide from “Using Analytics to Predict and to Change the Future” presentation by Dr. Kirk Borne, BAH
11WEBINAR: USING INNOSLATE FOR MBSE

12. How Have Our Languages Evolved Over the
Last 60 Years?
1960s – used flow charting techniques derived from software (SREM created for software and
systems engineering)
1970 –Data Flow Diagramming – heavily influenced by software development
1980s - IDEF, State Machine modeling and Computer-Aided Systems Engineering tools (e.g.,
RDD-100)
1990s – eFFBDs and Object-Oriented Analysis and Design/UML - derived from software
techniques
2000s – SysML: a profile on UML
2010s – Still SysML, but LML emerged derived from systems engineering techniques; LML
version 1.1 included an ontology so that systems engineering can be performed at the system
entity level, instead of at the diagram level
History of SE (continued)
Why do we always seem to be 10 years behind the software world?
12WEBINAR: USING INNOSLATE FOR MBSE

13. What Do We Need that We Are Missing?
Need methods to capture and visualize tremendous amounts of information
Massive storage and retrieval of information
Need not only all the technical readouts, but also the programmatic information
Capability to move data around easily, between applications
A language that enables decomposition and abstraction
◦ A systems engineering language, not a software engineering language
◦ A language that is simple so that systems engineering can easily use it
WEBINAR: USING INNOSLATE FOR MBSE 13
But I know you are saying SysML does all this right?

14. Why Isn’t SysML Enough?
Systems Modeling Language
was developed to extend the
software focused Unified
Modeling Language (UML) to
systems
Interest in UML peaked in
2004
Software developers have
moved on to Agile, which
requires functional
requirements
Both SysML and UML require
experts to create and interpret
Systems Engineering requires
communications with all
stakeholders
From Google Trends retrieved 11/17/2017
14WEBINAR: USING INNOSLATE FOR MBSE

15. If you must be an expert in SysML’s
lexicon and diagram specifications, who
are you communicating with?
WEBINAR: USING INNOSLATE FOR MBSE 15

16. Why Isn’t SysML Enough?
But it’s worse than just not being easy to understand
SysML is lacking many of the programmatic pieces of information: risk, issues, decisions,
schedule, cost, … as explicit diagrams or entities
The lack of an ontology has been noted and is in the process of being developed
But what if there was already a language that provided an ontology for SysML and filled in the
missing pieces?
There is: Lifecycle Modeling Language (LML). See it at www.lifecyclemodeling.org.
16WEBINAR: USING INNOSLATE FOR MBSE

17. How Will Technology Improvements Enable
Better SE?
Some emerging/available technologies of the future:
◦ Cloud computing (already here!)
◦ Artificial Intelligence (Natural Language Process is already here!)
◦ Graph Databases (already here!)
◦ Optical Computing (coming soon)
How can they help us?
◦ Cloud computing provides a means to collaborate worldwide today … SE tools need to take advantage
of this capability
◦ Artificial Intelligence can help us find design problems or potential problems early
◦ Graph Databases enable greater storage capacity
◦ Optical Computing will enable create speed of computations, thus allowing for higher fidelity modeling
and simulation
17WEBINAR: USING INNOSLATE FOR MBSE

18. Why Do We Have to Wait 10 Years?
We don’t!
As noted, many of these technologies exist today
The Lifecycle Modeling Language (LML) provides a starting point for your language
◦ It’s an open standard, free for use
◦ It’s designed to be the “80%” solution
◦ It’s a simple language that can be extended it to meet your particular needs
Innoslate® already uses cloud computing and AI (NLP) technologies and was designed to scale
Other tools are beginning to realize these capabilities and are migrating to the cloud
WEBINAR: USING INNOSLATE FOR MBSE 18
The Future of Systems Engineering is Here

19. How Is Innoslate the Future of SE?
Full Ontology includes risk, issues, decisions, schedule, cost
Automatic Traceability
Automatic Diagram and Document Creation from the data
Use of Cloud Computing technology
Artificial Intelligence
19WEBINAR: USING INNOSLATE FOR MBSE

20. Full Taxonomy (LML extended to include
SysML and V&V) …
• Action
• Test Case
• Artifact
• Asset
• Resource
• Port
• Characteristic
• Measure
• Connection
• Conduit
• Logical
• Cost
• Decision
• Equation
• Input/Output
• Location
• Physical, Orbital, Virtual
• Risk
• Statement
• Requirement
• Time
Entity classes
provide the
nouns to this
this language;
entities can
have attributes
associated with
them as well
(adjectives)
20WEBINAR: USING INNOSLATE FOR MBSE

21. … and Relationships to Complete the Ontology
Action Artifact
Asset
(Resource)
Characteristic
(Measure)
Connection
(Conduit,
Logical)
Cost Decision Input/Output
Location
(Orbital,
Physical,
Virtual)
Risk
Statement
(Requirement)
Time
Action
decomposed by*
related to*
references
(consumes)
performed by
(produces)
(seizes)
specified by - incurs
enables
results in
generates
receives
located at
causes
mitigates
resolves
(satisfies)
traced from
(verifies)
occurs
Artifact referenced by
decomposed by*
related to*
referenced by
referenced by
specified by
defines protocol for
referenced by
incurs
referenced by
enables
referenced by
results in
referenced by located at
causes
mitigates
referenced by
resolves
referenced by
(satisfies)
source of
traced from
(verifies)
occurs
Asset
(Resource)
(consumed by)
performs
(produced by)
(seized by)
references
decomposed by*
orbited by*
related to*
specified by connected by incurs
enables
made
responds to
results in
- located at
causes
mitigates
resolves
(satisfies)
traced from
(verifies)
occurs
Characteristic
(Measure)
specifies
references
specifies
specifies
decomposed by*
related to*
specified by*
specifies
incurs
specifies
enables
results in
specifies
specifies
located at
specifies
causes
mitigates
resolves
specifies
(satisfies)
spacifies
traced from
(verifies)
occurs
specifies
Connection
(Conduit,
Logical)
-
defined protocol by
references
connects to specified by
decomposed by*
joined by*
related to*
incurs
enables
results in
transfers located at
causes
mitigates
resolves
(satisfies)
traced from
(verifies)
occurs
Cost incurred by
incurred by
references
incurred by
incurred by
specified by
incurred by
decomposed by*
related to*
enables
incurred by
results in
incurred by located at
causes
incurred by
mitigates
resolves
incurred by
(satisfies)
traced from
(verifies)
occurs
Decision
enabled by
result of
enabled by
references
result of
enabled by
made by
responded by
result of
enabled by
result of
specified by
enabled by
result of
enabled by
incurs
result of
decomposed by*
related to*
enabled by
result of
located at
causes
enabled by
mitigated by
result of
resolves
alternative
enabled by
traced from
result of
date resolved by
decision due
occurs
Input/Output
generated by
received by
references - specified by transferred by incurs
enables
results in
decomposed by*
related to*
located at
causes
mitigates
resolves
(satisfies)
traced from
(verifies)
occurs
Location
(Orbital,
Physical,
Logical)
locates locates locates
locates
specified by
locates locates locates locates
decomposed by*
related to*
locates
mitigates
locates
(satisfies)
traced from
(verifies)
occurs
Risk
caused by
mitigated by
resolved by
caused by
mitigated by
references
resolved by
caused by
mitigated by
resolved by
caused by
mitigated by
resolved by
specified by
caused by
mitigated by
resolved by
caused by
incurs
mitigated by
resolved by
caused by
enables
mitigated by
results in
resolved by
caused by
mitigated by
resolved by
located at
mitigated by
caused by*
decomposed by*
related to*
resolved by*
caused by
mitigated by
resolved by
occurs
mitigated by
Statement
(Requirement)
(satisfied by)
traced to
(verified by)
references
(satisified by)
sourced by
traced to
(verified by)
(satisified by)
traced to
(verified by)
(satisified by)
specified by
traced to
(verified by)
(satisified by)
traced to
(verified by)
incurs
(satisified by)
traced to
(verified by)
alternative of
enables
traced to
results in
(satisified by)
traced to
(verified by)
located at
(satisfied by)
traced to
(verified by)
causes
mitigates
resolves
decomposed by*
traced to*
related to*
occurs
(satisified by)
(verified by)
Time occurred by occurred by occurred by
occurred by
specified by
occurred by occurred by
date resolves
decided by
occurred by
occurred by occurred by
occurred by
mitigates
occurred by
(satisfies)
(verifies)
decomposed by*
related to*
• decomposed
by/decomposes
• orbited by/orbits
• related
to/relates
• Relationships
provide the
verbs to this
language
• Relationships
can have
attributes
associated
with them as
well (adverbs)
21

22. Automatic Traceability
Relationships are defined for both
directions, thus leading to automatic
reverse traceability
Innoslate also provides “traceability
assist” which uses NLP technology to
identify potential connections
automatically
Impact analysis comes from the Spider
Diagram
Works with all classes and relationships, not just requirements!
22WEBINAR: USING INNOSLATE FOR MBSE

23. Ease of Use: View Auto-generation
SysML Requirements Diagram
Requirements View
Matrices
View generation ensures concordance!
23WEBINAR: USING INNOSLATE FOR MBSE

24. Functional Diagram Auto-generation
•Action Diagram
•Activity Diagram
•Use Case Diagram
•Sequence Diagram
•Hierarchy Diagram
•Risk Diagram
•Spider Diagram
•Timeline Diagram
•ICOM
•IDEFO
•N-squared
•Tree
•Etc..
24WEBINAR: USING INNOSLATE FOR MBSE

25. Physical Diagram Auto-generation
•Asset Diagram
•Block Definition Diagram
•Internal Block Definition Diagram
•Package Diagram
•State Machine Diagram
25WEBINAR: USING INNOSLATE FOR MBSE

26. Document Generation
Requirements View
Documents View
• Author all your documents from
within Innoslate
• Embed live diagrams from the
tool into the document
26WEBINAR: USING INNOSLATE FOR MBSE

27. Requirements Quality
Checker
Artificial Intelligence
We use Natural
Language Processing
(NLP) technology, a
branch of AI, to aid
the user in analysis of
their models
Intelligence View
Traceability Assistant
27WEBINAR: USING INNOSLATE FOR MBSE

28. Innoslate – The Cutting Edge of Systems
Engineering for the Lifecycle
We now have the other capabilities that many people ask for:
◦ Model-Based Reviews, Workflow, Fine-Grained Permissions (with Redaction!), cross project
relationships, notifications, dashboards, …
We will not stop here
◦ Integration with design engineering tools will enable the vision for digital engineering DoD has
expressed in its recent strategy document
Use a tool of the future, not the past!
28WEBINAR: USING INNOSLATE FOR MBSE

29. 10/31/2018
WEBINAR: USING INNOSLATE FOR MBSE 29
Live Demo

30. Questions and Answers
30
PLEASE USE THE PANEL ON THE RIGHT TO ASK QUESTIONS

31. Next Webinar
What?
Using Innoslate's Test Center for Integrated Lifecycle
Verification and Validation Planning and Execution
When?
Thursday, December 13th at 2:00pm ET
Where?
Go To Webinar
WEBINAR: USING INNOSLATE FOR MBSE 31

32. Thank you for Joining Us
Stay Connected!
571.485.7800
blog.Innoslate.com
innoslate.com
SPEC Innovations
Innoslate User Group
@Innoslate