시운전에는 냄새가 있다. 뜨거운 전기 캐비닛, 판지 먼지, 새벽 2시에 식어버린 커피. 그리고 내가 두려워하게 된 소리가 있다. 돌아가야 할 컨베이어 라인의 침묵.
지난주 나는 Inland Empire의 가동 현장에 있었다. 의류 반품을 처리하는 8만 평방피트 규모의 3PL에서, 기존 컨베이어 제어 설비에 새 WCS를 붙이는 작업이었다. 분기부에서 팔레트 하나가 죽어버렸다. WCS 모니터에는 밝은 녹색 글자로 "RELEASED"라고 떴다. PLC 캐비닛 앞의 제어 엔지니어는 I/O 램프를 바라보며 말했다. "출고 신호를 받은 적이 없습니다."
그 팔레트 때문에 이틀을 잃었다. 근본 원인은 민망할 정도였다. WCS 프로그래머는 신호 테이블의 리비전 7을 보고 작업하고 있었다. 현장의 PLC는 리비전 9으로 돌아가고 있었다. 그 사이에 현장 작업팀이 배선을 두 번 다시 끌어당기고 광전 센서를 두 개 추가했는데, 아무도 테이블을 업데이트하지 않았다. 출고 요청은 PLC 프로그램에게 아무 의미도 없는 예비 주소에 도달했다. 그 채널을 듣고 있는 사람은 아무도 없었다.
20년 동안 나는 이 영화를 수십 번 봤다. 하드웨어는 멀쩡하다. 두 소프트웨어도 멀쩡하다. 통합을 죽이는 건 그 사이에 있는 문서, 바로 I/O 신호 테이블이다. 나를 괴롭히러 돌아오지 않는 테이블의 만드는 법을 소개한다.
엑셀을 열기 전에 모든 신호를 세 개의 바구니로 분류하라
신입의 실수는 스프레드시트를 열고 끝없이 행을 입력해, 신호가 100개쯤 됐을 때 절반이 뭘 하는 건지 모르게 되는 것이다. 나는 먼저 분류하고, 그 다음에 목록을 만든다.
바구니 하나: 명령, WCS→PLC. 시작, 정지, 출고, 리셋, 모드 변경. 응답이 필요 없는 명령은 삭제한다. PLC가 응답하지 않아도 된다면, 한밤중에 문제가 생겼을 때 트러블슈팅할 근거가 아무것도 없기 때문이다.
바구니 둘: 상태, PLC→WCS. 정위치, 운전 중, 고장, 비상 정지, 수동/자동 모드. 상태는 읽기 전용이다. WCS는 보고, 절대 쓰지 않는다. 수많은 프로젝트가 바로 여기서 죽는다. WCS 프로그래머가 지름길로 가서 PLC가 소유한 상태 비트에 직접 쓰는 것이다. 쓰기 주체가 둘, 비트는 하나, 시운전에서 신호가 깜빡이고, 버그의 정체는 아군의 오사격이다.
바구니 셋: 하트비트. WCS가 1~2초마다 비트를 토글하고, PLC가 맞받아 비트를 토글한다. 양쪽이 상대의 맥박을 감시하고, 맥박이 멎으면 알람을 울린다. 테이블 전체에서 가장 싼 보험이자, 원가 절감의 이름으로 가장 자주 잘려나가는 것이다. 주장은 언제나 같다. "링크가 끊기면 네트워크 스위치가 알람을 울린다." 스위치 알람은 케이블이 끊겼다는 것만 알려준다. 하트비트는 건너편 기계가 살아 있는지, 죽었는지, 아니면 프로그램이 멈춰 뇌사 상태인지를 알려준다. 다른 사실이며, 새벽 2시에는 그 차이가 중요하다.
"팔레트 하나를 출고하라"를 예로 들어보자. 신호는 정확히 네 개가 필요하다. 출고 요청(WCS→PLC), 요청 수신(PLC→WCS), 출고 완료(PLC→WCS), 그리고 하트비트. 신호 네 개, 작업 하나, 소유 관계는 명확하다. "이게 뭐 하는 거고, 누가 쓰고, 누가 읽는가"에 답하지 못하는 행은 삭제한다. 신호 테이블은 길다고 좋은 게 아니다. 관리되지 않는 신호 하나는, 시운전이 삐끗했을 때 용의자가 한 명 느는 것과 같다.
3단계 핸드셰이크, 그리고 2단계가 화를 부르는 이유
내 타이밍 다이어그램은 3단계로, 이건 협상하지 않는다. WCS가 "출고 요청"을 세운다. PLC가 이를 보고 "요청 수신"을 세운다. PLC가 출고를 실행하고 팔레트가 도착하면 PLC가 "출고 완료"를 세운다. WCS가 "완료"를 보고 "요청"을 내린다. PLC가 "요청"이 사라진 것을 보고 "완료"를 내린다. 깨끗한 대기 상태로 돌아오며 한 바퀴가 완성된다.
왜 3단계인가? 두 가지 지름길의 대가를 내가 직접 치러봤기 때문이다. 지름길 하나: WCS가 쏘고 잊는다. 요청이 나가고, 신호 바운스로 PLC가 놓치고, 팔레트는 출고되지 않는다. 그런데 WCS는 출고됐다고 믿고 다음 작업을 보낸다. 라인 전체가 막힌다. 지름길 둘: PLC는 움직이지만 보고하지 않는다. 출고는 됐는데 WCS는 모르고, 타임아웃이 나서 요청을 재전송하고, 같은 팔레트가 두 번 출고된다. 하류 분기부는 파괴 더비장이 된다.
3단계 핸드셰이크의 핵심은 폐쇄 루프다. 이전 단계가 확인되기 전에는 아무것도 진행하지 않고, 리셋이 확인되기 전에는 아무것도 되돌리지 않는다. 아무도 말하지 않는 덤도 있다. 어느 한쪽이 네트워크를 잃거나 멈추면, 핸드셰이크는 단계 중간에서 얼어붙는다. 눈에 띄게, 시끄럽게, 알람과 함께. 얼어붙는 건 괜찮다. 죽이는 건 침묵의 실패다. 세 팔레트 뒤에 발견했을 때는 이미 손해를 본 뒤다.
모든 현장에서 돌리는 시운전 전 체크리스트
테이블 완성, 코드 완성. 아직 전체 라인 통합으로 가지 마라. 먼저 이 단일 항목 테스트를 돌려라. 시운전 밤의 눈물의 절반 정도를 구해준다.
디바운스부터. 광전 센서와 근접 스위치는 기계적 에지에서 바운스한다. PLC 프로그램에서 수십 밀리초의 입력 디바운스는 기본 중의 기본이다. WCS 쪽도 한 번의 스캔을 믿어서는 안 된다. 상태 변화를 받아들이기 전에 연속 두 번의 스캔을 요구하라. 바운스는 테스트에서는 보이지 않고, 물량이 정점을 찍을 때 정확히 모습을 드러낸다.
주소를 감사하라. 테이블을 들고 모든 신호를 PLC 프로그램 안의 실제 주소와 하나씩 대조하라. 현장 재배선과 막판 추가는 모든 프로젝트에서 일어난다. 테이블의 리비전과 프로그램의 리비전은 일치해야 한다. 내 현재 규칙: 테이블은 리비전 번호를 가지고, 그 번호는 PLC 프로그램 주석과 WCS 설정 양쪽에 나타난다. 오프닝 스토리의 리비전 7 대 9 참사는 바로 이것으로 막는다.
케이블을 뽑아라. 네트워크 케이블을 뽑고 WCS가 PLC의 소실을 알아채는 데 걸리는 시간을 재라. 그게 하트비트 테스트다. 비상 정지를 누르고 WCS가 보는 "비상 정지" 상태가 기계의 실제 동작과 일치하는지 확인하라. 여기서의 원칙: 비상 정지 회로 자체는 유선 안전 릴레이로 동작한다. WCS로 보내는 "비상 정지 상태"는 그저 거울일 뿐이다. 안전 기능을 소프트웨어 신호에 매달지 마라.
모드 신호를 테스트하라. PLC가 수동으로 넘어가면 WCS는 알아야 한다. 그리고 작업 투입을 멈춰야 한다. 나는 기술자가 컨베이어를 손으로 조깅하는데 WCS가 계속 출고 신호를 보내는 걸 본 적이 있다. 아무도 예상 못한 출고 명령에 팔레트가 밀려나갔다. 다친 사람은 없었지만, 운이 좋았을 뿐 설계가 아니었다. 모드는 안전 항목이지 옵션이 아니다.
그리고 숙성시켜라. 랜덤 비상 정지, 랜덤 네트워크 단절, 랜덤 수동 개입을 섞어가며 2시간 연속 운전을 돌린다. 시운전 시간은 프로젝트에서 가장 비싼 시간이다. 고객 앞에서 실패를 연출하는 것보다 리허설로 끝내는 게 낫다.
내일 시운전 현장에 들어간다면, 하나만 챙겨가라. 인쇄한 신호 테이블. 양쪽이 서명했고, 리비전 번호가 코드와 일치하는 것. 그것만으로 고장 모드의 절반을 막는다. 나머지는 위 체크리스트가 한 항목씩 처리한다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
