실무

AI 스마트 플랜트 모니터링 플랫폼

Data Engineer & Tech Lead · 2024 · 4 min read 읽기

플랜트 설비(압축기·터빈)의 센서 46개 태그를 폐쇄망 PI 시스템에서 수집·정규화하고, 외부에서 개발된 AI 모델(진단·예측·추천)을 Zeppelin 기반 이관 파이프라인에 통합해 웹으로 실시간 시각화한 설비 모니터링 시스템을 구축하고 2개 고객사 실증을 수행

Overview

석유화학·가스 분야 플랜트 고객사를 대상으로 한 설비 모니터링 시스템의 데이터 엔지니어링과 시스템 통합을 담당했습니다. 기존 폐쇄망에서 압축기·터빈 설비의 실시간 센서 데이터를 수집하던 PI 시스템에서 데이터를 수집하여 MS SQL에 적재하고, 외부에서 개발된 진단·예측·추천 AI 모델을 실제 운영 파이프라인에 통합해 결과를 웹으로 시각화하는 구조입니다. 수집 데이터가 여러 모델에서 공용으로 쓰여 데이터 정합성 확보가 핵심 요구였습니다.

System Architecture

AI 스마트 플랜트 시스템 구성도 — WAS(Tomcat)·PostgreSQL·Apache Zeppelin 기반 AI 모델 통합, PI 시스템 원본 데이터 수집, MS SQL 적재 흐름

Constraints

폐쇄망 + 보안 이관 — 외부 개발 측은 실제 센서 매핑을 알 수 없고 현장에서만 확인 가능
서버로 쓸 PC 사양·여력이 낮은 현장 하드웨어에서 운영
원본 데이터를 여러 AI 모델이 공용 — 데이터 정합성 확보 필수
이상 데이터 극소수 — 클래스 불균형 (정상/이상 판별을 위한 패턴)
고객사별로 데이터 확보 조건이 상이 (실데이터 반출 가능/불가)

Tech Stack

Python (pymssql / psycopg2)
Apache Zeppelin
MSSQL (원본 1차 적재)
PostgreSQL (앱 RDB)
PI System (실시간 수집원)
librosa (시계열 프레이밍) / SciPy (savgol 스무딩)
TensorFlow (.h5 진단·예측·추천 모델)

Learnings

AI 모델을 만든 것과, 그 모델을 실제 운영 파이프라인에 통합해 돌아가게 하는 것은 다른 일 — 통합·운영 관점에서 데이터 정합성과 정규화 기준(calibration range)을 잡는 것이 핵심이었다
기술 선택은 이상적 스택이 아니라 현장 제약(저사양 폐쇄망)에서 결정해야 한다 — Airflow 대신 Zeppelin을 고른 이유이자, 데이터가 커지면 Airflow로 가야 한다는 경계도 함께 알아야 한다
정상/이상 데이터 불균형은 모델 성능의 근본 제약 — residuals_max×ratio 같은 임계 보정은 대증적 대응이고, 뿌리는 정상·이상 데이터를 충분한 양으로 확보하지 못한 데 있다 (프로젝트 기간 내 미해결 과제로 남김)
고객사별로 데이터 확보 조건이 달라 검증 방식도 달라졌다 — 실데이터 반출이 불가한 고객사는 센서 calibration range 기반으로 합성 테스트 데이터를 생성해 검증했는데, 동작 검증엔 충분했지만 이상 탐지 성능 검증에는 한계가 있었다

Problem

AI 모델 자체는 외부 연구팀이 개발했지만, 그 모델이 실제 설비 데이터로 돌아가려면 폐쇄망·보안 이관 환경에서 센서 데이터를 수집·정규화해 모델 입력 형태로 맞추는 파이프라인이 필요했습니다. 외부(개발 측)에서는 센서 태그의 가상 ID만 알고 실제 매핑은 현장에서만 확인 가능했으며, 원본 데이터는 여러 모델이 공용으로 사용해 정합성이 중요했습니다. 또한 이상 데이터가 정상 데이터보다 극소수라 모델이 정상/이상 패턴을 명확히 가르지 못하는 데이터 불균형 문제가 있었습니다.

Approach

