지난 시간에는 예를 통해, 공장의 물리적 개체들인 기계들이 횡적으로 어떻게 상호 작용하는지와 개체들로부터 발생하는 데이터를 이용한 제조 시스템의 지능화에 대해 살펴보았는데요. 오늘은 이러한 지능화를 가능케 하는 자동화 단계의 종류와 각각의 단계 속, 시스템 내의 종적인 정보의 흐름을 통합하는 IT의 역할을 알아보겠습니다.

● ‘나’와 다른 ‘너’와의 상호 작용을 위한 IT의 역할 (8편) : http://blog.lgcns.com/709
● ‘나’와 다른 ‘너’와의 상호 작용을 위한 IT의 역할 (9편) : http://blog.lgcns.com/713

공장 자동화와 그 운영 기술들속의 IT

그렇다면, 앞의 글에서 언급한 전사적인 자동화/지능화가 순조롭게 실행되기 위해서는 어떤 것이 우선 갖춰져야 하는 것일까요? 앞의 예제에서와 같이 일단 서로 연결되어야 필요한 정보를 교환할 수 있겠죠. 그렇다면, 현장 기계들끼리의 상호 작용을 넘어서 앞의 글에서 소개한 제조 시스템의 다른 가상 시스템 및 여러 이해 관계자들과도 어떻게 이런 데이터를 공유할 수 있을까요?

앞서 1편에서 잠깐 소개했던 제어 계층 구조의 표준인 피라미드형 공장 자동화 시스템을 다시 한번 살펴보겠습니다. 각각의 계층은 제어 대상/역할/제어하는 위치에 따라 비슷한 기능을 하는 장비들 및 인터페이스, 입출력과 정보의 단위에 따른 소프트웨어 응용 프로그램들로 구분됩니다.

원래 현장의 여러 생산 단위에서 혹은 현장, 사무실 사이에서 수작업으로 오고 갔던 정보들이 이제는 디지털화된 컴퓨팅 환경에서 시그널과 메시지로 교환되고 있습니다. 이는 전형적인 중앙 집중식 계층 제어 시스템 구조이며, 상의하달식의 명령과 하의상달식의 보고 형태로 이루어집니다. 그리고 각각의 레벨별로 메모리 혹은 데이터베이스를 지닌 애플리케이션이 있어서 일종의 정보의 버퍼 역할을 하게 되겠죠.

그러나, 아직도 많은 중소 제조 업체들이 아래 그림과 같은 체계적인 정보의 구조조차 없이 주먹구구식으로 운영되고 있다고 합니다. 또한 어떤 체계나 정보맵 등에 의해 운영된다고 해도 정작 그 안의 데이터들은 계층을 넘나들며 자유롭게, 또 자동화되어 입출력에 활용되지 못하고 있는 실정입니다. 일부 단계에서는 시그널/메시지로 교환되고 있다지만, 한편으로는 아직도 많은 작업자들이 중복된 생산 배치 데이터들을 생산 운영 관리 시스템(MES)에서 ERP와 같은 비즈니스 시스템으로 수작업으로 입력하는 식으로 말입니다. 이는 시간과 비용의 낭비이자 데이터 입력으로 인한 오류 등의 문제를 안고 있기도 합니다. 완벽히 자동화된 정보 교환이 어려운 이유는 계층 사이에서 전달되는 데이터들의 형식/추상화 정도/입상도(Granularity)/상호 작용에 요구되는 시간의 스케일이 다 다르기 때문입니다.

조금 과장해서 비유하자면, 내일 큰 비가 온다고 해서 마을에 둑을 쌓아야 하는 상황에서, 각각 다른 나라에서 온 선생님/목수/수다스러운 어린이/과묵한 기업가가 방안에 모여 토론을 벌인다고 가정해 봅시다. 어린이는 단편적인 것을, 선생님은 둑을 쌓는 방법을, 목수는 일단 나가서 돌이라도 줍자고, 기업가는 듣고 있다가 둑을 이용해 뭔가 좀 돈이 될 만한 것을 찾자며 가끔씩 툭툭 던지는 상황입니다. 딱 봐도 원활한 토론이 이루어지는 것 같지 않습니다. 더군다나 참여한 사람들의 관점도 모두 다릅니다.

