CN110648147A - 用于轨道交通闸机二维码交易的信息交互方法及存储介质 - Google Patents

Abstract

本发明涉及一种用于轨道交通闸机二维码交易的信息交互方法及存储介质，该方法采用闸机SDK来接收闸机系统的上位机进程发送的二维码信息，并对二维码信息进行本机合法性验证，再将二维码信息生成符合二维码乘车业务后台标准的交易数据，上传给二维码乘车业务后台，供其进行二维码交易验证；接收二维码乘车业务后台返回的二维码交易验证结果，并根据该结果生成符合地铁标准的交易数据返回给上位机进程，供上位机进程根据交易处理结果控制是否打开闸机。本发明提供了一种标准化、规范化的方式进行地铁乘车业务的处理，以实现闸机上位机进程与二维码乘车业务后台之间的数据交互与处理，上位机进程只需做较小改动。

Description

用于轨道交通闸机二维码交易的信息交互方法及存储介质

技术领域

本发明属于轨道交通技术领域，具体涉及一种用于轨道交通闸机二维码交易的信息交互方法及存储介质。

背景技术

随着互联网技术的不断发展，特别是移动互联网技术的不断创新，人们越来越希望快捷、实惠、方便的交通出行以及购票方式，如：手机二维码乘地铁、在线购票等。采用基于移动支付的手机二维码乘地铁方案后，可直接使用手机终端生成二维码作为车票媒介的方式通行，使得支付手段多样化，大大减少现金及实体车票的使用。

国内许多大城市都已经实现了手机二维码乘地铁，但二维码乘地铁业务和现有地铁系统的传统实体车票业务差别很大，存在行程匹配、本机防复制控制、线网防复制控制、新的密钥管理体系、新的发卡机构和发码机构管理体系等诸多不同之处，二维码乘地铁的业务处理复杂度高于传统地铁实体票卡业务。

目前国内各大城市的地铁线路一般都由多家集成商来开发，主要采用由各线路集成商在闸机系统的上位机进程里实现所有的二维码业务，并由上位机直接对接二维码乘车业务后台。由于二维码乘车业务的复杂性和多变性，需要对不同厂商的上位机进程进行改造，以实现与二维码乘车业务后台的对接。但这种改造成本很高，工期很长，导致地铁各线路集成商接入二维码乘车业务后台的难度很大。这种处理方式在模块的独立性、业务的完整性、后续二维码乘车业务的升级便利性等方面都存在明显的缺陷。

发明内容

本发明提供了一种用于轨道交通闸机二维码交易的信息交互方法及存储介质，用以解决现有技术需要对上位机进程进行改造造成的接入二维码乘车业务后台难度大的问题。

为解决上述技术问题，本发明的技术方案和有益效果为：

本发明的一种用于轨道交通闸机二维码交易的信息交互方法，包括以下步骤：

1)接收闸机系统的上位机进程发送的二维码信息，对二维码信息进行本机合法性验证，在合法性验证通过且与二维码乘车业务后台连接正常时，将二维码信息生成符合二维码乘车业务后台标准的交易数据，并上传给二维码乘车业务后台，供二维码乘车业务后台进行二维码交易验证；

2)接收二维码乘车业务后台返回的二维码交易验证结果，并根据二维码交易验证结果生成符合地铁标准的交易数据，保存至本地，根据所述符合地铁标准的交易数据生成符合地铁标准的交易处理结果，并返回给上位机进程，供上位机进程根据交易处理结果控制是否打开闸机。

其有益效果：本发明的用于轨道交通闸机二维码交易的信息交互方法，提供了一种统一的标准化、规范化的方式来进行地铁乘车业务的处理，以实现闸机系统的上位机进程与二维码乘车业务后台之间的数据交互与处理，对上位机进程改造较小，使得后续二维码乘车业务的升级更加便利、方便。

进一步的，步骤1)中，在合法性验证通过且与二维码乘车业务后台连接断开时，则根据二维码信息生成符合二维码乘车业务后台标准的交易数据，保存至本地，根据符合地铁标准的交易数据生成符合地铁标准的交易处理结果，并返回给上位机进程，供上位机进程控制打开闸机。在与二维码乘车业务后台连接断开时，为了不影响用户乘坐地铁，直接控制打开闸机，保证用户便利乘坐。

进一步的，步骤1)之前，还包括：接收上位机进程发送的闸机配置信息，根据闸机配置信息进行初始化，并将初始化结果返回给上位机进程。

