# AVEVA System Platform — Upstream OPC UA Server Research

> **Status**: DRAFT — closes corrections-doc finding E2. Research deliverable for the v2 plan; informs the tier-3 (System Platform IO) cutover scheduled for Year 3 of the 3-year plan.
>
> **Branch**: `v2`
> **Created**: 2026-04-17

## Question

Can AVEVA System Platform (formerly Wonderware) consume equipment data from an arbitrary upstream OPC UA server (in our case `OtOpcUa`) instead of talking to equipment directly? This is the technical premise of tier 3 of the consumer cutover (handoff §"Rollout Posture", Year 3).

## Verdict — GREEN-YELLOW

**The cutover is technically supported.** AVEVA has a documented, official path for AppServer's IO layer to consume from any compliant OPC UA server via the **OI Gateway** communication driver. Multiple AVEVA partners (Software Toolbox, InSource) have published end-to-end integrations against four different non-AVEVA upstream servers (TOP Server, OPC Router, OmniServer, Cogent DataHub).

The yellow comes from two unanswered items in public sources: (1) GxP / 21 CFR Part 11 validation guidance for non-AVEVA upstream servers, and (2) published scale benchmarks for OI Gateway's OPC UA client. Both are integrator-burden items, not blockers.

## 1. Does AppServer's IO layer support an upstream OPC UA server?

Yes — through the **OI Gateway** communication driver (formerly "Wonderware Gateway", "FSGateway", product code `OI.GATEWAY.3`). OI Gateway is an OPC UA client that republishes data to System Platform via SuiteLink. AppServer attributes reference data through a DI Object pointing at the OI Gateway instance.

