스마트팩토리는 어떻게 설비 데이터를 수집할까?

10분

2024.04.01.

서로 다른 플랫폼 간에 어떻게 커뮤니케이션할 수 있을까?

개발자들은 보통 다른 플랫폼과 통신을 해야 할 때 무척 큰 부담감을 가진다. 이런 심정은 나도 많이 공감한다. 혹시 이때 느낄 부담과 곤란함이 무엇인지 이해가 안 될 분들을 위해 잠깐 가상의 이야기를 해보고자 한다.

한국에서 나고 자라 한국어로 대화하는 것이 익숙한 한국인이 있다고 하자. 그는 다른 한국인과 소통하는 데 불편함을 느끼지 않는다. 모두가 동일한 언어와 규칙을 쓰기 때문이다. 어느날 그가 대학로를 걷다 우연히 길을 묻는 외국인들을 만났다고 하자. 이들은 영어, 일본어, 중국어, 독어, 불어 등 다양한 언어를 구사한다. 어떤 일이 벌어질까? 예상할 수 있다시피 외국의 언어 규칙을 모르는 이 한국인은 소통에 실패한다. 곧 그는 곤란함에 처하게 될 것이다.

스마트팩토리에서는 이런 상황이 자주 일어난다. 생산 설비가 서로 다른 규칙을 따르기 때문이다. OS도 다양할뿐더러 임베디드이거나 PLC(Programmable Logic Controller:자동제어장치)인 경우도 많다. 이런 이질성은 시스템의 통신을 매우 어렵게 만든다.

물론 그럼에도 불구하고 스마트팩토리 개발자들은 이들을 성공적으로 연동해 왔다. 따라서 기존 개발자들이 어떤 과정으로 실무를 하는지 알아보는 것이 시스템을 이해할 때 큰 도움이 될 것이다. 그들의 접근 방식은 큰 틀에서 세 개 과정으로 나눌 수 있다. 첫 단계는 장비에서 활용할 수 있는 통신 프로토콜을 확인하는 것이다. 두 번째는 무슨 정보를 어떤 데이터로 주고받을지 협의하는 것, 마지막은 시운전, 즉 테스트를 진행하는 것이다.

이제 각각의 과정을 더 자세히 알아보도록 하자.

1) 통신 프로토콜 확인

가장 먼저 해당 설비가 어떤 통신 프로토콜을 지원하는지 확인해야 한다. 그래야 소프트웨어 개발 공수와 필요한 하드웨어 등의 견적이 나온다. 이는 곧 프로젝트 가격 산정과 이어진다. 따라서 보통 통신 프로토콜의 확인은 영업 단계에서 진행되는 경우가 많다. 이때는 숙련된 엔지니어가 함께 현장을 방문해 이를 조사한다.

이 글은 실무 흐름의 이해를 목표로 하기 때문에 설비에 따른 프로토콜과 그에 대한 설명은 생략하고자 한다. 이를 하나하나 설명하려면 내용이 길어지고 이해가 쉽지 않을 것이다. 다만 알아야 하는 부분인 만큼 별도로 학습하는 걸 권장한다.

윈도우 PC

가장 연동이 편리한 단말기지만, OS가 같다고 무조건 편한 건 아니다. 설비 제조사도 개발자 자원은 한정되어 있다. 제조사 내 연구소에 대응할 개발자가 충분히 있다면야 TCP/IP 통신 프로토콜로 통신을 주고받겠지만 큰 기대는 하지 말자. 이럴 경우 제조사 입장에서도 고객에 맞는 통신 프로그램의 개발, 상주 개발자 고용 등 부담이 생긴다. 즉, 보통은 지원이 안 된다고 생각하는 게 편하다.

대신 OleDB나 ADO 같은 SDK로 데이터베이스에 결과를 직접 전송해 주는 기능을 미리 갖춘 경우가 많다. 따라서 DB to DB 방식을 이용하는 것이 가장 속 편한 방법이다.

이렇게 DB로 데이터를 받을 때 주의할 사항이 있다. MES의 중앙데이터베이스를 외부 협력사에 열어주면 안 된다는 것이다. 이럴 때는 아예 라인 전용 DB 서버를 별도로 구성해 제공하기를 권장한다.

PLC

PLC(Programmable Logic Controller : 자동제어장치)와 통신할 때는 주로 TCP/IP, RS232c, RS485 프로토콜이 쓰인다. 이때는 제조사마다 요구되는 독특한 데이터프레임을 만들어 전송하고 응답받도록 프로그래밍해야 한다. 이들과 직접 통신하려면 여러 부분에서 알아야 할 내용이 많다.

이런 과정이 부담스럽게 느껴진다면 비용이 들지만 편리한 방법이 있긴 하다. 바로 OPC, SCADA 등 통합 드라이버가 갖춰진 상용 소프트웨어를 구매해 중간 매개로 사용하는 것이다. 이 소프트웨어들이 API, SDK 등을 지원하기 때문에 개발이 수월해진다.

임베디드, IoT 장비

