'시스템 아키텍처'에 해당되는 글 4건

  1. 2008.10.23 엔터프라이즈 시스템 아키텍처
  2. 2008.10.23 디바이스 미들웨어 사용 아키텍처 - ALE 정확히 알기
  3. 2008.10.23 디바이스 미들웨어 - 로컬 컨트롤러
  4. 2008.07.08 RFID 포털 시스템
2008. 10. 23. 20:44

엔터프라이즈 시스템 아키텍처

RFID 시스템 구축에 들어가며

RFID 시스템을 구축하기 위해서 많은 사람들은 우선 UHF RFID를 찾아서 공부를 하는 것 같다. RFID 태그와 리더, 프린터라는 것이 있다는 것을 알고, 전파를 통한 인식에 대해 이해하게 된다. 그러면서 EPC 라는 용어와 EPCglobal Network에 대해서 이해하면 이제 어느 정도 RFID를 안다고 여기게 되고 또한 "표준이 매우 중요하다" 라고 결론 짓는다. 그리고 응용 시스템 구축을 위한 기능에 대해 고민하고 조금 더 생각하면 웹 연동 기술과 웹서비스 같은 방안에 대해서 고민하면 매우 전문가가 되는 것이다. 보안이나 권한 문제는 글로벌한 개념을 고민할 때 중요한 이슈이다.

하지만 이러면 모든 준비가 다 끝난 것일까? 실제로 현장에서는 그럼에도 불구하고 제대로 시스템 운영이 되지 않는 경우가 허다하다. 굳이 RFID가 아니라고 하더라도 한때 ERP 시스템 구축이 유행처럼 번지던 때가 있었으니 대기업들이 ERP를 구축하여 어느정도 성과를 보이게 되자 타겟을 중소기업으로 돌려 너도나도 (혹은 정부 지원금으로) ERP를 구축하였다. 하지만 이때 위와 같은 고민이 똑같이 나타나게 되었다.

그것은 바로 현장에서 제대로 된 데이터가 들어오지 않는다는 어찌보면 우습기까지 한, 너무나 당연하면서도 너무도 중요한 사실을 망각한 결과이다. 왜 제대로 된 데이터가 들어오지 않았을까? 이 점을 자세히 들여다 보기 위해 우선 기업 환경에서 구축하는 시스템의 구조를 자세히 들여다 볼 필요가 있다.

2차원 엔터프라이즈 시스템 아키텍처

2차원 엔터프라이즈 아키텍처

그림1. 2차원 엔터프라이즈 아키텍처

<그림 1> 2차원 엔터프라이즈 아키텍처


기업에서 어떤 애플리케이션을 구축한다고 하면 사람이 화면을 이용해서 DB에 들어 있는 데이터를 어떻게 잘 꺼내 쓸 것인지를 고민하게 된다. 사람이 동시에 몇명이 접속을 해야하고 UI는 웹으로 할 것인지 C/S 환경이 될 것인지, 이를 DB에서 잘 꺼내서 보여 주기 위한 방법으로 WAS 를 어떻게 잘 구성해야 하는지 또는 트랜잭션 처리를 잘하기 위한 미들웨어를 써야 할지 말아야 할지, 쓴다면 어떻게 써야 할지 등등... 이것은 <그림 1>에서 수평축으로 표현된 데이터 소비 축이라고 얘기할 수 있다.

하지만 이것보다 더 근본적인 문제가 하나 더 있었으니 이것이 바로 위에서 얘기한 실패 사례의 해답이다. 그것은 바로 우리가 꺼내 쓰고자 하는 DB에 데이터가 잘 들어 가 있어야 한다는 것이다. 너무도 당연한 이야기이지 않는가? 좋은 데이터를 잘 꺼내서 보기 위해서는 좋은 데이터가 제때에 잘 들어가 있어야 하지 않겠는가? 하지만 이것이 생각보다 쉽지가 않다. 이 축을 수직축, 데이터 공급 축이라고 정의하겠다. 이 수직축은 자동화라는 개념이 도입된 때부터 있어 왔기 때문에 그 역사는 매우 길다. 그럼에도 불구하고 일반적으로 많은 사람들이 바로 이 수직축을 무시하기 때문에 수평축에 데이터 공급이 잘 안되는 결과가 만들어 지는 것이다.