进一步的，还包括以下步骤：3)定时向二维码乘车业务后台发送设备信息，使二维码乘车业务后台在收到设备信息后返回后台的中心公钥版本号；4)比较本地的中心公钥版本号与接收的二维码乘车业务后台返回的中心公钥版本号是否一致，若不一致，则向二维码乘车业务后台发送中心公钥下载请求，使二维码乘车业务后台返回最新的中心公钥和中心公钥版本号；5)根据接收到的最新的中心公钥和中心公钥版本号，更新本地的中心公钥和中心公钥版本号。

进一步的，若与二维码乘车业务后台连接恢复，将本次交易数据定时重新发送给二维码乘车业务后台，供二维码乘车业务后台处理，并接收二维码乘车业务后台的处理结果，根据该处理结果更新该交易数据的上传状态。

进一步的，还包括以下步骤：6)在当日运营结束后，将上一日的交易数据的交易流水清单打包上传给二维码乘车业务后台，供二维码乘车业务后台检查是否存在缺少的交易流水号，并返回缺少的交易流水清单；7)根据接收到的缺少的交易流水清单，对缺少的交易流水清单对应的交易数据重新上传给二维码乘车业务后，供二维码乘车业务后进行审计处理。

进一步的，步骤6)中，将上一日的交易数据的交易流水清单打包上传给二维码乘车业务后台前，还包括：将本地所有未上传或上传失败的交易数据重新上传给二维码乘车业务后台。

本发明还提供了一种计算机存储介质，该计算机存储介质用于实现上述用于轨道交通闸机二维码交易的信息交互方法，以达到与该方法相同的效果。

附图说明

图1是本发明的方法实施例中用于轨道交通闸机二维码交易的信息交互方法流程图；

图2是本发明的方法实施例中闸机SDK初始化流程图；

图3是本发明的方法实施例中二维码验证流程图。

图4是本发明的方法实施例中二维码交易审计流程图。

具体实施方式

方法实施例：

该实施例提供了一种用于轨道交通闸机二维码交易的信息交互方法，如图1所示，该方法应用于地铁的闸机系统中，即为闸机SDK，负责闸机系统的上位机进程与二维码乘车业务后台的通讯以及二维码乘车业务的逻辑判断，实现统一的二维码乘车业务处理。也即，将二维码乘车业务被独立出来打包成SDK，提供简洁的二维码乘车业务接口，使轨道交通各线路能使用统一的处理方法，高效、低成本地改造现有轨道交通各线路的闸机终端，快速地实现二维码乘车业务。

闸机SDK以动态链接库的形式提供，以二进制执行程序文件的形式提供，该程序文件以进程的方式独立运行于闸机系统。闸机SDK包括闸机API接口、业务处理模块和后台通信模块。闸机API接口由闸机上位机进程调用，是上位机进程与闸机SDK进行数据交互的接口；后台通信模块负责闸机SDK和二维码乘车业务后台之间的底层数据通信，数据传输采用基于TCP/IP协议的SOCKET通讯；业务处理模块负责闸机SDK和二维码乘车业务后台之间的业务功能处理，即该实施例的用于轨道交通闸机二维码交易的信息交互方法。

下面结合图1，对该方法的整个二维码交流程做一详细说明。该图中，对每种交易的报文接口(其对应代码的接口程序)按照处理先后顺序进行了数字编号。编号1-1至1-2是SDK初始化的报文接口；编号2-1至2-8是二维码验证交易的报文接口；编号3-1至3-2是传递闸机状态的报文接口；编号4-1至4-4是中心公钥下载的报文接口；编号5-1至5-2是进出站交易重传的报文接口；编号6-1至6-4是交易审计的报文接口。“上位机进程”和“闸机SDK”之间的报文接口(如编号为1-1、1-2、2-2、2-5等接口)，既可以采用API函数来实现，也可以采用TCP数据包来实现。“闸机SDK”和“二维码乘车业务后台”之间的报文接口(如编号为2-3、2-4、4-1、4-2等接口)，一般采用TCP数据包来实现。

步骤一，进行闸机SDK初始化，编号1-1至1-2是闸机SDK初始化的报文接口，其过程如图2所示，具体过程如下：

