fix(opcua): run a fault manager in the OpenPLC tank demo - #683
Draft
bburda wants to merge 2 commits into
Draft
Conversation
The demo gateway had no fault manager, so every alarm the OPC-UA plugin detected was reported into nothing and each /faults route answered 503 "ListFaults service not available". The demo could show live PLC values and never a fault, which is the one thing the alarm-to-fault bridge is there to demonstrate. scripts/start.sh now starts fault_manager_node in the gateway container before gateway_node, on the same ROS domain, and waits for /fault_manager/report_fault to be advertised instead of sleeping a fixed time. The wait is bounded and both the container and the host script fail with a message naming the missing service, so a fault manager that never came up is a loud failure rather than a 503 discovered later. database_path is passed explicitly so faults.db lands on the named state volume next to the entity freeze frames. A fault and the freeze frame it carries now cross stop.sh and start.sh together, and rosbag storage points at the same volume for when black-box capture is switched on. The test scripts and the CI workflow are untouched. They start their own containers, and run_alarm_tests.sh already ran a fault manager this way.
The previous wording claimed every /faults route answers 503 without a fault manager. Only the global GET /api/v1/faults does. A plugin-owned entity's list is served by the plugin's FaultProvider, and the context contract is an empty array when the fault manager is unavailable, so GET /api/v1/apps/tank_process/faults answers 200 with no items. The demo symptom is the same, live PLC values and never a fault, but the two routes fail differently and a reader chasing one will not see the other. Also correct the state comment in gateway_params.yaml. It said the test scripts keep the frames and faults.db inside the container, which reads as though they all run a fault manager. run_integration_tests.sh and test_all.sh run none and have no faults.db, while run_alarm_tests.sh and run_discovery_race_test.sh start one and keep it in the container.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The plugin's
start.shstarted OpenPLC and one gateway container and no fault manager, so the demo the README describes could not confirm a fault:GET /api/v1/faultsanswered 503ListFaults service not available, and a PLC alarm waited in the plugin's report buffer for a service that never came.start.shnow runsfault_manager_nodein the gateway container beforegateway_node, waits for/fault_manager/report_fault, and logs it to/var/lib/ros2_medkit/fault_manager.log. The fault manager's state sits under/var/lib/ros2_medkit, the named volume from #680, so faults, freeze frames and recordings survivestop.shandstart.shtogether. The image is unchanged.test_all.sh, the test scripts and the CI workflow are untouched.Stacked on #680.
Issue
Type
Testing
Shell and docs only, so the evidence is the demo run, base against branch.
Base:
start.sh,GET /api/v1/faultsanswers 503ListFaults service not available. Drivingtank_temperatureto 95 raises the alarm onx-plc-statusand the fault list stays empty, nofaults.dbon the volume.Branch:
GET /api/v1/faultsanswers 200. The same write confirmsPLC_HIGH_TEMPwithin 2 s, and the fault detail carries afreeze_framewithtank_temperatureat 95. Afterstop.shandstart.shthe same detail is served with the samecaptured_atwhile the live PLC reads 25 °C. After the documented purge the fault is gone and the list is empty.Injected failure: a directory in place of
faults.dbmakes the fault manager abort, andstart.shexits 1 naming the missing service and printing the log tail.shellcheckandpre-commitpass.Checklist