Trend cursor는 시계가 맞을 때만 증거가 된다

Trend cursor는 시간 기준이 맞을 때만 증거가 된다

Operator가 trend에 cursor를 찍고 readout을 가리키며 “펌프가 트립되기 전에 헤더 압력이 먼저 떨어졌다”고 말한다. 사고 분석에서는 이 한 문장이 곧 원인이 된다. 하지만 이 문장이 원인이 되려면 HMI client, SCADA server, historian, PLC, 그리고 그 기록을 출력한 report tool까지 전부 시각을 어떻게 찍고 어떻게 표시하는지에 대해 서로 맞아야 한다. 대개는 맞지 않고, 그 차이는 대충 보면 넘어갈 만큼 작다. 2초, 5초, 때로는 8초.

Trend 시간 오류가 고약한 이유가 여기 있다. 선은 여전히 그럴듯해 보인다. Quality도 bad로 뜨지 않는다. 문제는 alarm list, batch record, PLC event log, historian trend를 나란히 놓고 event 순서가 말이 안 되기 시작할 때에야 드러난다.

Timestamp가 어디서 찍히는지 먼저 본다

Trend 화면을 의심하기 전에 각 데이터 경로의 timestamp 출처를 확인한다.

데이터 경로	흔한 timestamp 출처	확인할 내용
Live HMI tag	SCADA server 수신 시각	Driver group 지연과 server clock
Historian sample	Historian interface 또는 archive node	Compression, buffering, late data 처리
PLC event record	PLC real-time clock	Time sync 방식과 daylight saving 처리
Alarm event	Alarm engine 평가 시각	Alarm delay, shelving, redundant server 동작
Batch, MES record	Application service 또는 database server	Timezone 저장 방식과 report 변환

한 project 안에서도 규칙이 하나가 아닐 수 있다. Live pen은 server가 값을 받은 시각으로 보이고, 같은 화면의 historical pen은 historian archive 시각으로 보일 수 있다.

OPC UA는 이 구분을 명시하고 있는데, 많은 SCADA driver가 이를 감춰 버리기 때문에 짚고 넘어갈 가치가 있다. 모든 DataValue는 timestamp를 두 개 가진다(spec Part 4). 값이 device나 gateway에서 실제로 취득된 시각인 SourceTimestamp, 그리고 OPC UA server가 그 값을 처리한 시각인 ServerTimestamp다. Historian이 server를 subscribe하면서 ServerTimestamp를 저장하는데 operator는 그것을 현장 시각이라 믿고 있다면, 모든 값이 전송과 polling 지연만큼 밀려 저장된다. 보통 수십에서 수백 ms, 느린 radio link에서는 더 크다. 어느 쪽을 archive할지 정하고 기록으로 남겨라. DNP3(IEEE 1815)도 같은 구조다. Class 1/2/3 time-tagged event object는 outstation 자신의 timestamp를 싣고 오지만, 일반 static poll은 master가 받은 시각으로 찍힌다. 그래서 같은 point라도 fast event와 느린 static read가 poll 주기 하나만큼 어긋날 수 있다.

Live trend와 historical replay를 비교한다

시운전 때는 안전한 test signal을 하나 만들어 live와 history에서 같이 보는 것이 좋다.

확인 순서는 간단하다.

생산에 영향 없는 test bit 또는 simulator tag를 정해진 시각에 바꾼다.
Live trend cursor에서 값이 바뀌는 시각을 본다.
Historian 저장이 끝난 뒤 같은 시간 범위를 history로 다시 불러온다.
두 화면의 timestamp, value, quality를 비교한다.
이중화 시스템이면 SCADA server failover 중에도 같은 시험을 한다.

Live 화면에서는 10:00:02에 edge가 보이고, history로 다시 보면 10:00:07에 보일 수 있다. 이 차이가 정상 buffering 때문인지 설정 문제인지 결론을 남겨야 한다. “조금 늦게 보이는 것 같다”로 넘기면 장애 분석 때 다시 문제가 된다.

Timezone과 daylight saving을 따로 확인한다

Trend 문제처럼 보이지만 실제로는 표시 변환 문제인 경우가 많다.

현장에서 자주 보는 항목은 다음과 같다.

Historian이 UTC로 저장하는지, site local time으로 저장하는지 확인한다.
HMI client가 timestamp를 변환하는지, server 문자열을 그대로 표시하는지 확인한다.
허용된 운전 방식이라면 다른 timezone으로 설정된 engineering laptop에서도 표시를 확인한다.
여러 지역으로 report를 보내는 site는 daylight saving 규칙을 검토한다.
CSV export에는 timezone 또는 offset이 같이 나가도록 한다.

