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
parent 0307a498ed
commit 1189dc87fd
3 changed files with 209 additions and 0 deletions
--- a/docs/v2/aveva-system-platform-io-research.md
+++ b/docs/v2/aveva-system-platform-io-research.md
@@ -0,0 +1,180 @@
+# 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/)
--- a/docs/v2/implementation/phase-1-configuration-and-admin-scaffold.md
+++ b/docs/v2/implementation/phase-1-configuration-and-admin-scaffold.md
@@ -444,6 +444,32 @@ Per `admin-ui.md` §"Release an external-ID reservation" and §"Merge or rebind
 - After release: same `(Kind, Value)` can be reserved by a different EquipmentUuid in a future publish
 - Merge equipment A → B: draft preview shows tag re-pointing + ID re-reservation; publish executes atomically; A is disabled with `EquipmentMergedAway` audit entry

+#### Task E.10 — AppServer-via-OI-Gateway end-to-end smoke test (decision #142)
+
+Per `aveva-system-platform-io-research.md`, the tier-3 (Year 3) cutover redirects AVEVA System Platform's IO layer from direct-equipment connections to consuming OtOpcUa via OI Gateway. Catching AppServer-specific quirks at Phase 1 — well before the cutover schedule — protects the Year 3 timeline and ensures OtOpcUa's transport security model is actually compatible with the most opinionated downstream consumer.
+
+Stand up a non-production AppServer + OtOpcUa pairing and verify:
+
+1. AppServer (System Platform 2023 R2 Patch 01 or later) installed with the matching Communications Drivers Pack
+2. OI Gateway service runs under a dedicated service account (NOT SYSTEM — known issue per AVEVA 2020 R2 readme)
+3. OtOpcUa endpoint exposed as `opc.tcp://{host}:{port}` with **no `/discovery` suffix** (forum-documented failure mode that produces `Bad_SecurityChecksFailed` even after cert trust)
+4. Configure an OPCUA Connection in OI Gateway pointing at OtOpcUa with `Basic256Sha256` + `SignAndEncrypt` + LDAP-username token
+5. OI Gateway client cert appears in OtOpcUa's pending-certs folder; admin moves it to Trusted; OtOpcUa server cert trusted on OI Gateway side
+6. Configure an OPCUAGroup with at least one tag from a published OtOpcUa generation
+7. Configure a SuiteLink DI Object in AppServer pointing at the OI Gateway instance
+8. Create an AppServer attribute with `IO.SourceAttribute = <SuiteLinkDIObjectName>.<TopicName>.<ItemReference>`
+9. Verify the attribute reads end-to-end with quality `0x00C0` (good)
+10. Re-verify after a publish-generation cycle in OtOpcUa (the AppServer attribute must continue reading without manual re-trust)
+11. Capture the full configuration as `docs/deployment/aveva-system-platform-integration.md` for the future tier-3 cutover team
+
+**Acceptance**:
+- All 10 connection steps succeed; AppServer reads at least one tag end-to-end with good quality
+- Reconnect after OtOpcUa publish: no manual intervention required
+- Documentation captured for the cutover team
+- Any failure mode that surfaces during the test is either: (a) fixed in OtOpcUa Phase 1, (b) added to Phase 1 known-limitations + escalated to corrections doc, or (c) confirmed as an AppServer / OI Gateway quirk operators must accept
+
+This is **non-blocking** for Phase 1 exit if the test surfaces only documentation-level fixes. It IS blocking if it surfaces an OtOpcUa-side incompatibility that requires architectural change — that would be a tier-3 cutover risk and should escalate immediately.
+
 #### Task E.9 — ACLs tab + bulk-grant + permission simulator

 Per `admin-ui.md` Cluster Detail tab #8 ("ACLs") and `acl-design.md` §"Admin UI":
--- a/docs/v2/plan.md
+++ b/docs/v2/plan.md
@@ -905,6 +905,8 @@ Each step leaves the system runnable. The generic extraction is effectively free
 | 138 | Every equipment-class template extends a shared `_base` class providing universal cross-machine metadata (identity, state, alarm summary, optional production context) | References OPC UA Companion Spec OPC 40010 (Machinery) for the Identification component + MachineryOperationMode enum, OPC UA Part 9 for alarm summary fields, ISO 22400 for KPI inputs (TotalRunSeconds, TotalCycles), 3-year-plan handoff §"Canonical Model Integration" for the canonical state vocabulary. Inheritance via `extends` field on the equipment-class JSON Schema. Avoids per-class drift in identity / state / alarm field naming and ensures every machine in the estate exposes the same baseline metadata regardless of vendor or protocol. `_base` lives in `3yearplan/schemas/classes/_base.json` (temporary location until the dedicated `schemas` repo is created) | 2026-04-17 |
 | 139 | Equipment table extended with OPC 40010 identity columns (Manufacturer, Model, SerialNumber, HardwareRevision, SoftwareRevision, YearOfConstruction, AssetLocation, ManufacturerUri, DeviceManualUri) all nullable so equipment can be added before identity is fully captured | First-class columns rather than a JSON blob because these fields are universal (every machine has them) and need to be queryable / searchable in the Admin UI. Manufacturer and Model are declared `isRequired: true` in `_base.json` and the Admin UI flags equipment that lacks them; the rest are optional. Drivers that can read these dynamically (FANUC, Beckhoff, etc.) override the static value at runtime; static value is the fallback. Exposed on the OPC UA node under the OPC 40010-standard `Identification` sub-folder | 2026-04-17 |
 | 140 | Enterprise shortname = `zb` (UNS level-1 segment) | Closes corrections-doc D4. Matches the existing `ZB.MOM.WW.*` namespace prefix used throughout the codebase; short by design since this segment appears in every equipment path (`zb/warsaw-west/bldg-3/line-2/cnc-mill-05/RunState`); operators already say "ZB" colloquially. Admin UI cluster-create form default-prefills `zb` for the Enterprise field. Production deployments use it directly from cluster-create | 2026-04-17 |
