2008. 10. 23. 20:42

디바이스 미들웨어 - 로컬 컨트롤러

디바이스 미들웨어의 시스템 구축 아키텍처를 좀더 자세히 들여다 보도록 하겠다. 디바이스 미들웨어가 가져야 하는 성능이나 기능 요소에 대해서는 앞에서 여러번 논하였는데 이제는 이것을 어떻게 써야 하는가에 대한 이야기를 하겠다. 대부분의 사람들은 디바이스 미들웨어를 현장에 구축할때 <그림1>과 같은 구성을 한다.

사용자 삽입 이미지
<그림1> 서버형 디바이스 미들웨어 구성

우선 산업 현장에 대한 이해부터 해야 하는데 PLC, RFID 리더, 바코드 스캐너, 작업자 단말, PC 기반 기계 컨트롤러 등 다양한 형태의 디바이스들이 산업 현장에 있고, 이러한 데이터 발생원으로부터 갖가지 데이터를 수집하고 관리하는 상위 애플리케이션은 잘 관리되는(무정전 상태, 보안 관리 등) 전산실 또는 외부의 전산센터에 놓이게 된다. 이렇듯 디바이스가 놓이는 현장과 상위 애플리케이션이 놓이는 전산실은 원격에 위치하는 것이 일반적이고 (심지어는 서로 다른 나라에 놓이기도 한다.) 따라서 이를 연결해 주는 통신 매체로는 TCP/IP를 사용하는 이더넷(Ethernet)을 사용하는 것이 일반적이다.

이때 애플리케이션과 디바이스들의 연결을 위해 디바이스 미들웨어를 <그림1>과 같이 서버 형태를 취하도록 구성하여 상위 애플리케이션과 같이 전산실에 두고 디바이스를 연결하는 구성을 하였다고 생각해 보자. 이 경우에 디바이스 미들웨어에게 필요한 기능 요소와 장단점은 어떤것이 있을까? 우선 디바이스 미들웨어는 한꺼번에 몇개의 장비와 연결될 수 있을것인가가 매우 중요한 기능 요소일 것이다. 왜냐하면 하나의 서버형 미들웨어에 한꺼번에 많은 장비들이 물리게 되므로 이들이 한꺼번에 데이터를 쏟아 낼 경우 성능에 문제가 없어야 하기 때문이다. 따라서 초기의 RFID Middleware 업체들이 한번에 100개, 200개의 리더를 붙이는 기능을 제공한다 등으로 얘기를 하곤 했었다. 즉 한번에 몇개의 리더를 동시에 연결할 수 있느냐가 중요한 기술 척도가 되었다.
하지만 이 경우 아무리 성능 좋은 미들웨어라고 하더라도 기본적으로 디바이스에서는 가공되지 않은 원시 데이터(raw data)를 실시간으로 뱉어 내기 때문에 동시에 여러 장비를 실시간성 훼손없이 좋은 성능을 발휘한다는 것은 물리적으로 불가능한 일이다. 게다가 전산실 네트워크에 몰려드는 수많은 데이터 트래픽을 감당하는 것은 매우 끔찍한 일이다.

또한, 모든 디바이스들이 TCP/IP를 지원하지도 않는다는 사실이다. TCP/IP는 허브와 스위치 장치를 통해서 아무리 원격에 있더라도 서로간의 통신하는데 문제가 없다. 하지만 RS-232C와 같은 시리얼 통신이나 전기적 신호만을 이용한 접점 연결 방식등에는 양 호스트가 연결되는 물리적인 거리 제한이 있으며, 아무리 그 전기적 신호를 증폭한다고 하더라도 별도의 공사비용 등으로 인해 원격 연결은 불가능하다. 따라서 대안으로 사용하는 방법이 시리얼 통신을 TCP/IP로 바꿔주는 컨버터를 쓰는 방법이다. 하지만 연결 포인트가 늘어날수록 에러의 발생 확률도 높아지고 또 작은 장비 하나가 전체 연결 흐름을 막을 수 있는 위험 요소가 되기 때문에 장기적인 차원에서 그리 좋은 방법이 아니다.

그리고 하나의 디바이스 미들웨어에 여러가지 장비가 한꺼번에 연결되면 우선 이 미들웨어가 죽게 되었을때 문제가 발생하므로 일반 서버에서 사용하는 장애 대책으로 보조 장비를 하나 더 두어서 Fail Over 시키는 방법 등을 쓰게 되므로 비용과 아무리 잠깐이라도 다운타임 동안의 데이터 유실 등에 대해서는 심각하게 고민해야 하는 문제이다. (모든 장비가 한꺼번에 연결되어 있으며 각 장비들은 초당 수백개의 데이터를 뱉어 낼 수도 있기때문에 1초동안만 연결이 끊어졌다 하더라도 막대한 손실이 일어날 수도 있다.)


하지만 디바이스 미들웨어의 시각을 다른 시각에서 한번 바라보자. 이것을 서버의 개념이 아니라 디바이스들과 같은 레벨에 있다고 하고, 여러 디바이스들을 대표하는 하나의 대표 디바이스라고 생각해 보자.

사용자 삽입 이미지
<그림2> 디바이스형 미들웨어 구성

