• 검색 결과가 없습니다.

저작자표시

N/A
N/A
Protected

Academic year: 2022

Share "저작자표시"

Copied!
46
0
0

로드 중.... (전체 텍스트 보기)

전체 글

(1)

저작자표시 2.0 대한민국 이용자는 아래의 조건을 따르는 경우에 한하여 자유롭게

l 이 저작물을 복제, 배포, 전송, 전시, 공연 및 방송할 수 있습니다. l 이차적 저작물을 작성할 수 있습니다.

l 이 저작물을 영리 목적으로 이용할 수 있습니다. 다음과 같은 조건을 따라야 합니다:

l 귀하는, 이 저작물의 재이용이나 배포의 경우, 이 저작물에 적용된 이용허락조건 을 명확하게 나타내어야 합니다.

l 저작권자로부터 별도의 허가를 받으면 이러한 조건들은 적용되지 않습니다.

저작권법에 따른 이용자의 권리는 위의 내용에 의하여 영향을 받지 않습니다. 이것은 이용허락규약(Legal Code)을 이해하기 쉽게 요약한 것입니다.

Disclaimer

저작자표시. 귀하는 원저작자를 표시하여야 합니다.

(2)

공학석사 학위논문

선박에서의 통합 정보처리를 위한 메시지처리 시스템 설계 및 구현

Design and Implementation of Message Processing System for Integrated Information Processing on ship

지도교수 박 휴 찬

년 월

2010 2

한국해양대학교 대학원 컴퓨터공학과

김 태 종

(3)

목 차

제 1 장 서 론... 1

제 2 장 관련 연구 ... 3

2.1 NMEA 2000 ... 3

2.2 IEC 61162-4 ... 4

통신 프로토콜 2.2.1 ... 4

데이터 및 메시지 2.2.2 ... 6

제 3 장 시스템 설계 ... 12

시스템 구조 3.1 ... 12

데이터 설계 3.2 ... 13

데이터 3.2.1 ... 13

데이터베이스 3.2.2 ... 17

데이터 및 메시지 처리 3.3 ... 20

데이터 처리 3.3.1 ... 20

메시지 처리 3.3.2 ... 24

데이터 전송 3.3.3 ... 33

제 4 장 시스템 구현 ... 35

게이트웨이 4.1 ... 36

미들웨어 서버 4.2 ... 37

어플리케이션 4.3 ... 39

제 5 장 결론 및 향후 과제 ... 41

참고문헌... 42

(4)

Design and Implementation of Message Processing System for Integrated Information Processing on ship

Tae-Jong Kim

Department of Computer Engineering, Graduate School of

Korea Maritime University

Abstract

Nowadays, numerous systems and devices are connected to networks in ships. These devices and systems generate various kind of data and information, and exchange them each other. Therefore, it is required to integrate data and information in ships, and also develop systems which can supervise and process the integrated data and information. So, it needs to collect data from each device, integrate and manage them, and provide them with proper processing when services are asked.

According to these needs, a system architecture for the processing and management of data and information is apparently required. Briefly, the system architecture is made of three parts. The first part is Gateway which transforms data transmitted from NMEA 2000 networks to tag data, the second one is Middleware Server that stores and manages the transformed data. the last one is Application that provides users with properly processed information.

(5)

In this paper, before designing system which can works in IEC 61162-4 networks, the NMEA 2000 standard is first discussed. Besides that, we also discuss on the transformation of NMEA 2000 data and network protocols. According to the analyzed protocols, this paper designs messages that are transmitted in IEC 61162-4 networks, marshalling and de-marshalling of basic data types and arrays, and message packing and message unpacking.

(6)

제 1 장 서 론

선박 내에는 네트워크로 연결된 수많은 장치와 시스템들이 탑재되어 있다. 이 들 장치와 시스템들은 다양한 형태의 데이터와 정보를 생성하고, 상호 교환한 다. 따라서 선박에서의 데이터와 정보를 통합하여, 관리 및 처리가 가능한 시 스템의 개발이 요구되고 있다. 즉, 각 장치에서 발생되는 데이터를 수집하고, 통합 및 관리하며, 서비스 요청에 대해서는 적절히 처리한 후 제공할 필요가 있다[1].

이러한 필요성에 따라 선박에서 발생된 데이터와 정보의 처리 및 통합 관리를 위한 시스템 구성이 요구된다. 시스템 구성은 크게 세 부분으로 나눌 수 있다. 첫 부분으로 NMEA 2000[2] 네트워크에서 오가는 데이터를 태그 데이터로 변환 할 게이트웨이(Gateway)이며, 다음 부분은 변환된 데이터를 데이터베이스에 저 장 및 관리하는 미들웨어 서버(Middle-Ware Server)이고, 마지막 부분은 저장 된 데이터를 적절히 처리하여 서비스할 어플리케이션(Application)으로 나눌 수 있다.

본 논문에서는 IEC 61162-4[3] 네트워크에서 동작하는 시스템을 설계에 필요 한 NMEA 2000 표준에 대하여 고찰한다. 또한, NMEA 2000에서 발생하는 데이터 를 분석하여 네트워크의 프로토콜에 맞게 변환하는 과정을 살펴보고, IEC

네트워크에서 전송되는 프로토콜을 분석한다

61162-4 .

그리고 게이트웨이, 미들웨어 서버, 어플리케이션의 세 부분으로 나누어진 시 스템 구조를 제시한다. 그리고 분석한 프로토콜을 토대로 하여 IEC 61162-4 네 트워크에서 주고받는 메시지들과, 들어갈 데이터 중에서 기본 데이터 형 및 배 열에 대한 마샬링(marshalling) ․ 디마샬링(de-marshalling)을 설계한다.

또한, 마샬링된 데이터를 메시지로 만드는 과정인 메시지 패킹과 메시지를 해 체하는 작업인 메시지 언패킹을 설계한다. 다음으로 패킹된 메시지를 전송하는 과정을 고찰한다.

(7)

본 논문의 구성은 다음과 같다. 2장에서 NMEA 2000과 IEC 61162-4 표준에 대 하여 논하고, 3장에서는 메시지 및 데이터 패킹과 언패킹, 메시지 처리 시스템 을 설계한다. 그리고 4장에서는 3장에서 설계한 시스템을 구현한다. 마지막으 로 5장에서 결론을 내리고 향후 과제를 제시한다.

(8)

제 2 장 관련 연구

선박의 안전 및 효율적인 운항을 위하여, 항해 장비와 통신 기술 및 서비스는 정보 기술의 발전과 더불어 발전되어 왔다. 그러나 이런 기술적인 진보가 부조 화를 남긴다면, 미래 국제 해운 산업의 발달은 선박과 육상 간의 표준화 결여, 선박 간의 호환성 결여 등을 야기할 수 있다. 지금까지의 개별적으로 개발되어 온 항해 장비들 간의 유기적인 작동과 사용자의 편의를 위한 신개념 선박 항법 시스템인 E-Navigation 시스템 도입 논의가 국제해사기구(IMO)에서 본격화되고 있다[4]. 또한, 국제 전기 전자 위원회(International Electrotechnical 는 시스템을 위하여 선박 내 각종 항해 및 통신 장비 Commission) E-Navigation

또는 시스템들의 인터페이스 규격을 제정하였다. 그 중, 다수 송신 및 수신 기 능 통신 규격인 NMEA 2000과 선박 시스템 접속 통신 규격인 IEC 61162-4에 대 하여 살펴보겠다.

2.1 NMEA 2000

네트워크는 쉽게 정보를 공유하기 위한 목적으로 공통의 채널에 여 NMEA 2000

러 전자 장비를 서로 연결시켜 준다. 그 때 네트워크에 전달되는 메시지는 에 의해 식별되는 파라미터 그룹으로 정의된다

PGN(Parameter Group Number) .

그림 1은 NMEA 2000 파라미터 그룹의 데이터 정의 구조를 나타낸다. 파라미터 그룹은 파라미터 그룹을 정의하는 IDRef_Tbl과 데이터 필드인

로 구성된다 은 파라미터 그룹 이름 설명 등

IDRef_Detail_Tbl . IDRef_Tbl , PGN,

을 나타내며 ID 레퍼런스 필드에 의하여 IDRef_Detail_Tbl과 연결된다. 또한, 은 로컬 이름 필드 노트 등을 갖는 개별 필드들로 구성되며 IDRef_Detail_Tbl ,

