SCADA Things
← 전체 글
언어English한국어
HMI/약 14분 읽기/— 조회

화면에는 새 레시피, 설비는 어제 값으로 돈다

레시피 다운로드에서 선택값·다운로드값·운전값을 태그로 나누고, PLC가 인정한 값을 echo로 대조하는 방법. 거부 사유를 파라미터 단위로 남기는 설계까지.

HMISCADA레시피태그체크리스트

Changeover 30분 뒤에 품질에서 전화가 온다. 화면에는 새 제품 레시피 이름이 떠 있는데 실링 온도는 어제 값 그대로다. 태그를 열어 보면 HMI_SelectedRecipeId는 바뀌었고 PLC_ActiveRecipeId는 안 바뀌었다. 다운로드가 시작도 안 됐거나, 시작만 하고 거부당했다. 화면은 그 둘을 구분해서 보여주지 않았다. 아래 그림은 그 구분을 만들어 주는 최소한의 절차다 — HMI가 staging 영역에 파라미터를 쓰고, recipe id·version·parameter count·checksum을 같이 쓰고, request number를 올리면, PLC가 accepted 또는 rejected와 reason code를 돌려준다. 핵심은 마지막 화살표를 두 번째 화살표와 대조하는 것이다.

HMI가 staging 영역에 파라미터를 쓰고 recipe id·version·count·checksum과 request number를 보내면 PLC가 accepted 또는 rejected와 reason code를 돌려주며, 보낸 값과 되받은 값을 대조한다 HMIPLC count checksum staging 영역에 파라미터 write recipe id · version · count · checksum request number +1 accepted / rejected · reason code 대조

태그 하나로는 세 가지 상태를 못 담는다

RecipeName 태그 하나에 모든 걸 담으면 현장에서 반드시 헷갈린다. 화면에서 고른 값, PLC가 받아서 검증한 값, 지금 cycle에 실제로 쓰는 값은 서로 다를 수 있고, 문제가 생기는 순간은 정확히 그 셋이 갈라진 순간이다.

이 구분은 새로 발명한 게 아니다. IEC 61512-1(ISA-88)이 master recipe와 control recipe를 나눈 이유와 같다. batch 하나에 묶여 실행되는 recipe는 라이브러리에 등록된 recipe와 별개의 객체다.

상태예시 태그용도
선택한 레시피HMI_SelectedRecipeId운전자가 화면에서 고른 값.
다운로드 요청RecipeDownload.RequestId파라미터 전송을 시작하는 명령.
다운로드 완료 레시피PLC_DownloadedRecipeIdPLC가 받고 검증한 값.
현재 운전 레시피PLC_ActiveRecipeId지금 batch나 cycle에 적용 중인 값.
레시피 versionRecipeVersion 또는 checksum이름은 같은데 내용이 다른 경우를 구분.
다운로드 상태Idle, Busy, Accepted, Rejected, Timeout화면 메시지와 interlock 판단에 사용.

화면 문구도 이 구분을 따라가야 한다. "선택", "대기", "다운로드 완료", "운전 중"을 각각 다르게 쓴다. 애매한 "현재 레시피" 한 줄은 교대조마다 다르게 읽힌다. Changeover 문제의 상당수가 이 한 줄에서 시작된다.

request bit 말고 request number

작은 장비는 레시피가 register 10개로 끝난다. 큰 장비는 tag 수백 개다. 후자에서 block write 한 번 하고 성공/실패만 표시하면 시운전 때 아무것도 못 잡는다.

위 그림의 순서를 코드로 옮기면 이렇게 된다.

  1. HMI가 staging 영역에 파라미터를 쓴다.
  2. HMI가 recipe id, version, parameter count, checksum을 쓴다.
  3. HMI가 request number를 증가시킨다.
  4. PLC가 count, checksum, range, 현재 machine mode를 확인한다.
  5. PLC가 staging 값을 download buffer로 복사한다.
  6. PLC가 accepted 또는 rejected와 reason code를 돌려준다.
  7. HMI가 결과를 표시하고 request id를 기록한다.

3번은 bit toggle이 아니라 증가하는 number로 하는 쪽이 낫다. 재시작 뒤에 bit가 켜진 채로 남아 있으면 "새 요청"인지 "지난번 잔재"인지 구분할 방법이 없다. Number면 PLC가 마지막 처리한 값을 들고 있다가 같은 번호를 무시하면 끝이다. 재전송도 공짜로 안전해진다.

5번을 빼먹는 구현을 자주 본다. staging에서 바로 운전하면 전송 도중 끊겼을 때 반쯤 받은 레시피로 돌아간다.

반도체 쪽에서 host가 설비에 recipe를 내려보내는 SEMI E5 Stream 7도 결국 같은 모양이다. S7F1 Process Program Load Inquire가 PPID와 body 길이를 먼저 보내 설비의 허가를 받고, 실제 body는 그 다음 S7F3로 간다. 설비는 받기 전에 거절할 수 있다. 협상 먼저, 데이터 나중.

PLC로 보내기 전에 거를 것

최종 방어는 PLC가 해야 한다. 그래도 HMI나 recipe service에서 먼저 막는 편이 낫다. 운전자가 바로 읽을 수 있는 메시지를 줄 수 있기 때문이다.

  • 파라미터별 최소값과 최대값.
  • 이전 제품 대비 최대 변경 폭이나 ramp rate.
  • 단위 확인. 다른 라인에서 가져온 레시피일 때 특히 중요하다.
  • 제품 코드, 원료 등급, tool 번호 같은 필수 항목.
  • 속도와 체류 시간처럼 같이 봐야 하는 파라미터 조합.
  • idle 또는 setup mode에서만 다운로드 허용 같은 설비 상태 조건.