그것의 원인을 찾아 보자면, 우선은 이 수직축은 수평축에 비해 기술적 난이도가 매우 높다. 보통 수평축에 있어서 사용자의 반응성은 3초 이내면 어느정도 괜찮다고 평가를 한다. 그리고 몇만명의 동시 사용자라고 하더라도 이건 연결된 세션의 수이다. 하지만 수직축은 사람이 입력하는 데이터일 수도 있지만 보통은 자동화된 기계에서 올라오는 데이터가 더 일반적이다. 기계는 하나가 1초에도 수백개가의 데이터를 쏟아 낼 수도 있고, 그 크기도 몇백 바이트가 넘을 수도 있으며 하나의 공장에서도 몇수십 만개의 기계나 컨트롤러가 접속될 뿐 아니라 종류도 예측이 불가능할 정도이며 접속 방법 또한 매우 다양하다는 사실이다. 따라서 이런 복잡하면서도 어려운 시스템을 잘 만들어 내는 것이 쉽지 않고 기계를 상대로 하다보니 소프트웨어 뿐 아니라 하드웨어에 대한 지식이 뛰어 나야만 하다.

하지만 이를 수행하는 작업 환경은 매우 열악해서 수평축의 개발자들이 비록 밤을 새고 힘들게 작업을 하고는 있지만 주로 전산실 사무실에 앉아서 작업을 하는 반면에 수직축에서 일하고 있는 개발자들은 현장을 누비고 다녀야만 한다. 그 작업 현장이라는 것이 100% 청정을 요구하는 반도체 공장에서 부터 쇳물을 녹이는 용광로까지 그 종류도 일일이 열거할 수 없을 정도이다. 이러한 환경에서 에러 없는 데이터 수집을 위해서는 몇일 밤을 새는 일이 허다하다 보니 (심지어는 이런 작업 환경에서 에러를 잡다가 잠시 졸아 목숨을 잃는 개발자도 있다.) 실로 목숨을 건 사투를 벌이는 일임에 틀림없다.

그것 뿐인가? 이런 고생을 하는 엔지니어의 몸값은 거의 제 값을 받지 못한다. 대부분의 회사들은 장비나 기계는 돈 주고 살지언정 그것을 움직이는 소프트웨어에는 공짜라는 인식이 뿌리박혀 있다. 따라서 소프트웨어 가격을 장비 가격에 포함시켜 겨우 받고는 하는데 문제는 이것도 경쟁이 심하다 보니 서로 제살을 깎아서 그 비용을 너도나도 줄이게 되는 것이다.

상황이 이럴진데 경험이 풍부하고 똑똑한 개발자들이 남아 있겠는가? 그러다 보니 악순환이 반복되어 수직축에 대한 인식도 제대로 되지 않았을 뿐 아니라 발전도 그만큼 되지 않았다고도 할 수 있을 것이다. 이것에 대한 완성도가 높지 않으므로 데이터의 신뢰성 부족 때문에 결국 수평축의 가장 끝단에 놓여진 사람에게까지 정보 전달이 되지 않는다고 볼 수 있다.

수평축과 수직축에 놓여진 각각 단위 단위 레이어를 살펴 보면 매우 유사함을 알 수 있다. 단지 각 끝단이 사람과 기계의 차이, 그리고 주고 받는 데이터의 방법 등의 환경만이 다르다.
사용자 삽입 이미지

<그림2> 3차원 엔터프라이즈 아키텍처