개별 필드는 관련된 데이터 사전(DD#_Tbl), 데이터 포맷(DF#_Tbl) 및 데이터 형식(Type_Tbl)을 갖고 정의된다[3,5].

(9)

그림 1 NMEA 2000 의 데이터 구조 정의 Fig 1 Data Structure Definition of NMEA 2000

2.2 IEC 61162-4

통신 프로토콜 2.2.1

선박 내 시스템 간의 데이터 및 정보 교환을 위한 대표적인 통신 프로토콜은 의 표준에 제시되어 있으며

IEC 61162-4 , MiTS(Maritime Information 를 발전 계승한 표준이다 프로토콜의 구조는 그림

Technology Standard) [1]. 2

와 같으며, 크게 T-Profile(Transport Profile)과 A-Profile(Application

로 구성된다 은 상에서 정의되며

Profile) . T-Profile Ethernet, IP, TCP/UDP

를 제시하고 있다 은

TLI(Transport Layer Interface) . A-Profile LNA(Local 로 구성된다

Network Administrator), MAU(MiTS Application Unit) [3,5].

(10)

그림 2 IEC 61162-4 프로토콜 구조 Fig.2 Protocol structure of IEC 61162-4

정보의 교환을 위한 통신 모듈인 MAU와 LNA간의 관계는 그림 3에 나타나 있 다. 그림에서 알 수 있듯이, 각 호스트 컴퓨터는 LNA와 MAU를 가질 수 있으며,

는 를 통하여 상위 어플리케이션과 통신한다

MAU MAU API .

그림 3. LNA와 MAU의 기능 Fig. 3 Functions of LNA and MAU

(11)

와 는 를 통하여 상호 통신이 가능하 MAU LNA TLI(Transport Layer Interface)

고, LNA와 LNA간에는 역시 TLI를 통하여 상호 통신할 수 있다. LNA는 하나 이 상의 MAU를 서비스할 수 있다. LNA는 네트워크를 관리하고 MAU간의 메시지 통 신을 담당하는 모듈이다. 또한, 세션 관리(session management), 트랜잭션 관 리(transaction management), MAU 이름 검색(MAU name look-up)기능을 담당한 다. 특히 세션 관리를 통하여 MAU의 연결, 상태 변경, 해지 등을 할 수 있으 며, 원격 LNA와의 연결 유지 및 해제도 가능하다. 각 LNA들은 원격 LNA와 연결 시, 서로의 정보를 교환하기 위하여 핸드셰이킹 프로토콜(handshaking

을 사용한다 protocol) [2].

의 기능은 크게 상태를 관리하는 기능 내부의 접

MAU (state management), MAU

속점들 간의 세션을 관리하는 기능(session control), 보안을 위해 인증을 담 당하는 인증 기능(authentication), 통신 문제를 해결하는 기능(congestion

내부 접속점들의 집합인 인터페이스를 관리하는 기능

control), (interface

등으로 나눌 수 있다 그 외에 대용량 전송을 위한 기능

management) . (bulk

도 가진다 data transfer) [2].

에서 원하는 기능을 작동시키고자 할 때 에 의해 구 User Application , MAU API

성된 것들을 이용하여 그 기능들을 수행할 수 있다. MAU API는 IEC 61162-420 의 Annex E에 상세하게 기술되어 있으며, 흔히 Companion Standard라 지칭된 다. 이 Companion Standard에는 알람과 모니터링 시스템 식별자, 기능적 개요, 응용 단계, Companion Standard의 구조, 파일 구조, 표준 태그 이름, 표준 태 그 구조, 야드 태그 구조, 내부적 태그 구조, 타임스탬프, 플래그, 마지막으로

의 상세가 기술되어 있다 Companion Standard .

시리즈에 정의된 인터넷 은 이 표준을 사용하는 장비와 IEC 61162-4 T-profile

함께 존재할 수 있다. 같은 호스트 컴퓨터상의 예전 응용과 새 응용을 통합함 으로써 두 프로토콜 사이의 게이트웨이가 고안된다, .

(12)

데이터 및 메시지 2.2.2

의 에서 사용되고 있는 데이터 타입은 다음과 같이 표현 IEC 61162-4 A-profile

할 수 있다. 표 1에서 나타낸 것처럼 1 bit Boolean 은 bool_m으로 정의되며,

는 으로 는 으로 정의된

8 bit character char8_m , 16 bit character char16_m

다. 또한 unsigned integer는 word[비트수]_m로, 2의 보수 정수형은 int[비트 수]_m으로 정의된다. floating point는 float[비트수]_m으로 정의된다[1].

Type Description

bool_m 1 bit Boolean

char8_m 8 bit character char16_m 16 bit character word8_m 8 bit unsigned integer word16_m 16 bit unsigned integer word32_m 32 bit unsigned integer word64_m 64 bit unsigned integer int8_m 8 bit 2's complement integer int16_m 16 bit 2's complement integer int32_m 32 bit 2's complement integer int64_m 64 bit 2's complement integer float32_m 32 bit floating point

float64_m 64 bit floating point

표 1 IEC 61162-4 A-profile에서 제공된 기본 데이터 타입

Table 1 Basic Data Types are defined in A-profile of IEC 61162-4

와 간의 상호 통신은 를 통하여 이루어지는데 에서는 메시지를

LNA MAU TLI , TLI

주고받으면서 정보를 교환한다. 메시지는 MAU와 LNA간의 메시지, LNA와 LNA간 의 메시지로 나눌 수 있다.

와 간의 통신 메시지 (1) MAU LNA

그림 4는 MAU와 LNA간의 여러 메시지 중 데이터 요청 메시지의 구조를 나타낸 다. MAU와 LNA간의 메시지는 처음부터 두 번째 옥텟까지 MV4_MAGIC 이라 하여

(13)

메시지들을 구분해 주는 일종의 구분자 역할을 한다. 값은 0x5844를 가지게 된 다.

그림 4 MAU와 LNA간의 메시지 중 데이터 요청 메시지의 구조 Fig.4 Structure of Data request Message between MAU and LNA

이후 네 번째 옥텟까지의 두 옥텟은 메시지 코드가 자리하게 된다. 표 2에 나 타낸 메시지 코드는 메시지의 타입을 결정하기 위한 코드이며, 이 필드를 분석 함으로써 MAU 혹은 LNA가 어떤 기능적 역할을 해야 할지 결정된다.

Symbol Value Description

... ... ...

MAPI_CREQ 0x0206 Cancel request

MAPI_DACK 0x0207 Individual subscribe data MAPI_DREQ 0x0208 Individual subscribe request MAPI_FACK 0x0209 Function call acknowledge

MAPI_FBACK 0x020a Broadcast subscribe first acknowledge MAPI_FDACK 0x020b Individual subscribe first acknowledge MAPI_FREQ 0x020c Function call request

MAPI_FSACK 0x020d Subscribe first acknowledge MAPI_IACK 0x020e Interface open acknowledge MAPI_IDOWN 0x020f Signal remote interface down

MAPI_IOACK 0x0211 Interface open acknowledge from server MAPI_IOPEN 0x0210 Interface remote connect request MAPI_IREM 0x0213 Destroy interface

MAPI_IREQ 0x0212 Interface connect request MAPI_NREQ 0x0216 Non-acknowledged write request MAPI_OACK 0x0214 MAU open acknowledge

... ... ...

표 2 MAU와 LNA간의 메시지 코드

Table 2 Message code between MAU and LNA

(14)

여섯 번째 옥텟까지의 두 옥텟은 메시지의 우선순위를 나타낸다. 메시지의 우 선순위는 표 3에서 보는 바와 같이 낮음 보통, , 긴급의 세 분류로 나뉜다.

Symbol Value Description

PT_LOW 0 Low priority

PT_NORMAL 0x100 Normal priority PT_URGENT 0x800 Urgent priority 표 3 메시지의 우선순위 코드

Table 3 Priority code for messages

여덟 번째 옥텟까지의 값은 메시지의 최종 길이를 나타낸다. IEC 61162-4의 표준은 메시지의 처음을 나타내는 MV4_MAGIC은 있으나, 메시지의 마지막을 나 타내는 필드는 없으므로 메시지의 길이가 매우 중요하다. 이후 열 번째 옥텟까 지 MCP ID를 나타내며, 열두 번째 옥텟까지는 서버 MAU에서만 쓰이는 필드로 세션 코드를 나타낸다. 열여섯 번째까지의 네 옥텟은 Transaction ID를 나타내 며, 스무 번째까지의 네 옥텟은 클라이언트 MAU에서만 쓰이는 필드로 Timeout 혹은 Status를 나타낸다. 마지막으로 스물한 번째 옥텟부터 데이터가 들어가서

와 간의 메시지를 완성하게 된다

MAU LNA .

와 간의 통신 메시지 (2) LNA LNA

그림 5에서 보이는 것과 같이, LNA와 LNA간의 메시지 중 처음부터 두 번째 옥 텟까지 메시지의 구분자 역할을 하는 값인 MV4_MAGIC이다.

그림 5 LNA와 LNA간의 메시지 중 데이터 요청 메시지의 구조 Fig.5 Structure of Data request Message between LNA and LNA

네 번째 옥텟까지의 두 옥텟은 표 4의 메시지 코드 중 하나가 자리하게 된다.

(15)

Symbol Value Description CC_DEADMAU 0x0401 Warning about death of MAU CC_DEFMAU 0x0402 Define a new MAU

CC_METOO 0x0403 Warning of duplicate CC_REQMAU 0x0404 Request a MAU

CC_WATCHDOG 0x0405 General watchdog message from LNAs LLBC_AACK 0x0406 Anonymous broadcast acknowledgement LLBC_SACK 0x0407 Broadcast subscribe acknowledgement LL_ALIVE 0x0301 Liveness request

LL_DATA 0x0302 Data transfer

LL_DATAC 0x0303 Data transaction cancel LL_IFACK 0x0304 Interface connect acknowledge LL_IFREM 0x0305 Interface removal

LL_IFREQ 0x0306 Interface location request LL_MAUACK 0x0307 MAU name acknowledge LL_MAUREQ 0x0308 MAU name request

LL_NOMCP 0x0309 Returned bad transaction LL_SESSION 0x030a Session control message 표 4 LNA와 LNA간의 메시지 코드

Table 4 Message code between a LNA and other LNA

그 후, 우선순위, 메시지의 길이까지 여덟 옥텟이다. 이후 열 번째 옥텟까지 두 옥텟은 이 메시지를 받는 MAU의 ID를 나타내며, 열두 번째 옥텟까지 두 옥 텟은 이 메시지를 받는 MCP의 ID를 나타낸다. 이후 열네 번째 옥텟까지 두 옥 텟은 이 메시지를 보내는 MAU의 ID를 나타내며, 열여섯 번째 옥텟까지 두 옥 텟은 이 메시지를 보내는 MCP의 ID를 나타낸다. 열일곱 번째 옥텟부터 MAU의 메시지가 들어가서 LNA와 LNA간의 메시지를 완성하게 된다.

(16)

제 3 장 시스템 설계

시스템 구조 3.1

본 논문에서는 IEC 61162-4 네트워크에서 데이터 및 정보를 통합 관리하고 처 리하기 위한 시스템 구조를 제안하며 그림 6과 같다. NMEA 2000의 데이터를 데이터로 변환할 게이트웨이 변환된 데이터를 저장하고 관리하는

IEC 61162-4 ,

미들웨어 서버, 저장된 데이터를 보여주거나 실시간 데이터를 보여주는 어플리 케이션의 세 부분으로 나뉘며, 각각의 부분은 MAU와 LNA를 포함한 시스템으로 구성된다.

그림 6 전체 시스템 구성 Fig. 6 Overall system architecture

게이트웨이는 NMEA 2000 네트워크에서 발생되는 각종 데이터를 본 시스템에 쓰이는 태그 기반 데이터로 변환하는 기능을 담당한다. 미들웨어 서버는 게이 트웨이로부터 변환된 데이터를 수신하여 데이터베이스에 저장하고 통합 관리하

(17)

며 어플리케이션 등에게 송신하는 기능을 담당한다. 또한 각종 처리 과정이나 결과를 로그 파일에 기록하게 된다. 어플리케이션은 응용 시스템으로써 데이터 를 처리하여 사용자에게 다양한 서비스를 제공하는 기능을 담당한다. 예로써 각종 장치들에서 발생되는 데이터를 통합하여 하나의 화면에 표시하는 서비스 가 있다. 게이트웨이, 미들웨어 서버, 어플리케이션에는 데이터 및 정보 교환 을 위하여 통신프로토콜의 LNA 및 MAU가 내장되게 된다[2].

데이터 설계 3.2

데이터 3.2.1

게이트웨이는 NMEA 2000 네트워크와의 연동을 위한 부분이다. 시스템 간에 전 달되는 정보는 관련 표준(Companion Standard)에 의해 정의된다. 데이터 타입 정의(Data Type definition), 인터페이스 정의(Interface definition), 응용 명세(Application specifications), 정보 명세(Information specification)로 구성되는 관련 표준은 다양한 데이터에 의미를 부여하여 응용 및 시스템에 정 보로서 제공한다. 관련 표준은 이를 통해 네트워크에 전달되는 다양한 데이터 에 의미를 부여함으로써 응용 및 시스템에 정보로서 제공한다. 특히, 다양한 장치의 상태 등에 대한 값과 같은 정보 항목은 태그 이름에 의하여 식별되며 표 5와 같은 구조를 갖는다[1,3,5].

pMGnn.SGnn.TC.nn p

MG nn

SG nn

TC nn

- Identify p Class

- Main group (two letters)

- Optional main group instance number - Sub group (two letters)

- Optional sub group instance number - Data type code (two letters) - Unique serial number

표 5 태그 이름의 구조

Table 5 Structure of tag name

(18)

표 6은 NMEA 2000에서의 Device class, Device Function이 태그 이름으로 매핑 되는 것을 보여준다. 실제 장비에서 받은 데이터를 표 5와 같이 분석하고 표 6 을 참조하여 태그 이름으로 변환한다. NMEA 2000 device class의 Class Code와

의 와 에

Class Name, NMEA 2000 device function Function Code Function Name 따라 태그 이름의 Main group과 Sub group의 값으로 매핑 된다.

NMEA 2000 device class NMEA 2000 device function Tag name Class

Code Class Name Function

Code Function Name Main

group Sub group 00 Reserved for 2000 use

10 System tools TBD TBD

20 Safety systems 110 Alarm Enunciator

... ... ... ... ... ...

50 Propulsion systems

130 Engine room monitoring MP

... ... ...

210 Gauge Small

60 Navigation systems

130 Sounder, depth

NA 145 Global Navigation

Satellite System(GNSS) GP

... ... ...

... ... ... ... ... ...

표 6 NMEA 2000 Device class, Device function과 Main group, Sub group 매핑 정보 Table 6 NMEA 2000 Device class and function assign to Main group and Sub group

태그 이름 변환 규칙은 다음과 같다. 표 7에서 보는 바와 같이, NMEA 2000의 필드들은 크게 NAME필드와 PGN필드가 있는데, 각각의 태그 이름의 필드들과 매 핑 되어 변환이 가능하다. 첫 번째, NAME필드 중 Industry group은 Identify p

로 는 으로 는

class , Device class Main group , System instance Main group 로 매핑 되며 각각 의 태그 이름 포맷을 가진다 또

instance number p, MG, nnn .

한, Device function은 Sub group으로, Device instance는 Sub group instance 로 매핑 되며 각각 의 태그 이름 가진다 두 번째 필드 중

number SG, nnn . , PGN

(19)

은 로 매핑 되고 는 PGN field data type Data type code PGN+PGN field number

로 매핑 되며 각각 의 태그 이름 포맷을 가진 unique serial number TC, nnnnnnn

다.

NMEA 2000 Tag Name

Field Tag Name Format Description

NAME

Industry group (4=marine) p Identify p class

Device class MG Main group

System instance nnn Main group instance number

Device function SG Sub group

Device instance nnn Sub group instance number PGN PGN field data type TC Data type code (type/role)

PGN + PGN field number nnnnnnnn Unique serial number 표 7 NMEA 2000 태그 이름 변환 규칙

Table 7 A rule of tag name converting NMEA 2000

다음은 GPS 장치로부터 발생된 데이터를 태그 이름으로 변환하는 예를 나타낸 다. 표 8에서는 실제 GPS 장비에서 받아온 데이터들을 태그로 매핑 하기 위하 여 필드를 분석해 놓았다.

은 주소를 요구하기 위하여 사용되는 이다 네 번째 필드까지가

PGN 60928 PGN .

와 를 나타낸다 다섯 번째 필드부터 마지막 필

unique-number manufacture code .

드까지는 ECU Instance, function, function instance, device class, device 을 나타낸다 장비를 분석한 결과 은 class instance, industry group . , function

로써 표 을 참조하면 를 뜻한다 또한 는 으로 내비게이션을 145 6 , GNSS . device 60

나타내게 된다.

주소를 요구하는 과정이 마무리 된 후, 장비에서 실제 데이터를 전송하게 되 는데 GPS의 실제 데이터를 나타내는 PGN은 129026이다. 이 PGN은 Course Over

와 의 값을 가진다

Ground Speed Over Ground .

(20)

PGN: 60928

NAME: ISO Address Claim Data: 86 67 31 11 00 91 78 C0

86 67 10001 (unique-number) 001 11 (Manufacture code)

000 (ISO ECU Instance)

00000 (ISO Function Instance) 91 (Function)=>145:GNSS

0 (Reserved)

0111100 (Device class)=>60:내비게이션 0000 (Device class instance) 100 (Industry group)

1 (Self-configurable address) PGN: 129026

NAME: COG & SOG, Rapid Update Data: B0 FC 04 74 19 00 FF FF

B0 (SID)

00 (COG Reference)=>true 111111 (Reserved)

04 74 (Course Over Ground)=>170rad 19 00 (Speed Over Ground)=>0.25m/s

FF FF (Reserved) 표 8 GPS 데이터의 예

Table 8 Example of GPS data

표 9는 129026 PGN 번호를 갖는 GPS장비의 네 번째 필드를 표 7의 매핑 규칙 을 사용하여 태그 이름으로 변환하는 과정이다. 변환 과정을 보면, Industry

의 값이 이므로 태그 이름 포맷은 로 나타내고 가

group 100 , p , Device Class 60 의 값을 가지므로 Main Group은 내비게이션을 뜻하는 NA로 매핑 된다. 또한, 의 값이 태그로 변환하면 이 된다 그리고 Device class instance 0000 001 .

필드의 값이 인데 진수로 변환하면 가 되므로 를 나타내

Function 91 10 145 GNSS

게 된다. GNSS의 Sub Group은 GP로 매핑 된다. pNA001.GP001.AX.01로 변환되 며, 1의 태그 번호가 부여된다.

(21)

NMEA 2000 Field value Tag Name Format value

Industry group 100 p p

Device class 60 MG NA

Device class instance 0000 nnn 001

Function 145 SG GP

Function Instance 00000 nnn 001

Unit / meaning rad / Any meaning TC AX

PGN + PGN Field 129026+04 nnnnnnnn 12902604 표 9 PGN 129026-4th 필드와 태그 이름의 매핑

Table 9 Mapping of PGN 129026-4th field to tag name

표 10은 129026 PGN 번호를 갖는 GPS장비의 다섯 번째 필드를 표 7의 매핑 규 칙을 사용하여 태그 이름으로 변환하는 과정이다. 네 번째 필드와 같은 방법으 로 변환 결과 pNA001.GP001.SX.01로 변환되며, 2의 태그 번호가 부여된다.

NMEA 2000 Field value Tag Name Format value

Industry group 100 p p

Device class 60 MG NA

Device class instance 0000 nnn 001

Function 145 SG GP

Function Instance 00000 nnn 001

Unit / meaning m/s TC SX

PGN + PGN Field 129026+05 nnnnnnnn 12902605 표 10 PGN 129026-5th 필드와 태그 이름의 매핑

Table 10 Mapping of PGN 129026-5th field to tag name

데이터베이스 3.2.2

미들웨어 서버는 게이트웨이로부터 데이터를 수신하여 3개의 데이터베이스 테

(22)

이블에 나누어 저장하는 구조를 지닌다. 각각의 데이터베이스 테이블은 태그 번호와 태그 이름을 매핑 하여 저장하는 테이블, 태그 이름에 매핑된 태그 번 호에 대한 속성 값들을 저장하는 테이블, 마지막으로 해당 태그 번호로부터 전 송된 실제 데이터를 저장하는 테이블로 나뉘었다. 태그 이름과 태그 번호, 속 성과 값들을 한 테이블에 저장하기에는 저장 공간의 낭비가 있기 때문에, 매핑 된 값과 속성 값을 분리하기 위해, 또한 접근을 용이하게 하기 위하여 세 개의 테이블로 나누었다.

표 11은 태그 번호와 태그 이름을 매핑 하여 저장하기 위한 테이블이다. 절에서 설명한 게이트웨이에서의 태그 이름 매핑 규칙을 사용하여 변환하 3.2.1

게 되면 태그 이름과 부여된 태그 번호를 저장하도록 하였다. 태그 번호는 같 은 번호가 발생될 수 없도록 테이블을 설계하였다. 예를 들어, 한 GPS에서 발 생된 데이터를 매핑 규칙에 따라 변환하게 되면 태그 이름은

와 가 태그 번호는 과

pNA000.GP000.AX.12902604 pNA000.GP000.SX.12902605 , 1 2 가 된다. 다른 GPS에서 발생된 데이터를 매핑 규칙에 따라 변환하게 되면 태그 이름은 pNA000.GP001.AX.12902604와 pNA000.GP001.SX.12902605가, 태그 번호는

과 가 된다 101 102 .

Tag number Tag name

0 -

1 pNA000.GP000.AX.12902604 2 pNA000.GP000.SX.12902605

... ...

101 pNA000.GP001.AX.12902604 102 pNA000.GP001.SX.12902605

... ...

표 11 TagID 테이블 Table 11 Table of TagID

표 12는 태그 이름과 매핑된 태그 번호의 속성 값들을 저장하기 위한 테이블

(23)

이다. 태그 번호 1의 경우 course over ground를 나타내는 값이며, 단위는

을 쓰는 점 은 라는 점 초에 이 데이터가 번이 발

radian , precision 1.00E-04 , 1 4

생하는 점 등등을 알 수 있다. 또한, 태그 번호 2의 경우 speed over ground를 나타내는 값이며, 단위는 m/s를 쓰는 점, precision은 1.00E-02라는 점, 1초에 이 데이터가 4번이 발생하는 점 등등을 알 수 있다. 데이터가 장비에서 변환되 어 태그 이름과 태그 번호가 발생되면 TagID 테이블에 태그 번호와 태그 이름 을, TagInfo 테이블에 태그 번호와 그의 속성 값들을 저장하게 된다.

tagNumber description tagType engUnit euText tagSemantics

1 course over ground 0 20 rad 2

2 speed over ground 0 30 m/s 2

... ... ... ... ... ...

표 12 TagInfo 테이블 Table 12 Table of TagInfo

authentication precision sampleTime tagAttributes fieldFlags

1000 1.00E-04 250 0 1111111111

1000 1.00E-02 250 0 1111111111

... ... ... ... ...

표 13에서는 장비에서 실제 데이터를 받아 로그를 기록하기 위한 테이블이다. 표 11, 표 12의 테이블에서는 장비가 NMEA 2000 네트워크에서 처음으로 동작하 는 경우 저장하기 때문에 Tag number가 중복되지 않는다. 만약 중복된다면 무 시된다. 또한 표 13에 나타난 TagValue 테이블은 실제 장비에서 어느 시각에 어떤 값이 전송되었음을 기록하고, 관리하기 위한 테이블이다. 태그 번호 1번

가 년 월 일 시 분 초에 의 값을 초

course over ground 2009 8 5 9 7 1.25 2.8001 , 1.5 에 2.9001의 값을 가졌음을 알 수 있다. 또한, 태그 번호 2번 speed over

는 년 월 일 시 분 초에 의 값을 초에 의 값

ground 2009 8 5 9 7 1.25 12.01 , 1.5 13.01 을 가졌음을 알 수 있다.

(24)

tagNumber state alarm time(sec) time(usec) value

1 0 0 20090805090701 2500000 2.8001

2 0 0 20090805090701 2500000 12.01

1 0 0 20090805090701 5000000 2.9001

2 0 0 20090805090701 5000000 13.01

... ... ... ... ... ...

표 13 TagValue 테이블 Table 13 Table of TagValue

데이터 및 메시지 처리 3.3

데이터 처리 3.3.1

마샬링(Marshalling)이라 함은 하나 이상의 프로그램 또는 연속되어 있지 않 은 저장 공간으로부터 데이터를 모은 다음, 데이터들을 메시지 버퍼에 넣고, 특정 수신기나 프로그래밍 인터페이스에 맞도록 그 데이터를 조직화 하거나 미 리 정해진 다른 형식으로 변환하는 과정을 말한다. 메모리 공간의 할당은 운영 체제마다 다르나, Windows의 경우 할당된 메모리 공간의 마지막부터 읽어 와 데이터를 표현하며, Linux와 Unix는 정반대의 구조를 가진다. 본 논문에서는 운영체제가 Windows의 경우에만 해당하는 데이터 마샬링(Data Marshalling) 혹 은 패킹(Data Packing), 디마샬링(Data de-Marshalling) 혹은 언패킹(Data

을 구현하였다 정수형 정수형의 배열

Unpacking) . (integer type), (array of

부울형 부동 소수점형 부동

integers), (boolean type), (floating point type), 소수점 형의 배열(array of floating points), 문자형(character type), 문자 열 형(array of characters)의 기본 자료 형에 대한 마샬링 함수, 디마샬링 함 수인 pack, unpack을 구현하였다. 마샬링 클래스인 DataPackWrapper 클래스의 이란 함수를 호출하면 인수로 주어진 데이터의 메모리 공간을 읽어서 문자 pack

열 형으로 변환한다. 여러 번 pack을 호출하면 문자열에 데이터를 순차적으로

(25)

모으게 된다. 디마샬링 클래스인 DataUnpackWrapper클래스의 unpack이란 함수 를 호출하면 문자열을 읽어 인수로 주어진 데이터의 메모리 공간만큼 되돌린 다. 여러 번 unpack을 호출하면 모아진 데이터로부터 순차적으로 분리하여 메 모리 공간에 적재하게 하였다.

표 14는 데이터 패킹을 위한 클래스 설계를 나타낸다. 멤버 변수로 를 가지고 있다 부울형의 경우 한 바이 boolIndex, continueBool, msg, start .

트 내에 8개의 부울형 변수의 값이 들어갈 수 있다. 따라서 한 바이트에 몇 번 째 차례인지 알도록 하기 위하여 boolIndex라는 변수를 두었다. 8개 이하의 연 속된 부울형이 나올 경우에만 한 바이트 내에 저장할 수 있으므로 연속되는 값 인지 아닌지를 검사하기 위하여 continueBool이라는 변수를 두었다. 그리고 다 음 데이터를 패킹하기 위하여 모아진 데이터의 몇 번째 데이터인지 체크하기 위해 start라는 변수를 두었고, 패킹된 데이터를 저장하기 위한 msg라는 변수 를 두었다.

(26)

class DataPackWrapper{

/** Member Variables */

private:

int start;

int boolIndex;

char* msg;

bool continueBool;

/** Member functions */

public:

int getLength();

DataPackWrapper(void);

~DataPackWrapper(void);

char* pack(char* data, int arrlen, int byteOfType);

char* pack(int data, int byteOfType);

char* pack(int* data, int arrlen, int byteOfType);

char* pack(float data, int byteOfType);

char* pack(float* data, int arrlen, int byteOfType);

void pack(char* data);

void pack(int data);

void pack(int* data, int arrlen);

void pack(float data);

void pack(float* data, int arrlen);

void pack(bool data);

void pack(bool* data, int arrlen);

char* getData();

};

표 14 데이터 패킹을 위한 클래스 설계 Table 14 Class design for data packing

표 15는 데이터 언패킹을 위한 클래스 설계를 나타낸다. 멤버 변수로 를 가지고 있다 부울형의 경우 한 바이 boolIndex, continueBool, msg, start .

트 내에 8개의 부울형 변수의 값이 들어갈 수 있다. 따라서 한 바이트에 몇 번 째 차례인지 알도록 하기 위하여 boolIndex라는 변수를 두었다. 8개 이하의 연 속된 부울 형이 나올 경우에만 한 바이트 내에 저장할 수 있으므로 연속되는 값인지 아닌지를 검사하기 위하여 continueBool이라는 변수를 두었다. 그리고 다음 데이터를 언패킹 하기 위하여 모아진 데이터의 몇 번째 데이터인지 체크 하기 위해 start라는 변수를 두었고, 실제 디마샬링 할 데이터를 저장하기 위

(27)

한 msg라는 변수를 두었다. 각각의 데이터 형에 대한 언패킹은 오버 로딩으로 설계하였다. 언패킹을 하기 위하여 언패킹을 할 데이터를 설정하는 함수가 이다 그 후 함수를 호출하면 언패킹 된 데이터를 얻을 수 있 setData . , unpack

다.

class DataUnpackWrapper{

/** Member Variables */

private:

int start;

char* msg;

int boolIndex;

bool continueBool;

/** Member functions */

public:

DataUnpackWrapper(void);

~DataUnpackWrapper(void);

char* unpack(char* target);

int unpack(int target);

int* unpack(int* target);

float unpack(float target);

float* unpack(float* target);

bool unpack(bool target);

bool* unpack(bool* target);

char* unpack(char* target, int sizeofarr);

int unpack(int target, int byteOfType);

int* unpack(int* target, int byteOfType);

float unpack(float target, int byteOfType);

float* unpack(float* target, int byteOfType);

char* getData();

void setData(char* message);

};

표 15 데이터 언패킹을 위한 클래스 설계 Table 15 Class design for data unpacking

메시지 처리 3.3.2

모든 메시지 타입에 맞는 클래스를 만들어 사용하기 편하게 하였다. 만든 클

(28)

래스의 개수는 MAU와 LNA간의 메시지(MAU-LNA) 14개, LNA와 LNA간의 메시지 개 최상위 공통 클래스 개로 총 개의 메시지를 클래스로 만 (LNA-LNA) 15 , 1 , 30

들었다.

공통 메시지 (1)

공통 메시지 부분에 해당하는 클래스는 CommonMsg클래스이다. CommonMsg클래 스는 2.2.2절에서 설명한 메시지 옥텟 순서 중 8번째 옥텟까지를 저장하고 생 성하기 위한 클래스이다. 표 16에서 볼 수 있듯이 각각의 필드들을 멤버 변수 로 가지고 get~과, set~의 멤버 함수들을 이용하여 접근할 수 있도록 하였다. 또한 전체 메시지에 접근하기 용이하도록 설계하였다. 8진수 0x5844로 정해진

를 자동으로 입력하는 함수를 만들었다 세 우선순

MAGIC_CODE setMagicCode() .

위 중 선택하여 입력할 수 있도록 setUrgentPriority(), setNormalPriority(), 함수를 만들었으며 우선순위를 직접 입력할 수 있게 setLowPriority() ,

함수를 만들었다 에는

setPriority([MESSAGE_PRIORITY]) . [MESSAGE_PRIORITY]

표 2에 나타나 있는 PT_LOW, PT_NORMAL, PT_URGENT 중 하나를 넣게 하였다. 또 한, 메시지의 타입을 결정하기 위하여 setMsgType([MESSAGE_TYPE])을 만들었 고, [MESSAGE_TYPE]에는 표 3과 표 4를 참고하여 메시지의 종류를 결정하게 하 였다. 메시지의 길이를 입력하기 위하여 setMsgLength([MESSAGE_LENGTH])를 만 들었으며, 정수형과 short형을 [MESSAGE_LENGTH]에 넣을 수 있도록 오버 로딩 하였다.

(29)

class CommonMsg{

public:

/** Member variables */

word16_m magic_code; word16_m msg_type; word16_m priority;

word16_m msg_length; char* msg;

/** Member functions */

CommonMsg(void); CommonMsg(char* msg);

~CommonMsg(void);

short getState();

short getMsgLength();

void setMsgType(word16_m field); void setMsgType(short field);

void setMagicCode();

void setUrgentPriority();

void setNormalPriority();

void setLowPriority();

void setPriority(word16_m field); void setPriority(short field);

void setMsgLength(word16_m field); void setMsgLength(short field);

void setMsg(char* msg);

char* getMsg();

word16_m stow16(short input); word32_m stow32(int input);

short w16tos(word16_m field); int w32toi(word32_m field);

char* setField(char* field, char* message,

int startNumber, int endNumber);

template <typename T> char* memAlloc(T field, int octetSize);

};

표 16 공통 메시지 설계

Table 16 Design for common message

와 간의 메시지 (2) MAU LNA

그림 7은 MAU와 LNA간의 메시지, 공통 메시지를 나타낸 클래스들이다. 공통 메시지 클래스에서 상속받은 MAU_LNA클래스는 14개의 하위 클래스들의 공통부 분인 MCP ID, Session Code, Transaction identity, status or timeout필드들 을 멤버 변수로 하였으며 각각 get~, set~함수를 통하여 접근하도록 하였다.

예를 들어, 데이터 전송을 요구하는 메시지를 만들고자 할 때 클래스의 생성자를 사용하여 만들 수 있다 그리고 요구된

TransactionReqMsg .

(30)

의 생성자를 사용하여 메시지를 만들 수 있다. 두 클래스 모두 각각 data란 필 드를 가지고 있는데, data 필드는 getData, setData 함수를 통하여 접근할 수 있다.

그림 7 MAU와 LNA간의 메시지, 공통 메시지

Fig.7 Class Diagram of Messages Common, between MAU and LNA

와 간의 메시지 (3) LNA LNA

그림 8은 LNA와 LNA간의 메시지, 공통 메시지를 나타낸 클래스들이다. 클래스 또한 공통 메시지 클래스에서 상속받아 개의 하위 클래스들

LNA_LNA 15

의 공통부분을 멤버 변수로 하였고 각각 get~, set~함수를 통하여 접근하도록 하였다. 15개의 하위 클래스는 각각의 필드들을 멤버 변수로 가지도록 하였다. 예를 들어, 데이터 전송을 요구하는 메시지를 만들고자 할 때 DataTransfer 클

(31)

래스의 생성자를 사용하여 만들 수 있다. DataTransfer 클래스는

와 필드를 가지고

receiveMauID, receiveMcpID, sendMauID, sendMcpID mauMsg

있으며, 각각의 필드들은 get~, set~함수를 통하여 접근할 수 있다. 각각의 함수들은 형과 형을 인자로 받을 수 있도록 오버 로딩 되어 set~ word16_m short

있다.

그림 8 LNA와 LNA간의 메시지 공통 메시지,

Fig.8 Class Diagram of Messages Common, between LNA and LNA

및 에서의 메시지 패킹 언패킹

(4) MAU LNA ,

또한, MAU-LNA 메시지를 LNA-LNA 메시지로 쉽게 만들기 위하여

라는 클래스와 메시지 중 메시지를 가져오기

MsgPackWrapper , LNA-LNA MAU-LNA

위한 MsgUnpackWrapper라는 클래스를 만들어 MAU-LNA 메시지를 가져오고,

메시지를 만드는 작업을 쉽게 하였다 에는 이란

LNA-LNA . MsgPackWrapper pack

(32)

함수를 만들어 메시지 타입과 메시지에 들어갈 데이터를 주면 메시지를 반환 하도록 하였고, MsgUnpackWrapper에는 unpack이란 함수를 만들어 메시지 타입 을 주면 MAU-LNA 메시지를 반환하도록 만들었다.

아래의 표 17부터 표 20까지의 내용들은 MAU와 LNA상에서 동작하는 메시지 패 킹, 언패킹을 위한 함수 부분이다.

표 17은 MAU에서의 메시지 패킹을 구현한 것이다. 메시지 타입과 데이터, 데 이터의 길이를 입력으로 하여 함수를 호출하게 되면 패킹되어 MAU-LNA메시지를 반환한다. 데이터 전송 및 함수 로딩 요청 메시지 타입인 MAPI_FREQ와 데이터 전송 및 함수 로딩 요청 메시지의 응답 타입인 MAPI_FACK의 경우만 메시지 패 킹과 언패킹 하는 과정을 나타낸다.

(33)

MAU_LNA* pack(short msgType, char* inMsg, int strLen){

MAU_LNA* ml_msg;

switch(msgType){

case MAPI_FREQ:

ml_msg = new TransactionReqMsg();

ml_msg->setNormalPriority();

ml_msg->setMsgType(MAPI_FREQ);

ml_msg->setMcpID("MCPID");

ml_msg->setSessionCode(SESSION_C0);

ml_msg->setTRID(1);

ml_msg->setStatusOrTimeout(LM_OK);

ml_msg->setMsgLength(strLen+20);

((TransactionReqMsg*)ml_msg)->setData(inMsg);

break;

case MAPI_FACK:

ml_msg = new TransactionAckMsg();

ml_msg->setNormalPriority();

ml_msg->setMsgType(MAPI_FACK);

ml_msg->setMcpID("MCPID");

ml_msg->setSessionCode(SESSION_C0);

ml_msg->setTRID(1);

ml_msg->setStatusOrTimeout(LM_OK);

ml_msg->setMsgLength(strLen+20);

((TransactionAckMsg*)ml_msg)->setData(inMsg);

break;

case MAPI_AACK: case MAPI_AREQ: case MAPI_BACK: case MAPI_BREQ:

case MAPI_CACK: case MAPI_CREQ: case MAPI_DACK: case MAPI_DREQ:

case MAPI_FBACK:case MAPI_FDACK:case MAPI_FSACK:case MAPI_IACK:

case MAPI_IDOWN:case MAPI_IOACK:case MAPI_IOPEN:case MAPI_IREM:

case MAPI_IREQ: case MAPI_NREQ: case MAPI_OREQ: case MAPI_OACK:

case MAPI_RACK: case MAPI_RREQ: case MAPI_SACK: case MAPI_SESSION:

case MAPI_SREQ: case MAPI_WACK: case MAPI_WREQ: break;

}

return ml_msg;

}

표 17 MAU에서의 메시지 패킹 Table 17 Message packing in MAU

표 18은 MAU에서의 메시지 언패킹을 구현한 것이다. MAU-LNA 메시지를 입력으 로 하여 함수를 호출하게 되면 언패킹 되어 데이터를 반환한다. 데이터 전송 및 함수 로딩 요청 메시지 타입인 MAPI_FREQ와 데이터 전송 및 함수 로딩 요청

(34)

메시지의 응답 타입인 MAPI_FACK의 경우만 메시지 패킹과 언패킹 하는 과정을 나타낸다. MAU에서의 데이터 부분은 3.3.1절에서 설명한 마샬링된 데이터를 패 킹하고 언패킹 하도록 설계하고 구현하였다.

char* unpack(MAU_LNA* inMsg){

switch(inMsg->getState()){

case MAPI_FREQ:

((TransactionReqMsg*)inMsg)->setMsg(inMsg->getMsg());

return ((TransactionReqMsg*)inMsg)->getData();

case MAPI_FACK:

((TransactionAckMsg*)inMsg)->setMsg(inMsg->getMsg());

return ((TransactionAckMsg*)inMsg)->getData();

case MAPI_AACK: case MAPI_AREQ: case MAPI_BACK: case MAPI_BREQ:

case MAPI_CACK: case MAPI_CREQ: case MAPI_DACK: case MAPI_DREQ:

case MAPI_FBACK:case MAPI_FDACK:case MAPI_FSACK:case MAPI_IACK:

case MAPI_IDOWN:case MAPI_IOACK:case MAPI_IOPEN:case MAPI_IREM:

case MAPI_IREQ: case MAPI_NREQ: case MAPI_OREQ: case MAPI_OACK:

case MAPI_RACK: case MAPI_RREQ: case MAPI_SACK: case MAPI_SESSION:

case MAPI_SREQ: case MAPI_WACK: case MAPI_WREQ: break;

}

return "";

}

표 18 MAU에서의 메시지 언패킹 Table 18 Message unpacking in MAU

표 19는 LNA에서의 메시지 패킹을 구현한 것이다. 메시지 타입과 MAU-LNA 메 시지, 출력될 LNA-LNA메시지를 담을 공간, 출력될 메시지의 길이를 담을 공간 을 입력으로 하여 함수를 호출하게 되면 패킹되어 LNA-LNA메시지를 반환한다. 데이터 전송 메시지 타입인 LL_DATA의 경우만 메시지 패킹과 언패킹 하는 과정 을 나타낸다.

(35)

void pack(short msgType, char* inMsg, char* target, int* msgLen){

int tmpMsgLen = 0;

LNA_LNA* rtnMsg;

MAU_LNA* tempMsg = new MAU_LNA(inMsg);

switch(msgType){

case LL_DATA:

rtnMsg = new DataTransferMsg(tempMsg);

rtnMsg->setNormalPriority();

((DataTransferMsg*)rtnMsg)->setRcvMauID(11);

((DataTransferMsg*)rtnMsg)->setRcvMcpID(22);

((DataTransferMsg*)rtnMsg)->setSndMauID(33);

((DataTransferMsg*)rtnMsg)->setSndMcpID(44);

((DataTransferMsg*)rtnMsg)->setMauMsg(tempMsg);

break;

case LL_ALIVE: case LL_DATAC: case LL_IFACK:

case LL_IFREM: case LL_IFREQ: case LL_MAUACK:

case LL_MAUREQ: case LL_NOMCP: case LL_SESSION:

//LNA_LNA multi-cast messages

case CC_DEADMAU: case CC_DEFMAU: case CC_METOO:

case CC_REQMAU: case CC_WATCHDOG: case LLBC_AACK:

case LLBC_SACK: break;

}

tmpMsgLen = rtnMsg->getMsgLength();

for(int i=0;i<tmpMsgLen;i++){

target[i] = rtnMsg->getMsg()[i];

}

target[tmpMsgLen] = '\0'

*msgLen = tmpMsgLen;

}

표 19 LNA에서의 메시지 패킹 Table 19 Message packing in LNA

표 20은 LNA에서의 메시지 언패킹을 구현한 것이다. 메시지 타입과 LNA-LNA 메시지를 입력으로 하여 함수를 호출하게 되면 언패킹 되어 MAU-LNA메시지를 반환한다. 데이터 전송 및 함수 로딩 요청 메시지 타입인 MAPI_FREQ와 데이터 전송 및 함수 로딩 요청 메시지의 응답 타입인 MAPI_FACK의 경우만 메시지 패 킹과 언패킹 하는 과정을 나타낸다.

(36)

void unpack(short msgType, char* source, char* target, int* msgLen){

int tmpMsgLen = 0;

LNA_LNA* tempMsg = new LNA_LNA(source);

if(tempMsg->getState() == LL_DATA){

tempMsg = new DataTransferMsg(source);

MAU_LNA* rtnMsg;

switch(msgType){

case MAPI_FREQ:

rtnMsg = new TransactionReqMsg(

((DataTransferMsg*)tempMsg)->getMauMsg());

break;

case MAPI_FACK:

rtnMsg = new TransactionAckMsg(

((DataTransferMsg*)tempMsg)->getMauMsg());

break;

case MAPI_AACK: case MAPI_AREQ: case MAPI_BACK:

case MAPI_BREQ: case MAPI_CACK: case MAPI_CREQ:

case MAPI_DACK: case MAPI_DREQ: case MAPI_FBACK:

case MAPI_FDACK: case MAPI_FSACK: case MAPI_IACK:

case MAPI_IDOWN: case MAPI_IOACK: case MAPI_IOPEN:

case MAPI_IREM: case MAPI_IREQ: case MAPI_NREQ:

case MAPI_OREQ: case MAPI_OACK: case MAPI_RACK:

case MAPI_RREQ: case MAPI_SACK: case MAPI_SESSION:

case MAPI_SREQ: case MAPI_WACK: case MAPI_WREQ: break;

}

tmpMsgLen = rtnMsg->getMsgLength();

for(int i=0;i<tmpMsgLen;i++){

target[i] = rtnMsg->getMsg()[i];

}

target[tmpMsgLen] = '\0'

*msgLen = tmpMsgLen;

} }

표 20 LNA에서의 메시지 언패킹 Table 20 Message unpacking in LNA

데이터 전송 3.3.3

에서 로 에서 로 에서 로 데이터를 전송하기 위해 그림 MAU LNA , LNA LNA , LNA MAU

(37)

와 같은 순서로 전송하고 받게 된다 구현한 부분을 간단히 설명하면 다음과

9 .

같다.

에서 클래스의 함수를 번 이상 호출하여 데

1) LOCAL MAU DataPackWrapper pack 0 이터를 마샬링 한다.

