필드 디바이스 정보를 클라우드로 전송하는 3가지 방안

지난 3월 전시회와 세미나를 하면서 많은 고객들이 IIOT(산업용사물인터넷, Industrial IoT)에 대한 기술적 수준이 높아졌다는 것을 느꼈다. 많은 사람들이 IIOT나 Industrie 4.0의 필요성이나 그 적용방안에 대해 실제적인 고민을 하기 시작했다는 것이다. 아마도 다양한 회사에서 자사 제품을 활용한 적용 실적을 발표하고 있고, 그 내용들이 다양한 매체를 통해 기사화되면서 표면적으로 더 많이 접할 수 있었기 때문이라고 판단된다. 하지만 그 적용 실적들을 자세히 살펴볼 필요는 있을 것 같다. 많은 경우 IIOT 제품이나 솔루션을 제공하는 회사에서 시장의 분위기 형성이나 홍보를 목적으로 IIOT와의 연관성이 모호한 프로젝트를 마치 새로운 기술이 적용된 시스템의 성공사례로 보도하고 있는 경우가 있기 때문이다. 또한 사용자의 입장에서는 보도되는 내용만으로는 시스템의 구조나 주요 기능들에 대한 파악이 어려운 경우가 많다.

이런 이유로 사용자는 시장의 변화를 감지하긴 하지만 실제적으로 어떻게 변화하고 있는지, 이를 위해 자신의 회사는 어떤 준비를 어떻게 해야 하는지에 대해서는 아직도 많은 의문점을 가지고 있는 것이다. 앞선 두 번의 칼럼에서 이더넷(Ethernet) 기반의 통신과 MQTT (Message Queue Telemetry Transport)와 OPC UA (Open Productivity and Collaboration Unified Architecture)에 대해서 먼저 언급한 이유도 IIOT를 준비하는 사용자의 입장에서 필요한 기반 지식이라는 측면에서 시간을 할애하여 설명했던 것이다. 이를 기반에 두고 이번 시간에는 데이터의 전송 방안에 대해서 생각해 보고자 한다.

어떤 데이터를 클라우드로 전송할 것인가? 어떤 방법으로 필드데이터를 클라우드로 전송할 것인가? 현재 설치되어 있는 시스템을 기반으로 구성이 가능한가? 투자를 최소화 할 수 있는 방안은 무엇인가? 클라우드로 전송되기 전에 데이터를 가공하여 사용할 수는 없는가? 수 많은 사용자들로부터 이와 같은 질문을 받고 있다. 물론 이런 질문을 할 정도의 사용자라면 이미 IIOT에 대한 기본적인 고민이 있었다고 할 수 있다. 흔하고 단순한 질문처럼 보이겠지만 시스템에 대한 그림을 그려본 사람이라면 누구나 가지게 되는 질문들이다. 궁극적으로 우리가 말하는 스마트 팩토리(Smart Factory)는 무엇을 하기 위한 것인가? 과연 어느 수준의 시스템이면 이를 잘 반영하고 있다고 말할 수 있는 것인가? 저는 그에 대한 답변을 유명한 영화의 한 장면을 예를 들어 설명하고자 한다.

마블의 유명한 시리즈 중 하나인 어벤저스2를 보면 전투에 참여했던 아이언맨 로봇이 주인공 중의 한 명인 토니 스타크의 빌딩으로 복귀하는 장면이 나온다. 복귀를 한 후 다른 로봇이 전투에 참여했던 로봇을 스캔하여 고장나거나 부서진 부분을 확인한 후 수리를 하고 이들 로봇은 다시 대기장소로 보내진다. 또 다른 장면에서는 로봇이 폐기된 부품을 모아 또 다른 로봇을 만드는 장면이 나온다. 아마도 이 두 장면이 현재 우리가 추구하고자 하는 스마트 팩토리의 최종 목적지이지 않을까 생각된다. 생산라인의 자동화 설비들은 프로그램 되어진 대로 제품을 생산하고 생산 중 자재수급이 필요할 경우 AGV(Automatic Guided Vehicle)가 자동창고에서 스스로 자재를 반출해 필요한 위치에 공급한다. 생산 설비가 고장 났을 경우에는 기기간의 통신을 통해 고장이나 파손부위를 확인하고, 이를 수리로봇이 스스로 수리하거나 새로운 제품으로 교체하는 시스템이 IIOT를 활용한 스마트 팩토리 최종 모습의 한 단면일 것이다.

물론 아직은 현실적으로 불가능한 부분이 있다. 예를 들어, 고장의 진단은 자동으로 가능하나 고장 제품의 교체는 많은 경우 사람의 손을 빌려야 한다. 그리고, 새로운 제품이 연결이 되면 클라우드와의 통신을 통해 기존에 클라우드에 저장된 파라메터를 자동으로 다운로드 받아 즉시 구동이 가능하게 할 수 있다. 하지만 이런 부분들 또한 아직 준비중인 단계이다. 그렇다면 미래의 Smart Factory를 위해 우리는 어떤 것부터 시작해야 하는가? 앞서 언급했던 질문에 대한 답변을 하나씩 찾아 보기로 하자.