외부에서 부여한 가상 센서 ID를 현장에서 확인된 실제 ID로 Python 폴링 스크립트 안에서 매핑해 PI 시스템의 raw 데이터를 수집했습니다. 원본은 공용·정합성이 중요해 기존 MSSQL에 1차 적재하고, 앱이 쓰는 RDB는 PostgreSQL로 역할을 분리했습니다. 각 센서를 calibration range(min/max) 기준 min-max로 정규화하고, librosa의 프레이밍으로 시계열을 슬라이딩 윈도우 시퀀스로 만들어 AI 모델 입력 Shape으로 reshape했습니다. 진단(재구성 오차 기반 이상탐지)·예측·추천 모델을 순차 적용하고, 결과를 PostgreSQL에 적재해 웹에서 46개 태그를 설비 도면 위에 실시간 시각화했습니다. 배치 주기는 Zeppelin의 Cron 기능으로 운영했습니다.

Key Decisions

저장소 역할 분리 — 원본은 MSSQL 1차 적재, 앱용 RDB는 PostgreSQL

Reasoning:

원본은 여러 모델이 공용으로 쓰고 데이터 정합성이 중요해 기존 MSSQL에 1차 적재하고, 앱이 조회·갱신하는 RDB는 PostgreSQL로 분리했습니다. PostgreSQL은 라이선스 부담 없는 오픈소스라 도입·유지가 정리되고, 사양이 낮은 현장 서버에서도 가볍게 동작하면서 워크로드에 충분했습니다.

Alternatives considered:

단일 DB로 원본·앱 데이터 통합 관리
상용 RDB 확장

데이터 처리·배치 도구로 Apache Zeppelin 채택 (Airflow 대신)

Reasoning:

Airflow도 후보였지만 서버로 쓸 수 있는 PC 사양이 낮은 폐쇄망 현장이었고, Airflow는 스케줄러·웹서버·메타DB·워커 등 구성요소가 많아 이 하드웨어에서 운영 부담이 컸습니다. Zeppelin은 이미 웹 시스템을 구성하는 모듈이라 별도 인프라 추가 없이 노트 하나에서 수집·가공·검증을 한 번에 처리할 수 있어, 이 규모·제약에는 Zeppelin이 적정 기술이라 판단했습니다. 다만 데이터량이 커지고 DAG 의존성이 복잡해지면 Airflow로 가는 것이 맞다고 판단했습니다.

Alternatives considered:

Apache Airflow (구성요소가 많아 저사양 폐쇄망 현장 운영 부담)
커스텀 Cron 스크립트

폐쇄망 제약 → 가상 센서 ID를 현장 실제 ID로 매핑하는 방식 채택

Reasoning:

보안 이관 환경상 외부 개발 측은 실제 센서 매핑을 알 수 없어, 부여한 가상 ID를 현장에서 확인된 실제 ID로 Python 폴링 스크립트 안에서 매핑해 수집하도록 했습니다.

Alternatives considered:

현장에 개발 인력 상주

데이터 불균형 대응 — residuals_max × ratio(1.5)로 이상탐지 임계값(UCL) 설정

Reasoning:

정상 데이터만 많고 이상 데이터가 극소수라 모델이 경계를 명확히 못 가렸습니다. 재구성 오차(autoencoder 방식)로 anomaly_score = mean(|입력 − 예측|)를 구하고, UCL = residuals_max × 1.5로 임계값을 정상 쪽에서 다소 올려 정상을 이상으로 오분류하는 것을 최소화했습니다(residuals_max는 모델·태그마다 다름).

Alternatives considered:

고정 임계값

Result & Impact

압축기·터빈 46개 태그

센서 규모
진단·예측·추천 3종 (.h5) 통합

AI 모델
현재시각 기준 30분 후까지 1분 단위 예측, 그래프 1시간 단위 샘플링

예측 / 모니터링

외부에서 개발된 진단·예측·추천 AI 모델을 폐쇄망 현장의 실제 설비 데이터 파이프라인에 통합해 웹에서 실시간으로 시각화하는 시스템을 완성하고, 2개 고객사 대상 실증(2024.12)을 수행했습니다. 46개 태그 전부 정상 시나리오와 일부 이상 시나리오로 진단·예측·추천 흐름을 검증했습니다. 이상 상태는 설비 도면 위 태그를 기준정보(LL/L/Normal/H/HH) 대비 초록/노랑/빨강으로 시각화하고, Rule base 테이블로 태그 조합 기반 트러블슈팅을 지원합니다.

전체 프로젝트