基于中心接入规范的交通一码通乘*

隋莉颖 于海涛 杜 勇 边嘉乐 庞俊彪

(1.北京市交通信息中心综合交通运行监测与服务北京市重点实验室 北京 100073;2.北京工业大学信息学部北京多媒体与智能软件技术重点实验室 北京 100124)

随着智能手机和二维码应用的普及，移动支付成为了重要的支付手段；城市交通作为市民生活中不可或缺的一部分，更是需要以便民利民为目的进行信息化[1-2]。以北京市为例,轨道交通行业通过“亿通行”APP实现二维码乘车和线上购票线下取票功能，北京市政交通一卡通通过开发“一卡通”APP实现线上充值和二维码乘车功能，公交集团则通过“北京公交”APP实现二维码乘车功能。3种场景、3家不同的互联网票务服务商、3个系统，相互独立、互不兼容,就意味着需要下载三款APP，给市民的出行带来了不便。另外, 对城市交通数据的管理也带来问题。地铁、公交、一卡通公司在清分结算、乘客咨询投诉处理流程、运营服务规则、跨行业争议仲裁等方面没有统一业务规则和管理机制，给轨道、公交二维码支付的运营服务质量带来影响。本文构造了“多主一备”架构的一码通乘平台，将多种出行平台整合起来，实现跨交通行业平台支付，将城市的交通变为一个整体。

1 一码通乘系统框架

基于中心接入规范的交通一码通乘平台由公共管理平台、统一发码平台和数据交换中心组成。一码通乘业务逻辑结构见图1。

图1 一码通乘业务逻辑结构

1) 统一发码平台采用“多主一备”架构，轨道交通、公交集团、一卡通等行业各自建设自己的发码平台，统一发码平台具备灾备发码平台。同时，中心密钥与各行业后台主发码平台的密钥一致。

2) 公共管理平台作为跨行业的业务处理中心，包括用户信息管理系统、跨行业清算对账系统、跨行业异议处理系统、统计分析管理系统和证书管理中心。

3) 数据交换平台，包括各行业间多种业务数据和推送数据交换的枢纽，一码通乘平台接收到数据后根据数据类型进行不同的处理和转发。

交通部证书管理中心授权一码通乘平台标准的发码密钥规范存储在公共管理平台的证书管理中心中，统一发码平台根据标准密钥进行发码，保证各行业二维码能实现通用。各行业APP用户开通“一码通乘”业务，勾选用户授权协议及“一码通乘”使用协议后，公共管理平台用户信息管理系统生成ID与各行业后台分配的虚拟卡号的关联关系，即可实现一码通乘城市交通。用户可使用行业APP二维码通过闸机，当行业APP二维码发码故障时，调用灾备发码平台发出通乘二维码，保障用户顺畅通行。出现跨行业业务时，公共管理平台将从用户信息中心找到用户对应的ID，从该ID对应账户支付费用，从而实现跨行业支付；跨行业清算对账系统每天会生成一份对账交易明细发至指定APP平台，同时提供对账差异申诉功能；跨行业异议处理系统，支撑各行业的客服人员及时处理异议问题[3]；统计分析管理系统，将各行业数据汇总入数据管理中心，对交通数据进行实时监控；还配有证书管理中心提供各行业后台来获取有交通部授权的公钥列表与各行业后台的公钥签名[4]。数据交换平台使用MQ(message queue)通信、OSS(object storage service)通信协议等通信规范，使各平台多种类数据实现异步化、规范化交换传输。

2 物理框架

为了降低硬件的建设成本和保证数据的安全运行，一码通乘平台物理架构采用混合云技术。一码通乘平台物理架构图见图2。

图2 一码通乘平台物理架构图

1) 云端部分部署在商用云平台上以降低硬件建设成本。建设内网区、NAT区和管理区。

2) 行业后台部分与商用云之间用高速通道连接。

3) 云端部分与轨道后台机房和公交后台机房分别以专线连接。

4) 一卡通后台系统部署在一卡通专用机房，与一码通乘平台专线连接。

3 中心统一发码模式

中心发码平台业务逻辑图见图3。为了确保一码通乘系统稳定可靠和高可用性，采用“多主一备”的架构模式。由各行业(轨道、公交等交通机构)分别建立一套独立的行业主发码平台，承担各自行业APP的生码业务。统一发码平台建立灾备发码平台，中心密钥与各行业后台主发码平台的密钥一致，且通过公共管理平台的证书管理中心获取符合交通部标准的签发密钥。中心建立一套备用的生码平台，任何一个行业发码平台故障实时切换至灾备发码平台，确保APP能继续正常生码。

图3 中心发码平台业务逻辑图

中心发码平台交互时序图见图4。当需要发码时，行业APP检查发码机构授权签名是否存在。存在时，生成二维码；不存在时，则向行业后台获取发码机构的签名接口，后台对用户的信息在加密模块中获取发码机构的授权签名接口，如果能返回发码机构授权签名信息，则在后台组装二维码信息返回发码机后授权的签名等信息，生成二维码。

图4 中心发码平台交互时序图

4 中心公共管理平台

