예측 정비 시스템 구현

1엣지-클라우드 아키텍처

예측 정비 시스템은 실시간 처리가 필요한 엣지와 대용량 학습이 이루어지는 클라우드의 하이브리드 아키텍처로 구성됩니다. 엣지 레이어에서는 밀리초 단위 응답이 필요한 이상 탐지와 알람 생성을, 클라우드에서는 복잡한 ML 모델 학습과 장기 트렌드 분석을 수행합니다. 이 구조는 네트워크 대역폭을 절약하고, 오프라인 상황에서도 기본적인 진단 기능을 유지할 수 있게 합니다.

예측 정비 엣지-클라우드 아키텍처

CLOUD LAYER 지연: >100ms | 처리: 배치 | 접근: 웹

🖥️

모델 학습

(GPU)

📊

트렌드분석

(배치)

🗄️

데이터 레이크

(장기저장)

📈

대시보드

(시각화)

🌐 네트워크

FOG LAYER 지연: <100ms | 처리: 준실시간 | 서버/VM

⏱️

RUL 예측

(추론)

🔍

고장 분류

(추론)

💚

HI 계산

(집계)

EDGE LAYER 지연: <10ms | 처리: 실시간 | Jetson/Industrial PC

⚠️

이상 탐지

(경량AI)

🔔

알람 생성

(즉시)

💾

데이터 버퍼

(임시저장)

🔌

센서 연결

(OPC-UA)

엣지-클라우드 아키텍처 (수도코드)
# ============================================
# 엣지-클라우드 예측 정비 아키텍처
# ============================================

# 처리 계층 정의
처리계층 = {
    EDGE: 지연 < 10ms (Jetson, Industrial PC),
    FOG: 지연 < 100ms (서버, VM),
    CLOUD: 지연 > 100ms OK (GPU 클러스터)
}

# 엣지 노드 구성
엣지노드 = {
    노드ID, 플랜트ID, 설비ID목록,
    모델버전, 추론엔진: ONNX/TensorRT,
    버퍼크기: 512MB, 동기화주기: 60초
}

# --------------------------------------------
# 작업 유형별 계층 라우팅
# --------------------------------------------
기본_라우팅 = {
    이상탐지: EDGE,
    HI계산: EDGE,
    RUL예측: FOG,
    고장분류: FOG,
    모델학습: CLOUD,
    트렌드분석: CLOUD
}

함수 작업_라우팅(작업유형, 지연요구ms):
    기본계층 = 기본_라우팅[작업유형]

    만약 지연요구 < 10ms: 반환 EDGE
    만약 지연요구 < 100ms: 반환 min(기본계층, FOG)
    반환 기본계층

처리 계층	기능	지연 시간	하드웨어
Edge	이상 탐지, 알람	<10ms	Jetson, Industrial PC
Fog	RUL 예측, 분류	<100ms	서버, VM
Cloud	모델 학습, 분석	>100ms	GPU 클러스터

2실시간 스트리밍 파이프라인

수천 대의 설비에서 초당 수만 포인트의 데이터가 발생하는 환경에서는 실시간 스트리밍 처리가 필수입니다. Apache Kafka를 메시지 버스로 사용하고, Apache Flink 또는 Kafka Streams로 실시간 변환과 윈도잉을 수행합니다. 센서 데이터는 인메모리로 처리되며, 알람 조건을 만족하면 즉시 이벤트를 발행합니다.

실시간 스트리밍 파이프라인 (수도코드)
# ============================================
# 실시간 예측 정비 스트리밍 파이프라인
# ============================================

# 센서 데이터 구조
센서읽기 = {설비ID, 센서ID, 타임스탬프, 값, 품질}

# 파이프라인 설정
윈도우크기 = 60초
버퍼: 센서별 deque (최대 10000개)
이상_임계값 = 3.0 (z-score)

# --------------------------------------------
# 센서 데이터 수신 및 처리
# --------------------------------------------
비동기 함수 데이터_수신(센서읽기):
    키 = "{설비ID}_{센서ID}"

    # 버퍼에 추가
    만약 키가 없으면: 새 버퍼 생성
    버퍼[키].추가(센서읽기)

    # 윈도우 기반 처리
    윈도우 = 최근_윈도우_데이터(키)

    만약 샘플수 >= 100:
        특징 = 특징_계산(윈도우)

        # 실시간 이상 탐지
        만약 z_score > 임계값:
            알람_발생(설비ID, 특징)

