An engineer, sitting down to design a product, rarely starts with a clean screen. Instead, the screen shows the product’s last version. The job now is to make it better, cheaper… or both. The engineer could pick up where they left off, continuing to refine a design interrupted by last year’s design freeze for the sake of production. Designs, as engineers know, are not perfected; they are abandoned. Picking up the abandoned design a year later, a thought occurs. It would be nice to get a report card on how the product had performed out there.
Let’s say the initial design was close to perfect. The product will not stay that way. No product stays as shiny and pristine as the rendered image. It gets dirty, wears, breaks and gets repaired.
If your product is a million-dollar excavator, for example, a failed part could delay a multimillion-dollar project. Knowing that it happened, perhaps more than once, the engineer who signed off on the part’s design could strengthen it. On the other hand, aircraft parts that show no wear or replacement after extensive use may be overdesigned and become candidates for lightweighting. And if every snowmobile customer in Minnesota is buying the same aftermarket accessory, the snowmobile manufacturer may want to offer its own version — thereby adding a surprise revenue stream.
Information inaccessible
Clearly, knowing how your product handles the hard knocks during its life would help design the next generation of the product. But getting service and maintenance data into the hands of the design engineer has been hard for several reasons:
- The records may not exist.
- They may be inaccessible.
- You don’t know where to look.
- Records are scattered.
- The data may sit in a system you are denied entry to. Like automobile warranty claims that are kept under lock and key by the dealer.
Even if all the above is false and maintenance and service records are accessible, would a design engineer want to wade through thousands of scattered notes, spreadsheets, work orders, invoices and receipts? I certainly would not. Not in my job description. Definitely not something I would enjoy.
Just ask
So what if the design engineer could ask, in plain English — or whatever language they speak — for (a) the most commonly replaced parts and (b) suggested design improvements? And what if AI could respond?
As usual, I am asking AI for the sky and the moon.
“Orbit can already answer what’s failing and where,” says Sumair Dutta, marketing lead of PTC Orbit. “With the 6.0 release, it can also reason about why and come back with an explanation and the evidence behind it.”
We meet Sumair Dutta and Micki Collart, also from PTC, on a Zoom call.
Those with a history with PTC know it as a design and engineering software company. But starting February 14, 2024, when Neil Barua took over as CEO, the writing may have already been on the wall. The company was expanding its role to an “intelligent product lifecycle approach,” connecting design and manufacturing to service.
Working in the dark
PTC announced Orbit at PTC NEXT in Chicago in June, 2026 as a cloud-native, AI-first as-maintained system of intelligence. Orbit is:
- a next-generation business intelligence capability for as-maintained assets.
- an AI-based product, so you query that knowledge in natural language.
- a connector across product information silos. Orbit pulls from Windchill and ServiceMax today, and on the roadmap are connectors to Servigistics, the SAS pipeline and Arbortext content.
Perhaps new to engineers is the term as-maintained, a term for all that has happened to an asset since it shipped from the manufacturer. It is not simply a snapshot of the asset at present but a connection all the way to when it was designed. That connection to the design is what makes the history useful to engineering. Engineering owns the as-designed product in CAD and the design bill of materials in the PLM system. Manufacturing owns the as-built, usually in an MES or ERP system. Sales owns the as-sold configuration, usually in SAP or Oracle.
Then the product ships and nothing happens. It’s not from lack of activity. Parts may be failing. Work orders may be piling up. Parts are swapped. Some of it lands in the field service system, some of it doesn’t. An engineer may get notified (maybe with a pink slip) of a part that results in a massive recall. Or they may not. Information about part failure must survive a trip more harrowing than a passenger pigeon in a war zone, going from field crews, warranty claims, landing at the manufacturer’s quality control window only to nest in a spreadsheet with a reliability engineer. Rarely does the message reach the design engineer.
The design engineer then makes the next generation of products from where they left off — in other words, in the dark.
Dissimilarity guaranteed
A 1953 Smithsonian study found that 98% of the molecules in a human body are replaced every year. Change is a fact of life.
Philosophers may ponder the idea of a universal flux, as did the ancient Greek Heraclitus, who said “No man ever steps in the same river twice, for it’s not the same river and he’s not the same man.”
It’s similar with machines. Any machine with a sufficiently long service life is in for having many of its parts replaced. I am reminded of buying a road bike with a titanium frame 20 years ago and justifying the expense as “the last bike I would ever buy.” Since then, every part of that bicycle has been replaced — except for the frame.
In a perfect world, a design is mass-produced and should lead to perfectly replicated products. In the real world, differences start appearing as soon as manufacturing starts.
- The second part coming off a CNC machine is different from the first, even if the difference is imperceptible. Tool wear does that.
- One production machine differs in age, use and operator.
- Each production machine itself is unique due to its unique. assembly and its own mass-produced yet imperceptibly unique parts.
Where the products are distributed from matters. Did they sit in a hot warehouse? Did the warehouse have rats? Rats are notorious for chewing off wiring insulation.
Let’s say the product is a delivery vehicle. Even in the same fleet:
- One operator runs a machine differently than the next.
- One operator may be more accident-prone.
- Each vehicle may have different routes, stop at different job sites and operate in different conditions.
If a consumer product company is lucky, its products end up all over the world. Now, they will live vastly different lives.
Orbit at your service
Applications like Salesforce, SAP and ServiceMax are built to record the lives of each product after manufacturing. But these are not apps that engineers are granted access to or trained to use.
All the apps have their own databases — and not always the same data. A motor may have three records: one in Salesforce, one in SAP, one in ServiceMax. The account name differs slightly. The install dates don’t match. Which one to trust?
Here’s where Orbit comes in. Orbit assembles the asset’s as-maintained history, connects that history back to design, and allows engineers to question the resulting context. Where there is a conflict in the data, Orbit will recommend which application’s data will become the data of record. For example, it would trust Salesforce for the account data, ServiceMax for the asset’s location, and ERP for the serial number. Roles get different permissions, preventing too much information and access to privileged information.
Orbit is smart enough to flag anomalies. An excavator might have an effective date in ERP from a month ago while CRM shows its cost a year ago. The AI can detect that discrepancy so the asset can be identified correctly.
English, please
A product engineer may know the language of CAD and PLM, but they wouldn’t know the language of ERP, FSM and CRM. With Orbit, they don’t have to. Orbit reduces that data-search burden and provides a more direct path to answers. They can simply interact with Orbit in their native language.
One demo showed a query for “reactive work orders of the Southern United States.” The AI on its own decided what states were in the South and returned results. In a later query for North America, it came back as the U.S., Mexico and Canada.
How Orbit works
PTC describes four layers:
- Data foundation. Aggregation from PLM, ERP, IoT, field service and proprietary homegrown systems, AKA spreadsheets. Then validation and unification. Tying data together is the ontology that supports data inquiry in your own business terms.
- AI layer. Agents supported by memory, context and reasoning.
- Connections. MCP, so Orbit’s agents can work with agents in other systems.
- Interaction. AI for natural-language queries and purpose-built applications.
Where engineers would use Orbit
Orbit can provide the opportunity to improve the next generation of a product by feeding the reality of what happens to it in the field into the design of the next version so it can be made more reliably and be more serviceable. That can be divided into multiple tasks, each one a chore today.
Field issue investigation. A quality or reliability engineer chasing a problem, trying to understand a potential design issue, may start gathering clues from the quality system, work orders, warranty claims, IoT signals and conversations with service engineers. Meanwhile, the issue keeps recurring. Orbit’s job is to get all the digital clues from the systems in place and cut the time required to understand the issue. By working faster and digging deeper, it can identify trends and help prevent product recalls and liability faster than a manual approach.
Orbit uses Creo’s viewer to present the product changes necessary.
Sample questions — asked in plain English — that Orbit can answer — in plain English.
- How many machines are affected?
- How many still run revision A of a pump?
- How many have already been replaced?
Orbit provides the evidence and impact analysis, such as how many assets are affected and which revisions are involved. The engineering change then runs in Windchill from problem report through change request and change notice. After approval, Orbit can turn the change into a field-service campaign.
Build it yourself?
Users with IT staff and access to advance data platforms such as Snowflake or Databricks may think they can do what Orbit does.
But general purpose database platforms cannot immediately know how the objects they store as records behave and how they relate to each other. Without an ontology connecting design, configuration, and service data, every new question could become a project. Orbit, on the other hand, already understands the physical assets, their configurations, service events, work orders and claims, and the relationships among them. A general-purpose database with AI has to be trained on your assets and the care they need, something ServiceMax has understood.
PTC applications—including Codebeamer, Creo models managed in Windchill, and ServiceMax work orders—create and manage source data and connect to Orbit. Orbit also connects to external applications, including Snowflake and Databricks, through integrations, open APIs and MCP.
When?
Although the usefulness of service/maintenance data in improving the next generation of products is undeniable, it remains to be seen how exactly it will be implemented for product designers and engineers and how much it will cost.
Imagine a world in which a design engineer need only to ask questions in their natural language and could just check in with Orbit when a product needs to be updated. Like this:
“Hey, Orbit. How can I make this product more reliable and serviceable?”
