Introductie tot Unified Namespace (UNS): Versnel Jouw Digitale Transformatie in Metaalbewerking

Dit artikel is ook beschikbaar in het Engels en Duits.

Weet je nog hoe de Smart Factory eruitzag in de folders? Alles verbonden. Dashboards aan de muur. AI die een storing voorspelt voordat hij er is. Operators met tablets in plaats van papier.

Misschien heb je erin geïnvesteerd. Een nieuw ERP. Een koppeling aan de laser. Een planningspakket. Een dashboard. Daarna een nieuwe machine, en daarmee een nieuwe koppeling.

En wat had je er uiteindelijk aan? Ik heb de afgelopen tien jaar veel metaalbedrijven van binnen gezien, en het antwoord is meestal hetzelfde: een bord spaghetti.

Hierover schreef ik eerder:

5 Principes van Elon Musk voor digitalisatie van metaalbedrijven

Na de terugkeer van de Starship-booster las ik de biografie van Elon Musk en zag hoe zijn denkwijze past op digitalisering in de metaalbewerking. Ik vertaal vij

vanenkhuizen.com

Dit artikel is de uitweg. Steeds meer metaalbedrijven vervangen de spaghetti door een Unified Namespace (UNS): een centrale, live plek waar alle fabrieksdata samenkomt, georganiseerd zoals het bedrijf is georganiseerd. Ik leg uit wat het is, waarom het anders is dan een database, wat een historian toevoegt, welke tools er een bevatten, en hoe je deze maand nog begint met een machine. Alles in gewone taal.

Zo groeit de spaghetti

Die wirwar kiest niemand bewust. Hij groeit stukje bij beetje, de ene logische beslissing na de andere, tot alles met elkaar verweven is. Ik heb het van binnenuit meegemaakt.

Het ERP werkt, tot zover goed. Dan komt er een planningspakket bij, want plannen in het ERP was omslachtig. Er komt een nieuwe machine, een ander merk, met eigen software, dus er gaat een nieuwe koppeling in. De laser praat met het ERP, maar ook direct met het planningssysteem, want de ERP-interface was niet goed genoeg. Van daaruit loopt een lijn naar een dashboard. XML hier, CSV daar, een API er tussenin.

Tel de leveranciers: vijf stuks, elk met consultants die hun eigen systeem snappen en naar elkaar wijzen als er iets stukgaat. Ondertussen typen jouw mensen dezelfde gegevens in drie schermen in. En dan staat er toch iemand naast dat alles met een Excel-sheet, want dat blad is de enige plek waar alles bij elkaar komt.

De wiskunde zegt dat dit nooit stabiel wordt. Tien systemen kunnen wel 45 aparte koppelingen nodig hebben, elk maatwerk, elk te breken bij de volgende software-update.

Dit is een belangrijke reden waarom digitaliseringsprojecten teleurstellen. McKinsey-onderzoek toont aan dat minder dan 30 procent van de digitale transformaties slaagt, en slechts 16 procent leidt tot blijvende verbetering. Een terugkerend patroon achter de mislukkingen: tools aangeschaft voordat de dataarchitectuur bestond om ze te verbinden.

Ondertussen stijgen de eisen alleen maar. Klanten die een pizza op de kaart volgen, verwachten een live antwoord op "waar is mijn bestelling". Elk AI-tool dat je gaat proberen is maar zo goed als de data die je het kunt voeren. En het EU Digital Product Passport vraagt straks om traceerbaarheid per onderdeel. Al dat heeft data nodig die actueel, gestructureerd en op een plek staat. Precies wat de spaghetti niet kan leveren.

De acht stappen die elk productiebedrijf doorloopt

Stap even weg van de systemen en kijk naar het werk zelf. Elk productiebedrijf, wat het ook maakt, doorloopt elke dag dezelfde acht stappen:

