Data wordt waardevol wanneer het real-time beschikbaar is, gecombineerd met andere relevante informatie en actief wordt gebruikt voor betere beslissingen, efficiëntere productie, inzicht in bottlenecks en een beter afgestemde planning.
In eerdere blogs legden we uit wat een Unified Namespace (UNS) en event-driven architectuur zijn en hoe je er stapsgewijs mee start. In dit blog laten we aan de hand van een concreet voorbeeld zien hoe data automatisch beschikbaar komt voor verschillende subscribers: van operator-dashboards en planningtools tot het ERP-systeem.
Elke gebruiker gebruikt zijn eigen tool voor inzicht, maar ze ontvangen allemaal automatisch real-time updates vanuit dezelfde bron van waarheid (Single Source of Truth). Geen losse koppelingen, geen handmatig werk.
We kijken specifiek naar wat er voor een operator zichtbaar is op zijn dashboard en wat er ‘onder de motorkap’ gebeurt in de Unified Namespace (UNS) volgens ISA-95.
Real-time productiegegevens via UNS en event-driven architectuur
Voordat dashboards of andere systemen real-time productiegegevens kunnen tonen, wordt data uit verschillende bronnen gepubliceerd als events in één uniforme naamstructuur: de Unified Namespace (UNS). Je bepaalt zelf hoe je deze structuur inricht, in onze voorbeelden gebruiken wij de internationale ISA-95 standaard als basis.
Hoe ziet een UNS eruit volgens ISA-95?
Volgens de internationale ISA-95 hiërarchie organiseer je de data uit je verschillende systemen als volgt:
[Enterprise] / [Site] / [Area] / [Work Center] / [Work Unit] / [DataProducer] / [DataPoint]
Note: In onze voorbeelden nemen we de [DataProducer] (de bron) op in het pad, zodat je precies ziet waar de data vandaan komt. In een volledig functionele UNS-structuur wordt deze laag vaak weggelaten. Voor de eindgebruiker maakt het technisch namelijk niet uit welk apparaat de data levert, zolang de informatie over de “Work Unit” maar correct is. In de opstartfase helpt het echter om de herkomst van data inzichtelijk te houden.
- Enterprise: De organisatie → MyCompany
- Site: De locatie of fabriek → Eindhoven
- Area: De afdeling of het productiegebied → Packaging
- Work Center: De productielijn → Line_01
- Work Unit: De machine of het werkstation → Wrapper_01
- DataProducer → De bron van de data (machine, MES, ERP)
- DataPoint: Het specifieke datapunt → ordernummer, status, snelheid, temperatuur, etc
Voordelen van deze structuur:
- Iedereen weet waar data thuishoort
- Datapaden worden uniform opgebouwd
- Verschillende systemen spreken dezelfde “datataal”
Event-driven architectuur: automatische updates
Om real-time inzicht te krijgen, combineren we deze uniforme naamstructuur met een event-driven werkwijze. Dat betekent:
- Dataproducers (machines, ERP, sensoren) publiceren wijzigingen in datapunten naar de broker zodra deze veranderen.
- Subscribers (dashboards, planningtools, ERP-systemen) abonneren zich op relevante datapaden en ontvangen automatisch real-time updates via de broker.
- Elke wijziging in een datapunt wordt als event verstuurd, met een payload die de actuele waarde bevat en eventueel extra context (bijv. timestamp, statuscode).
Concreet betekent dit:
- De UNS bepaalt hoe data logisch en uniform wordt benoemd, zodat iedereen weet waar welke informatie thuishoort.
- De event-driven architectuur zorgt dat wijzigingen automatisch en direct naar alle subscribers (geabonneerden) worden gestuurd , zonder dat iemand handmatig gegevens hoeft te verplaatsen. Updates komen direct binnen.
In het geval van ons dashboard betekent dit dat er geen aparte koppeling nodig is met het ERP of de sensoren. Het dashboard abonneert zich simpelweg op de relevante datapaden van één specifieke ‘Cell’ (machine).
Data beschikbaar op de werkvloer; real-time operator-dashboard
De sales binnendienst voert een order in
De sales binnendienst voert een nieuwe order in het ERP-systeem in:
| Ordernummer | Product | Aantal | Deadline |
| 456 | Widget A | 1000 | 15-02-2026 |
- Ordernummer: 456
- Product: Widget A
- Aantal: 1000
- Deadline: 15-02-2026
Het ERP publiceert deze orderinformatie als event in de UNS, waarna de broker het event automatisch verspreidt naar alle geabonneerde subscribers.
Het event wordt gepubliceerd op een datapad zoals:
MyCompany / Eindhoven / Planning / ERP / PlannedOrders / Order456
Hier staan alle relevante details zoals OrderNumber, ProductID, TargetQuantity en Deadline. De broker verspreidt dit event automatisch naar alle geabonneerde systemen.
Geplande orders op het dashboard
Het dashboard van de operator is geabonneerd op:
MyCompany / Eindhoven / Planning / ERP / PlannedOrders / #
Zo ziet de operator een lijst van beschikbare orders. De operator kan een order selecteren en starten.
Operator start een order en ontvangt real-time updates
Wanneer de operator order 456 selecteert om te draaien op zijn machine ‘Wrapper_01’, publiceert het systeem dit direct in de UNS.
In een event-driven architectuur zorgt dit ene event ervoor dat alle relevante systemen gelijktijdig in actie komen:
- Het ERP-systeem: Ontvangt het event en zet de orderstatus automatisch op ‘In productie’. Handmatig starten of overkloppen is niet meer nodig.
- De planningtool: Ziet de werkelijke starttijd en herberekent direct de planning voor de rest van de dag.
- De historian: Begint direct met het loggen van alle machinedata (snelheid, temperatuur, stops) specifiek gekoppeld aan dit ordernummer.
- Het dashboard: Toont de operator direct de actuele status, zodat hij ziet dat de order correct is opgestart.
UNS-structuur achter het dashboard
Het dashboard van de ‘Wrapper_01’ ontvangt alle gegevens van deze order, samen met real-time machinedata en sensorevents. Hieronder zie je hoe de UNS-structuur achter het dashboard eruitziet. We tonen hier bewust de DataProducer-niveaus:
📁 MyCompany (Enterprise)
└── 📁 Eindhoven (Site)
└── 📁 Line_01 (Work Center)
└── 📁 Wrapper_01 (Work Unit)
├── 📁 ERP (Dataproducer)
└── 📁 ActiveWorkOrder
├── OrderNumber: “456”
├── ProductID: “Widget A”
├── TargetQuantity: 1000
├── ProducedQuantity: 320
├── Deadline: “15-02-2026”
└── WorkOrderCompleted: False
├── 📁 Machine (Dataproducer)
└── 📁 State
├── Status: “Running”
├── Speed: 450
└── MachineTemperature: 185
└── 📁 Sensor (Dataproducer)
└── 📁 TemperatureMonitor
├── ActualTemperature: 182
├── TemperatureLimit: 200
└── TemperatureAlert: False
Note: In dit praktijkvoorbeeld zie je de bronnen (ERP, Machine, Sensor) als tussenlaag. In een puur functionele structuur zou je deze lagen verwijderen, omdat een operator alleen geïnteresseerd is in de status van de “Wrapper_01”, ongeacht welk technisch systeem die status doorgeeft.
Op het dashboard
Het dashboard toont direct:
- Welke order actief is
- Hoeveel er geproduceerd is
- Of de machine draait of stilstaat
- Of de temperatuur binnen limieten blijft
- Of de order gereed is
Dankzij de event-driven architectuur ontvangt het dashboard automatisch updates zodra een datapunt wijzigt:
- Machine stopt → Status = “Stopped”
- Temperatuur overschrijdt limiet → TemperatureAlert = True
- Werkorder voltooid → WorkOrderCompleted = True
- ProducedQuantity loopt op → dashboard update direct
Voordeel voor de operator:
De operator ziet in één oogopslag welke order actief is en hoeveel er al geproduceerd is. Hij krijgt real-time inzicht in de status van de machine en eventuele waarschuwingen, zoals temperatuuroverschrijding of onverwachte stops. Dit voorkomt fouten en vertragingen, omdat alle relevante informatie direct beschikbaar is in één overzicht.
Overal in de fabriek dezelfde waarheid
Voor één enkel operator-dashboard zou een directe koppeling met ERP of machindata technisch nog mogelijk zijn, volgens het request-response principe. Maar zodra meerdere rollen – operators, planners, productiemanagers en customer service – gelijktijdig real-time met dezelfde data willen werken, wordt een netwerk van losse koppelingen snel complex en foutgevoelig. De combinatie van UNS en event-driven architectuur voorkomt dit door één uniforme datastructuur en automatische distributie van updates naar alle subscribers.
Directie – overzicht van meerdere locaties
Wanneer een organisatie meerdere productielocaties heeft, kan een directiedashboard zich abonneren op meerdere Sites van de ‘Enterprise’, bijvoorbeeld:
MyCompany / + / + / + / + / Machine / State / # → alle machine status
MyCompany / + / + / + / + / ERP / ActiveWorkOrder / # → alle ERP-orders
Goed om te weten: De tekens + en # zijn ‘wildcards’. Hiermee verzamel je automatisch data van alle locaties, lijnen of machines tegelijk. In dit voorbeeld gebruiken we een wildcard voor overzicht, maar in de praktijk wordt er vaak selectiever geabonneerd om te voorkomen dat te veel data tegelijk binnenkomt, bijvoorbeeld door alleen relevante machines of datapunten te volgen.
Doordat elke locatie dezelfde UNS-structuur gebruikt, ontstaat automatisch inzicht over meerdere fabrieken zonder extra maatwerkkoppelingen. Dit maakt vergelijking tussen locaties, lijnen of afdelingen eenvoudig en betrouwbaar.
Planner – real-time inzicht in productievoortgang
De planner gebruikt een planningstool die zich abonneert op:
MyCompany / Eindhoven / Packaging / + / + / ERP / ActiveWorkOrder / #
MyCompany / Eindhoven / Packaging / + / + / Machine / State / #
Wat hij ziet en gebruikt:
- Hoeveel van een order al geproduceerd is (ProducedQuantity)
- De actuele machinestatus (bijv. draaiend of stilstand)
- Eventuele productieproblemen, zoals een onverwachte stop
Dankzij real-time updates kan de planner wanneer nodig direct bijsturen, bijvoorbeeld orders herschikken, capaciteit anders verdelen of sneller reageren op verstoringen in de productie.
Productiemanager – overzicht van de productielocatie
De productiemanager gebruikt een dashboard dat meerdere lijnen en cellen laat zien, geabonneerd op:
MyCompany / Eindhoven / #
Wat hij ziet en gebruikt:
- Status van alle actieve orders en productielijnen
- Alerts van sensoren, zoals temperatuuroverschrijdingen (TemperatureAlert)
- Voortgangsstatistieken per lijn of machine
Zo krijgt hij een direct overzicht van bottlenecks, risico’s of vertragingen en kan hij managementbeslissingen onderbouwen met actuele data, zonder dat hij zelf alle systemen hoeft te raadplegen.
Customer Service – actuele klantinformatie
De customer service medewerker gebruikt het ERP-systeem als interface. Ze volgt de relevante orderinformatie, zoals orderstatus en gereedmelding, zodat zij klanten betrouwbare updates kan geven. Het ERP-systeem is geabonneerd op alle relevante orderevents via het UNS-pad:
MyCompany / Eindhoven / + / + / + / ERP / ActiveWorkOrder / #
Zo ontvangt zij alleen de gegevens die relevant zijn voor haar taak. Niet elk machine-event wordt doorgestuurd; alleen relevante informatie zoals orderstatus, hoeveelheid geproduceerd en gereedmelding.
Wat ze ziet en gebruikt:
- Welke orders actief zijn en hoeveel er al geproduceerd is (ProducedQuantity)
- Of een order gereed is voor verzending (WorkOrderCompleted)
- Eventuele wijzigingen in deadlines of orderstatus
Dankzij de event-driven architectuur ontvangt zij direct updates zodra deze relevante gegevens wijzigen.
Samengevat: waarde van real-time data via UNS en event-driven updates
Door ERP-data, machine-data en sensor-events te combineren via de UNS en event-driven architectuur:
- Hebben alle betrokkenen – van werkvloer tot kantoor – altijd hetzelfde actuele inzicht.
- Kunnen dashboards en andere tools automatisch alle relevante events tonen.
- Wordt data uniform en betrouwbaar beschikbaar voor alle subscribers.
Van data naar direct inzicht op de werkvloer
Wil je ontdekken hoe je productiegegevens uit machines, sensoren en ERP samenbrengt in één overzichtelijke datastructuur?
Produmize helpt MKB- productiebedrijven om hun data real-time inzichtelijk en bruikbaar te maken op de werkvloer.
Wil je zelf ervaren hoe een UNS en event-driven architectuur rust en overzicht brengen in jouw productiebedrijf? Neem contact op voor een vrijblijvend gesprek of bekijk ons stappenplan in Starten met een UNS + event-driven architectuur.