CN112785293A - 一种交通多平台统一管理的一码通乘系统 - Google Patents

Abstract

本发明涉及一种交通多平台统一管理的一码通乘系统，包括统一发码平台、公共管理平台和数据交换平台；统一发码平台用于管理交通各行业发码平台，设置一套共用的密钥；公共管理平台为跨交通行业的用户身份识别提供统一的信息映射管理；对跨交通行业的业务处理提供辅助管理工具；为交通数据中心提供跨行业管理需要的各类运行统计数据和监控数据；数据交换平台作为交通各行业间业务数据和推送数据交换的枢纽，系统接收到数据后根据数据类型进行不同的处理和转发。本发明通过统一协议规范和中心密钥，实现交通行业内跨行业对账清账，跨平台数据传输，便捷了市民和游客的出行，提升了各平台用户的体验感，同时对交通数据进行规范，实现交通信息实时更新。

Description

一种交通多平台统一管理的一码通乘系统

技术领域

本发明涉及智慧城市交通技术领域，具体为一种用于交通多平台统一管理的一码通乘系统。

背景技术

随着二维码使用的普及，城市轨道交通、远郊公交、市内公交相继开通了二维码乘车服务。目前交通二维码支付体系虽然已经初步建立，但是三种场景三家不同的互联网票务服务商，市民出行需要下载三款APP，给市民的出行带来了不便。目前三家系统相互独立、互不兼容，主要存在以下几个问题：

一是标准不统一。如北京市轨道交通亿通行APP和北京公交APP的二维码采用的是企业二维码标准，北京市一卡通APP的二维码采用交通运输部二维码标准，不能互联互通。未来，乘客乘坐轨道交通、市内公交和郊区公交，需要在手机上下载多个APP，对乘客出行带来不便。

二是管理不统一。地铁、市内公交、远郊公交公司在清分结算、乘客咨询投诉处理流程、运营服务规则、跨行业争议仲裁等方面没有统一业务规则和管理机制，对轨道、公交二维码支付的运营服务质量带来影响。

当前各城市的交通行业没有一个统一的发码规范和数据管理。以北京为例，轨道交通行业开发亿通行APP实现刷码进出站，北京公交行业使用北京公交APP乘坐公交，一卡通集团则开发自己的一卡通APP线上充值与手机刷码，三家APP数据信息不互联互通、管理模式不统一。这给用户换乘交通工具带来了许多麻烦，想要在城市畅通出行需要下载三家APP并绑定信息。

发明内容

针对当前的问题，本发明提供了一种交通多平台统一管理的一码通乘系统，解决了多个交通行业发放二维码准则不一、管理制度不同，导致交通数据统计复杂，市民游客出行麻烦，统一管理加强了交通数据的安全。

为实现以上目的，本发明的技术方案为：一种交通多平台统一管理的一码通乘系统，包括统一发码平台、公共管理平台和数据交换平台；

所述的统一发码平台用于管理交通各行业发码平台，设置一套共用的密钥；

所述的公共管理平台为跨交通行业的用户身份识别提供统一的信息映射管理；对跨交通行业的业务处理提供辅助管理工具；为交通数据中心提供跨行业管理需要的各类运行统计数据和监控数；

所述的数据交换平台作为交通各行业间业务数据和推送数据交换的枢纽，系统接收到数据后根据数据类型进行不同的处理和转发。

所述的统一发码平台采用“多主一备”架构；

所述“多主一备”架构是指：轨道交通行业、公交交通行业、远郊公交交通行业分别建立一套独立的行业发码平台，承担各自行业APP的生码业务；统一发码平台建立灾备发码平台，密钥与各行业发码平台的密钥一致，且通过公共管理平台的证书管理中心获取符合交通部标准的签发密钥；任何一个行业发码平台故障实时切换至灾备发码平台进行发码，确保APP能继续正常发码。

进一步的，所述的公共管理平台包括交通用户信息统一管理系统；

