Digital engineering is easy to describe at a high level. It is much harder to recognize in practice.

Most engineering organizations already have pieces of what we call digital engineering. They have requirements, architecture models, simulations, scripts, test results, and shared repositories. From the outside, it can look like everything is in place. 

But the harder question is whether those pieces actually work together when the system becomes complex. 

Can the team explain why a particular result occurred? Can they trace a failed test back to a requirement, architectural decision, model change, software update, or operating condition? Can they understand the impact of a change before it becomes a problem? 

That is why we wanted to talk with Tanmay Samak and Chinmay Samak, researchers at Clemson University’s Virtual Prototyping of Autonomy-Enabled Ground Systems (VIPR-GS) Center. They worked on autonomous ground vehicle development and validation in collaboration with the U.S. Army DEVCOM Ground Vehicle Systems Center (GVSC). Their experience reflects a challenge we see across many engineering programs: teams do not usually fail because they lack digital artifacts; they struggle because those artifacts are disconnected from the decisions they need to make. 

Autonomy makes that problem visible quickly. Perception, planning, control, vehicle dynamics, and operating environment all interact. A vehicle may fail a test, but the hard part is explaining why. Was the problem in the perception algorithm? The controller? The vehicle model? The test scenario? A parameter change? A requirement that was not met? Or some combination of them? As Chinmay explained, system complexity makes it difficult to know which part of the system is responsible for the behavior seen in the results.  

That is what makes the VIPR-GS story interesting. It shows digital engineering not as a definition, but as an evolution in practice. The team began with digital twins and simulation. They could generate data and evaluate autonomy algorithms, but as the system and test space grew, they needed a more systematic way to connect requirements, architecture, models, simulations, and evidence.  

This first conversation starts with a more fundamental question: what changes when teams stop thinking about digital engineering as a collection of individual concepts and start thinking about it as a connected engineering workflow? 

Interview

Tamnay Samak      Chinmay Samak

Q: When you got started, where did you see the most confusion around digital engineering concepts?

Tanmay Samak: Digital engineering is not one thing. It is an umbrella term for different things that come together. Confusion often shows up at the interfaces between concepts: how does one concept connect to another, and where does it fit within digital engineering?

Some people treat digital twins alone as digital engineering. Others treat MBSE alone as digital engineering. Sometimes people understand the concepts individually but do not yet understand how they fit together. This power comes from connecting them rather than using each one in isolation.

Q: Did you see specific terms used interchangeably or incorrectly?

Tamnay Samak: We have seen people use the terms interchangeably. Sometimes a simple simulation is called a digital twin even when it has no connection to the real world. Sometimes people use MBSE when they are really doing model-based design, or the other way around. The terminology can be corrected, but the deeper issue is whether people understand what each workflow contributes.

Q: How did your own view of digital engineering evolve as you moved from theory into practice?

Chinmay Samak: We were always interested in

multidisciplinary engineering, which is why we studied mechatronics. We learned some of these concepts early, but learning them conceptually is different from applying them in practice. When we moved into off-road autonomy, we saw how quickly complexity grows. That is when the value of a systematic approach became clear.  

Q: What is the shift that matters most for teams starting to think about digital engineering? 

Chinmay Samak: The most important shift is thinking from a systems perspective. You can learn the terminology later. The real habit is connecting pieces and maintaining traceability so that digital engineering can deliver value.

Key takeaways 

• Digital engineering starts with systems thinking: connecting requirements, architecture, models, validation, and traceability into a coherent workflow.  

• Complex systems expose disconnected workflows quickly because teams need to explain behavior across multiple interacting components. 

• Digital engineering is not a single tool or concept. It is a connected approach that brings MBSE, Mmodel-Bbased Ddesign, digital twins, simulation, validation, and especially traceability together. 

• Confusion often appears when teams use digital engineering terms interchangeably but do not understand the distinct role each workflow plays. 

• The VIPR-GS/GVSC example is useful because it shows digital engineering as a practical evolution, not a theoretical definition. 

 When a system-level test fails, can your team confidently explain which engineering decision, requirement, model, or subsystem contributed to that outcome? 

Next in the series: Once the concepts are clearer, the next question is where conventional workflows begin to break down. 

Bonus material: This video includes the latest version of the work discussed in this blog series that integrates agentic tools into the digital engineering workflow.

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited. OPSEC11080.