Daylight saving 변경 뒤 한 시간 차이가 나면 실제 공정 지연처럼 보일 수 있다. 감사나 품질 기록에 쓰는 trend라면 시간 기준이 파일 안에서 분명해야 한다.

Cursor 보간 방식이 원인 분석을 흐릴 수 있다

Trend control마다 cursor 값을 보여 주는 방식이 다르다. 가장 가까운 sample을 보여 주는 것도 있고, 두 sample 사이를 보간해서 보여 주는 것도 있다. 둘 다 쓸 수는 있지만, engineer가 그 차이를 알고 있어야 한다.

주의할 상황은 이런 것이다.

Digital signal인데 cursor 값이 0.5처럼 보인다.
Historian sample 주기가 느려서 빠른 event 두 개의 순서를 알 수 없다.
Compression 때문에 실제 disturbance 구간이 직선처럼 보인다.
Zoom level을 바꾸면 trend control이 다른 해상도의 데이터를 요청해서 cursor 값이 달라진다.

Event 순서가 중요한 분석에서는 compressed analog trend만 믿으면 안 된다. Alarm event, PLC sequence number, totalizer, 고해상도 historian point를 같이 봐야 한다.

Sample rate가 다른 pen을 같은 순간처럼 읽지 않는다

Fast status bit, 느린 analog value, 계산 KPI를 한 trend에 올려 놓고 cursor 한 줄로 모두 같은 순간의 값처럼 읽는 경우가 있다. 이때 해석이 틀어지기 쉽다.

Trend 화면은 목적별로 나누는 편이 안전하다.

Command, feedback, permissive, sequence state용 fast event pen.
Engineering unit과 scale이 명확한 process analog pen.
PLC real-time sample이 아닌 calculated value나 MES value는 별도 label 표시.
Recipe change, mode change, operator action은 event marker나 note로 표시.

Cursor가 sample 사이에 있을 때 tool이 지원한다면 sample age를 보여 주는 것이 좋다. 최소한 중요한 pen의 수집 주기는 화면 설명이나 운영 문서에 남긴다.

자주 나오는 고장 형태

Network outage 뒤 historian interface가 buffered data를 밀어 넣으면서 잘못된 receive time으로 저장한다.
HMI client는 workstation local time을 쓰고 server는 UTC를 쓴다.
Redundant SCADA server 두 대의 clock이 몇 초 이상 다르다.
PLC event array가 controller의 free-running RTC 위에서 돌면서 time sync가 아예 없다. 조용한 control LAN에서 NTP는 controller를 source 기준 수 ms 안에 잡아 준다. PTP(IEEE 1588)는 sub-microsecond까지 가지만 switch가 boundary clock이나 transparent clock일 때만 그렇다. 둘 다 없는 PLC는 하루에 1초 이상 drift하고, event log가 historian보다 1초 앞설 때까지 아무도 눈치채지 못한다.
Archive에는 millisecond가 있는데 export 파일에서 잘려 나간다.
Report query가 local date filter와 UTC archive timestamp를 섞어 쓴다.
Plot은 raw value를 쓰는데 cursor readout은 반올림된 값을 보여 준다.

이런 문제는 사고 뒤 기록을 맞춰 볼 때 발견되는 경우가 많다. 시운전 때 미리 시험해 두는 것이 훨씬 싸다.

현장을 떠나기 전에 시간 기준을 적어 둔다

중요 trend나 report마다 남길 만한 유일한 문서는 pen별로 몇 줄이면 된다. Timestamp 출처(live, history, alarm, export), 저장 기준(UTC 또는 site local), sample rate와 deadband, compression과 interpolation 방식, 그리고 live 표시 뒤 historian에서 조회 가능해질 때까지의 worst-case 지연. Millisecond 순서를 어디까지 믿어도 되는지도 한 줄 덧붙인다. 사고가 나면 누군가 바로 그 부분을 과하게 해석하기 때문이다.

길 필요는 없다. 이 문서는 다음 engineer가 — 아마 1년 뒤 새벽 2시의 당신이 — 깔끔해 보이는 trend line을 있는 그대로, 즉 뒤의 시계를 확인하기 전까지는 정밀한 시간 순서 기록이 아니라 그냥 표시일 뿐인 것으로 보게 하려고 존재한다.