본문 바로가기

전체 글82

MES 장애 로그 분석｜Trace ID·Correlation ID로 PLC·API·DB 원인 추적 MES 장애가 발생했을 때 PLC Log, OPC UA Log, API Log, Database Log를 모두 확인했는데도 원인을 찾지 못하는 경우가 있습니다.로그가 부족해서가 아니라 서로 다른 시스템의 로그가 같은 생산 Event를 가리키고 있다는 것을 연결하지 못하기 때문인 경우가 많습니다.이럴 때는 Log를 많이 남기는 것보다 Event ID → Trace ID → Timestamp → 처리결과가 하나의 흐름으로 이어지도록 만드는 것이 중요합니다.핵심: MES 장애 분석의 목표는 “오류 로그를 찾는 것”이 아니라 문제가 발생한 하나의 Event가 어느 구간까지 정상적으로 이동했는지 증명하는 것입니다.목차30초 안에 장애 범위 좁히기Event ID와 Trace ID 설계시스템 로그를 하나의 시간축으로.. 2026. 9. 15.
PLC·MES 시간 안 맞을 때｜NTP·UTC·Timestamp 오류 해결 순서 PLC에서는 10시 30분에 생산이 완료됐는데 MES에는 10시 34분으로 기록되거나, Alarm 발생시간보다 생산완료 시간이 먼저 찍히는 문제가 발생할 수 있습니다.이런 문제는 통신이 끊긴 것이 아니라 PLC·OPC UA Server·Database·MES Server의 시간이 서로 다르거나 Timestamp를 찍는 위치가 달라서 발생하는 경우가 많습니다.따라서 단순히 서버 시계만 맞추기보다 시간 원본 확인 → Clock Offset 측정 → Timestamp 생성 위치 → UTC·Local 변환 → 저장 시각 → 화면 표시 시각 순서로 확인해야 합니다.핵심: MES의 시간 오류는 “현재 몇 시인가?”보다 이 Timestamp를 어떤 장비가, 어느 순간에, 어떤 시간대로 찍었는가?를 찾는 것이 더 중요.. 2026. 9. 14.
MES 실적 중복 저장될 때｜Retry·Transaction ID·Idempotency 점검 순서 MES에서 생산실적이 한 번만 발생했는데 Database에는 동일한 실적이 두 건씩 저장되는 문제가 발생할 수 있습니다.특히 네트워크 Timeout이나 API 응답 지연이 발생한 뒤 자동 Retry가 동작하는 환경에서 이런 현상이 자주 나타납니다.이 문제는 단순히 “Retry를 없애는 것”보다 요청 식별 → 처리 여부 확인 → 중복 차단 → 안전한 재시도 → DB 방어선 순서로 설계해야 합니다.핵심: Client가 응답을 받지 못했다고 해서 Server가 처리하지 않은 것은 아닙니다. 응답 유실과 처리 실패를 구분하지 않고 같은 요청을 다시 보내면 중복 실적이 발생할 수 있습니다.목차빠르게 보기중복 저장이 발생하는 이유대표적인 Retry 중복 시나리오Transaction ID와 IdempotencyDat.. 2026. 9. 14.
MES 데이터 안 올라갈 때｜PLC·OPC UA·API·DB 구간별 진단 순서 설비에서는 생산수량이 정상적으로 증가하고 PLC에서도 값이 보이는데, MES 화면에는 실적이 올라오지 않는 경우가 있습니다.이런 문제는 MES만 확인해서는 원인을 찾기 어렵습니다. 실제 데이터는 PLC → OPC UA 또는 통신 Middleware → API → Database → MES Application처럼 여러 구간을 지나기 때문입니다.따라서 장애가 발생하면 시스템 전체를 동시에 수정하기보다 어느 구간까지 데이터가 정상적으로 도착했는지부터 확인해야 합니다.핵심: MES 데이터 장애는 “MES가 안 된다”가 아니라 데이터가 마지막으로 정상 확인되는 지점을 찾는 문제라고 생각하면 훨씬 빠르게 해결할 수 있습니다.MES 데이터 장애 흐름 한눈에 보기MES 데이터 전달 경로PLC원본 데이터→OPC UA수.. 2026. 9. 13.
OPC UA 태그 많아지면 느릴 때｜Subscription 분할·Publishing·Queue 성능 튜닝 OPC UA Client에 처음 100개 정도의 Tag를 연결했을 때는 문제가 없었는데, MES·SCADA·Historian으로 연결하는 Tag가 수천 개로 늘어나면서 값이 늦게 바뀌거나 일부 데이터가 밀리는 경우가 있습니다.이때 네트워크 속도만 높이거나 모든 Tag의 Sampling Interval을 줄인다고 문제가 해결되지는 않습니다.대량 Tag 환경에서는 Tag 중요도 분류 → Subscription 분할 → Sampling·Publishing 조정 → Queue·Notification 확인 → Server Limit 확인 → 실제 부하 측정 순서로 설계해야 합니다.핵심: OPC UA 성능 문제는 “Tag가 많다” 자체보다 모든 Tag를 같은 주기로 읽고 같은 Subscription에 몰아넣는 구조.. 2026. 9. 13.

티스토리툴바