所述的用户信息管理系统用来管理用户实名信息，同时用户管理中心维护联盟ID与各行业后台分配的虚拟卡号的关联关系，供各交通行业后台查询；轨道交通行业、公交交通行业、远郊公交交通行业采用统一算法，各自生成唯一联盟ID，一个实名对应唯一一个联盟ID，三家根据规范各自生成不同号段的卡号，用于交易配对及计费；用户信息统一在系统进行存储，为了防止用户信息泄露，采用脱敏存储，信息包括手机号、姓名、证件类型、证件号，用于进行必须的统计分析。

进一步的，所述的公共管理平台还包括跨行业清算对账系统和跨行业异议处理系统；

所述的跨行业清算对账系统负责将行业后台生成的对账文件通过设定的通信方式至指定的APP提供方后台，各行业后台生成对账文件以后，需要以规定的规范形式上传，然后通过设定的通信方式转发各行业后台生成的对账文件至一码通乘平台，一码通乘平台再转发至指定的行业后台，各行业后台需要自行下载解析以后并入库。

进一步的，所述跨行业清算对账系统还包括跨行业对账差异申诉管理系统；所述跨行业清算对账差异申诉管理系统用于清算对账差异申诉处理工单的创建、查询、处理反馈，支撑各行业清算对账人员及时有效处理跨行业对账差异议问题；并能实现对各交通平台公共服务能力的有效评价。

进一步的，所述的公共管理平台还包含全维度的交通统计分析管理系统；

所述的交通统计分析管理系统能够提供轨道交通、城市公交、远郊公交多方数据整合，实现流量监控、热度预警、应急调度、可视化作战大屏、智慧交通大数据分析服务；以及提供多维度的统计分析报表，实时查看业务数据，及时全面掌握交通行业状况。

进一步的，所述的数据交换平台包括原始数据交换模块、单边交易数据交换模块、请款数据交换模块，退款数据交换模块、发票数据交换模块、黑名单数据交换模块、推送通知数据交换模块、数据传输审计模块；

所述的原始数据是乘客进出站后机具产生的跨行业原始交易，用于刷码提醒和行程记录展示，此数据单向传输，无交互逻辑；

所述的单边交易数据是指跨行业的不完整交易数据，用于提醒APP提供方的用户进行补票操作；

所述的请款数据是指跨行业配对完成后需要请款的交易数据，用于向APP提供方的用户请款使用；

所述的退款数据是指跨行业配对请款完成后，用户需要退款的交易数据，用于向APP提供方的用户退款使用；

所述的发票数据是指用户通过APP发出开据行业方发票申请的记录数据，用于场景服务提供方给APP提供方开具发票；

所述的黑名单数据是指行业方检测到一码通行用户触发了风控变动后加入或者移出黑名单的记录，用于同步黑名单数据；

所述的推送通知数据是指行业方、一码通乘平台进行公告、通知信息时的数据，用于APP提供方的消息通知使用。

有益效果：

本发明将多个相互独立的行业连接起来，用户下载绑定一家APP即可一码通乘城市交通，同时实现了跨行业清账、跨行业数据传输等功能。

附图说明

图1为本发明的一种交通多平台统一管理的一码通乘系统原理框图；

图2为本发明的系统架构框图；

图3为本发明的物理架构框图；

图4为统一发码平台的原理框图；

图5为数据交换平台原理框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

本申请实施例描述的系统架构是为了更加清楚地说明本申请实施例的技术方案，并不构成对本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新技术的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

本发明提供一种交通多平台统一管理的一码通乘系统，根据图1所示，包括：统一发码平台、公共管理平台和数据交换平台。

统一发码平台采用“多主一备”架构其原理图如图4所示。由各行业(轨道、公交、一卡通)分别建立一套独立的行业自主发码平台，承担各自行业APP的生码业务。中心发码平台作为各行业后台的灾备发码平台，中心密钥与各行业后台主发码平台的密钥一致，且通过公共管理平台的证书管理中心获取符合交通部标准的签发密钥。中心建立一套备用的生码平台，任何一个行业发码平台故障实时切换至备用生码平台，确保APP能继续正常生码。

