알람 합리화 워크숍, 숫자 네 개를 먼저 측정하고 들어간다

회의실에 알람 목록 3,200줄을 띄워 놓고 두 시간 동안 42줄을 검토했다. 그날 지운 알람은 7개. 다음 주 교대 보고서에 올라온 최다 알람은 그 전주와 똑같았다.

문제는 회의 진행이 아니었다. 들어갈 때 측정값이 없었다는 것이다. "알람이 너무 많다"는 말로는 아무 결정도 내려지지 않는다. ISA-18.2(국제 표준으로는 IEC 62682, 내용은 동일)와 EEMUA 191은 운전원 1명 기준의 숫자를 이미 정해 놓았다. 그 숫자를 먼저 뽑아야 회의가 "이 알람을 어떻게 할까"가 아니라 "목표까지 2,000건을 줄여야 한다"로 시작한다.

들어가기 전에 뽑을 숫자 네 개

historian에서 최소 30일, 가능하면 90일을 뽑는다. 운전원 콘솔 단위로 집계해야 한다. 설비 단위로 집계하면 기준값과 비교가 안 된다.

ISA-18.2-2016 clause 16(monitoring and assessment)이 요구하는 지표가 이 계열이다. 네 개 다 SQL 한 번이면 나온다. 안 뽑고 들어가면 회의는 가장 목소리 큰 사람의 의견대로 흘러간다.

brownfield 현장에서 실제로 나오는 값은 10분당 1240건, stale 1050건, high/critical이 전체의 절반이다. 마지막 항목이 특히 중요하다. 설정된 알람의 60%가 우선순위 1이면 우선순위 체계가 없는 것이다. 형식만 있는 것이다. 자세한 건 알람 우선순위 매트릭스에 적었다.

알람인지 아닌지 정하는 질문 하나

ISA-18.2-2016은 알람을 "적시 대응(timely response)을 요구하는 비정상 상태를 알리는 수단"으로 정의한다. 정의에 두 조건이 들어 있다. 비정상, 그리고 대응.

운전원이 할 일이 없으면 알람이 아니다. 이건 취향 문제가 아니라 정의 문제다. "언젠가 정비 부르기"는 work notification이고, pump 기동 permissive 미충족은 faceplate의 상태 표시다. 밸브 seat 누설 진단은 maintenance로 보낸다. 새벽 3시에 운전원이 할 수 있는 게 없는 항목을 알람 목록에 넣으면, 정작 읽어야 할 알람의 자리를 빼앗는다.

각 알람에 이 순서로 묻는다.

1. 비정상 상태인가, 정상 운전 정보인가?
2. 정해진 운전원 조치가 있는가? 문장으로 쓸 수 있는가?
3. 그 조치가 의미 있을 만큼 시간이 남는가?
4. 조치하지 않으면 생기는 결과를 숫자로 말할 수 있는가?
5. 상위나 하위의 더 나은 알람이 이미 같은 상황을 잡고 있지 않은가?
6. 지금 있는 계측기로 이 조건을 믿을 만하게 검출할 수 있는가?

2번에서 막히면 알람이 아니다. 3번에서 막히면 알람 위치가 잘못됐다. 공정이 이미 넘어간 뒤에 뜨는 알람은 기록이다.

거의 항상 비어 있는 칸

ANSI/ISA-18.2(그리고 IEC 62682)는 rationalization 단계에서 원인, 결과, 시정 조치, 대응 가능 시간을 기록하라고 한다. 내가 열어 본 알람 데이터베이스는 앞의 세 개는 어떤 형태로든 들어 있었다. 네 번째는 거의 다 비어 있다.

그런데 운전원 행동을 가장 많이 바꾸는 칸이 그 네 번째다.

"확인하십시오"는 조치 문구가 아니다. 어디를 보고 무엇을 결정하는지가 들어 있어야 한다. 문구 작성은 알람 도움말과 조치 문구에서 더 다뤘다.

억제 용어를 회의 시작 전에 못 박는다

