OPC UA 데드밴드, 밀리는 계측값을 숨기지 않고 설정하는 법

이 필터는 트래픽 옵션이 아니라 운전 판단이다

모니터드 아이템은 샘플링된 값을 전부 보낼 필요가 없다. 아이템에 붙이는 DataChangeFilter(OPC UA Part 4에 정의)가 어떤 변화만 통지(notification)로 올릴지 정하는데, 필드는 두 개다. DeadbandType과 DataChangeTrigger. 공정을 생각하지 않고 잡으면 두 가지 방식으로 실패한다.

너무 느슨하면, 시간당 0.4 °C씩 밀리는 계측값이 데드밴드를 한 번도 못 넘어서 화면은 멀쩡한데 루프는 벗어난다. 너무 촘촘하면, 노이즈가 있는 아날로그가 발행 주기마다 큐를 채워서 클라이언트가 불안정해 보이고, 실제 원인은 모든 흔들림을 다 달라고 한 것인데 네트워크를 탓하게 된다.

샘플링과 보고를 분리해서 본다

시운전 때 자주 섞이는 설정이 있다.

예를 들어 값은 250 ms마다 샘플링하되, 0.2 °C 이상 움직일 때만 보고하게 만들 수 있다. 노이즈가 있는 온도값에는 도움이 된다. 하지만 명령 피드백, 알람 상태, 배치 단계, 누적 카운터에는 맞지 않는다. 그런 값은 작은 변화가 아니라 변화 자체가 의미다.

DataChangeTrigger: 무엇을 변화로 볼 것인가

DataChangeTrigger enum은 값이 세 개다. 클라이언트마다 더 친절한 이름을 붙이지만 밑에서는 항상 이 셋이다.

• Status(0) — StatusCode가 바뀔 때만 통지. 값이 아니라 품질이 Bad로 떨어졌는지만 보는 순수 진단 태그에 쓴다.
• StatusValue(1) — 상태나 값이 바뀌면 통지. 대부분 스택의 기본값이고, 일반 HMI 공정값에는 이게 맞다.
• StatusValueTimestamp(2) — 상태와 값이 같아도 소스 타임스탬프가 움직이면 통지. heartbeat류 태그나, 여전히 재계산되고 있는지 증명해야 하는 PLC 계산값에 쓴다.

함정은 안정된 아날로그 무리에 StatusValueTimestamp를 거는 것이다. 소스 타임스탬프는 스캔마다 갱신되니 공정이 안 움직여도 발행 주기마다 통지가 올라온다. 반대 함정은 멈춘 계산 블록을 StatusValue로 두는 것이다. 값이 우연히 그대로라서 멈춘 블록이 멀쩡해 보인다. 템플릿이 아니라 태그마다 골라야 한다.

절대 데드밴드(DeadbandType 1)를 먼저 검토한다

DeadbandType을 Absolute(1)로 두면 DeadbandValue가 값과 같은 엔지니어링 단위다. 마지막으로 보고한 값에서 그만큼 이상 움직일 때만 보고한다. 변환할 게 없어서 이해하기 쉽다. 탱크 레벨은 0.1%나 0.5%, 온도는 1 °C, 압력은 운전자가 실제로 그 해상도로 일한다면 0.02 bar처럼 잡는다.

설정 전에 확인할 것:

• HMI에 표시되는 단위와 소수 자릿수.
• 정상 운전 중 계측 노이즈와 운전자가 의미 있게 보는 최소 변화.
• 알람 한계값과의 거리. 데드밴드가 너무 크면 알람 근처 움직임을 늦게 본다.
• 원시 카운트(raw count)와 스케일된 엔지니어링 값에 같은 데드밴드를 쓰고 있지 않은지.

화면에는 소수 한 자리만 보이는데 데드밴드를 0.001로 두면 대부분 트래픽 낭비다. 반대로 루프 튜닝용 화면이면 별도 구독 그룹을 만들어 더 촘촘히 보는 것이 낫다.

퍼센트 데드밴드(DeadbandType 2)는 EURange에 목숨을 건다

DeadbandType Percent(2)는 노드의 EURange Property(OPC UA Part 8, Data Access)를 기준으로 정의된다. 서버는 실제 밴드를 DeadbandValue / 100 * (EURange.high - EURange.low)로 계산한다. 그래서 0100 범위에서 1%는 1이고, 같은 1%가 010,000 범위에서는 100이다. 같은 설정인데 백 배 거칠다.