위의 자료들을 한번 살펴보시죠. 그 내용을 보면, 표에 나타난 시간 단위 스케일의 차이뿐만 아니라 ‘레벨 2’ 이하에서는 이산형 제조와 배치, 혹은 프로세스 제조 등에 사용되는 기기/시스템 및 제어 방법 또한 그 차이를 보입니다. 또한 지원하는 데이터에 대한 소프트웨어 모델은 가장 작게는 Binary 시그널, 데이터의 처리부터 상위로 올라갈수록 파일(NC code 파일 같은), 재사용 가능한 PLC 기능 블록들, 점차 집합된 애플리케이션의 형태로의 모습을 띠게 됩니다.

앞선 글의 예를 통해 같은 레벨 내에서도 서로 다른 개체들끼리는 자기 관심사가 다르다는 것을 알 수 있었는데요. 하물며 각각의 다른 레벨에서의 제어란, ‘어떤 대상이 내가 보는 우주/세계의 중심인가?’라는 물음에 대한 답이나 마찬가지입니다. 즉 계층별로 관점이 다르고, 제어하려는 대상이 다른 것이죠. 이렇듯 관점이 다르기 때문에 과거에는 그 관점에 부합하는 정보만 필요했던 것도 사실입니다. 그러나 상황이 바뀌면서 과거 관심이 없었던 혹은 획득하기 어려웠던 정보들에 대한 관심이 전사적으로 높아지고 있는 실정입니다.

이러한 단계들이 생긴 이유도 결국은 시스템 자체가 커지고 복잡해졌기 때문인데요. 보다 효율적으로 부분 또는 전체를 제어/관리하기 위한 것입니다. 그러나 계층이 생기고 난 후, 계층 안에서 뿐만 아니라 계층 간의 통신 및 메시지 호환성 등에 문제가 발생하게 됩니다. 물론 어떤 제조 기업은 마치 하나의 시스템처럼 바닥부터 위까지 동일한 언어를 쓰는 완벽한 호환 시스템이나 직접 제작한 가상 시스템들로 자동화를 구성해서 사용할 수도 있겠죠.

그러나 사실 현실은 그렇지 못합니다. 레벨 별로 다소 다른 업계들에서 가상 시스템 애플리케이션을 개발하기도 하고, 단계적인 자동화 도입 및 추가로 설비를 확장하는 경우 또한 많은데요. 그러한 상황에서 어느 정도 업계의 대세를 따르려고 하겠지만, 계층별로 도입된 수많은 산업용 기기들 및 가상 소프트웨어들은 자신들만의 대화법을 갖고 있는 실정입니다.

위의 그림에서 보여주듯이 각 계층 사이에 존재하는 통신층에서 다른 계층의 시스템들과 통신을 하기 위해서 다양한 종류의 소프트웨어 인터페이스와 하드웨어 어댑터들이 이를 보조하고 있습니다. 이를 통해 상위 레벨(Master)이 하위 레벨의 기기 및 소프트웨어(Slave)를 제어/관장하는 식입니다. 즉 여러 프로토콜들의 표준화 문제는 제조 시스템 내에서도 존재해 왔고, 아직도 해결되지 않은 부분들이 많습니다.

앞서 제시한 토론 상황의 비유에서처럼 관점은 어쩔 수 없는 문제라고 해도 같은 언어라도 쓰게 된다면 최소한 대화라도 가능해지지 않을까 싶습니다. 이 또한 어렵다면, 번역을 위한 도구를 사용하거나 손짓, 발짓, 그림 같은 원시 언어 또는 초언어(Meta Language)를 사용해야겠죠.

그런데 그 초언어라고 주장하는 것들 또한 현재는 너무 많습니다. 그러나 앞선 글에서 언급한 사물인터넷(IoT)의 표준화 전쟁보다는 조금 상황이 나아 보이기도 합니다. 현재 상황은 피라미드 계층 사이에 존재하는 개별적인 통신층에서 어느 정도 표준화 혹은 대세로 정립된 메시지 통신 프로토콜을 이용하려는 형태로 운영되고 있습니다.

예를 들어, 그림에서 ‘3~4 레벨’ 사이의 메시지 통신은 XML과 흡사한 스키마의 B2MML(Business-to-Manufacturing Markup Language) 등으로 이루어지고, 1-2-3 사이의 통신 역시 XML 기반의 메시지 포맷을 기반으로 한 OPC(Object Linking and Embedding (OLE) for Process Control)나, OPC-UA (OPC의 업그레이드 버전), MTConnect 같은 표준화된 모델에서 정의하는 프로토콜을 따르려는 추세입니다.