현장 대화에서 shelve, suppress, disable, bypass는 뒤섞여 쓰이고, HMI 설정에서도 뒤섞여 들어간다. ISA-18.2-2016은 이걸 서로 다른 상태로 분리해 놓았다. 상태별로 권한과 전이가 다르다.

• Shelved — 운전원이 직접, 임시로 내린다. 자동 해제 시각이 있어야 한다. timeout 없는 shelve는 조용한 disable이다.
• Suppressed by design — 로직이 내린다. pump가 정지 중일 때 low flow 알람을 죽이는 것이 이쪽이다. 설계 문서에 들어간다.
• Out of service — 정비가 내린다. 더 높은 권한이 필요하고, 추적과 복귀 점검이 따라붙는다. 정비 bypass는 shelve가 아니라 이쪽이다.

표준의 상태 모델에는 Normal, Unacknowledged, Acknowledged, Return-to-normal Unacknowledged, Shelved, Suppressed by design, Out of service가 있다. 현장에서 이 일곱 개의 이름을 바꿔 쓰는 경우가 많고, 교대 인계 때 어긋나는 게 바로 그 이름들이다. 워크숍 첫 30분에 용어 대응표를 만들어 벽에 붙여 놓는다. 자세한 구분은 알람 shelving과 suppression에 있다.

동작도 같이 본다, 문구만 보지 말고

• setpoint가 정상 운전 범위 밖에 있는지 확인한다. 안쪽에 있으면 그 알람은 정상 운전을 알람으로 신고하고 있다.
• noisy 신호에는 delay나 filter를 쓴다. 단, 빠른 안전 관련 조건은 지연으로 덮지 않는다. ISA-18.2는 delay-on, delay-off, deadband를 rationalization에서 결정하는 알람 속성으로 다룬다. 짜증 난 사람이 그때그때 바꾸는 값이 아니다.
• analog 알람에는 deadband를 준다. 없으면 임계값 주변에서 떨린다. ISA-18.2는 chattering을 짧은 시간 안에 알람과 정상 상태를 반복 전이하는 알람으로 정의한다. 하나가 10분에 10건을 혼자 다 쓸 수 있다.
• high와 high-high는 운전원 조치가 서로 다를 때만 둘 다 남긴다. 둘 다 "누구 부르기"면 하나는 소음이다.
• 기동, 정지, 세정, 품종 전환, 정비 상태에서 알람 동작을 각각 확인한다. 정상 운전만 보고 설계한 알람이 flood를 만드는 자리가 여기다.
• 비활성화되어 있거나 억제 중인 알람도 검토 대상에 넣는다. 꺼져 있는 알람은 nuisance 알람이거나, 고장 난 계측기거나, 문서화되지 않은 공정 변경이다. 셋 중 어느 것인지 알아야 한다.

워크숍이 망하는 방식

• 설비나 공정 구역이 아니라 알파벳 순으로 검토한다. 같은 원인에서 나오는 알람들이 서로 멀리 떨어진다.
• 한 부서가 모든 우선순위 결정을 가져간다.
• 발생 횟수가 적다는 이유로 알람을 지운다. 1년에 두 번 뜨는 sync 상실 알람은 그래서 중요하다.
• "공정 이상" 같은 결과 표현을 그대로 받아들인다. 숫자가 없으면 우선순위를 정할 수 없다.
• 야간 근무자에게 없는 지식에 기대는 조치 문구를 쓴다.
• 설정 변경을 담당자와 기한 없이 회의록 메모로 남긴다. 이게 가장 흔하다.
• HMI faceplate, 알람 도움말, historian 이벤트, 교육 자료 갱신을 빼먹는다.

끝났는지 판정하는 기준

회의록은 산출물이 아니다. 설정에 들어간 변경과, 변경 후 다시 측정한 숫자가 산출물이다.

마지막 줄이 합격 기준이다. 변경을 넣고 2주 뒤에 10분당 알람 수와 stale 개수를 다시 뽑는다. stale이 5건 미만으로 내려오지 않으면 합리화 기록은 서류상 맞고 제어실에서는 틀린 것이다. 그때는 standing 알람 검토를 정비 work order에 연결하는 쪽이 다음 할 일이다.