How AI and Software-Defined Design are Making Digital Twins More Accessible

AI’s dynamic capability to model and respond to user requirements is forcing the discipline of product design through unprecedented change. Deliverables are no longer speculative concepts or abstract projections. They are tangible outputs shaping real-world applications.

This transformation coincides with the shift from task-specific devices to software-defined hardware. By enabling continuous updates and improvements, products can adapt to new tasks and demands with greater flexibility.

For companies like Siemens, the surge in AI adoption comes at a critical time. Software complexity has grown exponentially relative to hardware, creating significant challenges for product development. This trend is especially pronounced in the automotive sector, where the average vehicle software platform has grown by nearly 40% annually since 2021, while productivity has crawled forward at just 6% per year, according to McKinsey.

The widening gap intensifies pressure on OEMs to speed up innovation and develop smarter, more efficient solutions. Siemens sees this as an opportunity to redefine how products are conceived and built.

David Fritz, vice president of hybrid-physical and virtual systems, Siemens, stressed that the concept of “software-defined” is more than a buzzword. Known as SDX, it represents a new approach to product development that merges hardware and software design into a fluid, concurrent process. “We define it as software-defined products,” Fritz explained. “Software-defined vehicles, SDV, is an example of an SDP, or an SDX.”

The roots of this concept trace back to decades of co-development practices. “It’s really come out of other technologies in the past—primarily co-hardware and software development,” said Fritz. “It’s come out of co-simulation, it’s come out of hybridization and virtualization, and a whole bunch of things come together.”

In essence, software-defined design transforms how products are conceived and engineered. “When you’re going through the development of a product, which includes the initial exploration of the product’s space—both hardware and software—where the hardware can impact the software design simultaneously, with the software impacting the hardware design,” Fritz said. “They both need to be malleable. They both impact each other.”

That interdependence is rewriting how engineers make core design choices. “The days of trying to choose a system on chip from a datasheet are pretty much over,” Fritz noted. “It’s not possible to have the generic part sold to many, many different vertical markets to get your volume up and then have it be able to handle each of those workloads equally well.”

The industry is responding to this need for flexibility. Fritz pointed to Arm’s Zena Compute Subsystem (CSS) as an example. “We have virtualized their compute subsystem so that software can be developed long before silicon ever exists,” he said.

That collaboration exemplifies the software-defined product concept on a smaller scale. “You can develop the software, and it’s bit-by-bit exact of what’s going to be in the physical device that doesn’t exist—and yet the software developer doesn’t know the difference,” Fritz said. “It’s as though he has an evaluation board with that device sitting on his desk. But it’s actually virtualized in the cloud.”

How Software-Defined Development Simplifies Automotive Software Integration

Modern vehicles are composed of interconnected electronic systems—such as in-vehicle infotainment (IVI), advanced driver assistance (ADAS), battery management and chassis control. These systems may run independently, share hardware or run on separate electronic control units (ECUs). When combined, they form a “system of systems,” making integration one of the biggest challenges in vehicle development.

“Putting all of those together before the vehicle exists is the most important way to verify that you’re not going to get into this integration hell,” Fritz said. “Whereas, with conventional technology, you would have separate Tier 1 providers provide each of those. Then, when they all come together, nothing works, and it’s not really an easy task to figure out what went wrong and why it’s not working. We’re still seeing this today. Virtually every OEM has massive recalls because, well, the software doesn’t work.”

READ MORE: AI Adoption in Manufacturing: Future Tech’s Matt Scavetta on Avoiding Last-Mile Failures

Fritz argues that a software-defined approach streamlines how carmakers identify or resolve design problems well before the physical vehicle exists. Engineers can now use continuous integration, continuous delivery and continuous testing, or an iterative CICD process, along with real-time virtualization to test versions of the vehicle as development progresses.

This can all happen through a “digital twin golden model” or a virtualization of the entire vehicle at its current stage in the development process, which is continuously refined over time. Teams can develop and test their own systems—such as braking or battery control—in the virtual environment and observe how it integrates with the overall system.

“You can run millions of those in the cloud over the weekend,” Fritz noted. When physical hardware becomes available, engineers can then swap virtualized parts for physical ones. The main goal is to avoid the aforementioned integration hell, where incompatible software or hardware causes major holdups in late development.

Verification Threading: Linking Software and Physical Requirements

As OEMs compete to deliver software-defined vehicles, Siemens is leveraging digital twin technology to overhaul the way automakers design, validate and update vehicle architectures.

Fritz explained that a true digital twin encompasses every actuator, sensor and compute component within a vehicle. From his vantage point, there are two parts to the digital twin. The first is the executable twin, which runs on the actual control software and simulates how physical elements (such as actuators, brakes or sensors) behave using physics-based models. The second is the declarative digital twin, which documents system requirements in a structured format that continuously updates throughout the product's life. 