는 모아진 데이터로 함수를 통하여 메시지를 만든 2) LOCAL MAU pack MAPI_xREQ

다.

로 전송한다 3) LOCAL LNA .

가 로부터 메시지를 받으면 함수를 통하여 메시지 4) LOCAL LNA MAU pack LL_DATA

를 만든다.

로 전송한다 5) RLNA(Remote Local Network Administrator) .

는 로부터 메시지를 받으면 함수를 호출하여 메시지를 얻

6) RLNA LNA unpack MAU

는다.

메시지를 로 전송한다

7) MAU RMAU(Remote MiTS Application Unit) .

에서 메시지 중 데이터 부분만 추출하기 위해 함수를 호출한다

8) RMAU unpack .

추출한 데이터를 클래스의 을 번 이상 호출하여

9) DataUnpackWrapper unpack 0 디마샬링 한다.

그림 9 일반적인 데이터 전송 과정 Fig. 9 Data Transfer process generally

(38)

제 4 장 시스템 구현

와 어플리케이션은 에서 개발되었으며 게이

MAU, LNA, TLI Visual Studio 2008 , 트웨이는 Visual Studio 6.0에서 개발되었다. 어플리케이션은 C#을 사용하였 고, 그 외의 부분은 C++로 개발되었다. 그림 10은 실제 구현된 전체 시스템이 다. 세 부분을 제어하고자 모니터 한 대, 키보드 한 대, 세 부분을 한 시스템 에 구축하고자 랙을 사용하였다.

