Towards a Model-Based Approach | Systems Engineering: Managing System Complexity, Part 2

As we mentioned in the previous video, the role of systems engineering is to help find and maintain a balance between the stakeholder needs, the management needs, and the engineering needs of a project - which can all be in conflict with each other.  If we ignore any one of those too much, the project will fail. We’ll run out of money, or design the wrong thing, or it won’t work, or whatever.  So, to the best of our ability we are trying to find a good balance of each of these needs as we progress through the lifecycle of the project.  Therefore, we can sort of think of systems engineering as a design optimization problem. And what I want to cover in this video is how optimization is done by making good decisions over the course of the project, and trade studies and engineering experience are methods for improving our chances that the decisions we make are actually good ones.  And we’re going to talk about how models play an important part in this whole process.  So, I hope you stick around for it.  I’m Brian, and welcome to a MATLAB Tech Talk.

Before we begin, I want to make sure we don’t take this idea of optimization too far. When you think of optimization you might have this thought that we’re trying to find the best solution.  That is, we’re trying to find some design that is the most optimal way to balance the needs of the three groups - which I’m just going to lump altogether and call the project needs.  But this isn’t actually the goal of systems engineering or really the goal of engineering in general.  What we’re trying to do is find a suitable solution.  It works but there are probably better designs out there. So, we are trying to optimize the design, but only so far as to find a working solution and not necessarily the best.  I think a graphic will help us realize this better.

During the course of an engineering project, there are many decisions that need to be made. Early in the project it might be choosing how to decompose the stakeholder needs into key requirements, and then more low-level decisions in the middle of the program like which resistor to use, and finally system-level decisions again near the end like how to validate what you built was what you needed.  All of these choices form a tree, a decision tree where at every node there are multiple paths that can be taken.

As a quick example, if the stakeholder is requesting a new air taxi vehicle, one of the choices that will need to be made early on is whether a fixed wing aircraft, a helicopter, or a quadcopter is the best way to meet the transportation goals, on schedule, and on budget, and all of that.

If we follow the tree through every decision, along every path, then at the far end are all of the theoretically possible solutions of each of these that you may come up with. Now, most solutions are dead ends, either they don’t meet the intent of the design, are not physically possible, are too expensive, or any number of reasons why a solution won’t work.  And there might be a theoretically best design that’s some perfect combination of performance, and cost, and simplicity and all that, but, there are more solutions that will meet the project needs. For example, it’s possible that these concepts each could result in a viable air taxi vehicle. Or slight variations of each of these could still be viable.

So, we have this landscape of design possibilities and ultimately, we’d like to go down the very best path and make all of the right decisions. But, to guarantee that we always choose the best path, we would need perfect knowledge of this entire landscape.   Which I think you have better chances of reaching the heat death of the universe before that happens. I mean, imagine designing every possible working variation of a flying vehicle as well as every possible non-working variation before you even make your first decision. Not going to work.  This is why we aren’t searching for the best solution. It’s unattainable.

So, this is the overview of the problem: we are looking for a path that results in at least one viable option, and in the process try not to venture too far down any dead ends and have to backtrack.  So, how can we approach this?

One of the first steps we have to do is explore what our option space looks like.  For each decision, we have to build up a list of reasonable choices that we want to consider as possible paths forward.  You might look at how other people have solved this problem, or what’s available commercially, or what what cutting edge research is being done.  Figuring out your options is where it can be beneficial to rely of the experience of domain experts.  I mean, we wouldn’t just choose these three configurations out of thin air, we’d have to know that there’s a possibility that each is worth exploring.  And experience can help narrow down the overwhelming infinite option space into something that is tractable. And something that can be designed and built by the workforce that is being set to it.  If a team only has experience designing fixed-wing aircraft, then it would make sense that more emphasis would be put on fixed-wing options.

Now with that being said, I do want to mention that we should be careful here, because you don’t want to ignore possible options just because they haven’t been done before. This is how our engineering biases can creep into the design and keep us building the same type of thing over and over again.  And systems engineering workflows try to address this by getting you to really considered the problem you’re trying to solve before thinking about a specific implementation.  We start with stakeholder needs, which is the purpose of the design, and then spend a lot of time working out the behaviors and the functions of the design before investigating the form and locking yourself into an implementation.

Ok, we know we need a set of options that we want to compare.  Now let’s talk about what we do with them.  We need some criteria or performance measures that we can use to weigh the options against each other.