# --------------------------------------------
# 윈도우 내 특징 계산
# --------------------------------------------
함수 특징_계산(윈도우):
    값들 = 윈도우의 모든 값
    평균 = mean(값들)
    표준편차 = std(값들)
    최신값 = 값들[-1]

    반환 {
        평균, 표준편차,
        z_score: |최신값-평균| / 표준편차,
        rms: sqrt(mean(값²)),
        peak: max(|값들|),
        crest_factor: peak / rms
    }

3모델 서빙 인프라

학습된 ML 모델을 프로덕션 환경에서 서빙하기 위한 인프라 설계입니다. 엣지에서는 ONNX Runtime이나 TensorRT를 사용하고, 클라우드에서는 Triton Inference Server나 TensorFlow Serving을 활용합니다. A/B 테스트와 카나리 배포를 통해 새 모델을 점진적으로 롤아웃합니다.

모델 서빙 인프라 (수도코드)
# ============================================
# 예측 정비 모델 서빙 시스템
# ============================================

# 모델 포맷: ONNX, TensorRT, OpenVINO, PyTorch, TF

# 모델 버전 정보
모델버전 = {모델ID, 버전, 포맷, 경로, 성능지표, 트래픽비율}

# --------------------------------------------
# 모델 배포 (카나리/블루-그린)
# --------------------------------------------
함수 모델_배포(모델, 전략="canary", 초기트래픽=10%):
    만약 전략 == "canary":
        # 카나리 배포: 점진적 트래픽 전환
        신규모델.트래픽 = 초기트래픽
        기존모델.트래픽 = 100 - 초기트래픽

    만약 전략 == "blue_green":
        # 블루-그린: 즉시 100% 전환
        신규모델.트래픽 = 100

    모델_레지스트리에 등록
    활성_모델 업데이트

# --------------------------------------------
# 추론 실행
# --------------------------------------------
함수 예측(모델ID, 특징):
    버전들 = 모델_레지스트리[모델ID]

    # 트래픽 비율에 따라 버전 선택
    선택된_모델 = 트래픽_라우팅(버전들)

    # 추론 실행 (ONNX Runtime 등)
    결과 = 선택된_모델.추론(특징)

    반환 {예측결과, 모델버전, 지연시간ms}

엣지 최적화 팁: ONNX 모델을 TensorRT로 변환하면 NVIDIA Jetson에서 2-3배 추론 속도 향상이 가능합니다. INT8 양자화를 적용하면 추가로 2배 속도 향상과 메모리 50% 절감 효과가 있습니다.

4데이터 레이크와 피처 스토어

대규모 예측 정비 시스템에서는 데이터 레이크에 원시 데이터를 저장하고, 피처 스토어를 통해 재사용 가능한 특징을 관리합니다. 피처 스토어는 온라인(실시간 서빙)과 오프라인(학습) 두 가지 경로를 제공하여 학습-서빙 불일치(Training-Serving Skew)를 방지합니다.

피처 스토어 통합 (수도코드)
# ============================================
# 예측 정비 피처 스토어
# ============================================

# 저장소 구성
온라인스토어: Redis, DynamoDB (실시간 서빙)
오프라인스토어: S3, Delta Lake (학습용)

# 피처 정의
피처정의 = {이름, 타입, 설명, 계산식, 윈도우크기}

# --------------------------------------------
# 피처 그룹 등록
# --------------------------------------------
함수 피처그룹_등록(그룹명, 피처목록, 엔티티키="equipment_id"):
    각 피처에 대해:
        피처_레지스트리["{그룹명}.{피처명}"] = 피처정의

# --------------------------------------------
# 온라인 피처 조회 (실시간 서빙용)
# --------------------------------------------
함수 온라인_피처_조회(설비ID, 피처명목록):
    피처값들 = {}
    각 피처명에 대해:
        키 = "pdm:features:{설비ID}:{피처명}"
        피처값들[피처명] = Redis.GET(키)
    반환 피처값들

# --------------------------------------------
# 오프라인 피처 조회 (학습용)
# --------------------------------------------
함수 과거_피처_조회(설비ID목록, 피처명목록, 시작, 종료):
    쿼리 = """
        SELECT 설비ID, 타임스탬프, {피처들}
        FROM pdm_feature_store
        WHERE 설비ID IN (목록)
        AND 타임스탬프 BETWEEN 시작 AND 종료
    """
    반환 쿼리_실행(쿼리)