1、闸机SDK初始化本地数据库，若本地数据库不存在，则需要创建本地数据库，并生成相关的数据库表结构。本地嵌入式数据库(例如SQLITE)包括系统配置表、中心公钥表、发卡机构编码表、发码机构编码表和交易信息表。其中，系统配置表包括：数据标识、数据取值等字段信息；中心公钥表包括二维码类别、机构公钥索引、机构公钥有效期、机构公钥数据等字段信息；发卡机构编码表包括发卡机构编码、发卡机构名、发卡机构有效期等字段信息；发码机构编码表包括发码机构编码、发码机构名、发码机构有效期等字段信息；交易信息表包括上传次数、入库时间戳、是否上传标志、入库日期、交易数据A、花设备流水号、交易类型、终端订单号等字段信息；交易信息表的进出站交易数据最多保存7天。

2、通过“1-1SDK初始化”接口，从上位机进程获取闸机配置信息，闸机配置信息包括：线路编号、车站代码、设备类型、设备编号、日志输出目录、本地交易数据库存放目录、二维码乘车业务后台的IP地址和二维码乘车业务后台的的端口号等信息。

3、判断此时闸机SDK与二维码乘车业务后台之间的连接是否正常，连接正常为在线，连接断开为离线。若为在线，闸机SDK从二维码乘车业务后台获取后台配置信息，后台配置信息包括中心公钥版本号、发卡机构版本号、发码机构版本号、中心公钥、发卡机构编码和发码机构编码，并把中心公钥版本号、发卡机构版本号、发码机构版本号保存到本地嵌入数据库的系统配置表，把中心公钥保存到本地嵌入数据库的中心公钥表，把发卡机构编码保存到本地嵌入数据库的发卡机构编码表，把发码机构编码保存到本地嵌入数据库的发码机构编码表。若为离线，直接从本地获取后台配置信息。

4、把处理结果通过“1-2返回初始化结果”返回给上位机进程。上位机进程只有接收到初始化处理成功的应答后，才能调用二维码验证接口。

步骤二，进行二维码验证，编号2-1至2-8是二维码验证交易的报文接口，其过程如图3所示。具体的：

1、扫码模块通过扫描用户手机展示的二维码图片来采集二维码原始数据，再通过串口把二维码原始数据发送给读卡器。

2、读卡器器通过“2-1二维码原始数据”把采集到的的二维码原始数据传递给上位机进程。

3、上位机进程通过“2-2二维码验证”接口，把待验证的二维码信息传递给闸机SDK，包括：二维码源串、二维码源串长度、扫码时间戳、交易类型、设备交易序号、运营模式、闸机IP地址、二维码数据结构、二维码签名、发卡机构号、发码平台编号和二维码有效期等信息。

4、闸机SDK收到二维码信息后，进行本机二维码合法性验证和本机防复制验证。其中，验证本机二维码合法性包括：验证二维码数据结构是否符合标准、二维码的签名、发卡机构号、发码平台编号和二维码有效期等。本机防复制验证包括：检查二维码是否重复刷码，相同码在本机当天只能使用一次；相同用户标识在本机3分钟内进站(或出站)只能使用一次，检查用户是否重复刷码：若重复刷码，则返回禁止开门。

若本机验证通过，判断是在线还是离线：

1)若为在线，闸机SDK生成标准化统一的符合二维码乘车业务后台标准的交易数据A，其内容包括：模块代码、终端时间、记录生成时间、交易类型、线路编号、车站代码、设备编号、设备类型、设备流水号、设备离线状态、二维码源串、终端订单号、二维码扫码时间、用户ID、用户卡号/卡ID、用户账户类型、支付账户号、二维码类别、二维码凭证号、发卡机构代码和发码机构代码等信息，通过“2-3交易上传请求”接口的TCP协议，把交易数据A上传至二维码乘车业务后台；同时，闸机SDK把交易数据A保存到本地嵌入式数据库的交易信息表，并执行步骤5；

2)若为离线，闸机SDK根据二维码信息生成符合二维码乘车业务后台标准的交易数据，并保存到本地存储介质(待在线时再上传该交易数据给二维码乘车业务后台)，再根据二维码交易数据生成符合地铁标准的交易处理结果，并返回给上位机进程，并通知闸机开门，以保证用户的安全通行。

若本机验证不通过，则直接向上位机进程返回禁止开门的结果。

5、二维码乘车业务后台收到交易数据A后，进行二维码交易验证，包括全线网的行程控制、防复制验证、二维码交易入库等验证处理，再通过“2-4交易验证结果”接口，把二维码交易验证结果返回给闸机SDK。

