PLC 재시작 후 HMI 명령 리셋 동작 설계

재시작 동작도 명령 설계에 포함된다

HMI 명령은 순간 버튼으로 만드는 경우가 많다. 운전자가 Start를 누르면 HMI가 bit를 쓰고, PLC가 그 bit를 보고, 다시 bit를 내린다. 평상시에는 단순해 보인다. 문제는 그 중간에 PLC, 통신 driver, HMI client가 재시작될 때 생긴다.

오래된 명령이 재접속 뒤 다시 써질 수 있다. Controller tag 안에 command bit가 true로 남을 수 있다. HMI 버튼은 이미 놓인 것처럼 보이는데 PLC에는 요청이 latch되어 있을 수 있다. Gateway가 session 복구 후 마지막 write를 다시 보낼 수도 있다.

그래서 command reset 동작은 driver 기본값에 맡기지 말고 별도로 설계하고 시험해야 한다.

요청, 접수, 결과를 나눈다

중요한 동작을 command bit 하나로만 만들면 장애 분석이 어렵다. 최소한 작은 handshake 구조를 두는 편이 좋다.

Sequence 값은 재시작 뒤 특히 중요하다. PLC가 이미 command 1482를 처리했다면, HMI가 재접속하면서 같은 값을 다시 썼다고 해서 1482를 다시 실행하면 안 된다.

명령을 retained 상태로 남기지 않는다

Command는 보통 edge 또는 transaction으로 처리한다. 오래 보존되는 desired state로 남기면 위험하다. Recipe 선택이나 운전 mode 목표처럼 PLC가 계속 검증하는 값은 retained state가 맞을 수 있다. 하지만 Pump start, Valve open, Fault reset, Alarm acknowledge 같은 일회성 동작은 다르다.

다음 위치에 명령이 의도치 않게 남지 않는지 확인한다.

• HMI tag database가 client restart 후 적용하는 default value.
• SCADA driver의 write cache 또는 store-and-forward 기능.
• OPC UA, MQTT gateway의 retained command topic.
• PLC retentive memory 영역에 잡힌 command bit.
• 화면 이동 후에도 살아 있는 script variable.
• 이중화 SCADA server 사이에 동기화된 pending write.

명령이 재시작을 넘어 살아남아야 한다면 요구사항으로 명확히 써야 한다. 그리고 화면에 pending 상태로 보여줘야 한다. 우연히 살아남는 명령이 가장 위험하다.

HMI가 아니라 controller가 요청을 소비한다

Command request의 최종 clear 또는 consume은 controller가 맡는 편이 안전하다. HMI는 버튼 표시를 놓을 수 있지만, PLC가 명령을 기록한 뒤 요청을 소비해야 한다.

현장에서 쓰기 좋은 흐름은 다음과 같다.

1. HMI가 request bit와 sequence number를 쓴다.
2. PLC가 새로운 sequence number인지 확인한다.
3. PLC가 mode, permissive, interlock, 가능한 경우 사용자 권한을 검사한다.
4. PLC가 accepted 또는 rejected 결과를 내부에 남긴다.
5. PLC가 요청을 clear하거나, 다음 sequence가 올 때까지 같은 요청을 무시한다.
6. HMI가 결과를 보여주고 transaction을 audit에 남긴다.

이렇게 하면 HMI가 bit를 너무 빨리 내려서 PLC scan이 못 보는 문제를 줄일 수 있다. 반대로 통신이 잠깐 멈춘 뒤 PLC가 같은 true bit를 매 scan마다 새 명령으로 보는 문제도 막을 수 있다.

Startup masking 기준을 분명히 둔다

PLC가 재시작된 직후에는 상태가 잠시 불확실하다. Drive 통신이 아직 안 붙었을 수 있다. Remote I/O가 reconnect 중일 수 있다. Interlock 값이 최신이 아닐 수 있다. HMI가 online이라는 이유만으로 command를 열면 안 된다.

Command enable 전에 확인할 startup gate는 다음과 같다.

