This article describes how Contoso Autowerks uses a Unified Namespace (UNS), captured formally in an CNCF xRegistry, to integrate its manufacturing systems.
Mind that this is a fictional example tro illustrate the concepts of a Unified Namespace and how CNCF xRegistry can be used to capture the metadata of the namespace.
At Contoso Autowerks East Plant, one continuous assembly line – Line 1 – carries the vehicle body from raw steel coil all the way through final tests. It’s organized into dedicated work cells, each performing a single phase of production:
-
Stamping Cell
- coilUnwinder (unwinds steel coil)
- press (stamps panels)
- transferRobot (moves blanks downstream)
- scanner (measures panel geometry)
-
Laser Cell
- laserCutter (precision cutting and welding of stamped panels)
-
Welding Cell
- weldRobot (spot‑ and seam‑welding)
- qualityCam (automated inspection of welds)
-
Painting Cell
- paintRobot (applies primer, base‑coat, clear‑coat)
-
Oven Curing Cell
- curingOven (bakes on paint layers)
-
Paint Inspection Cell
- inspectionScanner (checks paint film thickness)
-
Axle Assembly Cell
- axlePress (presses in axles)
- torqueTool (applies specified torque)
-
Bolt‑Tightening Cell
- torqueStation (tightens structural bolts)
-
Windshield Installation Cell
- glueApplicator (applies adhesive)
- windshieldRobot (sets and seals the windshield)
-
Wheel Assembly Cell
- wheelMountTool (mounts and torques wheels)
-
CAN‑Bus Test Cell
- canTester (runs ECU network diagnostics)
-
Roller Test Cell
- rollerRig (performs dynamometer runs)
-
Water Leak Test Cell
- leakRig (detects body leaks under water spray)
All machines, the MES and ERP publish and subscribe to a single MQTT broker namespace. Topics follow the plant hierarchy:
contoso/EastPlant/BodyShop/Line1/{cellName}/{assetID}/{messageID}
- Publishers (assets, MES, ERP) send events here.
- Subscribers (cell gateways, analytics, traceability) listen to relevant branches.
- Cell Gateway isolates each cell’s devices, subscribing to its assets and “part boundary” events (ingress/egress), then republishes them unchanged up to the line level.
This structure lets new machines or software simply “plug in” by using the agreed topic paths—no custom interfaces required.
Below, each cell’s message group, the events it emits, and real MQTT topic examples using our equipment names.
Message | Topic Path | When |
---|---|---|
coilFeedStatus | contoso/EastPlant/BodyShop/Line1/stampingCell/coilUnwinder/coilFeedStatus |
every 1 s: reports speed (m/min), tension (kN) |
pressCycle | …/stampingCell/press/pressCycle |
end of each press stroke (force kN, energy kJ, duration s) |
blankTransfer | …/stampingCell/transferRobot/blankTransfer |
when robot picks up blank (state, XYZ position) |
panelMeasurement | …/stampingCell/scanner/panelMeasurement |
after each geometric scan (mm dimensions, deviation) |
Message | Topic Path | When |
---|---|---|
laserProcess | contoso/EastPlant/BodyShop/Line1/laserCell/laserCutter/laserProcess |
at start/end of each cut/weld segment (mode, power, speed, result) |
Message | Topic Path | When |
---|---|---|
robotState | contoso/EastPlant/BodyShop/Line1/weldingCell/weldRobot/robotState |
on any state or mode change (AUTO, MANUAL, ERROR) |
weldProcess | …/weldingCell/weldRobot/weldProcess |
each spot weld (current kA, force kN, duration ms) |
weldQuality | …/weldingCell/qualityCam/weldQuality |
post‑inspection (qualityOK boolean, method) |
Message | Topic Path | When |
---|---|---|
paintRobotState | contoso/EastPlant/PaintShop/Line1/paintingCell/paintRobot/paintRobotState |
on robot status change (SPRAYING, CLEANING) |
paintProcess | …/paintingCell/paintRobot/paintProcess |
after each coat (coat type, flowRate, thickness) |
Message | Topic Path | When |
---|---|---|
ovenStatus | contoso/EastPlant/PaintShop/Line1/ovenCell/curingOven/ovenStatus |
every 5 s (zone temperatures °C, humidity, conveyor speed) |
Message | Topic Path | When |
---|---|---|
filmMeasurement | contoso/EastPlant/PaintShop/Line1/inspectionCell/inspectionScanner/filmMeasurement |
after spot checks (thickness µm) |
Message | Topic Path | When |
---|---|---|
stationState | contoso/EastPlant/FinalAssembly/Line1/axleCell/axlePress/stationState |
on cell state transitions (IDLE→ASSEMBLING→COMPLETE) |
pressProcess | …/axleCell/torqueTool/pressProcess |
each press/torque action (action, torque Nm) |
Message | Topic Path | When |
---|---|---|
boltTightening | contoso/EastPlant/FinalAssembly/Line1/boltTighteningCell/torqueStation/boltTightening |
after each batch of bolts (IDs, torques, angles) |
Message | Topic Path | When |
---|---|---|
stationState | contoso/EastPlant/FinalAssembly/Line1/windshieldCell/glueApplicator/stationState |
on glue start/end or error |
glueProcess | …/windshieldCell/glueApplicator/glueProcess |
after bead application (length m, continuity %) |
Message | Topic Path | When |
---|---|---|
wheelAssembly | contoso/EastPlant/FinalAssembly/Line1/wheelCell/wheelMountTool/wheelAssembly |
post‑mount (positions[], torques[]) |
Message | Topic Path | When |
---|---|---|
diagnosticReport | contoso/EastPlant/EOL/Line1/canBusTestCell/canTester/diagnosticReport |
after ECU network diagnostics |
Message | Topic Path | When |
---|---|---|
rollerTest | contoso/EastPlant/EOL/Line1/rollerTestCell/rollerRig/rollerTest |
post‑dynamometer run (maxSpeed km/h) |
Message | Topic Path | When |
---|---|---|
leakTest | contoso/EastPlant/EOL/Line1/waterLeakTestCell/leakRig/leakTest |
after water spray (pressure bar, leakDetected) |
-
Cell Assignment
- Topic:
contoso/EastPlant/BodyShop/Line1/stampingCell/assignment
- Event: MES → “Start workpiece WP‑1234 under order WO‑1005.”
- Topic:
-
Work Order Lifecycle
- Create (ERP):
contoso/EastPlant/BodyShop/WorkOrders/WO-1005/create
- Status (MES):
…/WorkOrders/WO-1005/status = "InProgress"
- Create (ERP):
-
Workpiece Progress
- Topic:
contoso/EastPlant/BodyShop/Line1/weldingCell/workpiece/WP-1234/progress
- Event: Welding Cell →
{ "stage":"SpotWeld","timestamp":"…" }
- Topic:
-
Part Boundaries
- Ingress:
…/stampingCell/transferRobot/partIngress
- Egress:
…/laserCell/laserCutter/partEgress
- Ingress:
By naming each cell by function (not sequence) and using unique asset IDs only where needed, Contoso’s UNS delivers crystal‑clear, real‑time visibility and full traceability—from raw coil to finished car—without unnecessary complexity.
To ensure consistency, discoverability and automated validation of every MQTT topic and payload, Contoso Autowerks captures its entire Unified Namespace in an xRegistry catalog. The example registry is a single JSON document - aligned to the CNCF xRegistry specification - that formally declares:
- Message Groups: each logical group of topics (e.g.
contoso.body.stamping
) with descriptions, protocol (MQTT/5.0) and references to the individual messages it contains. - Schemas: a JSON‑Schema draft‑07 definition for every payload (e.g.
PressCycleSchema
,WeldProcessSchema
), grouped underschemagroups
so developers and integrators know exactly which fields, types and units to expect. - Endpoints: abstract definitions for each cell gateway, asset device and enterprise system (MES, ERP, analytics), including usage (producer or consumer), protocol options and the message groups they publish or subscribe to.
-
Machine‑Readable Contract
- Every new robot, PLC gateway or software module imports the xRegistry document at startup. A small code library auto‑generates stub clients: MQTT topics, QoS settings and JSON serializers/deserializers. This eliminates manual ICDs and dramatically speeds up on‑boarding of new assets.
-
Central Governance & Versioning
- The registry lives in Git alongside PLC code and MES configurations.
Schema changes (e.g. adding a new property to
paintProcess
) trigger a Git pull-request review, ensuring all stakeholders agree on topic, payload and version. Rollout of a new schema version is coordinated with broker configuration, preserving backwards compatibility.
- The registry lives in Git alongside PLC code and MES configurations.
Schema changes (e.g. adding a new property to
-
Automated Validation
- At runtime, cell gateways validate every outgoing and incoming message against its declared JSON schema. Invalid payloads are rejected or flagged, preventing silent data corruption on the line. This enforces contract‑first design, reducing debugging time.
-
Self‑Documenting API
- The xRegistry file doubles as up‑to‑date documentation. Operations,
maintenance and quality teams use a simple web UI to browse message groups,
view examples of every topic path (e.g.
/stampingCell/press/pressCycle
) and inspect payload schemas. New engineers ramp up faster because there’s one source of truth.
- The xRegistry file doubles as up‑to‑date documentation. Operations,
maintenance and quality teams use a simple web UI to browse message groups,
view examples of every topic path (e.g.
-
Interoperability & Tooling
- Because xRegistry follows the CNCF spec, third‑party tools—such as HiveMQ’s registry explorer or custom validation scripts—integrate seamlessly. Contoso can also generate Postman collections or OpenAPI‑style docs from the same registry, providing standardized interfaces for ERP and analytics vendors.
- Reduced Integration Effort: New machines, analytics platforms or MES modules need only point to the registry—no bespoke interface contracts.
- Higher Data Quality: Automatic schema checks catch typos, missing fields or incorrect units (e.g. mistaking kW for W) before data ever reaches the historian or dashboards.
- Rapid Change Management: Versioned schemas in Git allow safe evolution of topics and payloads; rollbacks are trivial if a consumer breaks.
- Enterprise‑Wide Consistency: All teams—IT, OT, quality, maintenance—work from the same curated catalog, eliminating mismatch between documentation and reality.
By combining an ISA‑95‑aligned MQTT namespace with an xRegistry catalog, Contoso Autowerks achieves a truly governed, extensible and self‑documenting integration fabric. The result is faster deployments, fewer runtime errors and complete end‑to‑end visibility from raw material to finished vehicle.