• Verkoop. Een offerte gaat eruit, een opdracht komt binnen. Je CRM en offertetools.
• Plan. Het ERP bepaalt wat er gemaakt moet worden, en wanneer.
• Productiebeheer. Een MES, of een whiteboard, vertaalt het plan naar werk op de vloer.
• Produceer. Machines draaien. Hun besturingen en sensoren weten precies wat er gebeurt.
• Magazijn. Materiaal in, eindproduct eruit. Het WMS houdt bij.
• Verzend. Het product verlaat het gebouw, met papieren.
• Factureer. De rekening volgt de zending.
• Afstemmen. De boekhouding bevestigt dat wat verkocht, gemaakt, verzonden en gefactureerd klopt.

Elke stap genereert data. Elke stap heeft data nodig van de andere stappen. En in de meeste bedrijven stroomt die data punt-tot-punt tussen systemen, of erger: op papier, overgetypt, met Excel er tussenin. Dat is de spaghetti, gezien van binnenuit.

Draai nu het beeld om. Dezelfde acht stappen, maar met een hub in het midden. Het ERP praat met de hub. De machines praten met de hub. Het planningssysteem praat met de hub. Niets praat direct met iets anders. Elk systeem gooit wat het weet in een gedeelde plek en haalt op wat het nodig heeft uit diezelfde plek.

Die hub, en de naamgevingsstructuur daarin, is de Unified Namespace.

Wat is een Unified Namespace?

Een Unified Namespace is een architectuur waarbij elk systeem in je bedrijf publiceert wat het doet, op het moment dat het gebeurt, naar een centrale plek, in een gedeelde structuur, en leest wat het nodig heeft uit diezelfde plek. Het is een ontwerpkeuze, zoals "client-server" een ontwerpkeuze is. Daarna kies je tools om het te bouwen.

Ik heb deze architectuur geleerd van Walker Reynolds, mijn mentor in industriële digitalisering. In zijn UNS Handbook vat hij samen wat een UNS is in vijf stellingen:

• De structuur van je bedrijf en al zijn gebeurtenissen.
• Een enkele bron van waarheid voor alle data en informatie van het bedrijf.
• De plek waar de huidige toestand van het bedrijf zich bevindt.
• De hub waarmee de slimme dingen in je bedrijf met elkaar communiceren.
• De architectonische basis van je Industry 4.0- en digitaliseringsinitiatieven.

Achter die stellingen zitten een paar kenmerken, en elk heeft een concrete betekenis voor jouw bedrijf:

• Agnostisch. Het maakt niet uit welke machines je hebt of welk ERP je aanhoudt. Elk merk kan aansluiten.
• Edge-gedreven. Data wordt gepubliceerd waar hij ontstaat, bij de machine, in plaats van door een centraal systeem te worden opgehaald.
• Melden bij uitzondering. Systemen spreken alleen als er iets verandert en blijven stil als dat niet zo is.
• Lichtgewicht. De berichten zijn klein en eenvoudig, zodat gewone hardware en netwerken ze moeiteloos dragen.
• Open architectuur. Het draait op open standaarden, zodat aansluiten nooit toestemming van een leverancier vereist.
• Volledig stack. Een structuur dekt alles, van de sensor in de machine tot de software in de cloud.
• Georganiseerd als het bedrijf. De databoom spiegelt jouw bedrijf, zodat iedereen alles kan vinden.

Agnostisch is het dragende woord. Een UNS hangt niet af van een product of technologie, en dat is wat er een fundament van maakt in plaats van nog een leveranciersbeslissing. Walker's video-uitleg is wat ik stuur aan iedereen die het vraagt:

Adoptie ondersteunt de architectuur: Deloitte's smart manufacturing-onderzoek van 2025 stelt dat 54 procent van de fabrikanten een uniform datamodelstandaard adopteert.

Is het een product? Is het een database?

Twee vragen komen in elke presentatie terug, dus ik beantwoord ze hier meteen.

"Waar koop ik er dan een?" Dat doe je niet. Een UNS is iets wat je op bouwt, zoals een huis op een tekening van een architect. De tekening bepaalt waar de muren en leidingen komen. Welke stenen je gebruikt is een aparte keuze, en je kunt halverwege van steenleverancier wisselen zonder een muur te verzetten. In een UNS zijn de broker, de connectoren en de databases de stenen. De naamgevingsstructuur en de een-verbinding-regel zijn de tekening.