+| 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 (Software Toolbox, InSource) have published working 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. Two integrator-burden risks tracked: validation/GxP paperwork (no AVEVA blueprint exists for non-AVEVA upstream servers in Part 11 deployments) and unpublished scale benchmarks (in-house benchmark required before cutover scheduling). See `aveva-system-platform-io-research.md` | 2026-04-17 |
+| 142 | Phase 1 acceptance includes an end-to-end AppServer-via-OI-Gateway smoke test against OtOpcUa | Catches AppServer-specific quirks (cert exchange via reject-and-trust workflow, endpoint URL must NOT include `/discovery` suffix per Inductive Automation forum failure mode, service-account install required because OI Gateway under SYSTEM cannot connect to remote OPC servers, `Basic256Sha256` + `SignAndEncrypt` + LDAP-username token combination must work end-to-end) early — well before the Year 3 tier-3 cutover schedule. Adds one task to `phase-1-configuration-and-admin-scaffold.md` Stream E (Admin smoke test) | 2026-04-17 |

 ## Reference Documents

@@ -915,6 +917,7 @@ Each step leaves the system runnable. The generic extraction is effectively free
 - **[Admin Web UI](admin-ui.md)** — Blazor Server admin app: information architecture, page-by-page workflows, per-driver config screen extensibility, real-time updates, UX rules
 - **[OPC UA Client Authorization (ACL Design)](acl-design.md)** — data-path authz model: `NodePermissions` bitmask flags (Browse / Read / Subscribe / HistoryRead / WriteOperate / WriteTune / WriteConfigure / AlarmRead / AlarmAcknowledge / AlarmConfirm / AlarmShelve / MethodCall + bundles), 6-level scope hierarchy (Cluster / Namespace / UnsArea / UnsLine / Equipment / Tag) with inheritance, default-deny + additive grants, per-session permission-trie evaluator with O(depth × group-count) cost, default cluster-seed mapping v1 LmxOpcUa LDAP roles, Admin UI ACL tab + bulk grant + simulator. Closes corrections-doc finding B1.
 - **[Development Environment](dev-environment.md)** — every external resource the v2 build needs (SQL Server, GLAuth, Galaxy, Docker simulators, TwinCAT XAR VM, OPC Foundation reference server, FOCAS stub + FaultShim) with default ports / credentials / owners; two-tier model (inner-loop on developer machines, integration on a single dedicated Windows host with WSL2-backed Docker + Hyper-V VM for TwinCAT); concrete bootstrap order for both tiers
+- **[AVEVA System Platform IO research](aveva-system-platform-io-research.md)** — closes corrections-doc E2. Validates that the planned tier-3 cutover (AppServer IO consuming from OtOpcUa instead of equipment directly) is supported via AVEVA's OI Gateway driver. Verdict: **GREEN-YELLOW**. Multiple non-AVEVA upstream-server integrations published. Two integrator-burden risks: validation/GxP paperwork and unpublished scale benchmarks
 - **[Implementation Plan Overview](implementation/overview.md)** — phase gate structure (entry / mid / exit), compliance check categories (schema / decision / visual / behavioral / stability / documentation), deliverable conventions, "what counts as following the plan"
 - **[Phase 0 — Rename + .NET 10 cleanup](implementation/phase-0-rename-and-net10.md)** — mechanical LmxOpcUa → OtOpcUa rename with full task breakdown, compliance checks, completion checklist
 - **[Phase 1 — Configuration + Core.Abstractions + Admin scaffold](implementation/phase-1-configuration-and-admin-scaffold.md)** — central MSSQL schema, EF Core migrations, stored procs, LDAP-authenticated Blazor Server admin app with ScadaLink visual parity, LiteDB local cache, generation-diff applier; 5 work streams (A–E), full task breakdown, compliance checks, 14-step end-to-end smoke test