내가 본 최악의 알람 사고는 알람 폭주가 아니었습니다. 건조기 베어링 교체 중에 누군가 고온 알람을 "disable" 해 놓았는데, 제어실 어디에도 disable된 알람을 보여 주는 화면이 없어서 세 교대 동안 아무도 알아채지 못한 일이었습니다. 배너는 깨끗했고, 결과는 지저분했습니다.
보류와 억제의 진짜 위험이 이겁니다. 다들 넘치는 알람을 잡는 도구로만 이야기하지만, 실제 실패는 알람이 너무 많은 게 아니라 중요한 알람이 담당자도, 사유도, 종료 시간도, 확인할 화면도 없이 조용히 사라지는 것입니다.
이 넷은 서로 다른 상태다 — ISA-18.2가 그렇게 정의한다
대부분의 현장은 "shelve", "suppress", "disable", "bypass"를 말로는 섞어 쓰고, HMI에서는 제각각 다르게 구현합니다. ANSI/ISA-18.2-2016(그리고 이를 그대로 따르는 IEC 62682)은 이들을 전이 조건과 권한이 다른 별개의 알람 상태로 정의합니다. 설정에 손대기 전에 용어부터 못 박아야 합니다.
보류(Shelved) — 일시적이고 작업자가 시작하며 자동으로 복귀해야 합니다. 채터링하는 레벨 스위치나 이번 교대에 작업 중인 장비에 쓰는 도구입니다. 표준의 취지대로 보류에는 종료 시간이 있고, 만료되면 다시 알림이 뜹니다. 두 번 클릭으로 무기한 보류가 된다면 앞의 건조기 사고를 만든 셈입니다.
설계 억제(Suppressed by design) — 운전 상태 때문에 알람이 의미가 없어 자동으로 숨는 것. 정지 명령된 펌프의 저유량 알람 같은 경우입니다. 이건 로직에 들어 있어야 하고 작업자 손에 있으면 안 됩니다. 설계하고 시험하고 문서로 남기지 않았다면 억제가 아니라 그냥 마음에 든 버그입니다.
운영 제외(Out-of-service) — 누군가 다시 넣을 때까지 의도적으로 빼 두는 상태이고 자동 복귀가 없습니다. 종료 시간이 없기 때문에 알람 상태 중 권한 통제가 가장 강해야 합니다. 철거한 트랜스미터에 쓰는 것이지 "오늘 거슬린다"에 쓰는 게 아닙니다.
인터록 바이패스(Interlock bypass) — 애초에 알람 상태가 아닙니다. 바이패스는 보호나 퍼미시브 로직을 바꿉니다. 안전/MOC 절차에 속하고, 현장 확인이 필요하며, 알람 화면과 별도로 표시돼야 합니다. 바이패스 스위치가 알람 보류 화면 안에 있다면 빼내야 합니다.
숨긴 알람 화면은 선택이 아니다
숨긴 것과 안 보이는 것은 다릅니다. 지금 보류·억제·운영 제외·바이패스 상태인 항목을 모두 나열하는 상시 화면이 — 엔지니어링 메뉴 깊숙이가 아니라 — 있어야 합니다. 앞의 사고를 막는 가장 값싼 방법입니다.
항목마다 다음을 보여 줍니다.
- 태그/장비 이름과 알람 설명
- 어떤 숨김 상태인지
- 사유 또는 코멘트, 그리고 적용한 사용자
- 시작 시간과 종료/재확인 시간
- 현재 값과 품질
- 지금 실제로 알람 조건이 활성인지 — 보류 중인데 조건이 참인 알람이 가장 중요합니다
함정은 활성 알람과 이벤트 이력만 보여 주는 제어실입니다. 열몇 개의 알람 기능이 꺼진 채로도 깔끔해 보입니다. 감독자가 "무엇이 왜 숨겨졌는지"를 한 화면에서 답할 수 없다면 그 화면은 아직 없는 것입니다.
작업자 보류에는 시계를 달아라
작업자 보류는 만료돼야 합니다. 예외 없이. 저라면 프리셋을 30분, 2시간, 8시간, 교대 종료로 두고, 2시간을 넘기면 코멘트를 강제하며, 상급 승인 없이는 무기한 보류를 아예 막겠습니다. 고위험 알람 — ISA-18.2가 high/urgent 우선순위로 분류할 만한 것 — 은 최대 시간을 짧게 하거나 감독자 승인을 요구합니다. 저우선순위 진단 알람이면 긴 보류도 괜찮습니다.
무엇을 고르든 소프트웨어가 강제합니다.
- 만료 시 알람을 자동 복귀시키고 복귀를 기록한다
- 곧 만료될 보류를 미리 알리거나 나열한다(몇 분의 예고가 조용한 복귀보다 낫다)
- 보류·해제·만료 이벤트를 사용자와 시각과 함께 기록한다
핵심은 특정 숫자가 아니라, 그 한도가 "작업자가 내킨 대로"가 아니라 의도된 결정이라는 점입니다.
편의가 아니라 상태로 억제하라
상태 기반 억제는 특정 운전 상태에서 알람이 정말 의미가 없을 때 제값을 합니다. 이미 가진 장비 상태 모델에서 뽑아냅니다.
- 정지 / 기동 / 운전 / 정지 중
- 수동 / 자동 / 원격 / 로컬
- 생산 / 세정 / 정비 / 대기
- 운영 / 격리 / 운영 제외
- 통신 정상 / 실패
정지 명령된 펌프는 운전 피드백 실패 알람이 필요 없습니다. 세정 모드의 CIP 스키드는 생산 중과 다른 알람 세트를 원합니다. 좋습니다 — 조건을 문서화하고 시험하십시오.
제가 반대하는 건 목록을 짧게 하려고만 존재하는 억제 규칙입니다. 어떤 정상 상태에서도 쓸모없는 알람이라면 알람 자체가 틀린 것입니다. 셋포인트를 고치거나 지우십시오. 3년 뒤 누군가 역추적해야 할 억제 로직으로 덮지 마십시오.
억제가 위험해지는 지점은 품질 불량이다
사람들이 걸려 넘어지는 부분입니다. 상태 기반 억제는 운전 상태를 PLC에서 읽습니다. PLC, 원격 I/O 랙, 무선 링크, 프로토콜 게이트웨이가 끊기면 HMI는 현재라고 착각하는 오래된 상태로 알람을 억제하고 있습니다. 펌프가 "정지처럼 보여" 저유량이 계속 억제되지만, 실제로 펌프가 뭘 하는지는 알 수 없습니다.
그러니 실패 방향을 명시적으로 정하십시오.
- 품질 불량을 HMI에 드러낸다 — 오래된 값이 정상 초록으로 보이게 두지 않는다
- 억제를 좌우하는 장비의 통신 두절에 알람을 낸다
- 특별한 이유가 없다면, 좌우 품질이 나쁠 때 억제는 알람을 보여 주는 쪽으로 실패시킨다
- PLC 재기동, 서버 재기동, 네트워크 케이블 뽑기를 실제로 시험한다 — "데모에서는 됐다"가 조용히 무너지는 지점이다
원격 사이트에서는 통신 알람 하나가 더 이상 볼 수 없는 수십 개의 현장 알람을 대신합니다. 작업자의 머릿속 모델은 "알람 없음 = 정상"이므로, 이 관계를 분명히 보여 주십시오.
FAT/SAT에서 확인할 것
알람이 뜨는지만 증명하지 마십시오. 그 주변의 전체 생애주기를 증명하되, 마지막 시운전 날까지 미루지 마십시오 — 알람 상태 동작은 플랜트가 돌기 시작하면 디버깅하기 끔찍합니다.
- 알람이 올바른 우선순위·메시지·구역·장비로 뜬다
- 권한이 있어야만 보류할 수 있고, 지속 시간 옵션이 표준과 맞는다
- 필요한 코멘트가 강제된다
- 보류된 알람이 숨긴 알람 화면에 뜨고, 활성 보류 조건이 어딘가 보인다
- 만료가 알람을 복귀시키고 기록한다
- 억제가 의도한 장비 상태를 따라가고, 품질이 나빠지면 안전하게 실패한다
- disable과 bypass 동작이 사용자·시각과 함께 기록된다
- 이벤트 이력이 "누가 언제 왜 이 상태를 바꿨나"에 답할 수 있다
벽에 붙여 둘 규칙: 알림이 뜨지 않는 모든 알람은, 컨트롤러 코드를 열거나 오래된 메일을 뒤지지 않고도 HMI에서 설명이 돼야 합니다. 깨끗한 배너는 정직할 때만 가치가 있습니다.