그림 10 구현된 시스템 Fig. 10 Implemented System

(39)

게이트웨이 4.1

그림 11은 구현된 게이트웨이의 동작 화면이다. 게이트웨이는 장비들로부터 데이터를 전송받아 태그 변환 규칙에 따라 태그 이름과 태그 번호로 NMEA 2000

변환하는 역할을 한다. 3.1절의 시스템 구조처럼 게이트웨이는 홀로 동작하지 않고, MAU와 LNA를 거쳐서 미들웨어 서버와 같이 동작하도록 구현하였다. MAU 는 DLL형태로 되어 있어 태그 변환 프로그램과 함께 동작하도록 하였으며, LNA 는 MAU와 태그 변환 프로그램과 다른 프로세스로 동작하도록 하였다. 태그 변 환 프로그램에서 Connect 버튼을 클릭하면 장비와 연결을 시도한다. 장비와 연 결이 성공하면 내부의 MAU에서 LNA와 통신을 위한 사전 작업을 하게 되고, LNA 와 연결이 되면 실제 데이터가 전송되게 되어 있다.

태그 변환 프로그램의 왼쪽 상단의 화면은 연결된 장비와의 통신을 위한 프로 그램 세팅 작업을 나타낸다. 왼쪽 중앙의 화면은 현재 장비들로부터 전송되는 데이터를 보여준다 왼쪽 하단의 화면은 시리얼 통신의 포트와 전송률