<그림2>를 보면 디바이스 미들웨어의 위치가 전산실이 아닌 현장으로 내려와 있음을 알 수 있다. 하지만 이것은 단순히 위치만의 문제가 아니다. 우선 이것은 단위 공정별로 그룹핑을 함으로써 분산형으로 시스템 구성이 됨을 알 수 있다. 즉, 1라인의 A공정 설비들만 묶어서 A 미들웨어에 연결하고 B공정 설비들은 B 미들웨어에 연결하는 식이다.
이런 구성의 장점은 각 단위 공정별 묶음으로 관리하기 때문에 논리적, 물리적 시스템 분리가 되기때문에 한 공정의 문제가 다른 공정에 영향을 주지 않는다는 사실이다. 이것은 중앙 집중적인 시스템 구성보다 분산형 시스템 구성이 갖는 장점, 즉, 확장성과 성능 분산, 복잡성 완화 등의 특징을 가질 수 있다는 것과 서로 다른 공정에 각각 적용할 수 있는 단위 로직을 쉽게 적용하고 관리할 수 있다는 장점도 얻을 수 있게 된다.

물리적인 위치도 통신하는 디바이스와 인접하게 되므로 원격 접속 과정에 발생할 수 있는 전기적 신호의 손실도 방지할 뿐 아니라 별도의 컨버터를 사용하지 않으므로 컨버터에서 발생할 수 있는 에러 요소를 없앨 수 있다. 또한 연결되는 디바이스의 수도 단위 공정별로 한정되기 때문에 데이터의 양 또한 전체 공정을 모두 모은 것에 비하면 훨씬 적기 때문에 실시간성이 보장되며 여러가지 특정 로직을 구현하기가 수월해 진다. 따라서 이 디바이스 미들웨어는 한번에 몇개의 디바이스를 연결할 수 있느냐는 관심 사항이 아니며 얼마나 빨리 많은 로직을 적용하여 상위 시스템의 부하를 줄여 줄 수 있느냐가 더 큰 기능 요구 사항이 된다.

이런 디바이스 미들웨어는 일반 PC나 서버에서 동작하는 소프트웨어 형태가 아니다. 위에서 밝힌 것처럼 이것은 소프트웨어라기 보다는 하나의 다른 디바이스 개념이어야 한다. 따라서 척박한 현장에서 잘 견딜 수 있도록 산업용 요구사항을 만족하여야 하며 별도의 모니터가 필요 없을 수도 있다. 일반적으로 하드웨어형 또는 임베디드 미들웨어라고 부른다. 최근에는 RFID 리더 내부에 내장하기도 한다.

또하나 생각해 봐야 할 것은 현장 네트워크와 상위 네트워크의 분리 문제이다. 디바이스들과 상위 서버가 모두 같은 네트워크에 있다고 하면 어떤 특정 호스트가 지나치게 많은 트래픽을 발생시키거나 (웜이나 바이러스가 발생했을 경우를 상상해보자) 전체 네트워크가 다운되었을 경우에는 모든 데이터가 손실될 것이다. 하지만 산업 현장에서는 어떠한 경우라도 데이터의 손실만은 최소한으로 막아야 한다. 이를 위해서 하나의 디바이스 미들웨어를 기준으로 랜카드를 두개를 사용하여 하위 디바이스들끼리는 별도의 로컬 네트워크를 형성하여 연결하고 디바이스 미들웨어가 상위 애플리케이션과 연결된 네트워크에 참여하는 형태로 시스템을 구성하여야 한다. 이렇게 하면 네트워크 성능 보장과 안정성 두마리 토끼를 한꺼번에 잡을 수 있다.

하지만 이 역시 디바이스 미들웨어가 죽는다면 문제가 될 것이다. 그렇다고 하더라도 하나의 미들웨어가 다운되면 해당 공정에만 영향을 받지 다른 공정에는 문제가 없을 것이다. 물론 디바이스 미들웨어가 어떠한 경우라도 다운되는 경우는 없어야 한다. 이를 위해 별도의 보조 장비를 두는 것은 그리 좋은 방법은 아닌 것 같다. 왜냐하면 일단 전체 비용이 너무 상승하게 되고 아무리 보조 장비를 둔다고 하더라도 완벽한 해결책은 아니기 때문이다. 대신에 이 장비가 죽었음을 관리자나 작업자에게 최대한 빨리 알릴 수 있는 기능을 제공하고 현장에서 간단하게 리셋 버튼 하나만 누르는 등의 방법으로 해결이 되는 기능을 제공하는 것이 훨씬 나을 수 있다. 부팅 시간이 너무 오래 걸린다든지 하는 것도 안된다.

또하나 예상되는 문제점은 너무 많은 장비가 현장에 있음으로 해서 관리하기 어려울 수도 있는데 이를 위해서 원격 감시 툴을 제공하는 것이 매우 중요한 기능 요소이다. 관리자가 자리에 앉아서 전체 미들웨어의 상태와 그 밑에 연결된 장비 상태들을 확인하고 또 문제가 발생하면 메일이나 휴대폰 문자로 알려 주는 등의 기능을 제공한다면 매우 편리할 것이다.


시범사업이나 1회성 파일럿 프로젝트로 진행하는 것과 지속적으로 유지보수가 필요한 산업 시스템을 구성하는 것에는 많은 차이가 있다. 당장 눈앞에 보이는 것만 된다 안된다로 판단할 것이 아니라 지속적으로 운영할 것에 초점을 맞추어야 한다. 문제는 지속가능성(Sustainability)이다.
Trackback 0 Comment 0