3d19b186da
45 of the 65 rows in db/seed/tags.csv had a PS_* name as their PRIMARY KEY, and historian_items.csv, alarm_bits.csv, the fixtures, two Cube models and the exam all referenced them. They are gone. The tag seed is now keyed on the CI Server item for everything the historian carries - AID.WRPS.STN.LEVEL - and on the instrument tag for the 20 field devices that never reach SCADA. gen_historian_items.py reads db/seed/scada-source/ by default, so it runs for anyone with a clone: --wrps is now --source. The tag match is the item name itself, an identity lookup, and the TAG_FOR_ITEM special case is deleted - all 49 item names are unique, which the old point names were not. scada_point in the output is replaced by ci_station, ci_point and poll_group; 001_schema.sql and deploy.sh's upsert follow. Regenerated, and it comes out the same shape it went in: 49 items, 45 answerable, 4 deliberately excluded, three groups at 5 s, 30 s and on change. Every historian_items.tag_id and alarm_bits.tag_id resolves to a tags.csv row. No duplicate keys. THE ONE NAME THAT WAS AMBIGUOUS, AND NEARLY COST US PS_STN_HIGH_LEVEL_ALARM named two different things in the old delivery: the high level alarm STATUS BIT on coil 10, and the alarm SETPOINT on holding register 1032. Building the rename map from that file kept whichever came last, so the status bit was silently renamed onto the setpoint. check_mapping() refused to write and named the item that no longer resolved - which is the only reason this is a paragraph in a commit message rather than a defect. Had it gone through, alarm bit 0 - wet well high level - would have pointed at the setpoint. "How many high level alarms last week" would have counted setpoint changes and returned a small, plausible, confident, wrong number. That check exists because the same ambiguity caused the first Phase 5 finding in August. It has now bitten twice. NOT YET VERIFIED: pytest api/tests could not be run here - this machine has neither fastapi nor psycopg. The tests are unchanged and reference no PS_ name, but they have not been run. pg-ai on lin001 still holds the old keys and must be reloaded, Cube pre-aggregations rebuilt, and the Phase 1 gate re-run. eval/testset.jsonl changed, so the 78-case exam - never yet run - should be run after. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
17 lines
3.1 KiB
CSV
17 lines
3.1 KiB
CSV
bit,alarm_type,priority,tag_id,alarm_text,description
|
|
0,HIGH_LEVEL,2,AID.WRPS.STN.HIGH_LEVEL,Wet well high level,"Wet well level above the high level alarm setpoint (%MW8, default 5200 mm = 86.7%). The discrete item AID.WRPS.STN.HIGH_LEVEL mirrors this bit; the two are cross-checked at fixture load."
|
|
1,HIGH_HIGH_LEVEL,1,LSHH-102,Wet well high high level,"LSHH-102 wet at 5500 mm (91.7%). Forces all available pumps to 50 Hz and bypasses min-off timers. The switch itself is a field input and is not historised - this bit is the only record of it."
|
|
2,LOW_LOW_LEVEL,1,LSLL-103,Dry run lockout,"LSLL-103 dry. Stops all pumps and latches the dry-run lockout, which needs a manual reset. Field input, not historised - this bit is the only record."
|
|
3,SPILL,1,AID.WRPS.STN.SPILL_ACTIVE,Spill over the weir,"Level over the 6000 mm weir crest. An environmental reportable event - report the count plainly and never round it. The discrete item AID.WRPS.STN.SPILL_ACTIVE mirrors this bit."
|
|
4,PUMP_TRIP,1,AID.WRPS.PU301.TRIPPED,PU-301 tripped,"PU-301 tripped on thermal TE-312, vibration above 11.0 mm/s, or no-flow on PIT-311. Trips LATCH and clear only on the reset command."
|
|
5,PUMP_TRIP,1,AID.WRPS.PU302.TRIPPED,PU-302 tripped,"PU-302 tripped on thermal TE-322, vibration above 11.0 mm/s, or no-flow on PIT-321. Trips LATCH and clear only on the reset command."
|
|
6,PUMP_TRIP,1,AID.WRPS.PU303.TRIPPED,PU-303 tripped,"PU-303 tripped on thermal TE-332, vibration above 11.0 mm/s, or no-flow on PIT-331. Trips LATCH and clear only on the reset command."
|
|
7,SEAL_LEAK,3,MSE-313,PU-301 seal leak,"MSE-313 moisture detected. Alarm only - a seal leak does NOT remove availability (WRPS-PRO-001 section 5.5) and the pump keeps running."
|
|
8,SEAL_LEAK,3,MSE-323,PU-302 seal leak,"MSE-323 moisture detected. Alarm only; availability is unaffected."
|
|
9,SEAL_LEAK,3,MSE-333,PU-303 seal leak,"MSE-333 moisture detected. Alarm only; availability is unaffected."
|
|
10,HIGH_VIBRATION,2,VE-314,PU-301 high vibration,"VE-314 above the 7.1 mm/s alarm threshold. Above 11.0 mm/s the unit trips and bit4 sets as well. There is no vibration trend in the historian - the instrument is a field input."
|
|
11,HIGH_VIBRATION,2,VE-324,PU-302 high vibration,"VE-324 above the 7.1 mm/s alarm threshold. Above 11.0 mm/s the unit trips and bit5 sets as well."
|
|
12,HIGH_VIBRATION,2,VE-334,PU-303 high vibration,"VE-334 above the 7.1 mm/s alarm threshold. Above 11.0 mm/s the unit trips and bit6 sets as well."
|
|
13,LEVEL_SIGNAL_FAULT,1,LIT-101,Wet well level signal fault,"LIT-101 frozen or out of range - no change greater than 1 mm for 10 minutes with a pump running. Priority 1: losing the level signal on a well that can spill is a priority 1 condition. While this is active, AID.WRPS.STN.LEVEL is not trustworthy and any level answer over the window must say so."
|
|
14,MAINS_FAILURE,1,XA-502,Mains supply failure,"XA-502 unhealthy. Station is on loss of supply."
|
|
15,SETPOINT_REJECTED,3,AID.WRPS.STN.ALARM_WORD,Setpoint write rejected,"A SCADA setpoint write was rejected by the PLC as out of range and the previous value was retained. There is no dedicated instrument for this condition - the bitmask is the only record of it, so the tag is the bitmask itself."
|