탱크에 있어 본 적 없는 920 리터
데이 탱크의 레벨 transmitter는 380 mm를 가리키고, SCADA 재고 태그는 1,470 L라고 표시한다. 운전자가 직접 dip을 재 보면 이 탱크는 횡형이고 실제 값은 550 L에 가깝다. 아무도 범위를 잘못 넣지 않았다. transmitter도 멀쩡하고, 스케일링도 맞고, 4–20 mA 루프도 시운전 때 확인했다. 문제는 누군가 레벨에서 부피로 가는 변환을 직선으로 잡았다는 것이다. 횡형 원통은 직선이 아니다.
문제는 한 문장으로 끝난다. 레벨은 높이고, 부피는 형상이다. 둘이 비례하는 경우는 딱 하나, 바닥이 평평하고 디시헤드도 내부 구조물도 없는 수직 원통뿐이다. 현장의 나머지 탱크는 전부 테이블이 필요하다.
기하가 실제로 만드는 오차
실제 용기로 계산해 보자. 직경 2.5 m, 길이 6 m, 횡형, 헤드는 일단 무시. 동체 부피는 약 29.4 m³다.
직경의 5%, 즉 바닥에서 125 mm까지 채운다. 젖은 단면은 원의 세그먼트다.
A = r²·acos((r−h)/r) − (r−h)·√(2rh − h²)
V = A · L
계산하면 0.55 m³, **탱크의 1.9%**다. 선형 스케일이었다면 5%, 즉 1.47 m³라고 보고했을 것이다. 산수만으로 920 리터를 만들어 낸 셈이다. 탱크 위쪽에서는 부호가 뒤집힌다. 레벨 95%가 부피로는 98.1%다. 그래서 이 탱크는 재고 화면이 알려 주는 것보다 먼저 넘친다.
중간 구간이 함정이다. 여기서는 선형 스케일도 멀쩡해 보여서 다들 그대로 둔다. 절반 찼을 때 세그먼트 공식과 직선은 정확히 일치한다. 즉 이 태그는 모두가 확인하는 바로 그 한 점에서 완벽하게 검증되고, 정작 중요한 두 지점 — 거의 빈 상태와 거의 찬 상태 — 에서 가장 크게 틀린다.
strapping table, 그리고 간격을 균일하게 두면 안 되는 이유
strapping table은 실제 탱크 검정에서 나온 (레벨, 부피) 쌍의 목록일 뿐이다. API MPMS Chapter 2.2A의 수동 strapping, 수직 원통 탱크라면 같은 목적의 ISO 7507-1, 형상이 특이하면 액체 검정으로 만든다. 점 사이는 보간한다. 디시헤드가 달린 제작 용기라면 공식보다 실측 테이블이 낫다. 2:1 타원형 헤드, 경사 바닥, 내부 가열 코일, 흡입 웰이 전부 실측값에는 들어 있고 당신의 수식에는 하나도 없기 때문이다.
구현할 때 끌리는 방식은 간격을 균일하게 잡는 것이다. 100 mm마다 한 점을 두면 정수 나눗셈으로 인덱싱해서 탐색을 건너뛸 수 있다. 일반론으로는 맞는 감각인데, 횡형 탱크 바닥에서는 틀린다. 이유는 이렇다. 부피 곡선의 기울기는 현(chord)의 폭이고, 바닥 근처에서 이 값은 √h로 간다. h → 0에서 미분값이 발산하고, 선형 보간 오차는 그 곡률에 비례한다.
같은 2.5 m 탱크, 100 mm 간격 테이블로 계산한 숫자다.
| 레벨 | 실제 부피 | 100 mm 테이블 보간값 | 오차 |
|---|---|---|---|
| 50 mm | 141 L | 198 L | +40% |
| 1,250 mm | 14,726 L | 14,726 L | ~0 |
동체 중앙에서는 보간이 사실상 정확하다. 첫 구간에서는 40% 틀린다. 그러니 곡률이 있는 곳에 점을 몰아넣어야 한다. 아래 10%와 위 10% 구간은 10–25 mm 간격, 직선 동체 구간은 100 mm 간격. 대신 값싼 인덱싱 기법은 포기하고 탐색을 해야 하는데, 60–120점짜리 테이블이면 비교 몇 번이고 그 스캔에는 이미 더 큰 부하가 있다. 정확도를 택하는 게 맞다.
테이블 규칙 중 타협하지 않는 두 가지가 더 있다.
- 외삽하지 말고 클램프한다. 첫 점 아래와 마지막 점 위에서는 끝점 값을 유지하고 quality를 bad로 두거나 "레벨이 테이블 범위 밖" 플래그를 올린다. √h 곡선을 양 끝 밖으로 외삽하면 그럴듯하지만 틀린 숫자가 나온다.
- 테이블의 기준점은 검정에 쓴 datum이다. 보통 탱크 바닥이나 dip plate이지, transmitter의 영점이 아니다. 레이더가 플랜지에서의 거리를 읽는다면 기준 높이에서 거리를 빼야 하고, 그 오프셋은 문서화된 한 곳에만 있어야 한다. 테이블 안에 슬쩍 녹여 넣으면 안 된다.
계산을 어디에 둘 것인가
후보는 셋이고, 답은 "입력하기 편한 곳"이 아니다.
부피를 자동 로직이 쓴다면 PLC나 RTU에 둔다. 펌프 permissive, 배치 컷오프, 이송 인터록, 높이가 아니라 부피 기준의 고레벨 트립 같은 것들이다. 제어 로직이 네트워크에서 떨어져 나갈 수 있는 상위 시스템의 계산값에 의존해서는 안 된다.
부피가 순전히 표시·보고·재고용이라면 SCADA에 둔다. 대부분의 SCADA 제품에 lookup/보간 함수나 수식 태그가 있고, 원래 이런 용도다. 100점짜리 테이블을 PLC에 넣으면 retain 메모리를 먹고 재검정 후 수정도 고통스럽지만, SCADA lookup 편집은 감사 기록이 남는 5분짜리 작업이다.
양쪽 모두에 두지는 말자. 전형적인 사고는 이렇다. PLC는 인터록용으로 부피를 계산하고, SCADA는 raw 레벨에서 조금 다른 버전의 테이블로 자기 부피를 계산한다. 1년 동안은 값이 맞다가 수리 후 탱크를 재검정하면서 한쪽만 갱신되고, 그때부터 trend와 트립이 수백 리터씩 어긋나는데 원인은 눈에 안 보인다.
운영에 쓰는 값이라면 히스토리언 계산 태그로 만드는 것도 피한다. 히스토리언 계산은 저장된 데이터 위에서 돌기 때문에 그 데이터의 결측, 압축 deadband, 늦게 도착한 값을 그대로 물려받는다. 월간 재고 보고서라면 괜찮지만 운전자 화면에 올라가는 값으로는 부적합하다.
밀도 함정
레벨이 정수압(DP) transmitter에서 온다면, 당신이 재고 있는 것은 높이가 아니다. 헤드 압력이다.
h = P / (ρ·g)
기기는 당신이 설정해 둔 고정 밀도로 이 값을 높이로 환산한다. 800 kg/m³로 저장하던 제품을 810짜리 배치로 받으면 전 구간에서 지시 레벨이 1.25% 낮게 나오고, 그 값이 strapping table을 통과해서 부피 오차로 나온다. 테이블을 아무리 정밀하게 만들어도 못 잡는다. 온도도 같은 이야기다. 제품이 데워지면 밀도가 떨어지고, 같은 질량에 대한 정수압 헤드는 그대로인데 레벨 태그만 슬금슬금 올라간다. 물리적으로는 아무것도 움직이지 않았는데도.
재고 수치가 실제로 중요하다면 여기서 길이 갈린다.
- 부피만 필요하고 제품 밀도가 안정적인 경우 — 정수압 + strapping table로 충분하다. 대신 설정한 밀도를 태그 설명에 적어 두자. 다음 사람이 이 가정의 존재를 알아야 한다.
- 제품 등급이 바뀌거나 온도 변화 폭이 큰 경우 — 무게가 아니라 기하를 재는 레벨 기술로 간다. 가이드 웨이브 레이더나 비접촉 레이더는 밀도와 무관하다.
- 질량이나 표준 부피가 필요한 경우 — 이건 다른 작업이다. 총 실측 부피를 15 °C 기준 표준 부피로 보정하려면 API MPMS Chapter 11.1(ASTM D1250)의 부피보정계수(VCF)에, 탱크 쉘의 열팽창, 부유식 지붕이 있다면 지붕 보정까지 필요하고, 이 계산들은 API MPMS Chapter 12.1에 정리돼 있다. VCF 다항식을 래더 로직으로 다시 짜지 말자. 감사를 받는 flow computer나 탱크 재고 패키지의 몫이다.
거래 계량(custody transfer)이라면 논의 자체가 달라진다. 레벨과 온도를 어떻게 측정할지부터 ISO 4266과 API 표준이 규정하고, SCADA가 계산한 재고 값은 모니터링 보조 수단이지 전표가 아니다.
시운전에서 확인하는 법
한 점에서 수동 dip과 비교하는 것으로는 아무것도 증명되지 않는다. 앞에서 봤듯 탱크 중앙은 어떤 방법을 써도 값이 맞는 구간이다. 어려운 곳에서 확인해야 한다.
- 거의 빈 상태, 테이블 최하단 점 바로 위. 선형 스케일과 성긴 테이블이 무너지는 구간이고, strapping table 자체의 정확도도 여기서 가장 나쁘다.
- 거의 찬 상태, 헤드가 있는 탱크라면 동체 접선(tangent line) 위쪽.
- 절대값이 아니라 이송량으로 비교한다. 계량된 탱크로리 하역이나 교정된 유량계 기준의 정해진 이송을 넣고 부피 태그의 변화량을 비교한다. delta 부피는 datum과 오프셋 오차를 상쇄하고, 당신이 실제로 작성한 부분인 테이블의 형상을 검증한다.
히스토리언 쪽에서 자주 놓치는 것 하나. 부피 태그의 deadband는 레벨 백분율이 아니라 부피 단위로 잡는다. 횡형 탱크 바닥 근처에서 5 mm 레벨 변화는 몇 리터지만, 동체 중앙에서는 100 리터다. 레벨 백분율 deadband를 쓰면 중앙 구간에서는 이벤트가 폭주하고, 거의 빈 구간에서는 실제 움직임을 놓친다. 같은 이유로 고레벨 알람은 레벨 태그에 그대로 두는 게 맞다. 알람이 막으려는 것은 넘침이고 그건 높이 문제인데, 파생 부피에 붙이면 센서와 트립 사이에 계산 단계만 하나 더 끼워 넣는 셈이다.
숫자가 그래도 안 맞으면 다음으로 볼 것은 탱크 기울기다. 10년 동안 15 mm 가라앉은 용기는 중앙 구간에 영향이 오기 한참 전에 strapping table의 바닥부터 무효로 만든다. 해결책은 재검정뿐이다. 월말에 아무리 급해도 SCADA 수식에 보정 계수를 끼워 넣는 것으로는 안 된다.