NMEA . ,

통신의 전송률을 설정하는 화면과 이외의 설정을 할 수 있는 버튼

NMEA Config ,

장비로부터 데이터를 받기 시작하는 Connect버튼이 있다. 오른쪽 상단 화면은 정보를 분석하는 화면이고 하단의 화면은 특정 에 대한 상세 정보를

PGN , PGN

태그로 변환된 정보를 나타낸다.

(40)

그림 11 게이트웨이의 동작 화면 Fig. 11 A snapshot of Gateway

미들웨어 서버 4.2

미들웨어 서버는 데이터를 저장하고 관리하기 위한 부분이다. 게이트웨이 혹 은 어플리케이션의 MAU가 LNA를 거쳐 데이터를 요청하는 메시지를 보내게 되면 미들웨어 서버의 LNA가 받아서 LNA 메시지의 헤더를 제거하고 MAU 메시지를 받 고 MAU로 보낸다. MAU는 LNA로부터 받은 메시지의 타입을 체크하고, 데이터 전 송과 관련된 메시지인 MAPI_xREQ 일 경우, 데이터를 분석한다. 함수 호출 부분 인 MAPI_FREQ 메시지인 경우에만 처리하도록 하였다. 데이터는 함수명의 길이, 함수명, 함수명이 set으로 시작할 경우 인자 값들을 디마샬링 하게 된다. 하지

