[Protocol Buffer를 파헤쳐보자] Google의 Protocol Buffer 1부

[본 글은 http://blog.skcc.com/1001 에서 Storyteller 님께서 쓰신 글을 옴겨왔습니다]

주목을 받고 있는 IOT 기술

최근 시장조사전문업체 가트너가 2013년 주목할 만한 기술로 꼽은 10대 전략기술 중에 IOT(Internet Of Things)가 포함되었습니다. IOT와 유사하게 M2M(Machine to Machine), WOT(Web of Things)등의 용어도 혼용되어 사용되고 있습니다만 각각 정의하는 차이는 있겠지만 인터넷 망을 이용한 장비간, 기기간 연계에 초점을 두고 있습니다.

유비쿼터스와 M2M

유비쿼터스라는 요어가 한때 유행처럼 사용된 적이 있습니다. 물론 지금도 유비쿼터스를 위한 기술 진화가 진행되고 있지만 요즘은 오히려 M2M 혹은 IOT 등과 같은 용어들을 더 많이 접하게 됩니다. 유비쿼터스의 의미는 "사용자가 네트워크나 컴퓨터를 의식하지 않고 장소에 상관없이 자유롭게 네트워크에 접속할 수 있는 정보통신 환경"이라고 정의하고 있습니다. 이는 자유로운 네트웤 접속과 정형화된 컴퓨터 장비를 대체할 수 있는 다양한 형태의 컴퓨터 및 장치들을 포함하는 광범위한 의미를 가지고 있습니다. 이러한 광범위한 의미는 구체적으로 정의하기도 어려울 뿐더러 기술적으로 풀어야 할 숙제들이 많이 있습니다. 때문에 유비쿼터스는 단시간에 완성할 수도 없으며 계속 진행형인 것입니다.

이해 반해 M2M이라는 단어는 장치간 연계에 초점을 맞춘 기술을 의미하므로 유비쿼터스 보다는 좀더 구체적인 의미와 목적을 갖습니다. M2M은 사물통신 이라고도 불리며 사물간 혹은 장치(기기)간 통신을 하기 위한 통신환경, 통합운영 솔루션, 데이터 통신, 통신 가능한 각종 기기 등 다양한 분야를 포함하고 있습니다. 통신 환경에 대해서는 유선 통신인 경우 주로 인터넷 통신망 혹은 통신 프로토콜을 사용하여 IOT(Internet Of Things)라고 불립니다. 또한 무선통신의 경우 M2M을 위한 별도 통신 채널(한국의 경우 기존 무선호출기에서 사용하던 주파수 대역과 012번호를 M2M에서 사용하게 됩니다)을 지정하여 사용하기도 합니다.

통합 운영 솔루션은 각 장치간 연계서비스를 위한 플랫폼을 의미하며

데이터 송수신 처리, 데이터베이스 연동, 모바일 및 웹 접근 지원 등의 기능을 지원하며,

현재는 각 IT 회사들이 앞다투어 M2M 전용 솔루션을 구축 하고 있습니다. 데이터 통신의 경우 장치간 연계를 위한 물리적 데이터 프로토타입 및 구성을 의미하며 전달하고자 하는 데이터를 작성하거나 수신된 데이터를 해석하는 역할을 담당합니다. M2M 통신에서는 연결되는 각 장치의 환경이 워낙 다양하므로 이러한 다양성을 지원하는 동적인 데이터 인터페이스가 중요한 의미를 갖습니다. 통신 가능한 각종 기기는 종류를 막론하고 정보를 주고 받을 수 있는 장치가 포함 되는데 단지 운영체제를 갖지 않더라도 통신이 가능한 기기라면 중계를 통해 M2M의 대상의 대상이 될 수 있습니다.

이종간 데이터 통신

이종간 데이터 통신을 할 경우 서로 다른 환경에 기안한 여러 문제점들이 있습니다. 특히 서로다른 OS및 개발 언어를 사용하는 경우 다양한 문제점을 만나게 됩니다. 많이 이용하는 OS에는 Windows, Windows CE, iOS, Mac OS, Android, BlackBerry OS, Symbian, RTOS 등이 있습니다. OS의 종류가 다르면 개발 언어가 달라지고 (C/C++ , MFC, Java, Android, Objective C 등) 개발 언어가 다르면 Primitive Variable을 구성하는 Endian(Big Endian(Java 계열), Little Endian(C 계열)) 이 달라지게 됩니다.

Endian이 다르면 같은 데이터를 해석하는 방법이 달라지므로 정확한 값을 주고받지 못하게 됩니다. 따라서 별도의 Endian을 맞추는 작업을 해야 합니다. 또한 개발언어가 달라지면 언어마다 구성하는 객체가 달라지므로 Remote Object 등과 같은 객체 지향의 통신은 불가능해지며 Low Data를 이용하여 통신을 해야 합니다. 이러한 문제점들을 해결하기 위해 XML 데이터를 이용한 문자열 방식의 통신을 사용할 수도 있는데 호환성은 뛰어나지만 성능적인 측면에서는 단점이 있습니다. 아래 그림을 참조하여 설명하면 [그림 1]은 원하는 데이터를 생성하고 복원하는데 까지 걸리는 최종 시간을 의미하는데 지원하는 방법에 따라 성능상 많은 차이가 나는 것을 볼 수 있습니다. 대량의 데이터를 빈번히 송/수신하는 경우에는 성능 이슈를 중요하게 따져봐야 합니다.
Google의 Protocol Buffer는 상당히 좋은 성능을 보이는 것을 할 수 있습니다.

아래 [그림 2]는 생성된 데이터의 길이를 비교하여 보여줍니다. 생성된 데이터의 길이가 짧을수록 통신에 이점이 있습니다. 여기서도  보이듯이 Google의 Protocol Buffer는 좋은 결과를 보이고 있습니다.

또한, 개발 환경이 다르거나 문ㅇ자를 처리하는 방식(ASCII, UTF-8, UTF-16, UNICODE 등)이 서로 상이하여 영어 이외의 다국어를 지원하는 경우 문자열 인코딩 방식을 통일하는데에도 어려움이 있습니다.

그리고, 개발자들이 간과하는 가장 큰 어려움은 데이터 프로토콜에 대한 커뮤니케이션 이슈입니다. 대부분 데이터를 전송하고 수신하는 모듈의 개발자 및 회사가 상이한 겨우가 대부분이며 각 필드의 속성이나 크기 등을 서로 다르게 이해하여 혼란을 격게 되는 경우가 있습니다. 보통은 프로토콜 정의서를 작성하고 각자가 작업을 하게 되는데 때로는 데이터 서언에 대해 혼란이나 혹은 데이터 범위, 초기화 등의 문제 때문에 실제 데이터를 송수신 하는 테스트를 진행할 때는 많은 협의와 시간을 소비하게 됩니다. 이러한 문제점을 해결하기 위해 데이터를 구성하는 방법들이 고안 되고 있습니다. 아래는 이종간 데이터 통신을 위한 여러 인터페이스의 정의 언어들을 보여줍니다.

AIDL : Android Interface Definition Language, Google의 Android mobile debvice platform을 위한 IDL Opne Service Interface Definitions Microsoft Interface Definition Language Platform-Independent Component Modeling Language WSDL : Web Service Description Language Universsal Network Object : OpenOffice.org의 컴포넌트 모델 SWIG : Simplifed Wrapper and Interface Generator XPIDL : 모질라의 Cross-Platform IDL Etch : Cisco의 Etch Cross-Platform Service Description Language Protocol Buffers : Google;s IDL Slice : The Specification Language for ICE

 

각 산업에서의 이종간 데이터 통신 사례

지능형 교통정보 시스템에서는 각 현장장비, 즉 OBE(On Bus Equipment), VMS(Variable Message Sign), BIT(Bus Information Terminal)등 버스, 정류장, 도로 등 교통 현장에서 접ㅈ속하는 장치들이 있고 이러한 장비들은 Windows Mobile 혹은 Linux등 각 현장장비 제조사별 서로 다른 환경의 장비들이 존재하고 각 장비에 설치된 소프트웨어는 C/C++, Delphi, Android, MFC 등 다양한 개발 환경으로 작성되어 있습니다.  또한 중앙 ITS 서버는 C/C++/MFC/Delphi 등 윈도우 계열 개발언어 이거나 Java 기반의 WAS 서버인 경우가 대부분 입니다.

또한 각 서비스를 위한 서버 (위치가공 서버, 시설관리 서버, 이벤트 관리 서버, 유저 접속을 위한 위한 웹서버, 모바일 게이트웨어 서버 등) 또한 윈도우 계열 언어이거나 혹은 Java기반의 WAS 서버 입니다. 또한 연계를 위한 타 ITS 서버 혹은 타지역의 서버 등은 통신방식과 데이터 프로토콜 이외에는 정의하기 힘들 정도로 다양한 환경을 갖고 있습니다.

각 시스템 연계를 위한 인터페이스 데이터 포멧은 업체간, 혹은 서비스간 Low Data단에서 각각 정의하여 진행할 수도 잇지만 국제적으로 ASN.1 프로토콜을 적용하도록 표준으로 권고되고 있습니다.

에너지 관리 시스템에는 각종 에너지 생산 장치(태양광 패널, 수력발전 센서, 풍력 발전의 센서 등) 및 베터리 관리 시스템 (BMS, Battery Management System) 등과 연계를 해야 하는데 이때 각 센서들은 보통 시리얼 통신(ZigBee, 485통신 등)을 지원하며 이와 연계된 Gateway를 통해 EMS 서버와 연결됩니다.

또한 BEMS(Building Energy Management System) 에서는 각종 조명들을 관리하며 TEMS(Transport Energy Managementr System), HEMS(Home Energy Management System) 등 수 많은 에너지 관련 장소 및 장비들이 존재합니다.

각 현장 장비는 대부분 RTOS를 포함하지 않은 Serial Sensor 이기 때문에 중계 장치(혹은 소프트웨어)를 통해 서버와 통신을 합니다.  또한 타 EMS 서버와의 연계 및 전력 거래소 (Web Service 방식 예정)와도 연계를 해야 합니다.

최근 에너지 관련된 데이터 전송 규격은 IEC 16850 방식을 표준 프로토콜로 책정할 계획으로 알려져 있습니다. 이와 같이 한 분야의 비지니스에서도 무척 다양한 방식의 장비와 통신방식, OS등이 존재하여 이러한 단계별 복잡도를 줄이는 것이 무엇보다 중요하게 여겨집니다.