시운전 실수가 여기서 숨는다. 퍼센트 데드밴드는 EURange Property가 실제로 있는 노드에서만 유효하다. 없으면 서버가 Bad_MonitoredItemFilterUnsupported를 돌려줘야 맞지만, 허술한 스택은 조용히 데드밴드 없음으로 되돌리기도 한다. 그리고 EURange가 템플릿에서 상속된 뒤 고쳐지지 않았다면 밴드가 조용히 틀린다. 값이 한 번 크게 튈 때까지 멈춘 것처럼 보이면, 네트워크를 건드리기 전에 범위 메타데이터부터 읽는다.

실무 기준은 단순하다.

• 퍼센트 데드밴드를 쓰는 아날로그 태그는 EURange를 시운전 항목에 넣는다.
• 카운터, 레시피 파라미터, 인위적인 범위를 가진 계산값에는 퍼센트 데드밴드를 조심한다.
• 설정한 퍼센트가 계기 스팬 기준인지, 운전 범위 기준인지, 벤더 기본값 기준인지 문서에 남긴다.

데드밴드를 피하는 편이 좋은 태그

다음 값은 숫자 움직임의 크기보다 변경 이벤트 자체가 중요하다.

• 알람 active, acknowledge, shelve, suppress 상태.
• 설비 모드, 스텝, 페이즈, 인터록 요약.
• 명령 피드백과 퍼미시브 상태.
• 한 번 증가할 때마다 의미가 있는 카운터.
• 배치 ID, 로트 ID, 레시피 번호, 작업자 선택값.
• 통신 상태 판단에 쓰는 heartbeat와 watchdog 값.

이런 태그는 데드밴드로 숨기기보다 샘플링 주기와 발행 주기를 목적에 맞게 잡는 쪽이 안전하다.

자주 만나는 고장 양상

HMI는 조용한데 히스토리언 저장량이 많다

HMI 구독은 데드밴드가 걸려 있고, 히스토리언은 더 촘촘한 예외 수집이나 주기 수집을 할 수 있다. 운전 화면은 안정적으로 보이는데 저장량은 계속 늘어난다.

클라이언트를 각각 확인해야 한다. OPC UA 필터는 모니터드 아이템별, 클라이언트별 설정이다. HMI 설정이 좋다고 히스토리언 부하까지 자동으로 줄어들지는 않는다. 그리고 이 필터가 걸러낸 것 위에 히스토리언 자체의 데드밴드와 압축이 다시 적용되므로, 두 계층을 함께 봐야 한다.

튜닝 중 작은 헌팅이 사라진다

루프가 0.2 °C 폭으로 흔들리는데 데드밴드가 0.5 °C이면 트렌드에는 계단처럼 보이거나 거의 안 보인다. 제어 문제를 놓치기 쉽다.

튜닝할 때는 임시 진단 구독이나 별도 트렌드 펜을 만들어 더 작은 데드밴드로 본다. 시험이 끝나면 원래 운전 설정으로 되돌린다.

큐 오버플로로 순서가 빠진다

발행 주기 사이에 값이 여러 번 바뀌는데 큐 크기가 1이면 중간 값은 버려진다. 느린 아날로그 표시에는 괜찮을 수 있다. 하지만 시퀀스 스텝이나 고장 코드라면 실제 순서를 잃는다.

서버가 discarded notification 카운터를 제공하면 같이 본다. 중간 값이 필요한 태그에만 큐 크기를 늘린다.

서버가 요청한 필터를 받아들이지 않는다

모든 서버가 모든 필터 조합을 지원하지는 않는다. 어떤 노드는 필터를 거부하고, 어떤 클라이언트는 조용히 기본값으로 되돌아간다.

FAT에서 요청값만 보지 말고 서버가 돌려준 revised sampling interval, revised queue size, monitored item status를 확인한다. 요청했다고 적용된 것은 아니다.

시운전 때 남길 항목

• 태그를 운전 아날로그, 빠른 진단, 상태 비트, 카운터, 히스토리언 수집, 명령 피드백으로 나눈다.
• 단위가 명확한 값은 절대 데드밴드를 우선 검토한다.
• 퍼센트 데드밴드는 EURange 확인 후 적용한다.
• 알람과 명령 상태는 제어 로직의 의도적인 디바운스가 아니라면 필터로 숨기지 않는다.
• 강제 램프, 작은 스텝, 노이즈가 있는 정상 신호를 넣어 화면과 히스토리언을 같이 본다.
• 같은 시간대의 HMI 트렌드, 히스토리언 값, 서버 진단 카운터를 대조한다.
• 기본값이 아닌 필터는 태그 템플릿이나 클라이언트 설정 노트에 이유를 남긴다.

마지막 기준

먼저 질문을 정한다. 운전자, 알람 기능, 히스토리언, 문제 해결 담당자가 어떤 변화를 반드시 봐야 하는가. 그다음 샘플링, 발행, 필터, 큐 크기를 맞춘다. 좋은 DataChange 필터는 증거를 지우지 않고 노이즈만 줄인다.