그 중 앞의 글에서도 잠깐 소개한 MTConnect와 같은 프로토콜에서는 이러한 표준화된 형태로 변환/번역(Transformation/Translation)하는 과정을 기존의 컨트롤러에 API 형태의 인터페이스(그림에서 Interface 3,4,5,6)로 추가 사용하도록 유도하고 있습니다.

그러면 지금부터 각 레벨에 대해 조금 더 알아보려고 하는데요. 우선 오늘은 ‘레벨 0~레벨 1’을 살펴보겠습니다.

(1) 레벨 0

일단 공장 내의 무형의 기본적인 공정들과 그 공정들을 담당하는 물리적 개체들인 설비 자원(Equipment)들은 가장 하위의 단에 존재합니다.

앞서도 이야기했지만, 설비 자원과 공정 자체는 인간의 감각 기능 같은 것이 없는데요. 특히 프로세스형 제조에서는 연속된 시간 속에서 그 시작과 끝을 조절하여 밸브를 여닫고 합치는 과정에 있어서 많은 도움이 필요해 보입니다. 또한 이산형 제조에서도 마찬가지인데요. 하나의 기계 자원에서 어떤 공정이 끝나고, 또 다른 공정으로 바꾸기 위해서, 셋업을 조정하고, 다른 머신 프로그램을 로드하고, 혹은 하나의 공정에서 둘 이상의 기계 자원의 협업(예를 들어 공작 기계와 로봇) 및 동기화가 필요할 때, 의사 결정이 요구됩니다.

(2) 레벨 1

(Field Level and Control Level – 관점: 레벨 0 / 대상: 외부 자극, 기계의 세부 공정)

지난 번 글에서도 잠시 다뤘지만, 자동화의 최전방에 있는 기기들(센서, 액추에이터, 전기 모터, 콘솔 light, 스위치, 밸브, 컨텍터 같은 역할을 하는 컴포넌트들) 그리고 그들과 연동된 물리-가상 시스템이 이 레벨에 속합니다. 즉 기계들 및 프로세스에서 일종의 하드-소프트 인터페이스에 해당하며, ‘PLC(Master) – 센서 Nodes(Slave)’ 식으로 구성됩니다. 경우에 따라서는 하위 PLC나 산업용 PC, 기계의 내장 컨트롤러들을 관장하는 상위의 마스터 PLC를 두고 운영할 수도 있습니다.

앞서 제시한 그림을 참고한다면, PLC는 상위 레벨(주로 레벨 3 MES 등)에서 정의된 Part count, Scrap Count, Product ID, Operator ID, Production Order ID, Ideal Cycle Time, Shift, Available Indicator, Running Indicator, Downtime Indicator, Downtime Code 등의 항목들에 대해 센서나 기계들의 신호들을 이용하여 해당 정보를 수집 및 그 값에 따라 대상 개체를 제어하고 결과를 다시 상위 레벨로 전달합니다.

● Sensors for Data Collection, Inspection, and Control

이산형 제조에서는 대표적으로 근접 센서(금속 혹은 정전용량형)나 광전 센서가 가장 많이 사용되는 센서라 볼 수 있습니다. 프로세스형 제조에서는 그 밖의 물리 센서인 온도 센서 및 가스, 습도, 바이오 센서 등의 화학 센서들이 많이 이용되고 있습니다.

또한 가속도 센서, 미생물 센서, 압력 센서, 유량 센서, 각도 센서 등도 많이 사용되고 있는데요. 최근에는 스마트한 기능을 가지는 비전 센서나 바코드, Auto ID 리더 등 정보 데이터를 읽어 판별하는 기능의 센서들도 많이 사용되고 있는 상황입니다. 센서를 통해 수집된 정보는 사건들의 형태로 상위 제어 시스템 혹은 데이터베이스에 보고되거나 저장되어 왔는데요. 이러한 스마트 센서를 통해 이제 자체적으로 어느 정도까지의 판별이 가능해지고 있습니다.

특히, 많은 부품들이 필요한 자동차 공장이나 반도체, 휴대 전화 생산과 같은 이산형 제조에서는 단순히 온/오프, 물체의 유무 판독 기능을 벗어난 스마트한 비전 기술이 많이 응용되고 있는데요. 부품 유무 검출부터, 공급 장치의 부품 정렬, 코드 판독, 제품의 유닛별 이력 추적을 위한 코드 판독, 자동 부품 인식 및 검사 수행까지 가능하다고 합니다.