이 영역은 개인적으로 경험이 부실해 아는 정도만 언급하고자 한다. 임베디드 혹은 IoT 설비는 PC 등 중저가 설비, PLC 등 고가 설비와 달리 보통 가격대가 저렴하다. 예컨대 사출성형기 같은 설비의 경우 가장 중요한 정보는 카운팅인데, 고속으로 사출되는 제품을 카운팅하는 경우 이쪽이 훨씬 저렴해 많이 쓰인다.

다만 이런 설비는 통신이 불가능하거나 확장도 안 되는 모델이 더러 있다. 그 때문에 가장 먼저 제조사에 통신은 가능한지, 확장은 가능한지 문의해달라 고객에게 요청하자. 또는 외장만 봐도 어느 정도 지원이 되는지 아닌지 알 수 있는 방법이 있다. LAN 포트나 직렬 포트가 있는지 확인하는 것이다. 이 경우는 설비마다 품질 편차가 심하다. 따라서 실적 처리 같이 중요한 액션이 이런 설비에 의존하지 않도록 하자.

이처럼 프로토콜이 정해지면 개발 공수가 나오고 구매할 하드웨어 장비를 선정할 수 있다. 일반적으로 이런 부분이 모두 결정된 다음에야 계약서를 쓸 수 있다. 물론 주니어 개발자는 다른 설비와 통신해야 한다는 사실에 부담을 느낄 수 있다. 그렇지만 걱정하지 않아도 된다. 완전히 처음부터 쌓아가는 스타트업이 아니고서야 여태 해온 템플릿 정도는 가지고 있을 것이다. 그런 템플릿이 없다 해도 인터넷에 자료가 많이 있다.

2) 인터페이스 정의

통신 프로토콜이 정해졌는가? 이제 무슨 정보를 수집하고 어떤 데이터를 보낼지 협력 업체와 협의해야 한다.

그에 앞서 MES가 생산 설비와 통신하는 목적이 무엇인지 생각해 보자. 생산 설비는 필요한 기능을 잘 완수할 수 있는 상태로 출고된 완제품이다. 하지만 실제 고객은 이 설비를 사용하면서도 자체 전산 시스템에 이를 녹여내고 싶어 한다. 즉, 생산 설비의 작업 데이터를 MES에서 확인하며 일부를 제어하고 싶어 한다는 뜻이다.

여기서 설비 제어의 “일부”는 무엇일까? 대표적으로 두 가지를 소개할 수 있다. 설비가 MES에 작업을 진행해도 될지 묻는 것, 그리고 작업을 완료한 다음 보고하는 것이다.

더 자세히 살펴보도록 하자.

작업 허가

작업 허가란 설비가 MES에 “이 제품을 작업해도 되겠습니까?”하고 묻는 것이다. OK면 작업을 시작하고 NG면 라인을 멈추거나 (배출 공간이 있는 경우) 배출한다. PASS라면 작업을 하지 않고 지정된 다음 공정으로 이동시킨다. PASS의 경우 MES에 설정된 공정 라우팅* 정보에 기반한다.

* 라우팅(routing)은 제조되는 품목(Manufactured Item)에 대하여 정의되는 것입니다. 라우팅을 보다 정확히 정의한다면, 품목을 만드는 데 필요한 공정을 순서에 따라 정의하는 것으로, 어떤 장소(work center 또는 기계)에서 가공할 것인지, 그리고 이러한 공정을 수행하기 위해 필요한 셋업 시간과 단위 품목의 생산에 소요되는 시간(run time)은 얼마나 소요되는지에 대한 정보를 유지하고 있는 것입니다. <출처: MAILAB>

NG 상태 시 처리 방식은 여러 사정에 따라 고객사의 생산기술팀이 결정해 줄 것이다. 특히 자동화 라인의 경우라면 프로젝트를 시작할 때부터 처리 방식이 거의 결정되어 있기에 요구 사항 변경이 크지 않다. 물리적인 제약에 의해 좌우되는 사안이기 때문이다.

일반적으로 작업 허가는 이전 공정의 작업 여부를 체크해 문제가 있을 경우, 레일을 멈추고 공정 인터락*을 거는 것을 주목적으로 한다.

*‘공정 인터락’은 최적의 제품이 생산될 수 있도록 미리 설정해 놓은 공정 기준을 만족시키지 못할 경우, 작동이 중단되어 제품의 품질을 제어해 주는 역할을 합니다. <출처: 삼성 세미나 뉴스룸>

이때 인터락을 걸 수 있는지 아닌지 역시 물리적인 제약에 의해 결정 난다. 개발자는 공정 일부가 제어되지 않을 수 있다는 점, 그럼에도 언젠가 이런 제어가 추가될 수도 있다는 점 등을 고려해 확장성을 갖춘 소프트웨어를 설계해야 한다.

작업 완료

생산 설비에서 작업이란 기능의 수행을 의미한다. 따라서 설비는 그 기능을 잘 수행하는지 고객이 직접 확인할 수 있게 작업 이력을 저장하고 관리하도록 설계된다. 모든 작업을 마치면 설비는 이 작업 이력 데이터를 저장 공간에서 꺼내 완공 보고와 함께 MES로 전송한다.

