One thread from R&D to on-site integration across three continents.
The integrator commissioning robots in a warehouse opens the same bill of materials the designer edited that morning. No export, no re-keying, no version to reconcile.
| Assembly / part | Qty | Mass |
|---|---|---|
AMR platformAMR-SYS-001 | 92.40 kg | |
Chassis & driveASM-1100 | ×1 | 38.60 kg |
Drive wheel assemblyPRT-1142 | ×4 | 4.10 kg |
Suspension armPRT-1156 | ×4 | 1.85 kg |
Climbing moduleASM-1200 | ×1 | 21.20 kg |
Climbing gearboxPRT-1231 | ×2 | 6.40 kg |
Rail guidePRT-1248 | ×4 | 1.10 kg |
EnergyASM-1300 | ×1 | 18.90 kg |
Battery packPRT-1312 | ×1 | 16.80 kg |
Masses roll up from the leaves. This is not an export of the BOM — it is the BOM.
The people who install the robots are not the people who designed them
A warehouse robotics manufacturer sells a goods-to-person system: fleets of climbing AMRs, racking, picking stations. R&D holds the design; installation and maintenance are delivered by integrator partners under contract, across Europe, North America and Asia. Each partner needs the current BOM, the certification pack for the local authority and the update history for its fleet — on a product that changes every few weeks.
- Product
- Goods-to-person AMR system
- Delivery
- Integrator partners, maintenance contracts
- Footprint
- 6 sites · 3 continents
- Standards
- ISO 3691-4 · ISO 13849-1 · IEC 62443
**Reference scenario, not a recorded engagement.** Modelled on the shape of a real AMR manufacturer, but no customer was interviewed: the figures are properties of the model, not measured outcomes.
An export is out of date the second it leaves
Nothing here is a data problem in the abstract. It is a partner on a mezzanine in Singapore, fitting a part from a BOM that was exported three weeks ago.
The copy goes stale offline
A PDF pack and an XLSX BOM on a shared drive. The part was superseded last Tuesday; the file does not know that.
Every tool is updated separately
One revision means editing the PLM, the ERP, the BOM spreadsheet, re-issuing the certification pack and notifying the partners. Five places, by hand.
Sites diverge in silence
Nobody can answer “which sites are running the superseded gearbox?” without emailing three partners and waiting.
Design, certification and deployment on one graph
A part is never copied into a site's file — the site's deployment points at the part. Change the part, and every site referencing it knows.
The models behind the thread
Requirement → Part → Certification → Site
Down from a requirement to the sites running it, or up from a field intervention to the design decision behind it.
Parts, with the fleet total computed
Unit mass is entered once. The fleet column follows the quantity and the deployment.
| Part | Supplier | Qty / robot | Unit mass | Fleet mass | Access tag |
|---|---|---|---|---|---|
| Drive wheel assembly | Supplier A | ×4 | 4.10 kg | 11 480 kg | partner-emea |
| Climbing gearbox | Supplier B | ×2 | 6.40 kg | 8 960 kg | partner-emea |
| Battery pack | Supplier C | ×1 | 16.80 kg | 11 760 kg | core |
| Safety controller | Supplier B | ×1 | 0.84 kg | 588 kg | core |
| LiDAR module | Supplier D | ×2 | 0.62 kg | 1 736 kg | partner-apac |
ƒ Risk index = severity × probability — computed by Koddex, not typed by anyone.
One part, opened. The integrator sees exactly what the designer sees.
Safety controller
PRT-2214- Sub-assembly
- Safety chain · ASM-1400
- Supplier
- Supplier B
- Unit mass
- 0.84 kg
- Qty / robot
- 1
- Fleet mass
- 588 kgunit mass × fleet qty
- Standard
- ISO 13849-1
- Certification
- CERT-0091 · PL d
- Access tag
- core
What the graph computes for you
Swap a gearbox; the platform mass moves by itself.
The number a local authority asks for, derived from the parts — not assembled the week before the audit.
Which sites are behind, and on which parts. Visible, not discovered on a maintenance visit.
The tree the partner opens is the tree R&D edits
Every mass above a leaf is computed from the lines beneath it. One line is flagged superseded — and every site still referencing it is one click away, with no email round-trip.
| Assembly / part | Qty | Mass |
|---|---|---|
AMR platformAMR-SYS-001locked | 92.40 kg | |
Chassis & driveASM-1100locked | ×1 | 38.60 kg |
Drive wheel assemblyPRT-1142locked | ×4 | 4.10 kg |
Suspension armPRT-1156locked | ×4 | 1.85 kg |
Climbing moduleASM-1200in review | ×1 | 21.20 kg |
Climbing gearboxPRT-1231in review | ×2 | 6.40 kg |
Rail guidePRT-1248locked | ×4 | 1.10 kg |
EnergyASM-1300locked | ×1 | 18.90 kg |
Battery packPRT-1312locked | ×1 | 16.80 kg |
Charge contactsPRT-1327locked | ×2 | 0.55 kg |
Safety chainASM-1400locked | ×1 | 3.20 kg |
Safety controllerPRT-2214locked | ×1 | 0.84 kg |
LiDAR modulePRT-2231locked | ×2 | 0.62 kg |
Emergency stopPRT-2240superseded | ×2 | 0.18 kg |
Compute & commsASM-1500locked | ×1 | 10.50 kg |
Masses roll up from the leaves. This is not an export of the BOM — it is the BOM.
Six deployments, one baseline, and the drift is visible
Each site deployment references the same parts rather than holding a copy. Two sites are a revision behind — and that is on the screen, not in somebody's inbox.
| Site | Region | Fleet | Baseline | Operated by |
|---|---|---|---|---|
| SITE-04 | Europe | 128 robots | Rev 7 · current | Integrator partner A |
| SITE-07 | Europe | 64 robots | Rev 7 · current | In-house team |
| SITE-11 | North America | 210 robots | Rev 7 · current | Integrator partner B |
| SITE-14 | North America | 96 robots | Rev 6 · 1 behind | Integrator partner B |
| SITE-19 | Asia | 152 robots | Rev 7 · current | Integrator partner C |
| SITE-22 | Asia | 48 robots | Rev 6 · 1 behind | Integrator partner C |
Access tags decide what each partner sees: partner-emea reads the European sites and the parts they touch, and nothing else. Same graph, different windows onto it.
The distribution step is the cost, and it disappears
A revision is cheap to make and expensive to distribute: five tools to update, a pack to re-issue, three partners to notify, and a window during which every site is wrong.
Every double arrow is a synchronisation somebody maintains by hand.
| Five tools, stitched | One graph | |
|---|---|---|
| Getting the current BOM to a site | Export, email, and someone re-keys it locally | The site opens the live tree |
| Publishing a part revision | Update five tools, re-issue the pack, notify three partners | Revise once. There is no distribution step |
| Finding sites on a superseded part | Email each partner and wait for replies | Where-used on the part, immediately |
| Certification pack for a local audit | Assemble from the drive and hope it matches the as-built | Export the deployment with its children |
| Per revision | Days of distribution, multiplied by the number of sites | One revision. Nothing to distribute |
Reference scenario: the right column describes how the model behaves, the left is an order-of-magnitude estimate for a conventional tool chain. Neither is measured on a customer engagement.
The compounding part
A product that changes every few weeks pays the distribution cost every few weeks. Remove it once, it is gone every time.
A revision, not a campaign
Revise the part. Deployments reflect it, and the ones that cannot follow yet show as behind.
Nothing to reconcile
No second copy means no drift between what R&D believes and what the site installed.
The partner reads instead of asking
“Is this the latest?” stops being asked — and that is where the time actually goes.
One source of truth is not the same as everyone seeing everything
Partners are outside the company. Centralising only works if each reads exactly its scope, and what it writes back is attributable.
R&D ↔ integrator partners
They read the design. They write the field.
- Access tags scope a partner to its own sites and the parts those sites touch — partner-emea never sees the APAC deployments.
- Field interventions land on the same items, so an as-built discrepancy sits next to the design it contradicts.
- A partner cannot revise a design part. The boundary is a permission, not a convention nobody enforces.
Across internal teams
R&D, quality, supply and field service on one thread.
- A locked baseline stays locked; a change becomes a revision you can compare, not an overwrite nobody notices.
- Where-used answers “which sites, which suppliers, which certifications” before the change request is approved.
- Every change is attributed and timestamped on the item: the audit trail is a by-product of working, not a document to assemble.
Per partner, per site, per discipline.
Every reference, before you change anything.
Locked baselines, compared side by side.
Attributed, timestamped, on the item.
Masses and coverage nobody re-keys.
What changes for the partner on site
| Exports and shared drives | One graph | |
|---|---|---|
| The BOM a site works from | A copy, as old as its last export | The live tree, with computed masses |
| Publishing a revision | Five tools, one pack, three emails | Revise the part. That is the whole step |
| Sites on a superseded part | Ask the partners, wait days | Listed on the part itself |
| Baseline divergence | Discovered during a maintenance visit | A column in the site matrix |
| Certification pack per site | Reassembled by hand before each audit | Export the deployment with its children |
| What a partner can see | Whatever was in the folder someone shared | Its own scope, by access tag |
What this does not do
The interesting question is not what centralising fixes. It is what it does not.
A site with no connectivity still needs a pack. Koddex becomes the source it is generated from — current at the moment of export, traceable to a revision — but a basement with no signal still works from a file.
It does not replace your ERP. Part numbers, purchasing and stock stay where they are. Connecting the two is API or MCP work today, not a packaged connector.
The existing BOM has to come in once. A flat CSV imports directly; a nested legacy tree is better handled by having an agent write the import script than by fighting a spreadsheet importer.
Frequently asked questions
Do integrator partners get access to our whole design?
No. Access tags scope each partner to its own sites and their parts, and read is separate from write — a partner logs a field intervention without being able to revise a design part.
How does a site know it is behind?
The deployment references parts rather than copying them, so the gap to the current revision is a computed attribute — a column in the site matrix.
Does this replace our PLM?
It holds the BOM, the certifications and the deployment thread; CAD geometry and purchasing stay in the tools built for them. Most teams start with the layer nobody owns today: design ↔ certification ↔ what is actually installed.
Is this a real customer?
No — a reference scenario, modelled on the shape of an AMR manufacturer with integrator partners across three continents. The model, the BOM and the graph are real Koddex structures; the sites and figures illustrate them.