<그림1>과 같은 1,2차원의 시스템 아키텍처가 잘 만들어져야 비로서 <그림2>와 같이 Global한 연계가 가능한 3차원 아키텍처가 완성되는 것이다. 여기서 중요한 것은 RFID에서 얘기하는 EPCglobal Network이란 것은 바로 3차원의 개념에서 이해해야 한다는 사실이다. 그리고 RFID Middleware 라고 얘기하는 개념은 1차원 개념의 데이터 제공 축상에 놓여 있으므로 이 둘은 서로 다른 차원에서 이해해야 한다는 사실도 잊지 말아야 한다.
Trackback 0 Comment 0
2008. 10. 23. 20:42

디바이스 미들웨어 사용 아키텍처 - ALE 정확히 알기

RFID 시스템을 꾸밀때 RFID Middleware를 사용하느냐 마느냐의 문제로 설왕설래가 많다. 초기 RFID 프로젝트가 진행될때는 누구나 RFID Middleware를 써야한다고 알았다. 아니 알았다기 보다 잘 모르지만 어려운 RFID를 사용하기 위해서는 Middleware라는 소프트웨어를 반드시 써야만 하는 것으로 막연히 설득을 당한 것이다. 그 가격도 작게는 2,000만원에서 많게는 몇억까지도 비용으로 책정하기도 했다.
하지만 그러면서도 하는 일을 보면 RFID 리더에서 태그 데이터 읽어 들이는 역할이 고작이었으며 그렇다고 태그의 100% 신뢰성을 보장하지도 못했고 무엇인가 현장의 요구사항이 있으면 이건 할 수 없다라는 대답을 듣기 일쑤였다.
그렇게 된 원인은 RFID Middleware의 정의와 구현도 제대로 하지 못했을 뿐 아니라 그것을 현장에 적용하는 인력들의 자질 문제가 무엇보다 더 컸었던 것 같다. 단순한 실험실의 연구용과 기업 현장에 적용하는 실제 환경은 매우 큰 격차가 있다.

일이 이 지경이 되다 보니 초반에 비싼 비용을 지불하고 무용지물(?)에 우롱당한 고객들은 RFID Middleware라고 하면 무조건 필요 없다라는 반응을 보이곤 한다. 더욱이 초반 RFID 개념에 대해 교육을 하면서 RFID Middleware에 대해 설명을 할 때 어떤 이는 이른바 표준이라고 하는 EPCglobal의 과거 Savant 와 현재의 ALE 만을 논하면서 이론적으로만 가르치거나(주로 연구소 또는 연구소에서 창업한 회사) 또는 그에 대한 반대 급부로 RFID Middleware 무용론을 설파해 교육을 받는 이들로 하여금 혼란만을 주었다. (본인도 그 중에 한명이라서 그 분들에게 미안하다.)

하지만 이에 대한 정리는 여전히 제대로 되고 있지 않은 듯 하다. 이를 정리하려면 RFID Middleware 를 어떻게 사용해야 하는지 그 구성 아키텍처를 이해해야만 할 것이다. 기업내의 시스템 아키첵처에 대해서는 앞선 글에서 이미 논의되었고 이에 대한 이해가 있어야만 앞으로의 글들도 이해가 될 것이다.

먼저 많은 사람들이 RFID Middleware 는 곧 EPCglobal의 ALE (Application Level Events)라는 등식으로 오해하는 경우가 많은데, 이 부분에 대해 자세히 짚고 넘어 가자.

ALE 라는 것은 앞에서도 언급한 바와 같이 애플리케이션과 미들웨어간의 통신을 위한 인터페이스 표준이라고 할 수 있다. 다시 말하면 애플리케이션이 리더나 디바이스에서 데이터를 읽어 들이고자 할때 어떤 식으로 서로 데이터를 주고 받을 것인지를 먼저 정의해야 하는데 (이를 통신 프토토콜이라고 한다.) 이를 표준화한다면 새롭게 정의하고 그를 검증하고 하는 절차가 줄어 드니 얼마나 편리하고 믿을 수 있겠는가? ALE의 유용성은 거기에 있는 것이다. 즉, 지금 새로운 RFID 애플리케이션을 개발하고자 하는데, RFID 리더에서 데이터를 읽어 들이고자 하면 ALE 인터페이스를 제공하는 미들웨어를 사용하여 데이터를 읽어 들일 수 있고, 나는 표준에 정해진 데이터 구조를 해석해 처리하는 방식이다.

