Why engineering and maintenance need to work from the same digital twin
When Siemens engineers examined possible changes to an aircraft landing gear, the options initially belonged to product design: develop a new part, modify an existing component or reconsider the assembly. Then another possibility entered the discussion. Could changing the maintenance interval be evaluated alongside those engineering choices?
Tony Hemmelgarn, President of Siemens Digital Industries Software, uses the example at IFS Unleashed in Orlando while discussing the company’s partnership with IFS. The collaboration aims to connect the detailed product information held in Siemens’ engineering software with the maintenance and asset records managed by IFS. This would allow engineers to better understand how equipment performs throughout its working life and use that knowledge when investigating problems or considering design changes.
Manufacturers can simulate products in considerable detail before production, yet the knowledge collected while equipment is operating often sits elsewhere. Maintenance records, service histories and accounts of recurring problems can remain disconnected from the design models used to investigate failures or plan improvements. Hemmelgarn’s argument is that engineers need access to both kinds of information when deciding what to change and why.
Beyond the design model
Digital twins are established tools in complex product development, helping engineers test designs before committing resources to physical manufacturing. They allow manufacturers to explore how a design behaves under different conditions and whether it can be produced consistently. However, modeling a finished product requires engineers to consider the interaction of several disciplines and the processes used to bring the components together.
Siemens is developing digital twins that allow engineers to investigate potential problems before a product enters production. They can test how components fit together, assess likely performance and compare alternative designs without having to manufacture every variation. This gives engineering teams an opportunity to identify problems earlier and make changes before they become more expensive to resolve.
“The digital twin is not a new concept,” Hemmelgarn says. “It has been around for a long time, but product design is becoming increasingly complex. You have mechanical design, electronics, electrical systems, software and manufacturing processes, and all those elements are part of the digital twin. The closer we can bring those relationships together, the more valuable the information becomes.”
The engineering model, however, cannot anticipate every circumstance an asset will encounter after delivery. Equipment operates under different loads, environmental conditions and maintenance practices, while technicians accumulate evidence of wear, faults and the effectiveness of repairs. Some of this experience can influence subsequent design decisions, provided it can be connected to the appropriate product configuration and engineering records.
There is a precedent for this approach in Siemens’ earlier work with manufacturing engineering. Hemmelgarn describes efforts to improve the relationship between departments that have often worked with incomplete visibility of each other’s requirements. The intention was to make their decisions more closely connected during product development.
“There was a wall between manufacturing and engineering, and we created what we called process-driven product design,” he adds. “The idea was that you design the product with an understanding of the manufacturing process, and the two influence each other. We have continued looking for ways to break down those walls.”
Extending that exchange to maintenance would bring operational experience into decisions traditionally made using design and simulation data. Engineers investigating a component problem could examine what has happened in service as well as what the original model predicted. Maintenance teams, in turn, could receive information about modifications that affect how an asset should be inspected or serviced.
When maintenance changes the engineering decision
The landing gear example emerged during work with an agentic model that examines product configuration, design information and simulation results. The model was used to evaluate different scenarios, allowing engineers to consider possible responses using the information available within the digital twin. As Hemmelgarn describes, the discussion unexpectedly reached beyond conventional design alternatives.
“We were looking at the landing gear and considering whether we should redesign it, create a new part or modify an existing component,” he continues. “Then another possibility came up: what if we changed the maintenance intervals? We initially glossed over that, thinking we could simply link it to a maintenance asset, but when we started working with IFS, we realized there was an opportunity to do considerably more.”
The options carry different implications. Replacing a component may require engineering analysis, testing, manufacturing changes and new spare parts, whereas adjusting a maintenance schedule affects inspections, servicing activity and asset availability. Any decision involving safety-critical equipment would require appropriate engineering evidence and authorization, regardless of the technology used to support it.
The collaboration proposes a way to examine those alternatives with less separation between engineering and service information. Siemens brings detailed knowledge of product design and simulation, while IFS contributes capabilities associated with asset management, maintenance and operational workflows. Linking the two could help teams identify which response deserves investigation before committing to a redesign or altering established maintenance procedures.
Changes to a component’s design can also have consequences for the way equipment is maintained, particularly when modifications affect inspection requirements or servicing procedures. Maintenance teams need to know which versions of a product are affected and whether existing instructions remain appropriate. Equally, engineers need access to information about recurring problems encountered in service so that the experience of maintaining equipment can influence future design decisions.
For manufacturers with several product variants and long service lives, maintaining that connection is demanding. Assets can undergo modifications after delivery, and records may describe different versions of components that appear similar. Reliable identification of the asset, its configuration and its service history will be essential if intelligent systems are to present engineers with the right evidence rather than simply more information.
Shortening the investigation
Hemmelgarn also sees an opportunity to reduce the time employees spend locating the documents needed to investigate engineering problems. Specifications, simulation results, maintenance records and quality information may be held in separate applications, and tracing a fault can involve several rounds of requests between departments. Even when the necessary information exists, assembling it into a usable account of the problem can delay a decision.
Siemens is already applying agentic technology to accelerate some engineering processes. Hemmelgarn described tasks that previously took weeks being completed in hours, and he expects closer connections with IFS systems to extend those gains into investigations that depend on both design and operational information.
“We are doing some very interesting things with agentic technology, where processes that previously took weeks are being completed in hours,” Hemmelgarn continues. “If we can connect our software with IFS and close that loop even further, we can reduce the time it takes to identify quality issues, trace problems and make decisions about whether something needs to be redesigned.”
The timing claims refer to work Siemens has already undertaken, not verified results from the broader Siemens–IFS integration. Transferring information between systems is also only part of the task. Manufacturers must establish whether records describe the same asset and revision, whether maintenance observations are relevant to a design question and whether a proposed action complies with engineering and safety requirements.
A more connected process could nevertheless change the way investigations are conducted. Instead of asking an engineering team to assess failure and consulting maintenance specialists later, manufacturers could examine design, production and service evidence together. That may make it easier to distinguish problems that require changes to a product from those better addressed through approved adjustments to operating or maintenance practices.
The Siemens–IFS collaboration remains at an early stage, and the practical benefits will have to be demonstrated in customer operations. Hemmelgarn’s landing gear example provides a useful measure of what success would look like: engineers considering the full range of technically justified responses, informed by how the equipment was designed and how it has performed. For manufacturers investing in digital twins, the value of those models may increasingly depend on whether the experience gained after production can influence the next engineering decision.