For example, you might compare the carrying capacity, range, speed, and expected cost of a fixed-wing aircraft against the same for a helicopter and a quadcopter. A bigger and faster vehicle might cost more to build and operate, but could carry more people in a shorter amount of time so there’s a trade off here that needs to be done.

Which is why we call this decision making process a trade study.  A trade study, as the name suggests, is the process of comparing two or more options by judging them based on how they balance the conflicting program needs, and then choosing the solution that you think is the best.  It’s an optimization technique that helps you navigate through the decision tree.

Now, there’s nothing really special about trade studies, I mean it’s kind of generically how people make decisions anyway, right? You mull over some possible options, you think about what’s good and bad about them and then pick one.  If the decision is monumentally life changing, you may spend more time thinking about the possible outcomes of your choice.  And if it’s less consequential, perhaps you make the choice more flippantly. The same can be said for engineering decisions. The amount of information you need depends on the consequence of the decision.

So, how do we get that information. Here, we’re saying that we need to know capacity, range, speed, and cost in order to make this decision.  Now, in reality there would probably be a lot more quantitative measures that go into this and even some qualitative measures like the experience and skill level of the team, but to keep this simple, let’s just say we only need these four things.  The question now is how could you possibly know what the final range is going to be, or cost, or really anything at this early stage in the design? There’s so many possible paths for each of these choices from this point on that it seems like the uncertainty would be overwhelming.

Well, there are two extreme ways to make a choice: we could explore every path to its end and collect perfect information - we already said this was impractical, so the other extreme option is to make a choice with no additional information, essentially ignore every branch beyond this node and follow our gut or engineering experience. This can be done successfully, especially when you have the experts on your team who are able to understand the pros and cons of a particular choice based on their experience with similar past decisions.

But this doesn’t work in every situation because quite often we are doing something new and can’t lean on precedence or experience to quickly make a decision, and certainly not every single decision. So, if we shouldn’t rely solely on what we’ve done before, and we can’t collect perfect information, then we need to be able to make an approximation for each option.  And this is where modeling comes in.

Loosely speaking, a model is an approximation, or a representation of reality. They can take the form of a physical model, or a mathematical model, or more abstract things like behavior diagrams and architecture diagrams. Each of these are representations of reality and can be used to help us make an informed decision.

If they are done correctly, we can use them to simplify the problem by focusing on specific aspects of the design.  For example, a physical model of an airplane can help us analyze and make decisions about the aerodynamics of the real airplane.  By only modeling the parts of the design that affect aerodynamics, we have a simple approximation of the way air flows around the vehicle.  Of course, we don’t have to necessarily build a physical model to get this, we could also model the aerodynamics mathematically and perform the analysis with a computer through simulation. But both of these are examples of approximating the system with a model and they both can provide an estimate that we can use to make a decision.

And once we’ve committed to an aerodynamic strategy, that is, we’ve followed a particular branch, then the trade studies at the next level start again.  We build up a list of possible options, we develop a set of selection criteria, we approximate each option by refining our models, and make another decision.

This is essentially the idea behind model-based systems engineering - using models or approximations to help us make system-level decisions.  The richness of your model goes up as the complexity and importance of the problem increases.  Some decisions could be made using really simple mathematical equations that approximate things like the relationship between an aircraft size and the operation cost. These types of models could be analyzed or reasoned through by hand.  Some other problems might require more sophisticated equations that capture the complex dynamics of a system. In this case, understanding and analyzing this model might require simulation or some kind of computational engine to churn through the calculations. Still, other problems, require different types of models, like state machines and functional architecture diagrams.  And analyzing these types of models could also be done by hand or through simulation.  It depends on the richness of the problem.

But models provide more than just a framework for analysis and simulation, importantly, they also form the basis of how we communicate and exchange information between the stakeholders, management, and engineering domain experts. Models allow a way for each of these groups to understand the current design landscape and to help ensure that their needs are being met. And, furthermore, if they are set up to do so from the beginning, models can also evolve over the course of the project to become something more, like the production code, or a high-fidelity dynamics simulation that can be used for test and verification, as well as investigating what-if scenarios.

Ok, so hopefully from this video you get the idea that complex engineering projects require a huge number of decisions.  To make a good decision we can use trade studies, where we compare multiple options to determine which path has the highest chance of meetings the needs of everyone involved.  We want to make these decisions with information which we can get with models of the real system.  These models can take many different forms and of varying complexity, and in practice we have tools and workflows that help us develop, manage, and analyze these models, and that’s what I want to cover 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.