Home › O-PAS Pilot Project Planning
Selection · Scope · Evidence · Scale-Up
Choose a pilot that solves a real operating need, represents the architecture decisions the wider program must make, and produces evidence management can use to decide what happens next.
The short answer
An effective O-PAS pilot is a bounded production or production-representative project that tests the owner’s most important architecture, integration, application, operating and lifecycle assumptions against predefined evidence.
The pilot should address a funded business or operating need, include enough multi-supplier scope to expose real boundaries, and remain small enough to isolate, verify, recover and learn from safely. Its purpose is to reduce uncertainty before scale-up—not merely to show that selected products can communicate.
Define the decision the pilot must support, the evidence required for that decision, and the acceptance authority before products and suppliers shape the scope.
01 · Purpose
OPA pilots often begin with a technology question: can components from different suppliers exchange information? That question matters, but it is too narrow to support an owner’s deployment decision. A scalable program also needs evidence about process-control behavior, application ownership, engineering workflow, system management, cybersecurity, supplier coordination, recovery, operating workload and lifecycle change.
The pilot charter should state the decision that will be made when the work is complete. Examples include whether to proceed to a production unit, adopt a reference architecture, qualify a supplier combination, approve an application strategy, use a migration pattern, or revise the business case.
State the investment, architecture, procurement or deployment decision the evidence must support.
Identify the assumptions that could change cost, risk, schedule, operability or lifecycle value.
Specify measurements, demonstrations, records, witnesses and acceptance authority before execution.
02 · Candidate selection
The easiest isolated application is not automatically the best pilot. It may prove too little. The largest production area may represent the future well but expose the first project to too much operational risk.
Candidate A
A real operating scope with a clear boundary and manageable consequence.
Candidate B
A funded lifecycle need that connects OPA adoption to unavoidable work.
Candidate C
A new control, optimization or analytics capability on open compute.
Candidate D
A bounded operating area with meaningful availability and support requirements.
Candidate E
A clean boundary without legacy control cutover.
Candidate F
A controlled environment that reproduces selected architecture, load and failure conditions.
| Selection factor | Strong candidate | Weak candidate |
|---|---|---|
| Business need | Solves a funded operational, lifecycle or capability requirement. | Exists only because the technology is available to demonstrate. |
| Architecture coverage | Exercises interfaces, applications and management functions needed later. | Avoids the boundaries that create program uncertainty. |
| Risk boundary | Can be isolated, tested, recovered and supported safely. | Failure would expose a large operating area or critical schedule. |
| Evidence quality | Produces measurable operating and engineering results. | Success is based mainly on stakeholder impressions. |
| Repeatability | Methods and assets can become the next project’s baseline. | Depends on one-off supplier effort or undocumented knowledge. |
| Scale relevance | Represents important future products, roles and workflows. | Uses atypical conditions that will not recur. |
03 · Scope framework
A decision-grade pilot should state what is included, what is represented, what is deferred and which conclusions the missing scope prevents.
Define the process, operating need, production consequence, availability requirement, users, interfaces, project constraints and decision the pilot supports.
Show which future architecture roles, networks, retained systems, field interfaces, computing resources and management functions are represented.
Name exact offered products, versions, claimed profiles, evidence, dependencies, limitations, supplier boundaries and planned substitutions.
Define IEC 61131 languages, libraries, interfaces, source ownership, build and deployment workflow, runtime assumptions and portability demonstration.
Name the party accountable for the integrated pilot, interface decisions, configuration baseline, supplier coordination, issue resolution and correction.
Define zones, conduits, identity, certificates, access, hardening, monitoring, patch treatment, remote support, incident roles and recovery.
Specify components, simulations, loads, tools, reset method, evidence capture, supplier access, duration and conditions deferred to site.
For brownfield pilots, define coexistence, legacy interfaces, cutover sequence, control authority, abort criteria, restoration path and stabilization.
Demonstrate inventory, monitoring, deployment, backup, restore, patching, component replacement, supplier escalation and baseline control.
Identify the architecture, requirements, source, configurations, procedures, tests, evidence, lessons and commercial positions retained for scale-up.
04 · Success criteria
Specified data, semantics, quality, timing and failure behavior work across selected supplier boundaries under representative load.
Loops, sequences, interlocks, alarms and operator functions satisfy defined functional and performance criteria.
Applications can be built, deployed, versioned, rolled back and—where required—moved using the contracted owner assets.
Communication loss, restart, failover, partial recovery and restoration produce the required system and process response.
Identity, access, trust, communication, hardening, logging, remote support and recovery meet the pilot requirements.
The team can identify the baseline, apply a controlled change, recover it and replace a defined component through documented workflows.
Actual architecture, integration, application, test and correction hours are recorded by activity and supplier boundary.
Operators and maintainers can diagnose, operate, support and recover the pilot with defined tools, procedures and competence.
Supplier obligations, cross-boundary issue ownership, support response and correction treatment work as contracted.
The accepted architecture, requirements, templates, tests, evidence and lessons can reduce uncertainty on the next deployment.
Set numeric thresholds where the decision requires them—for example execution timing, recovery time, engineering hours, defect closure, availability or operator workload. Avoid invented universal targets; use the facility’s risk, process and business requirements.
05 · Governance
| Party | Typical pilot responsibility | Decision authority or evidence |
|---|---|---|
| Executive sponsor | Owns the business question, funding boundary and decision expected from the pilot. | Approves charter, gates and scale-up decision. |
| Owner architecture authority | Controls principles, requirements, deviations, evidence expectations and reusable reference assets. | Approves architecture and accepted exceptions. |
| Operations and maintenance | Define operating requirements, procedures, usability, maintainability, recovery and support acceptance. | Witness operational demonstrations and accept readiness. |
| EPC or project manager | Coordinates scope, schedule, procurement, suppliers, risks, deliverables and commercial change. | Maintains project controls and contractual closure. |
| System integrator | Owns integrated design, configuration baseline, interface resolution, application deployment and test execution. | Produces integrated evidence and closes boundary failures. |
| Component suppliers | Provide exact products, evidence, engineering support, limitations, corrections and lifecycle position. | Support product-level requirements and assigned tests. |
| Cybersecurity authority | Approves risk basis, architecture, access, monitoring, tests, exceptions and operational handover. | Accepts security evidence and residual risk. |
| Acceptance authority | Determines whether criteria are met and whether open items permit progression. | Signs gate decisions, deviations and final disposition. |
Adapt the O-PAS Responsibility Matrix to the pilot contract. A small scope still needs one accountable integration authority.
06 · Procurement and evidence
Require product identity, evidence scope, interfaces, dependencies, limitations, support status and substitution rules.
Allocate architecture, configuration, applications, supplier coordination, test development, correction and commissioning.
Define what is physical, simulated or deferred; who hosts it; how suppliers access it; and how long it remains available.
Require baseline manifests, procedures, logs, measurements, issues, corrections, effort records, approvals and exceptions.
Specify source, libraries, configurations, build and deployment packages, test assets, documentation and reuse rights.
Define support periods, vulnerabilities, updates, response times, cross-supplier escalation and replacement positions.
Use the O-PAS Procurement Specification Checklist to structure the RFQ and the O-PAS Vendor and Product Landscape to identify candidates without allowing the available product stack to define the pilot architecture.
07 · Decision gates
Business decision, candidate, boundary, assumptions, success criteria, budget, authority and scale-up question are explicit.
Roles, interfaces, profiles, retained systems, applications, cybersecurity, management and migration design are reviewable.
Products, suppliers, evidence, responsibilities, test support, correction terms, deliverables and owner rights are contracted.
Components, versions, configurations, applications, interfaces, certificates, tools and known deviations are controlled.
Functional, interoperability, failure, recovery, security, deployment, replacement and management criteria have evidence.
Site conditions, migration, rollback, procedures, training, support, monitoring and unresolved risks permit deployment.
Stabilization results, operator experience, maintenance workload, incidents, engineering effort and supplier performance are recorded.
Management approves expansion, targeted remediation, another bounded pilot or closure based on the original decision criteria.
08 · Verification
| Test domain | Representative pilot scenario | Evidence retained |
|---|---|---|
| Functional control | Normal operation, sequences, interlocks, alarms and operator action under representative process conditions. | Requirements traceability, procedure, actual results, trends and approval. |
| Interoperability | Multi-supplier data exchange under expected load, invalid data, communication loss and restoration. | Interface baseline, logs, measurements, failures, corrections and retest. |
| Application lifecycle | Build, deploy, update, roll back and restore an owner-controlled application package. | Source identity, build record, deployment record and functional comparison. |
| Cybersecurity | Identity, privilege, trust failure, logging, remote support, patch treatment and selected incident response. | Configuration, events, access records, test results and accepted exceptions. |
| System management | Discover assets, reconcile the baseline, monitor health, back up, recover and introduce a controlled update. | Inventory, baseline manifest, change record, recovery result and audit trail. |
| Replacement | Replace a selected component and restore its configuration, interfaces, application behavior and accepted service state. | Procedure, elapsed effort, dependencies, regression results and revised baseline. |
| Brownfield transition | Exercise coexistence, control transfer, abort criteria, rollback and restoration across a retained-system boundary. | Sequence, authority, timestamps, results, exceptions and stabilization record. |
| Support model | Diagnose and escalate a failure whose symptom crosses two supplier products. | Issue timeline, ownership, supplier responses, resolution and commercial disposition. |
Develop this program using the O-PAS FAT and Interoperability Testing Guide, the O-PAS Cybersecurity Requirements Guide and the O-PAS System Management and Lifecycle Operations Guide.
09 · Scale-up
Proceed
Adopt the accepted reference architecture, requirements, supplier model, application rules, tests and lifecycle workflows for the next bounded deployment.
Remediate
Continue only after specified architecture, product, supplier, workflow, evidence or organizational gaps are corrected and retested.
Redirect
Revise the architecture, candidate scope, migration sequence, commercial model or business case when the evidence invalidates a core assumption.
The reusable output is more valuable than the installed pilot equipment alone. Capture the accepted architecture, requirement library, supplier evidence, interface records, application package, configuration baseline, test assets, responsibility matrix, engineering effort, defects, operational lessons and unresolved limits.
Update the Open Process Automation Business Case with measured pilot costs and benefits rather than replacing facility-specific analysis with one pilot result. For brownfield expansion, use the Brownfield OPA Migration Strategy to sequence the next increments.
Frequently asked questions
A strong first pilot solves a real funded need, represents important future architecture and supplier boundaries, has manageable operational consequence, can be isolated and recovered, produces measurable evidence, and creates reusable assets for the next deployment.
Not always. A production pilot provides the strongest operating and lifecycle evidence, but a production-representative environment can retire substantial integration, application, cybersecurity, replacement and recovery risk first. The charter should state which conclusions require later site evidence.
Measure the criteria needed for the program decision: interoperability, control performance, application deployment and portability, resilience, cybersecurity, lifecycle workflows, engineering effort, operator usability, maintenance workload, supplier response, recovery and reusable documentation.
No. Product evidence and point-to-point communication can support selection, but the pilot must also test the selected products as an integrated system under the project’s architecture, configuration, loading, failure, security, recovery and lifecycle conditions.
The owner should retain the business, architecture and acceptance authority. One named system integrator should be accountable for the integrated pilot, while the EPC or project manager and component suppliers perform their contracted delivery and product responsibilities.
Handover should include the accepted architecture, requirements, exact baseline, source and deployment assets, supplier evidence, interfaces, configurations, certificates, procedures, test records, defects, engineering effort, responsibility model, operational lessons and scale-up recommendations.
Large enough to represent the architecture decisions and supplier boundaries the program needs to test, but small enough to isolate, integrate, verify, recover and learn from without exposing the facility to disproportionate first-project risk. There is no universal I/O count or project value.
Turn uncertainty into evidence
CSI helps owner/operators and EPCs select OPA pilots, define representative architecture and scope, assign suppliers, establish success criteria, develop verification plans and convert results into an executable scale-up roadmap.