GPS의 측위 정확도를 높이기 위해 한국에서는 DGPS(Differential GPS) 기준국을 설치, 운영하고 있다. DGPS 기준국은 GPS의 오차를 보정할 수 있는 보정정보를 생성하여 중파를 통해 DGPS 보정정보 서비스 수신이 가능한 사용자에게 전달하고, 사용자는 이를 이용해 GPS를 이용한 측위의 정확도를 높일 수 있다. 현재까지의 DGPS 기준국 시스템은 RTCM(Radio Technical Commission for Maritime Services)에서 정의한 DGPS RSIM(Reference Station and Integrity Monitor) 버전 1.2를 기반으로 구성되어져 있으나, RSIM 버전 1.2으로는 GPS의 보정정보만을 일반 사용자에게 서비스할 수 있다. RSIM 버전 1.2가 제정되던 시점과는 달리 현재는 미국의 GPS 외에도 러시아의 GLONASS, 유럽의 GALILEO, 중국의 Beidou, 일본의 QZSS등 다수의 측위위성이 존재하며 이들을 GNSS(Global Navigation Satellite System)이라 칭하고 있다. 한국의 DGPS 기준국 시스템이 따르고 있는 RSIM 버전 1.2로는 각 GNSS를 지원할 수 없어 RTCM에서는 이들의 보정정보를 생성, 서비스할 수 있도록 RSIM 버전 1.3을 제정하고 있다. RSIM 버전 1.3은 다양한 GNSS를 지원할 수 있도록 기존의 RSIM 버전 1.2와는 그 구조가 상당히 크게 바뀌어 기존의 DGPS 기준국의 아키텍처는 더 이상 사용할 수 없게 되었다.

따라서 GPS외의 GNSS들의 보정정보를 서비스할 수 있도록 본 논문에서는 RSIM 버전 1.3을 무리없이 지원할 수 있는 소프트웨어 RSIM의 아키텍처를 설계하였다.

이 장에서는 RSIM 버전 1.2을 기반으로 하는 현재의 DGPS 기준국 시스템의 구조를 분석하여 RSIM 버전 1.3과의 차이점을 도출, 새로운 아키텍처에 반영될 수 있도록 한다.

RSIM 버전 1.2 기반의 DGPS 기준국은 그림 1과 같이 구성되어 있다.

그림 1에서 보는것과 같이 하나의 DGPS 기준국은 4기의 GPS 수신기와 2기의 RS, 2기의 IM, 이들을 연결하는 네트워크 스위치, 그리고 MSK 모듈레이터와 비콘 송신기로 구성되어져 있다[1]. GPS 수신기는 GPS에서 전송해 오는 신호를 수신하여 그 측정치를 각 GPS 수신기 고유의 프로토콜을 사용해 RS와 IM 소프트웨어로 전송한다.

RS(Reference Station)는 GPS 수신기로부터 전송받은 데이터를 기반으로 GPS 측정치의 오차를 계산하여 보정정보를 생성하는 역할을 하며, IM(Integrity Monitor)은 RS가 생성한 GPS 보정정보의 품질 및 RS의 동작상태를 모니터링하는 역할을 수행한다[2].

RS와 IM의 데이터 전송 구조를 보다 자세히 도식화하면 그림 2와 같이 표현할 수 있다.

그림 2에서, RS는 GPS 수신기(Rcvr)로부터 데이터를 전송받아 생성한 보정정보를 RTCM 메시지 9번 형식으로 포맷팅 한 다음 송신기를 통해 이를 방송하고, IM에서 이 RTCM 9번 메시지를 수신받아 측위에 이용, 그 품질을 검사하는 것을 볼 수 있다.

RS에서 보정정보를 생성하고 IM에서 그 품질을 감시하는 일련의 구조는 RSIM 버전 1.2와 1.3에서 차이가 없다. 따라서 RSIM 버전 1.3 기반의 DGNSS 기준국 역시 RS와 IM이 존재해야 한다[3].

2장에서 언급한 것처럼 RSIM 버전 1.3 기반의 DGNSS 기준국에서도 RS와 IM을 위한 수신기, RS, IM이 동일하게 존재한다. 그러나 RSIM 버전 1.2는 서론에서 언급한 것처럼 GPS의 보정정보만을 서비스할 수 있게 설계되어 있어 RSIM 버전 1.3을 위해서는 GPS 수신기가 아닌 GNSS 수신기를 설치해야 한다. 이는 매우 큰 차이로, 기존의 RS와 IM 소프트웨어 아키텍처는 GPS 단 하나만을 처리하는 구조로 이루어져 있었다는 것을 의미한다.