平台可使用Java、PHP和SQL语言进行搭建，可采用中间件RocketMQ、Reidt通过消息队列的方式，实现异步通信。MYsql和PolarDB数据库用来存储数据，对多行业数据进行集中的存储和管理。可利用Apache Dubbo分布式RPC服务框架和Spring boot等开源工具对数据交换平台进行构造，确保对多种平台架构和数据能够很好的兼容。

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

其中，所述的用户信息管理系统用来管理一码通乘户实名信息。同时一码通乘平台用户管理中心维护联盟ID与各行业后台分配的虚拟卡号的关联关系，可供各行业后台查询。各行业采用统一算法，各自生成唯一联盟ID，一个实名对应唯一一个联盟ID，三家根据规范各自生成不同号段的卡号，用于交易配对及计费。用户信息统一在一码通乘平台进行存储，为了防止用户信息泄露，采用脱敏存储，信息包括手机号、姓名、证件类型、证件号等，用于进行必须的统计分析。根据本发明的一个实施例，用户在行业APP中开通“一码通乘”业务，勾选用户授权协议以及“一码通乘”使用协议后，验证支付密码后，向行业后台发起开通二维码乘车业务申请。行业后台向第三方支付机构验证用户实名一致性，并开通免密支付。同时第三方支付机构将开通结果及用户实名信息告知行业后台，行业后台存储实名信息及签约信息，并将实名信息(传入交通卡号、联盟ID、脱敏后姓名、证件号码、手机号等信息)发送至一码通乘平台的用户信息管理系统进行保存。获取发卡机构授权签名时需要验证该用户的卡号是否在一码通乘平台存在。服务提供方行业后台发送验证卡号合法性请求到一码通乘平台，平台进行卡号合法性验证处理，并将结果返回给服务提供方行业后台；行业后台根据卡号获取联盟ID，并发送至一码通乘平台，查询是否有制定的卡号对应的联盟ID，并将分配的联盟ID返回给行业后台进行使用。跨行业交易由各行业后台每个运营日(运营日是指当天02:00至第二天02:00)结束以后(凌晨2:30)自动生成，生成跨行业对账汇总文件(分为请款与退款)以及跨行业对账交易明细文件。

所述跨行业清算对账系统只负责将行业后台生成的对账文件通过设定的通信方式(如MQ通信)转发至指定的APP提供方后台即可。各行业后台生成对账文件以后，需要上传到私有的OSS上去，然后通过MQ的方式转发各行业后台生成的对账文件至一码通乘平台，一码通乘平台再转发至指定的行业后台，各行业后台需要自行下载解析以后并入库。根据本发明的一个实施例，对账文件原始文件为csv格式，传输到OSS中以zip压缩格式，获取对账文件后按zip方式解压，并解析csv文件即可。对账文件格式包括对账汇总文件和对账明细文件；包头：包含此次对账的发送方，接收方，对账日期，对账包含对账明细文件，其中字段以“，”，行与行之间以“回车换行符”分割。包体：包含此次对账的汇总数据，其中字段以“，”，行与行之间以“回车换行符”分割。

一码通乘平台包括跨行业对账差异申诉管理系统。跨行业清算对账差异申诉管理系统提供以下功能：清算对账差异申诉处理工单的创建、查询、处理反馈等功能。支撑各行业清算对账人员及时有效处理跨行业对账差异议问题。

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

(1)创建工单：跨行业异议受理方客服人员需要创建跨行业工单时，由受理方客服系统调用该接口。客服人员根据乘客描述记录工单，创建跨行业异议工单，并通过异议受理方客服系统提交工单。一码通乘平台跨行业异议处理系统接收到工单后，将工单转发给处理方客服系统，等待处理方结果反馈。

