Files

Joseph Doherty 1189dc87fd Close corrections-doc E2 (Aveva System Platform IO upstream-OPC-UA pattern verification) with GREEN-YELLOW verdict (decision #141 ) — AVEVA's OI Gateway communication driver is the documented path for AppServer to consume from arbitrary upstream OPC UA servers; 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). No re-architecting of OtOpcUa required. Path: OPC UA node → OI Gateway → SuiteLink → $DDESuiteLinkDIObject → AppServer attribute. Recommended AppServer floor: System Platform 2023 R2 Patch 01.

OtOpcUa-side requirements all met or trivially met by v2: Basic256Sha256 + SignAndEncrypt + username token (transport security covers this), reject-and-trust cert workflow, endpoint URL must NOT include /discovery suffix (forum-documented failure mode), hostname-stable certs (decision #86 already enforces this since clients pin trust to ApplicationUri), OI Gateway service must NOT run under SYSTEM (deployment-guide concern). Two integrator-burden risks tracked: validation/GxP paperwork (no AVEVA blueprint exists for non-AVEVA upstream servers in Part 11 deployments — engage QA/regulatory in Year 1) and unpublished scale benchmarks (in-house benchmark required in Year 2 before cutover scheduling).

Phase 1 acceptance gains Task E.10 (decision #142): end-to-end AppServer-via-OI-Gateway smoke test against a Phase 1 OtOpcUa instance, catching AppServer-specific quirks (cert exchange, endpoint URL handling, service account, security mode combo) well before the Year 3 tier-3 cutover schedule. Non-blocking for Phase 1 exit if it surfaces only documentation-level fixes; blocking if it surfaces architectural incompatibility.

New file `docs/v2/aveva-system-platform-io-research.md` captures the full research with all source citations (AVEVA docs, Communications Drivers Pack readmes, Software Toolbox / InSource partner walkthroughs, Inductive Automation forum failure-mode reports). Plan.md decision log gains #141 and #142; Reference Documents section links the new doc.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-17 13:27:13 -04:00

17 KiB

Raw Blame History

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).

Sources confirming the pattern is intentionally generic:

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).

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).

TLS stack is OpenSSL — 1.1.1g in 2020 R2, upgraded to 1.1.1n in System Platform 2023 (System Platform 2023 Readme).

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).

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 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).

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" — 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) — 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:

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.
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.
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.
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:

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.
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.
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

17 KiB Raw Blame History Unescape Escape