"Is het dan een database?" Ook niet, en dit onderscheid telt. Een database is gebouwd voor vragen achteraf. "Geef me de bestellingen van vorige week." Je vraagt, hij antwoordt. Een UNS is gebeurtenisgedreven: hij vertelt je wat er gebeurt, op het moment dat het gebeurt. Machine start: gebeurtenis. Opdracht binnenkomt: gebeurtenis. Status verandert: gebeurtenis. Een live stroom van de huidige toestand van je fabriek.

Je kunt nog steeds opzoeken. De namespace bevat de laatst bekende toestand van alles (een retained message, in MQTT-termen), zodat een systeem dat om 09:00 verbindt meteen de toestand van de hele fabriek kent. En voor de volledige geschiedenis hang je een historian aan, die hieronder zijn eigen hoofdstuk krijgt, want het verandert wie jouw data bezit.

Hub en spaak: elk systeem wordt een knooppunt

Een UNS volgt een hub-en-spaak-model. Een hub in het midden, en elk systeem als spaak eraan verbonden. Niets verbindt direct met iets anders.

In de praktijk is de hub een message broker, een klein stuk software dat berichten ontvangt en doorgeeft aan wie zich heeft aangemeld. Hij spreekt meestal MQTT, een lichtgewicht publish-subscribe-protocol dat hier precies voor is gebouwd. Elk systeem rondom de hub is een knooppunt: je ERP, je CAM-software, je machines, je dashboards, je toekomstige AI-agenten. Elk knooppunt publiceert wat het weet en abonneert op wat het nodig heeft.

Het werkt zoals het internet werkt. Apparaten van elke leverancier communiceren omdat ze het eens zijn over een protocol en een adresseringsschema, en geen enkele leverancier bezit het midden. In jouw fabriek is het adresseringsschema de namespace: een boom van onderwerpen georganiseerd als jouw bedrijf.

"Georganiseerd als jouw bedrijf" heeft een standaard achter zich: ISA-95, een eenvoudige naamgevingsconventie voor de niveaus van een fabriek. De gangbare boom loopt enterprise / site / area / line / cell.

Een onderwerp als metalworks/utrecht/laser-cutting/line-1/trulaser-5030/status vertelt iedereen, mens of software, precies waar in het gebouw die data leeft: bedrijf, vestiging, afdeling, lijn, machine.

En over de namen: die kies jij zelf, in je eigen taal als je wilt. Ze overleven elk tool dat je ooit gaat kopen.

Let op wat er met het ERP in dit beeld is gebeurd: het werd een knooppunt tussen de andere.

Why ERP No Longer Needs to Be the Center of Your Factory

Hoe een slimme structuur helderheid terugbrengt zonder je hele systeem te vervangen.

vanenkhuizen.com

Liever luisteren? Brian Pribe en ik gingen dieper in op het in de praktijk brengen van een UNS voor kleinere fabrikanten:

Waar de UNS zit in de automatiseringsstack

Automatiseringsingenieurs beschrijven een fabriek in niveaus, het Purdue-model:

• Niveau 0: sensoren en actuatoren, de fysica.
• Niveau 1: de PLC's en controllers die ze aansturen.
• Niveau 2: SCADA en HMI, de schermen waarmee het proces wordt bediend.
• Niveau 3: MES en operaties, de productiedag aansturen.
• Niveau 4: ERP en bedrijfssystemen, het bedrijf runnen.
• Niveau 5: cloud, BI en analyses.

Traditioneel klimt data die niveaus één interface tegelijk op en verliest bij elke stap aan versheid. De UNS loopt over dat alles heen, volledig stack: een sensor op niveau 0 en een dashboard op niveau 5 publiceren en abonneren op dezelfde namespace, op hetzelfde moment.

Waarom gebeurtenisgedreven beter is dan pollen en batch

