HMI 화면이 느리면 그래픽 말고 태그 부하부터 재라

5초짜리 faceplate

알람이 뜬다. 운전자가 해당 pump를 클릭한다. faceplate가 뜨기까지 5초. 그 5초 동안 운전자는 아무 판단도 못 한다.

이런 화면을 두고 회의에서 나오는 첫 마디는 대개 "그래픽이 무겁다"다. 그런데 실제로 재보면 mimic과 symbol 로딩은 몇백 ms에서 끝나고, 나머지 대부분을 화면 구석에 박아둔 trend widget의 historian 조회가 먹고 있는 경우가 많다. 그래픽을 다시 그리면 5초가 4.8초가 된다.

그래서 순서가 중요하다. 재고, 나누고, 그 다음에 고친다.

first-load와 update는 다른 고장이다

두 운전자가 똑같이 "화면 느려요"라고 말해도 가리키는 게 다르다.

first-load 지연 — navigation 클릭부터 화면을 쓸 수 있을 때까지. 그래픽 파일 크기, symbol library, startup script, 최초 tag subscription, alarm/historian 조회, browser cache가 섞여 있다.
update 지연 — 이미 열린 화면에서 현장 값이 바뀐 뒤 화면에 보일 때까지. PLC scan, driver scan class, subscription 설정, network latency, server CPU, client rendering이 섞여 있다.

이 둘을 안 나누면 엉뚱한 데를 고친다. 재는 순서는 이렇다.

Client를 재시작하고 화면을 열어 first-load를 잰다.
같은 화면을 닫았다 다시 열어 cached-load를 잰다. 1번과 2번 차이가 크면 캐시 가능한 초기화가 범인이다.
안전한 test bit나 simulator 값을 바꾸고 화면에 반영되는 시간을 잰다.
한가한 시간대와 생산 피크에서 각각 반복한다.
Local panel, thin client, remote desktop을 따로 잰다.

처음만 느리고 갱신은 즉각적이면 화면 초기화 문제다. 모든 화면에서 갱신이 느리면 화면은 무죄고 scan class, subscription, server, PLC 통신을 봐야 한다.

기록에는 화면 이름과 revision, client 종류, 화면이 실제 요청하는 live tag 수, 제일 느린 위젯, client에서 PLC까지의 경로를 같이 남긴다. 이게 없으면 6개월 뒤에 똑같은 회의를 다시 한다.

태그는 프로젝트가 아니라 화면 단위로 센다

태그가 80,000개인 프로젝트도 화면이 필요한 것만 구독하면 잘 돈다. 태그가 3,000개뿐이어도 overview 하나가 전 장비의 상세 태그를 1초 주기로 읽으면 느리다. 프로젝트 태그 수는 성능 지표가 아니다.

화면 요소	부하가 생기는 지점	현장 확인
Overview mimic	장치 수, 상태 색상, 집계 값	보이는 binding과 숨은 binding을 같이 센다
Motor/valve faceplate	중간 태그 수, 빠른 응답 기대	선택한 장치 태그만 구독되는지 확인
Alarm summary	조회, 정렬, filter	정상 상태와 flood 상태를 둘 다 시험
화면 안 trend	Historian 조회 + live cursor	조회 시간과 update 시간을 따로 측정
Recipe/MES panel	Database, web service 지연	Request 시간과 timeout 처리를 log로
Diagnostic page	값은 많지만 급하지 않은 태그	느린 scan 또는 on-demand load

숨은 tab, 화면 밖 popup, 최소화된 창이 계속 subscribe하는 HMI가 흔하다. 편집기에서 안 보인다고 런타임 부하가 없다는 뜻이 아니다. 런타임의 subscription 진단 화면에서 확인해야 한다.

Derived tag도 세야 한다. binding은 200개인데 색상 expression 하나가 source tag 10개를 읽으면 실제 부하는 2,000개짜리다.

전부 빠른 scan class에 넣는 게 제일 흔한 실수

시운전 마지막 주에 꼭 나온다. 화면에 보이는 태그를 전부 제일 빠른 scan class에 몰아넣고 "일단 되니까" 하고 넘어간다. 그날은 편하고 부하는 5년 남는다.

용도로 나눈다.

빠른 status: running/stopped/faulted, 중요 interlock, 운전자 command feedback.
중간 process value: 판단에 쓰는 온도, 압력, 유량, level.
느린 diagnostic: firmware version, 제어반 온도, 누적 운전시간, 정비 counter.
On-demand: tuning parameter, vendor diagnostic array, 몇 달에 한 번 보는 setup 값.

Pump serial number를 초당 10번 읽을 이유는 없다. 반대로 emergency stop 상태를 1분에 한 번 읽는 건 그냥 사고다. 판단 기준은 화면이 아니라 그 값으로 사람이 무슨 결정을 하느냐다.

ANSI/ISA-101.01-2015가 말하는 display hierarchy가 여기서 그대로 성능 기준이 된다. Level 1 overview는 공정이 흔들릴 때 제일 먼저 열리는 화면이니 빨라야 하고, Level 4 diagnostic은 느려도 된다. 두 화면에 같은 scan rate를 주는 순간 예산이 새기 시작한다.

