{"id":155,"date":"2026-10-06T15:49:53","date_gmt":"2026-10-06T19:49:53","guid":{"rendered":"https:\/\/blogs.mathworks.com\/digitaleng\/?p=155"},"modified":"2026-10-06T15:49:53","modified_gmt":"2026-10-06T19:49:53","slug":"part-1-why-digital-engineering-matters-real-examples-real-roi","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/digitaleng\/2026\/10\/06\/part-1-why-digital-engineering-matters-real-examples-real-roi\/","title":{"rendered":"Part 1: Why Digital Engineering Matters: Real Examples, Real ROI"},"content":{"rendered":"
\n

When we launched Digital Engineering De-coded, our goal was simple: move beyond buzzwords and share practical patterns that help engineering teams solve real problems.<\/p>\n

This four-part series follows VIPR-GS researchers Tanmay Samak and Chinmay Samak as they reflect on their work developing and validating autonomous ground vehicle systems<\/a> in collaboration with the U.S. Army DEVCOM Ground Vehicle Systems Center. Their experience illustrates a challenge familiar to many engineering teams: individual digital artifacts may exist, but connecting them into a coherent engineering workflow is far more difficult.<\/p>\n

Across the series, we explore how their approach evolved from ad hoc simulation and analysis toward a more systematic workflow built around systems thinking, traceability, executable architecture, and evidence-based decision making.<\/p>\n

They will present their work at MathWorks EXPO Online 2026<\/a> on Wednesday, November 4.<\/p>\n<\/div>\n

Digital engineering is easy to describe at a high level. It is much harder to recognize in practice.<\/p>\n

Most\u00a0engineering organizations already\u00a0have\u00a0pieces of what we call digital engineering.\u00a0They have\u00a0requirements,\u00a0architecture models, simulations, scripts, test results, and shared repositories. From the outside,\u00a0it\u00a0can look like\u00a0everything is\u00a0in place.<\/span>\u00a0<\/span><\/p>\n

But the harder question is whether those pieces actually work together when the system becomes complex.<\/span>\u00a0<\/span><\/p>\n

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?<\/span>\u00a0<\/span><\/p>\n

That is why we wanted to\u00a0talk with\u00a0Tanmay Samak\u00a0and\u00a0Chinmay Samak, researchers at Clemson University\u2019s\u00a0Virtual Prototyping of Autonomy-Enabled Ground Systems (VIPR-GS)\u00a0Center. They\u00a0worked on\u00a0<\/span>autonomous ground vehicle development<\/span><\/a>\u00a0and validation in collaboration with the U.S. Army DEVCOM Ground Vehicle Systems Center\u00a0(GVSC). Their experience\u00a0reflects\u00a0a\u00a0challenge\u00a0we see across many\u00a0engineering\u00a0programs: teams do not usually fail because they lack digital artifacts; they struggle because those artifacts are disconnected from the decisions they need to make.<\/span>\u00a0<\/span><\/p>\n

Autonomy makes that problem visible quickly.\u00a0Perception, planning, control, vehicle dynamics, and operating environment all interact. A vehicle may fail a test, but the hard part is explaining why.\u00a0Was\u00a0the problem\u00a0in\u00a0the\u00a0perception\u00a0algorithm? The controller? The vehicle model? The test scenario? A parameter change? A requirement that was not met?\u00a0Or some combination of them?\u00a0As\u00a0Chinmay\u00a0explained, system complexity makes it difficult to know which part of the system\u00a0is responsible for\u00a0the behavior seen in the results.\u00a0<\/span>\u00a0<\/span><\/p>\n

That is what makes\u00a0the\u00a0VIPR-GS\u00a0story\u00a0interesting. 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.\u00a0<\/span>\u00a0<\/span><\/p>\n

This first\u00a0conversation starts with\u00a0a more fundamental question:\u00a0what changes when teams stop\u00a0thinking\u00a0about\u00a0digital engineering as a collection of\u00a0individual\u00a0concepts\u00a0and start\u00a0thinking\u00a0about\u00a0it as a\u00a0connected\u00a0engineering\u00a0workflow?<\/span>\u00a0<\/span><\/p>\n

Interview<\/h3>\n

\"\" Tamnay Samak\u00a0 \u00a0 \"\"\u00a0 Chinmay Samak<\/strong><\/p>\n

 <\/p>\n

Q: When you got started, where did you see the most confusion around digital engineering concepts?<\/strong><\/p>\n

Tanmay Samak:<\/strong> 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?<\/p>\n

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.<\/p>\n

Q: Did you see specific terms used interchangeably or incorrectly?<\/strong><\/p>\n

Tamnay Samak:<\/strong> 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.<\/span><\/span><\/p>\n

Q: How did your own view of digital engineering evolve as you moved from theory into practice?<\/strong><\/p>\n

Chinmay Samak:<\/strong> We were always interested in<\/p>\n

multidisciplinary engineering, which is why we studied mechatronics. We learned some of these concepts\u00a0early, but\u00a0learning them conceptually is different from applying them in\u00a0practice. When we moved into off-road autonomy, we saw how quickly complexity grows. That is when the value of a systematic approach became clear.\u00a0<\/span>\u00a0<\/span><\/p>\n

Q: What is the shift that matters most for teams starting to think about digital engineering?<\/span><\/b>\u00a0<\/span><\/p>\n

Chinmay Samak:<\/span><\/b>\u00a0The most important shift is thinking from a systems perspective. You can learn\u00a0the terminology\u00a0later. The real habit is connecting pieces and\u00a0maintaining\u00a0traceability so that digital engineering can deliver value.<\/span><\/p>\n

Key takeaways<\/span><\/b>\u00a0<\/span><\/p>\n

    \n
  • Digital engineering starts with systems\u00a0thinking:\u00a0connecting requirements, architecture, models, validation, and traceability into a coherent workflow.\u00a0<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
      \n
    • Complex systems expose disconnected workflows quickly because teams need to explain behavior across multiple interacting components.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
        \n
      • Digital engineering is not a single tool or concept. It is a connected approach that brings MBSE,\u00a0<\/span>M<\/span>m<\/span>odel-<\/span>B<\/span>b<\/span>ased\u00a0<\/span>D<\/span>d<\/span>esign, digital twins, simulation, validation, and\u00a0especially\u00a0traceability together.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
          \n
        • Confusion often appears when teams use digital engineering terms interchangeably but do not understand the distinct role each workflow plays.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
            \n
          • The\u00a0VIPR-GS\/GVSC example is useful because it shows digital engineering as a practical evolution, not a theoretical definition.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

            \u00a0<\/span>When a system-level test fails, can your team confidently explain which engineering decision, requirement, model, or subsystem contributed to that outcome?<\/span><\/b>\u00a0<\/span><\/p>\n

            Next in the series:<\/span><\/b>\u00a0Once the concepts are clearer, the next question is where conventional workflows begin to break down.<\/span>\u00a0<\/span><\/p>\n

             <\/p>\n

             <\/p>\n

            Bonus material:<\/strong>\u00a0This video includes the latest version of the work discussed in this blog series that integrates agentic tools into the digital engineering workflow.<\/em><\/p>\n