Across two days at Siemens Realize LIVE APAC, Daimler Truck presented what appeared to be two separate stories, but together they formed a single argument. Day one's vision pointed toward predictive maintenance and digital twins. Day two showed the PDM rebuild that has to hold that future up. Having stripped out forty years of accumulated product data complexity, Daimler Truck's choice puts the same question to every legacy OEM preparing for the SDV and AI era.

By Sang Min Han _ han@autoelectronics.co.kr
한글로보기

Related Article: “Yesterday’s Data Is Dangerous”




On day one of Siemens Realize LIVE APAC, a screen beside the stage read "Engineering the Future of Trucks." Under deep blue lighting, Radhakrishnan Kodakkal, Managing Director and CEO of Daimler Truck Innovation Center India (DTICI), walked out with his hands in his pockets and talked about trucks that keep evolving ten years after they leave the factory.
The next day, near the end of the schedule, Daimler Truck's Divya Muraleedharan, Deputy General Manager, and Mansi Tonapi, Senior Solution Architect, stood side by side under purple light — one in a cream jacket, the other in a striped blouse. What they had to say was the record of tearing down a forty-year-old PDM system.
Put the two sessions side by side and a question emerges: can a truck built to keep evolving for another decade run on a system that spent forty years accumulating complexity? Kodakkal showed the destination — predictive maintenance, digital twins, virtual validation. Muraleedharan and Tonapi showed what had to change first to get there. The next day's presentation filled in the blank Kodakkal left on stage. The vision came together on stage; the foundation came together off it.







The Truck of the Future Keeps Being Designed After It Ships

Kodakkal framed his example around a logistics company hauling produce through a remote part of Brazil. Today, when something goes wrong with the truck, the driver sees a warning light and has to guess what failed. In the future he described, the truck diagnoses itself, tells the service shop which parts to have ready, and decides whether it needs to stop now or can run a few more days. The point isn't predictive maintenance as a feature. It's that the era when a truck's development ended the day it was sold is over. As Kodakkal put it:
"A truck, once sold, stays with the customer for ten years, sometimes more. Think about how much technology changes in that time."
He said software and cybersecurity regulations shift every year over a commercial vehicle's decade-plus service life. He'd run into the same problem reviewing India's connectivity programs — one new regulation this year, another next year, another the year after. Keeping up with that means closing the loop: feeding design, operations, and maintenance data back into development.
The truck he put on screen was a wireframe built from CFD analysis — a body in blue lines with red and yellow heat-flow curves running across it. Virtual validation, reduced to a single image.
But building that loop takes an engineering system that's already changed, before the truck itself does. Before the vehicle gets smarter, the organization has to.







Daimler Truck Was Born Twice

In December 2021, Daimler Truck split from Daimler AG to become an independent company. That's where Muraleedharan and Tonapi's presentation starts.
What the new company inherited was roughly 1,500 applications and an aging PDM system. It had three and a half years to stand up its own. The easiest path would have been to lift the old system and carry it over — but the presentation argued the opposite. One slide read, in large type: "Don't rebuild the complexity of the past."
Another showed an astronaut standing on the surface of the moon, captioned "a once-in-a-lifetime opportunity." The spin-off wasn't treated as an IT separation exercise. It was treated as a chance to decide what should—and should not—be carried forward from the past.
"We were a new company, but we were also a company carrying legacy. This was a once-in-a-lifetime opportunity for us," Muraleedharan said.
That opportunity wasn't about copying the old system into a new home. It was about asking, from scratch, what an independent company would design differently — what a company with no legacy would choose.
The goal came down to three principles: standardization, harmonization, and platform thinking. Minimize regional customization, harmonize processes scattered across business units, and design around a platform rather than a project. They built the new platform on Siemens Teamcenter and moved it fully into the cloud. They called it PLATON. The spin-off didn't just hand Daimler Truck its freedom — it forced a choice about the future.
What's notable is that the team called this a "PDM transformation," not a "PLM transformation." PLM is the larger concept — requirements through design, validation, manufacturing, and service across a product's full life cycle. What this session covered was the layer underneath that life cycle: the system that manages product data. Before adding new capability on top of PLM, they had to rebuild the foundation for managing product data that forty years had made complicated. PLATON wasn't the destination. It was the backbone for the broader PLM environment Daimler Truck plans to build.
Widen the lens to the AI and digital-twin future Kodakkal laid out on day one, and PLATON is also the engineering data foundation that future starts from.








Complexity Isn't Moved. It's Removed