현재 우리가 공장에서 사용하고 있는 시스템을 간단하게 표현하면 아래의 그림과 같이 표현할 수 있다. 제어기를 중심으로 하드와이어링, 필드버스 또는 리얼타임 이더넷(Real-Time Ethernet)을 통해 로봇, 서보 드라이버, 인버터, IO 디바이스, 센서, 액추에이터 등이 연결된다. 이렇게 연결된 시스템은 제어기의 명령에 따라 동작을 하거나 로봇처럼 별도의 프로그램에 의해 동작을 하다가 필요한 경우 전체 시스템을 제어하는 제어기로부터 명령을 받아 다음 동작을 수행하게 된다. 이와 같은 현재의 시스템에서 발생하는 데이터를 그림의 상단에 있는 클라우드로 올리는 것이 IIOT 활용의 시작이다. 현재의 시스템에서 데이터를 클라우드로 올리는 가장 간단한 방법은 제어기를 직접 클라우드로 연결하는 것이다. 제어기가 PC가 아니라 PLC 혹은 DCS라고 하더라도 이더넷 포트(Ethernet port) 또는 이더넷 모듈(Ethernet module)은 존재한다. 이를 통해 클라우드로 연결하는 것이 가장 간단한 방법이고, 또한 투자비용도 가장 줄일 수 있는 방법이다.

하지만 몇 가지 제약사항이 따른다. 현재의 시스템이 리얼타임 이더넷을 사용하는 시스템이라는 가정하에 설명하겠다. 제어기가 가지고 있는 각 필드 디바이스의 정보는 크게 3가지이다. 첫번째는 각 디바이스가 가지는 IO 데이터의 Size이다. Master가 자신의 네트워크를 Configuration하기 위해서는 각각의 Slave가 가지는 입력과 출력 데이터가 각각 몇 바이트인지 반드시 알아야 한다. 이와 같이 각 필드 디바이스의 IO Size가 제어기가 가지는 첫번째 정보이다. 두번째는 특정 필드 디바이스가 가지는 파라미터이다. 예를 들어 필드 디바이스 중에 온도제어기가 있다고 한다면 각 온도제어기의 설정값을 제어기가 알고 있어야 한다. 물론 온도제어기 스스로 설정 값을 저장하는 기능도 있지만 일반적으로 제어기에서 각 디바이스의 설정 값을 저장하고 있다가 필요 시 설정 값을 디바이스로 전달한다. 세번째 정보는 각 디바이스의 진단정보이다. 리얼타임 이더넷 통신을 하면서 각 디바이스가 정상적으로 통신이 되는지, 통신 이상이 발생했을 경우 몇 번 Station에서 발생했는지 어떤 종류의 Error가 발생하였는지와 같은 진단정보가 제어기의 세번째 정보인 것이다.

그렇다면 이 세가지 정보를 클라우드로 올려주면 IIOT 기능을 충실히 따르는 것일까? 클라우드에서 각 디바이스의 IO Szie나 설정값, 진단정보가 필요할까? 이 정보들을 받아서 빅데이터로 만드는 것이 유의미한 것인가? 일반적으로 제어기가 가지는 각 필드 디바이스의 정보양은 최소한으로 제한을 하는 경우가 많다. 이는 시스템의 안정성과 관련이 있다. 제어기는 시스템의 구동을 효율적이며 안정적으로 하는 것에 그 목적이 있다. 제어기가 처리해야 하는 정보의 양이 많아지게 되면 그와 비례하여 프로그램의 양이 많아지게 되고, 이는 프로그램의 Cycle Time에 영향을 주게 된다. 또한 필드 디바이스가 기존의 3가지 정보외에 자신의 CPU 온도, Motor의 온도, 가동시간, 정지시간, 실제 구동시간, 대기시간 등 제공할 수 있는 모든 정보를 기존의 리얼타임 이더넷 통신 라인을 통해 실시간으로 전송하게 되면 통신시간 또한 느려지게 된다. 제어기의 Cycle Time과 통신 시간이 느려지게 되면 시스템의 운영에 영향을 미치게 되고, 이는 불량품의 발생이나 생산량의 저하와 같은 부작용으로 이어진다. 필드 데이터를 클라우드로 전송하기 위한 부수적인 기능의 추가로 인해 시스템 본래의 목적인 생산에 지장을 받게 되므로 주객이 전도되는 결과를 가지게 되는 것이다.

