Acknowledge는 clear가 아니다
몇 년 돌린 플랜트에서 alarm summary를 열고, 지금 교대가 시작되기 전부터 active인 알람이 몇 개인지 세어 보라. 큰 연속 공정이면 스무 개 밑으로 내려가는 경우가 드물다. 전부 acknowledge가 되어 있어서 horn은 조용하고 banner도 잠잠하다. 그리고 그 하나하나가 지금 아무도 손대지 않는 비정상 조건이다.
ISA-18.2(IEC 62682로 채택)에는 이걸 부르는 이름이 있다. Stale alarm은 24시간 넘게 active인 알람이다. 표준의 기준값은 하루 평균 stale alarm 5개 미만이다. 내가 들어가 본 대부분의 사이트는 열 개에서 쉰 개 사이를 돌린다. 이 숫자 차이가 문제의 전부이고, 그 차이를 줄이는 것이 standing alarm 검토의 목적이다.
Acknowledge는 딱 한 가지 뜻이다. 사람이 알람을 봤고 horn을 껐다는 것. 조건이 clear됐는지, 위험을 승인했는지, work order가 있는지에 대해서는 아무것도 말하지 않는다. Acknowledge됐지만 active인 더미를 아무도 다시 보지 않으면 alarm system은 운전자의 신뢰를 조용히 잃는다. 그리고 실제 upset이 그 소음 한가운데로 들어오는 날, 다른 알람과 함께 그냥 acknowledge되어 버린다.
발생률이 아니라 지속 시간의 문제다
Standing alarm 검토를 flood 분석에서 같이 돌리지 마라. 둘은 다른 실패를 본다. Flood 분석은 ISA-18.2 발생률 metric에 산다. 10분당 알람 수, 정상 상태 목표 10분당 1개 이하, flood 임계값 10분당 10개 초과. 폭주에 대한 이야기다.
Standing alarm 검토는 다른 축, 즉 active 지속 시간을 본다. 한 번 뜨고 3주 동안 남아 있는 태그는 flood 숫자에는 거의 기여하지 않지만 시스템에서 가장 해로운 것 중 하나다. 두 report는 겹치지 않으니 standing 쪽을 따로 만들되 active 시작 시각으로 정렬한다. 마지막 acknowledge 시각이 아니다. 그건 매 교대마다 리셋되어 실제 지속 시간을 가린다.
검토를 실제로 굴러가게 하는 최소 항목:
| 항목 | 왜 한 칸을 차지하는가 |
|---|---|
| Active 시작 시각(마지막 ack 아님) | 실제 지속 시간 — 이게 정렬 키다 |
| Priority | 검토 주기와 escalation 기준 |
| Suppressed / shelved / disabled | 메인 목록 밖에 숨은 장기 bypass를 잡는다 |
| 운전자 note / work order 참조 | 실제 작업과 연결하거나, 없다는 걸 드러낸다 |
| Clear 조건 | 이 태그에서 "끝"이 무엇인지 정의한다 |
시스템이 live banner만 줄 수 있으면 이 검토는 못 한다. Banner는 다음 30초용이지 지난 3주용이 아니다. 먼저 historian 기반 report나 alarm 분석 view부터 확보한다.
매일 볼 것과 일주일 미뤄도 되는 것
계획 정지 중 cabinet fan low-flow 알람과 운전 중 라인에 남은 high priority safety permissive는 둘 다 "standing"이지만, 똑같이 다루면 검토가 지겨워서 죽는다. 매 교대나 아침 회의에서 볼 대상:
- 허용 response time보다 오래 active인 high, critical 알람.
- Safety, 환경, 품질, 규제 결과와 연결된 것.
- Comms와 data quality 알람 — 핵심 측정값의 bad quality flag는 그 값에 대해 눈을 감고 나는 것이다.
- Expiry에 가까운 suppressed, shelved, bypassed 알람. Timeout 없는 shelve는 설계 결함이다. ISA-18.2는 shelve의 자동 unshelve를 기대한다.
- Owner 없이 shift handover를 넘긴 알람.
- 정비 sign-off 뒤 같은 설비에서 다시 standing이 되는 알람 — 안 고쳐진 수리다.
Low priority 알람은 주간 pass로 옮겨도 되지만 사라지면 안 된다. 오래된 low priority standing 알람은 대개 증상이다. 드리프트하는 계측기, rationalization으로 빠졌어야 할 nuisance logic, 닫히지 않은 정비 loop.
운전자에게 한 화면에서 맥락을 준다
Standing alarm 하나 이해하는 데 historian, CMMS, PLC 프로그램을 다 열어야 하면 바쁜 교대에서 검토는 살아남지 못한다. Alarm detail view나 standing report 행에 그 화면을 벗어나지 않고 다음 조치를 정할 만큼은 담는다.
Cooling Water Low Pressure라면 현재 압력과 low limit을 나란히, pump running feedback, instrument quality bit, work order 유무. 그러면 운전자가 5초 안에 실제 저압 이벤트인지, 0을 읽는 죽은 transmitter인지, 이미 정비 큐에 있는 알려진 고장인지 구분한다. 이게 없으면 "이거 왜 아직 있지?"가 매 교대마다 전화 한 통 값이 되고, 그래서 아무도 안 묻게 된다.
계속 고장 나 있게 만드는 실패 형태
Acknowledge가 무시 버튼이 된다. 같은 알람, 매 교대, 즉시 ack, 그냥 넘어감. 그 알람이 actionable하지 않거나 owner가 정의되지 않았다는 신호다. 기대 조치를 붙이거나 재분류한다 — 알람이 아니라 event log 항목으로.
Disabled와 suppressed 알람이 목록에서 빠진다. 많은 시스템이 out-of-service 알람을 정상 view에서 빼는데, 그게 정확히 6개월짜리 bypass가 안 보이게 되는 경로다. Standing report는 disabled, suppressed, shelved, out-of-service 상태를 별도 section에, bypass 나이까지 함께 담아야 한다.
Chattering 알람이 회의 직전에 clear된다. 현재 active만 보는 report라면 하루에 마흔 번 active/clear를 오가는 점을 놓친다. 볼 때마다 마침 "standing"이 아니기 때문이다. 순간 상태만이 아니라 지난 하루와 일주일의 total active time과 activation 횟수를 포함한다.
Clear 조건을 아무도 모른다. 자동 clear인지, reset이 필요한지, PLC bit를 기다리는지, maintenance closeout이 필요한지. 이게 문서화 안 되면 알람은 기본값으로 active로 앉아 있는다. Alarm documentation에 한 문장이면 영구히 해결된다.
Priority가 잡동사니 서랍이 된다. 귀찮은 것과 risk가 낮은 것은 다른데, 귀찮은 알람이 그만 나대게 하려고 계속 low priority로 강등된다. 오래된 low priority 더미를 나이순으로 감사한다. 운전자 조치가 필요 없는 태그면 그건 알람이 아니다.
인수인계는 말로 넘긴다
Standing alarm은 다른 어디보다 교대 시점에서 끊어진다. 나가는 운전자는 사정을 머릿속에 다 갖고 있고, 들어오는 운전자는 이미 acknowledge된 행 목록만 서사 없이 물려받는다. Handover에 회의는 필요 없고 습관이 필요하다. High priority standing alarm은 모두 이름을 부르고, 측정이나 제어 기능을 무력화한 건 짚고, 다음 교대에 허용되는지 오늘 밤 조치가 필요한지 말하고, owner가 operations, maintenance, controls, process, vendor 중 누구인지 확인한다. 교대 중 이유나 owner가 바뀌었으면 떠나기 전에 note를 갱신한다.
정리를 밀어붙이는 숫자 두 개만 본다
여기서 metric은 dashboard를 채우려는 게 아니라 work order를 밀려고 있다. 시작은 두 개면 충분하다. stale alarm(active >24h) 개수를 priority와 area별로, 그리고 priority별 가장 오래된 active alarm. 최악의 반복 offender를 찾고 싶으면 지난 일주일 설비별 total active duration을 더한다. Stale 개수를 ISA-18.2 목표인 5개 미만에 대고 지켜본다. 숫자가 안 움직이면 검토가 실제 정비 작업이나 alarm rationalization에 연결되지 않은 것이고, 차트를 아무리 예쁘게 해도 바뀌지 않는다.
Reset만 하지 말고 이유를 남긴다
오래 서 있던 알람이 드디어 clear되면 왜인지 적는다. Instrument 수리, setpoint 수정, 설비 service 복귀, logic 변경, rationalization 제거. 다음 달 같은 태그가 다시 뜰 때 그 한 줄이 새로 진단하는 것과 이 transmitter가 세 번째 드리프트라는 걸 아는 것의 차이다. 증상, 원인 또는 승인된 이유, 변경 내용, 확인, 날짜/owner — 짧은 다섯 칸이면 된다.
그 마무리 note가 이 검토를 할 가치가 있는 이유다. 운전팀 잡무가 아니라 HMI 설계, PLC logic, 계측, alarm philosophy 문서로 돌아가는 feedback 경로다. 이걸 빼면 그냥 알람을 reset하는 것이고, 남기면 다음에 진짜로 무언가 잘못됐을 때 summary가 여전히 읽힌다.