Trip 직전 3분 동안 알람이 200건 넘게 올라왔다. 그중 하나가 압축기 Critical이었고, 운전자는 그걸 못 봤다. 화면은 최신순이었고 Chattering 중이던 Level Switch 하나가 1초에 한 번씩 목록 맨 위를 다시 차지했다. Critical 알람은 사고 조사에서 Event History를 뒤진 다음에야 나왔다.
Alarm Summary가 알람을 지운 게 아니다. 알람 서버는 ISA-18.2 상태 모델대로 상태를 그대로 들고 있었고, Filter가 일부를 숨겼고, 정렬이 남은 걸 줄 세웠다. 운전자 눈에 닿은 건 그 마지막 단계의 결과물이다. 어느 단계에서 잃어버렸는지부터 구분해야 한다.
최신순은 flood에서 제일 먼저 무너진다
ISA-18.2(IEC 62682로 그대로 채택됐다)는 alarm flood를 운전자 1인 기준 10분에 10건을 넘는 구간으로 정의한다. EEMUA 191이 흔히 인용하는 정상 운전 목표치는 운전자 1인당 10분에 1건이다. flood는 목표치의 10배 이상인 상태다. 그 구간에서 최신순 정렬은 Alarm Summary를 화면에 흐르는 로그로 바꿔 버린다. 운전자가 읽는 속도보다 목록이 빨리 움직인다.
Chattering Alarm이 여기에 얹히면 더 나쁘다. ISA-18.2는 chattering을 짧은 시간 안에 알람 상태와 정상 상태를 반복해서 오가는 알람으로 정의한다. 최신순에서는 그런 알람 하나가 상단 몇 줄을 영구히 점유한다. 등급은 낮은데 자리는 제일 좋은 곳을 먹는다.
| 기본 정렬 | 잘 맞는 경우 | 주의점 |
|---|---|---|
| Unacknowledged 먼저, 그다음 Priority | 비정상 상황 대응 | Acknowledge된 Critical Alarm이 아래로 밀린다. |
| Priority, 그다음 Active Time | Area 하나를 한 사람이 보는 라인 | 낮은 등급 신규 알람이 잘 안 보인다. |
| 최신순 | 시운전, Event 확인 | Chattering Alarm이 상단을 점유한다. |
| Area, 그다음 Priority | Area 책임이 나뉜 큰 설비 | Area 정보가 틀리면 Cross-area 문제를 놓친다. |
| First-out Sequence | Trip, Shutdown 원인 분석 | 평상시 Live Summary 기준으로는 부족하다. |
내가 Main Operating Summary 기본값으로 쓰는 건 첫 줄이다. Unacknowledged 먼저, 그다음 Priority, 같은 Priority면 오래된 것 먼저. 아직 아무도 안 본 알람이 위로 오고, 확인한 알람은 사라지지 않고 아래로 내려간다. 최신순은 시운전 화면과 Event History에만 남긴다.
운전자가 정렬을 바꿀 수 있어도 된다. 대신 Site Default로 되돌리는 버튼이 같은 화면에 있어야 하고, 기본값이 무엇인지는 문서에 적혀 있어야 한다. 사고 조사에서 "그때 뭐로 정렬돼 있었냐"는 질문이 반드시 나온다.
상태는 Row가 움직여도 남아 있어야 한다
ISA-18.2 상태 모델에는 Normal, Unacknowledged, Acknowledged 말고도 운전자가 구분해야 하는 상태가 더 있다. Return-to-normal but Unacknowledged, Shelved, Suppressed by design, Out-of-service다. 이 넷을 Summary에서 뭉개면 뒤에 나오는 실패 모드 절반이 여기서 시작된다.
- Return-to-normal but Unacknowledged — 공정은 정상으로 돌아왔지만 아무도 확인하지 않았다. 여기서 Row를 지우면 transient abnormal은 흔적 없이 사라진다. 짧게 떴다 사라지는 알람이 원인 분석에서 가장 값어치 있는 경우가 많다.
- Shelved — 운전자가 일시적으로 내린 것. ISA-18.2는 shelving을 임시 조치로 보고, 무엇이 shelve돼 있는지 볼 수 있는 목록을 전제한다. 자동 해제 시간이 없으면 shelving은 조용한 disable이 된다.
- Suppressed by design — 설계된 로직이 억제한 것. 운전자가 푼 게 아니라 상태 조건이 푼다.
- Out-of-service — 정비 목적의 제거. 권한과 기록이 붙어야 하는 항목이다.
Row 스타일은 단순하게 둔다. Active Unacknowledged를 제일 강하게, Active Acknowledged는 계속 보이되 강조를 낮추고, Return-to-normal but Unacknowledged는 따로 구분한다. Shelved, Suppressed, Disabled, Out-of-service는 표시를 숨기지 않는다.
색으로만 의미를 전달하지 않는다. ISA-101이 같은 얘기를 한다. 현장 모니터는 캘리브레이션이 안 돼 있고, 야간 조명은 낮과 다르고, 색각 이상은 남성 20명 중 1명꼴이다. 색 + 문자 상태 Column이면 셋 다 통과한다.
정렬 Column을 바꿨다고 Row의 의미가 바뀌면 안 된다. 이건 협상 대상이 아니다.
Filter는 자기가 숨긴 개수를 띄워야 한다
Filter 자체는 필요하다. Utility 담당자가 Packaging Alarm까지 늘 볼 이유는 없다. 문제는 Filter가 조용히 동작할 때다.
Summary 상단에 항상 있어야 하는 것:
- 현재 걸린 Area, Equipment, Priority, State Filter
- 지금 보이는 Alarm Count
- Filter 밖에 있는 Active Alarm Count — 0이 아니면 눈에 띄어야 한다
- Shelved, Suppressed, Disabled, Out-of-service Count
- Site Default Filter로 돌아가는 버튼
숨은 개수를 Tooltip이나 Detail 화면에 넣는 구현을 여러 번 봤다. 그건 없는 것과 같다. Header에 숫자로 있어야 한다.
Filter가 Login Session을 넘어 유지되는 동작은 기본값으로 두지 않는 편이 낫다. 야간조가 Skid 하나만 보려고 걸어 둔 Filter가 주간조 화면에 그대로 남는 상황이 실제로 사고가 된다. 유지해야 한다면 Logout 시 초기화하거나, 최소한 다음 로그인 화면에서 크게 알려야 한다.
Acknowledge 직후에 목록이 튀는 문제
Acknowledge는 상황이 나쁠 때 빠르게 눌린다. 그 순간 정렬 Key가 바뀌어서 Row가 움직이면 다음 클릭이 엉뚱한 알람에 들어간다. Unacknowledged 우선 정렬을 쓰면 이 문제가 구조적으로 따라온다 — Acknowledge하는 순간 그 Row가 목록 아래로 뛰기 때문이다.
해법은 정렬을 포기하는 게 아니라 재정렬을 늦추는 것이다. 마우스가 목록 위에 있는 동안, 또는 마지막 클릭 후 2초 정도는 순서를 얼려 둔다. Platform마다 구현 방법은 다르지만 동작 요구사항은 같다.
시험할 항목:
- Acknowledge 직후 Row가 즉시 이동하는가?
- 여러 Row를 선택한 상태에서 선택이 의도한 Row에 남아 있는가?
- 특정 Priority에서 Operator Note를 요구하는가?
- Mass Acknowledge가 Role이나 Alarm Class로 제한되는가?
- Server가 Acknowledge를 거부했을 때 화면에 실패가 보이는가? (조용히 성공한 것처럼 보이는 구현이 있다)
- Return-to-normal but Unacknowledged 알람이 Acknowledge 작업 중에도 계속 보이는가?
Live Summary와 Event History는 다른 화면이다
Live Summary는 지금 남아 있는 부담을 보여준다. Event History는 나중에 왜 그랬는지 재구성하는 데 쓴다. 목적이 다르니 Row 수명도 달라야 한다.
모든 과거 Event를 Main Summary에 남기면 운전자는 목록 전체를 무시하기 시작한다. 반대로 Return 후 미확인 알람까지 숨기면 앞에서 말한 transient가 사라진다. 두 화면을 Link로 연결하되 내용은 섞지 않는다.
기본 Column은 이 정도면 충분하다.
| Column | 메모 |
|---|---|
| Time In | 가능하면 Source Time. Site가 여러 Timezone이면 표시를 명확히 한다. |
| Area / Unit | 실제 운전 책임 구분과 맞아야 한다. |
| Equipment 또는 Tag | Raw Tag Name만 두지 말고 읽을 수 있는 설비명을 같이 둔다. |
| Alarm Message | 조건과 Limit가 필요하면 같이 보여준다. |
| Priority | Alarm Philosophy의 용어와 맞춘다. |
| State | Active, Acknowledged, Returned, Shelved, Suppressed, Out-of-service를 구분한다. |
| Duration | Standing Alarm을 찾는 유일한 실용적 수단이다. |
| Action Link | Faceplate, Procedure, Trend 화면으로 간다. |
Duration Column은 과소평가된다. 교대마다 한 번 Duration 내림차순으로 정렬해 보면 며칠째 서 있는 알람이 바로 나온다. ISA-18.2는 그런 알람을 stale alarm으로 부르고 24시간을 흔한 기준으로 쓴다. 그 목록이 길면 Alarm Summary 설계 문제가 아니라 Alarm 설정 문제다.
조용한 FAT는 아무것도 증명하지 못한다
Alarm Summary는 조용할 때 잘 동작한다. 깨지는 건 시끄러울 때다. 그러니까 시끄러운 상태를 만들어서 시험해야 한다. 시뮬레이터나 강제 알람으로 충분하다.
- Low Priority 알람 100건이 Active인 상태에서 Critical Alarm 하나를 띄운다.
- Chattering Alarm이 반복되는 동안 High Priority Alarm을 유지한다.
- Area Filter가 걸린 상태에서 다른 Area의 Critical Alarm을 띄운다. 숨은 개수가 올라가는지 본다.
- Return-to-normal but Unacknowledged를 만든 뒤 다른 Row를 Acknowledge한다.
- Shelved/Suppressed 알람이 있는 상태에서 Main Summary Filter를 바꾼다.
- Active Alarm이 있는 상태에서 Redundant Server나 Alarm Service를 Restart한다.
- 제일 느린 Workstation에서 flood 중에 Summary를 연다.
결과는 Screenshot이나 짧은 화면 녹화로 남긴다. 기본 정렬, 보이는 개수, 숨은 개수, 상태 표시, Acknowledge 동작이 화면에 찍혀 있어야 한다.
자주 나오는 결과는 몇 가지로 수렴한다.
| 실패 | 현상 | 수정 방향 |
|---|---|---|
| Chatter가 상단 점유 | 최신순 때문에 반복 알람이 계속 위로 감 | 정렬을 바꾸고 Chattering 원인을 고친다 |
| Active Alarm이 숨음 | Filter View에 숨은 개수가 없음 | Header에 숨은 Active 개수를 띄운다 |
| Clear된 알람이 즉시 사라짐 | transient를 운전자가 못 봄 | Return-to-normal but Unacknowledged를 유지한다 |
| Cursor 밑 Row가 바뀜 | Acknowledge 직후 재정렬 | 재정렬을 지연시킨다 |
| Shelved를 잊음 | Main Summary에서 완전히 사라짐 | Count와 Review Link를 둔다 |
| Event Journal이 Live Summary 역할 | 상태 섞인 수천 Row | 두 화면을 분리한다 |
문서에 남기는 것
기본 Sort Order, 기본 Filter, 상태 표시 정의, 숨은 개수 동작, Acknowledge와 Mass Acknowledge 규칙, Shelving/Suppression/Out-of-service 표시 방식, flood 시험 결과. 한 페이지면 된다.
이게 있으면 사고 조사에서 "HMI가 알람을 숨겼다"와 "설정된 Filter View를 보고 있었다"를 구분할 수 있다. 둘은 완전히 다른 문제고, 고치는 곳도 다르다. 기록이 없으면 둘 다 HMI 탓이 된다.