Decision maturity
Target architecture, component roles, retained systems and responsibility boundaries.
Home › O-PAS Project Schedule and Integration Milestone Planning
Project Schedule · Supplier Dependencies · Integration Gates · FAT · Cutover
O-PAS project schedule and integration milestone planning Schedule evidence maturity, not just equipment delivery
A practical guide for owner, EPC and system-integration teams building an executable O-PAS multi-vendor schedule from architecture and supplier information through integration, FAT, site acceptance, cutover, stabilization and lifecycle handover.
The short answer
An O-PAS project schedule needs integration and evidence gates between supplier delivery and site commissioning.
Plan the dates when architecture decisions, interface definitions, supplier information, exact product baselines, IEC 61131 applications, integration environments, integrated releases and acceptance procedures become usable. Then schedule correction and regression cycles before FAT, site-readiness gates before SAT and cutover, and operating-support readiness before handover. A supplier shipment date does not establish that the assembled system is ready for the next project phase.
01 · Schedule basis
Use the O-PAS Project Change Order and Scope Growth Management Guide →
Build the schedule around technical readiness
Start with the decisions and evidence each downstream activity needs, then assign supplier, owner, EPC and integrator dates backward from the required operating milestone.
Supplier inputs
Product data, interfaces, configuration, dependencies, evidence and release information.
IEC 61131 releases
Source, libraries, build assets, runtime allocation and testable application baselines.
Representative environment
Products, versions, services, supplier access and controlled integrated releases.
Acceptance maturity
Requirements, procedures, expected results, correction status and approved baseline.
Site readiness
Infrastructure, access, training, support, cutover and recovery prerequisites.
Schedule stop condition: FAT has a calendar date, but the schedule contains no predecessor for integrated baseline maturity, supplier correction or approved test procedures.
02 · Schedule levels
Carry O-PAS dependencies from master schedule to working plan
| Schedule level | O-PAS content |
|---|---|
| Master milestones | Architecture freeze, integration-ready baseline, FAT release, site-ready release, cutover and handover. |
| Control schedule | Supplier releases, interface maturity, IEC 61131 application releases, environment setup, correction cycles and acceptance preparation. |
| Look-ahead | Specific products, configurations, interfaces, tests, defects, supplier actions and evidence required in the next execution window. |
03 · Required information dates
Schedule information before the work that consumes it
| Information | Needed before | Schedule consequence if late |
|---|---|---|
| Architecture allocation | Detailed supplier design and interface definition. | Rework and unresolved procurement boundaries. |
| Exact product/version | Configuration, product evidence review and integration baseline. | Environment mismatch and invalidated evidence. |
| Interface definition | Mapping, application work and interoperability procedure development. | Late integration discovery. |
| IEC 61131 application basis | Runtime allocation, build, deployment and functional testing. | Application release and FAT delay. |
| Cybersecurity inputs | Identity, certificate, access and hardening configuration. | Integrated communications unavailable or untestable. |
| Acceptance requirements | Procedure development and witness planning. | FAT becomes requirements discovery. |
04 · Supplier schedule integration
Schedule deliverables, not just purchase-order dates
Each supplier schedule should expose the information and participation the integrated project needs.
Technical information
Product identity, interfaces, dependencies, configuration, evidence and lifecycle position.
Usable baselines
Hardware, software, firmware, configuration and application versions for integration.
Integration participation
Supplier resources for setup, diagnosis, correction, regression and witnesses.
Response commitments
Time to diagnose, provide fixes, issue releases and support retest.
Field participation
SAT, commissioning, cutover, stabilization and issue-resolution windows.
Lifecycle deliverables
Source, configuration, licenses, procedures, training and support activation.
Use the O-PAS Supplier Bid Evaluation and Technical Comparison Guide to make supplier schedule commitments visible before award.
05 · Interface maturity
Make interface readiness a predecessor to integration
| Maturity state | Exit evidence | Downstream release |
|---|---|---|
| Identified | Provider, consumer, purpose and accountable owner. | Detailed definition may begin. |
| Defined | Information, commands, states, quality, diagnostics, security and failure behavior. | Configuration and procedure development may begin. |
| Configured | Implemented mappings, endpoints, security and project configuration. | Representative integration may begin. |
| Verified | Expected behavior demonstrated with defects dispositioned. | Interface may enter the FAT baseline. |
Use the O-PAS Interface Definition and Boundary Management Guide to define the controlled maturity basis.
06 · IEC 61131 application releases
Schedule applications as controlled baselines
Application dates should distinguish engineering maturity from a release that is ready for integration or formal acceptance.
| Release | Minimum content |
|---|---|
| Engineering baseline | Source, libraries, functional definition and initial runtime allocation sufficient for development. |
| Integration release | Controlled source/build, dependencies, mappings and expected behavior suitable for representative integration. |
| FAT release | Approved version with required pre-FAT regression complete and open defects dispositioned. |
| Site release | Accepted FAT baseline plus approved post-FAT changes and site deployment package. |
Use the O-PAS Application Portability Guide for source, runtime, dependency and deployment control.
07 · Integration environment
Fund time for integration before formal acceptance
Environment ready
Representative infrastructure, services, access, tools and baseline-control process are operating.
Products introduced
Exact products and versions are installed, configured and inventoried.
Interfaces integrated
Boundary behavior is exercised and defects are recorded.
Applications deployed
IEC 61131 releases execute in the intended runtime allocation with dependencies controlled.
Failure scenarios exercised
Loss, restart, recovery, replacement and resilience behavior are explored before formal test.
Correction cycle closed
Supplier fixes are introduced and affected regression is complete.
FAT baseline released
The integrated configuration is stable enough for contractual testing.
Do not schedule FAT as the first integration event
Formal acceptance should consume a controlled baseline, not discover whether the supplier combination works.
Use the Integration Environment and Testbed Planning Guide →08 · Correction and regression cycles
Put defect resolution on the schedule before defects exist
Multi-vendor schedules should contain planned correction windows between integration releases and acceptance gates.
| Activity | Schedule basis |
|---|---|
| Triage | Time to reproduce, preserve evidence, assign technical ownership and establish operating consequence. |
| Supplier analysis | Contracted response period for diagnosis and proposed correction. |
| Corrected release | Build, supplier verification and controlled delivery into the integration environment. |
| Retest | Direct verification plus selected regression based on impact. |
| Baseline reconciliation | Update versions, configuration, evidence and open-item status before the next gate. |
09 · FAT entry and exit gates
Make FAT readiness measurable
Controlled baseline
Exact products, versions, configuration and IEC 61131 application releases identified.
Approved procedures
Requirements, expected results, witnesses, data and defect rules agreed.
Integration maturity
Exploratory integration complete and blocking pre-FAT defects closed.
Executed evidence
Required product review, interoperability, functional, failure and recovery evidence complete.
Defect disposition
Blocking defects closed; accepted open items assigned with clear treatment.
Site release
Approved baseline and controlled post-FAT change process released toward site.
Use the O-PAS FAT and Interoperability Testing Guide for the evidence basis behind these gates.
10 · Site, SAT and cutover
Schedule site readiness as more than construction complete
| Gate | Required readiness |
|---|---|
| Site installation | Approved products, infrastructure, field interfaces, services and controlled site configuration. |
| SAT entry | Installed baseline, field readiness, approved procedures, supplier support and acceptance authority. |
| Cutover entry | Blocking SAT items closed, rollback executable, operations ready and decision authority present. |
| Stabilization exit | Required operating period complete, defects dispositioned and support model demonstrated. |
| Handover | Accepted baseline, source/configuration, procedures, training, access, support and lifecycle custody transferred. |
Use the O-PAS Commissioning, Site Acceptance and Cutover Guide for detailed site gates.
11 · Schedule controls
Track evidence maturity alongside percent complete
Six-week readiness
Products, interfaces, applications, procedures, supplier actions and decisions needed for upcoming gates.
Technical blockers
Missing information, unresolved boundaries, unavailable releases, defects and owner decisions.
Release status
Which exact integrated baseline each test, shipment or site activity assumes.
Schedule exposure
Supplier response, first-of-kind interfaces, correction cycles and site windows.
Impact assessment
Effect of product, interface, application or acceptance changes on downstream milestones.
Evidence-based dates
Forecast gates from predecessor maturity rather than preserving an unsupported calendar date.
12 · Contract schedule
Make supplier dates enforceable at the points the project needs them
Contract milestones should include technical submittals, integration-ready releases, correction response, test support and lifecycle deliverables, not only shipment and site attendance.
| Contract milestone | Evidence of completion |
|---|---|
| Technical data complete | Approved product identity, interfaces, dependencies and required design information. |
| Integration release | Usable product/configuration baseline with supplier support available. |
| Correction release | Approved fix delivered within the contracted response window. |
| FAT support complete | Supplier obligations, defects and retest commitments dispositioned. |
| Site support complete | Commissioning, SAT and stabilization obligations fulfilled. |
| Lifecycle handover complete | Required source, configuration, licenses, training, support and records accepted. |
13 · Connected guidance
Connect schedule milestones to the complete execution chain
Estimate
Project Estimating
Price the resources and correction cycles behind the schedule.
OwnersResponsibility Matrix
Assign every scheduled deliverable and decision.
IntegrationIntegration Environment
Plan the pre-FAT integration and correction window.
ChangeChange and Regression
Control schedule impact when the baseline changes.
FATFAT and Interoperability
Define formal acceptance entry and exit evidence.
SiteCommissioning and Cutover
Carry the accepted baseline through site and handover.
Frequently asked questions
O-PAS project scheduling questions
What is different about scheduling an O-PAS multi-vendor project?
The schedule must coordinate architecture decisions, supplier information, interfaces, IEC 61131 application releases, representative integration, cross-supplier correction, formal acceptance and lifecycle handover across multiple commercial boundaries.
Should FAT be the first time O-PAS products are integrated?
No. Representative integration should occur before formal FAT so exploratory engineering and major cross-supplier correction can be completed before contractual acceptance testing begins.
What should be complete before O-PAS FAT starts?
The integrated baseline should be identified and stable, required interfaces and applications should be integrated, procedures and expected results approved, blocking pre-FAT defects closed and suppliers ready to support formal execution and correction.
How should IEC 61131 applications appear in the project schedule?
Track controlled engineering, integration, FAT and site releases with source, libraries, dependencies, runtime allocation and regression status rather than one generic software-complete milestone.
How much time should be allowed for correction and retest?
There is no universal duration. Base it on interface maturity, supplier response commitments, release process, test scope and project consequence, and schedule explicit cycles rather than assuming first-pass acceptance.
How does CSI support O-PAS project scheduling?
CSI helps owners and EPCs define technical milestones, supplier information dates, interface and application releases, integration windows, correction cycles, FAT/SAT gates, cutover prerequisites and lifecycle handover dependencies.
Before FAT becomes the first real integration milestone
Build the O-PAS schedule around technical readiness
CSI can help owner and EPC teams connect supplier commitments, interface maturity, IEC 61131 application releases, integration, correction and acceptance into an executable project schedule.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. This guide is a project-planning aid and does not imply endorsement by The Open Group. The applicable contract, owner requirements, approved project schedule, current O-PAS Standard and current certification records govern the project.