in the previous videos we talked about
how systems engineering can help us
define the problem that we're trying to
solve
by providing a formalized way to think
about and document the program needs
and over the timeline of a project we
tend to define the problem first
with needs and requirements and so on
and then transition into execution of
that definition
where we complete the detailed design
and build things
of course there's more phases than these
two but for the most part i want to
focus here
for this video we've already covered
that spending time in the definition
phase of a project
and building models in this phase can
make the execution phase
more efficient unfortunately program
phases tend to be a little more
chaotic than this graphic suggests and
the phases overlap
and you have to backtrack sometimes and
so it's not as straightforward as just
moving from one phase
to another so what i want to cover in
this video
is how model based systems engineering
can help cut through
all of the chaos and get you from
definition
to execution more seamlessly
i hope you stick around for it i'm brian
and welcome to a matlab tech talk
let's start by describing this
transitional period so that we can
understand what
drives the chaos you might be thinking
that systems engineering is
solely responsible for decomposing the
stakeholder needs
into perfect descriptions of what the
system is and that the transition
from definition to execution is just
throwing the requirements and budgets
and everything else
over a wall to the engineering domain
experts as some kind of
specification that they must follow
this is almost certainly not the case
remember with the toaster example from
the last video
requirements decomposition which is part
of definition
required an assumption about an
implementation
and this level of specificity can't be
done without the domain expert
performing trade studies
and determining what's feasible and
ultimately helping to choose the best
implementation to go forward with
and it also can't be done without the
stakeholders refining their needs as
questions arise
and without management to weigh in on
the impact
to cost risk and schedule and so
rather than a one-time handoff of a
completed definition
the transition is more of a fuzzy
gradient as the project
and all of the people involved slowly
transition from
mostly definition into mostly execution
furthermore this graphic is kind of
giving the impression that the entire
project is transitioning at the same
time
but complex engineering is messy and
often certain components begin detailed
design
while others haven't really been thought
about very much
and this might be because some
components are naturally
simpler and so you can commit to a
design earlier or it might be
intentionally moved up in the schedule
because of a known long lead in
procuring some of the parts
or a component has a lot of unknowns and
the feasibility of the entire project is
in jeopardy if you don't focus on
finding a solution for that component
so you have to start development earlier
but regardless of the reason this simple
gradient
is really many different gradients that
represent the transitions of each of the
major components or
sections of the system and to complicate
this even more
this isn't always a one-way street where
you define the features of a component
first
before doing a detailed design and
building it
sometimes you start with one or more
existing components and you have to
figure out how to fit them
into the definition for example you
might be reusing software or hardware
from a previous project
this is common in the automotive
industry where the same
engine or transmission or some other
part is used across multiple vehicle
models
in this case the component is fully
developed
and you have to define the rest of the
system
so that it works with it now a real
quick aside
if you are building a system completely
by reusing existing parts
and you don't have a sense of what you
want the final system to do
this is a bottoms-up approach to
engineering it would be like starting
with a collection of legos and then
snapping them together to see what you
can create
you don't have a grand idea of the end
product you just
see what emerges from the available
parts
the top-down approach on the other hand
would be starting with an
idea of what you want to create and then
figure out which parts you need
in order to accomplish it however
more often than not we're doing some
sort of meet-in-the-middle approach
where some of the components might be
fully fleshed out and designed already
and you have to incorporate them along
with other components that aren't built
yet
in a way that meets the overall project
needs
and so in the definition phase you have
to make sure that the design you're
coming up with has compatible interfaces
with these existing components and that
the items that flow into the component
exist in your system
and that the requirements for that
component are incorporated into
the requirement hierarchy all right
back to this transition hopefully you
can see how this is much more
complicated than a one-time handoff
of the definition it's a process that
occurs over time with asynchronous
component timelines
and involves different groups of people
and has components of varying levels of
maturity
it's a transition where people are still
decomposing the system into functions
and components and writing requirements
while simultaneously
trying to perform trade studies and make
design choices
and the goal of systems engineering
through all of this is to make sure that
all of the people
and components and system design stay
compatible and consistent with each
other
and that they're still continuing to
meet the needs of the project
as a whole through this entire
transition
and this is where model based systems
engineering can shine
models are valuable because we can
execute them
and learn something about the system
faster than we could with
static documents that have to be updated
and interpreted manually
and in the early chaotic stage of a
project fast and accurate information
for decision making can make a huge
difference we can kind of get a sense of
the benefits of models
by expanding on the simple toaster
example from earlier in the series
a systems engineering team working with
management and the stakeholders have
decomposed the high-level program needs
into an executable functional
architecture but
in order to decompose say the heating
function
further and to write lower level
requirements for it the domain experts
need to get involved and start trading
possible implementations with a model
like this
they can start from the function
definition itself
in this way the domain experts are given
something to start from
which would ensure that things like the
interface to that function
is consistent with what's needed at the
system level
and then starting from this they can
model the physics of different
implementations that they believe can
meet the heating
needs so in this way the model provided
the definition of the interface
the requirements and all of the things
that go into the definition
in a convenient way but it also provided
the structure
around which the domain expert could
complete their design
but that's just one component at the
same time other components are
undergoing similar
trades and each of them are at different
levels of maturity as they progress
from mostly definition to mostly
execution
at their own rate of course if we are
reusing components and those components
already have models created
we just pull those models in as is
and through this whole process we
monitor for interface violations
or constraint violations or any other
mismatches in the design
and if there are any violations we can
catch that before we go any further into
the design
and then make changes to the components
or implementation to address it
now in addition to this sort of checking
violations as component models are
created
we can also simulate the system level
model
to verify performance measures are being
met
so model-based systems engineering and
model-based
design can work together to provide a
testing framework
that can be used for the individual
components and
for the full system verification
and one more thing that i quickly want
to mention here is that the models that
we build
as part of defining the system
especially for software-based systems
these models can become the actual
implementation
so a model can be more than just a
definition or a starting point for the
implementation
they can be the implementation for
example
a state machine defines the different
states of a system and how the system
transitions between those states
the definition is built into this
representation
and someone could write the code for
this state machine
as it's defined but we can also generate
the production code for the state logic
directly from the model so the human
readable diagram that defines the states
and their transitions is the source for
the code itself
now there's this dream in model based
engineering
where a single modeling ecosystem could
capture the stakeholder needs
and then requirements definition and
components definition and
implementations
and then provide a way to verify the
system through simulation and test
and that it can even be used during
operation as a digital twin
to do predictive control or predictive
maintenance
and since everything is linked together
throughout the project
within this modeling ecosystem there is
traceability
for everything that is done but even if
you don't get to that full
end-to-end model-based approach
hopefully you can start to see that
there is still value in adopting parts
of this process
all right now before i end this video i
want to recap what i think
the takeaway should be complex
engineering problems create
messy timelines and systems engineering
is the process of keeping the project
needs in mind while all of this chaos is
happening
and for complex systems it's difficult
to understand how every decision will
impact the final system
it's why we decompose the system into
simpler
and understandable components and why we
distill abstract ideas into concrete
requirements
and why we manage interfaces to make
sure that all of these components
which are possibly designed and built by
different groups all still
fit together so that's systems
engineering
and model based systems engineering just
takes all of that stuff
and puts them into models that we can
use to
more clearly communicate ideas and to
allow for early verification and
validation in the definition phase
and to provide a framework for trading
different implementations all of which
can help us make sense
of a chaotic transitional phase
okay that's where i'm going to leave
this video if you don't want to miss any
future tech talk videos don't forget to
subscribe to this channel
also if you want to check out my channel
i cover other control theory topics
there as well
thanks for watching and i'll see you
next time