설비 예지정비 및 Vision 품질검사 · 중간 발표01 / 11
PROJECT 41 · SMART FACTORY AI · MID-TERM REVIEW

설비 예지정비
+ Vision 품질검사

팀장 이수현 유현하 임현 박성민 심정화
01 개요
베어링 마모→ 진동 증가→ 조립 정밀도 저하→ 제품 불량
사용자 01 · 설비 엔지니어

“이 설비를 언제
정비해야 하는가?”

→ Health Index와 4단계 설비 상태
사용자 02 · 품질 담당자

“불량이 늘어난 원인은
무엇인가?”

→ 설비-품질 상관관계와 시차
사용자 03 · 라인 운영자

“언제 라인을
멈춰야 하는가?”

→ 위험 단계 자동 정지(Interlock)
설비 데이터(OT)와 품질 데이터(IT)가 따로 관찰되어
불량이 쌓인 뒤에야 원인을 찾고 라인을 멈춥니다.
01 개요

네 모듈을 하나의 흐름으로 묶습니다.

MODULE 01

설비 시뮬레이터

Fault Level 0~10에 따라 진동과 불량률이 함께 오르고 제품 이미지를 만든다.

MODULE 02

예지정비 (PdM)

FFT·특징 추출 → 이상 탐지 → Health Index 0~100, 4단계 상태.

MODULE 03

Vision 품질검사

스크래치 · 찍힘 · 이물질 3종 판정과 Grad-CAM 판단 근거.

MODULE 04

통합 관제

실시간 Dashboard, 설비-품질 상관분석, Alarm, 위험 시 자동 정지.

PdM F1 ≥ 0.80 추론 ≤ 100 ms Vision mAP@0.5 ≥ 0.80 ≥ 20 FPS (CPU) 갱신 ≤ 5 s
최종 목표 — 설비 이상(원인)과 제품 불량(결과)을 하나의 흐름으로 연결해 보여 주고
위험 단계에서 라인을 스스로 멈추는 시스템
02 진행

AI 에이전트를 역할과 권한이 나뉜
하나의 조직으로 운영했습니다.

팀 (사람)목표 · 판단 기준 · 운영 규칙
조율 AI · Claude Code실행 AI 배치 · 교체 · CI 확인 후 merge
리뷰 AI · GPT다른 모델 · 읽기 전용
task 배정 · PR 제출
3D 시뮬레이터실행 AI
예지보전실행 AI
비전 검사실행 AI
관제 · 제어실행 AI
통합 검증실행 AI
저장소 1개 · task 1개 · 단계마다 새 세션 · merge 권한 없음  ·  모듈 사이는 코드가 아닌 계약(MQTT Topic · JSON Schema)으로만 연결
95PR
아키텍처 리뷰 → spec → plan → 구현
모두 CI 통과 확인 후 merge
규칙 01

merge는 한 곳에서만

실행 AI는 PR까지만. 누구도 자기 결과를 스스로 승인하지 않습니다.

규칙 02

기억 대신 파일로

단계마다 새 AI, 이전 결과는 merge된 문서로만 넘깁니다.

규칙 03

다른 모델이 교차 검토

설계의 모든 단계를 GPT가 읽기 전용으로 리뷰합니다.

02 진행

AI의 결과와 지적을 그대로 반영하지 않고
근거로 판정했습니다.

GPT 교차 리뷰 14회 · 지적 156건의 판정 결과 3건 중 1건은 그대로 따르지 않았습니다
반영 107 부분 반영 34 미반영 15
판정 예시 · 예지보전 spec 리뷰
부분 반영

“Health Index 목표식이 앞서 내린 결정과 다릅니다”

차이는 사실이었습니다. 두 식을 같은 데이터로 직접 구현해 비교하니 기존 식이 더 정확했습니다.

기존 식 F1 1.000지적된 식 0.966
→ 기존 식 유지, 앞선 결정 기록을 정정
발생한 문제 → 재발 방지 규칙
사고 01