(2)查询工单列表：各行业客服人员输入查询条件，通过各行业客服系统，向一码通乘平台查询跨行业的客服申诉工单系统来获取工单列表，用于查询客服异议工单详情信息。

(3)查询工单详情：各行业客服发起方与接收方均可根据工单编号查询工单详情。各行业客服人员点击查看客服申诉工单详情按钮，通过各行业客服系统，向一码通乘平台跨行业异议处理系统，发送查询详情请求。一码通乘平台根据工单编号，查询工单信息，并将客服异议工单详情返回给各行业客服系统，并进行展示。

(4)催办工单：受理方接到乘客电话时，可查询工单状态，如未处理完成可进行催办。异议受理方客服点击催办工单按钮，通过异议受理方后台客服系统发起催办工单请求，一码通乘平台跨行业异议处理系统记录催办状态，并转发给场景方进行处理，返回催办结果。

(5)工单状态变更：当客服专员需要受理、撤销、驳回、完成、关闭工单时，专员根据不同处理结果发起工单状态变更操作，通过各行业后台客服系统发起客服异议工单状态变更请求，发送至一码通乘跨行业异议处理系统。一码通乘处理系统根据状态参数，更新异议工单状态，并将状态变更结果返回给各行业后台客服系统，并进行展示。

建设可视化监测及管理系统，统计分析管理系统能够提供轨道交通、公交集团、郊区公交等多方数据整合，可实现从流量监控、热度预警、应急调度、可视化作战大屏、智慧交通大数据分析等服务。通过采集各行业方的数据，丰富交委的数据资产；系统提供多维度的统计分析报表，实时查看业务数据，及时全面掌握交通行业状况；数据资产可广泛应用，实现中心量化决策、行业优化等。主要包括数据服务接口配置、发布间隔配置、数据属性配置、时空特征配置、关联配置、调度配置、授权配置等。

(1)各行业统计数据：各APP的下载、注册数据，各行业交易数据,跨行业清算对账数据、跨行业客服异议数据等。

(2)统计分析报表：用户分析日报、月报，APP分析日报、月报，行业交易量分析日报、月报，支付方式分析日报、月报，出行方式分析日报、月报等。

(3)实时监控大屏：交易数据实时监控、运营动态实时监控等。

(4)平台资源监控：对数据池中的数据进行管理，包括数据种类、数据量、更新时间等进行监测。

(5)服务监测：对系统提供的服务进行监测，及时发现问题，微信或短信通知，定期生成监测报告。根据本发明的一个实施例，各行业平台数据交换通过中心数据交换平台实现其原理如图5所示。数据发送方需要向一码通乘数据交换平台发送数据时可以选择调用中心数据交换平台数据分拣接口服务数据上送API接口或者直接连接商用云数据分拣MQ生产数据给一码通乘数据交换平台，由数据分拣服务将数据分发到不同的MQ通道，数据接收方需要在一码通乘数据交换平台MQ所在商用云可用区部署交换数据的消费者服务，每个商户后台消费两个topic，一个是普通数据topic，一个是实时数据topic，消费者接收到数据后数据类型进行不同的处理。数据交换平台可实现原始数据交换、单边交易数据交换、请款数据交换、退款数据交换、发票数据交换，黑名单数据交换、推送通知数据交换、数据传输审计。

原始数据单向传输，无交互逻辑。跨行业数据需要在行业后台收到该数据以后立即发送给一码通乘数据交换平台，一码通乘数据交换平台按照交易唯一hash值去重，然后再入库；各行业收到原始交易以后需要进行剔重，然后入库。

单边交易数据单向传输，无交互逻辑。根据各方的业务逻辑，场景方需要在判定行业单边的信息的时候将单边交易(带html5链接)发送给一码通乘数据交换平台；一码通乘数据交换平台将该单边信息存储后转发至指定的行业后台的消息队列；各行业后台收到单边交易数据存储以后将单边信息推送给乘客，乘客通过h5链接可以点击查看单边信息，并且可以直接补单边信息；各行业收到单边请款交易时可以认为该单边已经处理完成，可将该行业处的单边置为已完成的状态。

