배너는 비어 있었고 플랜트는 조용하지 않았다

새벽 2시 10분, 야간 근무, 배너에는 아무것도 없다

야간 operator가 22시에 콘솔을 인수했을 때 alarm banner는 비어 있었다. 그리고 계속 비어 있었다. 새벽 2시 10분쯤 현장에서 반장이 전화를 걸어, 자정 전부터 떠 있던 압축기 trip에 왜 아무도 대응하지 않았느냐고 물었다.

콘솔은 정상이었다. Alarm server도 정상이었다. Trip alarm은 active였고 unacknowledged였고 priority 1이었다. 주간 근무 기술자가 오후 내내 level transmitter를 쫓다가 banner 검색창에 LT-를 쳐 놓고 퇴근했을 뿐이다. 그 filter는 logout을 넘고 인수인계를 넘어, 조용해 보이는 화면으로 네 시간을 버텼다. 실제로는 tank farm 계측기 열한 개짜리 화면이었다.

설정을 잘못한 사람은 없다. Banner는 시킨 대로 정확히 동작했다. 다만 자기가 무슨 일을 하고 있는지 아무에게도 말하지 않았다.

Filter는 화면이고 suppression은 결정이다

이 둘은 한 문장 안에서도 자주 섞인다. ISA-18.2(국제 규격으로는 IEC 62682)가 굳이 구분해 놓은 데는 이유가 있다. 규격에서 suppression은 alarm을 annunciate할지 자체를 바꾸는 상태들의 상위 개념이다. Shelved(operator가 임시로, timeout을 걸어서), suppressed by design(로직 기반. 펌프가 정지 중이면 low flow alarm을 죽이는 식), out of service(정비 측에서, 권한을 받고, 기록을 남기고). 셋 다 권한 모델과 audit trail과 만료 조건이 필요하다. 셋 다 alarm system 자체를 바꾸는 행위다.

Filter는 그중 어느 것도 아니다. 지금 한 사람이 한 화면에서 무엇을 보는지만 바꾼다. 승인도 audit trail도 필요 없다. 대신 놓칠 수 없게 보여야 한다. 조용히 바뀌는 쪽이 이쪽이기 때문이다.

실무에서 쓰는 기준은 이렇다. Operator의 조작이 다른 사람이 보는 것까지 바꾸면 suppression이고 suppression 절차를 태운다. 자기 화면만 바꾸면 filter고, 그때 요구사항은 전부 "보이는가"로 옮겨간다.

Alarm source가 OPC UA server라면 이 구분은 이미 모델링되어 있다. Part 9(Alarms and Conditions)의 AlarmConditionType은 ActiveState, AckedState, ShelvingState, SuppressedState, OutOfServiceState를 각각 별도 substate로 들고 있다. Server가 채워주고 있다면 화면에도 올려야 한다. 이걸 전부 "알람/정상" 한 칸으로 뭉개는 banner는 프로토콜이 애써 넘겨준 정보를 버리는 것이다.

기본 view만이 진짜 view다

나머지는 전부 operator가 생각을 해야 쓰는 조작이다. 기본 view는 새벽 2시에 아무 생각 없이 받는 화면이다. 그러니 기본 view를 설계하고 나머지는 편의 기능으로 두는 게 맞다.

현장에서 다른 요구가 없으면 기본값은 이렇게 잡는다.

담당 area의 active unacknowledged alarm 전부, priority 1과 2, 최신순.
아직 condition이 참인 active acknowledged alarm은 그 아래에, 시각적으로 구분해서. Acknowledge는 해결이 아니다.
Safety, environmental alarm은 area 배정과 무관하게 항상. 두 unit 건너에 있는 가스 감지기는 남의 일이 아니다.
Hidden alarm count는 0일 때도 포함해서 항상 그려둔다.

여기 없는 것도 봐야 한다. Return-to-normal alarm은 기본 view에 넣지 않는다. ISA-18.2 상태 모델에서 RTN-unacknowledged는 엄연한 상태고 alarm summary에는 있어야 하지만, 이미 해소된 condition이 아직 위험한 active condition을 아래로 밀어내면 안 된다. 상단 세 줄이 전부 저절로 해결된 것들이던 banner를 본 적이 있다.

Banner strip은 여섯에서 여덟 줄이 한계다. 그보다 많아지면 그건 summary page지 banner가 아니고, operator는 가장 여유 없는 그 1분에 스크롤을 해야 한다.

Hidden count가 안전 논리의 전부다

Filter가 걸려 있는데 banner가 그 사실을 크게 말하지 않으면, 그 filter는 위험 요소다. 이게 전부다. 이 글의 나머지는 세부 사항이다.

