Summary
The OPC UA plugin serves every PLC point through two front doors. It implements the gateway's provider interfaces, so a point is a data item under GET /apps/{id}/data/{name} and a writable point is an operation under POST /apps/{id}/operations/{name}/executions, with the authentication, error catalogue and OpenAPI document those routes already carry. It also registers its own routes for the same points: GET /apps/{id}/x-plc-data, GET /apps/{id}/x-plc-data/{name}, POST /apps/{id}/x-plc-operations/{name} and GET /components/{id}/x-plc-status (src/opcua_plugin.cpp:670-682), advertised as capabilities on the entities (:761-802).
Two doors cost twice on every change that touches the surface. The read-only build had to prove that no write reaches the controller on the provider path and on the vendor route separately, and every consumer of the tree has to decide which door to use for a value that is the same value. The vendor routes also sit outside the parts of the API that SOVD defines, so a client written to the standard never finds them.
Nothing in this repository consumes them: the web interface and the model adapter have no reference to x-plc- (checked on their main branches). The plugin's README is the only document that describes them.
Low priority: nothing is broken, and the provider path already carries the traffic. The point is to stop paying twice before more code grows on the second door.
Proposed solution (optional)
- Serve PLC points through the provider interfaces only: data under
/data, writable points under /operations.
- Keep the link status somewhere the standard tree can carry it, as an
x-medkit block on the PLC component or as a data item on it, so a client that walks the tree finds it without a vendor route.
- Drop the
x-plc-data, x-plc-operations and x-plc-status routes and the capabilities that advertise them, with a release note naming the replacements, and take the README along.
Additional context (optional)
src/ros2_medkit_plugins/ros2_medkit_opcua/src/opcua_plugin.cpp (route table at :670-682, capability registration at :761-802), the plugin's README.
Summary
The OPC UA plugin serves every PLC point through two front doors. It implements the gateway's provider interfaces, so a point is a data item under
GET /apps/{id}/data/{name}and a writable point is an operation underPOST /apps/{id}/operations/{name}/executions, with the authentication, error catalogue and OpenAPI document those routes already carry. It also registers its own routes for the same points:GET /apps/{id}/x-plc-data,GET /apps/{id}/x-plc-data/{name},POST /apps/{id}/x-plc-operations/{name}andGET /components/{id}/x-plc-status(src/opcua_plugin.cpp:670-682), advertised as capabilities on the entities (:761-802).Two doors cost twice on every change that touches the surface. The read-only build had to prove that no write reaches the controller on the provider path and on the vendor route separately, and every consumer of the tree has to decide which door to use for a value that is the same value. The vendor routes also sit outside the parts of the API that SOVD defines, so a client written to the standard never finds them.
Nothing in this repository consumes them: the web interface and the model adapter have no reference to
x-plc-(checked on their main branches). The plugin's README is the only document that describes them.Low priority: nothing is broken, and the provider path already carries the traffic. The point is to stop paying twice before more code grows on the second door.
Proposed solution (optional)
/data, writable points under/operations.x-medkitblock on the PLC component or as a data item on it, so a client that walks the tree finds it without a vendor route.x-plc-data,x-plc-operationsandx-plc-statusroutes and the capabilities that advertise them, with a release note naming the replacements, and take the README along.Additional context (optional)
src/ros2_medkit_plugins/ros2_medkit_opcua/src/opcua_plugin.cpp(route table at:670-682, capability registration at:761-802), the plugin's README.