또한 머신 비전과 센서 그리고 스캐닝 기술들을 이용하기도 하는데요. 인간의 눈을 대신해 더 정교하게 제품과 공정에 대한 진단을 할 수 있을 뿐만 아니라, 시각적 서보 제어 기능은 물론 일부 고성능 제어 즉 로봇 혹은 모션 컨트롤에 필요한 연속적인 피드백 장치로 활용되기도 합니다.

지난 시간에 예로 다뤘던 상호 작용에서는 일일이 다른 개체들과의 메시지 교환을 거쳐야 했다면, 머신 비전을 통해서는 대상 공정에 필요한 정보 즉, 제어 및 생산 의사 결정에 필요한 정보를 바로 획득할 수 있습니다.

또한 반도체 공정과 같이 높은 정밀도를 요구하는 곳에서 공정 하나하나마다 절단된 칩의 사소한 결함도 정밀하고 정확하게 감지하고, 이 결과를 바탕으로 대상 공정에 대한 사후 조정, 즉 바로 바로 절삭 공정의 세부 파라미터를 조정하기도 하는 등의 지능형 제어가 가능합니다.

그 밖에도 레이저 변위 센서를 이용하여 센서 정보를 기반으로 한 생산 공정의 미세 조정이 가능합니다. 이는 표면 평탄도가 서로 다른 물체에 대한 작업, 높은 정밀도를 요구하는 의료 기기와 같은 제품, 툴의 마모 등으로 인해 제품의 미세한 특성 변화에 민감한 경우 등에서 기존의 CMM 등을 이용한 추가 샘플링 검사를 거치지 않고 바로바로 전 제품을 검사할 수 있다는 장점이 있습니다. 이러한 지능형 센서의 도입으로, 중복되는 불필요한 과정을 생략하여 시간을 절약하고, 효율성을 높일 수 있게 되는 것입니다.

● Ubiquitous Communication for Factory of Things (FoT)

사물인터넷(IoT)에 빗대서 표현하자면, 기계 및 현장 기기들과 같은 제조 시스템 내의 물리적 개체들을 모두 묶어서 우리는 ‘Factory of Things (FoT)’라고 명명할 수 있습니다. 물리적 개체와 직접 맞닿아 연결을 가능케 하는 Cyber-Physical 시스템을 통해서 어떤 조합이이라도 직간접적인 통신 및 상호 작용이 가능해지고 있습니다.

1. 서로의 통신은 원래 케이블로 연결된 단거리용 ‘Fieldbus(IEC 61158)’라는 형태로 현장 기계와 센서들, PLC 등이 연결되어 통신해 왔습니다. 그러나 새롭게 개발되는 장비 및 무선 센서들의 증가로 이 계층에서도 이더넷, 무선 통신 등에 대한 필요성이 증가하는 추세입니다. (피라미드의 붉은색으로 표시된 통신층)
2. 그 밖에 SCADA, DCS와 같은 상위 레벨 시스템들 및 그 이상 레벨과의 통신은 주로 유선의 Industrial Ethernet이 많이 사용되어 왔습니다. (피라미드의 노란색 및 녹색으로 표시된 통신층)
3. 그 밖에 생산 공정의 제어와 직접적으로 연관되지 않는 여러 활동들, 즉 재고 추적, 자원 관리, 보안 경보 및, 여러 이해 관계자들의 인터페이스가 될 수 있는 모바일 기기들과 같은 필드레벨 기기들과 다른 제조 시스템 계층들 사이의 직접적인 연동이 많아지고 있습니다. 이러한 활동들에 대한 통신은 RFID tag 등을 이용해 바로 M2B로 연결되거나, 피라미드에서 ‘Interface 1 – Interface 8’ 이나 ‘Interface 3 – Interface 6’과 같은 SOA 인터페이스 쌍을 이용해 Wi-Fi 연결로 이루어지고 있습니다.

또한 3G, LTE 등을 이용해 장거리 통신망을 이용하거나, 공장 내에서는 Zigbee와 같은 단거리 라디오 통신을 이용하기도 합니다. 아래 표를 참고해 주시기 바랍니다.

그러나, 세계적으로 필드 버스에 기반한 기기들 수는 2010년의 1억 8천 3백만 개에서 2015년에는 두 배 가까이 증가한 3억 2천 6백만 개에 이를 것으로 전망하고 있습니다. 반면 산업용 이더넷에 기반한 필드 레벨 기기 수는 2015년에 천 8백만 개 정도가 사용될 전망입니다 .1