표시는 구석의 dropdown 값이 아니라 banner의 1급 요소로 만들고, 한눈에 네 가지에 답하게 한다.

현재 view 밖에 active alarm이 몇 개인가.
그중 priority 1이 있는가. 이건 색을 따로 준다. 14개 숨김과 14개 숨김, critical 2는 다른 종류의 상황이다.
어떤 filter인가. Area, priority, state, text 중 무엇인가.
어떻게 푸는가. 메뉴 안이 아니라 화면에 보이는 버튼으로, 한 번에.

AREA FILTER: TANK FARM — active alarm 14개 숨김 (critical 2) [전체 보기] 같은 문구는 길고 안 예쁘다. 그래도 header bar에 은은한 색조를 주는 것보다는 이쪽을 택한다. ISA-101.01이 일관되고 모호하지 않은 상태 표시를 강하게 요구하는 것도 정확히 이 부류의 문제 때문이다. Filter는 mode고, 표시되지 않는 mode는 operator가 놀라는 경로다.

Session을 넘어가는 persistent filter는, area 배정 자체가 콘솔의 정체성인 전용 area console에서는 괜찮다. 공용 control room이나 engineering station에서는 아니다. 지원한다면 user session이 아니라 workstation 설정에 묶고, logout 시에는 어느 쪽이든 초기화한다.

Priority는 normalize하기 전까지 거짓말이다

Priority로 정렬하는 banner는 들어오는 priority 숫자만큼만 정확하다. 그리고 vendor skid를 모아 만든 플랜트에서 그 숫자들은 서로 아무 의미가 없다. 압축기 패키지는 자기 alarm을 전부 priority 1로 올린다. OEM 시운전 엔지니어가 자기 skid가 제일 중요하다고 생각했기 때문이다. 수처리 skid는 1~999를 쓰면서 작은 숫자가 급한 쪽이다. 세 번째 박스는 항상 priority 0만 낸다.

Banner가 보기 전에 gateway나 alarm server에서 normalize하고, vendor 원본 값은 detail 항목에 남긴다. 현장 서비스 인력은 그 숫자로 대화하기 때문이다.

Priority 배정이 실제로 의미가 있는지 확인하는 방법은 분포를 세어보는 것이다. EEMUA 191에서 자주 인용되는 비율은 대략 high 5%, medium 15%, low 80%다. 설정된 alarm의 60%가 priority 1이면 그건 priority 체계가 아니라 형식이고, 그 데이터 위에 얹은 priority filter는 text filter만큼이나 임의로 숨긴다.

발생률이 나머지 절반이다. ISA-18.2는 operator position당 10분에 alarm 10개를 넘으면 flood로 본다. EEMUA 191이 말하는 감당 가능한 장기 평균은 10분에 1개에 가깝다. Filter를 설계하기 전에 한 달치 수치를 자기 historian에서 뽑아본다. 평상시가 이미 flood 수준이면 그건 alarm rationalization 문제고, filter는 반창고다. Banner 설계로 해결되지 않는다.

통신 두절: lead alarm 하나를 정하고 지킨다

통신 장애는 반대 방향으로 동시에 고장 난다. Stale 값으로 계속 평가되는 파생 alarm이 banner를 덮거나, 아예 평가가 멈춰서 정작 문제가 생긴 unit이 조용해진다.

프로토콜이 주는 정보는 생각보다 편차가 크다.

DNP3(IEEE 1815)는 object octet에 point별 flag를 싣는다. ONLINE, RESTART, COMM_LOST, REMOTE_FORCED, LOCAL_FORCED, CHATTER_FILTER. Driver가 이걸 버리고 master에 값만 넘기고 있다면, outstation이 이미 계산해 준 quality 정보를 버리는 것이다.
OPC UA는 값마다 StatusCode를 준다. Bad_NoCommunication, Uncertain_LastUsableValue 같은 것들이다. Alarm 로직은 숫자 값이 아니라 severity 비트로 분기해야 한다.
Modbus는 아무것도 주지 않는다. 규격에 quality 개념이 없으니 gateway가 응답 timeout과 exception code로 만들어내야 하고, 이후의 모든 quality 판단은 누군가 정한 그 timeout에 걸려 있다. 그 timeout 값은 operator가 찾아볼 수 있는 곳에 적어둔다.

그다음 device 단위로 quality가 bad일 때 dependent alarm을 어떻게 할지 정한다.