사용자 삽입 이미지
<그림 1> ALE 사용 구조

ALE 가 사용되는 구조에 대한 설명이 <그림1>에 보이고 있다. ALE는 RFID 애플리케이션과 RFID Middleware 사이에 연결되는 방법이다. 그런데 여기에서 몇가지 문제점이 숨어 있다.

첫째, RFID 애플리케이션이 반드시 RFID Middleware의 존재를 알고 있어야 하며 ALE를 사용한 통신 방법에 대해 알고 있어야 한다는 점이다. 이것이 무엇이 문제이냐고 반문할 수 있겠으나 만일 기존에 RFID에 대해 전혀 알지 못하는 레거시 시스템을 사용한다고 가정하자. RFID를 이용하여 자동화에 따른 효율화를 위해 시스템 도입을 하게 되었으나 기존 레거시를 사용하지 못한다면 말이 안되지 않겠는가? RFID 애플리케이션이 새로운 업무 관리 애플리케이션이거나(이 경우에는 문제가 덜하다.) 기존의 레거시 시스템을 중계해주는 애플리케이션이 되어야 한다. 문제는 후자의 경우 괜히 쓸데없이 디바이스 미들웨어와 상위 애플리케이션 사이에 쓸데없이 또하나의 중계 애플리케이션이 존재하는 형태가 된다. 이는 하나의 병목 현상이 될 수 있으며 만일 이 애플리케이션이 제대로 동작하지 못할 경우 전체 시스템이 망가지는 구조가 될 것이다.
실제로 본인의 경험에 의하면 이 부분에 대해 간과하여 성능 좋은 RFID Middleware를 사용하였음에도 불구하고, 수많은 데이터를 수집했을 때 이 애플리케이션이 죽어서 데이터 수집이 되지 않을 뿐 아니라 성능에 대한 요구사항도 제대로 파악되지 않아 전체 시스템 성능에 매우 해악 요소가 되는 것을 보았다.
보통 이 애플리케이션을 코멘드 콘솔 프로그램으로 작성해 두고 이를 띄워놓는 경우가 많은데 윈도우 OS 환경에서 부주의하게 그냥 창을 닫는 바람에 전체 시스템을 죽이는 어처구니 없는 상황이 연출되는 경우가 매우 빈번하다. (심지어는 RFID Middleware 프로그램도 그런 경우가 많으니 정말 한숨이 나올 지경이다.) 이런 경우 이 애플리케이션은 반드시 daemon 형태이거나 윈도우 서비스 프로그램으로 작성하여야만 한다는 것을 잊지 말아야 한다.
또한 RFID Middleware에 해당하는 디바이스 미들웨어는 상위 애플리케이션이 어떤 형태의 데이터 구조를 요구하더라도 이를 지원하는 기능을 가지고 있어야만 한다.
무엇보다 이 애플리케이션 역시 시스템 안정성과 신뢰성 보장이 되어야만 한다. 사실 이런 역할을 하는 것이 디바이스 미들웨어의 상위 계층의 미들웨어 시스템이다. EAI (Enterprise Application Interface) 솔루션이나 ESB (Enterprise Service Bus) 등과 같은 솔루션이 될 수도 있고 미들웨어 서버 같은 형태가 될 수도 있다.