Gebeurtenisgedreven betekent dat een systeem een bericht stuurt op het moment dat er iets verandert, en verder stil blijft. Dat klinkt als een technische bijzaak. Het is het hart van de hele architectuur, want de twee alternatieven zijn wat je vandaag mee leeft.

• Pollen is elke machine steeds vragen: "iets nieuws?" De meeste antwoorden zijn "nee", dus het meeste verkeer is verspilling, en wat er tussen twee polls gebeurt blijft onzichtbaar.
• Batch is de nachtelijke sync, de CSV-export, het maandagoverzicht. Tegen de tijd dat de data binnenkomt is het moment om er iets mee te doen voorbij. Je maandagoverzicht beschrijft een fabriek die niet meer bestaat.

Een UNS vervangt beide met de twee principes die je al tegenkwam: melden bij uitzondering, knooppunten publiceren als er iets verandert, en edge-verwerking, de machine of een kleine gateway ernaast filtert zijn eigen ruwe data en publiceert alleen wat betekenis heeft, zodat de namespace schoon en licht blijft.

Voor het metaalverwerkende geval hebben Wim Dijkgraaf en ik een heel podcast-aflevering besteed aan waarom gebeurtenisgedreven plus UNS beter is dan je smart factory bouwen rond het ERP.

Hoe een UNS in de praktijk werkt

Elke databron publiceert zijn gebeurtenissen in de namespace. Elk systeem dat informatie nodig heeft, abonneert op precies de takken die het bezighoudt. Niets pollt, niets batcht, niets wacht op de nachtelijke sync.

De onderwerpboom spiegelt je fabriek. Een echte ziet er zo uit:

metalworks/utrecht/laser-cutting/line-1/trulaser-5030/status
metalworks/utrecht/laser-cutting/line-1/trulaser-5030/job/current
metalworks/utrecht/bending/line-2/pressbrake-1/parameters/angle
metalworks/utrecht/quality/measurements/batch-456
metalworks/orders/incoming

En een enkele gebeurtenis is gewoon een klein, leesbaar bericht. Als de laser een nest klaar heeft, publiceert hij iets als:

{
  "topic": "metalworks/utrecht/laser-cutting/line-1/trulaser-5030/job/current",
  "state": "finished",
  "nest": "N-2207",
  "sheets": 14,
  "runtime_min": 43
}

Het dashboard toont het diezelfde seconde. Het planningssysteem past het schema aan. Het kwaliteitssysteem controleert of dit nest inspectie nodig heeft. Geen van die systemen weet van de andere. Ze kennen alleen de namespace.

Die laatste zin is de opbrengst. De volgende tool die je toevoegt, wat het ook is, vraagt om een verbinding: met de namespace. Vervang je ERP over vijf jaar en de machines merken het niet.

De historian: het geheugen van je fabriek, buiten het ERP

Een soort knooppunt verdient een eigen hoofdstuk, want het bepaalt wie de geschiedenis van jouw fabriek bezit.

Een historian is een systeem dat meeluistert op de namespace en alles wegschrijft, met tijdstempels. Metingen in de tijd: temperatuur, snijsnelheid, druk, elke seconde als je wilt. Maar ook orderdata, laatste toestanden, en wie wat wanneer heeft gewijzigd. De vraag waarvoor hij bestaat klinkt simpel: wat is er om 14:32 gebeurd?

Als dat geheugen er eenmaal is, begint het te renderen. Analyse: hoe lang duurt een kantslag echt, per materiaal? Process mining: waar wachten orders werkelijk? AI: patronen in maanden machinedata die geen mens zou gaan zitten zoeken.

Hier is het deel dat ik elke eigenaar wil laten horen. Die historian staat buiten je ERP. Jouw tabellen, jouw kolomnamen, jouw keuzes over wat je bewaart en hoe lang. Geen leverancier die je datastructuur voorschrijft. Hij draait op gespecialiseerde tijdreeksdatabases die hier razendsnel in zijn, op hardware in je eigen gebouw. Jouw data, lokaal, onder jouw eigen controle.