그림 2에서 보는 것처럼 RS 소프트웨어 및 IM소프트웨어는 GPS 수신기로부터 오는 데이터를 처리하는 모듈이 하나만이 존재한다. 그러나 RSIM 버전 1.3으로 버전이 변경되면서 DGNSS 기준국은 GPS 뿐만 아니라 GLONASS, GALILEO, QZSS 및 BeiDou까지 지원하도록 제정되었다. 따라서 우선, RSIM 버전 1.3 기반의 DGNSS 기준국에는 기존의 GPS 신호만을 수신하는 수신기가 아닌, 위에서 언급한 GNSS들을 모두 수신할 수 있는 GNSS 수신기를 설치하여야 한다.

RSIM 버전 1.2와 1.3의 큰 차이는 지원하는 RTCM 메시지 버전이 달라졌다는 것이다. RSIM 버전 1.3에서 지원 가능한 GNSS가 늘어남에 따라, 이들 GNSS의 보정정보를 일반 사용자에게 전송할 때 사용되는 전용규약인 RTCM 메시지 표준 역시 변경되었다. 현재까지 DGPS 기준국에서 표준으로 사용하고 있는 RTCM 메시지의 버전은 2.3으로, 이 버전에서 정의하고 있는 것은 GPS와 GLONASS 의 보정정보 메시지 프로토콜 뿐이었다. 이에 RTCM에서는 RSIM 버전 1.3을 제정하면서 동시에 RTCM 메시지 표준 역시 변경하면서, 그 버전을 2.4로 정의하였다. 즉, 기존의 RTCM 메시지 2.3버전은 GPS와 GLONASS 위성에 대한 보정정보를, RTCM 메시지 2.4버전은 GPS, GLONASS, QZSS, BeiDou, GALILEO 모두를 지원할 수 있게 된 것이다. 따라서 DGNSS 기준국에서 다양한 GNSS에 대한 보정정보 방송을 서비스하기 위해서는 RSIM 버전 1.3 기반으로 운영함과 동시에 RTCM 메시지 버전 2.4를 사용하여야 한다.

RSIM 메시지 자체가 재정의 되어, 기존의 버전인 RSIM 버전 1.2와 RSIM 버전 1.3은 호환이 불가능하게 변경되었다. RTCM 메시지의 경우, RTCM 메시지 버전 2.4는 버전 2.3과 호환이 가능하도록 한 변경이다. 즉, RTCM 2.3의 메시지를 그대로 사용하면서 GNSS들의 보정정보 서비스에 필요한 메시지가 ‘추가’된 것이어서 2.4 버전을 사용하더라도 몇가지 메시지를 제외하고는 2.3에서 제공하던 메시지를 그대로 사용할 수 있다.

그러나 RSIM 버전 1.3은 RTCM 메시지의 그것과 달리, 기존의 메시지에 새로운 메시지를 추가한 개념이 아닌 ‘개정’이 이루어 졌다. 메시지의 번호 또한 달라져 1~40번까지의 메시지 번호를 사용하는 RSIM 버전 1.2와 달리 1.3에서는 101~139까지의 메시지를 사용하도록 정의되었다. 각 메시지는 추가된 새로운 기능을 포함하면서, 기존 버전 1.2에서 지원하던 기능들 역시 지원할 수 있도록 설계되었다.

RSIM 버전 1.2와 1.3의 가장 큰 차이점은 지원하는 GNSS의 수가 1개에서 5개에서 늘어났다는 것이다. 이것은 즉, 각 GNSS의 보정정보를 계산하고 생성, 방송하는 모듈이 각각 존재해야 함을 의미한다.

따라서 본 논문에서는 GNSS들의 보정정보를 계산하고 메시지를 생성, 처리하는 부분을 각각의 모듈로 분류, 별개로 동작하도록 설계하였다. 각각의 모듈은 별개의 프로세스로 동작하며, 또한 동시에 작업을 수행하여 실시간으로 5개의 GNSS에 대한 보정정보를 생성해 내야 하므로, 이들이 생성해 내는 데이터를 관리할 수 있는 버퍼를 두었다.

그림 3은 소프트웨어 RSIM이 각 GNSS의 데이터를 동시 처리하면서 데이터를 생성해 내기 위해 각 GNSS를 담당하는 별개의 프로세스가 존재하면서 동작하는 모습을 도식화 한 것이다. 메인 프로세스는 각 GNSS 처리 프로세스의 동작 상태 및 데이터 생성을 감시, 제어하는 역할을 하도록 하였으며, 버퍼는 각 프로세스가 생성해 내는 데이터가 모일 수 있는 공유메모리가 되도록 하였다. IPC(Inter Process Communication)를 사용하여 각 프로세스는 이 메모리에 접근하여 데이터를 저장하거나 읽어 들일 수 있다.

