탱크가 실제로는 채워지는 동안 레벨 값은 40분 내내 62.4%에 머물러 있었다. 트렌드는 완벽하게 평평한 선이었다. 노이즈도 없고 끊긴 구간도 없고, 그냥 평평했다. 운전원은 그걸 "레벨 유지"로 읽었다. 화면의 다른 모든 곳에서 평평한 선은 그런 뜻이니까. 그 계기는 게이트웨이로 가는 경로를 잃어버린 WirelessHART 계기였다. 게이트웨이는 알고 있었다. SCADA는 몰랐다. 통합 담당자가 게이트웨이 Modbus 테이블에서 공정 값만 가져오고 상태 레지스터는 손대지 않았기 때문이다.
무선 계기를 SCADA 화면에 올릴 때의 문제는 이게 전부다. 유선 4–20 mA 루프는 죽으면 0 mA로 떨어지거나 fault 전류로 몰리고, 내가 다뤄본 모든 SCADA가 그걸 잡아낸다. 무선 값은 죽어도 그냥 갱신이 멈출 뿐이고, 마지막 정상값이 계속 선을 그린다.
값과 상태는 별개의 두 가지다
WirelessHART(HART 7의 무선 확장, IEC 62591) 기기는 폴링에 응답하지 않는다. 발행(publish) 한다. 각 기기는 network manager가 짜준 스케줄에 따라 설정된 업데이트 주기로 변수를 burst 하고, 게이트웨이는 마지막으로 도착한 값을 캐시해 둔다. 게이트웨이를 읽는다는 건 현장을 읽는 게 아니라 그 캐시를 읽는 것이다.
그래서 게이트웨이는 기기마다 대략 이런 것들을 들고 있다.
- 공정 변수 자체(PV, 그리고 대개 SV/TV/QV — 코리올리 유량계나 multivariable 계기라면 여러 개가 나온다)
- device malfunction 비트와 "more status available" 비트를 포함한 HART device status 바이트
- 신선도 지표 — 마지막 정상 publish 이후 경과 시간, 또는 게이트웨이의 stale 타이머를 넘겼을 때 서는 stale 플래그
셋 다 매핑해라. 첫 번째만 매핑하면 "안정"과 "끊김"을 구분하지 못하는 화면을 만든 것이다. 대부분의 게이트웨이에서 stale 타이머 기본값은 기기 업데이트 주기의 몇 배수 형태다. 가정하지 말고 실제 값을 확인해라. 업데이트 주기가 60 s인 기기에 stale 타이머가 고정 30 s로 남아 있으면 계속 깜빡거리고, 1 s 기기에 한 시간짜리 타이머가 걸려 있으면 진짜 고장을 근무 교대가 끝날 때까지 숨긴다.
내 원칙은 이렇다. SCADA 태그 품질은 SCADA 드라이버 자신의 통신 상태가 아니라 게이트웨이의 stale 출력에서 유도한다. 드라이버는 게이트웨이가 정상이라고 보고할 것이다. 실제로 정상이니까. 없어진 건 그 뒤의 기기다. SCADA가 태그에 품질을 쓸 수 있으면 Bad/Uncertain으로 세우고 표준 bad-quality 표시가 일을 하게 둬라. 안 되면 .STALE 보조 boolean을 하나 만들어 faceplate에 올려라. 아무 시각적 차이 없이 얼어붙은 숫자는 값이 없는 것보다 나쁘다.
기기가 발행하는 것보다 빨리 폴링하지 마라
시운전에서 가장 자주 보는 실수는 32초마다 발행하는 기기를 향해 1초 scan class를 걸어두는 것이다. 게이트웨이 CPU와 네트워크 트래픽만 쓰고 얻는 건 없다. 같은 float를 31번 다시 읽고 나서 계단 하나를 얻는다.
더 나쁜 건 뒷단을 전부 왜곡한다는 점이다. exception 기반 히스토리언 수집은 이 계단을 보고 공정이 실제로 단계적으로 움직인 것처럼 전이를 저장한다. 변화율 알람은 일어난 적 없는 계단 모서리에서 기울기를 계산한다. 그 태그로 미분이나 트렌드 기울기를 분석하는 건 전부 쓰레기 값을 받는다.
게이트웨이는 거기 붙은 기기 중 가장 빠른 업데이트 주기 정도로 폴링하고, 설정 주기가 비슷한 기기끼리 scan class로 묶어라. 그리고 트렌드에서는 이게 샘플링된 데이터라는 걸 솔직하게 표시해라.
업데이트 주기를 정하는 일 자체는 제어 이야기가 아니라 배터리 이야기다. WirelessHART는 1초부터 수 분까지 지원하지만, 배터리 구동 계기의 전원 모듈은 특정 duty cycle을 기준으로 산정돼 있다. 32 s에서 1 s로 바꾸면 몇 년짜리 모듈 수명이 몇 달로 줄 수 있다. "더 빠르게" 요청이 오기 전에 해당 모듈의 벤더 수명 곡선을 확인해라. 그리고 WirelessHART 메시에 올라간 것 중 폐루프 제어나 인터록에 들어갈 자격이 있는 건 없다. 감시, 최적화, 에너지 집계, 탱크 재고, 부식, 스팀 트랩과 안전밸브 감시, 온도 서베이 — 이게 이 네트워크의 일이다. IEC 62591은 다중 홉 메시를 가로지르는 결정론적 지연을 약속하지 않는다.
무선보다 Modbus 맵이 먼저 문다
대부분의 게이트웨이는 HART-IP, OPC UA, EtherNet/IP, Modbus TCP/RTU를 다 열어준다. 고를 수 있으면 HART-IP나 OPC UA를 택해라. device status와 신선도가 레지스터 오프셋에서 재구성해야 하는 무언가가 아니라 구조화된 데이터로 넘어온다.
Modbus여야만 할 때(브라운필드에서는 대개 그렇다) 예상되는 함정은 늘 같다.
- 32비트 float word order. 다른 모든 Modbus 통합과 똑같은 싸움이다. 아는 값으로 확인해라. 계기를 벤치에 놓고 실제 압력을 읽히면서 숫자를 맞춰봐야지, 매뉴얼 그림을 믿으면 안 된다.
- 레지스터 블록은 고정이 아니라 할당된 것이다. 게이트웨이의 Modbus 테이블은 당신이 만든 설정에서 나온다. 기기 X의 PV는 당신이 지정한 레지스터에 앉는다. 반년 뒤에 기기를 하나 추가하면서 누군가 그 테이블을 재정렬하거나 다시 채우면 뒷단 주소가 전부 밀린다. 맵을 export 해서 프로젝트 문서에 넣고 관리 문서로 취급해라.
- 단위는 기기가 말하는 그대로다. 게이트웨이는 계기에 설정된 공학 단위를 그대로 재발행한다. 현장에서 기술자가 계기를 kPa에서 bar로 바꾸면, 그 순간 아무 알람도 없이 SCADA 값이 100배 바뀐 것이다. 태그에 범위 체크를 걸어라.
join 문제는 무선 문제처럼 보이지만 대개 아니다
네트워크에 올라오지 않는 기기는, 내 경험상 신호 약함보다 자격 증명 오류인 경우가 훨씬 많다. 모든 기기는 게이트웨이와 일치하는 network ID와 join key가 필요한데, join key는 오타가 날 만큼 길다. 어느 쪽인지는 게이트웨이의 join 실패 로그가 알려준다. 들리는데 거부되는 기기는 key 문제고, 아예 나타나지 않는 기기는 무선이나 전원 문제다.
join은 설계상 느리기도 하다. 큰 메시의 가장자리에 있는 기기는 이웃을 찾고 advertisement 패킷을 받고 대역폭을 할당받기까지 꽤 긴 분 단위 시간이 걸릴 수 있다. 유선 시운전에서 몸에 밴 "몇 초면 올라와야지" 감각보다 훨씬 길다. 전원 넣고, 자리를 뜨고, 나중에 와서 봐라.
배치는 직관 말고 벤더 설계 지침을 따라라. 모든 기기가 통신 범위 안에 이웃을 최소 셋은 갖게 하고, 의미 있는 비율의 기기가 게이트웨이와 직접 통신 범위 안에 있게 해서 메시가 중계기 하나에 길게 매달리지 않도록 한다. Emerson의 경험칙은 25%가 직접 범위 안, 소규모 네트워크는 다섯 대다. 금속, 움직이는 설비, 가득 찬 탱크가 모두 그림을 바꾼다. 시운전 때 멀쩡했던 네트워크가 탱크 야드가 차면서 나빠질 수 있다.
인수 전에 확인할 것
- 게이트웨이 진단 페이지의 기기별 신뢰도(reliability) 퍼센트. 90% 아래에 계속 머문다면 재조정이 아니라 기기나 리피터를 하나 더 넣어야 한다는 뜻이다.
- 각 이웃 링크의 경로 안정성, 그리고 사용 가능한 경로가 하나뿐인 기기가 있는지. 단일 경로 기기는 메시가 우회할 수 없는 단일 고장점이다.
- 배터리/전원 모듈 잔여 수명을 SCADA 태그로 빼고 저 알람을 걸어라. 계획 정비 기간에 걸릴 만큼 충분히 앞당겨 세팅한다.
- 기기 하나의 전원을 뽑고 운전 화면이 어떻게 되는지 봐라. 예상한 stale 시간 안에 눈에 띄게 바뀌지 않으면 staleness 매핑이 틀린 것이다. 엔지니어링 워크스테이션 말고 실제 화면에서, 운전원이 보는 앞에서 해라.
이 네트워크에서 가장 좋은 트러블슈팅 도구는 게이트웨이 자신의 진단이고, 그건 거의 항상 매핑되지 않은 채 인수 뒤로는 아무도 로그인하지 않는 웹 페이지 뒤에 앉아 있다. 시운전 때 네트워크 상태 지표를 SCADA 태그로 끌어와라. scan class 하나와 한 시간쯤이면 되고, "레벨이 멈춘 것 같은데요"를 "14번 기기가 지난 화요일에 경로 하나로 떨어졌습니다"로 바꿔준다.