公共管理平台作为跨行业的业务处理中心，包括用户信息管理系统、跨行业清算对账系统、跨行业异议处理系统、跨行业分析管理系统和证书管理中心。负责为跨行业的用户身份识别提供统一的信息映射管理，对跨行业的业务处理提供辅助管理工具，为管理部门提供跨行业管理需要的各类运行统计数据和监控数据。

4.1 用户信息管理系统

中心平台用户管理中心用来管理一码通用户实名信息。同时中心平台用户管理中心维护联盟ID与各行业后台分配的虚拟卡号的关联关系，可供各行业后台查询。

用户实名信息上传交互时序图见图5。用户在行业APP中开通“一码通乘”业务，勾选用户授权协议及“一码通乘”使用协议，验证支付密码后，向行业后台发起开通二维码乘车业务申请。行业后台向第三方支付机构验证用户实名一致性，并开通免密支付。同时第三方支付机构将开通结果及用户实名信息告知行业后台，行业后台存储实名信息及签约信息，并将实名信息(传入交通卡号、联盟ID、脱敏后姓名、证件号码、手机号等信息)发送至一码通乘平台进行保存。

图5 用户实名信息上传交互时序图

4.2 跨行业清算对帐系统

跨行业交易由各行业后台每个运营日(运营日是指当天02:00至第二天02:00)结束以后(凌晨02:30)自动生成，生成跨行业对账汇总文件(分为请款与退款)以及跨行业对账交易明细文件。跨行业清算对账平台只负责将行业后台生成的对账文件通过MQ转发至指定的APP提供方后台即可。

同时一码通乘平台提供跨行业对账差异申诉管理系统。跨行业清算对账差异申诉管理系统提供以下功能：清算对账差异申诉处理工单的创建、查询、处理反馈等功能。支撑各行业清算对账人员及时有效处理跨行业对账差异议问题。各行业清算异议处理专员可点击查看清算工单详情按钮，通过各行业后台清算系统发起清算工单详情请求，在中心平台跨行业清算异议处理系统根据工单的编号查询具体信息，随后将清算异议工单详情返回行业后台，显示给各行业清算异议处理专员。其流程示意图见图6。

图6 清算对账差异工单交互时序图

4.3 跨行业异议处理系统

公共管理平台提供跨行业异议处理管理系统。跨行业异议处理管理系统提供以下功能：异议处理工单的创建、查询、催办、撤销、处理反馈等功能。支撑各行业客服人员及时有效处理跨行业异议问题[5]。

当乘客出现异议时，异议受理方客服记录工单信息，根据乘客的描述创建工单发送到异议受理方后台客服系统，后台客服系统调用接口将工单发送到中心平台的跨行业异议处理系统，中心平台记录下工单等待提供服务的行业方查询处理，处理后将反馈结果发送到受理方后台客服系统并记录下，异议受理方的客服在收到结果反馈后告知乘客工单已受理[6]。跨行业异议处理工单交互时序图见图7。

图7 跨行业异议处理工单交互时序图

4.4 统计分析管理系统

统计分析管理系统能够提供轨道交通、公交集团、郊区公交等多方数据整合，可实现从流量监控、热度预警、应急调度、可视化作战大屏、智慧交通大数据分析等服务。

服务提供方行业后台上传每天的统计报表到中心平台，中心平台的统计分析管理系统进行储存后反馈结果。

图8为由轨道交通、城市公交和远郊公交人流量数据汇总的交通热力图，颜色越深则说明乘坐公共交通人流量越大。通过一码通乘平台实现交通数据的实时监控，缩短了跨行业数据传输的时间，为缓解交通压力，提高城市交通效率，给城市交通资源的配置提供了宝贵的数据资料[7]。

图8 交通热力图

4.5 证书管理中心

证书管理中心提供各行业后台来获取公钥列表与各行业后台的公钥签名。公钥列表为交通部根证书的公钥，也包含交通行业备用根证书的公钥。公钥签名按照交通部标准，行业后台需要提供自己的公钥数据，用于签名以后将签名后的签名反馈给个行业后台。各行业后台将此签名用于各行业用户证书的签发。

5 试运行结果

表1为北京市2020年一码通乘平台试运行结果。将北京轨道交通APP亿通行、北京公交APP及一卡通APP互联互通，实现了跨行交易、公交数据实时监控等功能。

表1 北京市一码通乘试运行结果

由表1可看出跨行业刷码的每周使用量占比在稳定增加，一码通乘的服务得到越来越多用户的认可，至2020年10月跨行业交易已经达到整个交通出行服务量的19%，截止至2020年10月18日开通一码通乘用户已经达到652.05万人。

6 结语

如今，公共资源越来越来追求信息化、规范化，不断加强行业管理的一体化，力求给使用者带来方便快捷的体验。

基于中心接入规范的交通一码通乘平台，有效地将城市轨道交通、城市公交、城郊公交的数据规范化互通。北京市交通一码通乘的实现，不仅满足了市民幸福出行的需求，构建了公共出行“轻生活”方式，并且可以将所有出行数据归集于1个平台上，保证数据的完整性和唯一性，对各部门决策数据在应用层面的互联互通与共享具有重要意义。