DNP3 Need Time 비트로 이벤트 타임스탬프를 지키는 법

DNP3가 시각을 신경 쓰는 이유

대부분의 프로토콜은 값을 건네주고 마스터가 도착 시점에 시각을 찍게 둔다. DNP3는 다르게 한다. outstation이 이벤트가 일어난 바로 그 순간에 스스로 타임스탬프를 찍고, 마스터가 수집할 때까지 버퍼에 담아 둔다. 이것이 클래스 기반 이벤트 모델의 핵심이다. 무선이 끊긴 사이에 발생한 차단기 트립도, 폴이 마침내 통과한 시각이 아니라 실제로 트립한 시각으로 도착한다.

이 설계는 outstation의 시계가 맞아야만 동작한다. outstation이 30초 어긋나 있으면 그것이 보고하는 모든 이벤트가 30초 어긋나고, 마스터 쪽에서 아무리 영리하게 굴어도 고칠 수 없다. 그래서 DNP3에는 마스터가 outstation의 시계를 맞추는 메커니즘과, outstation이 시계가 어긋났다고 판단할 때 세우는 플래그가 내장돼 있다. 이 메커니즘을 잘못 다루면 이벤트 순서 데이터가 정밀해 보이는 허구가 된다.

이 글은 클래스 폴링과 비요청 응답 노트의 아래에 있는 시각 동기화 계층이다. 같은 이벤트 모델이지만, 타임스탬프가 의존하는 시계에 초점을 둔다.

Need Time 비트

모든 DNP3 응답 안에는 Internal Indications, 줄여서 IIN이라 부르는 2바이트 필드가 있다. DNP3 표준인 IEEE 1815에 정의돼 있다. 그 안의 한 비트 IIN1.4가 "Need Time" 비트다. outstation은 이 비트를 세워 마스터에게 말한다. 내 시계를 맞춰야 하니 동기화해 달라.

outstation이 Need Time을 세우는 상황은 몇 가지다.

• 기동 시, 아직 한 번도 동기화되지 않았을 때. 방금 부팅한 outstation은 지금이 몇 시인지 모른다.
• 설정된 주기 후, 내부 발진기가 드리프트하므로 드리프트가 문제되기 전에 새 동기화를 원하기 때문에.
• 특정 이벤트 후, 시각 유지에 영향을 줬을 수 있는 사건 뒤에.

마스터는 모든 응답에서 이 비트를 감시한다. Need Time이 세워진 것을 보면 시각 동기화 절차를 실행해 현재 시각을 outstation에 써야 하고, 그러면 비트가 지워진다. 루프는 단순하다. outstation이 요청하고, 마스터가 답하고, 비트가 지워진다.

전형적인 현장 실패는 절대 답하지 않는 마스터다. 마스터가 Need Time 비트를 처리하도록 설정되지 않았거나, 운전원이 "트래픽을 줄이려고" 시각 동기화를 꺼 두면, outstation은 플래그를 영원히 세운 채 시계가 자유 주행하고 이벤트 타임스탬프가 매일 더 어긋난다. 링크는 건강하고 데이터는 흐르니 아무 경보도 없다. 시각만 조용히 틀린다.

절대 시각 대 record-current-time

DNP3 마스터가 outstation의 시계를 맞추는 방법은 두 가지이며, 네트워크 경로 자체가 시간을 소모하기 때문에 둘 다 존재한다.

절대 시각 쓰기(LAN 절차). 마스터가 먼저 outstation까지의 왕복 지연을 측정한 뒤, 지연을 이미 더한 타임스탬프를 써서 값이 정확히 도착하게 한다. 전송 지연이 크거나 변동하는 모든 링크에서 써야 하는 절차다.

record-current-time(시리얼/비-LAN 절차). 마스터가 Record Current Time 함수를 보내면 outstation이 그 메시지가 도착하는 정확한 순간을 기록하고, 마스터가 이후 읽어 보정한다. 지연이 작고 안정적인 직결 시리얼 링크에 더 간단한 절차다.

이것이 중요한 이유. 마스터가 순진하게 "지금은 12:00:00.000이다"라고 쓰는데 메시지가 무선 경로를 건너는 데 400 ms가 걸리면, outstation은 도착하는 순간 시계를 400 ms 느리게 맞춘다. 두 이벤트 중 어느 것이 먼저인지 가려야 하는 네트워크에서 400 ms는 올바른 이벤트 순서와 뒤바뀐 순서를 가르는 차이다. 지연 측정 단계는 형식적 절차가 아니라 타임스탬프를 참으로 만드는 보정이다.

링크 지연 측정

LAN 시각 동기화 절차에는 명시적인 지연 측정 단계가 있다. 마스터가 지연 측정 요청을 보내면 outstation이 즉시 응답하고, 마스터가 왕복을 반으로 나눠 단방향 전송을 추정한다. 그 값이 마스터가 쓰는 시각에 반영된다.

여기서 두 가지가 잘못된다.

• 비대칭이거나 지터가 큰 경로. 왕복을 반으로 나누는 것은 가는 길과 오는 길이 같은 시간이 걸린다고 가정한다. store-and-forward 무선이나 혼잡한 네트워크에서는 그렇지 않고, 추정치는 그 오차를 안고 간다. 한쪽 끝에서 비대칭을 고칠 수는 없다. 경로를 최대한 깨끗이 유지하고 정확도에 바닥이 있음을 받아들이는 수밖에 없다.
• outstation 처리 지연. outstation이 지연 측정 요청을 늦게 되돌리면 마스터가 전송 시간을 과대 추정한다. 잘 만든 outstation은 바로 이 이유로 지연 측정에 최소한의 예측 가능한 지연으로 응답한다.

