Het digitale landschap in je productiebedrijf groeide waarschijnlijk stap voor stap. Je begon met een financieel pakket voor de administratie en een ERP voor verkoop en productie. Later volgden CAD/CAM voor engineering, een MES voor productie-inzicht en dashboards voor machinedata.
Het resultaat: een complex web van 1-op-1 (point-to-point) koppelingen. Elk systeem is rechtstreeks verbonden met andere systemen die data nodig hebben. Hierdoor worden overzicht, controle en onderhoud steeds moeilijker.
Wil je dit web van koppelingen doorbreken en data uniform én real-time beschikbaar maken voor alle systemen? Dan biedt een Unified Namespace (UNS) in combinatie met een event-driven architectuur de structurele oplossing. Dit vraagt om afspraken over datastructuur en naamgeving, maar voorkomt dat het aantal koppelingen onbeheersbaar groeit en maakt data eenvoudiger bruikbaar voor alle systemen. Er ontstaat één consistente en schaalbare datalaag waarin alle systemen real-time toegang hebben tot dezelfde informatie.
In dit blog leggen we uit wat een UNS is en hoe een event-driven architectuur werkt. Je leest over het verschil tussen werken zonder UNS, met UNS in een request-response-model en met UNS in een event-driven architectuur.
Het traditionele web van koppelingen
Wanneer het digitale landschap in je productiebedrijf stap voor stap groeide, groeide hoogstwaarschijnlijk ook het aantal point-to-point (1-op-1) koppelingen. Elk nieuw systeem voegde extra koppelingen toe met andere systemen die data nodig hebben. Het IT-landschap is complex, foutgevoelig en moeilijk schaalbaar geworden:
- Data staat verspreid over meerdere systemen
- Definities en betekenis van data verschillen per systeem
- Real-time inzicht is niet vanzelfsprekend
- Historische data is versnipperd
- Elke wijziging of toevoeging vereist vaak meerdere aanpassingen
Het vergt veel kennis van elke koppeling en goed onderhoud om overzicht en controle te behouden. Na verloop van tijd is vaak niet meer precies bekend welke koppelingen er bestaan en gaat kennis verloren bij bijvoorbeeld personeelswisselingen. Én het is lastiger om een consistente operationele werkelijkheid te creëren, waardoor analyses, rapportages en stuurinformatie minder betrouwbaar zijn.
Wat is een Unified Namespace (UNS)?
In een UNS spreek je bedrijfsbreed af hoe je data organiseert en benoemt. Dit zorgt ervoor dat alle systemen in je productiebedrijf dezelfde “datataal” spreken en dezelfde informatie op dezelfde manier interpreteren, zonder dat je de systemen intern hoeft aan te passen.
Belangrijkste kenmerken:
- Uniforme structuur: Iedereen weet waar data hoort en hoe deze wordt genoemd.
- Genormaliseerde data: Als data dezelfde naam heeft, betekent die naam overal hetzelfde. Bijvoorbeeld: elektrisch energieverbruik wordt overal in kWh uitgedrukt. De betekenis van de data staat eenduidig vast.
- Systeemonafhankelijk: Systemen kunnen hun eigen interne taal behouden; de UNS maakt de data voor iedereen begrijpelijk.
Door deze afspraken ontstaan minder interpretatieverschillen en kan data op een consistente manier gebruikt worden. Zo wordt het makkelijker om data bedrijfsbreed te gebruiken, analyses betrouwbaar te maken en processen te volgen.
Structuur van een UNS
Een UNS kan verschillend worden opgebouwd, afhankelijk van jullie processen en gewenste dataniveaus. Binnen je organisatie bepaal je zelf een structuur die logisch is voor jullie productieomgeving en systemen.
Een veelgebruikt en overzichtelijk voorbeeld van zo’n structuur is de internationale ISA-95 hiërarchie. Deze standaard helpt om data tussen kantoor- en productiesystemen op een eenduidige manier te organiseren:
[Enterprise] / [Site] / [Area] / [Work Center] / [Work Unit] / [DataProducer] / [DataPoint]
- Enterprise – de organisatie, het bedrijf of de hele fabrieksgroep
- Site – een fysieke locatie of fabriek
- Area – een productieafdeling of specifiek productiegebied binnen een site
- Work Center – een logische groep van machines of werkstations waar werk wordt uitgevoerd (bijvoorbeeld een productielijn)
- Work Unit – een onderdeel van een Work Center, bijvoorbeeld een specifieke machine, CNC, assemblagestation of PLC
- DataProducer – bronnen die data publiceren, zoals machines, sensoren, ERP-systemen of berekende waarden uit algoritmes (bijvoorbeeld een OEE-berekening).
- DataPoint – het specifieke datapunt (bijv. ordernummer, status, temperatuur, energieverbruik)
Een DataPoint kan op elk niveau worden toegevoegd. Zo kun je bijvoorbeeld het energieverbruik van een hele productielijn meten, in plaats van alleen per individuele machine. Dit maakt het eenvoudiger om zowel detailmetingen als geaggregeerde inzichten te gebruiken.
Let op: In onze voorbeelden nemen we de DataProducer op in het pad, zodat duidelijk is waar de data vandaan komt. In een volledig functionele UNS-structuur kan deze laag soms worden weggelaten. Voor de eindgebruiker maakt het niet uit welk apparaat de data levert, zolang de informatie over de Work Unit maar correct is.
Voorbeeld:
ProductiebedrijfX / LocatieA / Area1 / WorkCenter1 / WorkUnit1 / PLC / Status
Hiermee is direct duidelijk waar de data vandaan komt, op welk niveau deze hoort en wat de betekenis is.
Data beschikbaar via een UNS met request-response
Een UNS is dus een uniforme datastructuur. Systemen “weten” hierdoor waar data staat en wat deze betekent. Ze kunnen data uit deze structuur op verschillende manieren gebruiken, bijvoorbeeld via het request-response-principe:
- Een systeem vraagt data op (request)
- Het andere systeem stuurt de gevraagde data terug (response)
Request–response methoden
- Via API’s of queries: Een systeem vraagt informatie op bij een ander systeem wanneer dat nodig is.
- Via point-to-point koppelingen: Twee systemen wisselen direct data met elkaar uit via een integratie.
- Via integratiesoftware: Een integratieplatform haalt data op uit systemen en stuurt deze door naar andere applicaties.
Nadelen van request-response
- Systemen moeten steeds opnieuw data opvragen (pull). Soms gebeurt dit elke paar seconden (polling), zodat het bijna real-time lijkt – maar het net niet is.
- Elk systeem moet zelf de data opvragen, dus bij tientallen systemen en honderden datapoints ontstaat veel netwerkverkeer.
- Er komt geen automatische notificatie bij wijzigingen, een systeem krijgt alleen iets als het zelf vraagt (pollt). Het ziet dus geen updates als ze spontaan optreden.
- Het is lastig te combineren met automatische event-driven processen, bijvoorbeeld voor automatische triggers, meldingen of dashboards die continu moeten updaten
Conclusie: Een UNS voorkomt spraakverwarring en maakt data begrijpelijker en uniformer. Maar voor automatische, real-time updates bij alle relevante systemen en het elimineren van point-to-point koppelingen is een event-driven architectuur nodig.
UNS + event-driven architectuur: real-time datadistributie
Wanneer je een wirwar van koppelingen wilt vermijden en data uit meerdere systemen real-time wilt combineren, volstaat een UNS in een request–response-model niet. Een event-driven architectuur wél.
Met een event-driven architectuur worden wijzigingen automatisch beschikbaar gemaakt voor alle relevante systemen. Je krijgt écht real-time inzicht, het datalandschap blijft overzichtelijk en je kunt nieuwe systemen eenvoudig aansluiten.
Door de combinatie van een Unified Namespace (UNS) en een event-driven distributiemechanisme ontstaat één centrale en actuele bron van waarheid (single source of truth). Alle systemen ontvangen dezelfde events, waardoor er geen losse synchronisaties of afwijkende kopieën meer ontstaan.
Hoe een event-driven architectuur werkt
In een event-driven architectuur publiceren systemen gebeurtenissen (events) zodra data verandert. Andere systemen kunnen zich abonneren op de relevante datapaden en ontvangen automatisch een update.
Voorbeeld:
- Een machine meldt dat een job is afgerond.
- Het ERP-systeem registreert de order als gereed.
- Het voorraadsysteem boekt automatisch het geproduceerde aantal.
Deze aanpak creëert één centrale distributielaag die real-time updates levert aan alle systemen zonder directe point-to-point koppelingen. Updates worden actief ‘gepusht’, zodat er geen polling nodig is. Geabonneerde systemen hebben hierdoor altijd actuele informatie.
Kerncomponenten van event-driven architectuur
- Dataproducers: Bronnen die data genereren en bij wijziging een event publiceren, zoals machines, sensoren, ERP-systemen of algoritmes (bijvoorbeeld een OEE-berekening).
- Event: Een bericht dat een wijziging of gebeurtenis in een datapunt beschrijft.
- Broker (messaging-laag): Ontvangt events van dataproducers en verspreidt deze automatisch naar alle subscribers die zich op de juiste datapaden hebben geabonneerd (bijvoorbeeld via een MQTT-broker).
- Subscribers (data consumers): Toepassingen, zoals dashboards, planningtools, MES- of ERP-interfaces, die zich abonneren op UNS-paden en automatisch updates ontvangen wanneer een event wordt gepubliceerd.
- Historian: Slaat events of meetwaarden op voor trends en rapportages achteraf. Waar de broker zorgt voor de ‘live’ hartslag, dient de historian als het geheugen van je productiebedrijf. Analyse-tools en BI-dashboards halen hier via een query of API de benodigde historische data op.
Voordelen van een UNS + event-driven architectuur
De UNS zorgt voor structuur en betekenis van data, terwijl de event-driven architectuur ervoor zorgt dat deze data automatisch en real-time beschikbaar komt voor alle gebonneerde systemen.
De belangrijkste voordelen:
- Uniforme datadefinities
Data wordt volgens één uniforme structuur gepubliceerd, met eenduidige definities. Hierdoor kunnen systemen dezelfde informatie interpreteren, ook als ze intern verschillende ‘talen’ spreken.
- Single source of truth
Door de combinatie van UNS en event-driven architectuur ontstaat een single source of truth: alle systemen ontvangen dezelfde real-time events vanuit één centrale publicatiestroom, waardoor er geen afzonderlijke kopieën of synchronisaties meer nodig zijn.
- Real-time beschikbaarheid
Wanneer een datapunt verandert, ontvangt elke subscriber direct een update. Dashboards, MES, ERP en andere systemen kunnen zo actuele informatie tonen.
- Historische data beschikbaar voor analyse
Events of meetwaarden kunnen worden opgeslagen in een historian, zodat analyses, rapportages en dashboards ook toegang hebben tot historische informatie, ook wanneer machines of software worden vervangen.
- Efficiënt gebruik via subscribers
Het subscriber-model zorgt ervoor dat systemen alleen relevante updates ontvangen, waardoor real-time inzicht efficiënt blijft en resources worden bespaard.
- Overzichtelijk digitaal landschap
Geen complex web van point-to-point koppelingen meer. Systemen hoeven alleen met de broker te verbinden om data te publiceren of te ontvangen.
- Flexibiliteit en schaalbaarheid
Nieuwe machines, applicaties of dashboards kunnen worden aangesloten zonder bestaande integraties aan te passen.
Historische data en context
Een historian is een gespecialiseerde timeseries-database die meetwaarden en events met een tijdstempel opslaat. Bijvoorbeeld: om 10:32:15 was de temperatuur 85°C. Om 10:32:20 was die 86°C. Dat is ideaal om trends te analyseren en processen te monitoren.
Wat een historian meestal niet automatisch vastlegt, is de volledige context van dat moment, zoals bij welke order de meting hoorde, welke instellingen actief waren of welke grondstoffen werden gebruikt. Voor eenvoudige analyses is dat vaak geen probleem. Voor complexere analyses kan die extra context echter cruciaal zijn.
In een volwassen data-architectuur worden daarom meetwaarden vaak gekoppeld aan metadata of andere contextinformatie, zodat historische data later effectief en betrouwbaar geanalyseerd kan worden. Dit kan bijvoorbeeld betekenen dat ook berekende waarden, procesparameters of businesscontext in de historian worden opgeslagen. Zo kan je later precies reconstrueren wat er in de fabriek gebeurde op een bepaald moment, en kunnen verschillende dashboards of tools gebruikmaken van dezelfde basisdata zonder verborgen berekeningen.
Wat betekent dit onder de streep voor jouw fabriek
Met een UNS en event-driven architectuur hebben verschillende systemen toegang tot betrouwbare real-time en historische data. Het haalt de complexiteit uit je IT-beheer en legt de focus terug op waar het echt om gaat: je productie optimaliseren en beslissingen nemen op basis van feiten. Het biedt overzicht, betrouwbaarheid en flexibiliteit – precies wat moderne, datagedreven productie nodig heeft.
Herken je die ‘wirwar’ van koppelingen in je eigen fabriek en ben je benieuwd waar voor jou de eerste stap ligt? Wij denken graag met je mee over hoe we jouw data weer voor je kunnen laten werken, in plaats van andersom.
Lees de volledige serie over UNS & event-driven architectuur:
- Deel 1: Wat is een UNS en hoe werkt een event-driven architectuur? (Huidig)
- Deel 2: Waarom deze combinatie de ‘wirwar’ aan koppelingen in je fabriek oplost.
- Deel 3: Stappenplan: Zo start je met een UNS + event-driven architectuur.
- Deel 4: Praktijkvoorbeeld: Real-time data van ERP tot operator-dashboard.