블로그›2026. 8. 17.

스마트팩토리 CCP 이벤트 상태를 LS XGT와 MySQL로 MES·CIM에 잇는 기준

먼저 결론부터 볼게요

스마트팩토리에서 CCP 이벤트 상태를 상위 시스템에 넘길 때는 통신 방식보다 이벤트의 의미와 시각을 먼저 맞춰야 해요. 시작·종료·보류 같은 상태가 어느 PLC 필드에서 만들어졌는지, 이벤트가 발생한 시각과 서버가 받은 시각을 어떻게 구분할지 정해야 MySQL 이력과 MES·CIM 화면을 같은 사건으로 비교할 수 있어요.

이번 글은 LS PLC에 연결된 CCP 이벤트 상태 한 지점에서 출발해요. ccpinspectionstate 필드가 예시 PLC 주소 M120에 대응한다고 가정하지만, M120, CCPPLC01, CCP_INSPECTION_STATE는 현장 필드 주소 맵과 대조할 예시 이름이에요. 실제 디바이스 주소, 상태 코드와 스캔 주기는 PLC 프로그램 및 운영 기준으로 확정해야 해요.

이벤트 상태를 먼저 정의해요

상태값만 저장하면 나중에 왜 바뀌었는지 설명하기 어려워요. 이벤트 ID, 설비 ID, 상태 코드, 발생 시각, 수집 시각, 품질 상태와 마지막 전달 시각을 한 묶음으로 정리해요. 예를 들어 inspection_event_id는 사건을 묶고 event_state는 상태를 표현하며 occurred_at과 received_at은 발생·수신 시각을 나눠요. 상태 코드의 숫자 의미는 현장 PLC 주소 맵과 CCP 운영표에서 확인해요.

EASY-LINK는 LS XGT 현장 연결과 전달을 맡는 게이트웨이로 검토할 수 있어요. 한 지점의 상태를 정해진 목적지로 넘기는 연결만 필요하면 EASY-LINK만으로 충분할 수 있어요. 여러 지점의 수집 이력, 전달 상태와 화면을 함께 관리해야 하면 EASY LOGGER를 더해 역할을 나눠요. EASY LOGGER는 저장 이력·전달 상태·대시보드 운영을 맡고, 설비 제어 권한 자체를 대신하는 제품으로 설명하지 않아요.

PLC 이벤트 상태를 게이트웨이에서 MQTT·HTTP API·MySQL·Firebase 목적별 흐름으로 나누어 보는 추상 구조예요.

MQTT·HTTP API·MySQL·Firebase를 비교해요

MySQL은 기간별 CCP 이벤트를 검색하고 외부 업무 시스템의 기록과 대조할 때 중심이 되기 쉬워요. MQTT는 같은 상태를 여러 소비자에게 빠르게 분배할 때 비교하고, HTTP API는 MES·CIM이 정한 endpoint와 요청·응답 계약을 맞출 때 검토해요. Firebase는 현재 상태를 웹 화면에서 공유할 필요가 있을 때 비교할 수 있지만, 발생 시각과 수신 시각을 함께 남겨요.

MES·CIM 연계는 확인된 MQTT·HTTP API·DB 인터페이스 범위에서 설계해요. MES·CIM 전용 커넥터는 확인되지 않은 기능이라 전제로 하지 않아요. 외부 시스템 담당자와 이벤트 ID·상태 코드·시각·중복 처리 기준을 계약으로 맞춰요. 외부 MySQL을 쓴다면 qualityops 같은 외부 스키마와 ccp_event_history 같은 외부 테이블을 예시로 두고, 실제 이름과 컬럼은 DB 운영 문서로 확정해요. EASY LOGGER 내부 스키마라고 주장하지 않아요.

EASY LOGGER에서는 Runtime Status로 연결·전달 상태를 보고 Payload Log에서 필드와 수집 시각을 대조해요. 외부 DB의 DB History에서는 저장 성공·오류와 같은 시간대의 레코드를 확인해요.

EASY LOGGER OPC UA 예제

아래 예시는 CCP 이벤트 상태 필드가 예시 PLC 주소 M120에 대응하고, EASY LOGGER가 읽는 OPC UA 노드가 ns=3;s=CCP/InspectionState라고 가정한 운영 예제예요. CCPPLC01, M120, 노드 ID와 endpoint는 현장 필드 주소 맵·OPC UA 서버 설정·외부 연계 문서와 대조할 예시예요. Automatic Node Preview에서 노드와 데이터 타입을 확인하고 Runtime Status에서 연결·전달 상태를 확인해요.