기존의 제어기를 사용하여 클라우드로의 접속을 구현하려고 한다면 먼저 어떤 데이터를 클라우드로 올릴 것인지 선정하여야 한다. 각 필드 디바이스는 많은 종류의 부가적인 정보를 제공하고 있으며, 이 모두를 클라우드로 전송하는 것은 시스템의 변경없이는 불가능하다. 어떤 데이터를 수집하여 빅데이터화 한 후 어떤 결과를 도출하려고 하는지 먼저 결정한 후에 각 디바이스들로부터 추가로 데이터를 수집해야 한다. 또한 수집되는 데이터의 양으로 인해 시스템의 제어에 영향을 주지 않는 통신 속도를 찾아야 한다. 많은 경우 디바이스의 3가지 기본 정보외에 추가 정보는 데이터의 사이즈가 크고, 모든 디바이스들로부터 수집되어야 하기 때문에 그 총합은 기존 데이터 용량보다 훨씬 클 수가 있다. 또한 수집된 데이터를 처리하기 위해서 프로그램도 추가되어야 하는데, 프로그램 또한 Cycle Time에 영향을 주지 않는 범위내에서 늘려야 한다. 기존의 시스템을 그대로 사용하여 투자비용을 최소화한다는 장점이 있는 반면에 수집할 수 있는 데이터의 용량에 제한이 있다는 점이 사용자에게 있어서 단점이 될 것이다.

두번째 방안은 필드 디바이스를 직접 클라우드로 연결하는 것이다. 이를 위해서 각각의 필드 디바이스는 IIOT 기능, 즉 MQTT나 OPC UA와 같은 프로토콜을 채택하고 있어야 한다. 앞서 예를 든 것과 마찬가지로 리얼탕미 이더넷 통신 라인을 통해서 MQTT와 OPC UA를 즉시 사용할 수 있으므로 시스템 구조상에서 크게 추가되거나 변하는 것은 없다. 다만 클라우드로 연결이 필요한 필드 디바이스의 변경이 요구된다. 단순하게 설명해서 필드 디바이스에 IIOT 기능을 부여하는 것이지만 이는 결코 단순한 문제가 아니다. 각각의 필드 디바이스들은 고유의 기능과 특성을 가지고 있다. 단순한 IO Device를 제외한 단축 모션 제어기, 서보 드라이버, 온도제어기, 용접기, 유압 또는 공압 제어기, 로봇 제어기 등과 같은 디바이스들은 해당 메이커에서 IIOT 기능을 제공하지 않으면 사용자 입장에서는 적용이 거의 불가능하고, 다른 메이커에서 해당 기능을 가지는 유사한 제품이 있다고 하더라도 그 제품으로의 전환 또한 간단치 않다.

옵션 모듈이나 옵션 보드화되어 기존 제품에 장착하여 사용할 수 없는 경우에는 클라우드로의 연결이 필요한 모든 제품의 교체가 요구될 수도 있다. 하지만 이렇게 하면 제어기가 데이터를 수집할 필요가 없고, 표준 이더넷 TCP/IP를 사용하기 때문에 기존 시스템의 속도가 느려진다거나 하는 부작용은 없다. 클라우드와 필드 디바이스 간에 어떤 데이터를 공유할 것인지에 대한 설정을 하면 자동적으로 필요 데이터가 클라우드로 전달이 된다. 이렇게 전송되는 데이터는 클라우드로 도달되기 전에 가공하거나 먼저 사용할 수 없다는 단점이 있다. 또한 모든 데이터가 전송되기 때문에 경우에 따라서 불필요한 데이터까지 모두 취합되고 이것은 클라우드 저장 공간의 비효율성을 초래할 수도 있다.

마지막 세번째 방안은 엣지 게이트웨이(Edge Gateway)를 사용하는 것이다. 엣지 게이트웨이는 IT(정보기술) 영역과 OT(운용기술) 영역의 양끝단에 위치하며, 두 영역을 연결시켜 주는 역할을 한다. 제품에 따라서 수집된 데이터를 아무런 가공 없이 전송하는 역할을 하거나 별도의 프로그램을 통해 일부 데이터의 가공과 그 결과에 따른 특수한 동작을 할 수도 있다. 엣지 게이트웨이를 사용하는 방안에 대해서는 다음 시간에 자세히 알아보도록 하겠다.

원일민 / 힐셔코리아 대표

[원일민 칼럼]
산업용 사물 인터넷(IIOT)과 INDUSTRIE 4.0 (1)
통신기술 융합 산업용사물인터넷을 통한 산업현장의 변화

산업용 사물 인터넷(IIOT)과 INDUSTRIE 4.0 (2)
MQTT와 OPC UA 통신을 통한 산업용사물인터넷(IIoT) 구현

산업용 사물 인터넷(IIOT)과 INDUSTRIE 4.0 (3)
필드 디바이스 정보를 클라우드로 전송하는 3가지 방안