opcua plugin demo: start.sh brings up no fault manager, so the alarm-to-fault bridge the README describes cannot happen in the demo

[bburda]

Describe the bug

src/ros2_medkit_plugins/ros2_medkit_opcua/docker/scripts/start.sh starts OpenPLC and one gateway container with the OPC UA plugin, and nothing else. No fault manager runs (grep -c fault_manager_node is 0 in start.sh and test_all.sh, only run_alarm_tests.sh starts one, against its own test_alarm_server fixture).

On that demo GET /api/v1/faults answers 503 with error_code: service-unavailable and details: "ListFaults service not available". A PLC alarm the plugin detects waits in its pending-report buffer for a /fault_manager/report_fault service that never appears. No fault confirms, no freeze frame is captured, no rosbag is recorded.

The README reads as though the demo does all of this. "Docker Integration Tests" calls it "a self-contained OpenPLC tank demo in docker/ that exercises the full stack end-to-end", and "Alarm-to-Fault Bridge" walks through tank temperature crossing 80 C, PLC_HIGH_TEMP reaching the fault manager and the fault appearing at GET /api/v1/apps/tank_process/faults. That entity, threshold and fault code come from config/tank_demo_nodes.yaml, the demo's own node map.

To reproduce

1. bash src/ros2_medkit_plugins/ros2_medkit_opcua/docker/scripts/start.sh
2. curl -i http://localhost:8080/api/v1/faults answers 503, ListFaults service not available.
3. curl -X POST http://localhost:8080/api/v1/apps/tank_process/x-plc-operations/set_tank_temperature -H 'Content-Type: application/json' -d '{"value": 95.0}'
4. curl -i http://localhost:8080/api/v1/apps/tank_process/faults still answers 503. PLC_HIGH_TEMP never appears.

Step 3 only saves time. docker/openplc/tank_demo.st warms the tank on its own (heat_rate := 0.05 on a 100 ms task), so a demo left running crosses 80 C by itself.

Expected behavior

Either the demo confirms the alarm as a fault and serves its detail, or the README says the demo covers discovery and live data only and points at run_alarm_tests.sh for the fault lifecycle.

Options

• start.sh starts a fault manager next to the gateway. run_alarm_tests.sh has the shape: ros2 run ros2_medkit_fault_manager fault_manager_node in the background in the same container, wait for /fault_manager/report_fault, then gateway_node. No image change: Dockerfile.gateway builds the whole src/ tree, so the fault manager is already in gateway-opcua. start.sh mounts nothing and stop.sh does docker rm -f, so state lives only for the life of the containers unless a volume is added.
• Or the README stops calling the tank demo end to end and names the alarm suite as the way to see a fault.

Environment

ROS 2 Jazzy, Ubuntu 24.04, the plugin's own docker scripts. A fault manager had to be started by hand before any fault could be confirmed.