裴 练 军

(上海华虹计通智能系统股份有限公司 上海 201206)

0 引 言

随着我国城市化进程的进一步加快和城市规模的逐步扩大，城市轨道交通已成为大中型城市最重要的基础交通设施之一[1]。

城市轨道交通自动售检票系统是现代化的收费系统，一般采用五层架构：第一层为城市轨道交通票务清分系统，第二层为线路中央计算机系统，第三层为车站计算机系统，第四层为车站终端设备，第五层为车票。乘客可通过售票、检票设备实现关于车票票务的自助服务，最终在票务清分系统实现各运营商的收益分配[2]。

作为城市轨道交通自动售检票系统的第五层——车票层，轨道交通售检票系统支持的票卡类型有很多。储值类票一般分单程票、储值票和二维码支付等。储值票遵循的标准一般可分为地铁自发一票通卡、住建部一卡通卡、交通部一卡通卡和银行卡支付等。除二维码外，其他车票类型均为非接触式IC卡[3]，非接触式IC卡是城市轨道交通自动售检票系统中的常规基础票卡类型。不同类型的票卡同时在检票机上使用，这样的应用场景决定了终端设备须快速识别车票类型，并予以处理。

近年来，全国各地城市轨道自动售检票接入“互联网+”得到了大力发展，快速培养新一代的熟悉非接触式IC卡的开发人员任务越来越紧迫；与此同时，基于非接触式IC卡的公共交通行业优惠应用也督促开发商和开发人员需要响应快速。

1 现状分析

城市轨道交通是一种大运量交通运输系统，自动售检票系统须适应客流密集的进、出站需求。目前，轨道交通领域使用的非接触式IC卡种类较多，为了识别和区分，现常用的方法包括有：常量值法和命令重试法。

常量值法是指根据特定命令返回的常量值，标记不同车票介质的类别。采用常量值法可在车票种类较少时可快速区分不同的车票种类，但在自动售检票系统支持较多票卡供应商、较多发行方的车票时往往导致识别重试增多。

命令重试法是指尝试发送不同票卡的交易指令，以是否获得成功应答的方式来识别票卡。这种方式将导致交易时间过长，从而延长了整个的交易流程时间。

随着技术发展，轨道交通售检票终端设备已从单片机向嵌入式操作系统扩展。在传统的开发环境下，票卡处理业务应用与射频驱动应用是紧密耦合在一起，开发人员既需要了解硬件设计、掌握射频驱动，又需要关注业务需求，并将两者紧密结合在一起完成应用软件开发。这种开发方式既对开发人员提出了很高的要求，也不能快速响应业务变化的外部需求。

因此，通过分析票卡的物理特性，参考ISO-14443国际标准来识别票卡，归纳出层级软件开发架构不失为一种解决方法。

2 票卡物理介质

在轨道交通领域使用的非接触式IC卡物理介质主要包括有基于MIFARE Ultralight的单程票、基于MIFARE Classic的储值票和基于MIFARE Pro卡的储值票。目前，基于MIFARE Pro卡的储值票成为应用主流。

2.1 单程票

MIFARE Ultralight卡是一种小容量、符合ISO1443-A的存储车票。Ultralight车票有以下典型特点[4]：

1) 具有7个字节唯一物理卡号；

2) 具有4字节OTP；

3) 一般容量512位，分为16个page，每个page为4个字节；

4) 具有Lock锁功能，可对关键数据区进行锁；

5) 数据区可任意读、写。

MIFARE Ultralight卡本身不具备逻辑判断功能，在轨道交通应用时一般作为循环使用、面值不高的单程票。

MIFARE Ultralight卡的存储结构如图1所示。

图1 MIFARE Ultralight卡存储结构图

2.2 MIFARE Classic卡

MIFARE Classic卡是一种广泛应用的非接触式IC卡，包括MIFARE S50、MIFARE S70等，常用来作为储值卡使用。在轨道交通领域常使用是MIFARE Classic卡是1 KB容量、符合ISO14443-A[5]。

MIFARE Classic具有以下特点：

1) 具有4个字节的唯一物理序列号；

2) 每个块有16个字节，4个块组成一个扇区。1 KB容量的共有16个扇区；

3) 每个扇区可独立设置读、写权限，只有认证通过才可对本扇区的块进行读、写操作；

4) 扇区可分为数据区和值区,值区一般用于存储卡片金额数据。

MIFARE Classic卡本身具有逻辑判断功能，但没有逻辑计算功能。在初次通信时须进行三重认证，之后的交互数据以加密形式进行，从而防止截取报文数据以促进安全性。

