this is the first video in a series on
systems engineering
now we're not going to attempt to cover
all of systems engineering in four or
five videos
but i'm hoping to present a broad
overview of how it helps us develop
complex projects that meet the program
objectives
in an efficient way efficient here means
that we're trying to minimize
unnecessary work
and rework we're trying to catch errors
and defects early in the design
and we're trying to effectively
communicate between all of the key
participants in the program
so that everyone is working towards the
same common goal
to understand how systems engineering
helps us accomplish that we're going to
cover
how system architectures are developed
and described
how we communicate the needs
requirements and constraints throughout
the project
how we optimize the design through trade
studies
and how we know the system does what
it's supposed to
in the end so that's the overview of the
series
but in this video we're going to stay at
a really high level
and talk about what systems engineering
is and why it's useful
i hope you stick around for it i'm brian
and welcome to a matlab tech talk
systems engineering is a process that we
can use to develop something that is too
complex to just design
and build as a single monolithic entity
it's starting from an idea often
nebulous and ill-defined
and then putting form to it it's
thinking about the system
as a whole and understanding the
interactions between it
and the external world as well as the
interactions of the internal components
and it's guiding the engineering process
so that the system can be
described in a way that can be
implemented and along the way
ensuring that it's meeting the needs of
the project
now of course there isn't just one set
of needs but competing needs from
different groups of people
there are the stakeholders the ones who
started the whole project and drive
the high level objectives these are the
customers
the ones who ultimately determine in the
end whether the thing you built
has value to them however there's also
project management who needs to balance
risk and schedule
and the budget and other programmatic
constraints
and there's the engineering specialists
these are the software and mechanical
and electrical engineers or
whoever has specific domain knowledge
and is responsible for designing and
implementing the system as described
they need a description that is actually
implementable
and is clear enough to understand the
key requirements and constraints
but not so detailed that they have no
flexibility
in the implementation they are the
experts after all
and so they will know how to best design
something
so what's left outside of all of these
circles
is the role of systems engineering it
helps guide the engineering process
and to understand the needs of each of
these groups and work to describe
a system that is compatible with all of
it
at the beginning of a project we start
with a nebulous set of objectives of
what we're trying to accomplish
we then form a few different concepts
that might meet those objectives
and through analysis and simulation
narrow
it down to a preliminary set that we
want to go forward with
often this set is complex enough that it
needs to be broken down
into smaller components and then those
components can be broken down even
further
until you're left with a set of things
that are simple enough for you to
understand how to engineer them
and then once these components are
designed and built
systems engineering is also the process
of ensuring that
each component does what it's supposed
to do and then the integration of those
components do
what they're supposed to do and so on
until you have a functioning top level
system that satisfies the original
objectives
and these complex problems could take
the form of a machine
or it might be a software project or you
might be engineering a transportation
infrastructure for an entire city
the key here is not the specific problem
that you're trying to solve
but that the problem is sufficiently
complex that you can't fully grasp how
to design it
without first breaking it down into
smaller components
of course the whole process is not a
linear progression
where the stakeholders tell the project
management what they want the systems
engineers decompose that into
requirements
and an architecture and the engineering
specialists then go off and build it
the process is iterative with tight
communication between all of the groups
so that they can spiral in on finer
details as the project progresses
through definition
and design which is critical because
often you'll find that the needs of the
different groups are in conflict with
each other
and only through trade studies and
architecture descriptions and
requirements
will you figure that out and be able to
work through it
however this approach isn't without its
own challenges
new problems arise when you decompose a
system into components
now you need to think about what the
best way is to
simplify this complexity what is the
best way to split up the system
functionally
logically and physically and then what
should each of these components do so
that they meet the needs of the higher
level system
and how can we make sure all of the
components are compatible with each
other
so that when they're built often in
different areas at different times and
by different people
they all come together in the end to
meet the needs of the project
these are the challenges of systems
engineering and what makes it such an
interesting field for people who enjoy
solving tough cross-functional problems
now to help us with this we have tools
that provide simplified
ways to develop system architectures and
define interfaces
and author requirements and trace them
back to the design
and we have model based approaches that
let us quickly analyze and simulate the
early architecture
so that we can perform trade studies and
find design
issues sooner and we have a set of
standard milestones
and review cycles to ensure that we're
not proceeding forward
in a design that can't be implemented or
won't meet a specific need
now here's the thing that i want to
stress at this point
the architecture descriptions the
reviews the trade studies and all of
that stuff
is additional work it's absolutely above
and beyond what you have to do
to develop and build a system let's say
you're building
a web app so ultimately the product is
software
writing the code has direct value to the
program because it has to be there in
order for the product
to exist on the other hand talking about
writing software is not directly
valuable
a product can still exist without having
for example a system requirements review
or a functional architecture diagram
neither of those things are absolutely
required
because they're not part of the final
delivered product in the end
so if that's the case then why take a
systems engineering approach at all
well you can probably guess requirement
reviews and architecture diagrams and
everything else
is necessary if the system that you're
building is sufficiently complex
the additional time and effort of
systems engineering will be
less than the time and effort required
to rework
and fix a system that was not
architected and described correctly
at the beginning this might make more
sense with a simple example
let's say that you are designing a car
door
clearly you need something structural
that is hinged to the car
frame and some kind of latch that can be
opened from the inside
and outside of the car so those are the
requirements and you get a mechanical
engineer on the design
during integration you look at it and
you think wait a second i want to be
able to see
out through the door as well so you have
the engineer redesign the structure to
hold
a glass window but now you want to be
able to open the window
so they redesigned the door to include a
mechanism for moving the window and a
mechanical crank
but that's not exactly what you wanted
you want it to be electric
well now you need to get an electrical
engineer to design in
a motor and a toggle switch and somehow
route power from the car electrical
system to the door
yeah well this is close but you also
don't want the window to crush
fingers if it closes on them so now you
need sensors and
software to manage the safety element
and so on and this sort of explore
as we go approach can allow us to
quickly jump into a project
and make progress early on that we can
learn from
however it can also create a work and
rework cycle that's expensive and
time-consuming
now of course this problem was contrived
and a bit silly
and you're probably thinking that if i
was on that project at the beginning we
would just brainstorm all of the things
we wanted it to do
then loosely figure out all of the parts
and then go our separate ways to design
and build our components
and if we ever had a question of whether
our components would interact nicely
with
another we just walk over and talk to
each other and hash it out
well that's systems engineering just on
a much
smaller scale everyone is a systems
engineer
on small projects because the problem is
simple enough that the group of
engineers are able to keep
all of the important information in
their collective memories
or with ad hoc notes and everyone can
work to stay in sync
with the overall goals of the project
and with each other
but this breaks down with more complex
projects where the interdependencies
between the high level objectives
the different functions and the
components aren't as straightforward
or there's just too many of them to
reasonably expect
an ad hoc approach will suffice
so that's why we have our processes and
our tools that help us decompose a
system into reasonable components
and architect how those components
should interface with each other
what they should do and how we'll test
them
and with model based methods we can
quickly assess the system
and allow us to hone in on a working
design quickly
and hopefully without lengthy failure
and rework cycles
now to illustrate this let's look at
what a systems engineering approach
might look like for a project where the
stakeholder wants a personal air taxi
service
we begin with stakeholder needs analysis
this is figuring out what the customer
is ultimately hoping to achieve
things like how many people need to be
transported and over how much time
and how far do they need to go and where
does it need to
land and take off from and what is the
target cost per passenger mile
and so on here we're getting a sense of
what the final system
should accomplish now from there
we can start the process of concept
exploration
that is figuring out all of the
different forms that the project
could take should we build a fixed wing
or a rotorcraft how fast should it
travel
how many passengers should it carry and
so on
models and simulations are then put
together to assess the feasibility of
each of these concepts
so that we can trade the pros and cons
of each and narrow it down to a
preliminary solution
and with a preliminary concept we can
start putting some definition behind it
with
system requirements these are things
like compatibility requirements
like what existing airport
infrastructure does it need to interface
with
then there's reliability maintainability
and availability requirements
like what are the acceptable failure
rates based on the severity of the
consequence
and how long can the system be out of
commission for maintenance
and then there's also environmental
requirements like what type of weather
must it handle
does it take off at high altitudes what
about dusty environments
with those high level performance
requirements mostly set
we can start dividing the system concept
up into functions
things like the airframe it has to be
able to fly and stay together
power needs to be stored and distributed
the system has to be able to communicate
with the ground infrastructure
and so on then we can look at how the
functions interface with each other
that's the signals and the data and
material and energy
that is exchanged between them and we
can talk about how
they are physically configured is the
function
performed by hardware or by software and
how is logic split between the different
software elements
we now continue to validate that the
concept will meet the needs of the
stakeholder
through analysis and simulations we
perform more trade studies where we look
at the cost and performance of different
specific implementations
and functional organizations of the
concept
if it's looking promising we start
developing the concept into something
more concrete
we derive lower level requirements and
we define
subsystems and start preliminary
configuration
and we refine the architecture
descriptions
and we continue to spiral through these
tasks providing
finer and finer detail until we get to
the point where we have enough
confidence to begin
detailed design and manufacturing
at that point we begin the process of
integration
and test and if we did the front end
work correctly
we will have minimized the number of
problems and rework that needs to take
place
of course it doesn't guarantee that
there won't be problems
but the systems engineering process
should keep you out of the situation of
constant rework
that we had with the car door example i
mean could you imagine if you were in
the system
integration and test phase and then you
realized that you should have built a
fixed wing aircraft
instead of a rotorcraft that would be a
nightmare
okay here's where i want to leave this
video simple projects won't necessarily
need a formal systems engineering
process
on the other hand something complex like
building an aircraft absolutely does
and in between well the specifics of how
you do systems engineering can vary
maybe the project could benefit from
thinking about hashing out requirements
but not necessarily from a formal
architecture design
and review each system and industry
might require a slightly different
approach that's why
over the next few videos i'm not going
to try to explain a one-size-fits-all
systems engineering approach
there just isn't one instead we're going
to go through some of the more important
tools
and processes that are used in systems
engineering
explain how they help you simplify the
problem and
provide some scenarios where you may
consider using them
in the next video specifically we're
going to look at systems engineering as
an
optimization problem and show how
engineering experience
as well as trade studies can help
optimize the design through good
decisions
plus we'll show how models and other
approximations of your system
are a key part of the decision making
process
so if you don't want to miss that or any
other tech talk video
don't forget to subscribe to this
channel and if you're interested
you can check out my channel where i
cover control theory topics
as well thanks for watching and i'll see
you next time