교통카드관련 장비의 전국호환성 인증요령 개정 요청

(국토교통부 고시 제2010-180호, 2010. 4. 6)

1		국가표준규격 카드의 사용배제에 따른 사회적 비용 해소요구

정책의 일관성 유지에의 배치문제

❍ 2004년 1월 표준 지불 SAM(KS X 6923)이 제정되고 이를 국토교통부(당시 건설교통부)에서 설치 권고하였음.

- 2004.1.26일 차관주재 시·도 부단체장 회의 및 2004.2.9일 시·도 담당사무관 회의 등 다수

❍ 국토교통부의 권고에 따라 우리시에서는 표준 지불 SAM(KS X 6923)을 교통단말기에 장착하여 운영하였으며, 표준 카드(KS X 6924)가 제정되지 않은 상황에서도 표준 지불 SAM에서 사용될 수 있는 카드를 제작 공급하였고, 귀 부에서 2010년도 카드규격을 제정하기 이전에도 국가표준규격(KS X 6924)에 부합한 교통카드를 제작 공급하여 시민들이 안정적으로 사용할 수 있도록 하였음.

❍ 시민들의 편의와 산업발전을 위한 국가표준정책에 따라 국가표준 KS X 6923과 KS X 6924를 적용하였으므로 이미 발급되어 사용되고 있는 선불전자지불수단(교통카드)이 국토교통부에서 추진하고 있는 전국호환 카드사업에서 배제되면 신뢰보호에 저촉되어 카드발행사나 카드소지자에 대한 손해배상 책임문제 발생함.

막대한 사회적 비용발생 문제

❍ 국토교통부는 교통카드의 표준에 따라 교통운영기관이 관리하는 수집센터 및 단말기 FW 변경이 필요 없을 것으로 판단하나, 교통카드의 처리, 통제 및 제어를 위한 방법이 상이할 경우 이에 따른 FW의 변경과 추가 비용이 필요하고(현재와 같은 카드 호환 시에는 별도 소요되는 비용 발생이 없음.) 정산사업자가 관리하는 정산센터의 변경도 필요하며 관련 비용의 규모는 카드의 사용 여건(교통카드 제어방식 등)에 따라 커질 가능성이 큼.

- 권종 변경 등 새로운 카드 제어 처리 방안이 적용될 경우 시스템 변경 요소가 계속 발생함.

예) 새로운 전국호환카드 제어 방식 중 기존의 방식이 아닌 KL(Killing List)제어 방식을 적용할 경우 사업자간의 호환을 위한 비용 부담 등 합의의 필요성 대두

❍ 국가표준 KS X 6923과 KS X 6924 규정에 맞도록 교통카드를 발행했음에도 현재 사용 중인 교통카드를 국토교통부 제정 전국호환 규격이 아니라는 이유로 신규 사용처에 사용을 제한할 경우 이에 따른 카드교환 또는 사용자의 신규 구입에 따른 사회적 비용이 발생함.

(기 발행한 티머니 카드 약 9,600만장)

국가표준카드(KS X 6924) 한시적 인정 필요

❍ 국가표준규격(KS X 6924)에 따라 발행된 교통카드에 대해서는 경과규정을 마련하여 일정기간(국토교통부 규격에 따른 교통카드의 발급비율이 50%를 초과할 때까지) 국토교통부 규격으로 인정 필요

2		전국호환성 인증요령에 치명적 결함 존재로 인증요령을

수용하기 위해서는 인증요령 개정 선행 필요

인증요령의 운영 ․ 기술적 문제

❍ 우리시가 국토교통부 전국호환카드의 발행을 추진하였으나 국토교통부 고시 제2010-180호「교통카드 관련 장비의 전국호환성 인증 요령」에 운영 및 기술적인 면에서 결함 존재가 발견되었는 바, 이의 개정 요구가 반영될 경우 국토교통부에서 제정한 인증요령에 따라 전국호환카드를 발행하는 것을 추진(검토)

운영 ․ 기술적 문제(예시)