AVEVA's official docs page "Configure an OPC UA data source object" describes adding an `OPCUA Connection` under OI Gateway, entering a Server Node (localhost / IP / hostname), and browsing the upstream server's namespace ([docs.aveva.com](https://docs.aveva.com/bundle/sp-appserver/page/689813.html)).

**Sources** confirming the pattern is intentionally generic:
- [AVEVA docs: Configure an OPC UA data source object](https://docs.aveva.com/bundle/sp-appserver/page/689813.html)
- [AVEVA docs: Connect to an OPC UA data source](https://docs.aveva.com/bundle/sp-cdp-drivers/page/202524.html)
- [Software Toolbox: System Platform → TOP Server via OPC UA](https://blog.softwaretoolbox.com/topserver-aveva-system-platform-opc-ua)
- [Software Toolbox: System Platform → OPC Router via OPC UA](https://blog.softwaretoolbox.com/opc-router-aveva-system-platform-opc-ua)
- [Software Toolbox: System Platform → OmniServer via OPC UA](https://blog.softwaretoolbox.com/omniserver-aveva-system-platform-opc-ua)
- [Software Toolbox: System Platform → Cogent DataHub via OPC UA](https://blog.softwaretoolbox.com/cogent-datahub-aveva-system-platform-opc-ua)

## 2. IO reference shape

AppServer does not have a native "OPC UA IO reference" type; the path is:

```
OPC UA node  →  OI Gateway (OPC UA client)  →  SuiteLink  →  $DDESuiteLinkDIObject  →  AppServer attribute
```

Attribute `IO.SourceAttribute` syntax:

```
<SuiteLinkDIObjectName>.<TopicName>.<ItemReference>
```

where `TopicName` matches the OPC UA Group defined inside OI Gateway, and `ItemReference` is the OPC UA node (browsed or manually entered).

**From System Platform 2023 R2 Patch 01 onward**: AppServer/Industrial Graphics scripts can also call OPC UA methods on the upstream server via the Gateway driver, and the External Providers pane exposes the Gateway's configured OPC UA servers directly in the Tag Dictionary ([2023 R2 P01 Readme](https://docs-be.aveva.com/bundle/sp-2023-r2-p01-readme/raw/resource/enus/sp-2023-r2-p01-readme.pdf)).

## 3. Restrictions and requirements for the upstream OPC UA server

### Security (documented)

| Setting | Supported values |
|---------|------------------|
| Security policy | `None`, `Basic128Rsa15`, `Basic256`, `Basic256Sha256` (default + recommended) |
| Message security mode | `None`, `Sign`, `SignAndEncrypt` |
| User token | Anonymous, Username/Password (cert-based not called out) |

**Hard rule** from UA SDK v1.7.0 onward: if username/password is used, security policy cannot be `None` ([AVEVA Communications Drivers Pack 2020 R2 Gateway Readme](https://industrial-software.com/wp-content/uploads/Communication_Drivers/oi-communication-drivers-pack-2020-r2/Readme_Gateway.html)).

TLS stack is OpenSSL — `1.1.1g` in 2020 R2, upgraded to `1.1.1n` in System Platform 2023 ([System Platform 2023 Readme](https://industrial-software.com/wp-content/uploads/AVEVA_SystemPlatform/2023/ReadMe.html)).

### Certificates

OI Gateway auto-generates a client cert on first test connection and pushes it to the upstream server. Server-side admin must move it from rejected/quarantine to Trusted. Reverse direction (trusting the server cert on OI Gateway's side) is handled via OI Gateway's client security certificate pane ([AVEVA docs: OI Gateway client cert](https://docs.aveva.com/bundle/intouch-hmi/page/732922.html)).

### Namespace structure

**No mandated structure.** OI Gateway browses whatever the server exposes. There is an optional **Tag Prefix** column to strip a common namespace prefix and reduce item-name length in subscriptions.

### OPC UA Companion Specifications

**No AVEVA documentation found that requires** OPC 40010 Machinery, PA-DIM, or any other companion spec. OI Gateway behaves as a vanilla DA-style subscription client. **Implication for OtOpcUa**: our `_base` equipment-class template alignment with OPC 40010 is a *cross-system consistency* benefit, not an AppServer-required feature.

### Subscription / sampling

Configured per OPCUAGroup (publishing interval, sampling). **Specific documented limits not found in public readmes** — see §6 (Performance / scale).

## 4. Minimum versions

| Version | Capability |
|---------|------------|
| OI Gateway 2.0+ (Wonderware AppServer 2017 Update 3 / Comm Drivers Pack) | First OPC UA client capability |
| Communications Drivers Pack 2020 R2 | First broadly-documented baseline |
| System Platform 2020 | Native OPC UA *server* added (separate feature) |
| System Platform 2023 | OpenSSL upgraded to 1.1.1n; endpoint/security-policy browsing added |
| **System Platform 2023 R2 Patch 01** | **Recommended floor** — script-level OPC UA method calls + External Providers UI |

Recommend a greenfield deployment standardize on System Platform 2023 R2 P01 + the Comm Drivers Pack that ships with it.

## 5. Validated / GxP / 21 CFR Part 11

AVEVA has a [21 CFR Part 11 doc page](https://docs.aveva.com/bundle/system-platform/page/338331.html) for System Platform but the Zoomin-rendered content was not extractable over HTTP; AVEVA's Part 11 story centers on electronic signatures, audit trails, and secure user access at the AppServer / InTouch layer, with AVEVA PI often cited as the validated historian.

**No AVEVA document was found that explicitly addresses inserting a non-AVEVA OPC UA server between equipment and AppServer for a validated deployment.** This does not mean it's prohibited — it means the validation burden (qualification, change control, data-integrity evidence) falls on the integrator. Plan to:

- Produce an IQ/OQ package for OtOpcUa itself
- Map OtOpcUa controls to ALCOA+ data-integrity principles and 21 CFR Part 11 §11.10(a)–(k)
- Run a change-control impact assessment against the existing validated AppServer deployment when introducing OtOpcUa as the upstream IO source
- Engage QA / regulatory early (well before Year 3) so the validation paperwork doesn't gate the cutover

## 6. Performance / scale guidance

**Public AVEVA documentation does not publish per-topic item limits, max subscription counts, or throughput benchmarks** for OI Gateway's OPC UA client. The Gateway readme only mentions the Tag Prefix optimization and a note that parallel driver instances improve throughput ([AVEVA Communication Drivers product page](https://www.aveva.com/en/products/communication-drivers/)).

For a sizing commitment: benchmark in-house at target item count, publishing interval, and `SignAndEncrypt` security mode, **before tier 3 cutover scheduling**. Open an AVEVA support case if the in-house benchmark surfaces concerns; AVEVA support has performance data they don't publish.

## 7. Practical reports — teams doing this in production

- **Software Toolbox** has production-grade walkthroughs for four different non-AVEVA upstream servers (TOP Server, OPC Router, OmniServer, DataHub — links in §1). Consistent pattern: OPCUA Connection → OPCUAGroup → SuiteLink DI → `$AnalogDevice` / `$DiscreteDevice` attributes.
- **Inductive Automation forum**: ["Wonderware as OPC UA Client"](https://forum.inductiveautomation.com/t/wonderware-as-opc-ua-client/55888) — user connected OI Gateway to an Ignition OPC UA server. **Two recurring failure modes worth pre-empting in OtOpcUa's onboarding runbook**:
  1. `Bad_SecurityChecksFailed` after trusting the cert — fix was **removing `/discovery` from the endpoint URL** (`opc.tcp://host:port` not `opc.tcp://host:port/discovery`)
  2. Worked only with `None` after a hostname rename invalidated the Common Name on the reissued cert. **Pin cert CN to hostname; don't rename hosts post-issue.**
- **InSource Tech Note DAS153** ([knowledge.insourcess.com](https://knowledge.insourcess.com/aveva-communication-drivers-tech-notes/tn-das153-connecting-to-an-opc-ua-server-through-the-wonderware-gateway-oi-server)) — canonical AVEVA-partner procedure for the OPCUA Connection + OPCUAGroup + Activate pattern.
- **No public reports found** of teams deploying AppServer against a fully-custom in-house OPC UA server at scale. All published examples are against commercial upstream servers. **OtOpcUa would be the first of its kind in the public record** — not necessarily a problem, but worth noting that we won't have prior-art to lean on for tuning at production scale.

## 8. Known incompatibilities / hard blockers

- **OI Gateway under SYSTEM account cannot connect to a remote OPC server** (known issue per the 2020 R2 readme). Use a dedicated service account.
- **Endpoint URL sensitivity** to `/discovery` suffix (see §7).
- **Cert Common Name must match hostname** in use.
- **No deprecation timeline** found for OI Gateway's OPC UA client; AVEVA actively enhanced it in 2023 and 2023 R2 P01 (positive signal — AVEVA still investing in this path).
- **Public docs make no commitment** on OPC UA Companion Specifications. If OtOpcUa's future uplift relies on PA-DIM or Machinery types being consumed by AppServer specifically, validate that on a real deployment first.

## Implications for OtOpcUa Implementation

**Things to bake in earlier rather than retrofit:**

1. **`Basic256Sha256` + `SignAndEncrypt` + Username token must work** — this is the recommended-and-most-secure combination AppServer expects. v2's transport security model (`docs/v2/plan.md` §"Transport Security") already commits to `Basic256Sha256-Sign` and `-SignAndEncrypt` profiles per Phase 1. Confirm during Phase 1 implementation that the combination of `Basic256Sha256` + `SignAndEncrypt` + LDAP username token works end-to-end.
2. **Endpoint URL hygiene**: don't expose `/discovery` as part of the canonical endpoint URL operators copy. If we surface a "connection string for AppServer" in the Admin UI's Cluster Detail page, render it as `opc.tcp://{host}:{port}` with no path suffix.
3. **Certificate / hostname stability**: per decision #86, `ApplicationUri` is auto-suggested but never auto-rewritten because OPC UA clients pin trust to it. AppServer is exactly that case. The Admin UI's "warn on `Host` change" affordance applies directly here. Document the hostname-stable-certs requirement explicitly in the deployment guide.
4. **Service-account install** — OtOpcUa already runs as a Windows service per Phase 1 decisions; just make sure the deployment guide explicitly says **don't** run AppServer's OI Gateway under SYSTEM when pointing at OtOpcUa.

**Things NOT required by AppServer that we still chose for other reasons** — useful to know they're not load-bearing for tier 3 specifically:
- OPC 40010 Machinery alignment in the `_base` template — for cross-system consistency (Redpanda, dbt, MQTT projection), not because AppServer reads it
- `_base` template's Identification fields exposed as OPC UA properties — for general client convenience, not because AppServer reads them

## Risks for the implementation team

In priority order:

1. **Validation / GxP story is the integrator's problem.** AVEVA has no published blueprint for Part 11 deployments where a non-AVEVA OPC UA server sits between equipment and AppServer. Budget IQ/OQ work for OtOpcUa itself and a change-control impact assessment against the existing validated AppServer deployment.
2. **Scale is unpublished.** Benchmark OI Gateway → OtOpcUa at target item count, publishing interval, and `SignAndEncrypt` security mode before cutover scheduling. Don't assume the current direct-equipment IO rates carry over.
3. **First-of-its-kind deployment.** All published partner examples use commercial upstream servers (Kepware, OPC Router, etc.). OtOpcUa would be the first custom in-house upstream server in the public record. Mitigation: stand up a non-production AppServer + OtOpcUa pairing well before tier 3 cutover begins, exercise the full Software Toolbox-style configuration walkthrough, and capture lessons.

## Recommendation

**Tier 3 cutover is feasible and can stay on the Year 3 schedule.** No re-architecting of OtOpcUa is required to support it. The implementation team should:

- Add **Phase 1 acceptance test**: AppServer (any version ≥ 2023 R2 P01) connects to OtOpcUa via OI Gateway with `Basic256Sha256` + `SignAndEncrypt` + username token; reads at least one tag end-to-end through a SuiteLink DI Object.
- Add **`docs/deployment/aveva-system-platform-integration.md`** (separate doc, post-Phase-1) covering: OI Gateway version requirements, certificate exchange procedure, endpoint URL convention (no `/discovery`), service-account install requirement, common failure modes from §7.
- **Schedule the validation/QA conversation in Year 1** so paperwork doesn't gate the Year 3 cutover.
- **Stand up a non-production AppServer + OtOpcUa pairing in Year 2** for the first-of-its-kind benchmarking and operational learning.

## Decisions to add to plan.md

| # | Decision | Rationale |
|---|----------|-----------|
| 141 | Tier 3 (AppServer IO) cutover is feasible — AVEVA's OI Gateway supports arbitrary upstream OPC UA servers as a documented pattern | Closes corrections-doc E2 with **GREEN-YELLOW** verdict. Multiple AVEVA partners have published working integrations against non-AVEVA upstream servers. No re-architecting of OtOpcUa required. See `aveva-system-platform-io-research.md` |
| 142 | Phase 1 acceptance includes an end-to-end AppServer-via-OI-Gateway smoke test against OtOpcUa | Catches the AppServer-specific quirks (cert exchange, endpoint URL handling, service account, `Basic256Sha256` + `SignAndEncrypt` + username token combo) early — well before Year 3 cutover schedule | 

## References

- [AVEVA docs: Configure an OPC UA data source object](https://docs.aveva.com/bundle/sp-appserver/page/689813.html)
- [AVEVA docs: Connect to an OPC UA data source](https://docs.aveva.com/bundle/sp-cdp-drivers/page/202524.html)
- [AVEVA docs: OI Gateway OPC UA config (GATEWAY4OI4OPCUA)](https://docs.aveva.com/bundle/sp-cdp-drivers/page/GATEWAY4OI4OPCUA.html)
- [AVEVA docs: OI Gateway client security certificate](https://docs.aveva.com/bundle/intouch-hmi/page/732922.html)
- [AVEVA docs: 21 CFR Part 11 in System Platform](https://docs.aveva.com/bundle/system-platform/page/338331.html)
- [AVEVA Communications Drivers Pack 2020 R2 Gateway Readme](https://industrial-software.com/wp-content/uploads/Communication_Drivers/oi-communication-drivers-pack-2020-r2/Readme_Gateway.html)
- [AVEVA System Platform 2023 Readme](https://industrial-software.com/wp-content/uploads/AVEVA_SystemPlatform/2023/ReadMe.html)
- [AVEVA System Platform 2023 R2 Patch 01 Readme](https://docs-be.aveva.com/bundle/sp-2023-r2-p01-readme/raw/resource/enus/sp-2023-r2-p01-readme.pdf)
- [AVEVA Communication Drivers product page](https://www.aveva.com/en/products/communication-drivers/)
- [Software Toolbox: System Platform → TOP Server via OPC UA](https://blog.softwaretoolbox.com/topserver-aveva-system-platform-opc-ua)
- [Software Toolbox: System Platform → OPC Router via OPC UA](https://blog.softwaretoolbox.com/opc-router-aveva-system-platform-opc-ua)
- [Software Toolbox: System Platform → OmniServer](https://blog.softwaretoolbox.com/omniserver-aveva-system-platform-opc-ua)
- [Software Toolbox: System Platform → Cogent DataHub](https://blog.softwaretoolbox.com/cogent-datahub-aveva-system-platform-opc-ua)
- [InSource TN DAS153: Gateway OI Server → OPC UA](https://knowledge.insourcess.com/aveva-communication-drivers-tech-notes/tn-das153-connecting-to-an-opc-ua-server-through-the-wonderware-gateway-oi-server)
- [Inductive Automation forum: Wonderware as OPC UA Client](https://forum.inductiveautomation.com/t/wonderware-as-opc-ua-client/55888)
- [OPC Connect: Turning Wonderware System Platform into an OPC UA Server (2017)](https://opcconnect.opcfoundation.org/2017/06/turning-wonderware-system-platform-into-an-opc-ua-server/)
