가공 사이클 타임 데이터로 공정 병목 후보를 찾는 기준

가공시간을 왜 남길까요

같은 부품을 가공하는 장비 세 대가 있어도 하루 생산량만 보면 어디에서 흐름이 늦어졌는지 알기 어려워요. 한 장비는 절삭 시간이 길고, 다른 장비는 소재를 기다리며, 또 다른 장비는 작업 전환에서 시간이 늘어날 수 있어요. 가공 시작·완료 시각과 대기 구간을 같은 기준으로 남겨야 다음에 확인할 장비가 보여요.

스마트팩토리에서 설비 데이터 수집을 시작할 때도 장비 수보다 비교 기준을 먼저 정하는 편이 좋아요. 한국생산기술연구원의 공작기계 연구는 전력·공압 센서와 CNC 컨트롤러 데이터를 실시간으로 모아 Processing, Standby, Ready 같은 운영 상태를 구분했어요. 2026년 제조데이터 기반 디지털전환 실증 공고도 현장 데이터의 자동 수집·통합 저장, 실시간 공정 모니터링, 대시보드와 누적 이력 조회를 함께 제시해요. 여기서 가져올 핵심은 수치 하나가 아니라 상태와 시각을 이어서 보는 방식이에요.

결론부터 말하면 평균 사이클 타임이 가장 긴 장비를 곧바로 원인으로 단정하면 안 돼요. 품목, 작업 수량, 프로그램, 교대, 비가동 사유가 비슷한 구간끼리 비교하고, 반복해서 길어지는 단계가 병목 후보인지 현장 기록으로 확인해야 해요. 데이터는 원인을 자동 확정하는 답이 아니라 확인 순서를 좁히는 근거예요.

평균보다 분포를 봐요

먼저 공작기계마다 작업 ID, 품목, 가공 시작 시각, 완료 시각, 운전 상태, 마지막 수신 시각을 맞춰요. 사이클 타임은 완료 시각에서 시작 시각을 뺀 관측값으로 계산하되, 공구 교환이나 소재 대기처럼 공정 밖 시간을 포함했는지 표시해야 해요. PLC 신호와 실제 공정 의미가 다르면 계산은 정확해도 비교는 틀릴 수 있어요.

운영 질문	함께 볼 데이터	해석할 때 주의할 점
어느 장비의 시간이 자주 길어지나요?	장비별 중앙값·범위·반복 횟수	평균 한 번으로 원인을 정하지 않아요
가공 중 늘었나요, 대기에서 늘었나요?	시작·완료 시각과 운전 상태	정지 신호와 통신 공백을 나눠요
특정 품목에서만 달라지나요?	품목·프로그램·작업 수량	다른 조건의 장비를 바로 비교하지 않아요
지금 값이 최신인가요?	측정·수집·도착 시각	마지막 정상값을 현재값처럼 보지 않아요

한 번 긴 값보다 같은 조건에서 반복되는 분포가 더 중요해요. 가장 긴 장비가 앞 공정의 소재를 기다렸다면 그 장비 자체가 병목이 아닐 수 있어요. 작업자 기록, 프로그램 변경 시각, 계획 정지와 함께 보면 ‘느린 장비’가 아니라 ‘확인할 구간’을 고를 수 있어요.

장비에서 화면까지 이어요

Mitsubishi PLC의 가공 상태와 완료 신호를 읽어 외부로 보내려면 현장 연결 계층과 운영 계층을 나누는 편이 선명해요. EASY-LINK는 Mitsubishi MC 데이터를 수집해 HTTP API, MQTT, MySQL, Firebase로 전달하는 연결 역할을 맡아요. 한 장비의 몇 개 주소를 한 목적지로 보내는 범위라면 이 구성만으로 시작할 수 있어요.

현장 PLC 데이터를 수집해 HTTP API 등으로 전달하는 EASY-LINK의 공식 제품 이미지예요.

장비가 늘고 수집 주기, 저장 이력, 전달 성공·대기 상태와 대시보드를 한 기준으로 관리해야 한다면 EASY LOGGER를 함께 검토할 수 있어요. EASY LOGGER는 병목 원인을 자동 판정하거나 생산 계획을 대신 세우는 시스템이 아니에요. 현장 신호가 언제 들어왔고 어디까지 전달됐는지 확인하는 운영 계층이에요.

수집 주기와 저장 이력, 전달 상태와 대시보드를 관리하는 EASY LOGGER의 공식 제품 이미지예요.

가공 상태와 사이클 시각을 현장 주소에서 수집해 HTTP API와 운영 화면으로 잇는 흐름이에요.