典型的MIFARE Classic卡的存储结构如图2所示。

图2 MIFARE Classic卡存储结构图

2.3 MIFARE Pro卡

MIFARE Pro卡是指卡片内含微处理器、存储单元和芯片操作系统的具有逻辑处理能力的集成电路卡，一般称为CPU卡。CPU卡是将密钥安全存储在卡片内，在实际使用中自身进行逻辑计算来确定合法性，极大提高了卡片的安全。

CPU卡具备有以下特点：

1) 具有4字节的唯一物理编号；

2) 具有硬件DES/3DES协处理器；

3) 具有硬件真随机数发生器；

4) 以文件、目录形式定义存储结构，以目录进行安全隔离；

5) 空间容量大。一般常用的有8 KB空间，目前已达到128 KB。

由于CPU卡内具有操作系统，典型的CPU卡存储结构如图3所示。

图3 CPU卡存储结构图

3 与票卡的交互流程

无论MIFARE Ultralight卡、MIFARE Classic卡或MIFARE Pro卡，在轨道交通领域都是作为非接触式IC卡来使用，通过射频完成数据交互。不同的IC卡交互流程有所不同，操作命令不同，但均遵循ISO-14443国际标准。

典型的交互流程分为以下三种。

3.1 寻卡流程

非接触式IC卡经过寻卡(request)、防冲突(anti-collision)和选择(select)交互命令进入数据交互过程，确保了交互过程的唯一性[6]。非接触式IC卡寻卡流程如图4所示。

图4 非接触式IC卡寻卡流程图

由于MIFARE Ultralight卡具有7字节的唯一长度，须进行二次防冲突和二次选择后进入数据交互过程。而MIFARE Classic卡和MIFARE Pro卡具有4字节的唯一长度，只须一次防冲突和选择卡后进入后续的操作过程。

3.2 MIFARE Classic操作

MIFARE Classic卡不支持ISO-14443-4的协议，在选择(select)卡片后进行三重认证完成加密握手，然后根据相应的命令完成操作：

1) 对于数据区可使用读块、写块命令；

2) 对于值区可使用加值、减值、恢复等命令，确认后进行传递完成；

3) 对MIFARE Classic卡的操作以块为基础单位进行。

MIFARE Classic卡操作命令流程如图5所示。

3.3 MIFARE Pro卡操作

MIFARE Pro卡支持ISO14443-4的协议。由于MIFARE Pro卡容量大、数据交互量大。须发送RATS以交换双方的特性信息，包括是否支持PPS以更快速的进行数据交互；设置、获取FWT值以确定后续数据接收、传输缓存大小等特性。

RATS命令后所有CPU卡的操作称为APDU(Application Protocol Data Unit)命令。APDU命令在空中可读取，所以称为交换透明数据。正如之前所述，CPU卡的安全性依赖于CPU卡的逻辑计算处理能力，而不需要对空中数据进行加密传输。

MIFARE Pro卡操作命令流程如图6所示。

图6 MIFARE Pro卡操作命令流程图

4 车票的使用

在实际轨道交通自动售检票系统应用中，上述几种类型的车票都有可能使用，且会有不同的供应商供货。不同的车票物理介质其交互使用的命令接口不同，同是CPU卡物理介质的车票，其文件、目录也会随发行方的设计有所不同。因此，根据实际应用区分不同介质的车票，尤其是区分不同的发行主体的CPU介质车票是轨道交通应用的首要解决的问题。

4.1 对票卡物理介质的识别

Request命令的应答值定义如图7所示。

图7 寻卡(Request)命令应答值定义

其中的b7、b8两位表示卡号的长度，含义分别为：00b表示4字节的长度；01b表示7字节的长度；10b表示10字节的卡号，11b预留[6]。因此，根据Request的应答数据首先可以区分出MIFARE Ultralight卡，然后根据Ultralight卡命令执行后续操作。

Select命令的应答值定义如图8所示。

图8 选择卡(Select)命令应答值定义

其中的b6和b3位组合起来：10b表示唯一卡号完整，且符合ISO14443-4；00b表示唯一卡号完整，但不符合ISO14443-4。同时，若b3位值为1时，则说明卡片物理卡号不完全，还需要再次防冲突和选择卡[6]。

MIFARE Classic卡不支持ISO14443-4协议，因此可根据Select的应答区分出MIFARE Classic卡，然后根据MIFARE Classic卡命令执行后续操作。

所有不符合上述的流程判断的卡，可认为是MIFARE Pro卡。

完整的区分识别MIFARE Ultralight、MIFARE Classic卡和MIFARE Pro卡的流程如图9所示。

