The process industry has monitored plant values in real time for decades — historian systems like PI systems have handled that reliably for a long time. A Unified Namespace (UNS) in the process industry doesn’t replace these systems. Instead, it breaks open the rigid automation pyramid. It makes data from the process control system, safety system, historian, and MES available across channels. That replaces brittle point-to-point OPC bridges between levels. That’s exactly the core idea behind the NAMUR Open Architecture (NOA) too: a second, independent channel alongside the core process control system.
This article shows what sets a Unified Namespace in the process industry apart from a generic manufacturing architecture. It covers industry-specific use cases for AI and digital twins, plus concrete best practices. For the technical fundamentals of a UNS itself, see What Is the Unified Namespace (UNS)?
Unified Namespace Requirements in the Process Industry
Digitalization projects in the process industry face requirements that differ significantly from discrete manufacturing. The following drivers determine how data needs to be modeled, stored, and evaluated.
Conceptual and Regulatory Drivers: ISA-88, NAMUR NOA, and IEC 61511
ISA-88 (S88) structures batch processes at a finer granularity than the pure site model in ISA-95. Process cell, unit, equipment module, and control module form their own physical hierarchy, extended with recipe phases like charging, reaction, discharge, and cleaning. The NAMUR Open Architecture provides the conceptual counterpart at the communication level. It’s a second channel for monitoring and optimization that operates independently of the core process control system. IEC 61511, in turn, governs Safety Instrumented Systems (SIS). A safety instrumented system must stay functionally and organizationally separate from the basic process control system. A UNS may therefore only mirror SIS data, never control it.
These three concepts mesh together. ISA-88 models what happens inside the plant. NOA models how data flows safely to the outside. IEC 61511 draws the line that must never be crossed.
What Makes the Process Industry Technically Different
A process plant often combines continuous and batch processes on the same production line. A distillation column runs uninterrupted for weeks, while a batch reactor next to it works through one recipe after another. Both process types need different data models within the same UNS. On top of that comes the alarm flood. Under EEMUA 191, a plant counts as manageable when an operator handles no more than one alarm every ten minutes on average. In practice, many plants exceed that value many times over during upsets. These properties shape how a Unified Namespace in the process industry needs to be modeled. Recipe data, SIS status, and alarm context are separate data objects, not add-on fields in a generic sensor payload.
Process-Industry-Specific Topic Structure
In a Unified Namespace in the process industry, the physical hierarchy stays stable: plant, process cell, unit, equipment module, measurement. It doesn’t change with whichever batch is currently running. This follows the same ISA-95 principles as in MQTT Topic Namespace Best Practices, extended with the ISA-88 levels for batch units. What’s industry-specific here isn’t the topic hierarchy itself, but where recipe, SIS, and alarm data get stored in the UNS.
Typical topic hierarchy, independent of the batch:
ludwigshafen/pc12/k7/pressure-monitoring/actualludwigshafen/pc12/k7/pressure-monitoring/status
Batch and safety events, on the other hand, get their own one-off topics:
ludwigshafen/pc12/r204/batch/CHG-2026-0718-A17/batch-recordludwigshafen/pc12/r204/sis/sif-101/status
This data model has three process-industry-specific properties:
- Continuous measurements stay independent of the batch. A pressure sensor on the column publishes continuously on a fixed topic, with no batch ID in the path.
- A batch runs through several recipe phases. It gets its own topic per batch, because each batch is an individually auditable record under ISA-88.
- SIS status is inherently per safety function (Safety Instrumented Function, SIF). It’s tracked by SIF ID in the topic and mirrored read-only from the SIS.
The following use cases trace this structure through one continuous example plant: the Ludwigshafen site, process cell PC-12, with batch reactor R-204 and continuous distillation column K-7.
UNS Use Cases and Real-World Examples in the Process Industry
The following use cases show how this data model pays off in practice, from classic batch traceability to AI-driven insights and digital twins.
Batch Execution and Recipe Tracking Under ISA-88
Reconstructing batch data after the fact from the batch management system, historian, and lab exports takes time. The Unified Namespace delivers a batch’s complete recipe execution in real time instead. Raw material lots, recipe phases, process parameters, and release status are all linked directly through the batch ID. An audit that requires the complete manufacturing record of a batch becomes a query instead of a manual research project.
Topic: ludwigshafen/pc12/r204/batch/CHG-2026-0718-A17/batch-record
JSON Payload:
{
"batchId": "CHG-2026-0718-A17",
"recipeId": "REC-INT-204",
"recipeVersion": "v3.2",
"processCellId": "PC-12",
"unitId": "R-204",
"rawMaterials": [
{
"material": "monomer_a",
"supplierLot": "LOT-MA-55210",
"quantityKg": 850
},
{
"material": "catalyst_x",
"supplierLot": "LOT-CX-11072",
"quantityKg": 12
}
],
"recipePhases": [
{
"phase": "charge",
"startTime": "2026-07-18T04:00:00Z",
"endTime": "2026-07-18T04:45:00Z"
},
{
"phase": "react",
"startTime": "2026-07-18T04:45:00Z",
"endTime": "2026-07-18T09:15:00Z",
"targetTempC": 140,
"targetPressureBar": 6.2
},
{
"phase": "discharge",
"startTime": "2026-07-18T09:15:00Z",
"endTime": "2026-07-18T09:50:00Z"
}
],
"productionSite": "plant-ludwigshafen",
"status": "released",
"isa88Record": "batch_record",
"timestamp": "2026-07-18T09:50:00Z"
}
NOA-Compliant Monitoring and Diagnostics Channel
Additional instrumentation used solely for condition monitoring runs over its own channel, independent of the core process control system, following the NOA principle. An extra pressure sensor on the column delivers diagnostic data for monitoring and optimization this way, without intervening in the process control system’s control loop. For how the Unified Namespace implements this second channel in practice, see The Unified Namespace Enables the NAMUR Open Architecture.
Topic: ludwigshafen/pc12/k7/pressure-monitoring/actual
JSON Payload:
{
"sensorId": "PT-K7-MON-02",
"unitId": "K-7",
"measurementType": "pressure",
"monitoringChannel": "noa_secondary",
"controlRelevant": false,
"valueBar": 4.85,
"limitMinBar": 4.0,
"limitMaxBar": 5.5,
"status": "within_limits",
"timestamp": "2026-07-18T10:00:00Z"
}
SIS Status and Proof-Test Monitoring Under IEC 61511
The Unified Namespace mirrors the status of every Safety Instrumented Function (SIF), along with its proof-test due date, read-only from the SIS. That creates visibility for asset management and audit preparation. The safety logic itself stays entirely in the SIS. The UNS has no write access to safety functions whatsoever, and it must never replace a safety path.
Topic: ludwigshafen/pc12/r204/sis/sif-101/status
JSON Payload:
{
"sifId": "SIF-101",
"safetyFunction": "reactor_overpressure_trip",
"silRating": "SIL2",
"sisState": "healthy",
"lastProofTestDate": "2026-04-02",
"nextProofTestDue": "2027-04-02",
"writeAccessFromUns": false,
"dataSource": "sis_read_only_mirror",
"timestamp": "2026-07-18T00:00:00Z"
}
Alarm Management Data Aggregation Under EEMUA 191
Every alarm publishes priority, setpoint, actual value, and acknowledgment status as its own event. That allows the alarm rate to be evaluated centrally against the EEMUA 191 target, instead of compiling alarm lists manually from multiple DCS stations.
Topic: ludwigshafen/pc12/k7/alarm/ALM-20260718-0912/event
JSON Payload:
{
"alarmId": "ALM-20260718-0912",
"tag": "PT-K7-01",
"priority": "high",
"eemua191Class": "priority_2",
"setpoint": 5.5,
"actualValue": 5.9,
"raisedAt": "2026-07-18T09:12:00Z",
"acknowledgedBy": "operator-042",
"acknowledgedAt": "2026-07-18T09:13:10Z",
"clearedAt": "2026-07-18T09:24:00Z",
"rationalizationStatus": "reviewed"
}
AI Use Cases in the Process Industry
AI use cases for a Unified Namespace in the process industry only deliver value in one situation. Process, alarm, and lab quality data need to be linked together first — generic anomaly detection alone isn’t enough.
Alarm Flood Pattern Recognition and Root-Cause Correlation
A model groups alarms that occur together within a short time window and suggests a probable primary alarm. That speeds up root-cause analysis during upsets. The model never automatically suppresses safety-relevant alarms. It only ever delivers a prioritized recommendation for the operator.
Topic: ludwigshafen/pc12/ai/alarm-flood-correlation/EVENT-20260718-0912
JSON Payload:
{
"eventId": "EVENT-20260718-0912",
"model": "alarm-flood-correlation-v1.3",
"windowStart": "2026-07-18T09:10:00Z",
"windowEnd": "2026-07-18T09:18:00Z",
"groupedAlarms": [
"ALM-20260718-0910",
"ALM-20260718-0912",
"ALM-20260718-0915"
],
"probableRootCauseTag": "PT-K7-01",
"confidenceScore": 0.82,
"suppressesSafetyAlarm": false,
"recommendation": "flag_root_cause_tag_for_review",
"timestamp": "2026-07-18T09:19:00Z"
}
Soft-Sensor Refinement for Product Quality
Inference models for hard-to-measure quality variables have been standard APC practice in the process industry for years. A model in the UNS extends this practice by additionally factoring in context from the upstream batch, catalyst age, and maintenance history. The official lab release stays untouched by this. The soft sensor delivers an early indication, but it never replaces lab analysis.
Topic: ludwigshafen/pc12/k7/ai/soft-sensor/product-quality
JSON Payload:
{
"unitId": "K-7",
"model": "soft-sensor-purity-v2.0",
"predictedPurityPercent": 99.4,
"confidenceIntervalPercent": 0.3,
"contributingFactors": [
{
"source": "upstream_batch",
"factor": "feed_composition_deviation_percent",
"value": 0.8
},
{
"source": "maintenance",
"factor": "catalyst_age_days",
"value": 42
}
],
"replacesLabAnalysis": false,
"timestamp": "2026-07-18T11:00:00Z"
}
Digital Twin in the Process Industry
The digital twin in the Unified Namespace becomes especially valuable once it integrates recipe- and module-specific process data alongside equipment parameters.
MTP Module Twin for Virtual Commissioning
Module Type Packages (MTP) describe modular plant units, known as Process Equipment Assemblies, in a vendor-independent, standardized way. The digital twin simulates a new module in the context of the overall plant before it gets physically integrated. That way, the integration can be validated without interrupting ongoing production.
Topic: ludwigshafen/pc12/twin/mtp-module/simulation
JSON Payload:
{
"simulationId": "SIM-MTP-2026071801",
"peaId": "PEA-DOSIER-07",
"scenario": "new_module_integration_test",
"input": {
"dosingRateLPerMin": 12.5,
"interfaceProtocol": "opc_ua"
},
"predictedCycleTimeMin": 8.2,
"maxAllowedCycleTimeMin": 9.0,
"result": "sufficient",
"recommendedForLiveOperation": true,
"timestamp": "2026-07-17T22:00:00Z"
}
Batch/Recipe Twin for Parameter Validation
The digital twin simulates the temperature and pressure profile of a recipe before a new parameter set goes into real production. That way, the expected yield can be validated without risking a real batch.
Topic: ludwigshafen/pc12/r204/twin/recipe/simulation
JSON Payload:
{
"simulationId": "SIM-REC-2026071802",
"recipeId": "REC-INT-204",
"scenario": "reduced_reaction_time_test",
"input": {
"targetTempC": 143,
"reactionTimeH": 4
},
"predictedYieldPercent": 96.8,
"minRequiredYieldPercent": 95.0,
"result": "sufficient",
"recommendedForLiveOperation": false,
"timestamp": "2026-07-17T21:00:00Z"
}
Best Practices for UNS Adoption in the Process Industry
Do
- Model recipe version and batch ID as mandatory fields: they belong at the batch level, not scattered as an add-on attribute somewhere in the payload.
- Keep SIS status visible but isolated: the UNS mirrors SIF status and proof-test dates without gaining write access to the SIS.
- Carry alarm context: priority, setpoint, and acknowledgment status belong in the UNS, so EEMUA 191 evaluations can happen centrally.
- Carry calibration status: the calibration status of process and safety sensors belongs in the UNS, so audits can trace measurement accuracy end to end.
Avoid
- Closing or replacing SIS logic through the UNS: violates the separation of safety and process control systems required under IEC 61511.
- Leaving alarm data only in the local DCS log: without visibility in the UNS, the alarm rate can’t be evaluated centrally against EEMUA 191.
- Maintaining recipe parameters only in the batch management system: makes it harder to link them with process and quality data from the same batch.
Conclusion
A Unified Namespace in the process industry is more than a generic manufacturing architecture with a process-industry label slapped on. Recipe data, SIS status, and alarm context are separate data objects that shape the topic structure from the ground up. That’s what makes ISA-88 recipe audits, NOA implementation, and the EEMUA 191 alarm rate practically manageable. Three key takeaways:
- Industry-specific data modeling: recipe data, SIS status, and alarm context are separate fields, not a different broker choice.
- AI and digital twins need context: their value only emerges from linking process, alarm, and quality data, and AI never replaces lab release or a safety function.
- Safety separation is an architecture principle, not a compliance afterthought: IEC 61511 dictates that the UNS may only mirror SIS data. That boundary belongs in the architecture from day one.
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.
