본문 바로가기

전체 글88

PLC·MES 값이 이상할 때|Data Type·Endian·Scale 오류 진단 PLC 화면에서는 압력이 253.4인데 MES에는 2534 또는 25.34로 표시되거나, 음수 값이 갑자기 65000대로 바뀌는 경우가 있습니다.통신 연결도 정상이고 데이터도 계속 들어오는데 값만 이상하다면 Network 장애보다 Data Type·Byte/Word Order·Scale·String Encoding·Database 변환을 먼저 확인해야 합니다.이 문제의 핵심은 MES 화면의 최종값만 보는 것이 아니라 PLC의 RAW 값이 각 구간에서 어떻게 해석되고 변환됐는지를 단계별로 비교하는 것입니다.핵심: 통신이 성공했다고 데이터가 정확하다는 뜻은 아닙니다. 같은 RAW 값도 Data Type이나 Scale 규칙이 다르면 완전히 다른 값이 될 수 있습니다.목차30초 안에 오류 유형 찾기Signed·.. 2026. 9. 18.
MES API 503·504 반복될 때|Circuit Breaker·Retry Storm·Bulkhead 설계 MES API에서 503 Service Unavailable이나 504 Gateway Timeout이 반복되면 가장 먼저 Retry 횟수를 늘리고 싶어질 수 있습니다.하지만 이미 과부하된 MES Server에 여러 설비와 Interface가 동시에 재시도하면 Retry가 복구를 돕는 것이 아니라 오히려 장애를 키우는 Retry Storm이 될 수 있습니다.이런 상황에서는 단순 Retry보다 Timeout → Backoff → Retry Budget → Circuit Breaker → Bulkhead → 복구 검증 순서로 장애 확산을 제어해야 합니다.핵심: 장애 중인 MES를 계속 호출하는 것이 복구 전략은 아닙니다. 실패가 지속되면 요청을 잠시 차단하고, 다른 기능과 자원을 격리한 뒤, 회복 여부를 제한.. 2026. 9. 17.
MES Queue 적체 원인|Backlog·Throughput·Lag로 장애 전 감지 MES 데이터가 갑자기 늦어지기 전에 시스템에서는 이미 여러 신호가 나타나는 경우가 많습니다.Queue에 대기 데이터가 조금씩 쌓이고, 처리속도보다 유입속도가 빨라지며, 가장 오래 기다린 Event의 시간이 계속 증가하는 식입니다.따라서 Queue 장애는 Backlog가 몇 건인지만 보는 것보다 Ingress Rate → Processing Rate → Backlog 증가속도 → Oldest Age → 예상 복구시간을 함께 보는 것이 중요합니다.핵심: Queue에 5,000건이 있다는 사실보다 지금도 초당 몇 건씩 더 쌓이고 있는지가 장애 가능성을 판단하는 데 더 중요할 수 있습니다.목차30초 Queue 상태 판단장애 전 확인할 4개 신호Backlog 증가속도 계산경고 기준 만드는 방법복구까지 걸리는 시.. 2026. 9. 17.
PLC 생산수량과 MES 실적이 다를 때|누락·중복·Counter Reset 진단 PLC 생산수량은 12,480개인데 MES 실적은 12,467개처럼 두 시스템의 수량이 맞지 않는 경우가 있습니다.13개 차이라고 해서 단순 통신 누락이라고 판단하면 안 됩니다. 실제 원인은 전송 누락·중복처리·Counter Reset·Shift 경계·재전송·Database Rollback 등 여러 구간에 있을 수 있습니다.이 문제는 PLC Counter와 MES 최종값만 비교하는 것보다 PLC 발생건수 → 수집건수 → Queue → API → DB → MES 처리건수를 단계별로 대조해야 빠르게 찾을 수 있습니다.핵심: “PLC 100개, MES 98개”에서 멈추지 말고 100개가 어느 구간에서 98개가 됐는지 숫자로 좁혀가는 것이 생산실적 정합성 분석의 핵심입니다.목차30초 안에 차이 원인 좁히기PLC.. 2026. 9. 16.
MES 통신 끊김 데이터 누락 방지|Buffer·Store-and-Forward·Replay 설계 설비에서는 정상적으로 생산이 계속되고 있는데 MES Server나 네트워크가 잠시 중단되면 그 시간 동안 발생한 생산실적이 누락되는 문제가 생길 수 있습니다.통신이 복구된 뒤부터 다시 정상적으로 데이터가 올라온다고 해서 문제가 해결된 것은 아닙니다. 장애 시간 동안 발생한 Event가 어디에 저장됐는지를 확인해야 합니다.이런 환경에서는 단순 Retry보다 Buffer → Store-and-Forward → Replay → Idempotency → 복구 검증 구조를 함께 설계하는 것이 중요합니다.핵심: 안정적인 MES Interface는 통신이 항상 정상인 시스템이 아니라 통신이 끊겨도 데이터를 보관하고, 복구 후 순서대로 다시 전달하며, 중복 없이 정상 상태로 돌아오는 시스템입니다.목차데이터 유실 방지 .. 2026. 9. 16.