SCADA Things
← 전체 글
언어English한국어
HMI/약 15분 읽기/— 조회

화면은 받았는데 PLC는 안 받은 Setpoint

HMI setpoint 입력이 깨지는 지점은 입력이 아니라 응답 경로다. 표시 범위와 PLC hard limit을 나누는 방법, 조용한 반올림과 무시된 write를 잡아내는 시운전 시험 10가지.

HMISCADA태그알람프로젝트 노트

문제는 들어가는 길이 아니라 돌아오는 길이다

운전자가 Dryer Zone 2를 62.0 °C에서 68.5 °C로 올렸다. Popup은 값을 받고 닫혔고, 화면에는 68.5가 남았다. 그때 그 loop는 recipe ownership 상태였고, PLC는 HMI write를 그냥 버렸다. 한 shift 분량 제품의 수분값을 QC가 걸고 나서야 알았다.

이 과정에 버그는 없다. HMI는 범위 검사를 제대로 했고, PLC는 자기를 제대로 보호했다. 빠진 건 돌아오는 길이다. 화면이 controller가 실제로 받아들인 값을 다시 읽어오지 않았다.

현장에서 부르는 setpoint 문제는 대부분 이 모양이다. 프로젝트는 입력 경로에 힘을 쏟는다. Min/max 필드, 소수점 mask, 확인 popup. 그리고 응답 경로는 "tag에 쓰고 창 닫기"로 끝난다. Setpoint를 결과 코드가 있는 transaction으로 설계하면 이 실패의 절반은 아예 생기지 않는다.

Min/Max 한 쌍이 너무 많은 일을 하고 있다

Tag마다 Min/Max 한 쌍만 두고 trend 축, bar graph, 입력 검사, 심지어 alarm limit까지 같이 쓰는 경우가 흔하다. 누군가 기동 과도 구간을 보려고 trend 축을 넓히는 순간, 운전자가 입력할 수 있는 범위도 같이 넓어진다.

목적별로 나눈다.

제한 종류예쓰는 곳
화면 표시 범위0~100 %Bar graph, gauge, trend 기본 축
운전자 입력 범위20~80 %HMI 입력 검사
PLC hard limit10~90 %최종 clamp 또는 reject logic
Alarm thresholdHigh 85 %Alarm logic
설비 안전 범위공정·장비 설계 기준시운전 검토, 변경 관리

운전자 입력 범위는 PLC hard limit과 같게 두지 말고 더 좁게 잡는다. 그 사이 간격이 있어야 정비나 시운전에서 정상 운전 범위를 건드리지 않고도 넓게 쓸 수 있고, 범위를 벗어난 입력이 controller에서 조용히 clamp되는 대신 HMI에서 명확한 메시지로 막힌다.

값을 어디에 두느냐도 값 자체만큼 중요하다. Faceplate에 20, 80을 hard-coding하면 다음 logic 수정 뒤 HMI와 PLC가 어긋나는 건 시간 문제다. 입력 제한은 controller tag에서 읽고 popup이 열릴 때 가져오게 한다. Popup마다 read 몇 개가 더 붙지만, drift 계열 문제 한 묶음이 사라진다.

Popup이 운전자에게 줘야 하는 정보

빈 숫자칸과 OK 버튼만 있으면 운전자가 자기 입력을 대조할 기준이 없다. 최소한 설비명과 tag명(TIC_2042_SP가 아니라 Dryer Zone 2 Temperature SP), 현재 PV, 현재 setpoint, engineering unit, 소수점 자리수, 운전자 입력 범위는 보여야 한다. 그 loop를 다른 쪽이 소유할 수 있는 구조라면 지금 누가 소유 중인지도 표시한다. 앞의 dryer 사례는 이 한 줄로 걸렸을 것이다.

단위는 따로 다룰 만하다. 화면에서 가장 위험한 숫자는 75다. °C로도 °F로도 말이 되고, Hz로도 rpm으로도 말이 되고, 퍼센트로도 말이 된다. 단위는 헤더에만 두지 말고 현재값과 입력값 양쪽에 붙인다. ISA-101.01이 faceplate 간 단위·정밀도 일관성을 강조하는 이유가 여기 있다. 운전자는 숫자를 패턴으로 읽고 라벨은 건너뛴다.