피처 그룹	예시 피처	윈도우	갱신 주기
vibration_stats	rms, peak, kurtosis	1분	실시간
vibration_freq	dominant_freq, harmonics	10분	1분
health_index	weighted_hi, ae_hi	1시간	5분
operating_context	load, speed, temp	-	실시간

5알람 및 알림 시스템

예측 정비 결과를 운영자에게 전달하는 알람 시스템은 경보 피로(Alert Fatigue)를 방지하면서도 중요한 이벤트를 놓치지 않도록 설계해야 합니다. 우선순위 기반 에스컬레이션, 알람 집계, 근본 원인 연결 등의 기능이 필요합니다.

알람 관리 시스템 (수도코드)
# ============================================
# 예측 정비 알람 관리 시스템
# ============================================

# 심각도 등급
심각도 = {INFO: 1, WARNING: 2, CRITICAL: 3, EMERGENCY: 4}

# 알람 데이터 구조
알람 = {
    알람ID, 설비ID, 심각도, 유형,
    메시지, 타임스탬프, RUL, HI,
    권장조치[], 확인여부
}

# 중복 억제 윈도우: 15분

# --------------------------------------------
# 예측 결과 → 알람 변환
# --------------------------------------------
함수 예측_처리(설비ID, 예측결과):
    # RUL 기반 알람
    만약 RUL 존재:
        만약 RUL < 7일:
            반환 알람_생성(EMERGENCY, "failure_imminent",
                "RUL {RUL}일 - 즉시 점검 필요",
                조치: [긴급점검, 부품확보, 일정조정])

        만약 RUL < 30일:
            반환 알람_생성(WARNING, "rul_warning",
                "RUL {RUL}일 - 정비 계획 권장",
                조치: [스케줄검토, 재고확인])

    # Health Index 기반 알람
    만약 HI 존재:
        만약 HI < 0.3:
            반환 알람_생성(CRITICAL, "health_degraded",
                "설비 건강 지수 저하 (HI: {HI})")

    반환 없음

# --------------------------------------------
# 중복 알람 억제
# --------------------------------------------
함수 억제_확인(설비ID, 알람유형):
    키 = "{설비ID}_{알람유형}"
    만약 활성알람[키] 존재:
        만약 현재시간 - 기존알람.시간 < 15분:
            반환 True (억제)
    반환 False

6시스템 통합 아키텍처

예측 정비 시스템을 기존 IT/OT 인프라에 통합하는 전체 아키텍처입니다. OPC UA, MQTT, REST API를 통해 데이터를 수집하고, Kafka로 스트리밍 처리 후, ML 모델에서 추론을 수행합니다. 결과는 CMMS, MES, 대시보드로 전달됩니다.

시스템 통합 아키텍처 (수도코드)
# ============================================
# 예측 정비 시스템 통합 관리
# ============================================

# 시스템 구성요소 초기화
데이터_수집:
    OPC_UA_클라이언트(서버목록)
    MQTT_클라이언트(브로커목록)

스트리밍:
    Kafka_프로듀서
    스트림_처리기

ML_레이어:
    모델_서버
    피처_스토어(온라인: Redis, 오프라인: Delta Lake)

출력_레이어:
    알람_시스템
    CMMS_클라이언트
    대시보드_퍼블리셔

# --------------------------------------------
# 전체 파이프라인 실행
# --------------------------------------------
비동기 함수 파이프라인_실행(설비ID, 센서데이터):
    # Step 1: 피처 조회
    피처 = 피처스토어.온라인_조회(설비ID,
        [rms, peak, kurtosis, temp, load])

    # Step 2: 모델 추론
    예측 = {
        이상탐지: 모델서버.예측('anomaly_detector', 피처),
        RUL: 모델서버.예측('rul_predictor', 피처),
        HI: 모델서버.예측('health_index', 피처)
    }

    # Step 3: 알람 처리
    알람 = 알람시스템.예측_처리(설비ID, 예측)

    # Step 4: CMMS 작업 지시 생성 (필요시)
    만약 알람 AND 심각도 >= WARNING:
        CMMS.작업지시_생성(설비ID, 알람)

    # Step 5: 대시보드 업데이트
    대시보드.발행({설비ID, 예측, 알람})

주의: 실시간 제어 시스템(Safety PLC)과 예측 정비 시스템은 분리해야 합니다. 예측 정비의 오류가 설비 정지나 안전 문제로 이어지지 않도록 적절한 격리와 권한 설계가 필요합니다.