In my previous blogs, I’ve emphasized the importance of simulation for early verification as the key ROI of Digital Engineering.

I’ll be honest up front; this is a lie.

But not for the reasons you think.

In the post Bridging the Gap: Why Verification is the Missing Link in Your Digital Thread Strategy, we discussed how Model-Based Systems Engineering is a significant investment, and that simulating those models for early verification, or shift-left, is an essential aspect to achieving a return on that investment. This is true.

In the post Automatic Code Generation: The Unbroken Link in the Digital Thread, we also discussed how leveraging automatic code generation from these same models to extend the digital thread and automate verification down to the implementation amplifies this value. This is also true.

However, the ROI in both of these cases combined can be dwarfed by the value of using simulation for requirements VALIDATION, not verification.

The difference may sound subtle, but it is central to the ROI conversation, and industry priorities reflect that. In our Digital Transformation survey, the top topic respondents wanted to learn more about using system-level architecture models for simulation, trade-off analysis, and validation. To understand why that matters, let’s look at the Design V (pardon my being old-fashioned).

The image below is not just any Design V. It is the one in ARP4754A, which explicitly includes validation as requirements are derived and allocated.

SAE ARP4754 Rev A, Aerospace Recommend Practice, Guidelines for Development of Civil Aircraft and Systems, Pg 24

Here, simulation for early verification, and automated verification extending down to implementation, are both right-side-of-the-V activities. Verification activities answer the question, “Did I do this thing right?” In other words, did I build this thing correctly or, more specifically, does this system, software, etc. satisfy my requirements?

Verifying against requirements is often the focus in these workflows, especially when dealing with software safety standards like DO-178C. Most of the objectives in that standard are verification objectives. There is so much verification required we must focus on how to do it efficiently if we want to have any chance at meeting our program’s cost and schedule.

It’s natural to focus on modeling and simulation to automate these verification processes to succeed.

Organizations spend enormous effort proving they built the system correctly. Far less attention is often paid to a more important question:

Are we building the correct system?

This is validation.

Whereas verification is “did I do the thing right,” validation is “did I do the right thing.” Validation doesn’t care if the system or software satisfies the requirements. Validation is asking: are these even the right requirements in the first place?

That’s where simulation becomes much more than a verification tool. Instead of waiting until implementation to discover gaps in the requirements, engineers can explore operational scenarios earlier and identify missing behaviors before those omissions become software defects, design changes, or test failures.

In many ways, this is one of the most powerful applications of Digital Engineering: using executable models to improve engineering decisions before committing to a design. This is why I like the ARP 4754A Design V so much… it is very explicit that this is a question that MUST be asked.

SAE ARP4754 Rev A, Aerospace Recommend Practice, Guidelines for Development of Civil Aircraft and Systems, Pg 24

Every time you derive and allocate lower-level requirements, you must validate these back against the higher-level requirements. How are you doing this today? Even with something like a SysML model, this is most likely done by manual review as part of your Systems Engineering processes.

A quick thought exercise to illustrate why this is so important.

We are building an autonomous quadcopter. This autonomous quadcopter will require a software component for the Mode Logic.

Our models should start at the mission level of how the quadcopter interacts with the other systems in the scenario, then derive down to the system architecture of the quadcopter, to the software architecture of the flight control software, to the design for the Mode Logic software. At every level in this decomposition, we derive a lower-level set of requirements and allocate those, e.g. Mission Requirements –> Quadcopter Requirements –> Flight Control Requirements –> Mode Logic Requirements.

In this example, the Mode Logic requirements are treated as DO-178C High Level Requirements (HLRs), and an entire software development process is executed to build and verify software against these Mode Logic requirements. Using the models, and generated code, we can satisfy every objective of DO-178C and DO-331, meaning the code was developed in such a way that it does exactly what the requirements said, and nothing extra. This is the entire point of DO-178C.

However, in this case, there are still 2 latent bugs in the Mode Logic code that can crash the quadcopter!

How is this possible if we satisfied DO-178C? By definition, if we satisfied DO-178C, the code can only do what the requirements said. But what if, as is the case in this example, the requirements were WRONG? That means our fully verified software is perfect… just perfectly WRONG!

The requirements are incomplete because they forgot to address a few corner cases:

• What should the system and software do when it loses communication with the boat?
• What should the system and software do when the quadcopter is launched but has low battery?

There are no requirements to address these situations, so there is no code for these situations. This is a failure of requirements validation.

This is where simulation becomes a requirements-engineering tool, not just a verification tool.

By simulating operational scenarios before requirements are finalized, engineers can expose missing behaviors, unstated assumptions, and unexpected interactions long before software or hardware development begins.

This is sometimes referred to as design space exploration. Even with low fidelity models very early on, simulation of the system in its environment can illuminate scenarios for which desired behavior must be defined. These models can then gain fidelity as the system matures. But the key is to use simulation to help author the requirements correctly the first time!

This is not a new concept. Again, we can read ARP4754A, where it calls this out as recommended practice:

This brings us back to my lie: using simulation to automate verification to find errors earlier in the process is NOT the key to ROI in Digital Engineering.

Using simulation to avoid introducing requirements errors in the first place is the key to ROI in Digital Engineering.

In other words, using simulation to automate and shift-left verification is extremely valuable, but it’s not as valuable as using simulation to avoid the error in the first place.

With all this in mind, I challenge you to ask yourself and your organization this question:

Are the engineers writing your requirements using simulation?

If the answer is no, you’re missing out on the biggest potential ROI in Digital Engineering.

Mike Anthony is an aerospace engineer specializing in systems, controls, and verification, with more than 25 years of experience supporting complex, safety‑critical programs.