둘째, RFID 애플리케이션과 RFID Middleware의 위치도 잘 생각해 보아야 한다. 보통 RFID 리더는 당연히 현장에 놓일 것이다. 그러면 RFID Middleware 의 위치는 전산실과 현장 중 어디가 될까? 물론 둘다 가능하지만 디바이스 미들웨어가 가져야 하는 중요한 기능중 장비에서 수집된 데이터를 반드시 상위에 전달해 주어야 한다는 점을 고려해 보면 좀더 장비와 가까운 현장에 놓이는 것이 맞을 것이다. (이 부분에 대해서는 좀더 자세하게 다음 기회에 다룰 것이다.)
그렇다면 RFID 애플리케이션은 어떨까? 물론 현장쪽에 가까운 곳에 놓일 수도 있지만 이것은 좀더 중앙 집중적인 형태로 상위에 놓이게 될 것이다. 이때 ALE 방식은 <그림1>의 첫번째 ECSpec을 설정하기 위해 RFID 애플리케이션이 RFID Middleware에 접속하여야만 한다. (물론 ECSpec을 설정하는 대상과 ECReports를 받는 대상은 다를 수 있지만 어찌 되었든 누군가는 중앙에서 멀리 떨어진 RFID Middleware에 ECSpec을 설정해야만 한다.)
하지만 만일 RFID 리더와 미들웨어가 깊은 산골에 설치되어 있고 (국방부나 농림부 사례 대부분이 이런 경우이다.) RFID 애플리케이션은 중앙의 전산실에 있다고 생각해 보자. 일단 산골은 랜시설이 매우 열약하다. 겨우 ADSL 정도 쓸 수 있을까? 더군다나 더 큰 문제는 비공인 IP를 가진다는 것이다. 이것은 RFID 애플리케이션이 접근할 수 없다는 이야기이다. 만일 공인 IP를 가질 수 있다고 하더라도 보안상 문제가 있다. 반면에 방화벽으로 잘 둘러 싸여져 있는 RFID 애플리케이션은 공인 IP와 보안 관리가 나름대로 잘 되고 있을테고 전국에 설치된 RFID Middleware에서 잘 접근할 수 있을 것이다. 아니면 RFID Middlware가 ALE 방식이 아닌 (ECReports 데이터 구조를 사용할 수는 있겠으나 어찌되었든 ALE 표준 데이터 교환 방식은 아니다) 형태로 상위 애플리케이션으로 데이터를 전달할 필요가 있다.

셋째, 사용하는 방식에 따라 다를 수는 있지만, ALE가 웹기반의 XML 문서를 기본으로 사용한다는 것도 문제가 될 수 있다. 이것이 좀더 상위 애플리케이션 레벨끼리의 통신에는 매우 유용하지만 좀더 빠른 실시간성을 요구하는 수직축에 있어서는 성능에 많은 저하 요인이 되기도 한다. 이런 경우는 바이너리 포맷의 플랫 데이터 형태가 훨씬 빠른 성능을 제공할 것이다.

결론적으로 좀더 대규모의 분산된 실제 현장을 대상으로 시스템 아키텍처를 생각해 보면 ALE 방식이 그리 유용하지 않을 수 있다는 것을 알 수 있다. 미들웨어를 RFID 리더를 추상화하는 정도의 API 방식으로 사용한다면 매우 유용할 수 있으나 Application Integration에는 부족하지 않을까하는 생각이 든다. 일반적으로 표준이라는 것은 다양한 형태의 공통된 하나의 방법을 제시하는 것으로 특수한 모든 상황을 다 포용하지는 못하기 때문에 내가 구축하고자 하는 시스템이 매우 크리티컬하거나 성능에 많은 영향을 받는다거나 할 경우 ALE 사용을 고집할 것이 아니라 (표준을 지키지 못한다는 죄의식을 떨쳐 버리고) 과감히 자체 정의한 방법을 선택해야 할 것이다. 물론 그것에 대한 완성도는 스스로 보장해야만 한다.

Trackback 0 Comment 0
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
2008. 7. 8. 14:34

RFID 포털 시스템

RFID를 현장에 적용시키고자 할때 가장 많이 구축되는 단위 시스템 중 하나가 바로 RFID 포털이라고 하겠다. RFID 포털(Portal)은 RFID Gate 라고도 손쉽게 부르는 것으로 한마디로 RFID 리더가 달린 문을 통과하면서 RFID Tag 정보를 수집하는 장치라고 정의할 수 있다.

