"확인했다"에 서명하지 마라
인수 시험 기록에 통신 확인 — OK라고 적힌 줄을 본 적 있다. 그 줄 하나로 넘어간 현장에서 두 달 뒤에 나온 문제는 이랬다. Transmitter 한 대가 단선되어 3.5 mA를 내보내고 있었는데, SCADA는 그 값을 0%로 깔끔하게 보여 주고 있었다. 화면은 틀리지 않았다. 합격 기준이 틀렸다.
시운전 체크리스트가 쓸모를 갖는 조건은 하나다. 각 줄에 통과했는지 아닌지 다툴 수 없는 숫자가 붙어 있어야 한다. "스케일 확인"은 기준이 아니다. "0%, 50%, 100% 세 점에서 장비 표시값과 ±1% 이내"가 기준이다. 아래는 그 숫자들이 어디서 오는지다. 대부분은 이미 표준에 적혀 있어서 내가 정할 일도 아니다.
아날로그 입력: 고장 전류를 볼 수 있어야 통과
4–20 mA 쪽 기준은 NAMUR NE 43이 정해 놓았다. 4 mA가 0%, 20 mA가 100%, 유효 측정 구간은 3.8–20.5 mA다. 그 밖은 값이 아니라 고장 신호다. 하한 쪽 고장은 3.6 mA 이하, 상한 쪽 고장은 21.0 mA 이상이다.
그래서 시운전에서 봐야 하는 건 두 가지다.
- Transmitter가 고장 시 어느 쪽으로 가도록 설정됐는지. NE 43은 downscale과 upscale을 둘 다 허용한다. 현장에서 섞여 있으면 운전원이 "0%"를 보고 판단을 못 한다.
- SCADA 쪽 변환이 3.6 mA를 0%로 clamp 하는지. Clamp 하면 단선과 실제 0%가 같은 화면이 된다. 이 경우 scaling 코드가 아니라 fault band를 별도 상태 tag로 빼야 한다.
Loop calibrator로 3.5 mA와 21.5 mA를 실제로 주입해 보는 데 loop 하나에 2분이면 된다. 중요한 아날로그 20점이면 40분이고, 이게 내가 아는 시운전 작업 중 시간당 효과가 가장 큰 항목이다.
통신: 값이 보이는 것과 값이 맞는 것은 다르다
화면에 0이 떠 있다는 사실이 증명하는 건 아무것도 없다. 실제 0일 수도 있고, 읽기 실패 후의 기본값일 수도 있고, 멈춘 값일 수도 있다. 그래서 통신은 protocol 쪽 진단으로 확인한다.
Modbus TCP. Modbus Application Protocol v1.1b3 기준으로 FC 3(Read Holding Registers)는 응답 한 번에 125 register가 한도고, FC 1(Read Coils)은 2000 bit다. Poll block이 그 한도를 넘으면 장비는 exception code 03(Illegal Data Value)으로 거절한다. 주소가 범위를 벗어나면 02(Illegal Data Address)다. 이 두 코드를 driver 진단에서 직접 읽어 본 적이 없다면 poll block은 검증된 게 아니다. 32-bit 값의 word order는 Modbus 규격이 정해 주지 않으므로 장비 문서대로 맞춰 확인해야 한다. 자세한 건 Modbus register byte/word order 쪽에 있다.
OPC UA. Endpoint URL과 security policy만 맞으면 연결은 된다. 시운전에서 봐야 하는 건 그다음이다. OPC UA Part 4의 CreateSubscription에서 요청한 publishing interval은 server가 revised 값으로 바꿔 돌려줄 수 있다. 1초를 요청했는데 server가 5초를 돌려주면 trend 간격이 조용히 5초가 된다. Client 로그에서 revised 값을 확인하고 그 값으로 historian 주기를 적는다. 인증서 쪽 거절은 상태 코드로 나온다. Bad_CertificateTimeInvalid는 유효기간, Bad_CertificateUntrusted는 신뢰 목록 문제다. 갱신 절차는 OPC UA 인증서 갱신 체크리스트에 정리돼 있다.
시각 동기. Timestamp를 만드는 모든 장비에 NTP를 걸고, 편차 상한을 적는다. Windows domain 인증을 쓰면 상한은 이미 정해져 있다. Kerberos 기본 허용 편차가 5분이고, 넘으면 인증 자체가 실패한다. Historian 분석 쪽은 더 좁아야 한다. 같은 사건을 두 server가 다른 초에 기록하면 상관 분석이 안 된다.
알람: 개수에 상한을 적는다
알람 시운전은 "알람이 뜬다"를 보는 게 아니라 운전 중에 몇 개가 뜨는지를 재는 일이다. EEMUA 191이 운전원 1인 기준 알람률 표를 제시하고, ISA-18.2(2016) 16절 monitoring and assessment가 같은 성격의 지표 관리를 요구한다. 숫자는 이렇다.
| 지표 | 수용 가능 | 대응 곤란 |
|---|---|---|
| 10분당 알람 | 1건 이하 | 1분당 1건 초과 |
| 하루 알람 | 약 150건 | 수백 건 이상 |
시운전 중 정상 운전 2시간을 그냥 기록해 보면 된다. 10분당 12건이 나오면 그건 알람 설정이 아니라 설계를 다시 봐야 하는 신호다. ISA-18.2는 24시간 넘게 계속 떠 있는 알람을 stale alarm으로 따로 센다. 인수 시점에 stale 목록이 비어 있지 않다면, 그 알람들은 운전원이 이미 무시하기로 한 것들이다.
각 알람에 운전원 조치가 하나 적혀 있는지도 같이 본다. 조치를 못 적는 알람은 알람이 아니고 상태 표시다. 합리화 기록을 어떻게 남기는지는 알람 합리화 워크숍 체크리스트에, 자주 나오는 설계 실수는 SCADA 알람 설계에서 반복되는 실수에 있다.
화면: 계층을 먼저 정하고 색을 나중에 본다
ISA-101.01(2015)은 display hierarchy를 Level 1에서 Level 4까지 구분한다. 공장 전체 개요, 단위 공정, 상세 설비, 진단 쪽으로 내려가는 구조다. 시운전에서 흔히 깨지는 건 Level 2다. 공정 하나를 보는 화면이 없어서 운전원이 Level 1과 Level 4 사이를 계속 왕복한다.
색은 그다음이다. 색만으로 상태를 구분하면 색각 이상 운전원에게는 정보가 없다. 모양이나 글자를 같이 쓴다. 회의실에서 화면이 예쁜지 보는 것보다, 운전원에게 "지금 뭐가 돌고 뭐가 비정상인가"를 묻고 몇 초 걸리는지 재는 게 빠르다.
권한과 복구: 시험하지 않은 백업은 통과가 아니다
IEC 62443-3-3은 이 영역을 SR로 나눠 놓았다. 사람 계정 인증이 SR 1.1, software와 장비 인증이 SR 1.2, 권한 집행이 SR 2.1, 감사 기록이 SR 2.8이다. 백업은 SR 7.3(control system backup), 복구는 SR 7.4(recovery and reconstitution)다. SR 7.3이 요구하는 건 백업 파일의 존재가 아니라 백업 절차의 검증이다.
그래서 인수 기준은 하나로 줄어든다. 깨끗한 장비에 복원해서 몇 분 걸렸는지 적는다. 실측 RTO가 없으면 그 칸은 희망이다. 복원 리허설을 어떻게 돌리는지는 SCADA 백업은 깨끗한 장비에 복원해 봐야 백업이다 쪽에 절차로 적어 뒀다. 서비스 계정 비밀번호가 백업 안에만 있으면 복원은 거기서 멈춘다. 계정 쪽은 SCADA 서비스 계정 비밀번호 교체와 같이 본다.
다음에 확인할 것
인수 문서에 들어갈 건 "확인 완료" 표가 아니라 측정값이다. 아날로그 점별 오차, 실측 RTO, 2시간 알람 수, OPC UA revised publishing interval, 시각 편차 상한. 숫자가 적힌 줄은 1년 뒤에 다시 재서 비교할 수 있고, "OK"가 적힌 줄은 아무것도 증명하지 않는다.
시운전 중에 뒤로 미루면 비싸지는 결정들은 따로 모아 뒀다. HMI/SCADA 프로젝트에서 되돌리기 비싼 결정 다섯 가지를 인수 전에 한 번 훑는 편이 좋다.