Problem
Custom adapters built with the Adapter Framework use the same underlying technology and the same edgecmd-based management model as AVEVA's adapters. The new Adapter Configuration utility, however, does not natively support framework-built adapters. Teams building custom adapters must go back to command-line-only configuration with edgecmd, while the AVEVA adapters get a UI.
Why it matters
Custom adapters are a second-class experience compared with AVEVA adapters.
Configuration through edgecmd and JSON is slower and more error-prone, especially across many sites and hosts.
Operators and automation engineers who aren't developers have no UI to manage custom adapters.
Custom adapters are often built for gaps in the AVEVA adapter portfolio, such as quality mapping, so they are the ones that most need good tooling.
Requested behavior
The Adapter Framework should expose what the utility needs (component discovery, configuration schema, data source and data selection, and status/health) so a custom adapter appears in the utility with no extra UI work.
The configuration schema should drive the UI automatically, as it does for AVEVA adapters.
edgecmd should remain supported for scripting and automation.
Include documentation and a sample adapter that demonstrates the integration.
Who benefits
Adapter developers, system integrators, OT/IT engineers, and site administrators who deploy and maintain custom adapters.
Expected outcome
Custom adapters built on the Adapter Framework get the same UI configuration as AVEVA adapters, with no need to fall back to edgecmd only.