图9 区分MIFARE Ultralight、MIFARE Classic和MIFARE Pro流程图

4.2 对MIFARE Pro卡的识别

在轨道交通自动售检票系统中应用的CPU卡，除了地铁自身发行的IC卡外，还有符合住建部IC卡服务中心标准的一卡通、符合交通部标准的一卡通、符合银联标准的银行卡，以及其他系统发行的但不允许在地铁使用的CPU卡。因此在识别出CPU卡后，还需要进一步区分CPU卡的发行主体。

CPU卡的存储结构为文件、目录，因此可利用目录名、文件名以及文件内容来进行区分。比如，交通部和银联均要求其应用须在PPSE的支付环境下，可通过选择PPSE的返回值来确定是否为交通部卡；住建部IC卡服务中心标准的AID值为唯一值，可通过其确认是否为符合住建部标准的一卡通；其他发卡方可以在设计时，通过约定其中某一个文件的值来定义区分。

综上所述，CPU卡的区分发行主体须根据具体的应用环境进行设计、识别。以某城市地铁的应用为例，该城市地铁CPU卡的应用流程如图10所示。

图10 某城市地铁CPU卡应用流程

4.3 票卡应用优化法测试

使用华虹计通公司生产的DTD-3018型读写器进行寻卡时间测试。测试时间为通过命令可确定车票物理介质为止。

尝试法寻卡按照优先MIFARE Pro卡，其次MIFARE Classic卡，最后MIFARE Ultralight卡的来测试其寻卡的时间，如表1所示。

表1 尝试法寻卡时间表 ms

针对同样的卡使用优化方法进行寻卡时间测试，如表2所示。

表2 优化后寻卡时间表 ms

从测试结果可以看出，尝试法寻卡时间与确定车票物理介质的先后顺序相关联，首先确认的车票其寻卡时间更快，而优化后的寻卡时间与车票的介质不相关，提高了车票寻卡确定速度。

5 系统架构

通过上述对卡的快速识别的整理，提出读写器软件开发过程层级开发架构概念，使读写器的业务集中在应用层，而与射频的交互由底层驱动完成。

典型的软件系统结构设计如图11所示。

图11 读写器内软件系统结构示意图

在识别车票种类后，采取业务与硬件分离统一对射频的调用接口，并按照ISO-14443的卡片交互流程定义了相应的函数接口，使应用层开发直接面向应用开发。例如：

寻卡、防冲突、选择卡相应的函数定义：

UBYTE mcml_request(UBYTE request_type,UBYTE*atq);

UBYTE mcml_anticoll(UBYTE*psnr);

UBYTE mcml_select(UBYTE*psnr, UBYTE*status);

读、写MIFARE Ultralight的信息函数：

UBYTE UL_Page_Read(UBYTE addr, UBYTE*pReaddata);

UBYTE UL_Page_Write(UBYTE addr, UBYTE*pWritedata);

ISO-14443-4的交换透明数据接口函数：

UBYTE mifpro_icmd(UBYTE*inbuf,UBYTE inbytes,UBYTE*outbuf,UWORD*outbytes);

6 结 语

随着新建城市轨道交通的扩展，快速响应城市轨道交通自动售检票系统的应用面临更紧迫的需求。与此同时，既有已开通轨道交通的城市也面临接入更多票卡的需求。本文通过对轨道交通大量使用的各种介质车票的分析，参照ISO-14443规范的角度提出了识别车票的一种方法，进而优化了交易时间的处理。

针对轨道交通自动售检票系统使用的储值类车票进行进一步分析，提出了一种根据专用AID标识识别的方式，更进一步建议车票设计时的相互协调的方法，使得在满足业务的情况下，加快车票的交易处理时间。

最后，针对新一代的开发环境，将原来紧密耦合射频驱动、业务处理的软件开发变更为层级式开发，并提出了基于嵌入式系统读写器层级软件开发结构，使参与读写器的不同开发人员关注其重点方面，最终使对车票的处理转向对业务的分析、处理，更加灵活地适应变化的轨道交通业务需求，加快了开发速度，增强了产品的稳定性。

在宁波轨道自动售检票系统中增加符合交通部标准的一卡通、符合银联标准的银行卡功能应用时，使用票卡快速识别方法保证了不影响既有的MIFARE Ultralight卡、MIFARE Classic卡的交易速度，又可快速识别各发行主体的CPU卡。同时，利用层级式开发方法在宁波轨道应用公共交通换乘优惠时，使开发人员重点关注优惠规则的业务实现，快速响应了客户的需求。