PLC, RTU, gateway, skid마다 lead alarm 하나. 영향 point 수를 같이 싣는다. GATEWAY-3 COMMUNICATION LOST — 412 points.
평가가 불가능한 derived process alarm은 inhibit한다. Filter가 아니라 inhibit이다. Suppressed-by-design 경로로 처리하고 상태는 alarm summary에서 보이게 한다.
Hardwired alarm과 독립 전원 safety alarm은 건드리지 않는다. 여전히 유효하고, 네트워크가 죽었을 때 정확히 보고 싶은 것들이다.
Tag별 bad-quality alarm은 만들지 않는다. 412개짜리 목록은 진단이 아니라 자기 operator를 향한 서비스 거부다.

Trip 중인 operator가 PLC03_DI_1247을 해독하게 두면 안 된다. 한 줄이 훑어보기 가능한 한도는 대략 column 일곱 개다.

Column	자리값을 하는 이유
Time in	Condition이 active 된 시각. 메시지가 그려진 시각이 아니다
Priority	Normalize 후 값. 모든 화면에서 같은 색 규칙
Area / unit	내 담당인지
Equipment	현장의 실물. Pump, tank, drive, skid, tool
Condition	비정상 상태를 말로. Tag path가 아니라 "토출 압력 높음"
State	Active / acked / RTN-unacked / shelved / suppressed / out of service
Action hint	짧은 조치 한 줄, 또는 대응 절차 link

Engineering tag path도 필요하다. Detail pane에 넣으면 된다. 정비 쪽은 거기서 찾고 operator는 안 봐도 된다.

시험은 alarm 하나가 아니라 flood로 한다

Alarm 하나로 하는 시험은 banner가 줄 하나를 그릴 수 있다는 것만 증명한다. 실제로 무는 실패 모드는 아무것도 확인되지 않는다. 시운전 때 operator를 세워두고 아래를 강제로 만들어 본다.

한 unit에서 90초 동안 alarm 60개를 넣는다. 가장 급한 것이 여전히 banner 최상단에 있는가, 아니면 최신순 정렬에 묻히는가.
수백 point를 물고 있는 gateway를 끊는다. 몇 줄이 뜨는지 센다.
Area filter를 걸어놓고 다른 area에서 critical을 띄운다. 위의 압축기 상황이다. Operator가 banner만 보고 알 수 없다면 설계가 실패한 것이고 나머지는 장식이다.
Text filter를 남긴 채 logout하고 다른 사용자로 login한다. 여기서 일어나는 일이 화요일 22시에 일어날 일이다.
Condition이 아직 참인 alarm을 acknowledge한다. 사라지지 않는지 확인한다.
Unacknowledged alarm의 return-to-normal. RTN-unacked 전이는 다른 어떤 전이보다 alarm server가 많이 틀리는 지점이다.
Alarm이 active인 상태에서 alarm server를 재기동한다. Banner가 원래 timestamp로 복원되는가, 아니면 전부 재기동 시각으로 다시 찍히는가.

기록을 남긴다. 시계가 같이 나오는 화면 녹화는 비용이 0이고, 여섯 달 뒤 "banner에 안 떴다"는 논쟁을 어느 쪽으로든 끝내준다.

반복해서 보는 실수

Text search를 상시 filter로 쓴다. 그건 troubleshooting 도구다. 플랜트 구조와 무관한 문자열에 걸리고, 남아 있을 확률이 가장 높다. Mode가 아니라 검색창처럼 생겼기 때문이다.

Filter 걸렸을 때만 나타나는 표시. 합리적으로 들리지만 잘 동작하지 않는다. Operator는 위젯이 있는 것을 읽지, 없는 것을 읽지 않는다. Count는 항상 그리고, 숨긴 게 없으면 0으로 표시한다.

Vendor priority를 그대로 믿는다. 위에서 다뤘지만 다시 적어둔다. 필요했던 alarm이 필요 없던 alarm 아래로 정렬되기 전까지는 보이지 않는 문제다.

Shelving의 존재를 숨긴다. Shelved alarm을 전부 banner에 올릴 필요는 없다. 다만 선반이 비어 있지 않다는 사실과 어디서 확인하는지는 반드시 보여야 한다. 만료도 없고 개수 표시도 없는 shelf는 만든 사람보다 오래 사는 suppression이다.

기존 banner를 인수받아서 딱 하나만 시험한다면 3번을 한다. 조용한 area로 filter를 걸고, 다른 데서 심각한 것을 띄우고, 무슨 일이 있었는지 모르는 operator가 알아채는지 본다. 나머지는 다듬는 일이고, 이 하나가 banner가 안전한지를 알려준다.