请款数据交换时，场景服务提供方行业后台通过一码通乘数据交换平台，将请款交易请求发送至APP运营方行业后台，保存请款信息并发起扣款。APP运营方行业后台向其所支持的第三方支付渠道进行扣款，并将扣款完成推送通过一码通乘数据交换平台，发送至场景服务提供方行业后台。每天1点50分至2点10分不能发送该交易，行业方收到该交易时需要进行判断当前请款交易的matchType判断当前是否为单边交易，如果为单边交易需要将单边交易的补票状态改为已完成的状态。请款交易中如果计费类型为：一次性扫码计费，只需要在进站/上车的位置上填写相关的信息，出站/下车的位置可以填写空字符串。

退款数据交换时场景服务提供方客服后台将退款文件转发给一码通乘数据交换平台，一码通乘数据交换平台转发给APP提供方后台，APP提供方进行退款操作，退款完成后APP提供方通过一码通乘数据交换平台将退款结果，通知至场景服务提供方客服后台。

发票数据交换时，用户在各自的行业APP上选择要开票的行程列表，将选中的开票交易发送至行业后，行业后台在收到开票交易时需要将该交易转发至一码通乘数据交换平台；开票最长时限：7天(暂定)，若用户填写信息没有问题(所有交易都能找到并且为未开票状态)，并且没达到最长时限，若不是全部成功，等到最长时限返回；一码通乘数据交换平台收到开具发票交易以后对开具发票交易类型进行判断以后进行不同的处理，交易类型包括新开发票、错票重开、发票冲红等。发票开具完成以后需要给一码通乘数据交换平台发送开具发票的结果反馈，服务提供方可同时给用户发送发票开具成功的信息与邮件信息。

推送通知数据交换时，数据接收方接收到数据之后，通过联盟ID找到APP的用户信息，进行推送。推送内容和推送方式，按照推送内容字段来进行推送即可。

为了保障双方数据的完整性、一致性，减少对账的差异性；涉及到交易相关的重要数据，在进行清分之前，需要对前一天的数据进行一次审计，用以确认前一天的交易的完整性。

根据本发明的一个实施例，本发明的一码通乘平台的物理架构如图3所示，为了降低硬件的建设成本和保证数据的安全运行，一码通乘平台物理架构采用混合云技术，如图3所示。

(1)一码通乘平台云端部分部署在商用云平台上，分为内网区、NAT区和管理区；

(2)行业后台系统、以及公交后台系统与商用云平台之间用高速通道连接；

(3)行业后台系统、以及公交后台系统与行业后台机房和公交后台机房分别以专线连接。

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

尽管上面对本发明说明性的具体实施方式进行了描述，以便于本技术领域的技术人员理解本发明，且应该清楚，本发明不限于具体实施方式的范围，对本技术领域的普通技术人员来讲，只要各种变化在所附的权利要求限定和确定的本发明的精神和范围内，这些变化是显而易见的，一切利用本发明构思的发明创造均在保护之列。

Claims (7)

1.一种交通多平台统一管理的一码通乘系统，其特征在于，包括统一发码平台、公共管理平台和数据交换平台；

所述的统一发码平台用于管理交通各行业发码平台，设置一套共用的密钥；

所述的公共管理平台为跨交通行业的用户身份识别提供统一的信息映射管理；对跨交通行业的业务处理提供辅助管理工具；为交通数据中心提供跨行业管理需要的各类运行统计数据和监控数；

所述的数据交换平台作为交通各行业间业务数据和推送数据交换的枢纽，系统接收到数据后根据数据类型进行不同的处理和转发。

2.根据权利要求1所述的一种交通多平台统一管理的一码通乘系统，其特征在于，所述的统一发码平台采用“多主一备”架构；