❍ 인증요령에 정의한「카드 소지자 정보」를 수용할 경우 현재 시행중인 대중교통요금체계가 운영될 수 없고, 향후 다양한 요금정책의 지원도 불가능

❍ 인증요령에 정의된「부가정보 파일」을 준수할 경우 전국의 모든 교통운영기관 별로 IDCENTER를 부여 받아 생성하는 것이 불가

❍ 어플리케이션 정보조회 프로토콜에 따를 경우 기 발급되어 다수가 사용되고 있는 카드의 처리순위가 뒤로 밀려 카드처리시간의 지연에 따른 민원발생

「교통카드 관련 장비의 전국호환성 인증 요령」개정(안) : 별첨

인증요령 개정건의(안)

1		카드 소지자 정보 삭제

현  황

○ 카드 소지자 정보의 성격

- 카드 소지자(카드 타입) 정보는 카드를 소지하고 있는 사람의 정보를 표시함.

- 단말기에서 교통카드에 저장되어 있는 카드 소지자 정보를 확인하여 기본요금을 결정함.

○ 카드 소지자 정보의 현황

(출처: 국토교통부 고시 제2010-180호)

제1부 기본구조  8.3.2 교통호환 정보

소지자 정보

카드를 소지하고 있는 사람의 정보를 표시하며 자세한 사항은 아래와 같다.

Value	설 명	Value	설 명
01	일 반	11	버 스
02	어 린 이	12	화 물 차
03	청 소 년	13
04	경 로	14
05	장 애 인	15

문제점

○ 카드소지자 정보 제한

- 버스 및 화물차는 카드를 소지하고 있는 사람의 정보가 아님.

- 관련 법령 및 시행령에 따라 경로 및 유공자, 장애인 등의 경우 철도 및 버스 등의 대중교통에서는 무임 서비스를 적용받고 있음.

- 특히, 유공자는 철도와 버스가 모두 무임이나, 경로와 장애인은 철도만 무임, 버스는 유임으로 사용하고 있음. 이에 장애인이 버스를 승차할 경우, 일반․어린이․청소년에 따라 기본요금이 산정되고 있으며, 중증 장애인은 동반 1인이 무임으로 철도를 사용할 수 있는 등 여러 가지의 경우가 존재함.

- 요령(별표1 8.3.2(교통호환정보)에서 정의하고 있는 소지자 정보를 사용하여 장애인 등에 대하여 기본요금을 산정할 수 없는 문제점이 발생함.

- 따라서, 현재 시행되고 있는 요금체계도 수용할 수 없는 치명적 결함이 존재함.

예) 중증, 경증 및 일반장애인, 청소년장애인, 어린이장애인 등 미구분

- 또한, 인증 요령에 정의된 소지자 정보는 지자체에서 새롭게 수립, 제공할 수 있는 다양한 교통요금 정책을 지원하기 어려움.
예) 다자녀 가구, 임산부, 다문화 가구를 위한 교통 요금 정책

○ 기존 통합권종 적용 불가

- 우리시에서는 현재 통합권종 카드를 발급하여 사용자가 임의로 권종을 변경하여 사용 가능하도록 지하철 역사서비스 센터 또는 편의점에서 서비스를 제공하고 있음.

- 전국 호환성 인증요령에 의거 전국호환카드를 발행하게 되면 우리시에서 제공하였던 권종변경 서비스가 제한되므로 우리시에서 전국호환 교통카드를 발급하고자 하는 경우 인증요령에서 규정한 “카드 소지자 정보”를 삭제하여야 발급이 가능함.

개정 방안

○ 카드를 소지하고 있는 사용자의 정보를 표시하는 “소지자 정보”는 이미 각 사의 교통호환 카드에서 정의하여 사용하고 있음으로, 서비스 및 정책의 유연성을 위하여 소지자 정보의 삭제가 필요

2		부가정보의 기록(Tag의 구성 삭제)

현 황

○ 부가정보파일의 성격

