MES 메세지 통신 구성과 단계

저는 MES 메세지의 기본 구성과 흐름을 배터리 제조 공정을 예로 정리하겠다. 먼저 MES 메세지는 Validation, Start, Report, End의 순서로 흐르는 것이 일반적이다. 공정 예시로 A > B > C를 들면 현재 투입하려는 셀이 B를 끝낸 상태인지 확인하는 것이 Validation이고, 다른 공정을 아직 진행 중인 셀이 C를 투입하려고 할 때는 Validation에서 Nck를 보낸다는 점이 핵심이다. Start는 Track In 개념이 핵심으로, 셀의 ID마다 이 셀의 상태를 구분해둔다. 공정 중, 공정 완료, 대기 상태가 있는데, 공정 중(In Process)인 상태로 변하는 시점을 Track In이라 부른다. 실제로 물리적으로 설비 안에 있어도 트레이가 리프트를 타고 올라갔거나 더 안 쪽에 바코드가 읽히는 지점에서 Track In 기능이 작동하여 공정 중으로 전환될 수 있다. 이로 인해 현장 상태와 MES의 관리 상태가 차이가 생길 수 있다.

다음으로 Report는 설비의 공정이 끝난 뒤 데이터를 보내는 메세지다. End와 구분해 두는 이유는 Msg TimeOut로 메세지를 받지 못할 경우 결과 데이터와 Track Out 정보를 놓칠 수 있어 독립적으로 다루는 편이 안전하다는 점이다. End는 Start와 마찬가지로 Track Out이 되는 메세지로, 전산상 공정 종료 시점이며 물리적 Lot의 위치와의 괴리가 남아 있을 수 있다.

설비에서 MES로 이르는 전체 흐름을 보면 크게 설비 <-> CIM <-> MES AP <-> DataBase(Oracle) <-> MES UI의 단계로 이루어진다. 설비 EQ가 데이터를 올리면 CIM이 HSMS나 PLC로 구성된 데이터를 C#으로 변환하고 DB에 저장하거나 DB 데이터를 로직에 맞게 변환해 준다. MES AP는 Lot이 읽혀오는 flag에 따라 DB에서 Lot의 상태를 읽어 Validation을 수행하거나 DB의 Lot 상태를 업데이트한다. 사용자는 MES UI를 통해 DB에서 출력한 데이터를 확인하게 된다. 이처럼 MES UI에서 MES AP처럼 설비에게 명령하는 메세지를 바로 보내는 경우도 있지만 일반적으로는 위의 흐름으로 작동한다.