“We bring both of those parts together in what we call verification threading, which allows you to make that leap from what’s happening in the electromechanical world and compare that to the physical requirements,” said Fritz.

READ MORE: Q&A: Applying AI and Digital Twins to Improve Machine Design and Manufacturing Processes

The rollout of Siemens off-the-shelf digital twin offering, PAVE360 Automotive, follows this approach by addressing the growing complexity of automotive hardware and software integration, Fritz explained. It accelerates both application and low-level software development for ADAS, IVI and autonomous driving.

To further illustrate, Fritz offers a scenario: a car traveling at 100 miles per hour on the Autobahn in the rain, with an object the size of a breadbox 100 meters ahead. “Can you stop?” he asks. “The truth is, with a digital twin, I can tell you with 98% certainty that you will not stop based on your current design.” From there, engineers can iterate. They can, for example, boost camera resolution, add LiDAR or upgrade CPUs and NPUs, until the system meets performance goals.

“That’s engineering,” Fritz said. “That’s not throwing things together and driving it and hoping that we are successful. Very different approaches.”

Co-Design at Scale Using PAVE360 Automotive

Early evidence that the system could effectively operate at scale helped Siemens secure multiple contracts with a German automaker. Siemens commissioned three of its top architects to develop unique platform designs.

Two of the three designs failed under scrutiny and were discarded. The third showed promise, but only after iterative refinements. “We implemented a higher-fidelity digital twin and pushed it to its limits,” Fritz explained. “Heavy workloads, corner cases—everything to validate performance.”

Meanwhile, the hardware team began designing components based on initial specifications. When they flagged practical issues such as thermal constraints and vibration risks, the software team adapted, finding alternative solutions without derailing progress.

This ability to work in parallel epitomizes how co-design ensures alignment with requirements. The result, said Fritz, was “a fully functional vehicle driving downtown Austin, Tex. in 18 months”—a feat the OEM could not achieve in seven years.

Built for Openness and Scale

Fritz stated that PAVE360 Automotive was designed with two primary tenets: openness and scalability. “We wanted to make sure we didn’t disrupt existing workflows,” he explained. “That meant using open APIs wherever possible.”

This approach remains uncommon in the market, largely because the task of implementing a set of rules, protocols and tools that allow different software applications to communicate comes with complexity. This is particularly true for industrial, automotive and engineering software.

Widely documented, industry standard concerns include long-term visioning discipline, strong documentation tooling, backward compatibility guarantees, security, governance and IP controls, as well as ongoing support across ecosystems. Equally important are concerns about losing platform control, competitive IP risks and support costs.

READ MORE: Benchmarking Mechanical Design With AI-CAD Integration

Siemens views openness as a sustained investment that enables PAVE360 Automation to integrate seamlessly with a range of parter tools, allowing specialized capabilities to plug into the platform without friction.

The second tenet (scalability) drives PAVE360 Automation’s cloud-first design. The platform supports major platforms, including AWS, and is expanding to customers in China, Korea and Japan, Fritz said.

Cloud vs. On-Prem: Balancing Cost, Scalability and Control in Automotive Digital Twins

The biggest obstacle to implementing this technology is the cost of cloud hosting. According to Fritz, cloud providers currently charge as if customers are running high-performance computing workloads.

Running an automotive digital twin calls for a different pricing model, he argued. Siemens acknowledges that not everyone wants to run the system in the cloud. Some organizations, such as military and aerospace organizations, prefer on-premises deployments for security and control. Siemens offers this option as well, even helping design purpose-built server racks, deploying them inside the customer’s firewall and supporting the entire setup.

But although on-prem solutions provide control and security, he added, they lack the elasticity of the cloud, making scalability a capital-intensive undertaking.

Digital Twins and AI Driving the Next Era of Software-Defined Vehicles

As vehicles become software-defined, the complexity of integrating multiple systems demands a new development paradigm. At its core, PAVE360 Automotive provides flexibility by design, giving companies the option to choose the deployment model that fits their needs, argued Fritz.

The ultimate goal for Fritz is confidence. In other words, ensuring that millions of virtual tests translate into real-world performance.

Looking ahead, Siemens plans to infuse more AI into PAVE360, automating large portions of the design and validation process. “There’s quite a bit of AI in our solution today, with more coming,” he said, signaling a future where digital twins and AI-driven workflows redefine automotive engineering.

Editor’s note: Siemens is demonstrating a full-car digital twin operating in the cloud while controlling a physical car on-site at CES 2026 in Las Vegas, Nev. January 6-9, 2026.