Beyond Purdue No. 003 / Operations, Video
When 6 Vendors and 1 EPC Collide – and Operators Lose Millions
This article continues our Beyond Purdue series, where we said goodbye to outdated layers and introduced the Three-Channel Model. Now, let's take a closer look — starting with a story you might...

This article continues our Beyond Purdue series, where we said goodbye to outdated layers and introduced the Three-Channel Model. Now, let's take a closer look — starting with a story you might find all too familiar.
Goodbye Layers, Welcome Channels
⚡ A Story of Too Many Vendors, Too Many Errors
Imagine six vendors and one EPC contractor trying to piece together a power plant’s billing system — each working independently, each speaking a different data language. What could possibly go wrong? In this case: millions lost in penalties and operational chaos.
The task is simple: gather metering data for billing — accurately, securely, and in real time.
What actually happens?
- Vendor 1: Database system for metering readings (with random delays)
- Vendor 2: Software for OPC DA tunneling from DCS to the "Billing Gateway," responsible for gathering flow meters readings and other environmental data
- Vendor 3: Billing Gateway "integrator" trying to integrate many data sources with different tag names, incorrect timestamps, and data available at random times
- Vendor 4: Supplier of random, cheap desktop PCs not fit for purpose, often using USB network connections instead of proper network cards
- Vendor 5: Data diode supplier with limited supported protocols, no support beyond the first year, and systems often hiding password thus no modification possible
- Vendor 6: Billing system software vendor who require validated data files in exactly defined file structure with different names to be delivered via FTP every six minutes
Each vendor uses different tag naming, non-synchronized data, and inconsistent timestamps. Coordination falls to the EPC contractor, but the result?
When "integration" means patchwork, not structure.

❌ Data inconsistencies
❌ Delayed metering signals
❌ A lot of manual interventions
❌ Costly penalties under the PWPA (Power and Water Purchase Agreements)
Sound familiar?
This isn't rare. It's the reality when data architecture is treated as an afterthought — and when "integration" means patchwork, not structure.
🔍 Project Analysis: Where It Breaks Down
The failure wasn't just technical. It was systemic.
The primary reason the previous system was failing was the way the data sources operated. The data wasn’t consistently available when needed, often resulting in missing or incorrect records — especially energy counters critical for billing.
But even deeper than timing issues, we had to deal with a far more critical challenge. Each system — whether OPC DA, OPC UA, or control platforms like Emerson and Siemens — impose its own set of allowed characters for tag names, often introducing strange and inconsistent symbols such as &, ;, _, -, and && within communication protocols. This lack of standardization in tag structures further complicated integration, creating yet another layer of confusion that traditional layered ICS architectures are ill-equipped to handle. We discovered a far more critical and systematic flaw:
Inconsistent tag naming and data meaning across systems and vendors.
In this case simple metering signal could pass through six or more "translations":
- KKS name in the T3000 control system
- Modified OPC UA tag
- Altered again for OPC DA servers
- Further changed at the DataPass system (or whatever intermediate gateway is being used)
- Renamed completely at the FDM (Fuel Data Model) system
- And finally reinterpreted by the Electricity and Water Authority (EWA) billing database
The result? Confusion, human error, lost accountability — and financial penalties. And beyond that, an even bigger challenge: a jungle of mismatched lists, protocols, and documents from different systems that can't be compared or correlated with each other in any structured way.
The result? Confusion, human error, lost accountability — and financial penalties.
Recommended by LinkedIn

This fragmentation of information is why traditional integration keeps failing — and why we urgently need a consistent, scalable system for managing industrial data. Just as the internet solved human communication chaos with DNS, industrial systems must follow the same principle.
This paves the way for a new approach: a DNS-based system for the Plant Information and Control System, where every signal is reliably identified, understood, and trusted across all systems.
This inconsistency, more than anything else, revealed the limitations of how traditional layered ICS and DCS systems are built. It shows why rigid layered architectures fail — they simply cannot cope with the dynamic, unstructured chaos of real-world data. Rather than building yet another set of rigid and disconnected layers, we need purposeful, managed channels — precisely why the Multi-Channel Model matters more today than ever.
🛠️ A New Foundation: Structuring Plant Information
At Bohemia Market, we see the future differently.
Instead of continuing to pile up disconnected systems, each with its own layers, naming rules, and timing chaos, we propose a new model: applying the principles that made the Internet resilient — consistent identification (DNS-style system), robust information flow, and secure separation of trusted and untrusted domains.
The inspiration? The DNS (Domain Name System) model — a globally proven, resilient method to organize complex information.
We envision a Plant Information and Control System that not only organizes its own data but seamlessly connects systems from different OEMs — even without their cooperation or awareness — eliminating traditional vendor lock-in.
Our ICS Secure Data Transfer solution suite — with two core models, SecureRTU and SecureDCS — is the first step toward this future. It is based on principles introduced in our patent (EP3734376B1), which defines a new method for building control systems around structured information flows, eliminating OEM dependency, and enabling autonomous, intelligent data management across disconnected environments.
Using a DNS-style system, every tag, no matter how it is named across various systems, will be reliably mapped and found — all organized in one single place using a proven, distributed DNS approach, even if the data originates from many different departments or independent sources. This methodology is particularly beneficial to large corporations with many assets, where multiple layers, legacy systems, and varied departments make unified information management a major challenge.
Patents and real-world implementations of these ideas are already underway and will be shared in future editions.
🤖 Bringing Edge Intelligence to Data Management
Imagine this practical capability:
Every six minutes, an Edge AI Node assembles an intelligent data file:
- Correctly timestamps delayed signals from metering databases
- Captures real-time DCS counters exactly when sampled
- Adjusts for processing delays automatically
- Recalculates missing signals based on machine states and operations
- Packages clean, verified data for billing, reporting, and prediction
This is no longer theory. We’ve already built gateways that perform exactly this task, even handling late-arriving OPC signals and assembling final files without human intervention.
The plant becomes self-aware of its operational truth — independent of manual corrections, vendor-specific quirks, or network disruptions.
Are you ready to lead the future of power generation and water desalination control systems?
We believe it's not only possible — it's happening now.
🚀 What's Next
In upcoming articles, we will:
- Compare data diode solutions and discuss error handling
- Show cloud solution which allows safe access to data from anywhere
- Share real-world project examples where structure replaced chaos
The future of ICS isn't just "connected." It's understood, structured, and secured.
Stay tuned.