6、闸机SDK收到二维码乘车业务后台的二维码交易验证结果后，如果二维码验证通过，则把该次交易数据保存到本地嵌入式数据库的交易信息表。同时，闸机SDK生成标准化统一的符合地铁AFC标准的交易数据B，其内容包括：命令号、交易验证码、交易类型、交易地点、终端代号、操作员号、扫码(刷脸)时间、设备交易序号、设备离线状态、终端订单号、记录生成时间、卡类型、卡子类型、用户ID、支付账户号、应用类型标识、二维码凭证号、发卡机构代码、发码机构代码、交易标识、运营模式、码生成时间、IP地址、城市代码、行业代码和CRC校验码等信息，通过“2-5返回验证结果”接口，通过SDK提供的API接口函数(或TCP数据包)，同时在本地进行保存，进而生成符合地铁标准的交易处理结果传递给闸机上位机进程。

7、上位机进程收到闸机SDK返回的验证结果后，若二维码验证通过，则通过“2-6执行二维码数据”接口通知读卡器进行二维码交易处理。

8、读卡器通过“2-7返回处理结果”接口，把交易处理结果返回给上位机进程。

9、上位机进程若收到交易处理成功的结果，则打开闸门放行；再通过“2-8二维码交易数据”接口，把二维码交易数据传递给车站后台。

步骤三，传递闸机状态，编号3-1至3-2是传递闸机状态的报文接口。

1、上位机进程通过“3-1传递闸机状态”接口，把闸机状态、(进)码头状态、(出)码头状态等传递给闸机SDK，以供SDK的其他模块使用。

2、闸机SDK通过“3-2返回应答”接口，把处理结果返回给上位机进程。

步骤四，中心公钥下载，编号4-1至4-4是中心公钥下载的报文接口。

1、闸机SDK通过“4-1设备信息上传(心跳)”接口，定时(如一分钟)向二维码乘车业务后台发送设备信息，包括：本地中心公钥版本号、设备状态更新时间、闸机当天发生的交易总数、闸机当天已上传的交易数量、闸机磁盘剩余容量等设备信息。

2、二维码乘车业务后台收到设备信息后，再通过“4-2中心公钥版本信息”把后台的中心公钥版本号等信息返回给闸机SDK。

3、闸机SDK检查本地的中心公钥版本号和二维码乘车业务后台返回的中心公钥版本号是否一致：如果不一致，则通过“4-3中心公钥下载请求”接口则向二维码乘车业务后台发送中心公钥下载请求。

4、二维码乘车业务后台收到闸机SDK的中心公钥下载请求后，通过“4-4中心公钥内容”接口，把最新的中心公钥版本号和中心公钥传递给闸机SDK。

5、闸机SDK收到最新的中心公钥和中心公钥版本号后，更新本地的中心公钥和中心公钥版本号。

另外，关于发卡机构编码下载和发码机构编码下载的过程与上述介绍的中心公钥下载的过程类似。在闸机SDK检查本地的发卡机构编码版本/发码机构编码版本与二维码乘车业务后台返回的发卡机构编码版本/发码机构编码版本是否一致，不一致时需从二维码乘车业务后台获取最新的发卡机构编码版本/发码机构编码版本，并更新本地的发卡机构编码版本/发码机构编码版本。

步骤五，交易重传，编号5-1至5-2是进出站交易重传的报文接口。

对于处理成功的进出站交易，由于网络故障或其他原因，可能导致交易上传失败，要求SDK程序支持定时重传处理，以保证所有交易数据成功上传到二维码乘车业务后台。

1、闸机SDK通过“5-1交易重传请求”接口，把没有上传成功的二维码交易发送给二维码乘车业务后台。

2、二维码乘车业务后台通过“5-2交易重传应答”接口，把处理结果返回给闸机SDK。

3、闸机SDK收到处理结果后，更新该条交易的上传状态。

步骤六，交易审计，编号6-1至6-4是交易审计的报文接口。本接口是闸机SDK和二维码乘车业务后台的接口。具体流程如图4所示。

闸机在当日运营结束时，先将本地所有未上传或上传失败的交易通过“进出站交易上传接口”进行重传，重传失败三次则不重传；确保都尝试过重传后，进行交易审计。

1、闸机SDK通过“6-1交易流水清单”接口，把上一运营日的交易数据的交易流水清单打包上传给二维码乘车业务后台。