所述“多主一备”架构是指：轨道交通行业、公交交通行业、远郊公交交通行业分别建立一套独立的行业发码平台，承担各自行业APP的生码业务；统一发码平台建立灾备发码平台，密钥与各行业发码平台的密钥一致，且通过公共管理平台的证书管理中心获取符合交通部标准的签发密钥；任何一个行业发码平台故障实时切换至灾备发码平台进行发码，确保APP能继续正常发码。

3.根据权利要求1所述的一种交通多平台统一管理的一码通乘系统，其特征在于，所述的公共管理平台包括交通用户信息统一管理系统；

所述的用户信息管理系统用来管理用户实名信息，同时用户管理中心维护联盟ID与各行业后台分配的虚拟卡号的关联关系，供各交通行业后台查询；轨道交通行业、公交交通行业、远郊公交交通行业采用统一算法，各自生成唯一联盟ID，一个实名对应唯一一个联盟ID，三家根据规范各自生成不同号段的卡号，用于交易配对及计费；用户信息统一在系统进行存储，为了防止用户信息泄露，采用脱敏存储，信息包括手机号、姓名、证件类型、证件号，用于进行必须的统计分析。

4.根据权利要求3所述的一种交通多平台统一管理的一码通乘系统，其特征在于，所述的公共管理平台还包括跨行业清算对账系统和跨行业异议处理系统；

所述的跨行业清算对账系统负责将行业后台生成的对账文件通过设定的通信方式至指定的APP提供方后台，各行业后台生成对账文件以后，需要以规定的规范形式上传，然后通过设定的通信方式转发各行业后台生成的对账文件至一码通乘平台，一码通乘平台再转发至指定的行业后台，各行业后台需要自行下载解析以后并入库。

所述的跨行业异议处理系统提供以下功能：异议处理工单的创建、查询、催办、撤销、处理反馈功能，能够支撑各行业客服人员及时有效处理跨行业异议问题。

5.根据权利要求4所述的一种交通多平台统一管理的一码通乘系统，其特征在于，所述跨行业清算对账系统还包括跨行业对账差异申诉管理系统；所述跨行业清算对账差异申诉管理系统用于清算对账差异申诉处理工单的创建、查询、处理反馈，支撑各行业清算对账人员及时有效处理跨行业对账差异议问题；并能实现对各交通平台公共服务能力的有效评价。

6.根据权利要求3所述的一种交通多平台统一管理的一码通乘系统，其特征在于，所述的公共管理平台还包含全维度的交通统计分析管理系统；

所述的交通统计分析管理系统能够提供轨道交通、城市公交、远郊公交多方数据整合，实现流量监控、热度预警、应急调度、可视化作战大屏、智慧交通大数据分析服务；以及提供多维度的统计分析报表，实时查看业务数据，及时全面掌握交通行业状况。

7.根据权利要求1所述的一种交通多平台统一管理的一码通乘系统，其特征在于，所述的数据交换平台包括原始数据交换模块、单边交易数据交换模块、请款数据交换模块，退款数据交换模块、发票数据交换模块、黑名单数据交换模块、推送通知数据交换模块、数据传输审计模块；

所述的原始数据是乘客进出站后机具产生的跨行业原始交易，用于刷码提醒和行程记录展示，此数据单向传输，无交互逻辑；

所述的单边交易数据是指跨行业的不完整交易数据，用于提醒APP提供方的用户进行补票操作；

所述的请款数据是指跨行业配对完成后需要请款的交易数据，用于向APP提供方的用户请款使用；

所述的退款数据是指跨行业配对请款完成后，用户需要退款的交易数据，用于向APP提供方的用户退款使用；

所述的发票数据是指用户通过APP发出开据行业方发票申请的记录数据，用于场景服务提供方给APP提供方开具发票；

所述的黑名单数据是指行业方检测到一码通行用户触发了风控变动后加入或者移出黑名单的记录，用于同步黑名单数据；

所述的推送通知数据是指行业方、一码通乘平台进行公告、通知信息时的数据，用于APP提供方的消息通知使用。

Images