ENDPOINT: opc.tcp://EXAMPLE_SERVER:4840
NODE ID: ns=3;s=CCP/InspectionState
DATA TYPE: Int16
READ: ccpinspectionstate
WRITE: ccpinspectionstate

이 예제의 M120 값은 상태 코드이고, occurred_at은 PLC 이벤트가 만들어진 시각이라는 전제로 외부 이벤트 계약과 대조해요. Automatic Node Preview에서 노드가 맞는지, Runtime Status에서 마지막 수신 시각이 갱신되는지, Payload Log에서 상태 코드가 예상 필드로 들어오는지 순서대로 봐요.

상태를 외부 MySQL에 보존할 때는 qualityops.ccp_event_history를 운영팀이 관리하는 외부 스키마·테이블 예시로 사용해요. event_id, event_state, occurred_at, received_at, source_node를 외부 DB 문서와 맞추고 DB History에서 저장 결과를 확인해요. 이는 EASY LOGGER 내부 스키마가 아니며 실제 스키마와 컬럼은 DB 담당자가 정해요.

{
  "event_id": "CCP-EXAMPLE-001",
  "event_state": 2,
  "occurred_at": "2026-08-17T06:00:00Z",
  "received_at": "2026-08-17T06:00:02Z",
  "source_node": "ns=3;s=CCP/InspectionState"
}

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

JSON의 source_node와 event_state는 노드 주소 맵과 외부 이벤트 계약을 대조한 뒤 Payload Log와 DB History에서 같은 event_id로 확인해요. 읽기와 쓰기 범위를 나눌 때는 담당 화면, 승인 절차와 인터록 조건을 함께 문서화해요.

EASY LOGGER의 저장 이력·전달 상태·대시보드 운영 역할을 확인하는 공식 제품 이미지예요.

작은 범위에서 상위 연계까지

첫 단계에서는 CCP 이벤트 한 지점과 예시 주소 한 구간만 선택해 PLC 표시 상태, 원시 필드, 수집 payload와 외부 DB 레코드의 시각을 맞춰요. 한 대 또는 한 공정에서 작게 시작한 뒤 두 번째 단계에서 여러 이벤트가 연속으로 생길 때 동일한 이벤트 ID가 중복 저장되지 않는지 확인하고 범위를 넓혀요. 단절·재연결 뒤 누락 구간도 따로 표시해요. 세 번째 단계에서 MES·CIM의 MQTT·HTTP API·DB 인터페이스 중 업무 기준에 맞는 경로를 선택해요.

제품 역할도 이 순서에 맞춰 판단해요. 현장 LS XGT 연결과 목적지 전달만 필요하면 EASY-LINK를 먼저 검토하고, 저장 이력·전달 상태·대시보드 운영까지 필요하면 EASY LOGGER를 함께 검토해요. 제품 안내에서 EASY 제품의 역할을 비교하고, 주소와 화면 설정은 제품 매뉴얼 자료실에서 버전별로 확인해 보세요.

마지막으로 상태 코드표, PLC 주소 맵, OPC UA 노드 ID, 외부 MySQL 스키마, MQTT·HTTP API 계약과 MES·CIM 담당 화면을 한 장의 인터페이스 표에 모아요. 산업 데이터 보안 관점에서는 계정별 최소 권한, 허용 노드 범위, 변경 이력과 수동 복구 절차를 운영 기준으로 남겨요. 압력 데이터 인터페이스 설계 기준에서 다른 센서의 주소·시각·외부 MySQL 대조 흐름도 비교해 보세요. 현장 연결 가능 여부만 먼저 확인해 보고 싶다면 문의로 남겨 주세요.

#EASY-LINK #EASY LOGGER #스마트팩토리 #LS PLC #MySQL #PLC 연동 #데이터 연동 #산업 데이터 보안 #OPC UA #HTTP API #MQTT

먼저 결론부터 볼게요

이벤트 상태를 먼저 정의해요

MQTT·HTTP API·MySQL·Firebase를 비교해요

EASY LOGGER OPC UA 예제

작은 범위에서 상위 연계까지

관련 글