Open Process Automation (OPA) promises a future of interoperable, multi-vendor control systems that evolve continuously instead of locking operators into decades-long platforms. For many end users, that promise is compelling — even inevitable.
But one question consistently stops the conversation cold:
“Who do we call when something breaks?”
This is not a procurement detail or a legal footnote. In mission-critical control environments, accountability is as important as architecture. If an open system cannot provide a clear, trusted answer to this question, it will never run a plant.
Understanding how accountability works in open control systems — and how it differs from proprietary models — is essential to understanding why platforms like CPLANE exist.
Why Proprietary Systems Feel “Safer” Than They Are
Traditional DCS and PLC platforms offer a simple value proposition: one vendor owns the stack. When something goes wrong, there is one number to call.
That simplicity has real value. But it also masks structural risk.
Proprietary systems concentrate responsibility — and control — in a single vendor. That means:
- Upgrade timing is dictated by vendor roadmaps
- Security posture is dependent on vendor priorities
- Innovation is constrained by closed architectures
- Long-term lock-in is unavoidable
As Don Bartusiak of ExxonMobil has noted in the context of modernization decisions:
“When you commit to a proprietary system, you’re committing to that vendor’s pace of innovation for the next couple of decades.”
— Don Bartusiak, ExxonMobil (Why End Users Are Driving the Open Process Automation Standard, ~04:58)
In other words, proprietary systems offer short-term accountability at the expense of long-term flexibility and control.
Why Accountability Gets Harder in Open Systems
OPA intentionally breaks the monolithic vendor model. Components come from multiple suppliers. Innovation comes from ecosystems.
But ecosystems introduce a new risk: diffuse responsibility.
Without a system-level accountability model:
- Vendors blame each other
- Integrators are caught in the middle
- Operators are left diagnosing system-level failures themselves
This fear is not hypothetical. It is one of the most frequently cited concerns raised by end users evaluating OPA.
As one participant stated during an OPA forum discussion:
“Interoperability is great — until something breaks and everyone points somewhere else.”
— OPA Forum discussion, ~21:47
OPA standards deliberately avoid defining support models. That is not an oversight — it reflects the reality that accountability must be implemented operationally, not standardized abstractly.
Accountability Is a System Design Problem
A common misconception is that accountability can be solved purely through contracts. In practice, contracts follow architecture — not the other way around.
Accountability requires:
- Clear system boundaries
- Unified system state visibility
- Repeatable diagnostic workflows
- Defined escalation paths
- A single operational narrative of “what happened”
Without these, even the best-written contracts devolve into disputes.
As Brandon Williams observed when reflecting on early OPA pilots:
“If you don’t have a system-level view, you can’t even agree on what failed — let alone who owns it.”
— Brandon Williams, Next Generation IT/OT Convergence: ExxonMobil + CPLANE, ~14:41
This is why accountability must be designed into the system layer, not bolted on after deployment.
How Accountability Works in Practice in Open Control
In production-grade open control systems, accountability is typically structured across three layers:
1. Systems Integrator: First-Line Ownership
Systems integrators (SIs) remain the first line of support, just as they are today. They:
- Understand the plant context
- Handle configuration and change management
- Respond to incidents on site or remotely
OPA does not remove SIs from the equation. It makes their role more scalable and repeatable.
2. System Platform: Escalation and Coordination
Above the SI sits the system platform — the layer that understands the system as a whole.
This layer:
- Maintains a unified view of system state
- Coordinates diagnostics across vendors
- Provides structured issue tracking
- Escalates to component vendors with evidence, not speculation
Without this layer, SIs are forced to manually correlate logs, configurations, and timelines across incompatible tools.
3. Component Vendors: Domain Expertise
Individual vendors remain accountable for their components — but within a framework that defines how issues are surfaced, reproduced, and resolved.
This structure replaces finger-pointing with evidence-based escalation.
Why CPLANE Treats Support as Part of the Product
CPLANE was built with the explicit assumption that support infrastructure is as critical as control logic.
Rather than treating support as an afterthought, CPLANE productizes:
- System-wide health and state visibility
- Structured issue tracking tied to system events
- Clear escalation workflows across vendors
- A path to 24/7 support coverage for open systems
This is not about centralizing blame. It is about centralizing coordination.
As one ExxonMobil pilot participant emphasized:
“We needed a clear, accountable path — even in a multi-vendor system.”
— Next Generation IT/OT Convergence Pilot, ~18:09
That clarity is what allows open systems to be trusted with mission-critical operations.
Accountability Without Lock-In
One of the most important — and often misunderstood — aspects of open-system accountability is that it does not require returning to vendor lock-in.
In fact, properly designed accountability depends on openness.
Because system behavior is observable, standardized, and testable:
- Root causes can be identified faster
- Issues can be isolated more precisely
- Responsibility can be assigned based on evidence
This is fundamentally different from proprietary systems, where visibility is often limited to what the vendor exposes.
The Shift From “Who Do I Call?” to “How Do We Resolve This?”
In mature open systems, the accountability conversation changes.
Instead of:
- “Which vendor is at fault?”
The question becomes:
- “What failed, why did it fail, and how do we prevent it next time?”
That shift is only possible when the system itself provides a shared, trusted source of truth.
Accountability Is the Gate to Production
End users are clear-eyed about this: interoperability is necessary, but accountability is the gate to production.
OPA enables open architectures. CPLANE exists because someone must take responsibility for making those architectures operable, supportable, and trustworthy at scale.
In the next post, we’ll examine how security-by-design operates at runtime in open control systems — and why trust, verification, and containment must live at the system layer.