각 프로세스는 GNSS 수신기에서 데이터를 전송받음과 동시에 각각의 보정정보 생성 프로세스를 병렬로 수행하며, 데이터 수신, 보정정보 생성, RSIM 메시지 생성작업 까지를 동시에 수행해 낸다. 메인 프로세스에서는 이들 프로세스가 생성해 낸 보정정보 데이터를 사용하여 RTCM 메시지 전송스케쥴을 관리하는 역할을 한다.

4.1.절에서 언급한 것처럼, 본 논문에서는 각각의 GNSS 보정정보 생성 프로세스가 생성해 낸 데이터는 메인 프로세스에서 관리하도록 설계하였다.

그림 4는 RSIM 메시지를 저장, 처리하는 과정을 도식화 한 것이다. 그림 4에서 보이는 메인 프로세스는 Control Station(RSIM의 동작을 제어하는 제어국)에서 전송해 오는 명령을 받아 각 데이터를 저장, 읽기, 전송 등의 작업을 수행한다. 스토리지에 RSIM 메시지 데이터(PRCM 데이터라고도 함)를 저장하거나, 버퍼에 저장하는 과정 역시 제어한다.

4.1절과 4.2절의 내용에 따라, RS는 각 GNSS의 데이터를 처리하는 모듈, 보정정보를 생성하는 모듈, 프로세스를 제어하는 모듈, RSIM 메시지를 관리하는 모듈, 그리고 RTCM 메시지를 생성하는 모듈이 필요하다.

그림 5는 이들 모듈을 정의하고, 모듈간 데이터흐름을 정의한 아키텍처이다. 본 논문에서 설계한 RS의 아키텍처는 다음과 같이 크게 5개의 모듈을 정의한다.

모듈의 융통성을 높이기 위해, 본 논문에서는 가능한 한 RS의 아키텍처와 유사하도록 IM을 설계하였다. IM은 RS와 마찬가지로 크게 5개의 모듈로 구성되도록 하였다.

위에서 정의한 모듈을 기반으로 아키텍처를 설계한 것이 그림 6이다.

그림 7에서 보는 것처럼, RS와 IM은 RSIM 메시지(PRCM 메시지)를 사용하여 상호 통신한다. PRCM #135를 이용하여 네트워크(TCP/IP)를 통해 IM으로 즉시 보정정보 데이터를 전송하거나, RTCM Type 42를 이용하여 Radiobeacon을 통해 보정정보를 방송, 사용자와 IM에 전송할 수 있도록 하였다. 이때, PRCM #135 또는 RTCM type 42를 통한 보정정보 전송 과정은 GPS, GLONASS, GALILEO 및 기타 GNSS 모두가 동시에, 별도로 수행되도록 한다.

기존의 DGPS 기준국이 DGNSS 기준국으로서 운영될 수 있도록, 기준국의 운영표준을 정의하는 RSIM 버전이 1.2에 1.3으로 개정됨에 따라, 이를 지원할 수 있는 시스템의 개발이 필요해 지고 있다. 이에 본 논문에서는 RSIM 버전 1.2와 1.3의 차이를 분석하고, 버전 1.3에서 정의하고 있는 기능들을 수행해 낼 수 있는 소프트웨어 RS, IM의 아키텍처를 설계하였다.

설계한 소프트웨어 RSIM의 아키텍처는 RSIM 버전 1.3에서 지원하는 GPS, GLONASS, GALILEO, BeiDou, QZSS의 다섯가지 GNSS에 대한 보정정보를 동시에 생성하고 검사하며, 각각의 프로세스를 병렬 실행할 수 있도록 설계하여 동시에 5개 GNSS 모두의 보정정보를 서비스할 수 있도록 하였다.

본 논문에서 설계한 아키텍처를 기반으로 하여 개발된 소프트웨어 RSIM은 RSIM 버전 1.3의 기본 목적인 5개의 GNSS에 대한 보정정보 서비스를 충실하게 지원할 수 있다. 또한, GPS, GLONASS, GALILEO와 같은 GNSS를 한번에 하나씩만을 지원할 수 있는 것이 아닌, 5개의 GNSS 데이터 모두를 동시에 처리하여, 각 GNSS 보정정보를 실시간으로 모두 생성, 서비스할 수 있다.

본 연구의 다음 과정에서, 본 논문의 아키텍처를 사용한 시스템을 구현하여 그 성능을 테스트하고, 실제 국내의 DGNSS 기준국에 설치하여 DGNSS 서비스 성능을 시험하고 그 결과를 분석할 예정이다.