Ⅰ. 서 론
2007년 전국개통을 통해 본격 서비스가 시작된 하이패스는 2013년 334개 영업소 운영(896차로)되 고 이용률 58.8%이며, 하이패스 단말기(이하 OBU, On-Board Unit)는 883만대가 보급되었다.[1]
또한 2009년 『One Card All Pass 표준기술 개발 및 테스트베드 운영』(2009.9, 국토교통과학기술진흥 원)연구를 통해 전국호환카드가 개발되었으며, 이를 적용하기 위해 국가적인 움직임을 보이고 있다.[2]
이에 따라 전국호환카드를 자동요금징수시스템 (이하 ETCS, Electronic Toll Collection System)에 적 용하여 이용자에게 보다 편리하고 다양한 서비스를 제공하고 기존에 보급되어 있는 OBU 및 ETCS 인 프라와 전국호환카드를 활용해 교통편의시설 전자 결제 서비스를 제공하는 연구를 진행하였다.[3]
ETCS와 전국호환카드를 활용한 전자결제 서비 스를 개발하기 위해서는 기존 인프라를 활용한 결 제서비스 적용방안이 필요하며, 기존 인프라의 인 터페이스 추가 및 시스템 구성의 변경을 통해 서비 스를 구현할 수 있다.
하지만 인터페이스와 시스템 구성 변경을 통해 서비스를 구현하는 경우, 기존 구축된 시스템 변경 비용이 소요되어 중복투자를 발생 시키며, 이러한 서비스를 적용하기 위해서는 전국호환카드 적용방 안과 교통편의시설 결제에 대한 표준이 명확하게 이루어져야 한다.
현재 이와 관련한 기준이 마련되지 않아 개발되 는 시스템간 상호호환성에 문제가 발생하고 이로 인해 운영관리에 많은 시간과 비용이 소요될 것으 로 예측된다.
이에 본 논문에서는 기존 인프라와 연계성을 확 보하고, ETCS에 전국호환카드를 적용하는 방안을 제시하고자 한다.
이를 위해 시범운영 사이트에 시스템을 구현하 고 전국호환카드 결제지원 OBU, 기존 OBU, 시험 차량으로 차량주행을 통해 통신과 시스템 성능을 테스트 하였다.
Ⅱ. 관련 표준 현황 분석
ETCS의 전국호환카드 적용을 위해 관련분야 표 준의 현황을 분석하였다.
1. DSRC 표준 현황
DSRC기반 교통편의시설 결제시스템에 적용되는 DSRC관련 표준범위로 ETCS 응용 프로그램 인터페 이스와 DSRC 응용계층 인터페이스 그리고 DSRC 통신 표준이 있다.
DSRC 응용계층은 KS X ISO 15628에 정의되어 있으며, ETCS 응용 프로그램 인터페이스는 KS X ISO 14906에 정의되어 있다. 또한 통신 표준은 IR (적외선)방식은 KS X 6915에 정의되어 있고 RF(무 선주파수)방식은 TTAS.KO-06.0025/R1에 정의되어 있다.
2. DSRC 응용 서비스에 적용되는 표준
DSRC기반 교통편의시설 결제 적용을 위한 표준 은 DSRC 관련분야 KS X ISO 15628, KS X ISO 14906 표준이 있다.
DSRC 관련분야 표준인 통신절차는 KS X ISO 15628에서 정의된 절차를 준수하고 있으며, KS X ISO 14906은 DSRC를 이용한 전자요금징수(EFC, Electronic Fee Collection) 시스템에 대한 응용 프로 그램 인터페이스를 규정하고 있다.[4]
1) KS X ISO 15628
KS X ISO 15628은 DSRC를 기반으로 응용계층 상 하위계층의 기능을 포함하는 서비스 프리미티브 (Service Primitive)를 통해 응용서비스처리과정 (Application Process)에서 사용되는 커널들을 설명하 고 있다.
KS X ISO 15628의 응용계층은 전송커널 (T-Kernel), 초기화커널(I-Kernel), 방송커널(B-Kernel) 로 구성된다.
응용인터페이스 메시지 BST, VST, ACTION, GET, SET은 DSRC 응용계층의 관점에서 서비스라 부르며, 이들 서비스는 전송 커널로 서비스를 제공 하게 된다.
-
INITIALISATION : 초기화커널을 통해 제공되 는 서비스(BST, VST)
-
GET : 상대방의 응용서비스 정보를 읽어오는 데 사용됨
-
SET : 상대방 응용서비스 정보를 수정하는 사 용됨
-
ACTION : 응용서비스가 동작을 실행하도록 하는데 사용됨
-
EVENT-REPORT : 응용서비스 또는 초기화 커널에 이벤트를 알리는데 사용됨
전송커널은 각 서비스의 프리미티브를 통해 서 비스들이 제공된다. 서비스 프리미티브는 request, indication, response, confirm이 있으며, 제공되는 형 태는 서비스명에 프리미티브가 붙은 형태인 GET.request, Get.response로 표현한다.
DSRC를 이용한 ETCS의 요금징수기술은 DSRC 를 기반으로 교통편의시설의 이용요금을 현금․수 표 등이 아닌 전자거래로 지불하는 징수체계(ETCS, Electronic Toll Collection System)를 적용하기 위해 세부 메시지 형식, 요금처리절차, 어플리케이션 인 터페이스형식을 정의하고 있다.[6,7]
ETCS 응용프로그램은 초기화절차, 징수절차, 후 속처리 절차로 나누고, 각 서비스의 적용에 대한 구 체적인 내용을 설명하고 있다.
ETC 응용프로그램이 사용하는 정보 형식은 OBU 와 카드에 대한 발행정보 및 어플리케이션 정보의 포맷을 의미하는 것으로 속성(Attribute) 형태로 지 정된다. 각 Attribute는 서비스별 메시지의 세부 항 목 중 Container filed의 Octetstring에 설정된다.[4]
Container::=CHOICE { integer [0] INTEGER, bitstring [1] BIT STRING, octetstring [2] OCTET STRING (SIZE (0..127),...), universalString [3] UniversalString, beaconId [4] BeaconID, ... }
2) KS X ISO 14906
응용인터페이스 메시지는 BST, VST, ACTION, GET, SET으로 구성되며, RSE(Road Side Equipment) 는 응용인터페이스의 메시지를 전달하기 위한 I-Kernel(초기화 커널)을 구성하고, EFC를 위해 응용 프로그램 식별자(AID)를 1로 설정하여 사용한다.
AID는 DSRC에서 응용서비스를 식별하기 위한 것으로, 각 응용인터페이스 메시지가 사용되는 용 도를 의미하며, KS X ISO 14906은 EFC를 위한 것 으로 Electronic-Fee-Collection 서비스에 사용되는 어 플리케이션을 호출하는 의미로 AID 1을 사용한다.
Ⅲ. 제안하는 전국호환카드 적용방안
ETCS에 전국호환카드 적용 위해서는 KS X ISO 14906, KS X ISO 15628에서 정의하는 서비스의 데 이터 형식을 기반으로 기존 RSE와 OBU간 DSRC 통신에 다음과 같이 적용하였다.
1. 다양한 ICC(Integrated Circuit(s) Card) 결제 적용 방안
전자카드의 거래절차는 초기화 명령어(Initialize), 지불거래 명령어(Purchase), 지불거래 명령어(Credit), 거래완료명령어(Complete Purchase)로 분류되며, PSAM과 ICC간 거래절차는 아래와 같다.
기존 ETCS 거래절차에 전국호환카드 거래를 위 해 응용어플리케이션의 종류를 설정하는 AID (Application Identifier)에 기존 전자지불거래에서 사 용되는 1번(전자지불용)을 지정하고 AID의 각 속성 별 서비스를 설정하는 EID(Element Identifier)에는 0 번을 지정하여 기존 서비스의 충돌을 회피하였다.
또한 OBU의 TRANSFER_CHANNEL 사용으로 PSAM과 ICC간 거래 명령어를 OBU와 RSE가 전자 카드 결제절차의 전달자 역할을 통해 다양한 ICC결 제가 가능 하도록 구현 했다.
이에 따라 다양한 ICC결제를 위해 DSRC기반의 RSE와 OBU간 통신절차를 다음과 같이 정의 한다.
DSRC를 이용한 응용인터페이스 메시지 BST의 응용 프로그램 식별자 AID는 기존의 ETCS의 AID 인 전자요금징수 EFC, Electronic-Fee-Collection⑴로 지정하여 전송한다.
BST에 대한 응답으로 VST는 요소식별자 EID와 Context Mark 값을 지정하여 전송한다.
EID는 0으로 지정하고, VST의 EID가 0일 경우 TRANSFER_CHANNEL을 사용해 ICC 결제를 위한 지불 거래 절차를 수행한다.
VST로부터 전달받은 EID는 DSRC 세션동안 OBU 내에서 동일한 값을 유지하며, Context Mark는 다양한 종류의 ICC결제를 위해 기존 서비스와 중복 을 고려한 고유 값을 사용한다.
ICC는 고유의 DF(Dedicated File) Name을 갖고 있 으므로, ICC가 ETC용 DF를 제공할 경우, ETC의 Context Mark를 포함하는 파라미터를 RSE에 전달 하며, 그 외의 DF Name을 가지고 있을 경우에는 다양한 ICC결제를 위해 신규로 부여된 Context Mark와 attribute를 RSE에 전달한다.
Context Mark는 ITSK-00035 DSRC를 활용한 서비 스분류체계를 따르며, 내용은 아래 표와 같다.
TRANSFER_CHANNEL은 RSE와 OBU간 데이터 송․수신 요청 채널로 ICC 응답 정보(Command Read/Write)를 ICC결제 수행을 위해 N회 반복하여 송․수신한다.
ACTION-TRANSFER_CHANNEL.Request는 OBU 의 할당된 채널로 데이터를 전송하거나 전송 받기 를 요청하며, ChannelId 파라미터로 ICC 명령을 위 한정보를 전송한다.
ACTION-TRANSFER_CHANNEL.Response는 OBU 에 할당된 채널을 통해 요청된 데이터의 전송 또는 수신에 대한 응답으로써 ChannelId 파라미터로 ICC 응답 정보를 전송한다.
EVENT-REPORT는 서비스는 응용서비스 단에 이벤트를 알리는 데 사용하며, 다양한 ICC거래에서 는 통신종료 메시지로 활용한다.
2. 전국호환카드결제 적용 방안
다양한 ICC 결제 방안에 전국호환카드 지불결제 절차 적용은 아래와 같다.
전국호환결제를 위해 응용인터페이스 메시지BST 를 정보형식 AID 값을 1로 지정하여 OBU에 전송 한다. 응답 메시지 VST는 EID는 0으로 지정하고, Attribute ID #1, 3를 파라미터로 RSE에 전송한다.
ACTION-TRANSFER_CHANNEL.Request는 ChannelId 파라미터로 ICC 명령을 위한정보 Initialize Card, Purchase Card를 전송, 이에 대한 응 답으로 ACTION-TRANSFER_CHANNEL.Response는 OBU에 할당된 채널에 ChannelId 파라미터로 ICC 응답 정보인 인증 값 S1, S3를 전송한다.
모든 지불거래가 완료되면 EVENT-REPORT. Request를 거래를 종료한다.
이렇게 구성된 통신절차를 적용하여 RSE와 OBU 간 통신, ICC에 명령어 및 응답정보를 전송하여 전 국호환카드 결제가 가능하게 된다.
IV. 시스템 구성과 시험
제안한 적용방안의 유효성을 검증하기 위해 교통 편의시설 전자결제시스템 및 전국호환카드 결제지원 OBU를 개발하였으며, 개발된 결제시스템과 OBU을 활용해 주행환경을 고려한 시험을 수행하였다.
1. 시스템 구성
시스템구성은 전국호환카드 결제지원 OBU, 고정 형기지국제어기, 고정형기지국안테나, 교통편의시설 정산시스템으로 구성되며, 고정형기지국 제어기와 고정형기지국안테나는 기존 하이패스카드 및 전국 호환카드 모두 요금징수가 가능하도록 개발하였다.
고정형기지국제어기는 안테나를 제어하고, OBU 와 송․수신한 결과와 결제정보를 기록하며, 또한 결제정보를 정산시스템으로 전송한다.
고정형기지국제어기와 고정형기지국안테나는 표 준을 적용한 시스템이며, 고정형기지국안테나의 높 이는 3m, 통신영역은 교통편의시설 환경과 유사한 형태로 구성하였다.
RSE IR/RF 모두 길이4~5m, 폭 3~3.5m로 구성 하였 으며, 아래 그림과 같이 시험전 통신영역을 확인하였다.
또한 결제용 OBU는 기존 OBU와 전국호환카드 결제지원 OBU로 준비하여 표준적용 여부와 기존 OBU 수용 여부를 함께 확인하였다.
시험차량 3대에 OBU를 설치하고 하이패스카드 와 전국호환카드를 나누어 삽입하여 고정형기지국 안테나의 통신영역을 시나리오별로 주행하여 통신 및 결제정보를 확인하였다.
2. 시험방법
주행시험은 주행속도별 주행시험과 군집/정차 주 행 시험, 야간주행 시험으로 전체 400회 주행하여 통신성공 여부를 확인 하였다.
교통편의시설 환경을 고려하여 주행차로 및 진 출입구가 협소한 환경으로 고려하여 주행속도는 30Km/h이하로 설정하였다.
1) 주행속도별시험
시험차량 3대가 고정형기지국안테나의 통신영역 을 10Km/h ~ 30Km/h의 속도로 순차적으로 주행속 도별로 주행하여 시험한다.
2) 근접/정차 주행 시험
시험차량 3대가 근접하여 주행하며 승합차 뒤 경 차가 1m 차량간격 및 속도를 유지하며 주행하고, 일부 차량이 통신영역에서 30초 또는 1분정차 시험 한다.
근접주행시 차량의 OBU의 부착위치를 변경 또 는 OBU 2대를 장착하여 시험한다.
3) 야간 주행 시험
야간에 시험차량 3대가 근접하여 10Km/h ~ 30Km/h의 속도로 주행하여 시험하고, 진입 차량이 통신영역의 좌/우로 밀착주행 시험한다.
3. 성능시험결과
다양한 조건의 주행결과 전체 1,230회 통신 중 1,228회의 통신 성공과 2회의 통신실패를 하였다.
시험결과 약 99%의 통신 성공률과 약 1%의 통 신실패률로 보아 교통편의시설 ETCS로 사용하는데 문제없음을 확인 하였다.
4. 에러 원인 분석
각 시험방법별 성능시험을 수행한 결과를 토대 로 에러의 원인을 분석해보면 다음과 같다.
통신영역에서 정차시험은 안테나 통신영역에서 30초 또는 1분 정차하여 OBU와 안테나간 통신에 영향이 없는지 테스트 하는 시험으로 근접/정차 주 행 시험 180회 통신 중 179회의 통신 성공과 1회의 통신 실패함.
근접/정차 주행시험 방법 및 차량배열은 아래 그 림과 같다.
통신영역에서 1분 정차시험 에러 원인은 통신영 역이 불안정하여 통신영역 안의 차량과 통신영역 밖의 시험차량이 동시 통신하여 오류 발생하였다.
OBU 부착위치별 시험은 시험차량 내부에 OBU 부착 위치에 따른 통신 영향이 없는지를 테스트 하 는 시험으로 부착위치별 90회 통신 중 89회의 통신 성공과 1회의 통신 실패하였고, OBU 부착위치 및 1회 실패한 부착위치는 아래 그림과 같다.
OBU 부착위치별 통신 실패 원인은 통신영역이 좁고 불안정하여 OBU와의 통신오류가 발생한 것으 로 판단된다.
통신영역에서 1분 정차시험에서 1회, OBU 부착 위치별 시험 1회의 오류가 발생하였고, 주행속도별 좌/우 밀착시험 등 일반적인 상황보다 특수한 상황 에서 오류가 발생하였다.
다음 표는 시험항목별 주행횟수, 전체 통신회수, 통신 성공회수, 통신 성공률을 정리한 것이다.
Ⅴ. 결 론
현재 전국호환카드 및 ETCS을 이용한 교통편의 시설 전자결제 분야의 다양한 연구가 진행 중이지 만, 전국호환카드를 활용한 교통편의시설 ETCS 적 용방안이 명확하게 정의되어 있지 않다.
이러한 상황에서 전국호환카드를 적용한 교통편 의시설 전자결제시스템을 적용하기에는 많은 어려 움이 있다.
이에 본 논문은 ETCS에 전국호환카드 적용방안 을 제안하고, 제안한 표준을 교통편의시설 전자결제 시스템에 적용하여 시범운영 사이트에 구현하였다.
이렇게 구축된 시스템에서 주행시나리오별 실험 을 한 결과 구현된 시스템은 약 99% 통신 성공률을 나타냈다. 여기서 약 1%의 에러가 나타났으며, 이 에러의 원인분석 결과 에러의 주요인은 통신영역 설정과 연관 있음을 알 수 있었다.
현재 DSRC안테나의 경우 하이패스와 관련된 연 구만 진행되고 있으며, 교통편의시설과 같은 서비 스 적용에 대한 연구는 아직 미비하기에 다양한 서 비스 적용 연구가 필요하다.
ETCS에 전국호환카드 적용방안 연구로 교통편 의시설에서 전국호환카드를 활용하여 요금징수가 가능한 것을 확인 하였다.
본 연구로 개발된 시스템을 주차장 외에 셀프주 유소, 휴게소, Drive through 등 다양한 결제시스템 에 활용이 가능 하다.
향후 다양한 서비스로 확장하여 자유롭게 적용 되어 활용될 것으로 판단된다.