(41)

만 함수명이 get으로 시작할 경우 함수명의 길이, 함수명을 디마샬링 한다. 디 마샬링한 함수를 호출하기 위해 여러 함수들을 구현하였다.

(1) getTagOneValue

입력 인자들은 태그 번호, 태그 값을 저장할 주소이다. 입력된 태그 번호를 기준으로 검색하여 최신 값 순으로 정렬하여 하나의 값을 가져온다.

(2) getTagOneValueList

입력 인자들은 태그 번호, 태그 값들을 저장할 주소, 태그 값의 개수를 저장 할 주소이다. 입력된 태그 번호를 기준으로 검색하여 최신 값 순으로 정렬하여 태그 값의 구조들의 리스트를 최대 40개까지 가져온다.

(3) setTagValue

을 입력으로 받아서 각각 구조의 값을 데이터베이스에 저장한다

TagVal .

(4) setTagValueList

태그 값의 리스트를 입력으로 받아 각각 구조의 값을 데이터베이스에 저장한 다. 리스트는 최대 40개 까지 가능하다.

(5) getTagOneValueInterval

태그 번호, 태그 번호에 대한 값들의 개수를 저장할 주소, 시작 시각, 끝 시 각을 입력으로 받는다. 입력된 태그 번호를 기준으로 검색하여 최신 값 순으로 정렬하여 최대 40개까지의 값을 가져온다.

