Digital engineering is getting a lot of attention right now and for good reason. Teams across aerospace, defense, automotive, and industrial sectors are investing heavily in model‑based approaches, SysML v2, digital threads, and digital twins. The promise is compelling: better traceability, earlier insight, and fewer late‑stage surprises.

But in practice, many digital engineering efforts stall at the same point.

• The system architecture models look great.
• The executable behavior models validate design requirements and enable early design verification.
• And then… software gets written.

That’s where the digital thread quietly breaks.

Where Digital Threads Fail in the Real World

In theory, a digital thread connects requirements to architecture, behavior, implementation, and verification. In reality, most threads stop short of implementation.

The common pattern looks like this:

• Requirements are captured and traced to system models.
• SysML or architecture models define structure and intent.
• Analysis and simulation of executable models enable requirements validation automated early design verification.
• Then, engineers manually translate the verified designs into code for implementation on processors, FPGAs, SoCs, GPUs, etc.

Up to this point, engineering intent and system behavior are explicitly captured and verified. The break occurs when that verified behavior is reinterpreted during implementation instead of being carried forward directly and automatically.

That manual translation introduces interpretation, divergence, and rework. From that point on, the model is no longer authoritative. It’s a reference artifact. Verification has to be rebuilt downstream, and traceability becomes something you reconstruct after the fact instead of something you inherit by design.

I’ve seen this happen repeatedly. And it’s one of the main reasons digital engineering initiatives sometimes increase cost and schedule risk instead of reducing it.

MBSE operates at the level of the full product, spanning mechanical, electrical, software, controls, and other domains. Each domain requires a disciplined path from system intent to implementation and verification. But for the parts of the design implemented in software, FPGAs, SoCs, and GPUs, that path should remain automated and fully connected so verified behavior carries directly into implementation and verification.

Why Automatic Code Generation Matters

In a previous post, I discussed why verification is often the missing link in digital thread strategies, and that early verification only delivers value if verification intent and evidence remain connected as systems evolve. The next challenge is what happens to that verified intent when software is implemented.

Automatic code generation is often treated as a productivity feature. In digital engineering, it’s something much more important.

It’s the mechanism that keeps the digital thread intact.

When production code is automatically generated directly from verified executable models that are traceable to MBSE intent:

• The executable model remains the authoritative source of truth for the definition of the generated software’s behavior.
• Requirements trace cleanly to MBSE models and into executable behavior and on to generated software.
• Verification artifacts stay linked to both model and code.
• Changes propagate systematically instead of manually.

This is what turns models from documentation into engineering assets that drive execution.

Without automatic code generation, many digital engineering workflows lose continuity as they move from design into implementation. With it, digital engineering extends through delivery and stays intact when change inevitably happens.

Traceability That Survives Change

Change is not the exception. It’s the norm.

Requirements evolve. Architectures get refined. Interfaces shift as programs mature. When code is handwritten, every change forces teams to manually reconcile system models, executable behavior, software, and tests.

That’s expensive. And risky. And often… it never happens. During the inevitable schedule pressure of getting software delivered and out the door, the manual effort to go back and update models and upstream artifacts never happens. This means that system models and executable behavior no longer reflect what was actually delivered, and they gradually go stale. All the time, money, and effort that went into constructing those models is waste.

With automatic code generation:

• Updates to the executable behavior models drive updates to the software.
• Trace links remain valid by construction.
• Impact analysis becomes concrete and defensible.

This is especially important in safety‑critical and regulated programs, where proving what changed, why it changed, and how it was verified is as important as the change itself.

Figure 1: Traceability from requirements to executable models, tests, and generated code.

Enabling Early, Continuous Verification

One of the biggest promises of digital engineering is earlier verification to find problems when they’re still cheap to fix. That only works if the same artifacts are used consistently across design, implementation, and test.

Automatic code generation enables:

• Software‑in‑the‑loop testing early in development.
• Reuse of verification assets from executable model to generated code.
• Continuous verification as part of normal development workflows.

Instead of rebuilding tests downstream, teams carry verification forward as the system evolves.

That’s how you reduce late‑stage surprises instead of just documenting them.

Dashboard depicting model and SIL testing of a model

Closing the Loop: Models, Simulation, and Code

MBSE helps define system intent across the product, including requirements, architecture, interfaces, and cross-domain relationships.

Executable models at the system and design level enable analysis and simulation for requirements validation and early verification of system and design behavior.

Automatic code generation helps ensure that this verified behavior survives implementation without a manual translation step.

Together, they form a more complete and automated digital engineering workflow:

• MBSE defines product-level intent and architecture
• Executable models enable verification and validation of system and design behavior
• Automatic code generation preserves verified behavior into implementation in  software, FPGAs, SoCs, and GPUs
• Traceability connects models, code, tests, and results

This is the difference between doing digital engineering and getting value from it.

The Practical Takeaway

Digital engineering isn’t about creating more models. It’s about connecting the right models so engineering intent carries through to deployed systems.

MBSE defines system intent. Executable models define behavior. Automatic code generation preserves that behavior into implementation.

Simulation of models for early verification establishes confidence, and automatic code generation helps ensure that confidence is maintained as systems move into implementation.

Without that connection, the digital thread becomes a manual upstream modeling exercise with significant cost. With that connection, digital engineering becomes an automated execution strategy.

And that’s where the real payoff is: MBSE, executable models, verification, and automatic code generation come together to make the digital thread actionable. Not to mention that this also enables a value-added digital twin workflow… but we’ll cover that another day.

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