• Controller first scan 완료.
• Remote I/O 정상.
• Safety와 permissive 데이터 유효.
• Device feedback이 stale이 아니라 최신.
• Mode source가 local, remote, auto 중 무엇인지 확인됨.
• Command queue가 비었거나 reconcile 완료.
• Audit에 시간이 필요하면 time sync 유효.

Startup masking은 화면에 보여야 한다. PLC가 I/O 초기화 중이라 pump start가 막힌다면, 버튼 옆에 그 이유가 보여야 한다. 이유 없는 비활성 버튼은 현장 bypass와 전화 문의를 만든다.

Transaction 중간에서 재시작 시험을 한다

재시작 시험은 idle 상태에서만 하면 부족하다. 일부러 불편한 순간을 골라야 한다.

안전한 simulation이나 통제된 시운전 시간에 다음 경우를 시험한다.

1. Command를 누른 뒤 PLC가 접수하기 전에 HMI client를 재시작한다.
2. Command를 누른 뒤 PLC가 request를 clear하기 전에 PLC를 재시작한다.
3. Command 직후 HMI와 controller 사이 네트워크를 끊는다.
4. Confirmation popup이 열린 상태에서 SCADA server를 재시작한다.
5. Write buffer가 있는 gateway를 재시작한다.
6. Pending command 중 이중화 SCADA server를 failover한다.
7. Command tag가 true인 retentive memory 상태로 PLC를 power up한다.

각 경우에서 실제 동작이 0번 실행됐는지, 1번 실행됐는지, 2번 이상 실행됐는지 기록한다. 공정에 따라 정답은 다를 수 있다. 중요한 것은 동작을 알고 있어야 한다는 점이다.

버튼 상태와 command 상태를 구분한다

운전자는 버튼을 본다. PLC는 tag와 scan 변화를 본다. 둘은 같은 것이 아니다.

현장에서 자주 보는 나쁜 증상은 다음과 같다.

• 버튼은 원위치로 돌아왔는데 request bit는 true로 남아 있다.
• PLC는 아직 command pending인데 confirmation popup이 닫힌다.
• PLC가 reject했는데 HMI에는 timeout만 뜬다.
• 이전 명령이 실행 중인데 HMI가 같은 명령을 다시 enable한다.
• 화면을 이동하면서 script 상태가 사라져 운전자가 결과를 못 본다.

버튼 근처에는 command 상태를 같이 보여주는 편이 좋다. Pending, Accepted, Rejected - auto mode required, Executing, Done, Timed out waiting for open feedback처럼 구체적으로 보여주면 반복 클릭이 줄어든다.

Audit은 클릭이 아니라 transaction을 기록한다

Command audit은 마우스 클릭 한 줄로 끝나면 안 된다. 실제 transaction을 설명할 수 있어야 한다.

남기면 좋은 항목은 다음과 같다.

• 운전자와 조작 station.
• Command 이름과 대상 설비.
• 요청한 동작 또는 값.
• Command sequence number.
• Request time, accepted time, final result time.
• PLC result code 또는 rejection reason.
• Transaction 중 controller restart나 통신 끊김 여부.
• 최종 feedback 상태.

나중에 "운전자가 start를 두 번 누른 것인가, 시스템이 replay한 것인가"를 따질 때 sequence와 result가 없으면 audit trail이 답을 못 한다.

자주 생기는 실패 형태

시운전 확인 목록

중요 HMI command마다 다음 항목을 확인한다.

• Request를 clear 또는 consume하는 주체가 정해져 있다.
• PLC, HMI, server, gateway 재시작 후 오래된 요청이 실행되지 않는다.
• Startup 데이터가 유효하지 않으면 PLC가 command를 reject한다.
• HMI는 command가 막히거나 reject된 구체적 이유를 보여준다.
• Sequence number 또는 동등한 방식으로 중복 요청을 구분한다.
• Audit 기록에 request, acceptance, result, transaction 중 restart 여부가 남는다.
• Restart와 failover 시험을 command sequence의 여러 지점에서 수행했다.

모든 버튼을 복잡하게 만들자는 뜻은 아니다. 첫 실제 비정상 정지 전에 재시작 동작을 예측 가능하게 만드는 것이 목적이다.