From 42af4fd9767455b6339377394d9685e3ec1a8d30 Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Fri, 17 Apr 2026 13:27:28 -0400 Subject: [PATCH] =?UTF-8?q?Mark=20corrections-doc=20E2=20(Aveva=20System?= =?UTF-8?q?=20Platform=20IO=20pattern=20verification)=20as=20RESOLVED=20wi?= =?UTF-8?q?th=20GREEN-YELLOW=20verdict=20=E2=80=94=20the=20OtOpcUa=20team?= =?UTF-8?q?=20completed=20the=20research,=20published=20findings=20at=20lm?= =?UTF-8?q?xopcua/docs/v2/aveva-system-platform-io-research.md,=20and=20ad?= =?UTF-8?q?ded=20a=20Phase=201=20acceptance=20test=20(Task=20E.10,=20decis?= =?UTF-8?q?ion=20#142)=20to=20catch=20AppServer-specific=20quirks=20well?= =?UTF-8?q?=20before=20the=20Year=203=20tier-3=20cutover=20schedule.=20AVE?= =?UTF-8?q?VA's=20OI=20Gateway=20is=20the=20documented=20path;=20multiple?= =?UTF-8?q?=20non-AVEVA=20upstream-server=20integrations=20exist=20in=20pu?= =?UTF-8?q?blished=20partner=20walkthroughs;=20no=20re-architecting=20of?= =?UTF-8?q?=20OtOpcUa=20needed.=20Two=20integrator-burden=20risks=20the=20?= =?UTF-8?q?plan=20team=20should=20track:=20validation/GxP=20paperwork=20(n?= =?UTF-8?q?o=20AVEVA=20Part=2011=20blueprint=20for=20non-AVEVA=20upstream?= =?UTF-8?q?=20servers=20=E2=80=94=20engage=20QA/regulatory=20in=20Year=201?= =?UTF-8?q?)=20and=20unpublished=20scale=20benchmarks=20(in-house=20benchm?= =?UTF-8?q?ark=20required=20in=20Year=202=20before=20tier-3=20cutover=20sc?= =?UTF-8?q?heduling).?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.7 (1M context) --- handoffs/otopcua-corrections-2026-04-17.md | 28 ++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/handoffs/otopcua-corrections-2026-04-17.md b/handoffs/otopcua-corrections-2026-04-17.md index 1fe1fd7..924a90d 100644 --- a/handoffs/otopcua-corrections-2026-04-17.md +++ b/handoffs/otopcua-corrections-2026-04-17.md @@ -351,11 +351,31 @@ Questions the plan didn't think to ask but should have, surfaced during v2 desig --- -### E2. Tier 3 (System Platform IO) cutover — Aveva-supported pattern verification +### E2. Tier 3 (System Platform IO) cutover — Aveva-supported pattern verification — **RESOLVED (GREEN-YELLOW)** **Question:** Does Aveva System Platform IO support consuming equipment data from another OPC UA server (OtOpcUa) instead of from equipment directly? The handoff §"Downstream Consumer Impact" says this "needs validation against Aveva's supported patterns — System Platform is the most opinionated consumer." -**Recommendation:** plan should commit to a research deliverable in Year 1 or Year 2 (well ahead of Year 3 tier 3 cutover): "Validate with Aveva that System Platform IO drivers support upstream OPC UA-server data sources, including any restrictions on security mode, namespace structure, or session model." If Aveva's pattern requires something OtOpcUa doesn't expose, that's a long-lead-time discovery. +**Resolution** (lmxopcua decision #141, 2026-04-17): **YES — supported pattern.** AVEVA's OI Gateway communication driver is an OPC UA client that bridges arbitrary upstream OPC UA servers into AppServer via SuiteLink + DI Object. 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 (OPC UA client) → SuiteLink → $DDESuiteLinkDIObject → AppServer attribute (IO.SourceAttribute = ..)`. + +**Recommended AppServer floor**: System Platform 2023 R2 Patch 01 (best OPC UA client maturity, script-level method calls, External Providers UI in Tag Dictionary). + +**Documented OtOpcUa-side requirements** (already met or trivially met by v2): +- `Basic256Sha256` security policy + `SignAndEncrypt` message mode (OtOpcUa Phase 1 transport security covers this) +- Username/password user token over encrypted channel (LDAP-bound per `Security.md`, no change needed) +- Reject-and-trust certificate workflow on OtOpcUa side (standard OPC UA, no change needed) +- Endpoint URL of form `opc.tcp://{host}:{port}` — must NOT include a `/discovery` suffix (forum-documented failure mode) +- Hostname-stable certificates (per OtOpcUa decision #86 — `ApplicationUri` is auto-suggested but never auto-rewritten because clients pin trust to it; this case is exactly that) +- OI Gateway service must NOT run under SYSTEM (known AVEVA issue) — deployment-guide concern, not OtOpcUa-side + +**Two integrator-burden risks** the plan team should track: +1. **Validation/GxP paperwork**: 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 + change-control impact assessment against the existing validated AppServer deployment. Engage QA / regulatory **early in Year 1** so paperwork doesn't gate the Year 3 cutover. +2. **Scale benchmarks**: AVEVA does not publish per-topic item limits or throughput numbers for OI Gateway's OPC UA client. **Stand up a non-production AppServer + OtOpcUa pairing in Year 2** to benchmark at target item count + publishing interval + `SignAndEncrypt` security mode before tier 3 cutover scheduling. + +**Phase 1 acceptance test added** (lmxopcua decision #142, Task E.10 in `phase-1-configuration-and-admin-scaffold.md`): end-to-end AppServer-via-OI-Gateway smoke test against a Phase 1 OtOpcUa instance. Catches the AppServer-specific quirks (cert exchange, endpoint URL, service account, security mode combo) at Phase 1, well before Year 3 cutover. Non-blocking for Phase 1 exit if it surfaces only documentation-level fixes; blocking if it surfaces architectural incompatibility. + +Full research write-up: `lmxopcua/docs/v2/aveva-system-platform-io-research.md`. --- @@ -437,7 +457,7 @@ Neither of these affects the handoff or this corrections doc directly. | B. Missing constraints | 3 | ACLs, schemas-repo dependencies, certificate trust pre-cutover | | C. Architectural decisions to revisit | 6 | Driver list pre-survey, stability tiers, Polly resilience, multi-identifier model (now refined per addendum), missing cutover plan, per-building cluster interactions | | D. Resolved TBDs | 4 | Pilot class, schemas repo format, ACL location, **D4 enterprise shortname = `zb` RESOLVED 2026-04-17** | -| E. New TBDs | 4 | UUID-gen authority, Aveva validation, multi-cluster site addressing, cluster-endpoint mental model | +| E. New TBDs | 4 | UUID-gen authority, **E2 Aveva validation = GREEN-YELLOW RESOLVED 2026-04-17**, multi-cluster site addressing, cluster-endpoint mental model | | **Addendum hardening fixes** | **4** | EquipmentId system-generated; ExternalIdReservation table; same-cluster namespace binding; Namespace generation-versioned | The hardening fixes are committed in `lmxopcua` branch `v2` at commit `a59ad2e` (2026-04-17). Decisions #122–125 in `lmxopcua/docs/v2/plan.md` carry the rationale. @@ -466,7 +486,7 @@ After the plan team integrated the original 19 corrections + 4 hardening fixes, | B. Missing constraints | 3 | B1 ACLs **CLOSED** (#129–132); B2 schemas-repo **PARTIALLY CLOSED** (seed contributed; owner-team + dedicated-repo TBD); B3 cert-distribution remains operational concern | | C. Architectural decisions to revisit | 6 | C1 driver list **CLOSED** (#128); C5 cutover scope **CLOSED** (#136 — out of v2 scope); others still flagged | | D. Resolved TBDs | 4 | Pilot class, schemas repo format, ACL location, **D4 enterprise shortname = `zb` RESOLVED 2026-04-17** | -| E. New TBDs | 4 | UUID-gen authority, Aveva validation, multi-cluster site addressing, cluster-endpoint mental model | +| E. New TBDs | 4 | UUID-gen authority, **E2 Aveva validation = GREEN-YELLOW RESOLVED 2026-04-17**, multi-cluster site addressing, cluster-endpoint mental model | | **Addendum hardening fixes** | **4** | EquipmentId system-generated; ExternalIdReservation table; same-cluster namespace binding; Namespace generation-versioned | | **Round 3 additions** | **4** | ACL design (#129–132); dev-environment two-tier (#133–137); cutover scope removal (#136); `_base` template + OPC 40010 columns (#138–139) |