(6) getTagNameList

입력은 없으며, 이 함수를 호출할 때 연결된 장비들의 p 클래스 태그 이름들 을 최대 50개 까지 가져온다.

미들웨어 서버에서 동작하는 함수들과 게이트웨이, 응용프로그램에서 사용가 능한 함수들은 이름은 같을지라도 내부적으로 하는 동작이 다르다. 미들웨어 서버에서 동작하는 함수들은 미들웨어 서버 시스템에 있는 데이터베이스에 접 속하여 조회 혹은 삽입하고, 조회한 함수는 그 결과를 마샬링 하여 MAU와 LNA 간의 메시지 중 MAPI_FACK 메시지를 만들어 LNA에게 전송하는 동작을 한다. 미

(42)

동작하며, LNA가 또 다른 프로세스로 동작하게 되어 있다. 하지만 미들웨어 서 버가 아닌 게이트웨이와 응용 프로그램의 시스템에서의 함수들은 함수명의 길 이, 함수명, 함수명이 set으로 시작할 경우의 인자 값들을 마샬링하고 함수명 이 get으로 시작할 경우 함수명의 길이, 함수명을 마샬링 하여 MAU_LNA 메시지 로 만들어 LNA로 전송하는 동작을 한다. 게이트웨이와 응용프로그램에서의 함 수들은 DLL(Dynamic Link Library)로 만들어 범용화 하였다. 그림 12는 미들웨 어 서버의 동작 화면으로써 좌측 상단에 있는 콘솔 화면이 MAU, 우측 하단에 있는 콘솔 화면이 LNA의 동작 화면이다.

