기존 SCADA의 알람 summary를 열고 priority별로 개수를 세어 보라. 대개 목록의 절반이 High나 Critical에 몰려 있다. EEMUA 191은 3단계 체계라면 대략 low 80%, medium 15%, high 5% 근처가 되어야 한다고 본다. ISA-18.2(그리고 국제판인 IEC 62682)는 이 비율을 tag editor에서 고르는 색이 아니라 rationalization의 결과로 본다. 전부 빨간색이면 빨간색은 의미를 잃고, 정작 중요한 교대 때 운전자는 trip을 설명하는 알람 하나를 찾으려고 High 알람 마흔 개를 스크롤하게 된다.
Priority는 장식이 아니다. 하나의 질문에 답하는 도구다. 운전자가 얼마나 빨리 움직여야 하는가, 움직이지 않으면 어떻게 되는가.
실제로 중요한 두 축
Priority는 결과 영향과 대응 가능 시간으로 정한다. 나머지는 보조다.
- 결과 영향 — 안전, 환경, 품질, 생산 손실, 설비 손상, 규제 노출. 얼마나 나쁜가.
- 대응 가능 시간 — 알람이 active된 뒤 결과가 감당 못 할 수준이 되기 전까지의 여유. 얼마나 급한가.
발생 빈도는 rationalization 입력값이지 priority 축이 아니다. 3년에 한 번 뜨는 relief valve lift는 드물어도 여전히 Critical이다. 드물다고 심각한 알람을 낮추면, 몇 년 동안 아무도 못 본 그 알람이 정작 필요한 날 Low로 떠 있게 된다.
단계는 3~4개로 묶는다
대부분의 운전실에 priority 열 단계는 필요 없다. 나는 3~4개 운영 단계로 고정한다. 그보다 많으면 일관되게 교육하기 어렵고, "priority 6"과 "priority 7"의 차이는 야간 교대 인수인계를 넘기지 못한다.
| Priority | 현장 의미 | 운전자 기대 행동 |
|---|---|---|
| Critical | 즉시 안전, 환경, 대형 설비 risk | 다른 작업을 멈추고 바로 대응 |
| High | Trip, 품질 손실, 생산 손실을 막기 위해 빠른 조치 필요 | 정해진 몇 분 안에 조치 |
| Medium | 비정상 상태지만 즉시 정지 risk는 낮음 | 정상 감시 중 확인하고 처리 |
| Low | 정비 follow-up 또는 advisory 성격 | 운전 방해 없이 검토 |
명칭은 현장 표준에 맞추면 된다. 중요한 것은 각 단계에 색과 소리만 있는 게 아니라 분 단위 대응 기대 시간이 붙어 있어야 한다는 점이다. 그 기대 시간을 말로 못 하면 단계를 정의한 게 아니다.
조치가 없으면 알람이 아니다
조치가 없는 알람은 priority를 높여도 좋아지지 않는다. Priority 칸을 건드리기 전에 운전자가 실제로 무엇을 해야 하는지 한 문장으로 적어 본다.
- Standby pump 상태를 보고 auto start 실패 시 수동 기동한다.
- High-high level trip 전에 feed rate를 줄인다.
- 이중화 계측기 중 하나가 고장 났으므로 정비에 인계한다.
- 온도 이탈이 품질 한계를 넘으면 product hold 절차를 확인한다.
할 일이 "알고 있기"뿐이라면 알람이 아니라 event log, status indication, report에 들어갈 내용이다. 정비만 처리할 수 있고 다음 계획 정비까지 기다려도 되는 내용이면, 지금 대응이 필요한 것들과 같은 process alarm banner에서 경쟁시키지 않는다.
Response time은 alarm delay가 아니다
이 둘은 늘 헷갈린다. Response time은 알람이 active된 뒤 결과가 감당 못 할 수준이 되기 전까지의 여유다. Alarm delay(on-delay, off-delay, deadband)는 알람이 뜨기 전에 노이즈성 chatter를 막으려고 넣는 로직이다. 하나는 priority를 정하고, 다른 하나는 신호를 깨끗하게 유지한다. 시간축에서 둘은 반대 방향으로 작동한다.
예를 들면 다음처럼 본다.
- Compressor lube oil low pressure는 설비 손상까지 몇 초밖에 없을 수 있다.
- Chilled water temperature high는 품질 risk까지 몇 분 여유가 있을 수 있다.
- Panel cabinet temperature warning은 실제 장애까지 몇 시간 여유가 있을 수 있다.
시운전 때는 rationalization sheet에 적힌 response time이 실제 공정과 맞는지 봐야 한다. 공정은 12초 뒤 trip되는데 HMI 알람에 30초 delay가 걸려 있으면 priority matrix 문제가 아니다. 알람 설계 자체가 틀린 것이다.
Priority가 끌고 오는 동작을 확인한다
많은 SCADA 플랫폼은 priority나 alarm class에 동작을 묶어 두는데, 그 절반은 새벽에 실제로 울리기 전까지 보이지 않는다. 스펙 시트가 아니라 살아 있는 시스템에서 다음을 하나씩 확인한다.
- Banner 색상, flashing 동작.
- Audible tone과 반복 방식.
- Overview 화면 표시 여부.
- SMS, email, messenger, escalation 규칙.
- Shelving 권한과 최대 shelve 시간.
- Historian 또는 event 보관 기간.
- Acknowledge나 return-to-normal 때 operator note 요구 여부.
Instrument chatter 때문에 high priority 알람이 매번 supervisor에게 메시지를 보내면 곧 bypass 대상이 된다. 반대로 critical 알람을 한 교대 동안 shelve할 수 있다면 site alarm philosophy와 맞지 않을 수 있다.
스프레드시트가 아니라 실제 upset으로 시험한다
엑셀에서 균형 잡혀 보이는 priority 목록도 실제 upset이 오면 운전자를 묻어 버릴 수 있다. 운전, 정비, 공정 엔지니어가 같이 앉아 실제 HMI에서 몇 가지 scenario를 따라가 본다.
- 정상 startup 중 permissive가 아직 모두 만족되지 않은 상황.
- Utility loss로 여러 설비가 한꺼번에 영향을 받는 상황.
- Remote PLC나 package skid 하나와 통신이 끊긴 상황.
- 여러 알람에 쓰이는 계측기 하나가 bad quality가 된 상황.
- 하나의 primary alarm 뒤에 secondary alarm이 많이 따라오는 공정 upset.
- 계획 정비 중 bypass 또는 out-of-service 설비가 있는 상황.
각 scenario에서 운전자가 먼저 봐야 할 항목이 실제로 높은 priority로 올라오는지 확인한다. 원인을 설명하는 알람보다 주변 결과 알람이 위에 떠 있다면 priority, suppression, shelving, alarm logic 중 무엇을 고칠지 정해야 한다.
Priority로 나쁜 신호를 숨기지 않는다
Priority는 filter가 아니고, chattering 알람을 Low로 내리는 건 해결이 아니다. 그냥 깨진 신호, 틀린 limit, 빠진 delay, 반복되는 state transition을 잊기 좋은 곳에 숨기는 것뿐이다. 알람을 먼저 고치고, 그다음에 등급을 매긴다. 화면 부담은 다른 도구가 맡는다.
- Area filter는 해당 운전자가 맡은 구역 알람만 보이게 한다.
- Suppression은 특정 운전 상태에서 의미 없는 consequential alarm을 숨긴다.
- Shelving은 규칙 안에서 알려진 nuisance alarm을 임시로 관리하게 한다.
- Standing alarm review는 acknowledge 뒤에도 오래 남은 active alarm을 따로 본다.
알람 부하를 priority만으로 처리하면 시간이 지나면서 matrix 의미가 흐려진다.
자주 보이는 실패 형태
High priority가 너무 많다
모든 알람이 high이면 아무 알람도 high가 아니다. Area별, priority별 개수를 뽑아 EEMUA 191 목표치와 대 본다. 3단계 체계에서 high는 대략 5%다. 운전자 한 명의 station에 Critical 알람이 서른 개 떠 있다면, 표가 아무리 정교해 보였어도 등급 매기기는 실패한 것이다. High와 Critical은 외워서 나열할 수 있을 만큼 작고 설명 가능한 집합이어야 한다.
Vendor severity를 그대로 복사한다
Vendor가 붙인 severity와 현장 결과 영향은 다를 수 있다. Package 장비 warning 하나가 병목 라인을 멈출 수도 있고, 단순 local maintenance 알림일 수도 있다. Vendor alarm은 site matrix에 맞게 mapping해야 한다.
많이 민원 넣은 알람이 올라간다
시끄러운 알람은 눈에 잘 띈다. 그래서 조용하지만 더 위험한 조건보다 priority가 높아지는 경우가 있다. 민원량이 아니라 consequence와 response time으로 정해야 한다.
Bad quality 기준이 없다
Process value가 bad quality이면 그 값을 쓰는 알람이 유효하지 않을 수 있다. Communication loss나 bad-quality status 자체를 어떤 priority로 볼지, 관련 process alarm을 어떻게 처리할지 정해야 한다.
변경 근거가 남지 않는다
Priority를 바꾸면 날짜, 이유, 검토자, 영향을 받는 화면과 notification 규칙을 남긴다. 근거가 없으면 다음 장애 리뷰 때 왜 바뀌었는지 다시 추측해야 한다.
남겨 둘 시운전 증거
다음 자료는 나중에 큰 도움이 된다.
- 승인된 priority matrix와 각 단계 정의.
- Alarm list의 priority, consequence, response time, expected action.
- Scenario test 메모와 alarm banner screenshot.
- Notification 또는 escalation 시험 결과.
- 공정이나 운영 승인이 더 필요한 exception 목록.
이 모든 게 스프레드시트 안에만 있으면 별 가치가 없다. 잘 됐는지 확인할 곳은 딱 하나, 다음 실제 upset 때의 alarm banner다. 맨 위에 뜬 항목이 문제를 설명하는 그 알람이라면 등급 매기기가 제 역할을 한 것이고, 아니라면 다음 시운전 과제가 생긴 것이다.