- 부가정보파일의 목적은 환승정보, 입구정보 등 거래 시 요금을 계산하고 사용자에게 다양한 서비스를 제공하기 위한 여러 부가 정보를 저장하고 관리하는 파일임.

- 교통카드를 교통 단말기에 태그하였을 때, 단말기에서 교통카드에 기록되어 있는 부가정보파일의 정보를 조회하여 요금 및 서비스를 준비, 제공하고

- 교통 단말기는 징수된 요금 등 제공한 서비스의 정보를 구성하여 교통카드의 부가정보파일에 정보를 기록하게 됨.

- 부가정보파일에 기록되는 정보 중 Value의 구조는 각 교통 사업자가 필요한 정보를 임의로 기록할 수 있음(국토교통부 고시 제2010-180호)

○ 부가정보파일 중 Tag 구성의 현황

(출처: 국토교통부 고시 제2010-180호)

제1부 기본구조  8.5.4 부가정보의 기록

Tag의 구성

부가 정보 파일에 기록할 Tag의 경우 부가 정보 파일의 기록 주체를 확인할 수 있도록 거래 시 아래의 규칙에 따라 Tag를 구성한다. 또한 교통 호환 Application은 부가 정보 파일의 Tag 값을 확인하거나 조작하지 않는다.

B8	B7	B6	B5	B4	B3	B2	B1	내용
1	1	0	-	-	-	-	-	교통 사업자의 구분

Tag는 B5～B1에 현재 거래를 하는 교통 사업자의 IDCENTER값을 기록한다.

즉 IDCENTER가 ‘01’의 경우 Tag를 ‘C1’로, ‘11’의 경우 Tag를 ‘D1’로 기록한다.

문제점

○ 요령(별표1, 8.5.4 부가정보의 기록)에 의거 Tag를 생성․기록하기 위하여서는 부가 정보 파일의 기록 주체를 확인할 수 있는 교통 단말기의 소유․운영 주체인 버스 조합(버스 운수사) 및 철도 기관별로 코드가 할당 운영되어야 함.

○ 요령에서 정의되어 있는 IDCENTER(한국전자지불산업협회에 등록된 전자화폐 고유 식별번호)를 사용하기 위하여 전국의 많은 교통운영기관 등 현재 교통카드 발행사로 등록되어 있지 않아 추가적으로 많은 기관들이 등록을 수행하여야 함.

○ 요령에 의거 IDCENTER를 부여 받아 생성할 수 있는 수는 31개 기관(25=32, 0x00 Reserved)이며, 이미 13번(0x0D)까지(2009년 11월 기준, 국토교통부 고시 제2010-180호) 등록되어 있음.

제1부 기본구조  8.3.2 교통호환 정보

IDCENTER

