Open Process Automation (OPA) has crossed an important threshold. The standards are real. Reference architectures exist. Multi-vendor interoperability has been demonstrated. End users are no longer debating whether open control systems make sense — they are asking how to make them work in production.
This is where a hard truth emerges.
Open systems don’t assemble themselves.
OPA defines what should be possible. But standards alone do not deliver systems that can be deployed, operated, secured, updated, and supported over decades in mission-critical environments. That gap — between architectural promise and operational reality — is where most open-system initiatives historically stall.
Understanding that gap is essential to understanding why CPLANE exists.
Standards Define Possibility. Systems Deliver Reality.
The OPA reference architecture intentionally stops short of prescribing how multi-vendor systems should be managed in practice. This restraint is a strength at the standards level — but it creates a challenge at the system level.
As Don Bartusiak of ExxonMobil noted when discussing the motivation behind OPA:
“Standards are necessary, but they’re not sufficient to deliver a complete, operational system.”
— Don Bartusiak, ExxonMobil (Why End Users Are Driving the Open Process Automation Standard, ~10:41)
In production environments, “working together” means far more than communicating over standard interfaces. A real control system must answer questions like:
- How are devices discovered, provisioned, and verified?
- How are updates applied without shutting operations down?
- How is resilience maintained during failures or maintenance?
- How is security enforced continuously, not just at install time?
- Who owns the system when something breaks?
These are not standards questions. They are system questions.
The Myth of “Just Integrate the Pieces”
A common assumption is that systems integrators can simply assemble OPA-compliant components into a functioning whole. In reality, this approach breaks down quickly at scale.
Brandon Williams, discussing the ExxonMobil OPA pilot, highlighted where complexity accumulates:
“Once you move beyond a demo, you quickly realize that orchestration, lifecycle management, and system state become the hard part.”
— Brandon Williams, Next Generation IT/OT Convergence: ExxonMobil + CPLANE, ~12:08
Without a unifying system layer:
- Each component has its own management model
- Security policies fragment
- Updates become risky
- Troubleshooting turns into multi-vendor finger-pointing
The result is not openness — it is operational fragility.
This is why OPA does not claim that interoperability alone delivers production readiness. It never has.
IT Tools Don’t Translate Cleanly to OT Reality
Another tempting shortcut is to apply IT orchestration tools directly to operational technology (OT) environments. While IT platforms excel at managing cloud workloads, they often fall short in control environments where determinism, safety, and uptime are non-negotiable.
As discussed during the OPA demonstrations, OT systems must handle:
- Real-time process dynamics
- Safety constraints
- Long-lived assets
- Limited maintenance windows
“IT orchestration tools don’t understand control system timing, device behavior, or safety constraints.”
— Demo of Open Process Automation, ~18:22
Bridging IT and OT requires more than repurposing existing tools. It requires a system designed specifically for control environments — one that respects OT realities while enabling modern lifecycle practices.
The Missing Layer: Systemness
Across OPA pilots and demonstrations, a consistent insight has emerged: the hardest part is not interoperability — it is systemness.
Systemness is what turns components into a coherent, operable whole. It includes:
- Unified system state and health awareness
- Coordinated lifecycle management
- Security enforcement as a system property
- Software-defined resilience
- Clear ownership and accountability paths
Without this layer, open systems remain fragile prototypes. With it, they become production platforms.
As one ExxonMobil pilot participant summarized:
“The novelty isn’t the components — it’s making the system behave like a system.”
— Next Generation IT/OT Convergence Pilot, ~15:04
Why Accountability Matters as Much as Architecture
One of the most persistent objections to open control systems is deceptively simple:
“Who do I call when something breaks?”
In proprietary platforms, the answer is clear — even if the solution is not. In multi-vendor systems, that clarity must be designed deliberately.
OPA enables interoperability, but it does not define support models. That responsibility sits above the standard.
During discussions around production readiness, end users repeatedly emphasized the need for a clear escalation path:
“If this is going to run the plant, we need one accountable path — not a vendor guessing game.”
— OPA Forum discussion, ~21:47
This is not a commercial detail. It is a prerequisite for adoption in mission-critical environments.
Where CPLANE Fits — and Why It Exists
CPLANE exists precisely in this gap between standards and systems.
It is not another DCS. It does not replace OPA standards. Instead, it provides the commercial system layer that turns OPA from an architectural concept into a deployable, supportable control system.
CPLANE focuses on:
- System orchestration across multi-vendor components
- Security by design, enforced continuously
- Software-defined resilience and high availability
- In-process updates with minimal disruption
- Structured support and escalation workflows
In other words, CPLANE productizes the hard parts that standards intentionally leave open.
From “Open” to Operable
OPA has already succeeded in one critical way: it changed the conversation. End users are no longer debating whether proprietary lock-in is acceptable. They are deciding how to avoid repeating it.
But avoiding lock-in does not mean accepting chaos.
Open systems must still be:
- Reliable
- Secure
- Upgradable
- Supportable
They must still run plants.
As Ron Bro of Wind River put it:
“Open interoperable systems are inevitable — but they still have to work.”
— Ron Bro, Wind River (Why End Users Are Driving the Open Process Automation Standard, ~23:40)
That is the challenge CPLANE was built to solve.
The Shift from Standards to Systems
OPA defines the future of industrial control architecture. CPLANE exists because someone must take responsibility for making that future operable in production.
In the posts that follow, we’ll go deeper into:
- Why orchestration is the real bottleneck in OPA deployments
- How security-by-design works at runtime
- What software-defined resilience changes about uptime economics
- How accountability is preserved in open, multi-vendor systems
Standards set the direction.
Systems make the direction achievable.
