时间:2024-05-04
裴 练 军
(上海华虹计通智能系统股份有限公司 上海 201206)
随着我国城市化进程的进一步加快和城市规模的逐步扩大,城市轨道交通已成为大中型城市最重要的基础交通设施之一[1]。
城市轨道交通自动售检票系统是现代化的收费系统,一般采用五层架构:第一层为城市轨道交通票务清分系统,第二层为线路中央计算机系统,第三层为车站计算机系统,第四层为车站终端设备,第五层为车票。乘客可通过售票、检票设备实现关于车票票务的自助服务,最终在票务清分系统实现各运营商的收益分配[2]。
作为城市轨道交通自动售检票系统的第五层——车票层,轨道交通售检票系统支持的票卡类型有很多。储值类票一般分单程票、储值票和二维码支付等。储值票遵循的标准一般可分为地铁自发一票通卡、住建部一卡通卡、交通部一卡通卡和银行卡支付等。除二维码外,其他车票类型均为非接触式IC卡[3],非接触式IC卡是城市轨道交通自动售检票系统中的常规基础票卡类型。不同类型的票卡同时在检票机上使用,这样的应用场景决定了终端设备须快速识别车票类型,并予以处理。
近年来,全国各地城市轨道自动售检票接入“互联网+”得到了大力发展,快速培养新一代的熟悉非接触式IC卡的开发人员任务越来越紧迫;与此同时,基于非接触式IC卡的公共交通行业优惠应用也督促开发商和开发人员需要响应快速。
城市轨道交通是一种大运量交通运输系统,自动售检票系统须适应客流密集的进、出站需求。目前,轨道交通领域使用的非接触式IC卡种类较多,为了识别和区分,现常用的方法包括有:常量值法和命令重试法。
常量值法是指根据特定命令返回的常量值,标记不同车票介质的类别。采用常量值法可在车票种类较少时可快速区分不同的车票种类,但在自动售检票系统支持较多票卡供应商、较多发行方的车票时往往导致识别重试增多。
命令重试法是指尝试发送不同票卡的交易指令,以是否获得成功应答的方式来识别票卡。这种方式将导致交易时间过长,从而延长了整个的交易流程时间。
随着技术发展,轨道交通售检票终端设备已从单片机向嵌入式操作系统扩展。在传统的开发环境下,票卡处理业务应用与射频驱动应用是紧密耦合在一起,开发人员既需要了解硬件设计、掌握射频驱动,又需要关注业务需求,并将两者紧密结合在一起完成应用软件开发。这种开发方式既对开发人员提出了很高的要求,也不能快速响应业务变化的外部需求。
因此,通过分析票卡的物理特性,参考ISO-14443国际标准来识别票卡,归纳出层级软件开发架构不失为一种解决方法。
在轨道交通领域使用的非接触式IC卡物理介质主要包括有基于MIFARE Ultralight的单程票、基于MIFARE Classic的储值票和基于MIFARE Pro卡的储值票。目前,基于MIFARE Pro卡的储值票成为应用主流。
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卡存储结构图
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卡存储结构图
MIFARE Pro卡是指卡片内含微处理器、存储单元和芯片操作系统的具有逻辑处理能力的集成电路卡,一般称为CPU卡。CPU卡是将密钥安全存储在卡片内,在实际使用中自身进行逻辑计算来确定合法性,极大提高了卡片的安全。
CPU卡具备有以下特点:
1) 具有4字节的唯一物理编号;
2) 具有硬件DES/3DES协处理器;
3) 具有硬件真随机数发生器;
4) 以文件、目录形式定义存储结构,以目录进行安全隔离;
5) 空间容量大。一般常用的有8 KB空间,目前已达到128 KB。
由于CPU卡内具有操作系统,典型的CPU卡存储结构如图3所示。
图3 CPU卡存储结构图
无论MIFARE Ultralight卡、MIFARE Classic卡或MIFARE Pro卡,在轨道交通领域都是作为非接触式IC卡来使用,通过射频完成数据交互。不同的IC卡交互流程有所不同,操作命令不同,但均遵循ISO-14443国际标准。
典型的交互流程分为以下三种。
非接触式IC卡经过寻卡(request)、防冲突(anti-collision)和选择(select)交互命令进入数据交互过程,确保了交互过程的唯一性[6]。非接触式IC卡寻卡流程如图4所示。
图4 非接触式IC卡寻卡流程图
由于MIFARE Ultralight卡具有7字节的唯一长度,须进行二次防冲突和二次选择后进入数据交互过程。而MIFARE Classic卡和MIFARE Pro卡具有4字节的唯一长度,只须一次防冲突和选择卡后进入后续的操作过程。
MIFARE Classic卡不支持ISO-14443-4的协议,在选择(select)卡片后进行三重认证完成加密握手,然后根据相应的命令完成操作:
1) 对于数据区可使用读块、写块命令;
2) 对于值区可使用加值、减值、恢复等命令,确认后进行传递完成;
3) 对MIFARE Classic卡的操作以块为基础单位进行。
MIFARE Classic卡操作命令流程如图5所示。
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卡操作命令流程图
在实际轨道交通自动售检票系统应用中,上述几种类型的车票都有可能使用,且会有不同的供应商供货。不同的车票物理介质其交互使用的命令接口不同,同是CPU卡物理介质的车票,其文件、目录也会随发行方的设计有所不同。因此,根据实际应用区分不同介质的车票,尤其是区分不同的发行主体的CPU介质车票是轨道交通应用的首要解决的问题。
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流程图
在轨道交通自动售检票系统中应用的CPU卡,除了地铁自身发行的IC卡外,还有符合住建部IC卡服务中心标准的一卡通、符合交通部标准的一卡通、符合银联标准的银行卡,以及其他系统发行的但不允许在地铁使用的CPU卡。因此在识别出CPU卡后,还需要进一步区分CPU卡的发行主体。
CPU卡的存储结构为文件、目录,因此可利用目录名、文件名以及文件内容来进行区分。比如,交通部和银联均要求其应用须在PPSE的支付环境下,可通过选择PPSE的返回值来确定是否为交通部卡;住建部IC卡服务中心标准的AID值为唯一值,可通过其确认是否为符合住建部标准的一卡通;其他发卡方可以在设计时,通过约定其中某一个文件的值来定义区分。
综上所述,CPU卡的区分发行主体须根据具体的应用环境进行设计、识别。以某城市地铁的应用为例,该城市地铁CPU卡的应用流程如图10所示。
图10 某城市地铁CPU卡应用流程
使用华虹计通公司生产的DTD-3018型读写器进行寻卡时间测试。测试时间为通过命令可确定车票物理介质为止。
尝试法寻卡按照优先MIFARE Pro卡,其次MIFARE Classic卡,最后MIFARE Ultralight卡的来测试其寻卡的时间,如表1所示。
表1 尝试法寻卡时间表 ms
针对同样的卡使用优化方法进行寻卡时间测试,如表2所示。
表2 优化后寻卡时间表 ms
从测试结果可以看出,尝试法寻卡时间与确定车票物理介质的先后顺序相关联,首先确认的车票其寻卡时间更快,而优化后的寻卡时间与车票的介质不相关,提高了车票寻卡确定速度。
通过上述对卡的快速识别的整理,提出读写器软件开发过程层级开发架构概念,使读写器的业务集中在应用层,而与射频的交互由底层驱动完成。
典型的软件系统结构设计如图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);
随着新建城市轨道交通的扩展,快速响应城市轨道交通自动售检票系统的应用面临更紧迫的需求。与此同时,既有已开通轨道交通的城市也面临接入更多票卡的需求。本文通过对轨道交通大量使用的各种介质车票的分析,参照ISO-14443规范的角度提出了识别车票的一种方法,进而优化了交易时间的处理。
针对轨道交通自动售检票系统使用的储值类车票进行进一步分析,提出了一种根据专用AID标识识别的方式,更进一步建议车票设计时的相互协调的方法,使得在满足业务的情况下,加快车票的交易处理时间。
最后,针对新一代的开发环境,将原来紧密耦合射频驱动、业务处理的软件开发变更为层级式开发,并提出了基于嵌入式系统读写器层级软件开发结构,使参与读写器的不同开发人员关注其重点方面,最终使对车票的处理转向对业务的分析、处理,更加灵活地适应变化的轨道交通业务需求,加快了开发速度,增强了产品的稳定性。
在宁波轨道自动售检票系统中增加符合交通部标准的一卡通、符合银联标准的银行卡功能应用时,使用票卡快速识别方法保证了不影响既有的MIFARE Ultralight卡、MIFARE Classic卡的交易速度,又可快速识别各发行主体的CPU卡。同时,利用层级式开发方法在宁波轨道应用公共交通换乘优惠时,使开发人员重点关注优惠规则的业务实现,快速响应了客户的需求。
我们致力于保护作者版权,注重分享,被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自各大过期杂志,内容仅供学习参考,不准确地方联系删除处理!