Some Benefits of Model-Based Systems Engineering | Systems Engineering: Managing System Complexity, Part 5

In the previous videos we talked about how systems engineering can help us define the problem that we’re trying to solve by providing a formalized way to think about and document the program needs.  And over the timeline of a project we tend to define the problem first, with needs and requirements and so on, and then transition into execution of that definition where we complete the detailed design and build things. Of course, there are more phases than these two but for the most part I want to focus here for this video.

We’ve already covered that spending time in the definition phase of the project and building models in this phase can make the execution phase more efficient.  Unfortunately, program phases tend to be a little more chaotic than this graphic suggests and the phases overlap and you have to backtrack sometimes and so it’s not as straightforward as just moving from one phase to another. So, what I want to cover in this video is how model-based systems engineering can help cut through all of the chaos and get you from definition to execution more seamlessly. I hope you stick around for it.  I’m Brian, and welcome to a MATLAB Tech Talk.

Let’s start by describing this transitional period so we can understand what drives the chaos.  You might be thinking that systems engineering is solely responsible for decomposing the stakeholder needs into perfect descriptions of what the system is.  And that the transition from definition to execution is just throwing the requirements and budgets and everything over a wall to the engineering domain experts as some kind of specification that they must follow.

This is almost certainly not the case. Remember with the toaster example from the last video, requirements decomposition, which is part of definition, required an assumption about an implementation.  And this level of specificity can’t be done without the domain experts performing trade studies, and determining what’s feasible, and ultimately helping to choose the best implementation to go forward with. And it also can’t be done without the stakeholders refining their needs as questions arise, and without management to weigh in on the impact to cost, risk and schedule.

And so rather than a one-time handoff of a completed definition, the transition is more of a fuzzy gradient as the project, and all of the people involved slowly transition from mostly definition into mostly execution.

Furthermore, this graphic is kind of giving the impression that the entire project is transitioning at the same time.  But complex engineering is messy, and often certain components begin detailed design while others haven’t really been thought about very much.  This might be because some components are naturally simpler and so you can commit to a design earlier, or it might be intentionally moved up in the schedule because of a known long lead in procuring some of the parts, or a component has a lot of unknowns and the feasibility of the entire project is in jeopardy if you don’t focus on finding a solution for that component, so you have to start development earlier.

Regardless of the reason, this simple gradient is really many different gradients that represent the transitions of each of the major components or sections of the system.

And to complicate this even more, this isn’t always a one way street where you define the features of a component first before doing a detailed design and building it.  Sometimes, you start with one or more existing components and you have to figure out how to fit them into the definition.  For example, you might be reusing software or hardware from a previous project. This is common in the automotive industry where the same engine, or transmission, or some other part, is used across multiple vehicle models.  In this case, the component is fully developed and you have to define the rest of the system so that it works with it.

Now a real quick aside, if you’re building a system completely by reusing existing parts and you don’t have a sense of what you want the final system to do, this is a bottoms up approach to engineering.  It would be like starting with a collection of legos and then snapping them together to see what you can make.  You don’t have a grand idea of the end product, you just see what emerges from the available parts. The top-down approach, on the other hand, would be starting with an idea of what you want to create, and then figure which parts you need in order to accomplish that.

However, more often than not we’re doing some sort of meet in the middle approach where some of the components might be fully fleshed out and designed already and you have to incorporate them along with other components that aren’t built yet in a way that meets the overall project needs.  And so in the definition phase - you have to make sure that the design you’re coming up with has compatible interfaces with these existing components, and that the items that flow into the component exist in your system, and that the requirements for that component are incorporated into the requirement hierarchy.

Alright back to this transition. Hopefully, you can see how this is much more complicated than a one-time handoff of the definition.  It’s a process that occurs over time with asynchronous component timelines, and involves different groups of people, and has components of varying levels of maturity.  It’s a transition where people are still decomposing the system into functions, and components, and writing requirements, while simultaneously trying to perform trade studies and make design choices. And the goal of systems engineering through all of this is to make sure all of the people, components and system design stay compatible and consistent with each other and that they are still continuing to meet the needs of the project as a whole through this entire transition.

And this is where model-based systems engineering can shine.  Models are valuable because we can execute them and learn something about the system faster than we could with static documents that have to be updated and interpreted manually.  And in the early chaotic stage of a project, fast and accurate information for decision making can make a huge difference.

We can kind of get a sense of the benefits of models by expanding on the simple toaster example from earlier in this series. A systems engineering team, working with management and the stakeholders have decomposed the high-level program needs into an executable functional architecture.  But in order to decompose, say, the heating function further and to write lower level requirements for it, the domain experts need to get involved and start trading possible implementations.  With a model like this, they can start from the function definition itself.  In this way, the domain experts are given something to start from which would ensure that things like the interface to that function is consistent with what’s needed at the system level. And then starting from this they can model the physics of different implementations that they believe can meet the heating needs.   So, in this way, the model provided the definition of the interface, the requirements, and all of the things that go into a definition in a convenient way, but it also provided the structure around which the domain expert could complete their design.

But that’s just one component.  At the same time, other components are undergoing similar trades. And each of them are at a different level of maturity as they progress from mostly definition to mostly execution at their own rate.  Of course if we are reusing components, and those components already have models created, we just pull those models in as is.

And through this whole process, we monitor for interface violations or constraint violations or any other mismatches in the design.  And if there are any violations, we can catch that before we go any further into the design and make changes to the components or implementation to address it.

In addition to this sort of checking violations as component models are created, we can also simulate the system level model to verify performance measures are being met. So, model-based systems engineering and model-based design can work together to provide a testing framework that can be used for the individual components and for the full system verification.

And one more thing I want to quickly mention is that the models that we build as part of defining the system - especially for software-based systems, can become the actual implementation.  So, a model can be more than just a definition or a starting point for the implementation, they can be the implementation. For example, a state machine defines the different states of a system and how the system transitions between those states. The definition is built into this representation.  And someone could write the code for this state machine as it’s defined. But we can also generate the production code for the state logic directly from the model.  So, the human readable diagram that defines states and their transitions, is the source for the code itself.

Now, there’s this dream in model-based engineering, where a single modeling ecosystem could capture stakeholder needs, and requirement definition, and component definition, and implementations, and then provide a way to verify the system though simulation and test, and then even to use the model during operation as a digital twin to do predictive control or predictive maintenance. And since everything is linked together throughout the project within this modeling ecosystem, there is traceability for everything that is done. But even if you don’t get to that full end-to-end model-based approach, hopefully, you can start to see that there is still value in adopting parts of this process.

Alright, before I end this video I want to recap what I think the takeaway should be.  Complex engineering problems create messy timelines.  And systems engineering is the process of keeping the project needs in mind while all of this chaos is happening.  And for complex systems, it’s difficult to understand how every decision will impact the final system.  It’s why we decompose the system into simpler, and understandable components, and why we distill abstract ideas into concrete requirements, and why we manage interfaces to make sure all of these components, which are possibly designed and built by different groups, all still fit together.  So, that’s systems engineering, and model-based systems engineering just takes all of that stuff and puts them into models that we can use to more clearly communicate ideas and allow for early verification and validation in the definition phase, and to provide a framework for trading different implementations.  All of which can help us make sense of a chaotic transitional phase.

Ok, that’s where I’m going to leave this video.  If you don’t want to miss any future Tech Talk videos, don’t forget to subscribe to this channel.  Also, if you want to check out my channel, I cover other control theory topics there as well.  Thanks for watching, and I’ll see you next time.