The Benefits of Functional Architectures | Systems Engineering: Managing System Complexity, Part 3

As we mentioned in the last video, systems engineering workflows tend to start with stakeholder needs and objectives, then work out key requirements, behaviors, and structure diagrams, before diving into the implementation of the design.  This flow allows us to really think about what a system truly needs to do before constraining ourselves with a particular implementation. Now, this isn’t a linear progression but a back and forth as the stakeholders, management, and engineering domain experts spiral in on the design. 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 can 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 this benefit us?

Well, we may start system design by thinking about what the system needs to do.  That is thinking about the functions the system needs to perform and how material, energy, and signals flow between those functions. Then we may start to start 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 progress through system design by creating different architectures, by looking at the relationships between functions, and logical components, and physical parts.

To give you a sense of why architectures are important, let’s focus on the benefits and uses of a functional architecture.

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 explain 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 I’d like you to get from this video are the ideas behind the methods so 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 is an input that flows into the function which could be one or more items consisting of material, energy and signals.  There is 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 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.  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.  We may decide to build a component as embedded software in which case implementation is writing code, or we could implement a component as something physical like a specific processor, or mechanical part, or electrical component. 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 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 ok to just understand that in some way they complement the functional, logical, and physical architectures and we’ll move on with this video.

Alright, at this point, I think this graph will make more sense if we walk through this process with an example.  We start with stakeholder needs and in this case the stakeholder needs a toaster.  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.

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.  As a side note here, if you’re having trouble coming up with the functions that your system need 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 is acting on.  So we have load bread, and apply thermal energy to bread, and remove toast, and convert energy to thermal energy. By thinking about the verbs and the items in your system it can make functional decomposition a bit easier.

Ok, 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 inline 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, 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 slots on top, a commercial toaster that also plugs into a wall but you load toast on a conveyor belt, a camping toaster that is lightweight and toasts bread over an open camp stove, or just a flamethrower and pair of tongs.

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 aren’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 counter top, and so on.  So, from 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. 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.  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.  Ok, 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.  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.  During this process crumbs can be generated and so the toaster needs to be able to store and remove those crumbs. Once the bread is in place, it has to be secured and held near to but not touching the heating elements.  At this point, thermal energy can be transferred to the bread, and when that’s done the toast can be removed.

Part of toast removal is releasing the mechanical energy that was stored, popping the toast up and making it accessible removal.  And the trigger for releasing this stored energy is when a signal is toggled from hold to release.  This signal is based on the output of a thermal or optical sensor that is 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.

One thing to note here is that even though some implementation has been assumed (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 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. 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 and 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.  This might be a cord that plugs into the wall or maybe through some kind of wireless system. We also need to think about how we are going to turn on the toaster 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 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.

So, hopefully with this example, you can start to understand how functions and architecture 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’s 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.