이런 통계에서도 알 수 있듯이, 아직도 기존 기기들과의 호환성, 사용의 편리함, 보안, 가격 등의 이유로 인해 전통적 필드 버스에 기반하는 기기의 수가 압도적으로 많은 수를 차지하고 있습니다. 차차 공장 현장도 이더넷, 무선 등으로 바뀌어 나갈 것으로 예상하지만, 당분간 공장의 필드 레벨에서 통신 체계로 필드 버스는 계속해서 사용될 가능성이 높습니다. 피라미드의 아랫단을 점유하는 필드 개체 노드의 수가 윗단의 SCADA 등의 가상 시스템에 비해 월등히 많기 때문에, 이 사실은 결국 이질적인 통신 층 간에 교량 역할을 할 하드웨어 및 소프트웨어의 인터페이스를 통해 해결되길 요구하고 있는 실정입니다.

FoT의 통신은 그 동안 일반적인 사물인터넷(IoT)에서 이야기 하는 M2M의 특수한 형태라고 볼 수 있습니다. 공장이라는 제한적이고 다소 폐쇄적인 공간에서 이루어져 왔지만, 최근의 추세가 제조 환경 내에서 발생하는 데이터들에 대한 전사적인 가시성 및 보다 오픈된 환경으로의 확장성 즉, M2M에서 M2E(Machine-to-Enterprise)나 M2B(Machine-to-Business)까지 요구되고 있는 실정입니다.

개별적인 개체들 및 다른 층의 시스템들과의 상호 작용을 위해서는 더 높은 수준의 상호 운용성(Interoperability)이 필요한데요. 결국 그 표준화의 방향성은 공장이란 폐쇄 환경에 중점을 두었던 제조 시스템 특화에서 점차 IT 관점의 Service Oriented Architecture로의 변화를 요구하고 있는 추세입니다. 그러할 경우 마치 동전의 양면처럼 추가적인 보안 문제 등에 대한 고려가 뒤따라야 할 것으로 보입니다. 진화하는 FoT에 특화된 상호 운용성을 보장하기 위하여 다음과 같은 두 가지 방법이 많이 사용되고 있습니다.

첫번째로 표준화 모델을 기반으로 한 가상 Agent/API 등을 활용한 통신/번역 인터페이스를 이용한 소트트웨어적인 방법이 있겠습니다. 앞서 소개한 OPC-UA(XML 메시지 포맷과 .NET/SOAP등을 기반으로 함)나 MTConnect(역시 XML 데이터 포맷과 RESTful 인터페이스를 기반으로 함) 등이 SOA를 위한 인포메이션 모델/메시지 표준화의 좋은 예라고 볼 수 있습니다.

위의 그림에서처럼 Client-Server 구조를 기반으로 하여 공통의 인터페이스를 각각의 하드웨어 개체(예를 들어 어떤 CNC머신에 대해)에 대해 만들어서 이 공통의 인터페이스를 다른 계층에 있는 여러 가상 시스템에서 클라이언트로 재사용하기 위한 모델이자 프로토콜이라 할 수 있는데요. 즉 위의 오른쪽 그림에서처럼 필드 레벨의 물리 개체들(Things)에 해당하는 기계들의 데이터를 제공하는 서버를 기계 컨트롤러 등에다 추가하고, M2M뿐만 아니라, M2B, B2B 등, 제조 시스템 내의 모든 가상 물리 시스템의 인터페이스들끼리 동일한 프로토콜로 대화를 가능하게 하는 방법입니다.

또 다른 방법으로는 위의 그림에서처럼 통신층 사이에 일종의 보편적 가상-물리 Gateway를 두어 범용 마스터 컨트롤러 등의 역할을 수행하게 할 수도 있습니다. 그 안에 I/O 통합 및 스위칭 등의 하드웨어적 인터페이스뿐만 아니라 필드 버스, 이더넷, 와이파이 등을 모두 포괄하는 기능 및 데이터 통합 변환 기능까지 추가하고 있는데요. 앞서 소개한 PAC 등의 PC-based 시스템이 이러한 통합 기능까지 제공하는 솔루션으로 현재 많이 개발/출시되고 있는 상황입니다.

지금까지 제조 시스템의 지능화를 가능하게 하는 자동화 단계 중, 일부 내용과 각각의 단계 속에서 시스템 내의 종적인 흐름을 통합하는 IT 역할에 대해 살펴보았습니다. 이어서 다음 시간에는 자동화 단계의 나머지 부분들의 세부 내용을 함께 알아보겠습니다.

l 글 이승엽 연구원