S-100 기반 한국형 이내비게이션 서비스 메시지 교환을 위한 메시지 카탈로그 제품 표준 설계

2-1 SMART-Navigation Project

SMART-Navigation은 그림 1과 같이 SMART-Navigation 서비스를 이용하는 서비스 이용자, SMART-Navigation 운영시스템을 이용하여 서비스 이용자에게 이내비게이션 서비스를 제공하는 서비스 제공자, 그리고 서비스 이용자와 서비스 제공자 사이의 연계 지원을 위한 MCP (Maritime connectivity platform)와 MCP와 SMART-Navigation 운영 시스템의 인터페이스를 지원하는 MCC(MCP connector)로 구성된다[8].

Fig. 1.

SMART-Navigation system configuration

SMART-Navigation 운영시스템은 우리나라의 해상교통 환경에 특화된 표 1의 서비스를 제공하기 위하여 다양한 정보처리 기능과 네트워크 관리 기능을 갖는 정보시스템이며, 선박 등 해양의 서비스 이용자에게 LTE-Maritime 또는 VDES (VHF data exchange system)등의 통신망을 이용하여 서비스 제공 플랫폼인 MCP를 통해 서비스 제공자들이 제공하는 이내비게이션 서비스를 제공한다[1][2].

MCC는 MCP를 통해 전송되는 선박위치정보, 운항정보 등을 수집하며, 이 정보가 운영센터내의 서비스에서 요구하는 정보형태로 가공하는 역할을 수행한다.

MCP는 해상 무선 통신 환경에서 끊김 없는 서비스를 제공하기 위해 ID 기반 네트워크 통신을 지원하며, 통신 객체 식별자로 MRN(Maritime resource name) 기반의 해사사용자 식별자를 사용한다. MRN은 해사자원을 유일하게 식별할 수 있는 체계로서 IALA에서 제안되었으며, 그림 2와 같이 IETF (International engineering task force)에서 정의한 URN (Uniform resource name)를 기본 구조로 갖는다[9][10].

Fig. 2.

Basic structure of MRN

MCP는 그림 1과 같이 해사사용자 식별자와 인증 관련 정보를 관리하는 Identity Registry, 서비스 유형의 해사사용자 식별자와 접속 관련 정보를 관리하는 Service Registry, 메시지 교환을 담당하는 Messaging Service로 구성되며, Messaging Service는 효율적인 선육간 메시지 교환을 위하여, 그림 3과 같이 MMS(Maritime messaging service)를 사용한다[8][11][12].

Fig. 3.

Maritime messaging service functions

MMS는 SMART-Navigation 프로젝트에서 정의한 MRN을 기반으로 해사사용자 식별구조를 정의하고, 해사사용자 정보검색 서비스를 위한 식별자와 ID 기반 네트워크 통신구간에서 통신 객체 식별자로 활용한다[12].

2-2 SMART-Navigation Standard Model

SMART-Navigation standard model은 SMART-Navigation 서비스 데이터의 선육간 교환을 위하여 국제수로기구(IHO) S-100 표준에 따라 그림 4와 같이 Ship Information, Dynamic 2개의 공통 모델, Accident warning, Alarm & Emergency, ENC service meta, Pilot request, Pilot schedule, Port guideline, Ship density, MIO service meta 8개의 서비스 모델로 개발되었다.

Fig. 4.

Concept of SMART-Navigation standard model

공통모델인 Ship Information 모델은 선박의 식별 및 고유 정보를 다루며, Dynamic는 선박의 동적정보를 제공한다.

서비스 모델 중, Accident warning은 NAMAS 고유 모델로서 선박의 취약상황 인식 또는 선박의 사고 상황정보를 전달하며, Alarm & Emergency은 SBSMS 고유 모델로서 선박의 주요 장비 정보를 전달하고, 위험도를 판단하고 그에 대한 가이드라인 코드를 전송한다. 파일럿과 터그 서비스를 위한 PITAS 고유모델 중 Pilot request는 PITAS 서비스를 선박에서 육상센터로 요청 시 사용되며, Pilot schedule 모델은 선박과 도선사 사이에 필요한 정보를 전달한다. Port guideline 모델은 도선 구역에 대한 정보와 터그선에 대한 정보를 전달하며, Ship density는 일정구간 내의 선박 혼잡도 정보를 전달한다. ENC service meta, MIO service meta 모델은 실제적인 정보를 전달하는 모델이 아닌, 서비스 제공을 위한 메타정보를 전달하는 모델로 각각 REDSS, MESIS 서비스 이용을 위한 정보를 전달한다.

3-1 통신 및 서비스 식별

통신 객체 식별자로서 MRN은 MMS에서 Network locator가 변하더라도 MRN을 기준으로 지정된 목적지로 메시지를 제공하기 위한 근거로 사용되며, 이러한 기능을 위해서 MMS를 경유하는 메시지는 표 2와 같이 Source MRN과 Destination MRN을 정의하는 헤더가 추가된다[12].

Table 2.

MMS message relaying format

이를 통하여 Network locator 또는 선박의 IP 정보가 변경되어도 Destination MRN을 기준으로 정확한 목적지에 데이터를 전달할 수 있다.

