Information Management and AI in Modern Manufacturing

Here's a scenario: You're a multi-site manufacturer with historians at 40 locations. Some are OSIsoft PI installations from 10 years ago. Others are newer systems from different vendors. When you assess them, you find that half work fine for their current role. No technical reason to replace them.

But now you want to deploy standardized analytics, event detection, KPI calculations, cross-site comparisons. To do this with traditional architecture, you must standardize on one historian platform. That means ripping out systems that work perfectly fine just to bring everything under one roof.

The uncomfortable choice:

• Keep mixed historians → No way to standardize analytics
• Replace working systems → Waste millions on unnecessary infrastructure

The deeper issue:

Even if you do standardize on one historian, you've only solved one problem while creating another. That historian is a time-series specialized system. It does one thing brilliantly: store sensor data at high frequency with lossless compression.

But analytics need more than time-series data. They need:

• Transactional data from ERP systems
• Quality records from lab systems
• Maintenance history from CMMS
• Inventory data from warehouse management
• Production schedules from MES

A time-series historian isn't designed to handle this contextual data. So you build custom integrations pulling from multiple systems for every analytics project. No reusability. No standardization. Just bespoke data wrangling for each use case.

This is the historian trap: the system that solved your data storage problem a decade ago is now the bottleneck preventing you from scaling analytics.

Jeff Knepper, President of Flow Software and former Executive Director at Canary Labs, watched this pattern repeat across hundreds of manufacturers. After helping build the Sparkplug working group and spending a decade in industrial data management, he realized the need for what he calls the Unified Analytics Framework to solve this challenge.

‍

‍

Where the UNS Architecture Actually Breaks

‍

The Unified Namespace movement correctly identified a critical problem: too many point-to-point integrations creating unmaintainable spaghetti. The solution—a central broker with hub-and-spoke architecture—elegantly handles real-time data flow.

But there are three fundamental limitations that emerge when you try to use UNS for analytics:

Limitation 1: Historical data access breaks hub-and-spoke

You cannot query nine days of raw historical data from an MQTT subscribing client, through the broker, to a publishing client. The broker holds last-known values, not history. This means:

• For real-time monitoring: UNS works perfectly
• For any analytics requiring history: You need separate connections to historians/databases
• Result: Point-to-point integrations return, just for different reasons

Limitation 2: Namespace versioning destroys continuity

Your carefully designed namespace structure will evolve. You'll refine it, add context, restructure as you learn. That's healthy. But what happens to your historical data when you change a tag name?

The day you modify your naming convention, you get a new tag in your historian. The old tag stops updating. Now you have discontinuous history—the exact problem you were trying to avoid. No single historian platform solves this automatically, because the identity of the data (its name/path) changed.

You can't name your convention "right" once and forever. The business changes. Equipment changes. Your understanding improves. The architecture needs to handle evolution, not assume perfection from day one.

Limitation 3: Analytics context lives in the wrong place

When engineers at the plant floor build metrics, they understand operational context: valve states that invalidate sensor readings, normal behavior vs. drift, calibration schedules, process dependencies.

When data teams at corporate build the same metrics for executive dashboards, they lack that context. They don't know which edge cases to handle or which data cleansing rules to apply.

If these two groups build metrics independently—plant floor using real-time tools, corporate using the data lake—the numbers will never match. Trust breaks down. "The business is using the wrong KPIs" becomes the constant refrain from operations.

You need one place where metrics get defined, contextualized, and calculated, then propagated both to real-time systems and historical analytics. The UNS doesn't provide this.

‍

The Unified Analytics Framework - The Layer You're Missing

‍

The solution isn't replacing the UNS. It's adding a complementary analytics layer that handles what brokers can't: historical queries, cross-system context, and knowledge modeling.

The architecture:

Data sources → Analytics Framework → UNS (real-time) + Data Lake (historical)

The Unified Analytics Framework sits on top of your existing data sources (historians, SQL databases, MES, ERP, CMMS) and provides:

Capability 1: Federated historical access

Query across multiple historians and databases without moving data. The framework understands how to pull context-rich historical data from wherever it lives. This means:

• Keep existing historians that work fine
• Add new storage as needed
• No requirement to standardize on single vendor
• Queries span all sources seamlessly

Capability 2: Operational data modeling

This is where your plant engineers define what data means. Build models that capture:

• Asset hierarchies and relationships
• Process context and dependencies
• Data quality rules specific to equipment
• Event definitions and calculations
• Relationships between metrics

Critically, these models are built by people who understand operations, not data teams guessing at context from afar.

Capability 3: Knowledge graphs beyond hierarchies

ISA-95 hierarchies work for some use cases. But AI agents need to understand relationships that cross hierarchical boundaries:

• Which assets share common failure modes?
• What upstream processes affect downstream quality?
• Which suppliers correlate with which product issues?

Knowledge graphs let you link related objects across your entire operation, not just parent-child relationships within one line or one site.

Capability 4: Data reshaping and publishing

Take raw data from multiple sources, apply your operational models, calculate derived metrics, add context—then publish results back to:

• The UNS broker (enriched real-time data)
• Cloud data warehouses (for BI tools)
• Other operational systems that need calculated values

This is where you bridge the gap between OT data at the edge and IT consumption at the enterprise.

‍

Why Your Engineers Must Build the Models (Not Your Data Team)

‍

There's a critical organizational insight hidden in this architecture: data modeling must happen at operations, not in corporate IT.

The context problem:

Your data lake team can build a "utility consumption" KPI. They'll pull flow meter data, apply standard aggregations, generate reports. Technically correct.

But your plant engineer building the same KPI knows that flow readings are invalid when the valve is closed (sensor noise from electromagnetic feedback). They write data cleansing rules nullifying those periods. The numbers don't match.

Multiply this across dozens of KPIs, and you have a trust crisis. Operations doesn't believe corporate dashboards because "they don't understand our process." Executives don't trust operations' numbers because "they're not following data governance standards."

The solution:

Make it necessary for operations to build models by making models required for their daily work. Don't ask engineers to model data as extra work. Give them tools where modeling data makes their diagnostics, troubleshooting, and analytics easier.

When operations builds the model once—with all the context, cleansing rules, and domain knowledge—that model propagates to:

• Real-time operational dashboards
• Historical analytics in the data lake
• Executive reports
• AI model inputs

Same definitions. Same calculations. One version of truth. Trust maintained across the organization.

Implementation reality:

This is a 40-hour project for two production lines with a few metrics. Not boiling the ocean. Then you templatize and scale—10 more lines becomes another 10 hours. You're solving problems in bite-sized chunks while building reusable infrastructure.

‍

MCP and AI Agents: Getting the Implementation Right

‍

Model Context Protocol (MCP) from Anthropic promises to standardize how AI agents interact with applications. But most implementations are failing because companies are just wrapping REST APIs and calling it "MCP support."

That's not enough for complex manufacturing systems.

What agents actually need:

Remember Jarvis from Iron Man? Tony Stark's agent followed him everywhere—into the workshop, the car, the boardroom, and could interact with any system Tony needed. That only worked because Jarvis had:

• Connectivity: Ability to reach every system
• Tools: Know-how to actually do tasks (not just see that a connection exists)
• Context: Understanding of what each tool does and when to use it
• Instructions: Guidance on handling errors and edge cases

Most MCP implementations provide connectivity but not the other three.

Manufacturing-specific challenges:

General-purpose AI models don't understand manufacturing terminology. "Tag" means something completely different in manufacturing than in the model's training data. "Batch," "run," "campaign," "recipe"—all carry specific meanings an agent won't grasp without context.

Giving an agent too much context also degrades performance. You need narrow, focused context for each tool—explaining exactly what it does, when to use it, and how to handle common issues.

A product approach:

Build 18-20 specialized tools for your analytics platform. The first tool an agent encounters provides an execution plan showing how to use all the others to accomplish tasks. Each tool includes:

• Specific manufacturing context (what "tag" means in your system)
• Usage instructions tailored to common analytics workflows
• Error handling guidance
• Constraints on what actions are safe

This isn't an MCP project you hand to users. It's a product that works out of the box because you've done the hard work of encoding domain knowledge into the agent's toolset.

Trust but verify:

Even with perfect tooling, never let agents make decisions autonomously. They're searchlights showing where to look, not autonomous decision-makers. Every recommendation must be inspected before action.

When agents build models or queries, keep those isolated from production until human review elevates them. The agent can work 10x faster than manual building, but you need the safety of review before committing to live systems.

Conclusion

If you're implementing UNS, don't stop there. You're solving real-time data flow but not analytics. The moment someone asks for a 30-day report or wants to build KPIs across multiple historians, your clean architecture breaks down into point-to-point integrations again.

The Unified Analytics Framework isn't a replacement for UNS, it's the complementary layer that makes UNS practical for real-world analytics needs. You need both:

• UNS handles real-time last-known values with clean pub/sub architecture
• Analytics framework handles historical access, cross-system modeling, and knowledge graphs

Most critically, this framework must live at operations, not in corporate IT. The engineers who understand process context must build the models that define what data means. Otherwise, you'll forever have mismatched KPIs, broken trust, and analytics that operations won't use because "they don't understand our process."

The companies winning with manufacturing AI aren't building better models. They're building better information architecture—where data gets modeled once, close to the source, by people who understand it, then propagates everywhere it's needed with full context intact.

Your competitors are probably still treating every analytics project as a custom integration. That's your window. Build the framework that lets you define metrics once and reuse them everywhere. That's the only way to scale from pilots to production across your entire enterprise.

Start small—two lines, a few metrics, 40 hours. Prove the pattern. Then scale through templating. The architecture grows with you, unlike the monolithic "rip and replace everything" approaches that fail because they try to boil the ocean.

Because at the end of the day, if your architecture can't answer "show me 30 days of history" without breaking your hub-and-spoke pattern, you don't have an analytics architecture. You have a real-time monitoring system with a bunch of custom integrations bolted on.

And that won't scale to AI.

‍

‍