UHF RFID 가 처음에 아이디어가 나온 것이 바로 이 도메인에서부터 시작되었다고 해도 과언이 아니다. RFID 포털은 창고에 설치가 되어 물리적인 물건의 이동에 따라 자동으로 데이터를 수집함으로써 WMS 가 제 기능을 다하도록 도와주고 이를 통한 SCE, 결국은 SCM을 완성하고자 고안되었다고 이미 소개한 바가 있다.

이번에는 이러한 RFID 포털 시스템의 세부 기술 사항에 대해 살펴 보도록 하겠다.

우선 RFID 포털에 필요한 세부 구성 요소를 살펴 보자. RFID 포털은 기본적으로 물론 RFID 리더가 필요할 것이다. 리더에는 또한 안테나가 연결될 것인데 이러한 안테나를 달아 둘 지지대가 필요할 것이다. 이 지지대는 안테나의 위치와 높이 등에 따라서 인식률이 달라질 것이므로 이를 잘 조절할 수 있는 기능이 필수적일 것이고 또한 현장에 설치하기 위해서는 튼튼한 구조물과 현장 상황에 맞도록 설치하는 공사 기술이 필요할 것이다.

그리고 일반적인 창고 현장은 환경적으로 매우 열약한 곳이 많다. 야외에 놓여지는 곳도 많고 겨울에는 매우 낮은 온도까지 내려가고 여름에는 또 매우 높은 온도까지 올라가는 척박한 환경이다. 여기에서 동작하는 리더나 다른 전자 기기들이 버틸 수 있도록 함체를 잘 만들어 주어야 하고 방온, 방습 처리가 잘 되어 있어야 함은 말할 것도 없다.
지게차로 이동하는 현장은 매우 험하게 움직이는데 잘못해서 포털이 파손되지 않도록 충돌 방지를 위한 안전 장치 등 주변에 기구물을 추가로 필요할 수도 있다. 그렇다고 무조건 튼튼하게 만들기 위해서 쇠로만 만들어도 안된다. RFID 전파가 영향을 받을 수 있기 때문이다.

RFID 포털은 창고 현장에서만 사용되는 것은 아니고 Long-Range 형태를 요구하는 출입 관리 분야에도 사용할 수가 있는데 이런 경우는 튼튼함 보다는 게이트 주변의 인테리어와의 조화가 더 중요한 문제가 될 수도 있다.

지금까지는 기본적인 구성에 대해서 이야기하였고 조금더 세부적으로 들어가 보도록 하겠다. 현장에 RFID 리더와 기구물만 덩그러니 세워져 있으면 아무런 의미가 없을 것이다. 상위 시스템과 연계를 해야 하는데 이를 위해서 RFID M/W를 떠올리는 것은 당연하다. 하지만 대부분 창고 현장에 특히 포털이 놓여지는 장소에 유선 네트워크를 끌어다 놓는 것은 현실적으로 어려운 점이 많다. 대신 무선 인프라는 잘 되어 있는 곳이 많다. (RFID를 도입하고자 하는 창고라면 보통 무선 PDA를 사용한 WMS 시스템을 갖고 있는 곳이 많다.)
RFID 리더가 바로 무선으로 상위 서버와 연결하는 것은 바람직하지 않고 또한 무선 네트워크는 잘 끊어지는 등 유선에 비해 안정성이 떨어지기 때문에 이런 경우에 대비하기 위해 로컬 컨트롤러가 리더가 있는 곳에 필요하다는 이야기도 이미 한 바가 있다.

그리고 로컬 컨트롤러가 필요한 더 중요한 이유는 바로 센서와 경광등 같은 다른 자동인식 장치와의 연동이 필요하다는 것이다.