IDCENTER는 한국전자지불산업협회에서 지정한 교통 사업자의 고유 번호이다. 교통호환 사업자는 고유의 IDCENTER값을 가지고 있으며 이를 표시하는 영역이다. 자세한 사항은 한국전자지불산업협회 (http://kepia.org/) 또는 IDCENTER 관리기관의 전자화폐 고유 식별번호를 참조한다.

IDCENTER	사업자
0x00	Reserved
0x01	금융결제원
0x02	에이캐시
0x03	마이비
0x04	Reserved
0x05	브이캐시
0x06	몬덱스코리아
0x07	한국도로공사
0x08	한국스마트카드
0x09	코레일네트웍스
0x0A	Reserved
0x0B	이비
0x0C	서울특별시버스운송사업조합
0x0D	카드넷

2009년 11월 한국전자지불산업협회에 등록된 전자화폐 고유 식별번호

(출처: 국토교통부 고시 제2010-180호)

○ 따라서, 요령의 방식으로는 전국의 수많은 교통운영기관 별로 코드를 부여할 수 없음.

개정 방안

○ 전국의 모든 교통운영기관 별로 IDCENTER를 부여 받아 생성하는 것이 불가하고 현재 부가정보로 사용하고 있는 환승정보의 경우, 부가정보의 기록 주체를 확인할 수 있는 여러 부가정보를 이미 별도 기록 관리하고 있으므로 요령에 기재된 부가정보의 기록 중 Tag의 구성은 삭제가 바람직함.

3		어플리케이션 정보조회 프로토콜 한시적 권고사항으로 조정

현 황

○ 어플리케이션 정보 조회 프로토콜의 성격

- 프로토콜은 CONFIG DF가 교통호환 카드에 탑재되어 있을 때, 어떻게 교통호환 어플리케이션의 정보를 조회할 수 있는 지를 정의한 것임.

- 교통카드를 교통 단말기에 태그하였을 때, 단말기는 CONFIG DF를 우선 선택 및 조회하여 CONFIG DF에 저장되어 있는 교통호환 어플리케이션의 정보를 획득하고

- 획득된 교통호환 어플리케이션의 정보를 통하여, 교통호환 어플리케이션을 선택 후 거래 프로세스를 진행하게 됨.

○ 어플리케이션 정보 조회 프로토콜의 현황

(출처: 국토교통부 고시 제2010-180호)

제2부 명령어 및 프로토콜

6.6 Application 정보 조회 프로토콜

표준호환카드의 모든 거래는 거래 전 다음과 같은 프로토콜을 수행하여 Application 정보를 조회한다. 단 Application의 정보를 알고 있는 경우 생략 할 수도 있다.

지불SAM                     단말기                 전자화폐 카드(EP)

Application 정보 파악

- CONFIG DF 확인

-Response

- EF CONFIG 확인

-Response

Select CONFIG DF

Read EF CONFIG

문제점

○ 요령(별표1, 6.6 Application정보조회 프로토콜)에 의거 단말기에서는 교통카드를 태깅하였을 때 우선적으로 CONFIG DF를 선택하고 정보를 조회하여야 함.

< 교통카드 처리 프로세스 >

<그림 1> 기존 교통카드 처리 프로세스	<그림 2> CONFIG DF 포함 처리 프로세스

○ 현재는 <그림 1> 기존 교통카드 처리 프로세스를 따라 기존 여러 교통카드를 처리하고 있음.

○ 요령에 의거, 단말기에서 카드 처리 순서를 CONFIG　DF를 우선으로 처리하는 경우, 많이 사용되는 다른 카드 우선 순위가 뒤로 밀려 기존 카드 사용자가 체감하는 카드 처리 시간의 지연으로 민원이 발생할 우려가 있음.

개정 방안

○ 단말기에서 조회하는 교통카드의 순서는 지자체 또는 교통 단말기 소유․운영 주체가 판단하여 결정하는 것이 기존 사용자의 편의성을 증대하고 민원 요소를 줄이는 것이므로 국토교통부 규격의 교통카드 이용율이 기존의 교통카드 이용율 보다 높을 때까지 한시적으로 어플리케이션의 정보를 조회하는 방식을 권고사항으로 변경 적용하고 그 이후에는 국토교통부 전국호환카드 Config DF를 우선 호출하도록 강제사항으로 개정.

4		인증 요령 개정(안) (별표1)

현  행

개  정(안)

제1부 기본구조

8.2 CONFIG DF

"교통카드"에서는 각 사와의 호환사용을 위하여 존재하는 ADF이며 "교통 카드"의 교통 호환 ADF의 정보를 저장하고 있다. 교통 호환 ADF의 정보를 외부에 제공하는 역할을 하며 최초의 거래 시 필수적으로 CONFIG DF를 선택하여야 한다.

제1부 기본구조

8.2 CONFIG DF

"교통카드"에서는 각 사와의 호환사용을 위하여 존재하는 ADF이며 "교통 카드"의 교통 호환 ADF의 정보를 저장하고 있다. 교통 호환 ADF의 정보를 외부에 제공하는 역할을 하며 거래 시 CONFIG DF를 선택할 수 있도록 한다.

8.2 CONFIG DF

FCI(File Control Information)

파일 구조						Lf
파일 크기
레코드번호	Tag			Length	항목		Value	비고	조건
1	6F				FCI Template				필수
		84			DF Name				필수
		A5			FCI Proprietary Template				필수
			50	2	카드 규격 및 선후불 구분		01 00(선불) 11 00(후불)		필수
			47	2	지원 항목				필수
			43	1	IDCENTER				필수
			11	5	잔액 조회 명령(선불 필수)				선택
			4F	5~16	교통 호환 ADF AID				필수
			9F10	3*N	부가 Data File 정보				필수
			45	1	카드 소지자(카드타입) 정보				필수
			5F24	2	유효기간				필수
			12	8	카드일련번호(후불 필수)				선택
			13	8	카드관리번호				선택
			BF0C	Var	FCI Issuer Discretionary Data				선택

8.2 CONFIG DF

FCI(File Control Information)

파일 구조						Lf
파일 크기
레코드번호	Tag			Length	항목		Value	비고	조건
1	6F				FCI Template				필수
		84			DF Name				필수
		A5			FCI Proprietary Template				필수
			50	2	카드 규격 및 선후불 구분		01 00(선불) 11 00(후불)		필수
			47	2	지원 항목				필수
			43	1	IDCENTER				필수
			11	5	잔액 조회 명령(선불 필수)				선택
			4F	5~16	교통 호환 ADF AID				필수
			9F10	3*N	부가 Data File 정보				필수
					< 삭제 >
			5F24	2	유효기간				필수
			12	8	카드일련번호(후불 필수)				선택
			13	8	카드관리번호				선택
			BF0C	Var	FCI Issuer Discretionary Data				선택

8.3 EFCONFIG

CONFIG DF 하위에 존재하며 실제 교통 호환용 Application 에 대한 정보를 저장하고 있다. Read Record 명령으로 파일 내용의 정보가 조회 가능하다.

EFCONFIG를 통하여 얻을 수 있는 정보는 아래와 같다.

카드가 지원하는 “호환 카드”규격 버전

“호환 카드” 규격 중 카드가 지원하는 항목

교통 호환 ADF의 AID

교통 호환 ADF에서의 존재하는 부가정보 파일의 정보

카드 소지자에 대한 정보

각 교통 호환 카드 사업자의 임의의 정보

카드 유효기간

잔액 조회 명령 (선택 사항)

EFCONFIG 파일은 1개 이상의 레코드로 구성되어 있으며 1번 레코드는 필수 항목이며 교통 호환을 위한 정보를 저장하고 있다. 2번 이하의 레코드는 선택 사항으로 발급사가 임의의 데이터를 저장할 수 있다.

DF Select시 FCI로 조회하는 방법과 하위 EF파일을 조회하는 방법이 있다. FCI응답으로 EFCONFIG 파일의 1번 레코드의 데이터를 포함하는 경우 FCI Proprietary Template Tag인 ‘A5' Tag에 포함 되어야한다.

파일 구조					Lf 또는 Lv
파일 크기					Var.
SFI					01
읽기 권한					Free
쓰기 권한					(주)
레코드번호	Tag		Length	항 목		Value	비고	조건
1	87			Config Data Template			교통호환 정보	필수
		50	2	카드 규격 및 선후불 구분		01 00(선불) 11 00(후불)		필수
		47	2	지원 항목				필수
		43	1	IDCENTER				필수
		11	5	잔액 조회 명령(선불 필수)				선택
		4F	5~16	교통 호환 ADF AID				필수
		9F10	3*N	부가 정보 파일				필수
		45	1	카드 소지자(카드타입) 정보				필수
		5F24	2	유효기간				필수
		12	8	카드일련번호(후불 필수)				선택
		13	8	카드관리번호				선택
		BF0C	Var	카드 사업자 임의의 정보				선택

8.3 EFCONFIG

CONFIG DF 하위에 존재하며 실제 교통 호환용 Application 에 대한 정보를 저장하고 있다. Read Record 명령으로 파일 내용의 정보가 조회 가능하다.

EFCONFIG를 통하여 얻을 수 있는 정보는 아래와 같다.

카드가 지원하는 “호환 카드”규격 버전

“호환 카드” 규격 중 카드가 지원하는 항목

교통 호환 ADF의 AID

교통 호환 ADF에서의 존재하는 부가정보 파일의 정보

< 삭제 >

각 교통 호환 카드 사업자의 임의의 정보

카드 유효기간

잔액 조회 명령 (선택 사항)

EFCONFIG 파일은 1개 이상의 레코드로 구성되어 있으며 1번 레코드는 필수 항목이며 교통 호환을 위한 정보를 저장하고 있다. 2번 이하의 레코드는 선택 사항으로 발급사가 임의의 데이터를 저장할 수 있다.

DF Select시 FCI로 조회하는 방법과 하위 EF파일을 조회하는 방법이 있다. FCI응답으로 EFCONFIG 파일의 1번 레코드의 데이터를 포함하는 경우 FCI Proprietary Template Tag인 ‘A5' Tag에 포함 되어야한다.

파일 구조					Lf 또는 Lv
파일 크기					Var.
SFI					01
읽기 권한					Free
쓰기 권한					(주)
레코드번호	Tag		Length	항 목		Value	비고	조건
1	87			Config Data Template			교통호환 정보	필수
		50	2	카드 규격 및 선후불 구분		01 00(선불) 11 00(후불)		필수
		47	2	지원 항목				필수
		43	1	IDCENTER				필수
		11	5	잔액 조회 명령(선불 필수)				선택
		4F	5~16	교통 호환 ADF AID				필수
		9F10	3*N	부가 정보 파일				필수
				< 삭제 >
		5F24	2	유효기간				필수
		12	8	카드일련번호(후불 필수)				선택
		13	8	카드관리번호				선택
		BF0C	Var	카드 사업자 임의의 정보				선택

8.3.2 교통호환 정보

소지자 정보

카드를 소지하고 있는 사람의 정보를 표시하며 자세한 사항은 아래와 같다.

Value	설 명	Value	설 명
01	일 반	11	버 스
02	어 린 이	12	화 물 차
03	청 소 년	13
04	경 로	14
05	장 애 인	15

< 삭제 >

8.5.4 부가 정보의 기록

Tag의 구성

부가 정보 파일에 기록할 Tag의 경우 부가 정보 파일의 기록 주체를 확인할 수 있도록 거래 시 아래의 규칙에 따라 Tag를 구성한다. 또한 교통 호환 Application은 부가 정보 파일의 Tag를 값을 확인하거나 조작하지 않는다.

B8	B7	B6	B5	B4	B3	B2	B1	내용
1	1	0	-	-	-	-	-	교통 사업자의 구분

Tag는 B5～B1에 현재 거래를 하는 교통 사업자의 IDCENTER값을 기록한다.

즉 IDCENTER가 ‘01’의 경우 Tag를 ‘C1’로, ‘11’의 경우 Tag를 ‘D1’로 기록한다.

< 삭제 >

제2부 명령어 및 프로토콜

6.6 Application 정보 조회 프로토콜

표준호환카드의 모든 거래는 거래 전 다음과 같은 프로토콜을 수행하여 Application 정보를 조회한다. 단 Application의 정보를 알고 있는 경우 생략 할 수도 있다.

지불SAM                     단말기                 전자화폐 카드(EP)

Application 정보 파악

- CONFIG DF 확인

-Response

- EF CONFIG 확인

-Response

Select CONFIG DF

Read EF CONFIG

제2부 명령어 및 프로토콜

6.6 Application 정보 조회 프로토콜

표준호환카드의 모든 거래는 다음과 같은 프로토콜을 수행하여 Application 정보를 조회한다. 단 Application의 정보를 알고 있는 경우 생략 할 수도 있다.

지불SAM                     단말기                 전자화폐 카드(EP)

Application 정보 파악

- CONFIG DF 확인

-Response

- EF CONFIG 확인

-Response

Select CONFIG DF

Read EF CONFIG