Baseline and design the migration
Inventory tags, alarms, scripts, licenses, historian interfaces and retained data. Verify the supported version and virtualization matrix before selecting the target.
← Project library
ARCHITECTURE EXAMPLE
AVEVA System Platform and PI modernization
An illustrative supervisory and historian modernization plan, with separate availability, recovery and data continuity checks.
For Enterprise architects · SCADA managers · Operations leaders
The operational challenge
A facility with standalone operator stations and inconsistent historical records needs managed engineering changes, common equipment context and a tested recovery plan.
Candidate stack: AVEVA System Platform and OMI · PI Data Archive and Asset Framework · Windows Server · VMware vSphere / ESXi. Final selection depends on the actual site, supported versions, licenses and intended use.
The architectural strategy
Build reusable supervisory objects
Plan a Galaxy repository and reusable equipment templates. Review the alarm philosophy, operator navigation and acceptance tests with operations before deployment.
Create historian asset context
Map approved PI points into AF assets, templates and units. Define Event Frame trigger rules and test event boundaries and time consistency against known examples.
Test each resilience layer
Engineer application redundancy separately from hypervisor high availability. VM restart, fault tolerance, application failover and historian continuity have different behavior and prerequisites; test them individually, including backup restore and rollback.
Proposed information flow
Sanitized conceptual view. Each numbered boundary requires an approved interface; this is not an installation drawing.
- Equipment dataApproved connectors, source timestamps and quality
- Supervisory layerManaged Galaxy objects, application engines and OMI
- Historian contextPI points, AF assets and tested Event Frames
- Operations evidenceTrends, failover tests, backups and recovery records
Operational impact
Verification status: evidence pending
No operational impact has been verified for this proposed architecture. The blueprint describes intended benefits; dated baseline and post-change measurements, the test period and acceptance by the responsible plant owner are needed before publishing them as achieved results.
Verification plan
Agree the baseline, test conditions, acceptance limits and evidence owners before implementation.
| Measure | Evidence to collect |
|---|---|
| Fault identification | Use repeatable trip scenarios to time detection and diagnosis against a baseline, with equivalent operator conditions. |
| Availability and recovery | Define the measurement period, outage boundaries, RTO and RPO. Test host, application, storage and interface failures; record data gaps. |
| Engineering maintenance | Time a controlled template change, regression checks, deployment and rollback on a representative equipment set. |
Expected project deliverables
- Version and dependency inventory
- Object, tag and AF mapping specifications
- Migration, cutover and rollback plan
- Failover, recovery and operator acceptance evidence
These deliverables would form part of an agreed engagement. This page does not establish certification, regulatory approval, guaranteed availability or an achieved operational result.