En het werkt ook andersom. Je hebt het eigen monitoringpakket van de machineleverancier vaak helemaal niet nodig. Moderne machines spreken open protocollen (OPC UA, MQTT), dus je kunt ze direct uitlezen en de data zelf opslaan. De TRUMPF-laser, de Bystronic-pers, de lasrobot: allemaal in dezelfde hub, een structuur, een scherm. Vergelijk dat met drie leveranciersdashboards die niet met elkaar praten.

Zelf een historian bouwen is precies les 5 van mijn ledenbouwreeks: Opslaan: je eerste historian.

Wat je met een Unified Namespace kunt doen

Deze mogelijkheden versterken elkaar. Betere meting voedt betere analyse, die de signalen scherper maakt. En omdat alles een structuur deelt, is elke verbetering direct beschikbaar voor elk systeem. Dit is ook het fundament waarop een MES staat, een laag die ik behandel in mijn complete MES-gids voor de metaalverwerking.

Is dit realistisch voor een gewone metaalwerkplaats? Denis en ik namen een praktijkcasestudy op van een UNS bij een Nederlands lasbedrijf, opgezet in een enkele dag. Kleine bedrijven doen dit.

UNS-platformen en tools: een eerste blik

Je koopt geen UNS, je stelt er een samen, en de onderdelen zijn goed geworden. De korte versie van wie waar speelt:

• UMH Core (open source): de hele UNS in een container, een ingebedde Kafka-compatibele broker plus bruggen voor meer dan 50 machineprotocollen. De documentatie leest als een cursus.
• Ignition: het industriële platform waarop veel systeemintegratoren een UNS bouwen.
• HighByte: industriele DataOps-software, wat betekent dat het je data modelleert en tussen systemen verplaatst met de context erbij. Thuis bij data-gedreven bedrijven.
• HiveMQ: een MQTT-broker gebouwd voor enterprise-schaal, met sterke ISA-95- en Sparkplug-tooling.
• EMQX: een andere zwaargewicht MQTT-broker, gebouwd voor serieuze berichtvolumes.
• Mosquitto (open source): een kleine broker die op alles draait. De standaardkeuze voor een pilot in een kleinere werkplaats.
• Node-RED: de lijm. Een visuele tool voor het verplaatsen en transformeren van berichten tussen al het bovenstaande.

Elk verdient een goede evaluatie op basis van de omvang en vaardigheden van je bedrijf, meer dan een introductie kan bevatten. Welke bij jouw werkplaats past, beantwoordt mijn toolingvergelijking voor leden, met dezelfde namespace gebouwd in verschillende tools, naast elkaar.

Wat AI verandert voor de Unified Namespace

Toen ik begon te schrijven over de UNS eindigde het verhaal bij dashboards: zie je fabriek live. Sinds 2024 is het verhaal verschoven, want AI is verschoven.

Een AI-agent, een programma dat een taalmodel gebruikt om te observeren, te beslissen en te handelen, kan alleen werken op data die het kan vinden en vertrouwen. Geef het dertig losgekoppelde systemen en elk AI-project begint met een data-opruimproject. Geef het een gecontextualiseerde, realtime namespace en het heeft wat het nodig heeft op dag een. Walker maakte dit punt in zijn lezing over waarom de UNS het essentiële fundament is voor industriele AI en agentische operaties, en Capgemini bereikte dezelfde conclusie in zijn eigen onderzoek: de UNS is het schaalbare fundament voor AI.

De loodgieterswerk hiervoor komt snel aan. MCP (Model Context Protocol, een standaard waarmee AI-modellen verbinding kunnen maken met tools en databronnen) is de industriele stack binnengekomen: Litmus heeft nu een MCP-server waarmee een taalmodel direct live fabrieksdata kan opvragen.

Mijn werkmodel hiervoor is 10-80-10: jij geeft de richting, agenten doen het lopende werk, jij keurt goed wat er toe doet. Dat is een verhaal voor een ander artikel. Hier is de conclusie simpel: de namespace maakt je fabriek leesbaar voor AI.

Begin met een machine