하지만, SMART-Navigation 운영 센터는 통신 정책을 UDP로 정의하고 그림 1과 같이 UDP 통신 기반의 DDS와 MCC를 도입하였기 때문에, MCC와 DDS 각 서비스 통신구간에서 표 2의 헤더정보가 삭제된다. 또한 MCC에서 삭제되는 헤더 정보에 대한 관리를 지원하지 않기 때문에 헤더정보에 포함되어 있는 요청된 서비스에 대한 응답을 수신할 선박에 대한 정보를 알 수 없는 문제가 발생된다.

예를 들어 그림 5와 같이 선박에서 육상으로 SORPS에 최적항로정보를 요청하는 경우, ① 선박에서는 S-421 데이터 모델을 활용하여 S-100 기반의 Route request 메시지를 송신하고, 송신된 메시지는 ② MCP에서 이벤트 식별자, 클라이언트 정보, 인코딩 정보와 Source MRN, Destination MRN, PKI 인증서와 같은 HTTP 헤더를 포함하여 MCC에 전달한다.

Fig. 5.

Example of message exchange between ship to shore for optimal route request

③ MCC에서 데이터를 수신하면, HTTP 헤더 정보를 삭제하고 S-100 라이브러리를 활용하여 선박에서 전송된 S-100 기반의 Route request 메시지는 DDS topic data로 변경한 후 ④ DDS에게 topic에 대한 응답을 요청한다. ⑤ DDS에서는 SORPS, DDS database, 외부 시스템 연동을 통해 ⑥ 선박에서 요청된 Route request 메시지에 대한 optimal route 값을 도출한 후, DDS에 optimal route에 대한 waypoint를 전달한다.

⑦ DDS에서 MCC로 waypoint topic data를 전달하면 ⑧ MCC에서는 S-100 라이브러리를 활용하여 S-421 표준 기반 waypoint 데이터로 변환하여 ⑨ MCP로 전달한다. MCP에서는 이벤트 식별자, 클라이언트 정보, 인코딩 정보와 Source MRN, Destination MRN, PKI 인증서와 같은 HTTP 헤더를 포함하여 destination MRN을 기반으로 서비스를 요청한 선박에 Optimal route에 대한 waypoint 데이터를 전송하여야 하나, ③의 과정에서 요청된 Route request 메시지의 HTTP 헤더 정보가 삭제되었기 때문에 ⑨에서 작성되어야 하는 헤더 정보를 생성하기 어려 우며, 서비스를 요청한 선박에 대한 통신 객체 식별이 불가능하여 ⑩과 같이 정보를 요청한 선박에 메시지에 대한 응답을 정확하게 전달하기 어렵다.

따라서 메시지 카탈로그 데이터 모델은 Source MRN, Destination MRN 데이터를 포함하여 MCC에서 HTTP 헤더가 삭제되더라도 서비스를 요청한 선박에 대한 통신 객체 식별이 유지되도록 MRN 정보를 포함하여야 한다.

3-2 교환데이터 정보

S-100 표준에 따라 해사데이터를 교환하기 위해서는 먼저 그림 6 상단과 같이 SMART-Navigation 서비스 및 운영 시스템 요구사항을 반영하여 어플리케이션 스키마를 개발하고, 어플리케이션 스키마에 정의된 각 Feature와 Information을 S-100 Registry에 등록한 후 레지스트리를 활용하여 Feature catalogue와 Portrayal catalogue를 제작하며, 데이터 셋의 구조와 인코딩 포맷을 포함한 제품 표준 개발을 완료한다.

Fig. 6.

Concept of using the S-100 standard

각 서비스에서는 개발된 제품 표준을 활용하여 S-100 표준 데이터를 읽거나 쓸 수 있으며, 선박과 육상 간 S-100 데이터 교환이 이루어지기 위해서는 그림 6의 하단과 같이 반드시 선박과 육상에 동일한 버전의 Feature catalogue와 Portrayal catalogue가 존재하여야 한다[13].

따라서 메시지 카탈로그 모델은 교환되는 데이터 모델에 대한 이름과 해당 모델에 대한 버전 정보를 포함하여, 선박과 육상에 동일한 Catalogue 파일이 존재하는지 확인할 수 있어야하며, 인코딩 포맷에 대한 정보를 함께 송부하여 해당 포맷에 따라 데이터를 사용할 수 있도록 하여야 한다.

SMART-Navigation standard model은 교환되는 메시지 중심이 아니라, 그림 4와 같이 데이터의 특징에 기반 한, 콘텐츠 중심으로 개발되었기 때문에 서비스 데이터를 표현하기 위해서는 필요한 데이터를 포함하고 있는 개별 제품 표준을 표 3과 같이 조합하여 구성된다.

Table 3.

SMART-Navigation standard model list

따라서 메시지 카탈로그 모델은 교환되는 데이터가 몇 개의 제품 표준으로 구성되어 있는가에 대한 정보를 제공해야하며 전송되는 제품 표준에 대한 이름과 버전 정보 등이 함께 송부되어야 한다.