병렬 AI의 임시 파일 충돌

→ AI별 전용 폴더, 자기 프로세스만 종료

사고 02

다른 저장소 침범

→ 다른 저장소는 읽기만 허용

사고 03

성능 측정 간섭

→ 측정은 단독으로, 직전에 허가

검증 기준(테스트 기대값)은 AI가 바꿀 수 없게 막았고 모듈을 가로지르는 결정 31건은 선택지 · 결정 · 이유로 기록했습니다.
02 진행

시나리오 전체가 자동 검증을 통과했습니다.

Dashboard 정상 상태: RUNNING, NORMAL, Health Index 99
Fault 0 · NORMAL · HI 99 · RUNNING
Dashboard 위험 상태: CRITICAL, Interlock으로 STOPPED
Fault 10 · CRITICAL · Interlock → STOPPED
1.000/ 0.80
PdM 이진 F1
50.5ms / 100
AI 판정 최대 지연 (통합 환경)
3.9s / 5
Dashboard 반영 최댓값
53/53× 2
통합 E2E 검증
데이터
  • 진동 10 kHz · 3축 → 1초 윈도우, 0.5초 간격 (Nyquist 5 kHz)
  • Fault Level ↑ → BPFO 107.5 Hz · BPFI 162.5 Hz 성분 ↑
  • 특징 30개 — 시간 5종 + 주파수 5종 × 3축
  • 정답(Ground Truth)은 학습·평가에만, 모델 입력과 분리

위험 판정 → Conveyor STOP 최대 47 ms · 설비-품질 상관계수(Pearson · Spearman)와 lag별 곡선을 Dashboard에 실시간 표시
Vision은 흐름을 먼저 완성하려고 정답 전달 방식으로 연결해 두었고 모델은 다음 단계에서 도입합니다.

03 시뮬레이터

요구사항은 Gazebo였지만
Three.js로 만들었습니다.

과제 출제자의 승인을 받은 결정입니다.

Three.js 가상 공장 화면: 컨베이어 RUNNING, Fault Level 0
Three.js 가상 공장 — 브라우저만 열면 실행
이유 01

핵심 데이터가 물리 엔진에서 나오지 않는다

베어링 진동은 Python 수식(Mathematical Fault Injection)으로 합성합니다. 물리 엔진을 띄워도 옆에서 numpy로 진동을 만들어야 합니다.

이유 02

실행 환경이 맥북 브라우저다

Gazebo는 Linux · ROS 2에 묶여 Apple Silicon에서 불안정하고 Isaac Sim은 NVIDIA GPU가 필수입니다.

이유 03

배포가 단순해진다

컨테이너 하나가 server · web · 3D 모델을 서빙합니다. Gazebo였다면 ROS 2 브리지, MQTT 변환, 화면 전달 계층이 더 필요합니다.

포기한 것은 물리적 정확성이고 시나리오에 필요한 Fault Level · 진동 · 불량 · 이미지 · MQTT · Start/Stop은 모두 갖췄습니다.
다른 모듈은 MQTT 계약만 보므로, 시뮬레이터는 교체 가능한 Adapter입니다.
04 평가

모델 구성과 평가 방법

관리도와 Autoencoder는 모두 과제 요구사항이고, 결합 방식이 단독보다 나은지를 관리도와 비교해 검증합니다.

예지정비
구현됨
비교 기준

통계적 관리도

Hotelling T², 정상 데이터 99% 분위를 경계로 사용

적용 모델

Autoencoder + 결합 점수

정상 데이터로만 학습, 관리도와 결합(max) → 보정 → Health Index

평가 방법
  • Precision · Recall · F1 · Latency 비교 표
  • 학습에 없던 조건의 test — 다른 RPM, 잡음 증가, 축 불균형 · 헐거움
  • 5회 이상 반복 측정, 하드웨어 사양 명시
Vision
추후 도입
비교 기준

