설비 OEE 데이터가 실제 생산량과 다른 이유 | PLC 상태코드·미세정지 진단

10월 30일

2분 분량

최종 수정일: 11월 2일

현장 문제: OEE 대시보드는 높은데 생산량은 왜 부족할까?

PLC의 RUN 비트만 수집하면 설비가 자동운전 중이라는 사실은 알 수 있어도 실제 제품을 만들고 있는지, 잠깐 멈췄는지, 불량이 발생했는지는 구분하기 어렵습니다. 교대별 생산실적과 OEE 대시보드가 다르거나, 병목이 반복되는데 정지 원인이 집계되지 않는 현장은 먼저 데이터 정의부터 점검해야 합니다.

검색 질문: PLC 가동 신호만으로 OEE를 계산해도 될까? 1~3초 미세정지는 고장시간인가 속도손실인가? NG 재검사와 재투입 수량은 어떻게 계수해야 할까?

Technology ①: 가동률·성능·품질을 별도 계산

OEE = Availability × Performance × Quality입니다. Availability는 계획생산시간 대비 실제 운전시간, Performance는 이상적인 Cycle Time과 실제 생산수량을 기준으로 한 속도 손실, Quality는 총 생산수량 대비 양품수량으로 정의합니다. 교대 휴식, 계획정지, Changeover를 계획생산시간에 포함할지 사전에 합의해야 수치 비교가 가능합니다.

RUN 신호만으로는 생산수량, 양품수량, 정지 사유를 복원할 수 없습니다. 제품 완료 펄스와 검사 OK/NG 이벤트, Recipe, 설비 상태, 정지 사유를 동일한 타임스탬프와 제품 ID 기준으로 연계해야 합니다.

Technology ②: PLC 상태코드와 Edge 데이터 구조

PLC 상태를 예시로 AUTO_RUN, STARVED, BLOCKED, FAULT, MANUAL, CHANGEOVER, WAIT_MATERIAL, SAFETY_STOP으로 분리합니다. 상태 우선순위가 충돌하지 않도록 Fault와 Safety Stop의 판정 순서, 생산 이벤트의 중복 수집 방지, 전원 재기동 시 상태 복원 규칙을 정의합니다.

Engineering Concept: 설비 PLC(상태·알람·카운트) → 산업용 Edge(타임스탬프·이벤트 정규화·버퍼) → OEE 계산 서버(교대·품번·계획시간) → 생산기술·품질 대시보드. 통신 단절 중에는 Edge 버퍼에 저장하고 복구 시 이벤트 ID로 중복 반영을 막는 구조를 검토합니다.

정지시간 분류 임계값은 현장 Takt와 정지 원인 분석 목적에 따라 정합니다. 모든 미세정지를 일률적으로 고장으로 집계하면 Availability가 과소평가되고, 전부 무시하면 Performance 손실을 놓칠 수 있습니다.

Proof: FAT와 현장 데이터 대조 체크리스트

① PLC RUN=ON 상태에서 제품 배출이 없는 사례를 재현합니다. ② 계획정지/비계획정지 분모 정의를 확인합니다. ③ NG 재검사·재투입 수량이 이중 계수되지 않는지 검증합니다. ④ PLC·Edge·서버의 시각 동기 및 이벤트 누락을 검사합니다. ⑤ 작업자 수기 정지기록과 이벤트 로그를 교대별로 대조합니다.

⑥ Changeover와 자재 대기를 별도 상태로 표시합니다. ⑦ 네트워크 단절·복구 중 카운트 보존과 중복 전송을 검증합니다. ⑧ OEE 산식, 표준 CT, Good Count 기준을 FAT 승인 항목으로 문서화합니다. 목표 정확도와 데이터 수집 주기는 현장 실측 후 합의해야 합니다.

ROI 검토: 수치가 아니라 손실원인부터

OEE 자체가 올라갔다는 사실만으로 ROI를 산정하지 않습니다. 병목 설비의 미세정지 건수, 고장 복구시간, 품종교체시간, 불량 재작업시간의 기준선을 먼저 확보하고 개선 후 동일 조건으로 비교해야 합니다. 실제 생산량·수율·운영비를 확인하기 전에는 개선율이나 회수기간을 확정하지 않습니다.