OK를 누르면 즉시 적용인지, 나중에 다운로드되는 stage인지도 화면에 써 둔다. 즉시 적용이라고 생각하는 운전자는 stage 필드에서 OK를 계속 누른다.

두 번 검사하고, 제대로 검사한다

HMI 검사는 사용성이고 controller 검사는 보호다. 서로 대체하지 못한다. HMI만 write하는 구조가 아니기 때문이다. OPC UA client, historian 쪽 script, 엔지니어링 tool, recipe download가 모두 같은 tag를 건드린다.

HMI는 write 전에 막는다. 빈 값이나 숫자가 아닌 입력, 계측 분해능보다 많은 소수점, 운전자 입력 범위를 벗어난 값, 설비 mode가 맞지 않는 write, 권한 없는 사용자의 write. 마지막 항목은 IEC 62443-3-3 SR 2.1에서 authorization enforcement 요구사항으로 다룬다. UI 편의 기능이 아니다. SR 1.1까지 보면 그 뒤의 identity가 실제 사용자여야 한다는 뜻이고, 모니터에 붙여 둔 공용 operator 계정은 여기에 해당하지 않는다.

Controller는 hard min/max, permissive, popup이 열려 있는 동안 바뀌었을 수 있는 interlock, rate-of-change 제한, ownership을 다시 본다. 여기서 타이밍 문제를 짚고 넘어갈 필요가 있다. 90초 동안 열려 있던 popup은 그 시점의 snapshot으로 동작한다. 창이 그려질 때 참이던 interlock 상태가 OK를 누르는 순간에도 참이라는 보장은 없다.

조용한 쪽은 data type이다. IEC 61131-3에는 REAL, INT, DINT가 있고, HMI는 자기가 어느 쪽과 통신하는지 항상 알지는 못한다. INT tag에 68.5를 쓰면 driver 반올림 방식에 따라 68이나 69가 되고, 어디에도 오류는 남지 않는다. Scaled integer를 쓰는 Modbus holding register도 같다. 68.5는 register에 685로 들어가야 하는데, 배율이 10배 틀린 driver는 그 write를 그대로 받아준다. 중요 setpoint tag는 faceplate에서 짐작한 type이 아니라 실제 data type을 FAT에서 확인한다.

범위 안이어도 공정에 무리가 가는 값

40 °C에서 90 °C로 가는 변경은 제한 범위 안이면서도 heater element를 상하게 하거나 batch를 버리게 만들 수 있다. 자주 쓰는 순서대로 네 가지다.

  1. Controller ramp. 목표값은 받고 working setpoint를 정해진 속도로 옮긴다. 온도·압력 loop의 기본값으로 가장 낫다. 운전자는 요청한 값을 얻고, 공정은 천천히 받는다.
  2. 큰 변경 거부. 차이가 설정 delta를 넘으면 막는다. 단순하지만 큰 변경이 정상인 기동 구간에서 운전자를 괴롭히므로 mode 예외와 같이 쓴다.
  3. 상위 권한 확인. 큰 변경은 supervisor 권한이나 maintenance mode에서만 허용한다. 큰 변경이 드물고 항상 의도적인 설비에 맞는다.
  4. Stage 후 apply. 관련 값 여러 개를 넣고 검토한 뒤 한 번에 내린다. Setpoint끼리 물려 있을 때 필요하다. Zone 3 없이 zone 2만 바꾸는 건 둘 다 안 바꾸는 것보다 나쁘다.

Batch 설비에서는 지금 어느 계층을 고치는지 분명히 해야 한다. IEC 61512 / ISA-88이 master recipe, control recipe, 진행 중인 batch를 나눠 둔 이유가 있다. 이걸 뭉뚱그린 HMI는 가장 나쁜 형태의 사고를 만든다. 맞는 값을 틀린 대상에 적용해 놓고 세 batch 뒤에 발견하는 것이다.

확인창에는 위험이 보이게 쓴다

Apply new setpoint?는 아무것도 막지 못한다. 운전자에게 Yes를 누르는 습관만 만든다. 대상, 방향, 변경 폭을 쓴다.

Dryer Zone 2 Temperature SP를 62.0 °C에서 68.5 °C로 변경합니까?

변경 폭이 클 때는 한 단계 더:

Dryer Zone 2 Temperature SP가 +18.0 °C 변경됩니다. Ramp target으로 적용합니까?

한 값이 여러 계산에 영향을 주면 그것도 창에 쓴다. Gap 계산, reject timing, downstream rate까지 같이 바꾸는 conveyor speed setpoint라면 화면에서 그 사실을 밝혀야 한다.

6개월 뒤에도 읽히는 Audit Event

Setpoint changed는 audit event가 아니다. 운전자가 넣은 값인지, recipe가 내린 값인지, controller가 clamp한 값인지 아무것도 말해주지 않는다.

쓸모 있는 기록에는 동기화된 system time 기준 timestamp, user·role·workstation, 화면 object명과 내부 tag path, 이전 값과 요청 값 그리고 단위, 결과(accepted, rejected, clamped, staged), 거부 사유, source(HMI screen, recipe download, engineering tool, remote client), 그리고 가능하면 batch·lot·order context가 들어간다.

빠뜨리기 쉬우면서 가장 아쉬운 항목이 결과 필드다. IEC 62443-3-3 SR 2.8은 접근 제어와 제어 기능 사용에 대한 auditable event를 요구하고, 규제 대상 공장이라면 21 CFR Part 11이 이전 값과 새 값을 함께 요구하며 더 강하게 밀어붙인다. 요청만 남기고 결과를 빼면 둘 다 만족하지 못한다. 앞의 dryer 조사가 일주일짜리 일이 되는 지점이 정확히 여기다.

FAT에서 실제로 터지는 것들

  • HMI는 소수점 한 자리를 받는데 PLC tag는 INT라서 조용히 반올림된다.
  • 화면은 rpm인데 controller는 Hz나 percent를 기대한다.
  • Min/max가 HMI에 hard-coding된 채로 두 revision 전 PLC 상수에서 멀어져 있다.
  • Manual mode에서는 입력이 되는데 auto mode에서 PLC가 무시하고, 화면에는 피드백이 없다.
  • Recipe download가 수동 setpoint를 event 없이 덮어쓴다.
  • 거부된 write인데 popup에 요청값이 남아, 공정이 가져본 적 없는 숫자가 화면에 보인다.
  • Redundant HMI 두 대가 부분 update 뒤 서로 다른 limit cache를 들고 있다.
  • Alarm limit는 개정했는데 입력 limit는 그대로다.

어느 것도 한 컴포넌트 안에 있지 않다. HMI, PLC, historian, recipe 관리 사이의 interface contract 문제다. 그래서 각자 단위 시험은 다 통과하고, 시운전 사흘째에 나온다.

중요 setpoint class마다 해볼 시험 10가지

  1. 허용 최소값 입력, 정상 적용 확인.
  2. 허용 최대값 입력, 정상 적용 확인.
  3. 최소값보다 한 step 낮게 입력, 거부 메시지가 명확한지 확인.
  4. 최대값보다 한 step 높게 입력, 거부 메시지가 명확한지 확인.
  5. 소수점을 넘치게 입력, 반올림인지 거부인지 그리고 화면이 어느 쪽인지 알려주는지 확인.
  6. 권한이 낮은 사용자로 write 시도.
  7. 설비 mode가 맞지 않을 때 write 시도.
  8. Controller 쪽 reject를 강제로 만들고 HMI message 확인. OPC UA client라면 일반적인 write 실패가 아니라 반환된 status, 예를 들어 Bad_OutOfRange가 화면에 드러나야 한다.
  9. Historian에 이전 값과 새 값이 모두 남는지 확인.
  10. Audit event에 user, station, tag, value, unit, result가 들어가는지 확인.

시험 중에는 process value, working setpoint, target setpoint, output을 같이 trend로 띄워 둔다. 값이 즉시 적용됐는지, ramp됐는지, clamp됐는지, 무시됐는지는 trend에 바로 보인다. Popup은 구조상 그걸 보여주지 않는다.

Redundant 구성에서 HMI를 update한 뒤에는 한 가지를 더 본다. 두 station에서 같은 faceplate를 열고 표시되는 입력 제한을 비교하는 것이다. Cache된 limit table은 위 시험을 다 통과하고도 살아남는 실패다. 각 station이 저마다는 통과하기 때문이다.