헤더 압력이 처지자 운전자가 트렌드를 열었는데, 화면에는 오토스케일 축 위에서 40과 80 사이를 오가는 PT_204 펜 하나뿐이었습니다. 설정값도, 밸브 개도도, 펌프 운전 상태도 없어서 계기가 움직인 건지 공정이 움직인 건지 알 길이 없었습니다. 그 트렌드가 틀린 건 아니지만, 새벽 2시에 유일하게 중요한 질문—무엇이 먼저 움직였나—에는 답하지 못했습니다.
트렌드가 화면 자리값을 하려면 몇 개의 태그를 하나의 인과 이야기로 바꿔 줘야 합니다. 제가 넘겨받는 트렌드는 대개 그 반대입니다. 외로운 펜 하나, 아니면 서로 상관없는 스무 개를 같은 축에 욱여넣은 것. 둘 다 원인을 좁혀 갈 때는 쓸모가 없습니다. ISA-101(Human-Machine Interfaces for Process Automation Systems)이 트렌드에 한 절을 통째로 할애하는 이유가 이것입니다. 트렌드는 장식이 아니라 진단 계기입니다.
태그가 아니라 질문에서 시작하라
태그가 있으니까 트렌드를 만들지 마십시오. 누군가 시간에 따른 거동을 비교해야 하기 때문에 만드는 겁니다. 펜을 고르기 전에, 저는 이 트렌드가 답해야 할 질문을 화면 설정 맨 위에—달리 둘 데가 없으면 주석에라도—적어 둡니다.
- 이 알람이 뜨기 직전 1분 동안 무엇이 바뀌었나?
- 명령이 우리가 기대한 피드백을 만들어 냈나?
- 루프가 발진하는 건가, 아니면 그냥 계기 노이즈인가?
- 상단(upstream) 조건이 하단(downstream)보다 먼저 움직였나?
태그는 질문을 따라옵니다. 스무 줄짜리 트렌드는 꼼꼼해 보이지만 보통 분석을 느리게 만듭니다. 정작 중요한 하나의 관계가 상관없는 열아홉 개 아래 묻히기 때문입니다.
근처에 있어서가 아니라 제어 루프 단위로 묶어라
쓸모 있는 묶음은 설비나 루프를 따라갑니다. 펌프라면 명령, 운전 피드백, 속도나 출력, 토출·흡입 압력, 유량, 그리고 트립/permissive 상태를 원합니다. "P-204 faceplate에 있는 모든 태그"가 아닙니다. PID 루프라면 루프 거동을 한눈에 읽게 해 주는 네 신호를 원합니다.
| 펜 | 트렌드에 넣는 이유 |
|---|---|
| Process variable | 루프가 실제로 하고 있는 것 |
| Setpoint | 루프에게 시킨 것 |
| Controller output(또는 밸브 개도) | 루프의 노력 — 포화와 windup이 보인다 |
| Mode / 설비 상태 | Auto/Manual, Running/Stopped — "왜 반응 안 했나"의 절반 |
여기에 유력한 외란 변수 한둘과, 플랫폼이 지원하면 알람 리밋 선을 더합니다. 그게 전부입니다. 한 축에 단위를 섞는 것 자체는 괜찮습니다. 밸브 퍼센트와 헤더 압력은 정말 유용한 짝입니다. 단, 운전자가 어느 펜이 어느 스케일인지 한눈에 구분할 수 있을 때만입니다. 구분이 안 되면 트렌드가 아니라 퍼즐을 만든 겁니다.
오토스케일은 탐색용이지 운전용이 아니다
펜마다 독립 오토스케일을 거는 것은 운전자를 속이는 가장 빠른 방법입니다. 센서 노이즈로 ±0.3 barg 떠는 태그가 화면을 가득 채워 위기처럼 보이고, 넓은 고정 스케일 위의 진짜 2 barg 편차는 baseline에 묻혀 사라집니다. 오토스케일은 낯선 데이터를 뒤질 때는 훌륭하지만, 압박 속에서 읽는 화면의 기본값으로는 나쁩니다.
그러니 스케일을 의도적으로 잡으십시오. 아날로그 펜마다 정상 운전 밴드, 알람/공학 리밋, 기동·정지 시 견뎌야 할 극값, 그리고 0이 보여야 하는지를 정합니다. 유량, 속도, 밸브 명령, 퍼센트 출력은 거의 항상 0 기준이어야 합니다. 축이 400 m³/h에서 시작하는 유량 트렌드는 10% 하강을 파국처럼 보이게 만듭니다. 헤더 압력, pH, 좁은 온도 루프는 축에 라벨이 붙어 있는 한 좁은 밴드에서 더 잘 읽힙니다. 애매하면 안정적인 고정 기본값을 주고, 문제 분석용으로 수동 재스케일을 열어 두십시오.
트렌드가 구멍을 선으로 잇게 두지 마라
이게 사람 여럿을 데는 실패입니다. 수집기가 10분간 통신을 잃었다면, 트렌드는 마지막 정상 샘플과 다음 정상 샘플을 매끄러운 선으로 이어 마치 공정이 얌전히 그렇게 움직인 척해서는 안 됩니다. 이벤트 중에는 데이터 품질도 이벤트의 일부입니다. 트랜스미터가 고장 나서 떨어진 압력 트렌드와 펌프가 트립해서 떨어진 압력 트렌드는 전혀 다른 문제인데, 직선 보간은 그 차이를 감춥니다.
플랫폼에서 두 가지를 확인하십시오.
- 불량 품질, 불확실 품질, 통신 끊김, 수집기 정지를 어떻게 그리는지 — 간극, 점선 구간, 색 변화, 무엇이든 좋지만 자신만만한 직선은 안 됩니다.
- 히스토리언 압축이 조용히 무엇을 삼키고 있는지. Swinging-door/데드밴드 압축은 디스크를 아끼려는 것이지만, 빠른 압력 태그에 걸린 1% 데드밴드는 후단 인터록을 트립시킨 3초짜리 스파이크를 태연히 버립니다. PLC가 분명히 반응한 편차를 트렌드가 못 보여 주면, 계기를 의심하기 전에 데드밴드를 의심하십시오.
알람 대응 트렌드에는 리밋 선을 올려라
알람 대응이야말로 트렌드가 값을 하는 자리이므로, 고압 알람 화면은 알람 비트 하나보다 훨씬 많은 것을 보여 줘야 합니다. 압력, 그 설정값, 밸브 출력, 펌프·압축기 상태, 상단·하단 조건, 그리고 같은 축에 그린 알람 리밋 선까지. 무엇보다 알람 직후가 아니라 직전 구간을 보여 줘야 합니다. 원인은 거의 항상 그 진입 구간에 있습니다. ISA-18.2는 알람 합리화를 "운전자가 무엇을 하는가"로 밀어붙이는데, 그 화면의 트렌드는 운전자가 짝이 되는 태그를 뒤지지 않고도 그 답을 분명히 보게 해야 합니다.
알람이 shelve되거나 억제되었더라도, 트렌드는 shelve 구간 동안의 실제 공정 값을 그대로 보여 줘야 합니다. 알림을 억제하는 것이 비정상 값을 감출 이유는 아닙니다.
운전자 트렌드와 엔지니어 트렌드는 같은 화면이 아니다
운전자는 신뢰할 수 있는, 이름 붙고 안정적이며 업무 지향적인 트렌드가 필요합니다. 시운전·튜닝·근본 원인 분석에는 컨트롤러 내부값, 통신 카운터, 임시 테스트 포인트로 빽빽한 일회용 트렌드가 필요합니다. 둘 다 정당하지만, 하나의 화면으로 만들면 어느 쪽도 만족시키지 못합니다. 운전자용 라이브러리는 정리되고 예측 가능하게 유지하십시오. 임시 엔지니어 트렌드가 계속 유용하면 낙서 화면으로 두지 말고, 제대로 된 라벨·스케일·담당자를 붙여 유지 라이브러리로 승격하십시오.
그 마지막 단어가 중요합니다. 트렌드는 다른 HMI 객체처럼 낡습니다. 태그명이 바뀌고, 트랜스미터가 교체되고, 압축 설정이 흘러가고, 제어 전략이 바뀝니다. 인계 시점에 소유권을 지정해서 누가 트렌드 라이브러리 변경을 승인할 수 있는지 현장이 알게 하십시오. 그러지 않으면 모든 화면이 자기가 그려졌던 플랜트와 서서히 어긋나게 됩니다.
알려진 이벤트로 시운전하라
선이 그려지는지 확인하는 것은 시운전이 아닙니다. 인계 전에 알려진 이벤트—펌프 기동, 밸브 스트로크, 모드 변경, 의도적 설정값 조정—를 일으키고, 트렌드가 현장·PLC 로직과 같은 이야기를 하는지 확인하십시오. 온 김에 지루한 목록도 훑으십시오. 모든 펜이 올바른 태그를 가리키는지, 단위와 라벨이 맞는지, 스케일이 정상과 이상 조건 모두에서 버티는지, 기본 시간창이 설비에 맞는지(모션은 초, 유량·압력 루프는 수십 분, 탱크와 열 시스템은 시간, 파울링과 느린 드리프트는 일 단위), 디지털 상태가 실제 설비 상태와 일치하는지, 서버 재기동이나 수집기 failover 후에도 이력 조회가 되는지.
그 시험에서 트렌드와 현장이 어긋나면, 배선·스케일·태그 매핑 오류를 값싸게 찾은 겁니다. 실제 이상 상황에서 운전자가 찾기 전에 하는 것—그게 시운전을 미리 하는 이유의 전부입니다.