계기는 알고 있지만, 아무도 묻지 않았다
로딩 라인의 코리올리 유량계가 질량 유량을 깔끔한 4-20 mA 신호로 SCADA에 보낸다. 그런데 이 계기는 밀도, 튜브 온도, 드라이브 게인(drive gain), 센서 결함 플래그도 함께 측정하고 있다 — 그리고 그 어느 것도 제어실에 도달하지 않는다. 튜브에 코팅이 쌓이기 시작하고 드라이브 게인이 트립 지점까지 올라가는 동안, 사람들이 처음 알아챈 것은 "센서 고장" 알람과 멈춰버린 배치였다. 트랜스미터는 2주 동안 아무도 듣지 않는 언어로 불평하고 있었다.
그 언어가 HART이고, 이미 4-20 mA 신호와 같은 두 가닥 전선을 타고 흐르고 있었다. 빠진 것은 SCADA 쪽에서 그것을 읽어줄 무언가뿐이었다.
전선 위에 실제로 무엇이 실려 있나
HART(Highway Addressable Remote Transducer)는 아날로그 전류 루프 위에 Bell 202 FSK 신호를 중첩시킨다. 1은 1200 Hz, 0은 2200 Hz, 속도는 1200 bps다. 이 톤들은 평균 전류가 0이라, PLC의 아날로그 카드가 읽는 DC 값을 흔들지 않고 4-20 mA 위에 얹혀 간다. 제어 신호는 이전과 똑같이 동작하고, 디지털 계층은 별개의 대화다.
HART 장치는 최대 네 개의 동적 변수(dynamic variable)를 노출한다.
- PV — 1차 변수, 4-20 mA가 나타내는 바로 그 값(코리올리의 경우 유량).
- SV, TV, QV — 2차, 3차, 4차. 코리올리 유량계라면 밀도, 온도, 드라이브 게인.
그 위에 장치 상태 바이트, 확장 장치 상태, 그리고 전체 명령 집합을 실어 나른다. 범용 명령 3(Universal Command 3)은 한 번의 트랜잭션으로 루프 전류와 네 동적 변수를 모두 반환한다. 명령 48(Command 48)은 추가 장치 상태를 반환하는데 — "뭔가 잘못됐다"를 "드라이브 게인 높음, 튜브 코팅 의심"으로 바꿔주는 진단 세부 정보가 여기에 있다.
문제는 속도다. 점대점(point-to-point) HART는 장치당 초당 약 2회 정도의 업데이트를 준다. 밀도, 온도, 진단에는 충분하다. 하지만 제어 루프 속도에는 한참 못 미치고, 그래서 빠른 DC 4-20 mA 경로가 여전히 존재하는 것이다. HART 디지털 변수로 제어 루프를 절대 닫지 마라. 제어에는 4-20 mA를, 보조 값과 건전성에는 HART를 쓴다.
SCADA로 끌어오는 네 가지 방법
HART 지원 아날로그 I/O
요즘 많은 DCS·PLC 플랫폼의 아날로그 입력 카드는 4-20 mA를 정상적으로 통과시키면서 백그라운드에서 HART를 디지털로 읽는다. 이미 이런 카드를 갖고 있다면 이 방법이 가장 적은 신규 하드웨어로 끝난다. 보조 변수와 장치 상태가 추가 태그로, 또는 SCADA 드라이버가 매핑하는 데이터 블록으로 나타난다.
함정은 백그라운드 스캔 속도다. 8채널이나 16채널에 걸쳐 HART를 도는 카드는 각 채널을 수 초, 때로는 수십 초마다 읽는다. 진단에는 괜찮지만 SV를 1초 트렌드 해상도로 기대했다면 쓸모가 없다. 누구에게든 빠른 보조 변수를 약속하기 전에 카드의 HART 스캔 사양을 읽어라.
HART 멀티플렉서
HART 멀티플렉서(mux)는 마샬링 캐비닛에 자리 잡고, 기존 단자를 통해 16~32개 루프를 태핑해, 모든 것을 Modbus RTU/TCP로 — 최신 장비라면 OPC나 HART-IP 인터페이스로 — 내보낸다. 이것이 개조(retrofit) 정답이다. 현장 배선도, 제어 I/O도 바꾸지 않고, SCADA 드라이버로 돌아가는 RS-485 또는 이더넷 회선 하나면 된다.
시운전 때 확인할 두 가지:
- 루프 저항. FSK 모뎀이 읽을 수 있는 신호를 만들려면 루프에 230~600 Ω, 보통 250 Ω 감지 저항이 필요하다. 누군가 루프를 저항이 거의 0에 가까운 순수 전류 입력으로 값 절감(value engineering)해 놓았다면, mux는 아무것도 읽지 못하고, 빠진 저항을 찾아낼 때까지 "통신 실패"를 쫓게 된다.
- 폴링 예산. 32개 장치에서 네 변수와 상태를 스캔하는 mux는 즉시가 아니다. 포인트마다 실제로 필요한 스캔 값만 요청하고 그 Modbus 레지스터만 매핑하라. 모든 장치에서 모든 변수를 끌어오고 왜 한 사이클이 20초나 걸리는지 의아해하지 말고.
HART-Modbus / HART-이더넷 게이트웨이
중요한 계기가 몇 개뿐이라면, 한쪽은 HART, 다른 쪽은 Modbus TCP나 이더넷으로 말하는 작은 게이트웨이가 완전한 mux보다 싸고 간단하다. 저항과 폴링에 관한 주의사항은 동일하다. SCADA 쪽은 평범한 Modbus 레지스터를 보므로 매핑은 일반적인 태그 작업이다 — 다만 어느 레지스터가 SV이고 어느 것이 TV인지 문서화하라. 게이트웨이 벤더의 레지스터 맵이 "밀도"와 정체불명 float 사이에 서 있는 유일한 것이니까.
WirelessHART
WirelessHART(IEC 62591)은 같은 HART 명령 집합을 2.4 GHz 메시 위에서 돌린다. 필드 게이트웨이가 메시를 집약해 북쪽으로 Modbus TCP, OPC UA, 또는 HART-IP로 내보낸다. 여분의 전선이 없는 계기 — 나중에 추가된 것, 회전 장비 위의 것, 굴착할 생각이 없는 도로 건너편의 것 — 에는 이것이 현실적인 경로다. 업데이트 속도는 장치별로 설정되므로(보통 1~60초), 장치가 낼 수 있는 가장 빠른 값이 아니라 SCADA와 히스토리안이 실제로 소비하는 값으로 맞춰라. 모든 업데이트마다 배터리 수명을 지불하니까.
태그를 손에 넣은 뒤, 그것들이 있어야 할 자리
HART 보조 변수는 제어 PV와 같은 등급의 데이터가 아니며, 같은 것처럼 취급하면 문제가 생긴다.
건전성 신호에는 별도의 품질과 알람 처리를 줘라. 장치 상태 바이트와 명령 48 진단은 공정 알람이 아니라 정비 우선순위 알람을 구동해야 한다 — 드라이브 게인 상승은 "지금 당장 플랜트 정지"가 아니라 "세정 일정 잡기" 이벤트이고, 실제 트립과 경쟁하며 운전원의 공정 알람 요약에 절대 올라가서는 안 된다. 대신 정비 화면이나 CMMS 알림으로 보내라.
타임스탬프 이야기도 살펴라. 몇 초마다 갱신되는 HART 변수를 좁은 데드밴드로 예외 기반 히스토리안에 저장하면 거의 아무것도 남지 않는다 — 죽은 태그처럼 보인다. 이런 포인트에 대해 히스토리안의 기대치를 넓히거나 주기적으로 샘플링하고, 오래된 HART 값이 조용히 마지막 판독값에 얼어붙는 대신 bad 또는 uncertain 품질을 달도록 하라. "good"으로 읽히며 얼어붙은 밀도는 밀도가 아예 없는 것보다 나쁘다.
대부분을 잡아내는 시운전 점검
HART 데이터를 라이브로 선언하기 전에, 계기 하나에서 전체 경로 하나를 처음부터 끝까지 증명하라.
- 핸드헬드 커뮤니케이터나 자산 관리 도구로 현장 단자에서 장치를 읽어 — 계기가 HART로 말하기는 하는지 확인한다.
- mux, 카드, 게이트웨이가 태핑하는 지점에서 루프 저항이 230~600 Ω 범위인지 확인한다.
- 선택한 게이트웨이를 통해 명령 3이 네 동적 변수를 모두, 명령 48이 장치 상태를 반환하는지 검증한다.
- 보조 변수 하나 — 이를테면 밀도 — 를 계기에서 mux 레지스터, SCADA 드라이버, 화면의 태그까지 추적하고, 공학 값과 단위가 트랜스미터 자체 표시와 일치하는지 확인한다.
- 장치가 보고하는 결함을 강제로 발생시키고(센서 테스트나 의도적으로 오래된 판독값), 그것이 good 값이 아니라 bad 품질과 정비 알람으로 나타나는지 확인한다.
이것을 한 번 꼼꼼히 하고 나면 나머지 계기는 복사하고 검증만 하면 된다. 건너뛰면, 그럴듯해 보이고 "good"으로 읽히면서 조용히 거짓말하는 밀도·온도 태그의 벽으로 끝난다 — HART를 아예 배선하지 않은 것보다 유일하게 더 나쁜 결과다.