EfficientDet-D0

시뮬레이터 이미지로 파인튜닝

적용 모델

YOLOv8n + Domain Randomization

조명 · 각도 · 배경을 바꾼 학습 데이터, Grad-CAM은 백본 마지막 Conv Layer

평가 방법
  • mAP@0.5 ≥ 0.80 · ≥ 20 FPS (CPU, 전처리 포함, 100장 평균)
  • test는 학습과 다른 조명 · 각도 · 배경
  • Grad-CAM 정상 · 불량 비교 해석
지금 F1은 1.000(관리도 1.000 · AE 0.9997)입니다. test가 학습과 같은 설정에서 seed만 바꾼 데이터라 너무 쉽습니다.
과제 요구대로 다른 시나리오의 test를 따로 만들어 어려운 조건에서도 차이와 근거를 설명할 수 있어야 결합 방식을 쓸 근거가 됩니다.
05 계획

남은 기능 구현 · 성능 검증 · 서비스 통합

기능성능 검증서비스 통합 최종 발표 11/26까지 5주
W110/22 – 10/28
  • 검증PdM 별도 시나리오 test 생성
  • 통합사람 시연 확인 2건
  • 기능Vision 데이터 생성 시작
W210/29 – 11/04
  • 검증관리도 / AE 비교, 5회 반복
  • 기능정상 3,000 · 유형별 1,000장, 자동 라벨
  • 기능비교 기준 · 적용 모델 학습
W311/05 – 11/11
  • 검증Vision mAP · FPS 평가
  • 기능Grad-CAM
  • 통합Vision 계약 변경 · Python 3.11 정렬
W411/12 – 11/18
  • 통합정답 전달 → Vision 모델 교체
  • 기능불량 이력 DB · Dashboard Grad-CAM
  • 통합E2E 재검증
W511/19 – 11/26
  • docs/ 정리 · 성능 문서
  • 시연 리허설
  • 11/26 최종 발표
05 계획

역할분담

이수현팀장
통합 · 계약
  • 일정 · 판단 기준 승인
  • Vision 계약 변경
  • 통합 조합 · E2E 재검증
유현하
시뮬레이터 · 데이터
  • PdM 별도 시나리오 데이터
  • Vision Domain Randomization
  • 자동 라벨링
임현
예지정비
  • 관리도 / AE 성능 비교
  • 5회 반복 측정
  • Health Index 가중치 문서
박성민
Vision
  • EfficientDet / YOLOv8 학습
  • mAP · FPS 평가
  • Grad-CAM 해석
심정화
통합 관제
  • 불량 이력 DB 저장
  • Dashboard Grad-CAM 표시
  • 상관분석 문서 · 시연 체크리스트
각자 맡은 모듈의 기준과 판단은 사람이, 구현과 반복은 Agent가 — 착수 때의 원칙을 그대로 유지합니다.
06 점검

지금까지 만든 것, 남은 위험

설비 상태 악화✓→ 진동 이상 감지✓→ 불량을 Vision으로 확인△→ 하나의 흐름으로 연결✓→ 위험 기준에서 라인 정지 ✓

△ 흐름은 동작, Vision 모델은 도입 예정

위험 01 · 평가 신뢰도

같은 시나리오 test라 F1이 과대평가될 수 있다

→ 별도 시나리오 test, 5회 반복 측정
위험 02 · Vision 일정

데이터 생성 · 학습 · 통합이 한 번에 남았고 CPU 20 FPS가 필요하다

→ 경량 모델부터, 통합 경로는 이미 동작
위험 03 · 사람 검증 미완료

지금은 자동 검증만 통과한 상태다

→ 시연 체크리스트로 직접 확인
위험 04 · 개발 환경 차이

과제는 Ubuntu 22.04 · Python ≤ 3.11, 현재 이미지는 Python 3.12

→ W3에 Python 3.11로 정렬 후 재검증
← → · Space 이동  ·  F 전체화면