For robotics companies
Robotics teams do not have a BOM problem. They have a problem where the mechanical design, the board and the firmware are on three different cadences and the product is whatever combination shipped that week.
The three-cadence problem
Mechanical parts revise on a timescale set by tooling and suppliers — weeks to months, expensively. Electronics revise on board spins, which is faster and still discrete. Firmware revises whenever somebody merges, which may be several times a day.
Most PLM systems handle the first well, the second acceptably, and the third by pretending it is the second. Treating a firmware build as a part revision produces either a change order per commit or a version field nobody updates, and every robotics company has tried one of those.
Manufacturing PLM holds firmware as an item with revisions like anything else, but the release that matters is the configuration: this mechanical revision, this board revision, this firmware version, qualified together. The configuration is the thing that was tested, and it is the thing a unit ships as.
That reframing is most of the value. It stops the question being *what revision is the robot* — which has no answer — and makes it *which qualified configuration is this unit on*, which does.
Fleets are never on one version
A deployed fleet is a distribution across configurations, not a version number. Units built in March have the old bracket, forty of them took a firmware update last week and eleven failed it, and three were repaired with a substituted motor that is functionally equivalent and physically different.
The as-built record per serialised unit is what makes that tractable. A unit's configuration is what it was built with plus what has changed since — field service actions, firmware updates, part replacements — each recorded as an event against the unit rather than as an edit to a number.
The question that pays for the whole system is scoping. A defect is found in a specific motor lot; which units contain it, where are they, and what configuration are they otherwise on. That resolves through as-built records and lot genealogy in minutes, or through a spreadsheet and several people's memory over days.
The failure it prevents
A firmware update is validated against the current hardware configuration and released to the fleet. It works on every unit in the lab.
Nineteen units in the field are on an older motor driver revision, superseded eight months earlier, still in service because those units have not needed repair. The update changes a current limit the older driver handles differently. Two units fail in a way that damages a gearbox.
The validation was correct for the configuration it was run against. Nobody knew nineteen units were on a different one, because the fleet was thought of as a version rather than as a distribution. Compatibility rules expressed against configurations rather than against a version number are what stop an update reaching hardware it was never tested on.
How it meets the rest of the product
Variant resolution handles the configuration matrix, which in robotics is usually driven by end-effector options, sensor packages and regional power differences rather than by a long option list. The rules stay small and the resolutions stay fast.
Effectivity handles the cutover between mechanical revisions, which matters here because mechanical changes and firmware changes have completely different lead times and a change calendar showing both is the only place they meet before production does.
Requirements and their verification links carry more weight in robotics than in most industries, because safety arguments depend on them. A requirement satisfied by a firmware behaviour needs to name the firmware version that satisfies it, and that link is what makes a safety case re-checkable after an update.
How it meets your ERP
Firmware is the field where PLM and ERP disagree most often in this industry. Your ERP generally wants a serialised unit to have a part number and a serial, and has no concept of that unit's software changing afterwards.
The workable arrangement is that the ERP holds the unit as built and Manufacturing PLM holds its configuration over time. Trying to represent post-shipment firmware changes as ERP transactions produces either a flood of item revisions or a field that stopped being true within a month.
Service parts are the other seam. A replacement motor that is functionally equivalent and physically different needs to be orderable, which means the AML and the ERP's item master have to agree about substitution — and that agreement is a system-of-record decision made once rather than argued per part.
Where the boundary is
Manufacturing PLM is not a fleet management or OTA update system. It holds the configuration record and the compatibility rules; deploying an update, monitoring a fleet and collecting telemetry belong to tools built for that, and it reads their results rather than replacing them.
It also does not build or version your firmware. Your source control and CI own that entirely. What Manufacturing PLM holds is the released artefact, its identity, and the configurations it is qualified against.
Facts
| Three cadences | Mechanical (months) · boards (spins) · firmware (daily) |
| The unit of release | A qualified configuration, not a product revision |
| Wrong question | What revision is the robot — it has no answer |
| Right question | Which qualified configuration is this unit on |
| A fleet | A distribution across configurations, never one version |
| Per unit | As-built, plus every service action and update since |
| Pays for itself | Defect scoping through as-built and lot genealogy |
| Not offered | Fleet management · OTA delivery · firmware builds |
Frequently asked
How do you handle firmware that changes daily?
As an item with revisions, but the release that matters is the configuration — this mechanical revision, this board revision, this firmware version, qualified together. Treating a firmware build as a part revision gives you either a change order per commit or a field nobody updates.
What revision is our robot, then?
That question has no answer, which is the point. A product spanning three disciplines on three cadences is not at a revision; a specific unit is on a specific qualified configuration, and that is the fact worth being able to look up quickly.
How do you track a deployed fleet?
As a distribution across configurations rather than as a version number. Each unit's record is what it was built with plus every change since — field service actions, firmware updates, part replacements — recorded as events against that unit rather than as edits to a number.
What is the failure this prevents most often?
An update validated against current hardware reaching units on a superseded revision that nobody knew were still out there. Compatibility rules expressed against configurations rather than version numbers are what stop an update reaching hardware it was never tested against.
Does Manufacturing PLM deliver firmware updates?
No. It holds the configuration record and the compatibility rules; deploying updates, monitoring a fleet and collecting telemetry all belong to tools built for that work. Manufacturing PLM reads their results where an integration exists, rather than trying to replace any of them.
Do you build or version our firmware?
No. Your source control and CI own that entirely and do it far better. What Manufacturing PLM holds is the released artefact, its identity, and the set of configurations it has been qualified against — which is what your source control does not track.
How does our ERP handle post-shipment firmware changes?
Usually badly, which is why the workable split is that the ERP holds the unit as built and Manufacturing PLM holds its configuration over time. Representing software changes as ERP transactions produces either a flood of item revisions or a field that quietly stops being true.