MES는 전송된 정보를 받아 실적을 처리한다. 그에 대한 품질 데이터 역시 저장한다. 시스템에서 모든 처리가 완료되면 OK와 함께 다음 공정에 대한 응답이 나간다. 작업 허가 때와 마찬가지로 이다음 공정도 공정 라우팅 설정에 기반한다.

때로 이력 데이터의 용량이 너무 크면 연동을 포기하고 필요한 요약 정보만 받기도 한다. 특히 비전 검사기의 경우, 고용량, 고해상도 이미지를 처리하기 때문에 대부분은 연동하지 않는다. 보통 검사 항목의 OK/NG 여부 및 이미지 파일명, 검사 일시 정도를 수집한다.

이외에도 설비 알람 보고, 통신 상태 보고, 품질 스펙 요청 등 제조사의 특성과 상황에 따라 다양한 인터페이스가 있다. 하지만 위에 소개한 큰 틀을 이해할 수 있다면 나머지 작업은 그리 어렵지 않을 것이다.

3) 시운전

시운전 단계는 몸도 고되고 심리적 압박감도 큰 일정이다. MES 담당자의 경우 설비 제어 담당자만큼이나 책임지는 인터페이스가 많다. 그러니 여기저기 협력 업체에서 “MES!” 하며 부르기도 한다. 라인 역시 보통 크고 멀어 체력적으로 고생한다. 특히 여름에 테스트를 할 때는 에어컨 공사도 안 된 현장을 땀을 철철 흘리며 누비기도 한다. 처음 시운전을 할 때는 전날 잠도 제대로 못 자니 아주 고역이다.

하지만 이 업계에서 어차피 첫 테스트는 잘 안된다는 것을 다들 안다. 그만큼 큰 기대를 하지 않는다. 다만 테스트에서 발생한 이슈를 고객과 협력 업체에 투명하게 공개하는 것이 중요하다. 여기서 고객과 협력 업체의 신뢰도가 결정 난다. 시스템이 잘 돌아가는 것보다 이슈를 투명하게 보고하고 어떻게든 해결하겠다는 태도를 보일 때 더 큰 신뢰가 돌아오는 듯하다.

누군가는 이 일이 IT “서비스”라는 사실을 잘 인지하지 않는다. 이 바닥은 고객에게 신뢰를 주고 커뮤니케이션을 원활하게 하며 요구사항을 만족시키는 것이 절체절명의 목표인 곳이다. 시운전 일정은 이런 역량을 시험받는 대표적인 일정이다. 코딩하는 시간보다 이 시간이 스마트팩토리 개발자로서 가치가 정해지는 시간임을 유념하라.

시운전이란 이슈의 관리와 해결을 지속하여 문제를 0으로 만드는 일이다. 모두 함수의 극한이 0으로 수렴할 것이라는 기대를 한다. 때로 문제가 발산해 버리면 다 소용없는 짓이 되기도 한다. 그 원인은 다 사람에 있다. 기계는 잘못이 없다.

프로젝트 매니저라면 공감하겠지만, 이 시기에는 이슈 트래커가 가장 큰 빛을 발한다. 때로는 협력사에서 해결했다고 보고한 현상이 재발하거나 애초에 그들이 문제의 원인을 착각하기도 한다. A업체 탓으로 생긴 문제가 다시 터졌는데, 이를 아무도 기억 못 해 B업체 측에서 이를 해결하려다 일정이 늦어지는 경우도 있다.

이때 도움이 되는 것이 이슈 트래커다. 연관성을 가질 법한 이슈는 모두 연결해 두고 천천히 검토하다 보면 해결할 실마리가 나오고는 한다. 카카오톡, 슬랙과 같은 메신저는 소통에 좋지만 이슈 추적에는 도움이 되지 않는다. 써본 적이 없다면 당장 레드마인, 트렐로, 지라 같은 이슈 트래커 앱을 이용해 보도록 하자.

마치며

지금까지 스마트팩토리에서 다양한 설비를 연동하는 과정과 방법들을 소개했다. 이 글을 읽기 전, 여러 설비에서 데이터를 실시간으로 수집하고 이를 제어하는 시스템의 소개 영상 등을 본 적이 있는가? 이를 보고 그 시스템을 구축하는 과정이 매우 인텔리할 것이라 생각하면 큰 오산이다. 여기 깔끔한 정장을 입은 사람들이 여유롭게 커피 한 잔과 함께 코딩하는 풍경은 없다.

실제로 이 과정은 굉장히 어렵고 매우 심란한 과정이다. 정장은 벗어던진 다음 작업복과 안전화를 신고 현장을 누벼야 한다. 다만 한 가지. 일이 힘든 만큼 모든 작업이 끝났을 때 오는 성취감은 이루 말하기 어려운 수준이다. 또한 이런 통과 의례를 거치고 나면 마침내 스마트팩토리 개발자라는 인정을 받을 수 있다. 그렇게 되면 쉽게 대체할 수 없는 개발자가 된다. 꿈과 희망을 갖자.

설비 연동에 부담을 갖는 주니어 개발자들에게 이 글이 작은 도움이 되었기를 바란다.

로그인하고 자유롭게 의견을 남겨주세요.