In machine and plant building, hardly any two projects look alike. Custom machines and customer-specific plants often get built as one-off units or in small batches. They move through engineering, procurement, manufacturing, assembly, and commissioning over the course of months. The customer order is the central organizational unit that every process revolves around. This article looks at the internal system integration of machine and plant builders, not connectivity as a product feature of the delivered machine. It uses industry-specific use cases to show what a Unified Namespace (UNS), digital twins, and AI can do in machine building. Together, they create transparency, speed up processes, and improve collaboration between engineering, production, and business systems. For the technical fundamentals of a UNS itself, see What Is the Unified Namespace (UNS)?
Unified Namespace Requirements in Machine Building
ERP systems manage customer orders, and PLM systems manage the engineering baseline. Both have existed in practically every machine-building shop for a long time. A Unified Namespace in machine building doesn’t replace these systems. Instead, it links their data in real time with actual assembly progress and acceptance results. That replaces pulling everything together manually from paper drawings and spreadsheets after the project closes. The following drivers determine how this data needs to be modeled.
Conceptual and Regulatory Drivers: the Machinery Regulation, One-Off Production, and Long Service Horizons
The Machinery Regulation (EU) 2023/1230 takes effect in January 2027, replacing the previous Machinery Directive 2006/42/EC. It requires that technical documentation stay available for at least ten years after the machine goes to market. That documentation has to reflect how the machine was actually built, not how it was originally planned. That’s exactly where the industry’s typical risk shows up. During assembly, the real machine almost always drifts from the engineering baseline, whether through component substitutions during supply delays or last-minute customer requests. In practice, these deviations often end up as nothing more than a handwritten correction on a paper drawing.
On top of that comes a time horizon none of the other industries in this series deal with. Machines stay in the field for 15 to 30 years. The as-built record has to remain usable long after the build project itself has closed.
What Makes One-Off Production Technically Different
In series production, you design a data model once and reuse it for thousands of identical units. In machine building, every customer order is potentially one of a kind. Even so, many machines get built on the same reusable subassemblies, a particular servo axis module, say, or a standard safety enclosure. These subassemblies show up across many different machines, even when the overall machine is different every time. A Unified Namespace has to represent both the unique customer order and the recurring subassemblies at the same time.
Machine-Building-Specific Topic Structure
In a Unified Namespace in machine building, the physical hierarchy stays stable: plant, assembly hall, assembly bay, measurement. It doesn’t change with whichever order is currently being assembled there. This follows the same ISA-95 principles as in MQTT Topic Namespace Best Practices. What’s industry-specific here is that the customer order number gets carried as a foreign key through every phase. That runs from release all the way to a spare-parts request years later.
Typical topic hierarchy, independent of the customer order:
amthausen/assembly-hall2/bay-07/environment/temperature/actualamthausen/assembly-hall2/bay-07/environment/temperature/status
Order and acceptance events, on the other hand, get their own one-off topics:
amthausen/order/KA-2026-0442/order-master-recordamthausen/order/KA-2026-0442/as-built-deviation/DEV-2026-0031
This data model has three industry-specific properties:
- Environmental telemetry from the assembly hall stays independent of the order. A sensor publishes continuously on a fixed topic, with no order number in the path.
- The order master record and as-built deviations get their own topics, because each one is an individually auditable record under the Machinery Regulation.
- Reused subassemblies, like the servo axis module, carry their own module ID alongside the order number. That keeps patterns analyzable across multiple orders, without losing the uniqueness of the overall order.
The following use cases trace this structure through one continuous example: the Amthausen plant, customer order KA-2026-0442, custom machine SM-207.
UNS Use Cases in Machine Building
The following use cases show how a Unified Namespace in machine building pays off in practice. They range from the order master record to AI-driven insights and digital twins.
Order Master Record with Milestone and Phase Status
The Unified Namespace tracks the current phase status for every customer order: engineering released, procurement complete, assembly in progress, FAT scheduled. Instead of chasing that status down through multiple departments, it’s available as a single, current record.
Topic: amthausen/order/KA-2026-0442/order-master-record
JSON Payload:
{
"orderId": "KA-2026-0442",
"machineDesignation": "SM-207",
"customer": "customer-ref-4471",
"currentPhase": "assembly_in_progress",
"milestones": [
{
"milestone": "engineering_released",
"completedAt": "2026-05-12T00:00:00Z"
},
{
"milestone": "procurement_complete",
"completedAt": "2026-06-30T00:00:00Z"
}
],
"fatScheduledDate": "2026-08-20",
"productionSite": "plant-amthausen",
"timestamp": "2026-07-18T08:00:00Z"
}
As-Built vs. As-Designed Reconciliation
An installed component sometimes deviates from the original engineering baseline. When that happens, the Unified Namespace captures the deviation right at the point of assembly, in structured form. That replaces a red-pen correction on a paper drawing. Formal approval of the deviation still belongs to the engineering change process, especially when it’s safety-relevant and needs reassessment under the Machinery Regulation. The UNS delivers the structured record, not the approval decision.
Topic: amthausen/order/KA-2026-0442/as-built-deviation/DEV-2026-0031
JSON Payload:
{
"deviationId": "DEV-2026-0031",
"orderId": "KA-2026-0442",
"position": "servo-axis-x1",
"designedPartNumber": "SRV-4200-A",
"asBuiltPartNumber": "SRV-4200-B",
"reason": "supplier_lead_time_delay",
"safetyRelevant": false,
"engineeringChangeStatus": "pending_ecr_approval",
"reportedBy": "assembly-technician-14",
"timestamp": "2026-07-18T10:30:00Z"
}
FAT Data Capture and Acceptance Evidence per Machine
Test rigs and data loggers already capture readings locally during the Factory Acceptance Test. The Unified Namespace additionally links those readings directly to the customer order number and the as-built configuration. That replaces filing them away as an isolated PDF report. That keeps the acceptance record findable and tied to the exact machine configuration, even years later.
Topic: amthausen/order/KA-2026-0442/fat/FAT-2026-0820
JSON Payload:
{
"fatId": "FAT-2026-0820",
"orderId": "KA-2026-0442",
"testResults": [
{
"parameter": "cycle_time_s",
"measuredValue": 12.4,
"specLimit": 13.0,
"result": "pass"
},
{
"parameter": "positioning_accuracy_mm",
"measuredValue": 0.02,
"specLimit": 0.05,
"result": "pass"
}
],
"overallResult": "accepted",
"customerRepresentativePresent": true,
"timestamp": "2026-08-20T15:00:00Z"
}
Long-Term Spare Parts Requests from the As-Built Archive
When a customer requests a spare part years after delivery, the Unified Namespace resolves that request against the archived as-built record. It doesn’t use the original nominal bill of materials. That prevents a component swapped during assembly from resulting in the wrong part getting shipped.
Topic: amthausen/order/KA-2026-0442/spare-parts-request/SP-2036-0004
JSON Payload:
{
"requestId": "SP-2036-0004",
"orderId": "KA-2026-0442",
"position": "servo-axis-x1",
"resolvedAgainstAsBuilt": true,
"resolvedPartNumber": "SRV-4200-B",
"nominalPartNumber": "SRV-4200-A",
"documentationRetentionCompliant": true,
"timestamp": "2036-03-14T09:00:00Z"
}
AI Use Cases in Machine Building
AI use cases for a Unified Namespace in machine building only deliver value in one situation. Order, procurement, and subassembly data need to be linked together first — generic anomaly detection alone isn’t enough.
Delay Risk for Long-Lead-Time Components
ERP systems already track order due dates today. A model additionally correlates supplier-specific history across multiple orders, to catch elevated delay risk earlier than a simple due-date comparison would. The order itself stays procurement’s call. The model only prioritizes which orders should get followed up on first.
Topic: amthausen/ai/delay-risk/KA-2026-0442
JSON Payload:
{
"orderId": "KA-2026-0442",
"model": "delay-risk-v1.2",
"componentPartNumber": "SRV-4200-A",
"supplierId": "supplier-ref-118",
"contractualDeliveryDate": "2026-06-15",
"predictedDelayRiskScore": 0.62,
"riskLevel": "elevated",
"contributingFactors": [
{
"factor": "supplier_on_time_rate_last_12mo_percent",
"value": 71
}
],
"recommendation": "escalate_with_procurement",
"timestamp": "2026-05-20T00:00:00Z"
}
FAT Deviation Prediction from Subassembly History
With one-off production, there’s often no large enough population of similar complete machines to make a prediction reliable. A model correlates at the level of reused subassemblies instead. A particular servo axis module might show a cluster of FAT deviations across several different machines. That pattern becomes visible before the actual test even runs. The FAT result itself stays the authoritative record.
Topic: amthausen/ai/fat-deviation-risk/KA-2026-0442
JSON Payload:
{
"orderId": "KA-2026-0442",
"model": "assembly-defect-risk-v1.0",
"assemblyModuleId": "servo-axis-module-x1",
"moduleOccurrencesLast12mo": 14,
"historicalFatDeviationRatePercent": 21,
"predictedDeviationRiskScore": 0.34,
"riskLevel": "moderate",
"replacesFatInspection": false,
"recommendation": "additional_pre_fat_check",
"timestamp": "2026-08-10T00:00:00Z"
}
Digital Twin in Machine Building
The digital twin in machine building’s Unified Namespace becomes especially valuable once it integrates actual assembly history and subassembly configuration alongside project data.
Assembly and Build Sequence Twin
Critical-path scheduling has been standard practice in project planning for decades. The twin in the UNS goes further. It calibrates the simulation against real, historical milestone timestamps from past orders in the UNS itself, instead of relying on generic planning figures. That validates a more realistic build sequence before a delivery date ever gets committed to.
Topic: amthausen/twin/build-sequence/simulation
JSON Payload:
{
"simulationId": "SIM-SCHEDULE-2026071801",
"orderId": "KA-2026-0442",
"scenario": "delivery_date_commitment_test",
"calibratedAgainstHistoricalMilestones": true,
"comparableOrdersUsed": 9,
"predictedAssemblyDurationDays": 34,
"requestedDeliveryDate": "2026-08-15",
"predictedCompletionDate": "2026-08-22",
"result": "delivery_date_at_risk",
"timestamp": "2026-05-15T00:00:00Z"
}
Virtual Commissioning Before FAT
Virtual commissioning is already established practice in machine building, testing control logic against a mechanical model. The twin in the UNS goes further. It calibrates itself against the actual as-built configuration, instead of the original planning baseline. That validates the control logic against the machine as it was actually assembled, before the physical FAT even begins.
Topic: amthausen/order/KA-2026-0442/twin/commissioning/simulation
JSON Payload:
{
"simulationId": "SIM-COMMISSIONING-2026071802",
"orderId": "KA-2026-0442",
"scenario": "control_logic_pre_fat_validation",
"calibratedAgainstAsBuiltConfig": true,
"asBuiltDeviationsIncluded": [
"DEV-2026-0031"
],
"predictedCycleTimeS": 12.6,
"specLimitS": 13.0,
"result": "sufficient",
"recommendedForFat": true,
"timestamp": "2026-08-05T00:00:00Z"
}
Best Practices for UNS Adoption in Machine Building
Do
- Link the customer order number through every phase end to end. Only that keeps a machine traceable from release to a spare-parts request years later.
- Capture as-built deviations in structured form at the point of assembly. Don’t leave them as a red-pen correction on a paper drawing that rarely makes it back into the engineering system.
- Link the FAT result to the technical documentation required under the Machinery Regulation. Only that keeps the acceptance record findable across the legal retention period.
- Carry subassembly IDs alongside the order number: this enables pattern analysis across reused modules, even when every complete machine is one of a kind.
Avoid
- Documenting as-built changes only as a handwritten correction on the paper drawing. This often gets lost by the time a service visit happens years later.
- Leaving FAT data only at the local test rig: makes linking it to order and as-built data harder for later audits.
- Processing spare-parts requests without reference to the as-built configuration: leads to incorrectly shipped parts whenever the machine deviates from the nominal bill of materials.
Conclusion
A Unified Namespace in machine building is more than a generic manufacturing architecture with a machine-building label slapped on. Customer order, as-built configuration, and FAT result are separate data objects that shape the topic structure from the ground up. That happens across a time horizon measured in decades. Three key takeaways:
- The customer order replaces the batch as the traceability unit. In one-off production, the order itself is the unique item, not a repeated production unit.
- AI and digital twins need context. Their value only emerges from linking order, procurement, and subassembly data. They never replace the engineering change process or the physical FAT.
- Regulation is an architecture driver, not a compliance afterthought. The Machinery Regulation determines which data must exist, for how long, and at what level of accuracy. That reach extends well beyond the build project itself.
Building these industry-specific requirements into the topic structure from day one avoids costly rework later. It also leaves you ready to build AI and digital-twin use cases directly on a solid data foundation.