2、二维码乘车业务后台根据收到的交易流水清单检查是否存在缺少的交易流水号，若存在缺少的交易流水号，则通过“6-2缺漏流水清单”接口，把缺少的交易流水号清单返回给闸机SDK。

3、闸机SDK收到缺少的交易流水号清单后，对这部分交易数据进行重传处理；重新上传完成则审计结束。而且，闸机在关机前需留出足够的时间(例如30分钟)，以保证闸机SDK审计处理的正常完成。

计算机存储介质实施例：

该实施例提供了一种计算机存储介质，该计算机存储介质用于实现上述方法实施例中介绍的用于轨道交通闸机二维码交易的信息交互方法，由于对该方法的介绍已足够清楚，这里不再赘述。

尽管本发明的内容已经通过上述优选实施例作了详细介绍，但应当认识到上述的描述不应被认为是对本发明的限制。在本领域技术人员阅读了上述内容后，对于本发明的多种修改和替代都将是显而易见的。因此，本发明的保护范围应由所附的权利要求来限定。

Claims (8)

1.一种用于轨道交通闸机二维码交易的信息交互方法，其特征在于，包括以下步骤：

1)接收闸机系统的上位机进程发送的二维码信息，对二维码信息进行本机合法性验证，在合法性验证通过且与二维码乘车业务后台连接正常时，将二维码信息生成符合二维码乘车业务后台标准的交易数据，并上传给二维码乘车业务后台，供二维码乘车业务后台进行二维码交易验证；

2)接收二维码乘车业务后台返回的二维码交易验证结果，并根据二维码交易验证结果生成符合地铁标准的交易数据，保存至本地，根据所述符合地铁标准的交易数据生成符合地铁标准的交易处理结果，并返回给上位机进程，供上位机进程根据交易处理结果控制是否打开闸机。

2.根据权利要求1所述的用于轨道交通闸机二维码交易的信息交互方法，其特征在于，步骤1)中，在合法性验证通过且与二维码乘车业务后台连接断开时，则根据二维码信息生成符合二维码乘车业务后台标准的交易数据，保存至本地，根据符合地铁标准的交易数据生成符合地铁标准的交易处理结果，并返回给上位机进程，供上位机进程控制打开闸机。

3.根据权利要求1所述的用于轨道交通闸机二维码交易的信息交互方法，其特征在于，步骤1)之前，还包括：接收上位机进程发送的闸机配置信息，根据闸机配置信息进行初始化，并将初始化结果返回给上位机进程。

4.根据权利要求1所述的用于轨道交通闸机二维码交易的信息交互方法，其特征在于，还包括以下步骤：

3)定时向二维码乘车业务后台发送设备信息，使二维码乘车业务后台在收到设备信息后返回后台的中心公钥版本号；

4)比较本地的中心公钥版本号与接收的二维码乘车业务后台返回的中心公钥版本号是否一致，若不一致，则向二维码乘车业务后台发送中心公钥下载请求，使二维码乘车业务后台返回最新的中心公钥和中心公钥版本号；

5)根据接收到的最新的中心公钥和中心公钥版本号，更新本地的中心公钥和中心公钥版本号。

5.根据权利要求2所述的用于轨道交通闸机二维码交易的信息交互方法，其特征在于，包括：若与二维码乘车业务后台连接恢复，将本次交易数据定时重新发送给二维码乘车业务后台，供二维码乘车业务后台处理，并接收二维码乘车业务后台的处理结果，根据该处理结果更新该交易数据的上传状态。

6.根据权利要求1所述的用于轨道交通闸机二维码交易的信息交互方法，其特征在于，还包括以下步骤：

6)在当日运营结束后，将＝上一日的交易数据的交易流水清单打包上传给二维码乘车业务后台，供二维码乘车业务后台检查是否存在缺少的交易流水号，并返回缺少的交易流水清单；

7)根据接收到的缺少的交易流水清单，对缺少的交易流水清单对应的交易数据重新上传给二维码乘车业务后，供二维码乘车业务后进行审计处理。

7.根据权利要求6所述的用于轨道交通闸机二维码交易的信息交互方法，其特征在于，步骤6)中，将上一日的交易数据的交易流水清单打包上传给二维码乘车业务后台前，还包括：将本地所有未上传或上传失败的交易数据重新上传给二维码乘车业务后台。

8.一种计算机存储介质，其特征在于，所述计算机存储介质用于实现如权利要求1～7任一项所述的用于轨道交通闸机二维码交易的信息交互方法。

Images