"Some of the migrations I've been part of didn't remove complexity — they relocated it. You take one system's customizations and legacy processes and give them a new home in another system," Muraleedharan said.
That's exactly what Daimler Truck tried to avoid. Move the data while replicating every exception and compromise the old system built up over forty years, and all that changes is the platform — the engineering complexity stays the same.
The project's scale was substantial: three continents (the Americas, Europe, Asia), seven business units, nine million objects, 123 terabytes of files, 5,200 bills of materials. More than sixty connected applications also had to exchange data with the PDM environment in real time and through batch processes.
Tonapi broke down why a migration of this size is hard into four points: harmonizing processes that had run independently across business units; migrating a mountain of legacy data while accounting for legal retention requirements; integrating more than sixty connected systems; and replacing the existing engineering client with the new one while validating the entire chain down to the shop floor.
The early approach leaned too heavily on technical proof. There were proofs of concept, but nothing that scaled across the enterprise, and neither the cross-business-unit harmonization strategy nor the MVP criteria were clear. Layer schedule pressure on top of the pull toward an ideal solution, and the gap only widened.
So Daimler Truck changed its approach. Instead of preserving every requirement from every business unit, it chose decisions that could actually scale, and it moved from pure agile development to a quality-gate model to manage the deadlines and quality that agile alone couldn't hold through the transition. That's when a big-bang cutover became a realistic option.
Rather than wait for a perfect solution and lose time, they moved forward on the premise of iterative validation — progress over perfection. But validation itself was never the thing they compromised on.
The biggest resistance here wasn't technical. It was organizational. Every business unit believed its own process was special and had to be preserved. The team's answer was to make leadership and governance explicit and pull every business unit into the decision-making process, so responsibility and ownership were shared rather than imposed.
Tonapi named early business involvement as the factor most often underestimated in this kind of work.
"You have to involve the business from the start. That is how you get the right feedback and make sure you do it properly," Tonapi said.
That's a different model from handing a finished system to the business and asking it to adapt. Bringing each business unit into validation and decision-making early made them participants in the transformation rather than its targets. Daimler Truck pulled experts from both its own team and Siemens's to build a stable core team, and made the structure explicit enough that parallel work was possible even inside a complicated process.
This wasn't a PDM replacement. It was the removal of the exceptions and compromises the old system had built up.







The Cutover Was One Day. The Success Came From Repetition

On April 13, 2026, Daimler Truck cut over to PLATON all at once. The numbers: 7,000 users worldwide, 123 terabytes of migrated data, seven major test cycles, more than 15,000 test cases.
The scale alone makes it a textbook big bang. But the presentation put its weight somewhere other than the numbers — on a paradox. The cutover took one day. The preparation didn't. Validation started with base objects and attributes, then widened to lower-level product structures, bus and truck product configurations, and business-unit-specific rules. Test capability increased in stages—from 30 percent to 60 percent, 90 percent, and finally 100 percent—through repeated checks that CAD files actually opened, BOM structures were complete, and data-sharing rules between business units held.
"The migration strategy was big bang, but our steps and validation were iterative," Tonapi said.
The final slide read: "PLATON is LIVE — Where We Are Today."
That slide was where the presentation's honesty showed.
"We are not perfect," Muraleedharan said.
Strong upfront planning made the big-bang cutover smoother than expected, while establishing a stable operating environment and a foundation for expansion into full PLM. But bug fixes are still ongoing, not everything has been tested, and performance still needs to stabilize across regions and time zones. PLATON is live. The transformation isn't finished.



The Future Belongs to Organizations That Combine Domain Expertise With Digital Intelligence

Circle back to Kodakkal's day-one talk and the precondition for the future he described comes into view.
For AI to assess a truck's condition, real-time operating data alone isn't enough. It needs to know how that specific vehicle was built — what parts and software it shipped with, what conditions it was validated under. Real-time data has to connect to forty years of domain knowledge.
"The future belongs to organizations that can combine domain expertise with digital intelligence," Kodakkal said.
Set the two presentations side by side and the premise behind that line becomes clear. AI transformation, or AX, isn't a project that simply bolts on one more AI feature. It's redesigning the relationships between product, data, and process so AI has something to reason over. Cutting ties with the past doesn't mean discarding the past's knowledge. What Daimler Truck tried to strip away wasn't forty years of product knowledge — it was the customization, exceptions, and regional process complexity that knowledge had gotten trapped inside. The truck of the future needs the engineering knowledge of the past. It doesn't need the past's systems. To connect the future, Daimler Truck started by separating the two.
After the session, I asked Muraleedharan whether she thought a transformation like this was possible at a traditional large OEM. She didn't hedge: Daimler Truck itself, she said, spans multiple product lines and a large user base, and the transition was never easy. "I think it's possible."
Scale itself wasn't the barrier. The question was how much of the complexity that scale had accumulated could be stripped away. What Daimler Truck cut to connect with the future wasn't the past. It was what the past had left behind.


 

AEM(오토모티브일렉트로닉스매거진)