What does MBSE stand for?

MBSE stands for Model-Based Systems Engineering, which is a methodology that focuses on using models for system engineering to improve productivity and reduce errors.

What is requirements engineering?

Requirements engineering involves the entire process of planning, developing, and managing requirements from needs or capabilities to specific system requirements.

How should companies start adopting MBSE?

They recommend starting with understanding your company's objectives and aligning MBSE activities with these goals.

How does requirements engineering integrate with system architecture?

Requirements engineering integrates with system architecture through tools that manage allocations and traceability among system components and requirements.

Who are the panelists in this webinar?

The panel consists of experts in aerospace, defense, system engineering, and simulation including Mark Dietrich, Melissa Cordova, Sanjay Kurana, and Jason Pyles.

When does acceptance testing occur?

Acceptance testing begins at the requirements vetting stage and continues through various development stages.

Does Dassault Systèmes offer MBSE training?

Yes, they offer training and certification programs through Dassault Systèmes University and partnerships with other organizations.

MBSE Live Panel Discussion

00:41:42

https://www.youtube.com/watch?v=37oFshvsmzM

Summary

TLDRThe webinar, hosted by Mark Dietrich along with panelists Melissa Cordova, Sanjay Kurana, and Jason Pyles, focuses on the importance and application of Model-Based Systems Engineering (MBSE) in aerospace and defense. The session discusses integration of MBSE and requirements engineering, touching on incremental approaches to adopting these methodologies. The concept of overlaying traceability on existing systems was emphasized, rather than replacing them. Panelists highlighted the use of comprehensive tools and methodologies that facilitate the development and management of system requirements at different abstraction levels. The seminar also touched upon MBSE’s applicability in manufacturing and services, and offered insights into training and certification opportunities provided by Dassault Systèmes for adopting MBSE effectively. Audience questions covering aspects like tool openness, system architecture integration, and Department of Defense's model acquisition strategy were addressed.

Takeaways

📌 MBSE is crucial for modern aerospace and defense engineering.
💡 Incremental approach recommended for adopting MBSE methodologies.
🛠️ Tools allow integration with existing systems enhancing traceability.
📊 Traceability is key, from planning to execution in system engineering.
📘 Comprehensive methodologies support detailed requirement management.
🏭 MBSE is also applicable in manufacturing processes.
📈 Importance of simulation processes in MBSE techniques.
🎓 Training and certification are available for MBSE adoption.
💬 Open discussion sessions to address specific industry needs.
🔗 Integration between MBSE tools and existing engineering frameworks.

Timeline

00:00:00 - 00:05:00
Introduction to the second webinar in a six-part series by Mark Dietrich focusing on MBSE. It follows a session on requirements engineering and addresses audience-submitted queries.
00:05:00 - 00:10:00
Overview of Dassault Systèmes’ contribution to the aerospace and defense sector, focusing on MBSE adoption. Mark offers to connect governmental attendees with appropriate contacts.
00:10:00 - 00:15:00
Outline of the six-part series being held biweekly, with an emphasis on interactivity in today's session. Future topics include system engineering practices and trace-based analysis.
00:15:00 - 00:20:00
Roundtable discussion kick-off, introducing panelists with extensive aerospace and defense expertise. Melissa Cordova highlights the shift from tactical to strategic discussions in digital transformation.
00:20:00 - 00:25:00
Sanjay Krurana discusses the incremental approach to systems engineering transformation, advocating for non-disruptive traceability overlay on existing applications.
00:25:00 - 00:30:00
Discussion on openness and integration with external system modeling tools. Dassault provides connectors for interoperability and introspection of SSML models in MBSE processes.
00:30:00 - 00:35:00
Jason Pyles explains the role of test management and Monte Carlo analysis on the 3D experience platform, highlighting end-to-end requirement validation and simulated trade studies.
00:35:00 - 00:41:42
Sanjay expounds on DoD's model-based acquisition strategy, emphasizing authoritative source of truth. Challenges in system integration and requirement traceability are discussed.

Mind Map

Frequently Asked Question

What does MBSE stand for?
MBSE stands for Model-Based Systems Engineering, which is a methodology that focuses on using models for system engineering to improve productivity and reduce errors.
What is requirements engineering?
Requirements engineering involves the entire process of planning, developing, and managing requirements from needs or capabilities to specific system requirements.
How should companies start adopting MBSE?
They recommend starting with understanding your company's objectives and aligning MBSE activities with these goals.
How does requirements engineering integrate with system architecture?
Requirements engineering integrates with system architecture through tools that manage allocations and traceability among system components and requirements.
Who are the panelists in this webinar?
The panel consists of experts in aerospace, defense, system engineering, and simulation including Mark Dietrich, Melissa Cordova, Sanjay Kurana, and Jason Pyles.
When does acceptance testing occur?
Acceptance testing begins at the requirements vetting stage and continues through various development stages.
Does Dassault Systèmes offer MBSE training?
Yes, they offer training and certification programs through Dassault Systèmes University and partnerships with other organizations.

View more video summaries

Get instant access to free YouTube video summaries powered by AI!

Subtitles

Auto Scroll:

00:00:08
hey good afternoon
00:00:10
and uh welcome to all of you in
00:00:11
attendance today for the second webinar
00:00:13
in our six part series
00:00:16
my name is mark dietrich and i'm a catia
00:00:18
senior sales expert here at daso
00:00:20
and i will be your host this afternoon
00:00:22
for the next hour
00:00:24
today's topic is mbse a live panel
00:00:27
discussion
00:00:29
uh this this session follows our webinar
00:00:32
that was held on tuesday
00:00:33
on requirements engineering and uh
00:00:36
there's
00:00:37
a few of you out there that had posed
00:00:39
some questions and we'll be
00:00:41
answering those questions that you
00:00:42
submitted during this session
00:00:45
next slide please
00:00:51
so this is a broad look at the
00:00:52
commercial aerospace and defense
00:00:54
organization here at the so systems
00:00:57
these individuals are backed by a large
00:00:59
team of both industry and technology
00:01:01
experts
00:01:02
that assist customers in defining and
00:01:04
adopting mbse
00:01:06
and requirements engineering methods and
00:01:07
processes
00:01:09
i've kind of filtered through some of
00:01:12
the attendees here and it looks like
00:01:13
several of you
00:01:14
have a dot gov or a dot mil email
00:01:17
address so
00:01:18
if if you're one of those people and you
00:01:21
are interested i can direct you to the
00:01:23
dsgs
00:01:24
sales team that supports us government
00:01:26
organizations if you're in need of
00:01:28
further follow-up
00:01:30
but i can be your point of contact as
00:01:32
well to
00:01:33
get you introduced to the appropriate
00:01:35
people if you're one of those
00:01:37
next slide please
00:01:41
so as mentioned earlier this is a six
00:01:44
part series
00:01:45
and it's being held on tuesdays and
00:01:47
thursdays at one pm eastern time
00:01:49
over the next three weeks today's
00:01:52
session is our round table discussion
00:01:54
and we will take questions and comments
00:01:56
from you
00:01:58
and we hope to make this a highly
00:01:59
interactive session
00:02:01
the last four sessions are more detailed
00:02:04
and technical
00:02:04
and cover important topics like system
00:02:06
engineering practices
00:02:08
modeling simulation and trace-based
00:02:12
analysis
00:02:13
next slide please
00:02:18
so again welcome to our roundtable
00:02:20
discussion today
00:02:22
uh this provides you as a participant
00:02:25
the chance to ask questions
00:02:27
on tuesday i invited the participants to
00:02:29
send over a few questions and we'll be
00:02:31
answering those and posing those to the
00:02:33
panel
00:02:34
i also invite you to send questions in
00:02:36
through um
00:02:38
the questions tab here on the side of
00:02:40
the of our session here in the webinar
00:02:43
go to webinar panel so we will fill
00:02:46
those as well
00:02:48
our panelists today all have extensive
00:02:50
knowledge in
00:02:51
aerospace and defense model-based system
00:02:54
engineering
00:02:55
and requirements engineering and i'll
00:02:57
ask each one of them to say hello and
00:02:59
offer any comments
00:03:00
so um melissa i'll let you uh go first
00:03:06
thank you mark as mark mentioned my name
00:03:08
is melissa cordova i
00:03:10
am a senior business consultant for the
00:03:12
aerospace and defense
00:03:14
industry my previous life
00:03:17
includes systems engineering model based
00:03:20
systems engineering applications
00:03:21
at former andy businesses
00:03:25
what i focus on specifically is
00:03:29
understanding how to derive and develop
00:03:32
a business justification
00:03:34
for anything digital transformation
00:03:36
systems engineering mdsc
00:03:39
specifics and i try to help elevate the
00:03:42
conversation
00:03:43
conversation from just a tactical um
00:03:46
conversation to a more strategic
00:03:47
conversation
00:03:49
i'm here to support any questions around
00:03:52
how to do just that
00:03:55
so uh so sanjay would you like to go
00:03:57
next please
00:03:59
sure thanks mark um hi there my name is
00:04:01
sanjay kurana you heard
00:04:04
me during the requirements engineering
00:04:06
webinar a few days ago
00:04:08
i lead the team of model-based system
00:04:10
engineering technical consultants here
00:04:12
for deso systems in north america
00:04:16
thanks mark yeah and uh and jason pyles
00:04:18
please
00:04:21
hi everyone my name is jason pyles uh i
00:04:24
represent the simula brand today on this
00:04:27
panel
00:04:28
which is the brand for realistic
00:04:29
simulation within design systems
00:04:33
and my team is focused on simulation
00:04:36
processes
00:04:38
data management and optimization
00:04:41
and trade studies uh within uh disso
00:04:44
systems more recently with
00:04:48
leveraging more simulation and higher
00:04:50
fidelity simulation in the mbsc
00:04:54
context
00:04:56
all righty so it looks like uh we
00:04:59
currently have no questions that have
00:05:00
been submitted through the uh
00:05:02
go to webinars uh panel currently so
00:05:05
let's start out
00:05:06
asking uh the panel of some of the
00:05:08
follow-up questions that we had from
00:05:10
tuesday
00:05:11
and um our first uh session was really
00:05:15
was covering requirements engineering so
00:05:18
we had a question that was supposed to
00:05:20
sanjay during that session so
00:05:22
the question was that thank you sanjay
00:05:25
quick question
00:05:26
how would you recommend reducing the
00:05:29
learning curve and i would assume
00:05:31
that meant for adopting you know
00:05:34
requirements engineering
00:05:35
as a as a methodology
00:05:39
right so um my response to that would be
00:05:43
that we typically when we look at
00:05:47
a transformation uh in terms of systems
00:05:50
engineering in terms of requirements
00:05:52
engineering
00:05:53
we typically adopt uh an incremental
00:05:56
approach
00:05:57
um and not a reprimandal place kind of
00:05:59
approach because you probably already
00:06:01
have
00:06:01
a set of applications it's widely
00:06:04
acknowledged that there's a lot of
00:06:06
heterogeneity when we are talking about
00:06:08
model based system engineering or the
00:06:10
overall conceptual engineering space and
00:06:13
our recommendation is typically to
00:06:16
understand the process as is and
00:06:20
the first step would be to start
00:06:22
building traceability or digital thread
00:06:24
between the existing applications on
00:06:27
and what is possible in terms of uh
00:06:30
the communication between those links of
00:06:33
the design
00:06:34
intent so that that would be the first
00:06:36
incremental step so
00:06:38
that is not ripping and replacing the
00:06:40
existing applications
00:06:41
but to build a traceability between the
00:06:44
existing
00:06:45
uh applications this is kind of an
00:06:47
overlay traceability on top of what you
00:06:50
may already be doing
00:06:51
um and this could be a traceability
00:06:53
between your
00:06:54
uh modeling applications uh where you're
00:06:58
modeling your system
00:06:59
um your behavior modeling applications
00:07:01
your software modeling your
00:07:04
detailed modeling applications and then
00:07:06
making sure that
00:07:07
as we build that traceability the
00:07:10
requirements
00:07:11
go hand in hand and they are allocated
00:07:14
based on those traceable links
00:07:17
so the traceability is not existing only
00:07:19
between the artifacts that are being
00:07:20
developed
00:07:21
at different levels of abstractions but
00:07:24
the traceability is also existing at
00:07:26
every level of abstraction as those
00:07:28
requirements are allocated
00:07:30
so in short again um
00:07:33
making sure that we we overlay
00:07:36
traceability on the
00:07:38
existing uh set of applications first
00:07:41
and then slowly
00:07:43
look at what needs to be replaced with
00:07:47
you know another tool or another
00:07:49
application
00:07:50
that would be my my recommendation in
00:07:52
terms of
00:07:54
an incremental approach that will be
00:07:56
easy to take on
00:07:58
okay thank you for that um this was
00:08:01
another question that was posed
00:08:03
um through uh follow-up um during the
00:08:06
during the session on tuesday
00:08:09
uh and i think it's this is more open i
00:08:11
think to anyone who would like to answer
00:08:13
how open is your system to accepting
00:08:16
content from
00:08:16
other system alternates
00:08:22
i can take that one again if you like
00:08:23
mark and then everyone else can add
00:08:27
so um once again um
00:08:30
our in terms of working with uh
00:08:33
any of the system modeling applications
00:08:37
we provide um up to 70 plus connectors
00:08:41
today
00:08:42
that connect with a wide variety of
00:08:46
both system and software modeling
00:08:48
applications
00:08:49
and you know this includes some of the
00:08:52
sml
00:08:53
tools as well what what we
00:08:57
when we talk about openness to be able
00:09:00
to
00:09:00
when i say using a connector our
00:09:03
platform has the capability to
00:09:05
introspect a sml model and it can
00:09:08
it could have been developed by any
00:09:10
application
00:09:12
we can introspect ssml model and we can
00:09:16
extract
00:09:16
the information in terms of um
00:09:20
all the specif uh you know the specific
00:09:24
uh blocks and ports and interfaces
00:09:27
everything we can
00:09:28
extract all that information and all the
00:09:30
traceability that exists
00:09:32
between that model and all the other
00:09:35
artifacts within the so that visibility
00:09:37
within the model and traceability
00:09:39
of that model with the outside world we
00:09:41
can extract that information
00:09:43
in our platform today and then build the
00:09:47
traceability from that
00:09:48
model to everything else it is not
00:09:51
connected to
00:09:52
so so again the answer in nutshell would
00:09:54
be that
00:09:55
we use connectors to system
00:09:58
other ssml tools and we can introspect
00:10:02
any sml model in our platform today
00:10:08
all right thank you any comments from
00:10:10
either of you
00:10:11
or just i think sanjay did a good job on
00:10:14
that one
00:10:15
so here's here's a very open question
00:10:19
um is envy is mbse just
00:10:22
used for developing products or can it
00:10:25
be used in manufacturing
00:10:27
or services
00:10:31
all right i'll i'll provide my take and
00:10:33
then i'll uh i'll have others
00:10:35
jump in as well um
00:10:38
one of the things that i said earlier
00:10:40
during the webinar also
00:10:42
is that to a certain extent
00:10:45
the essence of systems engineering
00:10:48
and henceforth the essence for
00:10:50
model-based systems engineering
00:10:52
is requirements everything that we are
00:10:55
trying to put together
00:10:57
in terms of process and the artifacts
00:11:00
and the decision making that is going on
00:11:02
in the entire process of model-based
00:11:04
systems engineering
00:11:06
is to get to the the the requirement
00:11:10
at the next level of abstraction so all
00:11:13
the modeling and simulation that we are
00:11:14
doing at one level of abstraction
00:11:16
feeds into the next level and we are
00:11:19
extracting requirements based on that
00:11:21
and we keep decomposing those
00:11:23
requirements
00:11:24
um this is very much this whole process
00:11:27
is very much
00:11:28
applicable from a manufacturing
00:11:30
perspective to
00:11:32
um whether you are um putting a plant or
00:11:36
something your you know you're trying to
00:11:38
do some kind of a factory simulation
00:11:40
um you know programming those robots or
00:11:44
even you know designing those robots
00:11:46
that are going to be used in the
00:11:47
manufacturing
00:11:49
um also in terms of uh
00:11:52
you know control systems how do you
00:11:55
manage the requirements for that how do
00:11:57
you actually do the simulation from a
00:11:59
control systems perspective
00:12:01
all of that is an integral part of
00:12:04
uh the model-based system engineering so
00:12:08
yes a model-based system engineering is
00:12:10
very heavy on the
00:12:12
the conceptual design side but
00:12:14
everything
00:12:15
that is created in terms of artifacts
00:12:18
is is heavily leveraged throughout the
00:12:22
system
00:12:22
development life cycle as well as the
00:12:25
manufacturing life cycle
00:12:27
all right thank you sanjay uh
00:12:31
here's a question about uh test
00:12:33
management and monte carlo trade study
00:12:36
analysis
00:12:37
is looks like the question is what test
00:12:40
management monte carlo trade study
00:12:41
analysis is available
00:12:43
uh on the platform
00:12:47
i can take this one i'll answer that in
00:12:50
two parts
00:12:51
uh first with test management we do have
00:12:55
two new roles on 3d experience platform
00:12:57
for managing uh and executing
00:13:01
tests the test planner role and the test
00:13:04
engineer role those are coming out
00:13:08
i think generally available next year um
00:13:11
they are being
00:13:12
used at a in a limited fashion this year
00:13:15
with some select
00:13:16
customers so if there's there is
00:13:19
interest uh
00:13:20
we can you know connect you with some
00:13:22
people to get uh information about those
00:13:24
roles
00:13:25
but they will be generally available
00:13:27
next year
00:13:28
uh and those roles on the platform are
00:13:31
uh designed specifically to
00:13:34
be allow you to define test cases
00:13:37
and test scripts and then allocate those
00:13:41
in stage test executions against a list
00:13:44
of requirements
00:13:46
and then you can um uh your validation
00:13:50
of those test cases whether it's a
00:13:52
a virtual test or a physical test uh and
00:13:55
the artifacts that come from those
00:13:57
um to the the test executions and then
00:14:00
monitor your coverage against the
00:14:02
requirements
00:14:03
uh so it's a pretty complete end and
00:14:06
package for
00:14:07
validating requirements um with
00:14:10
artifacts from
00:14:11
uh physical and virtual tests um so
00:14:14
that's our our test management
00:14:17
um part of the answer uh and then the
00:14:19
other
00:14:20
um the question in that in that uh
00:14:23
uh block was about monte carlo
00:14:27
on the platform we have a role called
00:14:30
multi-disciplinary optimization engineer
00:14:33
mdo and in that role on the platform
00:14:37
there is the ability to create process
00:14:40
workflows
00:14:42
that can link one simulation or many
00:14:44
simulations together
00:14:46
um whether those are simulations on the
00:14:48
platform or
00:14:49
simulations that are done with external
00:14:52
tools
00:14:53
and then being able to do trade studies
00:14:56
or monte carlo simulations or
00:14:58
optimizations
00:14:59
on those workflows so those are
00:15:02
parametric based
00:15:04
monte carlo optimization or trade
00:15:06
studies
00:15:07
we provide a variety of sampling
00:15:09
techniques
00:15:10
and distribution for
00:15:13
for your uncertainty variables uh in the
00:15:17
in the monte carlo capabilities so
00:15:20
that is all covered in the mdo role
00:15:23
the multi-disciplinary optimization
00:15:25
engineer role on the platform
00:15:28
okay thank you here's an interesting uh
00:15:33
i think a very open-ended question can
00:15:35
you provide
00:15:37
more insight into the dod's model
00:15:39
acquisition strategy
00:15:41
and how it will work in practice mark
00:15:44
could you please repeat the question i'm
00:15:45
sorry
00:15:46
sure they're asking if we can provide
00:15:49
more
00:15:49
insight into the dod's model based
00:15:52
acquisition strategy
00:15:54
and how it's how it's going to actually
00:15:56
work in practice
00:15:59
yes so so we do have
00:16:02
uh we do have many engagements
00:16:06
with the dod where we are actually
00:16:10
uh working on real-time scenarios from a
00:16:13
model based acquisition perspective
00:16:16
um in the the if i were to briefly
00:16:19
summarize the approach
00:16:22
that we are taking is that we we
00:16:25
take the we take a strategy in which we
00:16:30
are taking a model that has been
00:16:33
released by
00:16:35
and we have done quite a bit of mock
00:16:38
exercises around this so we have taken
00:16:40
um a sml model which which is defining
00:16:44
the overall systems of systems level
00:16:46
approach
00:16:47
um and using one of the architecture
00:16:49
frameworks
00:16:50
and then there's a capability
00:16:52
architecture there's a specific view
00:16:54
that is defined in there we are
00:16:56
able to take that we are able to extract
00:16:59
uh information such as the measures of
00:17:02
effectiveness or measures of suitability
00:17:04
or many other measures that could be
00:17:06
defined
00:17:08
and then the the beauty of uh
00:17:11
managing it in a model based acquisition
00:17:14
environment
00:17:14
is that as the
00:17:18
the the rfi or rfe that has been
00:17:20
released in a sml model
00:17:23
by the acquirer and as one of the prime
00:17:26
contractors is trying to put a
00:17:29
an architecture in place as a response
00:17:32
to that rfi
00:17:34
how the the intent the needs of
00:17:37
that have been laid out or the
00:17:39
capabilities that have been laid out
00:17:40
in that sml model uh that has been
00:17:44
provided by the acquirer
00:17:46
how that that intent creates the
00:17:50
appropriate
00:17:51
constraints and the appropriate uh
00:17:54
provides the appropriate level of
00:17:56
parameters for consideration
00:17:59
the downflow managing the downflow of
00:18:01
all of that information so that
00:18:03
it is that information is available to
00:18:06
the designer
00:18:08
at the the lowest end of the chain
00:18:11
um as well as the constraints that
00:18:15
is the power that we are talking about
00:18:17
when we are working from an
00:18:18
authoritative source of truth
00:18:20
perspective so
00:18:21
um ingesting everything that has been
00:18:24
laid out in that
00:18:26
sml model where there's a capability
00:18:28
architecture
00:18:29
taking the information the needs from
00:18:32
there at the level of specific
00:18:34
parameters
00:18:35
and constraints and you know making
00:18:38
decisions based on that
00:18:39
as you come up with the systems
00:18:41
architecture and then as you go into the
00:18:43
simulation
00:18:44
phase and do the trades and make some
00:18:46
decisions in terms of
00:18:48
your critical systems or non-critical
00:18:50
systems and then that decision-making as
00:18:53
it goes through different levels of
00:18:54
abstractions because
00:18:56
there are multiple artifacts that are
00:18:58
created to
00:18:59
simulate all of that and to do all the
00:19:01
trade studies that are needed to be done
00:19:03
and then all of that information flows
00:19:05
back to the system engineer in the
00:19:07
system model
00:19:08
and which is prepared as a response to
00:19:12
uh the model based rfi that has been
00:19:14
released to you
00:19:16
that's that's the power of the
00:19:18
authoritative source of truth where all
00:19:19
the artifacts
00:19:21
all the key all the kpis all the
00:19:24
stakeholders and all the requirements
00:19:27
associated with
00:19:28
every abstraction is fully integrated so
00:19:31
vertically throughout the different
00:19:33
levels of abstraction
00:19:34
and as i mentioned a couple of days ago
00:19:36
horizontally throughout
00:19:38
the different alternatives that you
00:19:40
probably are working on
00:19:42
so that's in in in a in a brief
00:19:45
how we are able to manage the model
00:19:47
based acquisition process and we have
00:19:49
developed various
00:19:50
assets and if there is any interest
00:19:54
we can specifically go into this topic
00:19:56
and present to you
00:19:58
how we have done some mock exercises
00:20:01
around
00:20:01
this entire process and then obviously
00:20:04
we are working on some of
00:20:06
the real life projects with the with the
00:20:08
government
00:20:12
okay thank you sanjay we had um we've
00:20:15
had a couple of questions come in
00:20:17
um during the session today that i think
00:20:19
they're kind of follow up from
00:20:21
some of the discussions that we've had
00:20:23
so let's um
00:20:25
we have a question around um
00:20:28
acceptance testing and the question is
00:20:31
at what stage are you writing and
00:20:33
executing the acceptance test
00:20:36
so acceptance testing is starting
00:20:40
right from the time those needs and
00:20:42
capabilities are laid out
00:20:44
in the capability architecture
00:20:47
you know there are performance
00:20:50
requirements there are security
00:20:51
requirements there
00:20:53
are cyber safety requirements there's
00:20:56
all kinds of
00:20:57
abilities um you know survivability or
00:21:00
affordability
00:21:01
or maintainability there's all kinds of
00:21:06
needs that are that can be extracted
00:21:09
from the capability architecture
00:21:11
if there's a certain you know framework
00:21:14
that is being used like
00:21:16
the uaf or nef uh
00:21:19
which is the unified architecture
00:21:21
framework nato architecture framework if
00:21:23
any of those
00:21:24
architectures are being used um
00:21:27
depending on the different views there
00:21:28
are specific
00:21:30
abilities and the associated needs
00:21:32
requirements
00:21:33
that can be extracted out of the model
00:21:35
that has been provided by the acquirer
00:21:38
and typically the acceptance criteria
00:21:42
the acceptance testing
00:21:44
um is starting at that level
00:21:47
i mean this is from a validation
00:21:49
perspective of
00:21:51
the system validation perspective as you
00:21:53
move forward with respect to developing
00:21:56
the actual system architecture
00:21:58
it gets into the specific performance
00:22:00
requirements of
00:22:02
the equipment and subsystems that are
00:22:05
going to be
00:22:07
brought into the the system architecture
00:22:10
from a simulation perspective or to
00:22:12
address
00:22:12
the different functions and services
00:22:14
that are needed
00:22:16
from an overall capability perspective
00:22:18
at that level
00:22:20
we are typically defining the test cases
00:22:24
that are verifying if the system
00:22:26
the subsystems or the specific
00:22:28
equipments are able to achieve the
00:22:30
performance that is needed
00:22:33
to actually address the overall
00:22:35
capability of the
00:22:37
system so i'll stop there and
00:22:40
see if you have any more details um no
00:22:43
he
00:22:43
he he thank you thank you sanjay i think
00:22:45
you answered this yeah
00:22:47
and uh and i will just add that to what
00:22:50
sanjay said
00:22:51
that we you know you could you could say
00:22:54
that you're doing acceptance testing
00:22:56
even at the requirements vetting stage
00:22:58
uh in a product such as stimulus
00:23:02
where you were checking the validity of
00:23:05
of your requirements and conflicts
00:23:07
between requirements that might be
00:23:09
um uh uncovered as part of that so
00:23:14
i would say acceptance testing would
00:23:16
would begin at
00:23:18
you know at the very beginning phases
00:23:20
and then continue throughout as sanjay
00:23:22
um mentioned okay hey thank you
00:23:26
there's a additional uh follow-up
00:23:29
question with regards to what we were
00:23:30
talking about with requirements
00:23:32
engineering
00:23:33
and the question is how is the
00:23:35
requirement engineering
00:23:37
integrating with system architecture
00:23:41
and then the the question says also what
00:23:44
what tool
00:23:45
so looks like wanting to know how we
00:23:49
integrate
00:23:50
um the requirements with uh the system
00:23:53
architecture
00:23:55
right so we from from a platform
00:23:59
perspective from the dussel systems 3d
00:24:01
experience platform perspective
00:24:03
what we do is as i said we have
00:24:07
a capability to work with
00:24:10
multiple external requirement management
00:24:14
applications be it
00:24:15
doors jama or many others on the market
00:24:18
or the platform provides
00:24:20
an integrated requirements management
00:24:23
application
00:24:24
uh which is which is part of the
00:24:26
platform
00:24:28
in either of those cases we are able to
00:24:31
manage the allocation
00:24:33
of the requirements um specifically
00:24:36
in in the system architecture at you
00:24:39
know each and every function
00:24:40
or a block level and those links
00:24:44
as those requirements are allocated
00:24:47
again the requirement could be endorsed
00:24:49
or requirement could be in jama or the
00:24:51
requirement could be
00:24:53
in a word document it could be in
00:24:56
a specific spreadsheet out there so we
00:24:59
see
00:24:59
all those situations when we work with
00:25:01
the
00:25:02
different many different programs across
00:25:04
different industries
00:25:06
in any of those situations we are able
00:25:08
to manage the
00:25:09
allocation of that requirement
00:25:13
to this specific um you know blocks
00:25:16
inside a system architecture if you're
00:25:18
working developing your system l
00:25:20
model we can allocate those requirements
00:25:23
to specific functions blocks
00:25:25
interfaces ports as needed and that
00:25:28
those links even though some of these
00:25:31
uh the the requirement application
00:25:33
itself
00:25:34
or the requirement document itself could
00:25:37
be outside of the platform
00:25:39
but the platform is able to capture the
00:25:42
the link that is being created
00:25:44
uh between that application and the the
00:25:47
system system model that could be
00:25:49
managed inside the platform per se
00:25:52
um so that that is my first answer to
00:25:56
the question
00:25:56
um hopefully that clarifies but i'm open
00:26:00
to
00:26:01
if you have a subsequent question here
00:26:06
um no there's no no follow-up question
00:26:10
yet uh there is kind of a
00:26:13
tangential to uh requirements
00:26:15
engineering question here i'll go ahead
00:26:16
and just uh
00:26:19
pose that it says that you know other
00:26:22
tools your requirements
00:26:23
management doors etc what is the
00:26:26
difference between
00:26:27
requirements management and requirements
00:26:30
engineering
00:26:32
right that's a great question um so
00:26:35
you know doors is doing um requirements
00:26:39
management
00:26:40
um and what you are typically
00:26:43
working on when you are working in a in
00:26:46
a context where you have a
00:26:48
standalone requirements management tool
00:26:50
you you have a system modeling tool
00:26:53
you have some kind of a behavior
00:26:56
modeling tool
00:26:57
or some any any tool which is doing
00:27:00
analytical modeling for you
00:27:03
then you have a specific simulation
00:27:06
tools
00:27:06
or um software modeling tools that are
00:27:09
part of the equation as well
00:27:11
so even if we're talking about the
00:27:13
conceptual design world i'm not even
00:27:15
touching the detailed design world i'm
00:27:16
not talking about 2d or 3d um
00:27:20
how how the requirements engineering and
00:27:22
requirements management are different so
00:27:24
when you talk about doors
00:27:26
it is basically capturing the end result
00:27:28
for you
00:27:29
in terms of capturing your needs and
00:27:32
your requirements
00:27:34
when we are talking about requirements
00:27:36
engineering we're talking about the
00:27:38
entire process of uh one
00:27:41
requirements planning that is how those
00:27:45
requirements that need to be developed
00:27:48
are going to be allocated to the
00:27:50
stakeholders so you have high level
00:27:52
needs you have high level capabilities
00:27:53
that have been
00:27:55
extracted from the capability
00:27:56
architecture
00:27:58
now there are going to be different
00:28:00
stakeholders in your organization
00:28:02
who are potentially going to to build
00:28:05
the actual
00:28:06
system requirements uh from those high
00:28:08
level needs or capabilities
00:28:10
so the allocation and planning in
00:28:13
context of
00:28:15
the jsits process for example where uh
00:28:17
you have the
00:28:19
um uh the uh the the systems
00:28:22
requirements review the preliminary
00:28:24
design review
00:28:25
the um critical uh design review
00:28:28
and many cfrs or
00:28:32
other reviews that take place so the
00:28:34
requirements engineering
00:28:36
includes first of all an integration
00:28:39
with the requirements planning process
00:28:41
where all the reviews
00:28:42
and the allocation of who the
00:28:46
stakeholders who are going to actually
00:28:47
build those system requirements
00:28:49
that is managed in tandem with the
00:28:52
development of the requirements
00:28:53
the second piece is the requirement
00:28:55
development itself
00:28:57
so the entire process of taking the
00:29:00
needs and converting them into first
00:29:02
stakeholder requirements from
00:29:04
stakeholder requirements to system
00:29:06
requirements
00:29:06
system requirements to specific um
00:29:10
you know subsystem or requirements or
00:29:12
test requirements
00:29:13
um verification validation criteria we
00:29:16
followed the in
00:29:17
cosy um system engineering handbook
00:29:20
which is based on the iso 15 288
00:29:23
to some extent we followed that process
00:29:26
of developing the requirements from
00:29:30
as i said from needs to stakeholder
00:29:32
requirements to system requirements to
00:29:34
specific subsystem and test requirements
00:29:38
and then verification validation uh
00:29:40
criteria associated with that so we
00:29:41
follow that um
00:29:43
that process and we have methodologies
00:29:46
laid out
00:29:46
on the platform where if you follow the
00:29:49
methodology some of you might have heard
00:29:50
about
00:29:51
it it's called as the cyber magic grid
00:29:54
um
00:29:54
used to be called as magic grid as part
00:29:57
of
00:29:58
the no magic uh tool set after the
00:30:01
acquisition of no magic
00:30:02
with the 3d experience platform and
00:30:04
integration with 3d experience platform
00:30:06
we extended the the magic grid to
00:30:09
include
00:30:10
the 2d and 3d processes so basically the
00:30:13
detailed design process as well
00:30:14
and the the new name for that is cyber
00:30:17
magic grid
00:30:18
when you look at the cyber magic grid
00:30:20
you see the development of the
00:30:22
requirements
00:30:23
at the different levels of abstraction
00:30:25
and the requirement evolves i'm
00:30:27
repeating myself
00:30:28
from the needs and the capabilities that
00:30:30
have been extracted out of the system or
00:30:32
system model
00:30:34
to the to the specific stakeholder
00:30:37
requirement to the system requirement
00:30:39
and then so forth
00:30:40
so this is this is again uh the
00:30:42
requirements planning then the
00:30:44
requirements development
00:30:45
um and then requirements traceability
00:30:48
the traceability is making sure there is
00:30:51
traceability not only between the
00:30:53
planning aspects of it so
00:30:55
all the reviews and the allocation of
00:30:58
tasks to develop these requirements that
00:31:00
have been
00:31:01
put in place there's traceability
00:31:03
between the program
00:31:05
this traceability between the design
00:31:07
artifacts uh there's traceability
00:31:09
between the artifacts themselves between
00:31:11
the requirements between the
00:31:13
stakeholders
00:31:14
and then the fourth level of the
00:31:17
requirements enduring
00:31:18
is the management so when you have
00:31:22
the planning the development and
00:31:25
traceability going in hand in hand
00:31:27
and at every level of abstraction there
00:31:29
are requirements that are being churned
00:31:30
out of this process
00:31:32
those requirements are captured either
00:31:35
in the
00:31:36
application available on the platform
00:31:38
for requirements management
00:31:40
or it can be captured again back into
00:31:43
doors
00:31:43
or back into your your your requirements
00:31:46
management tool of choice
00:31:47
but we do have a very strong
00:31:50
requirements capability requirements
00:31:52
management capability on the platform
00:31:54
which captures this
00:31:55
at every level of abstraction and then
00:31:57
manages those requirements
00:31:59
in a configured uh change controlled
00:32:02
environment with full status tracking
00:32:05
okay thank you sanjay a little bit of a
00:32:08
long-winded answer hopefully but
00:32:10
that that answers the difference between
00:32:13
uh
00:32:14
um requirements management and
00:32:15
requirements enduring to a certain
00:32:17
extent here
00:32:18
yeah yeah so looks like
00:32:21
from these last two questions i have
00:32:23
here
00:32:24
um i'm going to pose that people are
00:32:27
starting to think about
00:32:29
ways to adopt so this is a this
00:32:32
this is a kind of a two-part question
00:32:34
and then there'll be a final question
00:32:36
later but this question
00:32:37
is do you have any methods or processes
00:32:40
that companies can use to start adopting
00:32:42
mbsc
00:32:43
where should you start right so i
00:32:46
prefer go ahead and go ahead melissa i
00:32:50
think i think you will be
00:32:52
a better spot to answer that one that's
00:32:54
fine
00:32:55
um so one of the things that i find
00:32:58
through experience working with with
00:33:00
different uh aerospace and defense
00:33:01
companies is that
00:33:03
the the complexity of where to start is
00:33:05
definitely
00:33:06
a question and
00:33:09
knowing where your business is trying to
00:33:11
head for
00:33:12
in a transformational aspect is
00:33:14
important but
00:33:16
a lot of the entry points seem to be
00:33:18
from this bottom up
00:33:19
technology point of view and for a
00:33:22
transformational opportunity that
00:33:24
encompasses
00:33:24
mbsc aligning to the driving factors
00:33:28
both externally and
00:33:30
internally of why your business is
00:33:32
trying to transform to this mbsc
00:33:34
type environment um is essential and
00:33:36
then aligning those to the objectives of
00:33:39
why your company is changing and what
00:33:40
your company is doing
00:33:42
on from an initiative basis is important
00:33:44
to align to
00:33:46
so when you understand those top needs
00:33:49
um within your company
00:33:50
within your business aligning the
00:33:53
priorities
00:33:54
of activities that are going to fulfill
00:33:56
those needs are are
00:33:57
essentially what gives you the answer of
00:33:59
where to start and how to start
00:34:01
adopting um usually mdsc can be uh
00:34:06
defined at different levels for
00:34:08
different stakeholders
00:34:09
but priority would be aligning to what
00:34:12
your definition of mdse is
00:34:14
is it different within your company as
00:34:16
it is from industry
00:34:18
and if so try to align that um then
00:34:21
focus on the activities that help
00:34:23
support that
00:34:25
implementation is mbac just a system l
00:34:28
development tool
00:34:30
or is it the overarching practice from
00:34:32
requirements down through
00:34:34
development testing into manufacturing
00:34:36
right
00:34:37
so understanding the level of complexity
00:34:39
or the level of fidelity that you're
00:34:41
talking to
00:34:42
is is a first step um and then
00:34:45
once you understand that you'll be able
00:34:47
to kind of align the activities to
00:34:49
start prioritizing where you where your
00:34:51
needs are based on your company's
00:34:52
objectives and initiatives i hope that
00:34:56
kind of gave some clarity in that
00:34:57
confusion
00:35:00
changes you have a follow-up comment to
00:35:02
that or do you think she pretty much
00:35:03
covered it there no i i think that's uh
00:35:06
that's a good summary of
00:35:08
um besides that um in addition to what
00:35:11
melissa said
00:35:12
we do have specific methodologies
00:35:17
defined on our platform which are
00:35:19
typically
00:35:20
very much like a handholding
00:35:23
set of processes which can be
00:35:27
adopted to go step by step through this
00:35:30
approach
00:35:30
of developing the requirements
00:35:32
developing the system architecture
00:35:34
and um you know going through the
00:35:36
simulation processes
00:35:39
because you know if you really look at
00:35:40
that throughout the different levels of
00:35:43
abstraction as the system development
00:35:45
moves from a high level abstraction to a
00:35:46
lower level of abstraction
00:35:48
one thing that is a constant throughout
00:35:51
the entire process
00:35:52
is the requirements and the trade space
00:35:55
analysis
00:35:56
so the so the the simulation the
00:35:59
modeling and the simulation
00:36:00
of those modeling artifacts go hand in
00:36:02
hand and then the requirements are being
00:36:05
churned out of this
00:36:06
process between models and their
00:36:08
simulation
00:36:09
um you know through trade studies
00:36:11
through the trade spaces that are being
00:36:12
created
00:36:13
now all of this is part of what we
00:36:16
um we call as a cyber magic grid this is
00:36:20
our methodology
00:36:21
of uh you know how you can take a
00:36:24
high-level set of requirements
00:36:26
how you can analyze and a system need
00:36:29
from a black box perspective
00:36:31
and how do you analyze that from a white
00:36:33
box perspective
00:36:35
so that the whole methodology is
00:36:37
captured in what is called as
00:36:39
cyber magic grid uh this takes into
00:36:42
account all the capabilities that we
00:36:44
have integrated into our platform from a
00:36:46
no magic perspective so this takes into
00:36:48
account all the sml capabilities as well
00:36:51
and it goes all the way to the um
00:36:54
the 3d uh aspect of the design
00:36:57
so the the cyber magic grid
00:37:01
takes into account what you are doing in
00:37:03
developing a 0d artifact
00:37:05
a 1d artifact a 2d artifact and a 3d
00:37:08
artifact so
00:37:09
um you know if you are if you're going
00:37:11
through that entire process
00:37:13
there is a methodology in place if you
00:37:15
have not done
00:37:17
uh something like this before that
00:37:19
methodology takes you step by step
00:37:21
throughout the entire process
00:37:24
okay thank you and uh i have a final
00:37:27
question here if
00:37:29
if anybody in the audience would like to
00:37:31
ask a question
00:37:32
please enter it uh now and we'll get to
00:37:34
that but
00:37:36
my final question that i have here is
00:37:38
does the so
00:37:39
offer any training or services for
00:37:41
helping companies adopt in bsc
00:37:46
the answer is yes i mean there are
00:37:48
trainings available
00:37:50
from the 3dx or deso systems university
00:37:53
there are certifications available from
00:37:56
nasa systems 3dx university
00:37:58
and then we have a multitude of system
00:38:01
integrators and partners who provide
00:38:04
trainings on top of our platform
00:38:08
what melissa mentioned earlier we
00:38:10
typically go through this process
00:38:12
of understanding your
00:38:16
your current environment your current
00:38:18
needs and
00:38:19
your goals in terms of transformation
00:38:21
and
00:38:22
your business processes we identify
00:38:25
at what level and with what stakeholders
00:38:27
what training is needed and we typically
00:38:30
suggest on training certifications
00:38:33
from the 3dx university which are which
00:38:36
are
00:38:37
there's a lot of self-learning courses
00:38:38
available um
00:38:40
there are um you know in-person
00:38:43
training uh trainings available from
00:38:45
vessel systems training organizations
00:38:48
or there are opportunities to uh
00:38:51
uh get similar trainings from justice
00:38:53
system partners
00:38:55
who are partnering with deso systems to
00:38:57
develop this training material
00:39:00
on the platform and typically are able
00:39:02
to
00:39:03
not only provide the tool training but
00:39:06
consulting from methodology
00:39:09
depending on the industry you are
00:39:12
representing
00:39:14
yeah and to add to sanjay's comment
00:39:17
there's
00:39:18
also a services activity around organ
00:39:22
organizational change management and
00:39:24
that is aligned to kind of the
00:39:26
the engagement framework that we
00:39:28
typically do
00:39:30
to really understand your business and
00:39:31
how this transformation is going to take
00:39:34
place
00:39:34
um since there is a lot of complexities
00:39:36
in moving part we would work with the
00:39:39
the ocm group um to help
00:39:42
with the underlying organization needs
00:39:46
of your business so that it's not just
00:39:48
tools and functions but it's really
00:39:50
organizationally how how does this
00:39:52
impact your business
00:39:55
that runs alongside okay
00:39:58
well thank you jason um it appears that
00:40:02
uh we don't have any other questions
00:40:04
i'll leave it here for a few seconds if
00:40:07
anybody
00:40:08
any of the any of the attendees would
00:40:10
like a
00:40:11
chance to ask a final question before we
00:40:13
uh close out the session today
00:40:16
let's give it a few seconds here and see
00:40:18
what happens
00:40:20
all right so with that if uh
00:40:23
if you have any questions after we close
00:40:27
out today that you'd like to
00:40:29
ask um didn't think about till
00:40:32
after we've closed out the session you
00:40:35
all will be getting an email
00:40:36
from us you know thanking you for your
00:40:38
tenants advertising the future sessions
00:40:41
and there'll be some contact information
00:40:42
i believe that that email will have
00:40:44
my contact information so if you
00:40:47
uh you do have a follow-up email or i do
00:40:50
have a follow-up question please email
00:40:52
that back to me and
00:40:53
we'll get those answered to you and uh
00:40:57
so huge thanks to my three panelists
00:40:59
today i appreciate their time and their
00:41:01
effort and their information being
00:41:03
so great and with that i personally want
00:41:06
to thank all of you for your attendance
00:41:07
today
00:41:08
and i also want to thank heather
00:41:09
schneider who was
00:41:11
behind the scenes here controlling the
00:41:13
webinar session
00:41:15
hope to see you all in our future
00:41:17
sessions over the next two weeks and i
00:41:19
hope you all have a great
00:41:20
rest of your afternoon so thank you very
00:41:32
much
00:41:41
you