What Is Systems Engineering? | Systems Engineering: Managing System Complexity, Part 1

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 4 or 5 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 putting form to it.  It’s thinking about the system as a whole, and understanding the interactions between it and the external world and as well as the interactions of the internal components.  Its 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 is meeting the needs of the project.

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 is also project management who needs to balance risk, and schedule, and the budget, and other programmatic constraints.

And there are the engineering specialists. These are the software, 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 each of these circles is the role of systems engineering. Systems engineers help 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 system that we want to go forward with.  Often this system is complex enough that it needs to be broken down into smaller components.  And then those components could 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 suppose to do, and then the integration of those components do what they are supposed to do, and so on until you have a functioning top-level system that satisfies the original objectives.

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 they can spiral in on finer details as the project progresses through definition and design.  Which is critical because often you 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, however, isn’t without it’s 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 and 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 we’re not proceeded forward in a design that can’t be implemented or won’t meet a specific need.

Now here’s the thing I want to stress at this point. The architectures 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, as 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 to 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 you’re designing a car door.  Clearly you need something structural that is hinged to the car frame and some kind of latch that I 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 think, wait, 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 redesign 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. 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.

Ah, but you also don’t want the window to crush fingers if it closes on them. Now you need sensors and software to manage the safety element. And so on.

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 also can create a work and rework cycle that is expensive and time consuming.

Now, of course, this problem was contrived and a bit silly.  And you’re probably thinking if I was on that project, at the beginning we’d just brainstorm all of the things we wanted to do, 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’d just walk over 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 straight forward, or there are 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, architect how those component should interface with each other, what they should do, and how we’ll test them.  And with model-based methods we can quickly assess a system and allow us to hone in on a working design quickly, and hopefully, without lengthly failure and rework cycles.

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? How far do they need to go? Where does it need to land and take off from? What is the target cost per passenger mile? And so on. We’re getting a sense of what the final system should accomplish.

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 rotorcraft? How fast should it travel? How many passengers should it carry? etc. Models and simulations are put together to assess the feasibility each of these concepts so we can trade the pros and cons of each concept and narrow it down to a preliminary solution.

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? There are 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 there are environmental requirements like what type of weather must it handle? Does it take off at high altitudes? What about dusty environments?

With the 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, data, 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 software?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, balancing the project needs from management, the implementation needs of the engineering specialists, and the overall objectives of the stakeholder, providing finer and finer detail until we get to the point where we have enough confidence to begin detail 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 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 realized you should have built a fixed wing aircraft instead of a rotorcraft? That would be a nightmare!

Ok, 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, the specifics of how you do systems engineering can vary. Maybe the project could benefit from thinking about and hashing out requirements, but not necessarily from a formal architecture design and review.  Each system and industry might require a slightly different approach.  That is 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 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.

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.