이벤트 순서 정확도 요구가 측정 가능한 링크 지연보다 빡빡하면 DNP3 시각 동기화만으로는 도달할 수 없다. 이때는 outstation에 GPS나 IRIG-B 같은 독립 시각원을 주고, 마스터의 시계 쓰기는 주 기준이 아니라 대체 수단이 된다.

동기화 주기: 너무 자주와 너무 드물게

outstation이 Need Time을 얼마나 자주 세울지는 대개 설정 가능한 주기로 정한다. 양극단 모두 문제를 만든다.

• 너무 드물면 동기화 사이에 시계가 멀리 드리프트한다. 값싼 발진기는 하루에 몇 초씩 드리프트할 수 있다. 일주일에 한 번 동기화하면 6일째에는 다음 보정이 되돌리기 직전에 타임스탬프가 의미 있게 틀려 있고, 그 되돌림 자체가 이벤트 시각의 불연속으로 보인다.
• 너무 자주면 느린 무선이 감당하기 어려운 링크 대역폭을 필요 없는 정확도를 위해 시각 쓰기에 소모한다.

주기는 기본값이 아니라 outstation의 실제 드리프트율과 타임스탬프 정확도 요구에서 정한다. 이벤트를 10 ms로 분해해야 하고 분당 1 ms 드리프트하는 outstation은, 시간별 합계를 보고하는 것과 전혀 다른 일정으로 동기화가 필요하다. outstation을 자유 주행시키고 그 타임스탬프를 알려진 기준과 비교해 드리프트를 측정하라. 그 숫자가 주기를 알려 준다.

틀린 시각이 히스토리언에 숨는 방식

DNP3 시각 동기화 불량의 피해는 outstation에서는 좀처럼 드러나지 않는다. 하류의 히스토리언과 이벤트 순서(SOE) 로그에서 드러나고, 원인을 거슬러 찾기 어렵다.

알아둘 증상.

• 순서가 뒤바뀐 이벤트. 시계가 몇 초 차이 나는 두 outstation이 원인과 결과를 보고하면, 결과가 원인보다 먼저 타임스탬프된다. 이런 일이 한 번 생기면 운전원은 SOE 로그 전체를 불신한다.
• 동기화 후 이벤트 시각의 계단. outstation이 일주일 자유 주행하다 동기화되면, 동기화 이전의 모든 이벤트는 오프셋되고 이후는 정확하며, 동기화 순간에 눈에 보이는 점프가 생긴다.
• 폴 경계에 몰린 타임스탬프. 이벤트가 outstation이 아니라 마스터 도착 시점에 찍히면 DNP3 이벤트 모델의 이점 전체를 잃고, 빠른 이벤트가 실제 시각이 아니라 스캔 시각에 몰린다.

히스토리언 클록 드리프트 규율이 일부를 잡지만, 해결은 상류에 있다. 이벤트가 찍히기 전에 outstation 시계가 맞아야 한다. 사후에 어떤 하류도 타임스탬프의 드리프트를 되돌릴 수 없기 때문이다.

시운전 체크리스트

단 하나의 이벤트 타임스탬프를 믿기 전에 시각 동기화를 확인하라.

1. 마스터가 단지 연결된 것이 아니라 실제로 Need Time(IIN1.4) 비트를 처리하도록 설정됐는지 확인한다. 응답을 지켜보며 동기화 후 비트가 지워지는지 확인한다.
2. 네트워크·무선 링크에는 LAN 절차(지연 측정과 함께 절대 시각 쓰기)를, record-current-time은 짧고 안정적인 시리얼 링크에만 선택한다.
3. LAN 링크에서 지연 측정 단계가 실행되고, 측정된 지연이 물리 경로에 타당한 값이며 0이 아닌지 확인한다.
4. outstation의 동기화 주기를 측정한 드리프트율과 타임스탬프 정확도 요구에서 설정하고, 기본값을 쓰지 않는다.
5. 빡빡한 이벤트 순서 요구에는 outstation에 독립 시각원(GPS/IRIG-B)을 주고 마스터 쓰기를 대체 수단으로 다룬다.
6. outstation을 잠시 자유 주행시키고 이벤트 타임스탬프를 알려진 기준과 비교해 실제 드리프트를 측정한다.
7. Need Time 비트를 트렌드하거나 노출해, 조용히 동기화를 멈춘 마스터가 침묵 대신 눈에 보이게 한다.
8. 히스토리언에서 순서가 뒤바뀐 이벤트와 동기화 후 시각 계단을 표본 점검해, 타임스탬프가 참인지 종단 간 확인한다.
9. 동기화 절차, 주기, 측정된 링크 지연, 외부 시각원을 포인트 맵과 함께 기록한다.

목표는 그 위에 이벤트 순서를 세울 수 있는 타임스탬프다. 차단기가 트립하고 하류 계전기가 뒤따르면, 로그는 그것들을 실제로 일어난 순서로 보여 줘야 한다. 그리고 그 순서는 그것들을 찍은 outstation 시계만큼만 정확하다.