as we mentioned in the last video
systems engineering workflows tend to
start with stakeholder needs and
objectives
and then work out key requirements
behaviors and structure diagrams
before diving into the implementation of
the design
and this flow allows us to really think
about what a system
truly needs before constraining
ourselves with a particular
implementation
now this isn't a linear progression but
a back and forth
as the stakeholders and management and
engineering domain experts
spiral in on the design so
in this video let's explore a bit of
this process
by walking through a simple design
example we're going to focus on building
a functional architecture
for a toaster and we'll show how
describing a system as a collection of
its functions
can help us navigate the early stages of
a project
and can provide a foundation from which
we can develop
models and perform trade studies i hope
you stick around for it
i'm brian and welcome to a matlab tech
talk
to start let's talk about what an
architecture is
a system can be characterized by the
elements that make it up
and depending on what we're trying to
achieve we may choose
different types of elements to describe
the same system
that is we could describe a system as a
collection of functions
or as a collection of logical components
or
a collection of physical parts or any
combination of these
and an architecture is capturing the
relationships between
those elements it's a mapping that shows
how different elements in the system
interact
and complement each other so how does
that
benefit us well we may start system
design by thinking about what the system
needs to do
that is thinking about the functions
that the system needs to perform
and how material and energy and signals
flow between those functions then we may
start to think about
who or which logical components are
responsible for achieving
a given set of functions and finally we
can think about
where those components will be
physically implemented
in this way we can progress through
system design by creating different
architectures
by looking at the relationships between
functions
and the relationships between logical
components and the relationships
between physical parts to give you a
sense of why
architectures are important let's focus
on the benefits
and uses of a functional architecture
but as a quick aside i want to mention a
small caveat here
systems engineering is a broad term that
is interpreted differently depending on
the industry you're in
you might use different types of
diagrams and terminology and
approaches to developing complex
projects than what i explained in this
video
so i just want you to be aware that what
i'm going to present
is one version but by no means the only
way
the important thing that i'd like you to
get from this video are the ideas behind
the methods so that you have a better
appreciation for
why they are valuable so with that out
of the way
let's get back to functional
architectures a
function has three parts there's an
input that flows into the function
which could be one or more items
consisting of material
and energy and signals then there's the
function itself that processes the input
in some way
and then there is an output that flows
from the function
that again consists of one or more items
let's look at a graph that shows roughly
how functions can play a role in the
systems engineering process
the stakeholder needs and objectives
kick off the whole
program and then the engineering team
starts to figure out the functions
that are required to achieve what the
stakeholder wants
items flow into and out from functions
and these connections from item to
function to item to function
form the basis of the functional
architecture
and we can decompose functions into
smaller functions
with more and more detail and
connections being added to the
architecture
and once we have sufficient detail the
functions are allocated to components
where they are grouped in some logical
way that is
we're grouping functions that either
work together in order to achieve
some higher level goal or are related in
some other way
and it's the components that are built
or implemented
to create the system itself a component
could be built with
software in which case implementation is
writing or generating the code
and there are software architects and
software engineers that are concerned
with a whole bunch of stuff here
like timing analysis and scheduling and
a lot of things that we're not going to
cover
in this systems engineering video
okay so besides software the other way
to implement a component is
as something physical like a specific
processor or a mechanical part
or an electrical component and
organizing the relationships between
these
physical parts is where the physical
architecture comes into play
now this simple graph only shows how the
three architectures are related
it's not a complete understanding of the
entire early systems engineering process
for example we have other things like
requirements
that state the key parameters that the
system must meet
now i'm going to cover requirements in a
lot more detail in the next video
so for now it's okay to just understand
that in some way
they complement the functional logical
and physical architectures
and we'll just move on with this video
all right so at this point i think this
graph is going to make a lot more sense
if we walk through this process with an
example
we start with the stakeholder needs and
in this case the stakeholder needs a
toaster
so let's build a functional architecture
at the top level
the main function of a toaster is to
toast bread
bread goes in some process happens to it
and toast comes out
and this is a functional architecture
but it's not a very complete one
at this point we haven't really
decomposed the problem enough to be able
to allocate this function to a component
and implement it or to be able to write
requirements
therefore the next step in this process
is to decompose the function
into smaller functions we could add one
that says that we need to be able to
load the bread into the toaster
and then apply heat to remove the
moisture and oxidize the surface of the
bread and then we need to be able to
remove the toast
and we can continue this decomposition
even more
and realize that in order to apply heat
we need a source of energy
and a way to convert that energy into
thermal energy
now as a side note here if you're having
trouble coming up with the functions
that your system needs to perform
a good way to think about a function is
as a verb
noun pairing the verb is what the
function is doing
and the noun is the item that it's
acting on
so we have load bread and apply thermal
energy to bread
and remove toast and convert energy to
thermal energy and by thinking about the
verbs and the items in your system
it can make functional decomposition a
bit easier
okay so back to the example how can we
decompose these functions even
further well we might be tempted to add
a function that controls how
toasted the bread gets but we have to be
careful here because we don't actually
know
if this is in line with what the
stakeholder wants
all we know is that they want a toaster
and the functions that we've identified
so far
are necessary for any toaster we will
have to load bread and apply thermal
energy and remove toast
regardless of whether we're building a
standard residential toaster that plugs
into a wall
and you load toast through the slots on
the top or
a commercial toaster that also plugs
into a wall but that you load toast on a
conveyor belt
or a camping toaster that's lightweight
and toasts bread over an open campfire
or if it's just a flamethrower and a
pair of tongs
and this is how thinking about
functional architectures and other types
of behavior diagrams can facilitate
the back and forth between the
engineering team and
the stakeholders the needs and
objectives were underspecified
so we weren't able to make any more
progress without revisiting the high
level objectives
and key requirements let's say that the
stakeholder is actually looking for a
residential toaster
where the users need to be able to
adjust the toasting level and to be able
to clean it and have it fit on a kitchen
countertop and
so on so from all of this we're able to
continue the process of decomposing the
functional architecture
now this is going to get massive pretty
quickly so let me show you a version
of this architecture that i built in
system composer
and the inspiration for this
architecture comes from a paper called
theoretical underpinnings of functional
modeling
preliminary experimental studies that
i've linked to in the description
if you want to check it out
on the far left are the inputs into this
system
we have electrical energy a hand and of
course
the bread now having a hand as an input
might
seem kind of silly but we need to make
sure that certain processes are designed
in a way that a person
can interact with it so this is a
necessary
reminder of that okay now let's follow
the bread
through this process there is the import
bread function which again sounds kind
of funny but what this is saying is that
we need to consider how the bread is
going to
enter into the toaster we need a place
for it to go
and beyond that we have to be able to
position the bread with a hand
and then guide the bread from the
initial position to the toasting
position
which in a lot of residential toasters
is with a lever that you pull down
storing mechanical energy in a spring
and during this process
crumbs can be generated and so the
toaster needs to be able to
store and remove those crumbs and once
the bread is in place
it has to be secured and held near to
but
not touching the heating elements and at
this point
thermal energy can be transferred to the
bread and when that's done
the toast can be removed and part of
toast removal
is releasing the mechanical energy that
was stored popping the toast up
and making it accessible for removal and
the trigger
for releasing this stored energy is when
a signal
is toggled from hold to release
and this signal is based on the output
of a thermal or
optical sensor that's measuring the
state of the toast
and comparing it to a variable set point
and all of this is powered by electrical
energy that comes
in from some external source
now one thing to note here is that even
though some implementation has been
assumed
you know that we're storing mechanical
energy for example
most of these functions are independent
of any form
or implementation for example we haven't
yet assumed
how to store the crumbs or how to
generate thermal energy from electrical
energy
just that these functions are necessary
and that we should probably trade some
different implementations
to see which best serve the needs of the
overall toaster
and the user and once we agree on a
method
like a removable tray and nichrome
heating coils
then we can decompose the functions even
further if
it makes sense to do so alternatively we
may have
reached a level here where the
engineering domain experts are able to
take this function
and the requirements and design a crumb
tray
or heating coils with no additional
decomposition
now this full view of every toaster
function is nice
because we can get a holistic view of
how everything interconnects
and from this view we can audit the
toaster architecture from a system level
perspective
and try to determine which functions
might be missing or to make sure that
the interconnections between functions
are consistent and complete
and even though this is a simple model
so it's easy to understand the
architecture in its entirety
that isn't necessarily going to be the
case for your system
the system level architecture might be a
spaghetti mess of boxes and connections
and difficult to use as a tool for
communication
so one way to simplify an architectural
model is to view
only the components that are of interest
to the person looking at it
for example an electrical engineer might
only want to see the components that
in some way interact with the electrical
system
we can get that by changing the view
and i've set one up for just the
electrical components
here we can see that there is electrical
energy from some external source
and we need to import it into the
toaster and this might be a cord that
plugs into the wall or maybe through
some kind of wireless system
and we also need to think about how
we're going to turn the toaster
on and begin toasting is this with a
mechanical switch
a digital switch maybe you want it to be
turned on from a smartphone over
bluetooth
again this diagram doesn't constrain the
implementation it just lays out the
functional needs
we can also see that we need to regulate
the energy
use it then to drive a sensor and
convert it to thermal
energy for heating so at this point
we have most of what we need to start
the process of trade studies
where we come up with different
implementation options describe the
performance measures
build models to estimate those measures
and make a selection
all right hopefully with this example
you can start to understand how
functions
and architectures can play a role in the
systems engineering process
but as we talked about it's not the only
thing
we also need requirements so that we
have a description of the key parameters
that the system
must meet and that is what we're going
to talk about in the next video
so if you don't want to miss that or any
other future tech talk videos
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