그림 12 미들웨어 서버의 동작 화면 Fig. 12 A snapshot of Middleware server

어플리케이션 4.3

(43)

그림 11은 구현된 어플리케이션의 동작 화면이다. 콘솔로 표현된 부분이 LNA 와 TLI가 결합된 형태로 되어 있고, 어플리케이션에서는 MAU와 결합되어 미들 웨어 서버에 저장된 데이터를 전송받아 화면에 출력하는 역할을 한다. 지도로 표시된 부분이 GPS에서 현재 좌표를 받아와서 표시해 주고, 표시된 좌표를 클 릭하면 풍속, 기압, 풍향, 수심, 배의 속도, Course Over Ground의 최근 값을 출력하도록 하였다. 각각의 게이지를 클릭하면 최근 데이터의 동향을 꺾은선 그래프로 나타나도록 하였다. 미들웨어 서버에서 설명한 여러 함수 중, get으 로 시작하는 함수를 주로 사용하도록 하였다.

그림 13 어플리케이션의 동작 화면 Fig. 13 A snapshot of Application

(44)

제 5 장 결론 및 향후 과제

본 논문에서는 IEC 61162-4 네트워크에서 동작하는 시스템을 개발하기 위한 게이트웨이, 미들웨어 서버, 어플리케이션 세 부분으로 나누어진 시스템 구성 을 제시하였다. NMEA 2000에서 발생하는 데이터를 분석하여 IEC 61162-4 네트 워크의 프로토콜에 맞게 태그로 변환하는 과정을 살펴보았으며 IEC 61162-4 네 트워크에서 전송되는 프로토콜을 분석하였다. 그리고 분석한 프로토콜을 토대 로 하여 TLI상에서 MAU와 LNA간, LNA와 LNA간의 상호 통신하는 메시지들을 구 현하였고, 메시지의 데이터 부분에 들어갈 데이터 중 기본 데이터 형에 대한 마샬링 ․ 디마샬링을 구현하였다.

향후 연구 과제로서 사용자 정의 클래스 혹은 구조체의 마샬링 ․ 디마샬링의 연구가 필요하다. 그리고 MAU와 LNA간, LNA와 LNA간의 메시지 처리 부분 중 함 수 형태뿐만 아니라 다른 형태의 메시지 처리 부분을 추가하는 연구가 필요하 다. 또한 범용적이며 더 많은 동작을 할 수 있도록 연구가 필요하며 Companion

의 더 많은 함수가 구현되어야 할 것이다

Standard .

(45)

참고 문헌

박휴찬 이장세 장길웅 이정우 정희섭 박중현 강순열 선박에서의

[1] , , , , , , , "

통합 정보처리를 위한 시스템 아키텍처", 2009년도 전기학술대회논문집, 한국마린엔지니어링학회, 2009.

[2] National Marine Electronics Association, NMEA 2000◯R Standard for Serial-Data Networking of Marine Electronic Devices, Version 1.2, 2004.

[3] IEC 61162-4 : Maritime Navigation and Radiocommunication Equipment and Systems - Digital Interfaces - Multiple Talkers and Multiple Listeners - Ship Systems Interconnection, 2001.

서기얼 오세웅 조득재 박상현 서상현 정중식 의 국제

[4] , , , , , , "E-Navigation

동향과 구현 방향", 한국해양정보통신학회논문지, 제10권 12호, pp.

2127-2131, 2006.

이장세 박휴찬 장길웅 이주형 장남주 이주영 이부형 선박 내 정보

[5] , , , , , , , "

의 통합 관리를 위한 정보 아키텍처", 2009년도 전기학술대회논문집, 한 국마린엔지니어링학회, 2009.

김용성 완벽 가이드 영진출판사

[6] , Visual C++ 6 , , 2001.

김선우 윈도우 네트워크 프로그래밍 한빛미디어

[7] , , , 2004.

안토니 존스 짐 오룬드 랜스 올슨

[8] , , , Network Programming For The 정보문화사

Microsoft .NET Framework, , 2005.

김상형 닷넷 프로그래밍 정복 가메출판사

[9] , , , 2008.

[10] Timothy A. Budd, Cay Horstmann, Big C++, Wiley, 2004

(46)

감사의 글

걱정이 많았고 탈도 많았던 논문의 마지막 수정을 마치고 나니 한결 마음이 편해집니다. 한 문단, 한 문장, 한 단어까지도 몇 번을 쓰고 지웠던 기억이 아 직도 생생합니다. 제 표현력을 이렇게 탓해 본 적도 없었고, 머리를 원망해 본 적도 없었던 만큼 짧은 논문이나마 논문을 쓴다는 것이 얼마나 힘든 일인지, 또한 논문을 쓰고 계시는 교수님들이 얼마나 존경스러운지 새삼스레 느꼈습니 다. 많은 분들의 도움으로 간신히 논문을 마칠 수 있었습니다.

먼저, 학부 때부터 항상 신경 써 주시고 많은 고민도 함께 해 주신 지도 교수 님 박휴찬 교수님께 감사드립니다. 건강이 안 좋으신 데도 부족한 저를 여기까 지 이끌어 주신 교수님의 인자하심을 평생 간직하도록 하겠습니다. 항상 안부 를 물어주시는 류길수 교수님, 만날 때 마다 칭찬해 주시는 김재훈 교수님, 바 쁘신 데도 논문에 많은 신경을 써 주신 이장세 교수님과 장길웅 교수님, 항상 인사드릴 때마다 웃어 주시는 신옥근 교수님과 손주영 교수님, 이서정 교수님 께 감사드립니다.

또한 많은 조언과 칭찬을 해 주신 이성대 형님을 비롯하여 데이터베이스 실험 실 선배님들, 인공지능 실험실 선배님들, 자연어 처리 실험실 선배님들, 보안 시뮬레이션 실험실의 후배님들, 네트워크 실험실 선배님들께 감사드립니다. 항 상 웃음과 믿음을 주시는 강군호 조교님, 김경언 조교님 감사합니다. 논문 쓴 다고 바쁜 와중에도 건강 챙기라는 친구들, 대학 동기들과 후배들 모두 감사드 립니다.

마지막으로 바쁘다는 핑계로 매일 집에도 안 가도 이해 해주시던 부모님의 배 려와 성원, 정말 감사드립니다.

참조

관련 문서

전화 회사는 음성을 최대 4000 Hz 주파수를 갖는 것으로 가정하고 디지털화한다.. 사람의

회선 교환에서는 설정 단계에서 자원 할당이 필요하며, 해제 단계에 들기 전까지는 계속해서.. 전체 데이터 전송 기간

위하여 연결설정(SYN) 요청 à 위조된 IP 주소로 부터 응답(ACK)을 받을 때까지 대기 q 위조된 대량의 연결설정(SYN) 요청 패킷이 수신되면 서버의 대기

◈ _messageEntries: 각 메시지 종류에 따라서 메시지 식별 번호, Function Pointer 등을 가 지는 엔트리의 Array. ◈ messageMap: 기반 클래스의 messageMap에 대한

또한, 「기상청 데이터 관리 및 제공 규정」 제6조(공공데이터제공담당관의 임무)에는 데이터 관리에 관한 기본정책의 수립 및 제도의 개선, 데이터 통계의 작성·관리

여러분이 열심히 참여하 다보면 스마트폰이 단순히 문자 메시지 전송, 전화, 카카오톡, 카카오스토리, 페이스북, 트위터 뿐만 아니라 다양한 기능이 있음을 알게

 왼쪽 마우스를 클릭하면 출력하던 것이 멈췄을 때, WM_LBUTTONDOWN 메시지 처 리를 하는 곳으로 메시지 제어권을 보내주므로

 주 프로그램과 인터럽트 서비스 루틴 사이를 요청/응답 인터페이스로 연결함으로써 상태도 기반 알고리즘 구성을 이해할