Why Verification and Validation Matter in Model-Based Design

Let me start with a simple question: How do you make sure the system you’re designing is actually going to work?

Your answer might, well, I’ll test it, right? You might build a physical prototype, or run the final code and hardware, and check everything at the end of the design cycle to ensure that it works. And sure, that is part of it, but it’s only one piece of a much larger verification picture.

And to understand that picture, I want to talk about model-based design. With model-based design, you’re using models throughout the entire process, from early definition, to development, to testing, and even deployment. And one of the biggest benefits of that approach is that you can verify that your system is doing what you want, and validate that you’re building the right system, much earlier in the process and continuously throughout.

So, in this video, we’re going to talk about what verification looks like in practice.

I’m Brian, and welcome to a MATLAB Tech Talk.

Before we go further, I want to quickly clarify something: We usually hear about verification and validation together - V&V. But they are slightly separate concepts.

Here’s a simple way to think about it: Validation is about whether you’re solving the right problem. Is the solution you are going after a valid way to meet the project objectives? For example, let's say your objective is to create something that counts how many steps you take in a day. A valid approach might be to use an accelerometer, maybe in a watch, that measures arm swing and infers steps from it. An invalid approach might be to build a satellite that records your movement and counts the steps directly. Obviously, this is a silly example but I really want to make the point that there are many ways to approach every problem and validation is the process by which you determine if what you are building is the  right thing.

Verification, on the other hand, is about whether you built the thing correctly, regardless of whether it's valid or not. We have to verify that we built exactly what we wanted to. Or in other words, did we successfully implement step counter in the watch or the satellite, whichever we chose to go with.

Now, both of these are really important, but in this video, we’re going to focus on verification; how you actually build confidence that your design does what you think it does.

And the key idea I want to get across is that verification is not a single test at the end of a project. It happens at multiple stages and in different forms.

Let’s walk through a few important ways to verify a system.

The first one is probably the most familiar: verification by example. That is, you show, by example, that your system does what you want it to do. That could be running a physical test once you have hardware to test, but, ideally it's also running a simulation with a model of your system, which can happen well before you have any hardware, in many more scenarios than, and without having to worry about breaking hardware . Either way, in both of these cases, we have defined inputs, expected outputs, and clear pass fail criteria. And we are using this criteria to answer the question - Did it work the way we expect it to.

But here’s the catch, not every issue shows up as a failed simulation or test. Some problems are more subtle. A few examples are poor code structure, violations of standards, maintainability issues, or things like divide-by-zero and overflow.

Plus, some things are just really hard to prove with testing alone. For example, how do you prove something never happens? If you only run a handful of tests, you can’t guarantee that certain behavior won’t occur, just that it hasn’t yet.

These types of things are verified without testing, through static analysis and formal methods. They don’t rely on running the system, they’re more about ensuring the design itself is sound, readable, and robust.

The last thing we need to think about is completeness. This is where coverage analysis comes in. Coverage answers questions like, which parts of the system did we actually exercise? Which states did we visit? Which branches did the code take?

This becomes especially important when systems get complex. If you have lots of logic, branching, or modes of operation, then unverified behavior can hide in the corners. And those corners are often where failures show up in the real world.

That’s why you need to ensure that you are exploring the system more completely than just running a few test cases.

So, when we say “verification,” we don’t just mean testing. We mean building multiple forms of evidence that your system behaves correctly, according to what you intended for it to do, and it does that across the entire design, under expected, and unexpected conditions.

With all of that being said, it's important to think about how you're going to verify your system - even before you've designed anything at all because if you don't think about verification early, you might make it difficult to do later on.

Let me give you a quick example from my own experience. I was working on a spacecraft, designing the guidance, navigation, and control system, and I had what I thought was a great idea; make the system fully customizable so that when it was in orbit, it could reconfigure itself any way it wanted to get the best pointing performance possible. We had multiple attitude sensors, multiple actuators that could adjust the attitude, and I developed multiple control algorithms of various complexity that could determine how to control the spacecraft most effectively.

And the spacecraft could mix and match any combination of them. I thought I was being kind of clever in allowing it to be this flexible. But during a design review, someone pointed out a problem, by adding in this flexibility, I had created a system with effectively hundreds of states and state transitions.

And that meant it would be nearly impossible to verify every scenario, nearly impossible to achieve full coverage, and ultimately, impossible to guarantee correct behavior on orbit.

So instead of increasing confidence by allowing the system to be flexible, I had actually reduced it, because I created a system that could easily hide failures and I’d have no way of knowing.

In this case, thinking about how we were going to verify this system actually drove changes in the design. We reduced complexity, limited the number of modes, and made the system something we could realistically verify.

And so a takeaway here is that good engineering isn’t always about making the most capable system possible. Constraining a system, through requirements, and specifications, and standards, is one way to make verification easier and have more confidence in the final result.  

Now, there’s so much talk these days about agentic AI, and you might be wondering whether these advances will fundamentally change the approach to verification. And I think the answer is yes. Verification will be even more important.

And the reason I say that is because AI helps with execution. It can build code, models, and even entire implementations. And it can do so incredibly quickly from a relatively small amount of input.

But when you give an AI a simple prompt and it produces something large and complex, it had to make decisions along the way. The prompt simply didn't contain enough information to fully specify every detail of the result. Some of those details had to be inferred.

So now it's even more important to ask the same questions we always ask: Does it actually meet the intent? And even if it works in the scenarios we've tried, does it work across all the scenarios we care about? That's where verification and validation come in. They are how we build confidence that a system does what we intended—even when AI helped create it.

Now ideally, you're not asking AI to invent large parts of the system for you. Instead, you've defined the system well enough that the agent is mostly executing your intent rather than filling in the blanks. You'll still need objectives, requirements, specifications, and standards. You'll still need to think through what you want to build and describe it clearly. This is also an important step because clearly defining what you want to build, is required for verifying that it was built correctly. This gives you the criteria that you are checking against.

So, AI may change how the work gets executed, but it doesn't eliminate the need to define what should be built - and it certainly doesn't eliminate the need to verify that it's correct.

So, verification, in general, just means building different kinds of evidence, and layering them together to ensure you built the things that you wanted, and your tools should make that process simple.

You are going to have to run simulated and physical tests, showing that your system meets specific expectations. You will use static analysis and other formal methods to catch issues without even running the model. And then you'll have to look at coverage, to understand what parts of the system you actually exercised, and importantly, didn't exercise.

And specifically with Model-Based Design, your verification efforts are connected to the model so you can do it early - even before specific details are decided like which hardware you're targeting, and keep doing it as the design evolves. So tools like MATLAB and Simulink aren’t just there to build models and run simulations. They help you build confidence in your system, throughout the entire design process.

If you want more information on how to do verification with MATLAB and Simulink, I’ve left a bunch of resource links below.b

Now, we can’t cover everything you need to know about verification in 9 minutes, but I hope this short introduction has made you aware of the importance of verification.

This is where I’m going to leave this video. If you enjoyed this explanation, you can find all of the MATLAB Tech Talk videos, across many different topics, nicely organized at mathworks.com. Thanks for watching, and I’ll see you next time.