화면 안에 박힌 trend와 alarm table은 그림이 아니라 query다. 과거 데이터를 긁고, 수천 건을 정렬하고, filter를 걸고, 운전자가 뭘 하려는 동안에도 계속 refresh한다.

Trend에서 볼 것:

기본 time range. 30일로 박혀 있는 걸 제일 많이 봤다. 운전자는 최근 1시간만 보는데 화면 열 때마다 큰 historian query가 돈다. 8시간이면 충분한 화면이 대부분이다.
기본으로 열리는 pen 수. 6개 열어놓고 실제로 보는 건 1~2개인 경우.
긴 범위 조회에 sampling이나 compression을 쓰는지. Historian 쪽 설정은 히스토리언 데드밴드 설정에서 따로 다뤘다.
조회가 실패했을 때 화면 전체가 멈추지 않고 실패가 보이는지.
데이터가 몇 달 쌓인 상태에서 시험했는지. 새 historian에서 잰 숫자는 아무 의미 없다.

Alarm table에서 볼 것:

faceplate에서 열 때 area/equipment filter가 걸리는지. 로컬 패널이 전 사이트 alarm history를 매번 끌어오면 flood 때 같이 죽는다.
Flood 중에 정렬과 acknowledge가 버티는지. 흔히 인용되는 EEMUA 191의 기준(운전원 1인당 10분에 10건 초과)을 넘는 상황을 만들어놓고 시험해야 의미가 있다. 정렬 방식 자체가 위험한 경우는 Alarm Flood에서 Critical 알람을 숨기는 건 최신순 정렬이다에 정리했다.
Bad quality가 순간적으로 쏟아질 때 widget이 반복 reload하지 않는지.

제일 빠른 진단은 이거다. trend를 화면에서 빼고 다시 열어본다. 그래도 느리면 그래픽 문제일 수 있고, 빨라지면 그래픽은 무죄다.

화면 스크립트는 계측 없는 애플리케이션이다

스크립트는 편해서 화면을 슬금슬금 작은 프로그램으로 만든다. 문제는 그 프로그램에 로그도 profiler도 없다는 것이다. 매 scan, 매 value change, 매 mouse move마다 도는 것부터 의심한다.

매초 전 장치를 loop 돌며 count를 세는 스크립트. Derived tag 하나면 될 일.
색상 expression 하나가 태그 여러 개를 읽는 구조.
화면이 보이기도 전에 database를 조회하는 navigation script.
Faceplate 열 때 child popup과 trend object를 한꺼번에 생성하는 코드.
실패한 호출을 backoff 없이 계속 재시도하는 코드. 통신이 끊긴 동안 부하가 오히려 올라간다.
PLC나 server에 이미 있는 계산을 client가 다시 하는 코드.

공통 계산은 server side나 derived tag로 내린다. 화면 스크립트는 짧고 예측 가능해야 하고, 다음 사람이 찾을 수 있는 곳에 문서화돼 있어야 한다.

화면이 빨라도 PLC가 아프면 실패다

Driver마다 성격이 다르다. 연속 주소를 하나의 request로 묶는 driver가 있고, 태그 주소가 흩어져 있으면 작은 request를 잔뜩 만드는 driver가 있다. 화면 설계가 이 차이를 그대로 통신 부하로 번역한다.

무거운 화면을 열기 전후로 다음을 비교한다.

PLC 통신 부하와 CPU.
Driver 진단의 request rate, failed read, queue depth, timeout count.
Modbus register나 PLC array가 연속이면 실제로 묶여서 읽히는지.
큰 structure를 통째로 browse하지 않고 필요한 member만 읽는지.
Ethernet에서 serial이나 vendor network로 넘어가는 gateway. 여기가 거의 항상 제일 먼저 막힌다.
화면 navigation 때문에 command나 안전 관련 태그 응답이 늦어지지 않는지. 이건 성능 문제가 아니라 안전 문제로 취급한다.

Simulator에서 멀쩡하던 화면이 오래된 PLC, 무선 link, serial gateway 뒤에서는 못 쓸 수 있다. 인수 시험은 실제 경로에서 해야 한다.

인수 전에 숫자를 박아둔다

"느리다", "괜찮다"로 sign-off하면 1년 뒤에 같은 싸움을 한다. HMI 표준 문서에 화면 종류별로 몇 줄만 정해두면 된다.

대략적인 live tag 수 상한.
기본 scan rate.
기본으로 열리는 trend pen 최대 개수와 기본 조회 범위.
Script 실행 규칙.
기대 first-load 시간과 update 시간.

우리가 쓰는 기준은 Level 1 overview 2초, 운전용 faceplate 1초, diagnostic page는 제한 없음이다. 숫자 자체보다 숫자가 문서에 있다는 사실이 중요하다. overview 하나가 슬금슬금 숨은 diagnostic workbook으로 자라날 때 거절할 근거가 생긴다.

모든 화면을 가볍게 만들자는 얘기가 아니다. 공장이 흔들릴 때 운전자가 보는 화면만 빠르면 된다. 다음에 확인할 것 하나만 고르라면, 지금 운영 중인 시스템에서 최소화된 창과 숨은 tab이 몇 개나 subscribe를 유지하고 있는지 세어보는 것이다.