RFID 포털은 하나의 통로에서 입고와 출고가 동시에 이루어 지는 것이 일반적이며 설사 입고와 출고 게이트가 따로 분리되어 있는 경우라고 하더라도 들어 왔다 나갔다 해야 할 필요가 있기 때문에 이러한 방향 판별 기능이 필요하다. 가장 일반적인 아이디어로 안테너를 여러개를 설치하고 안테너에 인식되는 태그 정보의 위상차로 방향을 판별하는 것을 떠올리기 쉬운데 이는 전파의 간섭이나 오류로 인해 현실적으로 정확도가 많이 떨어진다는 것이 현장의 경험이다. 최근에는 ImpinJ 사나 Alien 사와 같은 리더 제조 업체에서 리더 만으로 태그의 바향을 판별하는 기능을 내어 놓고는 있지만 직접 현장에서 눈으로 확인하지도 못했고 (2008년 7월 현재, 아직 정식 제품이 나온 것이 없다.) 또한 앞에서 말한 전파 간섭을 완벽하게 해결하지 못한다면 오류율은 무시하기 힘들 것으로 생각된다.

그 뿐 아니라 만일 태그가 인식이 되지 않은 채로 물체가 지나갔을 때 이를 해결하기 위해서는 현장 작업자에게 알려서 문제 해결을 지시해야 하는데 문제를 알려 주는 방법은 경광등이나 모니터를 통해 알려주는 방법이 있을 테지만, 물체가 지나갔는데 데이터가 읽히지 않았다는 판단은 어떻게 할 수 있을까? 바로 광센서 같은 다른 센서를 사용하는 방법이다. 센서에는 물체가 인식되었는데 태그 데이터가 없다면 인식이 되지 않았다고 판단할 수 있기 때문이다.

이러한 구성에 따른 RFID 포털 시스템 구성은 <그림1> 과 같다.
사용자 삽입 이미지

근데 센서를 이용해 방향 판별을 한다고 이야기는 했지만 사실 그것도 쉬운 일이 아니다. 아니 어쩌면 더 어려울 수도 있다. 센서 값도 RFID 간섭 문제와 같은 오동작 데이터가 많이 발생하고 지게차가 통과하면서 중간에 센서가 인식하지 못하는 빈 공간이 만들어 지면서 순간적으로 물체가 사라졌다가 나타났다 하는 현상이 발생할 수 있기 때문이다. 더군다나 센서 데이터와 RFID 태그 데이터를 결합시켜야 하는데 이 결합 시점을 잡을때 지게차가 물건을 앞에다 싣고 전진할 때는 센서와 태그 데이터 수집 시간이 거의 일치하지만, 현장에서는 지게차가 후진으로 이동하는 경우가 빈번한데 이 경우는 센서 데이터는 먼저 들어 오지만 태그 데이터는 나중에 들어 올 수도, 인식이 안되거나 태그가 없어서 안 들어 올 수도 있는데, 이런 다양한 경우에 대한 처리 로직을 만들기가 그리 쉬운 일만은 아니다.

그리고 현장에서 수집된 정보는 항상 상위 시스템과 연동하여 제대로 입출고를 처리하여야 하는 데이터인지 그 정합성을 확인해 봐야만 한다. 예들 들어 입고 요청에 따라 창고로 입고하는 물건이 등록된 입고 제품 목록과 일치하는지 검증을 받아서 문제가 없으면 입고 처리를 하고 그렇지 않다면 이를 작업자에게 알려서 재시도를 하거나 아니면 수작업으로라도 처리가 되도록 하여야만 한다.

'기술 관심 > RFID' 카테고리의 다른 글

RFID 의 진정한 의미  (0) 2008.07.17
RFID 스마트 선반  (0) 2008.07.11
RFID 포털 시스템  (0) 2008.07.08
디바이스 미들웨어 - RF Server  (0) 2008.05.29
디바이스 미들웨어 1 - RFID 미들웨어를 넓게 보자  (0) 2008.05.09
RFID Middleware is Extinct.  (0) 2008.03.06
Trackback 0 Comment 0