Limit를 PDF에만 두면 안 된다. 레시피 정의와 같이 시스템 데이터로 관리한다. MES에서는 승인인데 HMI에서 거부되는 상황이 생기면, 최소한 두 시스템이 같은 rule 이름이나 같은 reject reason을 보여야 이야기가 된다.

"다운로드 실패"는 메시지가 아니다

그 다섯 글자로 운전자도 보전도 다음 행동을 정할 수 없다. 어느 값 때문인지, 설비 조건 때문인지가 화면에 바로 나와야 한다.

  • 실링 온도 상한: 215 °C는 레시피 허용값 200 °C보다 큼
  • 레시피 다운로드는 설비 idle 상태에서만 가능
  • Recipe version 18은 Line 2 생산 승인 전
  • 파라미터 전송 후 PLC checksum 불일치
  • Parameter count 64개 예상, 62개 수신

문구와 함께 숫자 code를 남긴다. HMI 언어, PLC comment, support ticket의 표현이 다 달라도 code가 같으면 같은 문제인지 맞출 수 있다.

되받은 값을 대조한다

HMI가 태그 쓰기를 끝냈다고 다운로드가 끝난 게 아니다. 이게 이 글의 전부라고 해도 된다. PLC가 무엇을 받았고 어떤 조건으로 인정했는지를 echo해야 하고, HMI는 그 값을 자기가 보낸 값과 비교해야 한다.

  • PLC가 인정한 recipe id와 version.
  • PLC가 계산한 checksum 또는 signature.
  • PLC가 받은 parameter count.
  • Controller나 SCADA server 기준 완료 시간.
  • Reject code와 처음 실패한 parameter index.

중요 setpoint는 시운전 중에 requested value와 accepted value를 나란히 띄워 두는 게 좋다. Scaling 오류, 정수 반올림, 배열 index 밀림, stale value가 여기서 다 드러난다. 정식 운전 들어가면 지워도 된다.

운전 중 덮어쓰기 규칙

설비마다 다르다. 포장 라인은 현재 제품을 마무리하면서 다음 제품을 staging할 수 있다. batch reactor는 원료 투입 뒤 process parameter 변경을 아예 금지하는 쪽이 맞다. 어느 쪽이든 문서가 아니라 로직에 적어야 한다.

  • Idle 상태에서만 다운로드 가능.
  • 현재 active recipe는 유지하고 next recipe만 staging 가능.
  • 운전 중에는 label이나 표시용 항목만 수정 가능.
  • Limit 변경은 engineer 권한 필요.
  • 생산 사용 전 MES approval 필요.
  • Manual override는 audit event와 사유를 남김.

시운전 때 일부러 실패시킨다

정상 다운로드 한 번 되는 걸 보고 끝내면 안 된다. 실제 운전에서 필요한 건 실패했을 때의 복구 경로다.

시험기대 결과
Idle 상태에서 정상 레시피 다운로드PLC accept, id/version/checksum 일치.
범위 밖 파라미터 입력HMI 또는 PLC reject, 항목별 사유 표시.
잘못된 machine mode값이 active 되기 전에 다운로드 차단.
전송 중 네트워크 단절Timeout 또는 reject 처리, 기존 active recipe 유지.
같은 request number 재전송PLC가 무시하거나 이미 처리됨으로 응답.
같은 이름의 새 version화면에서 version 차이를 분명히 표시.
Staging 후 PLC 재시작반쯤 받은 레시피가 자동 active 되지 않음.

이 시험의 화면 캡처와 log export는 버리지 말고 남긴다. 나중에 품질 문제가 올라왔을 때 어떤 레시피가 실제로 적용됐는지 대는 근거가 된다.

자주 보는 고장 형태

화면은 새 제품인데 설비는 이전 값으로 운전한다. selected recipe만 바뀌고 accepted recipe를 아무도 확인하지 않은 경우. 위의 대조가 없으면 이건 무조건 다시 난다.

파라미터 하나가 다음 항목으로 밀린다. 중간에 새 항목을 추가하면서 배열 index가 바뀐 것이다. count와 checksum 검사가 있으면 생산 전에 잡힌다.

Engineering station에서는 되는데 runtime HMI에서는 안 된다. Runtime service account에 database나 file share 권한이 없거나, 운영 HMI가 다른 recipe folder를 보고 있다. 둘 중 하나다.

다운로드가 막히면 PLC tag를 직접 고쳐서 넘어간다. 거부 사유가 불명확하거나 changeover 절차가 너무 느리다는 신호다. 이게 습관이 되면 레시피 시스템은 그때부터 장식이다.

MES와 HMI의 승인 상태가 다르다. 승인 기준을 한 곳으로 정하거나, approval state를 timestamp와 version까지 포함해서 동기화한다.

다음에 레시피 화면을 열면 먼저 볼 것 하나. PLC_ActiveRecipeId가 화면 어디에 떠 있는지. 안 떠 있으면 나머지 검증은 아직 의미가 없다.

SECS/GEM 쪽에서 같은 handshake를 바이트 단위로 보고 싶다면 SECS/GEM 시뮬레이터에서 S7 흐름을 직접 돌려볼 수 있다.