HTTP API는 정해진 수신 서버가 요청과 응답을 관리할 때 이해하기 쉬워요. 여러 서비스가 같은 값을 받아야 하면 MQTT, 기간별 조회가 먼저면 MySQL, 기존 웹·모바일 데이터 경로가 있으면 Firebase도 비교할 수 있어요. 이 프로토콜 비교에서는 우열보다 수신 주체, 재시도, 중복 키, 보관 책임을 먼저 정해야 해요.

EASY LOGGER HTTP API 예제

아래 PLC, CONFIG, D100, D102와 값은 공식 형식을 설명하기 위한 예시예요. 예시 주소 맵에서는 가공 완료 상태 필드를 D100, 관측한 사이클 초 필드를 D102에 대응한다고 가정했어요. 실제 Mitsubishi PLC의 디바이스 주소, 데이터 타입과 배율은 현장 필드 주소 맵 및 수집 설정과 반드시 대조해야 해요.

{
  "D100": 1,
  "D102": 23.77,
  "write_callback_url": "http://LOGGER_HOST:8000/api/write/PLC/CONFIG"
}

이 POST JSON은 주소를 키로 쓰는 예시예요. Automatic Endpoint Preview에서 POST 대상과 callback endpoint를 확인하고, Runtime Status의 LAST POST와 LAST ERROR를 수신 서버의 최근 도착 시각과 함께 비교해요. HTTP 성공 응답만으로 외부 시스템의 저장이나 업무 처리가 끝났다고 단정하지 않아요.

WRITE CALLBACK 검증에서도 D100과 D102는 실제 가공 명령 주소가 아니라 분리된 테스트 주소에 대응해야 해요. PLC와 CONFIG 역시 예시 이름이며 실제 설정명과 주소 맵으로 바꿔요. body에는 wrapper를 덧붙이지 않고 주소와 값만 보내며, API Payload Log에서 Timestamp, endpoint와 JSON이 함께 남는지 확인해요.

POST http://LOGGER_HOST:8000/api/write/PLC/CONFIG

{
  "D100": 1,
  "D102": 23.77
}

• WRITE CALLBACK을 사용합니다.
• 테스트 주소만 사용합니다.
• 최소 권한만 부여합니다.
• 허용 주소 범위를 제한합니다.
• PLC 인터록을 확인합니다.
• 수동 복구 절차를 준비합니다.

WRITE CALLBACK은 측정값을 모으는 데 꼭 필요한 경로가 아니에요. 쓰기 검증이 필요할 때만 운영 주소와 분리하고, 응답·큐 상태를 PLC의 실제 동작 성공으로 해석하지 않아요.

화면은 세 질문에 답해요

대시보드에는 모든 디바이스를 올리기보다 세 질문을 먼저 둬요. 지금 데이터가 들어오는지, 같은 품목의 사이클 분포가 어느 장비에서 반복해서 길어지는지, 그 구간이 가공·대기·전환 중 어디인지예요. 현재값 옆에 마지막 수신 시각과 유효 상태를 두면 통신 공백을 장비 정지로 오해하지 않아요.

한 장비에서 주소와 시각을 맞춘 뒤 같은 조건의 여러 장비로 비교 범위를 넓히는 단계예요.

MES·CIM 같은 상위 시스템이 HTTP API 수신 인터페이스를 제공한다면 합의한 필드, 시각, 중복 키를 경계로 연계할 수 있어요. 공식 확인 범위는 MQTT·HTTP API·DB 인터페이스이며, 그 밖의 연계 방식은 이 글에서 주장하지 않아요. 수신 측 설정·개발과 업무 처리 성공은 상위 시스템에서 따로 검증해야 해요.

한 장비부터 확인해요

첫 단계는 공작기계 한 대와 완료 신호 한 개로 시작해요. PLC 모니터 값, 수집값, HTTP API payload와 대시보드 시각을 나란히 적고 정상 가공, 계획 정지, 통신 단절과 재연결을 차례로 확인해요. 한 품목의 반복 데이터가 안정되면 같은 조건의 두 번째 장비를 더하고, 차이가 반복될 때만 현장 기록과 함께 병목 후보를 검토해요.

기존의 Mitsubishi PLC 상위 시스템 연계 구조는 관련 글에서 비교할 수 있어요. 다른 수집 주제는 기술 블로그에서 살펴보고, 제품의 공식 연결 범위는 HT Automation 홈에서 확인할 수 있어요. 구매를 서두르기보다 PLC 모델, 읽을 주소, 품목 구분 기준과 목적지를 정리해 현장 연결 가능 여부부터 부담 없이 확인해 보세요.