Je hebt geen stuurgroep nodig om dit te testen, en je hebt zeker geen meerjarig transformatieprogramma nodig dat een rapport voor de plank oplevert. Ik noem het alternatief een lighthouseproject: een bewijs in weken. Zet de hub op, verbind een machine, bouw een dashboard. Laat iedereen het zien, en besluit dan de volgende stap op basis van wat je leerde.

Denk aan een speedboot, en laat de olietanker volgen: de pilot draait naast je bestaande systemen en raakt niets aan. Stap een is uitzoeken hoe jouw machine communiceert, en dat is precies waar de ledenbouw begint:

Vragen die ik krijg over de Unified Namespace

Meer leren: de UNS-boekenplank

Alles hierboven is genoeg om de architectuur te begrijpen en een pilot te starten. Als je dieper wilt gaan, is dit de plank waar ik mensen naar wijs:

• Walker Reynolds' UNS Handbook. De schriftelijke definitie van de bron, op LinkedIn.
• Walker op video. De originele What is the Unified Namespace?-uitleg, de volledige UNS Masterclass, en Unified Namespace and Historians.
• HiveMQ's UNS Essentials. Een gratis, cursusachtige introductiereeks van het MQTT-brokerebedrijf.
• United Manufacturing Hub. Hun kernartikel, de UNS basics-videoreeks, en de open-source code zelf.
• De standaarden. mqtt.org voor het protocol, de OPC Foundation voor OPC UA, en Corso Systems' toegankelijke ISA-95 101.
• Gebeurtenisgedreven denken. FlowFuse's uitleg van gebeurtenisgedreven architectuur in de maakindustrie.
• Mijn podcastafleveringen. Gebeurtenisgedreven architectuur en UNS met Wim Dijkgraaf, een UNS realiseren met Brian Pribe, en een praktijkcasestudy van een implementatie.

De kern

Je fabriek produceert de data al. Een Unified Namespace is de keuze om die eenmalig te organiseren, in een live structuur die jij bezit, zodat elk huidig systeem en elk toekomstig systeem er gebruik van kan maken. De architectuur is bewezen, de tools zijn open, en de kleinste bruikbare versie past in een pilot van weken.

Hier is de gedachte waarmee ik mijn presentaties afsluit. ERP werd de standaard in een tijd dat je geen software zelf kon bouwen, en toen was het het juiste antwoord. Vandaag kun je wel bouwen. Dus de vraag verandert, van "welk pakket lost mijn probleem op" naar "welk fundament laat me de rest zelf bouwen". De UNS is dat fundament.

Als je klaar bent om de jouwe te ontwerpen, staat de volledige methode in de ledenbibliotheek, gratis te joinen. De ontwerphulp leidt je door het modelleren van je fabriek op papier, daarna het bouwen een machine tegelijk, met het invulsjabloon:

Design your Unified Namespace

Een stapsgewijze UNS-ontwerphulp voor metaalbedrijven: de ISA-95-structuur, de drie datarollen, je eerste machines en het invulsjabloon. Gratis voor leden.

vanenkhuizen.com

De rest van de bouwreeks en de toolingvergelijking staan in de ledenbibliotheek. En als je een tweede paar ogen wilt op je architectuur voordat je je vastlegt, is dat waarvoor mijn diensten zijn.

Wat wil jij als eerste op een live scherm zien: ordervoortgang, machinestatus of werkelijke opdrachtkosten? Laat het weten, ik lees elke reactie.

Dankwoord. Deze inzichten bouwen voort op het werk van Walker Reynolds, mijn mentor in industriele digitalisering, het team van United Manufacturing Hub, en mijn Smart Metals Podcast-cohost Denis Gontcharov, die dit concept allemaal tastbaar hebben gemaakt voor de metaalverwerking.

Hierover schreef ik eerder:

A en B-klasse oplossingen

Binnen CAM-software verschillen nestingprogramma's en kantprogramma's flink van elkaar. Ik leg het verschil uit tussen A- en B-klasse oplossingen: de een gaat d

vanenkhuizen.com