SMART-Navigation 서비스는 표3과 같이 서비스 요청에 따른 응답이 기본 구조로 동작된다. 하지만 SMART-Navigation standard model은 동작이 아닌 콘텐츠 중심의 모델로 개발되어 서비스 요청과 응답에 대한 데이터를 처리할 수 없기 때문에 서비스 요청과 응답에 대한 별도의 모델이 필요하다. 또한 NAMAS, 그림 2의 Message geocasting 과 같이 요청에 대한 응답이 아닌 특정 지역에서 위험이 발생되면 자동으로 전송되는 데이터를 구분할 수 있는 식별자가 필요하다.

따라서 메시지 카탈로그 모델에 메시지 타입을 정의하여 해당 데이터가 서비스를 요청하는 데이터인지, 요청에 대한 응답인지 확인할 수 있도록 한다.

3-3 요구사항 정의

앞서 살펴본 결과를 바탕으로 SMART-Navigation Standard Model을 이용하여 SMART-Navigation 서비스 데이터 교환 시 모듈형 모델의 조합 및 정보의 내용을 구분하기 위한 메시지 카탈로그 모델에 대한 요구조건을 다음과 같이 도출하였다.

• 1) 모듈형 SMART-Navigation Standard Model의 활용을 위해 교환데이터는 그림 7과 같은 데이터 패키지형태로 전달되며, 메시지 카탈로그 모델은 전달되는 정보의 요약 정보 제공 및 식별자 역할을 수행해야함

Fig. 7.

Data package for service data exchange

• 2) 개발된 SMART-Navigation Standard Model를 서비스 이벤트에 따라 사용될 수 있도록 조합되는 모델 구성, 교환되는 모델의 이름, 버전, 인코딩 포맷 등의 상세 정보를 제공하여야 함
• 3) 서비스 제공 형태에 대한 정보를 확인할 수 있도록 메시지 타입 정보가 제공되어야 함
• 4) 통신 객체 식별을 위한 MRN 정보 제공하여야 함

4-1 Application Schema

3장에서 도출된 요구사항을 기반으로 메시지 카탈로그 데이터 어플리케이션 스키마 개발을 위하여 데이터 명과 각 클래스간의 관계를 설정하고 S-100 문법에 맞추어 attribute와 attribute의 속성을 정의하고 data type, multiplicity, 각 데이터의 범위와 Enumeration 값을 표 4와 같이 정의하였다.

Table 4.

Message catalogue data specification

정의된 데이터 상세 명세서를 활용하여 그림 8과 같이 메시지 카탈로그 어플리케이션 스키마를 개발하였다.

Fig. 8.

Message catalogue product specification – application schema

메시지 카탈로그 어플리케이션 스키마는 교환되는 데이터정보를 갖는 1개의 Feature type과 통신 및 식별정보를 위한 1개의 Information type으로 구성되며, 3개의 complex attribute, 3개의 enumeration type를 포함한다.

3개의 complex attribute는 교환되는 실 데이터의 상세 정보를 제공하는 역할을 수행한다. Exchange File의 nameOfFile과 sizeOfFile은 실제 전송되는 파일의 이름과 사이즈 정보로, 수신된 파일 이름과 사이즈를 비교하여 정상적으로 데이터가 전송되었는지를 확인할 수 있으며, typeOfFile의 인코딩 포맷에 따라 데이터를 읽고 쓸 수 있다.

Exchange Model은 서비스 메시지 교환을 위해 조합되는 제품 표준의 이름 또는 제품 표준 번호를 전송하며, 조합되는 제품 표준의 수에 따라 복수 개를 사용할 수 있도록 구성하였다.

messageType은 전송되는 메시지가 서비스 요청인지, 요청에 대한 응답인지와 특정지역을 항해하는 경우 자동으로 발송되는 알람 메시지인지를 판단할 수 있도록 하였다.

information은 기존 정의된 Attribute 외에 추가적인 정보의 확장을 목적으로 한다.

3개의 Enumeration type은 각각 product specification의 종류, 교환되는 데이터의 포맷 그리고 교환되는 데이터의 목적을 정의하였다.

4-2 Feature Catalogue

메시지 카탈로그 피쳐 카탈로그는 표 4의 데이터 상세 명세서와 그림 8의 어플리케이션 스키마에서 제시된 Feature와 Information에 대한 data type, size, 다중도, 데이터 범위, 우선순위를 정의하고, S-100 표준 Edition 4에 따라 Machine Readable이 가능하도록 그림 9와 같이 xml 파일과 표 5, 6등과 같이 작업자가 해독 가능한 문서 형식으로 작성하였다.

1) Feature type

● Geographic

Table 5.

Geographic data list

● Cartograpic
● Theme
● Meta

3) Information Relationship

Table 6.

Information relationship

그림 9의 xml 파일은 S100Base, S100CI, S100FC, S100FD로 구성된 xml 스키마 파일을 통해 S-100에 적합하도록 작성되었는지를 검증하였으며 그 결과는 그림 10과 같다.

Fig. 9.

Message catalogue product specification – Feature catalogue

Fig. 10.

S-100 xml Schema files and Validation Results