Welcome to the UNS Patterns repository. This is a collection of ideas aimed at sparking discussions on designing Unified Namespace (UNS) topic structures for industrial and manufacturing operations. Drawing from ISA-95 Part II's core hierarchy, the focus here is on providing generic starting points that can be extended to fit specific industries or needs. I'm sharing these as a way to explore principles, not as definitive solutions—feedback and contributions are very welcome (actually encouraged) to refine them.
A Unified Namespace (UNS) is an architectural pattern for organizing real-time data in industrial systems, often built on pub/sub protocols like MQTT. It creates a hierarchical, browsable structure (e.g., /Enterprise/Site/Area/Line/Machine/Metric) that mirrors organizational assets, enabling decoupled data flows between OT (Operational Technology) and IT systems. In back-end terms, think of it as an event-driven data fabric—prototype with C# (MQTTnet) or Python (paho-mqtt) clients publishing to a broker like HiveMQ on your K8s cluster, with RDBMS (e.g., Postgres) for historical persistence.
A huge thank you to Walker Reynolds (President of 4.0 Solutions) for coining the term "Unified Namespace" and championing its adoption in industrial IIoT. His practical insights from real-world integrations have shaped much of the modern discussion around UNS as an event-driven architecture for decoupling OT/IT systems.
Walker prototyped the concept as early as 2005, building his first implementation using Dynamic Data Exchange (DDE) in a salt mine to unify machine data without physical trips to control booths. The term itself was formalized around 2015, evolving with MQTT and Sparkplug to address data silos in Industry 4.0. For a deeper dive, check this masterclass interview where he covers origins and evolution: Unified Namespace for Industrial IoT: The Masterclass (YouTube). This repo builds on those foundations but tailored to specific use cases as a starting point.
This repo builds on ISA-95's equipment and activity models for a standardized foundation. Start with a core hierarchy like:
Enterprise > Site > Area > Production Unit > Work Cell > Equipment, then layer in variations based on manufacturing types or methodologies. Extend via YAML templates in /patterns/ for your custom setups—e.g., map to gRPC services for backend integration or AWS IoT Core for cloud scaling.
There are many other classification schemes that have not yet been considered. The idea of UNS does not necessarily force you to choose anything presented here. This is a repository for examples the community can puth forth and others can take a look, experiment, refine, propose changes or present a brand new idea. Other facets that could have been used here include (but not limited to):
- Purdue Model
- As defined by US Energy Department
- Others?
What classification ontologies should be used to classify UNS patterns? It is difficult to say since your approach may be very different depending on your industry, corporate philosophy, company culture, etc., etc.
To get this effort off the ground a decision was made to consider ISA 95 Part II, Manufacturing Process Types and Manufacturing Methodology Types. Are there other classification schemes that can be used? Absolutely! If you do not see one you'd like listed, feel free to submit a pull-request!
For now, we'll use the following:
These types classify operations by production style, influencing UNS depth and granularity. For instance, a Job Shop might emphasize flexible /JobID/ sub-levels, while Continuous ops focus on flow metrics. Use as a base to adapt your topic structures.
| Type | Definition & Key Characteristics | Examples | Advantages | Disadvantages |
|---|---|---|---|---|
| Job Shop | Low-volume, high-customization production using flexible workstations (not lines) for make-to-order (MTO) or small batches; each job is unique, with workflows rerouted as needed. | Custom furniture, prototypes, aerospace parts, specialty tools | High flexibility for bespoke items; scalable to discrete if demand grows | Inefficient for high volumes; hard to automate fully due to variability |
| Batch | Produces identical items in groups (batches) based on demand; involves setup/cleanup between batches, often for fluids/powders but adaptable; machines handle most work. | Baking goods, pharmaceuticals, chemicals, paints | Flexible batch sizing; good traceability and quality control; minimal downtime for switches | Downtime for cleaning/setup; requires identical items per batch |
| Repetitive | High-volume production of similar/identical items on dedicated assembly lines running 24/7; minimal changeovers, focused on efficiency for standardized products. | Appliances, electronics, consumer goods like toys or electrical components | High efficiency and scalability; low setup time for consistent runs | Low flexibility; overproduction risk if demand drops |
| Discrete | Assembly of distinct, countable items from components; lines allow frequent changeovers for product variations (e.g., sizes/styles); products can be disassembled/recycled. | Automobiles, smartphones, furniture, airplanes | Handles product diversity; efficient for mid-to-high volumes with variations | Time-consuming setups for changes; more complex than repetitive |
| Continuous | Non-stop flow of raw materials (gases, liquids, powders) through chemical/physical transformations; 24/7 operation with uniform output, no batches. | Oil refining, metal smelting, paper production, food like peanut butter | Extremely efficient for high volumes; minimal interruptions | Inflexible for variations; high initial setup costs; faults propagate quickly |
| Additive (e.g., 3D Printing) | Layer-by-layer building from digital designs; enables complex, customized low-volume parts; often seen as a supplement to traditional types. | Medical devices, prototypes, aerospace components, custom visors | Ultimate customization; reduces waste; innovative for complex geometries | Slower for high volumes; material limitations; higher per-unit costs |
These approaches guide process optimization and can overlay on types to refine UNS structures—e.g., add /Constraint/ levels for TOC or /Sprint/ for Agile.
| Methodology | Definition & Core Focus | Key Tools/Principles | Examples in Practice | Pros | Cons |
|---|---|---|---|---|---|
| Lean Manufacturing | Eliminates waste (muda) in all forms (e.g., overproduction, waiting, defects) via continuous flow and value-stream focus; rooted in Toyota Production System (TPS). | 5S (Sort/Set/Shine/Standardize/Sustain), Kaizen, JIT, Kanban, Value Stream Mapping | Automotive (Toyota assembly lines), electronics (reducing inventory in PCB manufacturing) | Reduces costs/inventory; boosts efficiency; adaptable to any scale | Requires cultural buy-in; initial disruptions during implementation |
| Six Sigma | Data-driven methodology to minimize process variability and defects (aiming for 3.4 DPMO); uses DMAIC (Define/Measure/Analyze/Improve/Control) cycle. | Statistical tools (e.g., control charts, DOE), root cause analysis (fishbone diagrams), process mapping | Pharma (defect-free drug batches), semiconductors (yield optimization) | Quantifiable improvements; strong on quality metrics | Data-heavy; can be rigid/overly analytical without Lean integration |
| Total Quality Management (TQM) | Organization-wide commitment to quality at every level, emphasizing customer satisfaction, employee involvement, and preventive measures over inspection. | PDCA (Plan-Do-Check-Act) cycle, benchmarking, employee empowerment | Aerospace (Boeing's quality audits), consumer goods (consistent product standards) | Builds long-term culture; improves overall satisfaction | Slow to implement; vague without metrics |
| Theory of Constraints (TOC) | Identifies and exploits bottlenecks (constraints) to maximize throughput; focuses on system-wide optimization rather than local efficiencies. | Drum-Buffer-Rope (scheduling), five focusing steps (identify/exploit/subordinate/elevate/repeat) | Metal fabrication (optimizing machine queues), supply chains (inventory buffers) | Quick wins on throughput; holistic view | Over-focus on single constraints; needs ongoing monitoring |
| Agile Manufacturing | Emphasizes flexibility, rapid response to market changes, and customization; borrows from software Agile (sprints, adaptability). | Modular production, cross-functional teams, quick prototyping | Consumer electronics (adapting to trends like wearables), fashion (fast fashion cycles) | Handles volatility; fosters innovation | Less efficient for stable, high-volume ops; higher coordination overhead |
| Just-In-Time (JIT) | Produces/delivers goods exactly when needed, minimizing inventory; often a Lean subset but can stand alone. | Pull systems, supplier integration, minimal buffers | Food processing (fresh ingredients on demand), auto parts (vendor-managed inventory) | Lowers holding costs; improves cash flow | Vulnerable to supply disruptions; requires reliable partners |
| World Class Manufacturing (WCM) | Holistic framework integrating safety, quality, cost, delivery, and environment; pillar-based (e.g., focused improvement, autonomous maintenance). | 10-20 pillars (e.g., TPM for maintenance), audits/scoring | Fiat/Chrysler plants (pillar audits), heavy industry | Comprehensive; measurable progress | Complex rollout; resource-intensive |
| Sustainable Manufacturing | Integrates environmental/social responsibility with efficiency; reduces resource use, emissions, and waste for long-term viability. | Life-cycle assessment, circular economy principles, green metrics | Textiles (recycled materials), energy (renewable sourcing) | Eco-compliance; appeals to modern markets | Higher upfront costs; regulatory variability |
- Start with Core Patterns: Check /patterns/core/isa95-hierarchy.yaml for a base UNS template. Customize by adding levels based on the types/methodologies above.
- Prototype: Use included C# or Python snippets to build a simple MQTT publisher/subscriber. Deploy to your home K8s lab or EKS for testing—focus on prototyping first, add ACLs/JWT later for security.
- Extend for Your Industry: Fork and add subdirs like /patterns/pharma/ with tailored YAML. For UI (if needed), suggest Vue3 with Vuetify for quick dashboards.
- Discuss: Open issues for ideas on variations, trade-offs, or integrations (e.g., bridging to RDBMS for queries).
This is just a starting point—let's iterate together.
Pull requests are encouraged! Please follow a simple PR template: Describe the change, why it fits (e.g., aligns with ISA-95), and any backend examples. Keep it collaborative.
MIT License – feel free to use, modify, and share as permitted by this licensing model.