죽은 유량계에서 6주 동안 나온 아주 좋은 데이터
FT-110 전자유량계의 coil driver가 화요일 밤에 고장 났다. 계장 담당자는 상식적인 임시 조치를 했다. Faceplate를 열고 manual value에 35.0 m³/h를 입력한 뒤, 목요일에 transmitter를 교체하겠다고 반장에게 말했다. 목요일에 그 사람은 다른 현장에 있었다.
대체값은 6주를 버텼다. 아무도 못 잡은 이유는 이상하게 동작해서가 아니라 너무 멀쩡하게 동작해서였다. Trend는 평평했고, 일일 적산값은 소수점 셋째 자리까지 재현됐고, 고유량 alarm은 한 번도 울리지 않았다. 월간 물질수지가 4% 정도 모자라게 나오고 누군가 원본 trend를 열어서 자로 잰 듯한 직선을 보고 나서야 드러났다.
누가 넣었는지 추적하는 데 거의 하루가 걸렸다. Faceplate는 tag write만 남기고 mode 변경은 남기지 않았고, 그 station은 공용 OPER1 계정으로 로그인돼 있었고, historian은 그 manual value를 앞의 실제 계측값과 똑같은 Good quality로 저장했다. 이 과정에 극적인 고장은 하나도 없다. 아무도 내리지 않은 설계 결정이 다섯 개 있었을 뿐이다.
Manual은 최소 다섯 가지 상태다
가장 흔한 근본 원인은 Manual flag 하나가 모든 일을 하는 것이다. 운전자는 그 표시만 보고 장비를 사람이 직접 움직이는 중인지, 화면의 숫자가 사람이 넣은 값인지, interlock을 우회한 상태인지 구분할 수 없다. 이 셋은 위험도도 복구 절차도 완전히 다르다.
| Override 종류 | 화면에 나와야 할 문구 | 별도 상태로 둬야 하는 이유 |
|---|---|---|
| Command override | V-204 — HMI manual command | Sequence가 actuator 소유권을 잃은 상태다. |
| Value substitution | FT-110 — manual value 35.0 m³/h | Trend, 적산, 계산값이 더 이상 현장 데이터가 아니다. |
| Interlock bypass | P-201 — low pressure permissive bypassed | 위험이 가장 크다. 시간 제한과 공장 전체 표시가 필요하다. |
| Simulation | M-330 feedback simulated (시운전) | 생산 상태와 절대 헷갈리면 안 된다. |
| Data correction | Downtime 사유 수정 — supervisor | MES와 report는 덮어쓰기가 아니라 변경 전/후가 필요하다. |
이 중 value substitution이 가장 멀리 간다. HMI를 벗어나기 때문이다. Historian에 최종 숫자만 들어가면 그 숫자는 영원히 실제 계측값과 구분되지 않는다. OPC는 두 세대 모두 이걸 표시할 자리를 주는데 대부분의 연동이 무시한다. OPC Classic DA에는 Good — Local Override quality(sub-status 0xD8)가 있고 정의 자체가 "사람이 입력한 값이 강제로 들어간 상태"다. OPC UA에는 Good_LocalOverride status code가 있다. NAMUR NE 107은 기기 쪽에서 Function check 범주로 같은 것을 표현한다. 셋 중 하나를 쓰고, historian이 quality byte를 그냥 Good으로 뭉개지 않고 실제로 저장하는지 확인하고, trend client가 그 구간을 다르게 그리게 한다. 점선이나 빗금 구간 하나면 FT-110은 하루 만에 잡혔을 것이다.
Faceplate에 반드시 보여야 하는 것
Override 표시는 영향을 받는 object 바로 옆에 있어야 한다. Diagnostic page 안쪽에만 있으면 없는 것과 같다. 생산 중에는 아무도 그 화면을 열지 않고, 문제가 되는 시점이 바로 생산 중이다.
장비 faceplate에는 현재 control owner(auto sequence / local panel / HMI manual / maintenance / simulation), 입력된 사유, enable한 사용자와 role, 시작 시각과 경과 시간, 시간 제한이 있으면 만료 시각, 그리고 auto로 돌려주기 전에 만족해야 할 조건이 나와야 한다.
색만으로 상태를 표현하면 안 된다. ANSI/ISA-101.01은 이 부분을 분명하게 다룬다. 색은 보조 단서지 주 단서가 아니다. 남성의 약 8%는 색각 이상이 있다. 작은 amber outline은 "뭔가 조금 다르다"로 읽히고, state 항목의 MANUAL이라는 글자는 manual로 읽힌다. 경과 시간도 생각보다 중요하다. "manual 상태"는 그냥 정보지만 "manual 41시간"은 작업 지시다.
권한, 그리고 대상을 명시하는 확인 문구
모든 override에 같은 dialog를 띄우지 말고 결과의 크기에 권한을 맞춘다.
Conveyor manual jog는 일반 operator 권한으로 충분하다. Interlock bypass는 상위 role, 사유 입력, 명시적 duration을 요구해야 한다. Safety instrumented function의 bypass는 일반 HMI logic에 두면 안 된다. IEC 61511-1은 SIF bypass를 문서화된 운전 절차 아래에 두고, bypass 상태를 표시하고, 시간을 제한하도록 요구한다. 실무적으로는 safety system이 그 기능을 소유하고 HMI는 상태만 표시한다는 뜻이다. Value substitution은 사유를 요구하고 확인창에 engineering unit이 붙은 입력값을 그대로 보여줘야 한다. 엉뚱한 칸에 들어간 숫자는 어떤 권한 모델로도 못 잡는 오류다.
확인창 문구도 제대로 써야 한다. Are you sure?는 사람들에게 Yes를 누르는 습관만 가르친다. Pump P-201의 low pressure permissive를 30분간 bypass합니까?는 반대할 근거를 준다. 대상, 동작, 시간이 한 문장에 다 있어야 한다.
자주 빠지는 두 가지가 더 있다. 의미가 없는 mode에서는 클릭을 받아 놓고 조용히 write를 거부하지 말고 버튼 자체를 disable한다. 그리고 local panel이 ownership을 가진 상태에서는 remote override를 막는다. 제어권이 있다고 착각하는 운전자가 없다는 걸 아는 운전자보다 훨씬 위험하다.
Audit 기록, 그리고 다들 빼먹는 절반
Audit trail의 판단 기준은 하나다. PLC program을 열지 않고 사건 순서를 복원할 수 있는가. 그러려면 동기화된 시계 기준 timestamp, 사용자와 role과 workstation, object name과 tag path, override 종류, 이전 상태와 새 상태, 단위가 붙은 manual value, 사유, expiry, 그리고 결과(accepted / rejected / write failed / 자동 만료)가 필요하다.
IEC 62443-3-3은 이걸 요구사항으로 못 박는다. SR 2.8은 접근 제어와 설정 변경을 포함한 auditable event를, SR 2.11은 공통 시각원에 추적 가능한 timestamp를 요구한다. 공용 OPER1 로그인이 단순히 지저분한 관리가 아니라 실제 지적 사항인 이유가 여기 있다. 사람을 특정할 수 없는 audit 기록은 둘 다 만족하지 못한다.
빼먹는 절반은 disable event다. Enable만 남기는 현장이 많고, 그러면 운전자가 해제한 것인지, timeout으로 만료된 것인지, mode change로 풀린 것인지, controller restart 때 날아간 것인지 구분이 안 된다. 이 넷은 override 기능이 제대로 동작하는지에 대해 전혀 다른 이야기를 한다. 해제는 원인과 함께 남긴다.
이유보다 오래 사는 Override
Override 사고는 대부분 조용하다. 인수인계에 안 들어간 야간조 대체값, 정비 창이 닫힌 뒤에도 남아 있는 bypass, 생산으로 돌아왔는데 여전히 true인 simulation bit 같은 것들이다.
잡아낼 만한 조건은 이렇다. 설정 duration보다 오래 active, 생산 mode인데 active, 열린 work order 없이 active, controller restart 이후에도 active, 설정한 운전자가 logout한 뒤에도 active, 상하류 설비는 전부 auto인데 한 대만 manual.
Alarm 쪽은 이 문제를 이미 오래전에 풀었고 패턴을 그대로 가져오면 된다. ANSI/ISA-18.2의 shelving은 명시적으로 시간이 제한된 상태이고, 만료 시 자동 해제되며, 현재 shelve된 목록을 주기적으로 검토하도록 요구한다. Override도 똑같이 한다. 무제한이 아니라 기본 expiry를 두고, "지금 override 걸린 것" 목록을 반장이 교대마다 보게 만든다. 자동 만료 기능이 없는 시스템이라면 24시간 넘게 active인 항목의 일일 report가 부족하나마 아무것도 없는 것보다는 낫다.
Auto 복귀가 더 위험한 쪽이다
Override 해제는 제어권 이양이고, 제어권 이양 중에 장비가 움직인다. 사람이 다치는 지점이 여기다.
Command override라면 auto 복귀 후 sequence가 어느 step에서 시작하는지, actuator가 지금 어디 있는지, permissive와 interlock이 정상인지, override 이전의 pending command가 큐에 남아 있는지, feedback timeout timer가 제대로 reset되는지를 미리 알아야 한다. 나쁜 경우는 잘 알려져 있다. Sequence가 override 이전 상태를 그대로 들고 있다가 소유권을 되찾자마자 actuator 위치가 틀렸다고 판단하고 즉시 움직인다.
Value substitution이라면 실제 계측기가 다시 Good인지, 그 값을 쓰던 계산 tag에서 대체값이 빠졌는지, historian에 manual 구간의 quality나 annotation이 남는지, 그 입력이 manual이라서 suppress됐던 alarm이 다시 살아났는지를 확인한다. 마지막 항목이 자주 문제가 된다. Value override 때문에 suppress된 alarm은 해당 alarm의 hold logic이 다시 평가될 때까지 그대로 눌려 있는 경우가 많고, 그 평가 시점이 override 해제와 같지 않다.
"Auto는 step 40에서 재개, V-204는 close 예정" 같은 복귀 경로를 faceplate에 띄우는 데는 화면 작업 반나절이면 되고, 놀랄 일 한 종류가 통째로 사라진다.
증상별로 먼저 볼 곳
| 보이는 증상 | 먼저 볼 것 |
|---|---|
| 장비가 auto sequence를 따라가지 않음 | Command override 잔류, local/remote ownership 불일치, manual mode 잔류 |
| Trend가 평평하고 수상하게 깔끔함 | Value substitution, simulation mode, bad quality를 숨기는 계산식 |
| 시험 중 alarm이 발생하지 않음 | Alarm 입력 override, bypass active, 표시 없는 suppression |
| Restart 후 override가 사라짐 | 상태가 HMI memory에만 있고 controller나 persistent store에 없음 |
| 누가 바꿨는지 알 수 없음 | User 항목 누락, 공용 로그인, 시계 동기화 불량 |
| Override를 끄는 순간 장비가 움직임 | Sequence에 pending command나 이전 step 상태가 남음 |
대부분을 잡아내는 시험 하나
인수인계 시점에 override 종류별로 적어 둔다. Enable 가능한 role, 사유 입력 필수 여부, 최대 duration, faceplate와 overview와 report에 나타나는 표시, 이력을 저장하는 table 또는 event stream, historian quality 표시 방식.
그리고 거의 아무도 안 하는 시험을 한 번 한다. Override를 걸어 놓고 SCADA 서버를 재기동한 뒤 다시 로그인한다. Override가 사라졌다면 그건 HMI memory에만 있었다는 뜻이고, 서버가 재기동될 때마다 audit trail에 구멍이 생긴다. Override는 남아 있는데 표시가 사라졌다면 더 나쁘다. 화면에는 아무 언급도 없는 bypass를 걸어 놓고 공장이 돌아가고 있다는 뜻이다.