품질 담당자가 배치 B-2026-0617-04 보고서를 열었는데 건조기 출구 온도 평균이 41 °C로 나온다. 90분짜리 cycle 치고는 말이 안 되는 값이다. 건조기는 멀쩡했다. 앞 배치의 frame이 닫히지 않았고, 새 시작 트리거는 그와 무관하게 두 번째 frame을 열었고, 쿼리는 정지 상태 14시간을 90분짜리 답에 같이 넣어버렸다.
흔한 실패 방식이다. frame을 저장하는 것 자체는 어렵지 않다. 어느 히스토리언이나 한다. 언제 시작하고 언제 끝내는지가 일의 전부이고, 프로젝트가 무너지는 지점은 대부분 종료 트리거다.
시간 범위로는 답이 안 되는 질문들
사람들은 히스토리언에 "13:40부터 15:10까지"를 묻지 않는다. 이렇게 묻는다.
- 이번 CIP 단계의 압력 프로파일은 어땠나?
- 지난주에 길게 돈 프레스 cycle은 어느 것이고, 전부 같은 금형이었나?
- 이 lot은 레시피 변경 전인가 후인가?
- 충전기 속도 저하와 겹친 downtime은 무엇인가?
event frame(PI AF 용어), batch segment, 제품마다 이름은 달라도 같은 객체가 이 질문에 답한다. 원시 시계열 위에 이름과 경계와 속성을 가진 구간을 얹기 때문이다. 이게 없으면 사용자는 트렌드를 내보내 손으로 세로선을 긋는다. 한 번은 된다. 매주 하는 품질 검토로는 못 버틴다.
경계는 상태에서 잡는다, 아날로그 임계값이 아니라
장비에 이미 상태 기계가 있으면 그걸 쓴다. 배치 설비라면 ISA-88(IEC 61512-1)이 골격을 그냥 준다. procedure, unit procedure, operation, phase 구조가 있고 phase 상태가 RUNNING, COMPLETE, ABORTED, HELD로 넘어가는 시점이 바로 원하는 경계 이벤트다. 개별 가공 설비라면 CycleActive 비트와 cycle 카운터 조합이 같은 역할을 한다.
내가 피하는 방식은 "출구 온도 80 °C 이상", "모터 전류 10 A 이상" 같은 아날로그 교차로 frame을 시작하는 것이다. 화면에서는 멀쩡해 보이지만 warm-up, jog, 일요일 새벽 6시 보전 시험, 임계값 근처에서 떨리는 센서 앞에서 전부 무너진다. 굳이 아날로그로 잡아야 한다면 히스테리시스와 on-delay를 제대로 넣고(단순 비교가 아니라 2 °C, 30 s 같은 값) 튜닝할 각오를 한다.
같이 짚어둘 함정이 둘 더 있다.
start 명령이 아니라 running에서 시작한다. Start_PB나 MES lot start 메시지는 누군가 요청했다는 뜻이다. 실제로 돌기 시작했다는 뜻은 Running이 알려준다. 그 간격이 작은 펌프에서는 3초, 회전식 건조기에서는 4분이고, cycle time 분포가 깨끗하게 나오느냐 아니면 아무도 설명 못 하는 왼쪽 꼬리가 붙느냐를 가른다.
화면 이동이 아니라 공정 완료에서 끝낸다. HMI 화면 전환 이벤트로 frame을 닫아 놓은 현장을 본 적 있다. 개발자 입장에서 그 자리에 스크립트 훅이 있어서 편했던 것이다. 교대 중에 그 화면을 계속 띄워 둔 조가 나올 때까지는 잘 돌았다.
frame 종류마다 만들기 전에 다섯 가지를 문서로 남긴다. 무엇이 시작인지, 무엇이 종료인지, abort/hold/restart 때 어떻게 되는지, 중첩을 허용하는지, 어느 시계가 기준인지. 경계 규칙을 공정 엔지니어에게 두 문장으로 설명 못 하면 시운전을 넘기기에는 너무 약하다.
오래 버티는 건 이름이 아니라 속성이다
frame 이름은 사람이 보라고 있는 값이다. 뒷단은 전부 속성으로 조인한다.
최소한 이 정도는 캡처한다. batch/lot/work order id, 실제로 보고서를 뽑는 ISA-95(IEC 62264) 계층 수준의 equipment id, recipe id 와 recipe version, product code, shift 또는 crew, 완료 상태, MES transaction id가 있다면 그것도. 시작 시점의 주요 setpoint도 같이 넣는다.
여기서 중요한 말은 시작 시점이다. batch id 속성을 캡처된 값이 아니라 live 태그 참조로 걸어 두면 다음 lot이 다운로드되는 순간 frame 중간에 조용히 바뀐다. 두 frame이 같은 lot을 주장하는 걸 누가 발견하기 전까지는 아무도 모른다. 시작 트리거에서 캡처하고, 고정하고, 다시 읽지 않는다.
Batch B123 Line 2 같은 표시 이름에 기대는 것도 마찬가지다. 읽기는 좋은데 아무것과도 조인이 안 된다. LIMS, 알람 이력, CMMS는 전부 다른 키를 쓴다.
열린 frame에는 정리 스크립트가 아니라 정책이 필요하다
open frame은 어느 현장이든 결국 생긴다. 배치 중 PLC 재시작, 네트워크 단절, abort, MES 메시지 유실, 새벽 2시 스크립트 예외.
생산 투입 전에 정책을 정한다. 기본값은 "영원히 열어 둔다"이고, 그게 위의 건조기 평균 14시간을 만들어낸 바로 그 동작이기 때문이다.
- open frame을 엔지니어링 화면에 올려서 당일에 누가 보게 한다.
- 최대 지속 시간을 넘기면
timeout이나inferred상태를 명시해서 자동으로 닫는다. 최대값은 레시피 공칭이 아니라 실제 분포에서 잡는다. P95 배치가 3시간 10분이면 3시간 30분이 아니라 6시간에서 닫는다. - 권한 있는 사용자가 사유와 이름을 남기고 수동 종료할 수 있게 한다. GxP 현장이면 감사 이력 요건(21 CFR Part 11)이 여기에도 걸린다. 원래 시작 시간을 덮어쓰지 말고 보정 이력을 따로 남긴다.
- 같은 장비에서 새 frame이 닫히지 않은 frame을 조용히 가리지 못하게 막는다. 거부하든지, 이유가 남는 상태로 기존 frame을 닫든지 한다.
검증은 SQL이 아니라 트렌드 위에서
로직을 다 짠 다음 frame 경계를 태그 위에 겹쳐 놓고 눈으로 본다. 상태, 속도, 온도, 압력, 레시피, lot id. off-by-one 전이와 오래된 context는 눈에는 바로 보이고 행 개수로는 거의 안 보인다.
표본은 의도적으로 고른다. 정상 run 하나, abort 하나, hold 후 재개 하나, 아주 짧은 test cycle, 보전 jog, 중간에 PLC가 재시작된 run, 네트워크 단절 후 late data가 들어온 run, 구간 중 product 전환이 있었던 run. 마지막 것 하나가 나머지 일곱 개를 합친 것보다 속성 캡처 버그를 많이 잡는다.
시계 문제도 여기서만 드러난다. 경로 어딘가에서 local time을 저장하면 DST 전환이 태그 데이터와 경계를 어긋나게 하고, PLC 시계와 히스토리언 서버가 같은 NTP 소스에 물려 있지 않으면 드리프트가 쌓인다. 자기 데이터보다 40초 먼저 시작하는 frame은 로직 문제가 아니라 시계 문제다.
시운전 보고서
인수인계 전에 최근 며칠치로 아래를 돌리고 직접 읽는다.
| 점검 항목 | 걸렸을 때 보통 의미하는 것 |
|---|---|
| 아직 열린 frame | 종료 트리거 누락, 또는 처리 안 된 abort 경로 |
| 예상 최대보다 긴 frame | 같은 원인, 또는 안 풀리는 중첩 규칙 |
| 예상 최소보다 짧은 frame | 임계값 채터링, 또는 test cycle 유입 |
| batch/recipe/product 속성 누락 | 시작 시점에 null이던 태그에 속성을 걸어 둠 |
| 시작 시간이 종료 시간보다 늦음 | clock skew, 또는 late data 재정렬 |
| 허용 안 되는데 겹친 frame | 가려진 open frame |
| 수동 보정으로 생성된 frame | 가끔은 정상. 계속 늘면 트리거가 틀린 것 |
단순한 점검이지만 히스토리언이 신뢰를 얻느냐 마느냐가 여기서 갈린다. 첫날 frame 목록이 이상하면 작업자는 스크린샷과 엑셀로 돌아가고 다시 오지 않는다.
목적이 분명한 업무 하나부터 시작한다. 배치 검토든, cycle 비교든, downtime 분석이든. 거기서 경계와 속성 캡처를 제대로 맞춘다. 그다음에 frame 종류를 늘리는 건 싸게 먹힌다. 흔들리는 경계 위에 얹는 frame은 아무도 안 믿는 이력만 더 만든다.