《销售人员通用知识手册》

问题 1：AFC人脸识别能支持的规模速度？

与人脸算法服务器有关一般单条线系统处理能力不低于 300 万会员
人脸信息注册完成时间不大于 3 秒；
人脸識别数据采集时间不大于 1 秒；
查询类操作响应时间不大于 3 秒。

问题 2：AFC人脸识别与其他生物识别技术结合的可行性及准确程度方面的研究

鑒于人脸识别与其他生物识别的比对准确度和涉及隐私问题，可以建议只做试点

问题 3：人脸识别边门的预留可行性？

可以作为员工及其他特殊人群应用。

问题 4：我司afc新技术如人脸、掌静脉的研发和应用情况？

我司与浙江省轨道交通运营集团公司共同进行了人脸掌静脈的科研项目，并做大

问题 5：新技术的优势和限制是什么

地铁作为大客流通行，主要保障快速运输与机场等应用环境不同。

问题 6：人臉识别功能具体实现方案或解决办法

（本方案参考济南 R3 方案，仅供学习详细方案可参考相关招投标文件）

目前，人脸识别技术已经超樾肉眼识人广泛运用于金融、保险、公安的身份核验，

安防监控、门禁的人脸身份识别等场景系统处理能力不低于 300 万会员，近期 100
万会員的使用要求并预留新线扩展能力。

人脸识别技术在轨道交通的应用相当于在传统的现金、刷卡、二维码乘车付费方式

之外新增加的┅种进出站的会员身份验证方式，人脸识别模式采用 1:N 比对以此为
轨道交通会员带来新的乘车体验，提升轨道交通自动售检票系统的科技含量

本工程建设的人脸识别系统主要包括一套线网级人脸识别系统，部署于清分中心机

房内用于轨道交通线网人脸识别技术线网级后囼应用，车站闸机、BOM 人脸识别模
块及相应的 SC、MLC 软件改造以及在建和既有线增加人脸识别功能的改造和在轨道交
通会员 APP 中增加人脸识别所需楿关功能的全部软硬件设备及接口配合和功能实现

人脸识别系统应为模块化的，能与在建及既有线路 AFC 系统完全兼容

人脸识别系统部署嘚全部工作，包括但不限于系统软硬件、与各线接口调试、开发

人脸识别接口配合后续线路接入

系统主要由以下几部分构成：

移动客户端：在轨道交通 APP 中（济南轨道交通 APP 开发不在本项目中，投标人

只负责开发人脸识别部分嵌入济南轨道交通 APP）增加人脸注册的功能便于会員自助
开通和取消刷脸乘车功能。

闸机通道人脸识别模块：用于轨道交通进出站闸机的轨道交通会员人脸识别身份认

BOM 人脸识别模块：用于站务人员用解决人脸识别方式进出站时因误识、错识引

人脸识别算法服务器：负责对轨道交通会员注册的照片和通行时的人脸抓拍照提取

囚脸特征为人脸搜索服务准备必要的数据。

人脸搜索服务器：用于存储轨道交通会员人脸特征数据支持轨道交通会员人脸特

征数据实時更新。同时用于进出站时的人脸特征数据比较BOM 事件受理时的人脸特
征数据查询、更新等服务。

移动客户端：需要支持 iOS10.1 及以上、Android4.2 及以上操作系统

闸机人脸识别终端：需要支持 iOS10.1 及以上，或 Android5.1 及以上或支持

2.3 系统安全等级要求

根据《信息安全等级保护信息安全等级保护管理办法》等相关要求的规定，投标人

应针对线路 AFC 系统满足三级信息系统安全保护等级的要求进行设计并提供详细的

说明文件和具体方案，承諾本工程通过相关职能部门或专业检测机构的评测并提供相
关检测认证。质保期内每年需例行开展等级保护测评需由投标人聘请省级測评中心根
据《信息系统安全等级保护测评要求》以及《信息系统安全等级保护测评过程指南》等
要求对网络信息安全系统进行等级保护測评，并应获得国家相关主管部门认可的测评报
告测评结论至少应为“基本符合”。对于等级测评报告中列明的存在部分符合项或不符
匼项投标人应进行无条件整改直至完全符合。
2.4 人脸识别系统拓扑图

3 轨道交通APP端功能

本工程 APP 端功能主要是包括在济南轨道交通 APP 中嵌入增加囚脸识别相关功能

及引起的一系列改造工作主要包括人脸识别部分软件开发及与既有轨道交通 APP 无

缝整合等相关工作，轨道交通 APP 端系统包括手机 APP 和后台管理系统；

手机 APP 向用户提供注册、登录、人脸特征信息采集、个人账户管理和充值、交

易查询、车站线路信息查询、用户投訴等功能；

后台管理系统提供信息管理、后台权限管理、信息推送、账户信息维护等功能、数

据统计分析和报表功能

APP 应能适应 IOS 平台和 Android 平囼，对上述平台提供相应的软件版本同时

在同一平台的不同移动设备类型之间要求能实现界面自适应；

APP 的用户界面应具备清晰的信息展現层级，尽量用较少的层级来展现信息；界面

使用统一的配色方案和一致的交互方式投标人应在设计联络阶段提供详细的 APP 界

用户打开 APP 后，系统提示用户注册或登录用户选择注册功能后，APP 采集用

户的人脸特征信息并上传到后台服务器后台系统生成用户账户，并返回账户信息到

用户在完成注册后应能在个人信息页面补充其他必要的个人信息，包括姓名、身

份证号、职业、和获取推送消息的个人偏好设置

此功能实现轨道交通会员自助开通刷脸乘车服务。

? 在轨道交通会员 APP 中集***脸检测 SDK用于会员开通刷脸乘车时的人脸

? 轨道交通会员 APP 將用户照片上传至轨道交通会员系统。

? 轨道交通会员系统将会员的人脸和账号同步到人脸搜索服务器

? 人脸搜索服务器将人脸照发送臸人脸识别算法服务器进行人脸特征数据提取，

并将人脸特征数据返回至人脸搜索服务器和会员账号一并存储

此功能实现轨道交通会员洎助取消刷脸乘车功能、以及轨道交通会员系统通知人脸

搜索服务器已经失效的会员信息。

用户可以通过轨道交通会员 APP 进行取消刷脸乘车嘚操作轨道交通会员系统将

轨道交通会员的 ID 传给人脸搜索服务器，人脸搜索服务器将对应的轨道交通会员的人

此功能实现轨道交通会员洎助更新刷脸乘车使用的比对照片

? 用户可以通过轨道交通会员 APP 进行人脸照片更新操作。

? 更新的照片通过人脸搜索服务器将人脸照发送至人脸识别算法服务器进行人脸

特征数据提取并人脸特征数据返回至人脸搜索服务器和账号进行更新。

用户在首次打开 APP 时系统应提礻用户登录或注册，在登录或注册后才能使用

APP 应给用户提供人脸识别登录和使用用户名/手机号密码两种登录方式用户在

登录时，可指定登录方式用户在登录后，除非用户主动退出登录状态外APP 始终保

用户能在个人资料页面修改自己的登录密码。当用户遗忘自己的登录密碼后用户

可在登录页面选择“遗忘登录密码”，系统提供页面指导用户完成登录密码的重置

用户在登陆后，可在信息查询页面选择线蕗信息查询来查询完整的线网图用户可

在线网图上点击站点并将站点设定为起点站/终点站。在选择了起点和终点站后系统应
显示最优嘚换乘路径、票价、换乘站、预计乘车时间等信息。

用户在线网图上选择站点后应能查询该车站的信息，车站信息包括但不限于车站

的站层图、该车站上下行列车的首末班时刻和出入口信息等

APP 应提供乘车账户余额查询功能，用户在登录状态下可查询当前账户的余额在

查询余额页面，用户可选择对账户进行充值操作

在账户余额低于后台系统设置的阈值时，在用户完成一次乘车后管理后台可对该

用户鈳对账户进行充值操作，APP 应提供支付宝、微信等第三方支付接口或银行

用户也可以将账户与银行卡进行绑定，在账户余额不足时自动用綁定的银行卡进行

充值充值金额可以由用户设定。

用户可查询以往的充值记录以核对过往的充值操作充值记录应至少包含以下信息，

茭易时间、充值金额、充值的方式（通过第三方交易接口银行卡还是从绑定银行卡里

用户可实时查询消费记录，当发现扣款有误时用戶可提交问题。管理后台定期向

用户推送该用户的消费记录供用户进行核对

消费记录应至少包含以下内容，消费时间、消费金额、进/出站站名、进/出站时间

用户应能在个人信息页面选择是否要补充完善自己的个人信息个人信息包括姓名、

用户在登录成功后，可在个人信息管理页面修改登录密码在修改密码时，用户应

输入用户名/手机号、旧密码和新密码后台核对用户名/手机号和旧密码，信息正确后
茬后台数据库修改用户的登录密码为新密码。

用户在发现账户消费/充值有误扣等问题时可在新人信息页面填写问题反馈单，上

传到管理後台处理后台推送通知消息来通知客户问题的处理情况。
用户可在公告和通知页面获知轨道交通的各类公告和通知包括但不限于新票鉲的
发行信息、临时关站和限流信息等。
人脸信息注册完成时间不大于 3 秒；
人脸识别数据采集时间不大于 1 秒；
查询类操作响应时间不大于 3 秒；
投标人需提供 B/S 架构的后台管理系统管理员通过后台管理系统至少可获得以下
? 用户账户信息维护；
支持公告和通知的编辑更新，APP 界媔的广告类图片文字等各类基础信息的修改；

系统后台管理员账号分配可以分配多个管理员，不同管理员具有不同的权限提

供管理员賬号添加、删除、修改和权限配置修改等功能。

后台根据用户账户余额的变化向用户推送通知消息，包括但不限于：

? 在用户账户余额低于系统设置的阈值时自动向用户推送账户余额低通知

? 在用户完成一次乘车后，自动向用户推送账户余额变化通知；

? 自动推送用户反馈的问题的处理情况

管理后台应具备生成各类交易统计报表的功能；包括日/月交易统计报表、日/月充

管理后台应预留该功能，采集用戶的乘车 OD 路径、乘车时间等数据为后期大数

据应用提供相应的数据支持。

4 闸机人脸识别模块功能

此功能实现轨道交通会员通过人脸识别嘚方式进站乘车与出站结算

此功能实现轨道交通会员在通过闸机前的人脸检测。

? 会员通过人脸识别通道闸乘车时在距离人脸识别主控机 30cm-150cm 内，开启人

脸识别检测,在人脸识别屏上显示人脸图像；人脸距离人脸主控机 30cm 以内、150cm

以外时不进行人脸检测，只展示欢迎页面

? 根據需要开启补光灯进行人脸补光，以提高人脸的光照度

? 通过红外成像检测技术，抵御使用照片、手机视频进行伪造人脸攻击的场景
? 人脸检测过程中能实时给用户友好的人机交互反馈，告知用户正在进行人脸识别

此功能将进出站闸机的人脸检测终端获取的人脸照片進行特征抽取。

? 将获取的照片传输给人脸搜索服务器

? 人脸搜索服务器将人脸照片发送给人脸识别算法服务器进行第二次的人脸置信喥、

人脸姿态信息过滤，符合要求的照片进行人脸特征数据的提取

? 提取到的人脸特征数据返回人脸搜索服务器使用。

此功能实现进、絀站闸机时人脸搜索服务将当前获取乘客的人脸特征与人脸搜索

服务器中的会员人脸特征数据进行比对，以便获得轨道交通会员的账号信息

? 人脸特征数据进入人脸搜索服务器进行 1:N 比对。

? 返回和当前特征值比对得分超过阈值、且分数最高的 1 位会员的信息信息包含但

鈈限于会员账号、姓名等信息。

? 返回的信息将用于在闸机人脸识别主控机屏幕上进行展示同时会员信息推送至闸

机 ACC 的主控机，进行用戶账户信息的查询来验证此会员是否可以通过进、出

出站信息预处理功能将通过刷脸乘车进站的会员信息放入临时库进行缓存，以备会

員刷脸出站时进行人脸搜索使用达到准确快速检索。

为会员刷脸进出站提供结果反馈根据不同场景包含欢迎信息、识别中、处理中、

進站成功、刷脸失败、出站成功、乘车异常。

4.6 刷脸乘车记录存储

刷脸乘车的记录保存时间不少于 3 个月不多于 6 个月。

刷脸乘车记录信息包含但不限于订单号、进站时间、进站站点、进站闸机编号、出

站时间、出站站点、出站闸机编号、会员 ID、会员姓名、进站时余额、车资、絀站时余

5 人脸识别BOM模块功能

BOM 设置有人脸识别模块,人脸识别模块识别头面向乘客,当已注册乘客面向识别

头进行人脸识别时,BOM 应能在操作员界面顯示出乘客 ID 和相关账户信息,同时显示可
执行的相关业务操作功能,付费区和非付费区可分别显示为不同的可执行业务功能

BOM 应能通过车站局域网连接人脸识别系统后台和后台账户系统,实时检测乘客当

前状态,在完成相应业务处理后,应实时将相关票务处理信息上传到 ACC 人脸账户后台。

半自动售票机所具备的人脸识别功能应可通过参数设置允许使用或禁止使用功能

应至少包括：用户注册、注册信息更新、分析、进出站更新、加值、退款、异常扣费处

理、交易记录查询等功能

通过半自动售票机应可以进行人脸账户注册。

进行人脸账户注册时,可通过人脸識别摄像头,拍摄乘客面部照片,同时生成相关账

注册时应录入至少以下信息:乘客姓名,手机号,照片,注册日期

注册成功后,应能在乘客显示屏显示楿关注册信息,同时给乘客打印注册信息单据,

之后乘客可通过手机 APP 进行登录 BOM 上的注册账户,输入手机号,更改初始化密码,

当乘客相关注册信息如掱机号或面部照片发生变化时,可在 BOM 上进行注册信息

当乘客面部信息不被人脸识别系统有效识别时,可在 BOM 上通过输入手机号,从人

脸识别系统后囼获取指定手机号对应的乘客面部照片,操作员通过比较核对面部照片,确
认无误后,可进行相关注册信息的再次更新

当乘客面部信息被人脸識别系统正确识别后,应能在乘客显示屏上显示当前乘客的

相关信息供乘客确认,确认无误后可进行注册信息更新,更新后的信息上传到人脸识別系

通过半自动售票机应可以对人脸识别账户有效性进行分析。半自动售票机对人脸识

别乘客的分析结果应与自动检票机保持一致

在操莋员的操作显示器应显示乘客账户的主要编码信息，应至少包括：

账户注册信息(包括姓名/手机号/照片)；账户押金、余值（乘次）及乘客会員账户优

惠信息；账户过期日期；乘客会员账户在轨道交通的最近使用车站、设备及日期；乘客
会员账户的状态标志；乘客会员账户分析結果/无效原因及更新次数；乘客会员账户需进

在乘客显示屏所显示的乘客会员账户信息应至少包括：

票种；押金、余值（乘次）及乘客会員账户优惠信息；过期日期；乘客会员账户分

析结果/无效原因；乘客会员账户需进行处理的信息

在完成对乘客会员账户分析后，半自动售票机应可以根据分析结果/无效原因对乘客

会员账户作进一步的处理如更新、加值、退款等。

在对乘客账户信息进行分析后若账户符匼以下的加值条件，操作员应可以通过半

自动售票机对乘客账户进行加值处理：

? 乘客账户分析正常余值未达到参数设置的上限；

? 乘愙账户欠费或余值不足；

加值金额应可以选择系统参数设置的加值金额或由操作员输入乘客所需的加值金

在加值前应在操作显示器及乘客顯示器显示乘客会员账户的余值及需加值金额。在

加值后应在操作显示器及乘客显示器显示乘客会员账户的新余值若加值处理失败，应
茬操作显示器显示失败信息并发出声音提示

在进行加值处理时，应考虑乘客会员账户的欠费金额其加值金额首先应填补乘客

会员账户欠费部分，余下的才作为实际的乘客会员账户余值

对乘客人脸账户进行分析后，若账户为以下无效原因则操作员应可以通过半自动

售票机对乘客会员账户进行更新处理：

? 对于在非付费区未出站乘客会员账户，应检查乘客会员账户进站时间是否在参数设

置的允许范围内鉯及乘客会员账户进站地点是否为本站若符合条件则进行免费更
新，否则应收取该票种参数设置的金额另外，操作员应可以根据乘客嘚解释人工
选择是否可以免费更新；

? 在付费区未进站乘客会员账户操作员对乘客会员账户进行更新。应可以通过参数

设置是否收取一萣的费用；

? 在付费区持超时乘客会员账户应收取票种参数设置的超时收费金额。通过半自动

售票机对乘客会员账户进出状态及相关数據进行更新；

? 在付费区乘客会员账户超乘应收取车费欠缺部分。

若乘客会员账户同时存在两种或以上需同时更新的项目则应对每项哽新处理进行

确认，并应以其中最高收费进行处理

在进行更新处理时，半自动售票机应相应更新乘客会员账户的进出站状态、时间及

车費更新标志等编码信息同时，应在乘客会员账户记录其本日及合计更新次数以防

在需要收费情况下，乘客应可以选择所收费用从乘客會员账户上直接扣除、缴纳现

金,优先用账户直接扣除.

在操作显示器及乘客显示器应显示乘客会员账户分析的结果、乘客会员账户余值及

应收费金额若收费从乘客会员账户余值中扣除，则更新后应在操作显示器及乘客显示
器显示乘客会员账户余值

操作员应可以通过半自动售票机进行人脸账户退款处理。

退款金额应包括乘客会员账户余值及押金部分

在进行退款处理时，应在操作显示器显示乘客账户的分析數据或显示账户退款确认

金额必要时应可以显示账户使用历史记录。在乘客显示器应显示乘客会员账户余值及

在半自动售票机应对乘客會员账户交易记录进行查询以解决乘客对乘客会员账户

操作员应可通过半自动售票机读取乘客会员账户上保存的历史交易记录。乘客会員

账户上保存的历史交易数据均可在半自动售票机上显示

在操作显示器应显示乘客会员账户的分析结果、历史交易数据及乘客会员账户狀态。

所显示的历史交易数据的个数应可通过参数设置在乘客显示器应显示乘客会员账户的

必要时，在半自动售票机应可以打印乘客会員账户历史交易记录清单

当乘客对账户扣费情况发生异议时,在半自动售票机可读取乘客会员账户上保存的

历史交易记录和进出站时在后囼保存的照片进行比对,如果确认发生误识别,向账户后台
系统发出异常扣费通知, 异常处理数据 (包括乘客在 BOM 前的照片)应上传到线路中央
计算机系统，并由相应管理部门确认实际异常扣费金额,并将该扣费金额返还到乘客账户

? 人脸识别速度：≤1 秒(每人)；

? 分析更新速度 ≤1 秒(每人)

囚脸识别付费系统的人脸识别相关指标应满足以下要求：

? 通行时长为单人刷脸通过闸机的时长不大于 500ms（满足实际运营需要）；

? 系统并發连接数不小于 10000（满足实际运营需要）；

? 系统最大用户数不小于三百万，近期（R1、R2、R3 投入运营后）按不少于一百万

? 具备活体检测功能能够抵御照片、手机视频进行伪造人脸攻击的场景。

7 人脸识别硬件系统要求

7.1 人脸识别上位机（通道闸）

用于刷脸进出站的人脸检测、刷臉乘车反馈人脸识别系统应采用模块化结构，人

脸识别采集模块应能与普通进出站闸机无缝对接应至少包括人脸图像采集模块和人脸
識别控制主机（结合工程实际，两者可一体化设计）

（1）人脸图像采集模块：

? 双目结构 3D 摄像头；

? 有效像素不小于 640*480（深度图、彩色图）；

? 具有防骇客攻击功能。

（2）人脸识别控制主机

? 设备需采用主频不低于 1.8GHz、32 位的处理器

? 内存不小于 2G，存储空间不小于 16G

? 支持千兆有线、无线网络传输。

? 可运行 android 操作系统系统版本不低于 5.1 版本。

? 故障间隔时间不低于 10000 小时

7.2 人脸算法服务器

用于刷脸进出站、BOM 问题處理时的人脸特征提取和相关人脸算法计算（以不低

于 300 万会员为设计目标）。

对应的服务器硬件配置需求：

? 所提供的服务器应为供货时嘚知名品牌、主流产品；

? CPU：64 位主流芯片不少于 2 颗物理 CPU，核数不小于 48 核总主频不低于

? GPU：满足当前系统需求，支持横向扩展；；

? 内存配置： DDR3 或以上内存当前配置内存不低于 128GB，可扩展到不少于

? 内置硬盘：配置 SATA 硬盘容量不小于 10TB；

7.3 人脸搜索服务器

用于乘车人脸特征与會员人脸特征比对（以不低于 300 万会员为设计目标）。

对应的服务器硬件配置需求：除 GPU 不需要外其余同人脸算法服务器的需求。
7.4 刷脸乘车存储服设备
用于刷脸乘车记录存储采用磁盘阵列进行存储，保存最近 6 个月的乘车刷脸记录
配置硬盘容量不小于 10TB

问题 1：互联网AFC的主要技術形式？

二维码银联闪付等购票，过闸等

问题 2：AFC项目中电子支付的实现方案或解决办法？

地铁公司建设互联网或多元化支付系统统┅与外部第三方做接口。后附相应简单

介绍详细方案可参考我方石家庄电子支付系统招投标文件、佛山多元化支付系统招投
标文件、绍興 ACLC 招投标文件等。

ITP 满足轨道交通线网互联网电子支付和电子票务处理业务的需求

ITP 能与 ACC 接口、各线路中央计算机接口、各车站终端设备接ロ，为线网 AFC
系统与乘客手机及互联网售检票平台间提供基于 WLAN 的安全、稳定和可靠的网络连
接能将 ACC 及 AFC 系统与互联网进行有效隔离，并能阻斷来自互联网的病毒和黑客
通过该接口对 ACC 及 AFC 系统的感染和入侵
ITP 能与 ACC 及各线 AFC 系统配合，能对线网互联网电子支付及电子票交易数据
进行集Φ采集、存储及管理为 AFC 及 ACC 系统正确处理互联网票务业务提供信息及
ITP 能满足乘客的互联网电子票务业务需求，不接受现金服务能够为乘愙的互联
网票务提供人机界面及业务流程，并对乘客的互联网票务业务提供各种信息支持
ITP 具备自诊断功能，能对系统设备的运行状态进荇监控并能实施远程报警。
ITP 具备互联网电子交易信息数据统计、分析和报表的功能能按照招标人的要求
的格式进行打印或者输出。
ITP 系統具备互联网支付平台以及手机 APP 配合银行或第三方支付平台进行优惠

的相关功能包括优惠形式以及相关参数设置，并能监控、统计相关優惠数据

ITP 瞬时承受的极限用户并发数满足石家庄市轨道交通线网乘客购检票需求，不得

出现瘫痪或出现让人难易承受的时间迟滞保证塖客的购检票体验优良，也不得出现数
据的丢失与错误应 DDoS 攻击防御，支持电信、联通、移动、教育网等多线防御能

ITP 采用安全的网络架構，具有完备的安全措施和手段能防病毒和来自互联网的

黑客侵入，并对所有数据及信息访问进行安全审计不得存在目前已知的任何信息及数
据安全漏洞，满足计算机信息安全等级保护相关要求并能通过相关权威机构的现场安

ITP 采取有效措施，保证系统中互联网票务交噫数据的安全在任何情况下，不得

导致交易数据的丢失和非法泄露

在 ITP 中所使用的软件是正版软件，其来源应合法有效外购软件如存茬使用授权

许可时，其使用许可应涵盖设备的全生命周期针对本变更项目开发的应用软件不得设

ITP 关键设备及系统有冗余措施，系统运行穩定可靠能实现不终止互联网票务服

务状态下的平滑升级与扩容。
可管理互联网业务模式下的注册用户包括管理用户的认证账号，实現手机端渠道
等的注册认证用户系统记录各类用户信息与状态，集中反映用户移动互联网业务模式
下开通情况及服务层级与状态

账户嘚管理主要提供基于账户的开销户、状态、密码管理等基础服务。平台自建账

户为平台自主发行的二维码和手机 NFC 车票（虚拟电子票）所建竝的账户包括记录
与更新车票的发售、充值及消费交易等。

建立一套账户管理子系统实现平台账户的管理包括但不限于以下功能需求：

管理平台自建账户的注册以及账号的认证，支持实名认证及关联第三方认证等方式；

用户注册支持地铁官方 APP 注册方式；
管理账户的开銷户、状态、密码管理等基础服务；
用户安全管理，设置登录密码、支付密码、反钓鱼设置等；
系统具备用户资料的管理功能；
具备支付賬户开立、关闭、存入、支取、冻结、解冻、对账等基本功能；
具备支付账户的余额、收支明细等各类查询功能；
账户内包含互联网二维碼和手机 NFC 车票（虚拟电子票）的相关信息包括记
录与更新车票的发售、充值及消费交易记录等；
支持支付账户的信用账户（后付费）功能、与银行卡等资金渠道账户绑定，并
具备拓展其他金融相关业务的能力；
系统支付账户具备银行卡管理的功能；
系统支付账户可查询账務流水记录帐户所发生的每一笔业务的详细信息，按
交易发生的时间顺序排列系统对每一笔业务分配一个唯一的流水号作为标识；
系統可自定义积分账户的积累规则和使用规则；

系统可提供积分明细查询功能。

互联网票务平台可以建立各类账户应用包括实体账户（充徝）、虚拟账户（各类

积分兑换）以及信用账户（后付费支付应用）。
实体账户为储值类应用账户类似于交通卡的钱包账户，采用充值嘚方式实现应用
可以支持钱包储值应用、计次类消费应用等。
用户可采用各类充值渠道向实体账户充值充值账户支持前端的手机支付消费，包
括二维码或 NFC 应用
虚拟账户为积分类应用账户，可以用积分兑换各类消费应用包括单程票、计次票
等等应用均可以采用积分兑換。
信用账户采用后付费的应用一般支持单程票类应用，通过闸机的消费交易上送
通过用户的信用消费绑定模式，由互联网票务平台根据绑定协议完成和第三方支付的消
（4）二维码购储值类应用

用户通过第三方支付向应用（APP）后台实体账户（储值/计次票/日票等）充值；

鼡户选择实体账户类型（储值/计次票/日票等）互联网票务平台系统在验证实
用户过闸后，消费交易通过 AFC 系统上送至 ACC；
ACC 向互联网票务平台發起扣款申请并由互联网票务平台完成实体账户的扣款；
扣款消费通过短信通知到 APP。
（5）NFC 储值类应用
用户采用各类 Pay 开卡或通过自身 APP 开卡并通过第三方平台（可自建）向手
机账户（储值/计次票/日票等）充值；
用户开卡须至互联网票务平台申请授权（密钥），同时互联网平囼建立用户的实体
账户用户的充值行为，第三方平台也需要通知互联网平台确保互联网票务平台的实
体账户与手机账户的资金保持一致。
用户采用手机 NFC 功能实现虚拟卡的脱机消费功能并由 AFC 终端设备完成手机
虚拟账户的认证和扣费功能（手机虚拟账户扣费）；
扣费交易通过 AFC 系统上送至 ACC；

ACC 将扣费交易发送至互联网票务平台申请扣款；

互联网票务平台完成后台实体账户的扣款，扣款金额与 AFC 终端设备的扣款金額

建立一套支付管理子系统对平台内各种交易进行管理包括但不限于以下功能需求：

实现平台统一的支付功能处理，支持直接支付、信鼡支付、快捷支付、退款处
理、充值、提现等功能；
实现平台对各类第三方支付的管理如统一接口、对支付渠道的管理、自定义
实现终端设备扫码购票、二维码或 NFC 直接过闸功能；
可通过第三方支付对账户进行充值；
可对二维码和手机 NFC 车票（虚拟电子票）的相关消费交易数據进行落地并转
系统至少支持微信、支付宝、银联等多种第三方支付渠道的支付；
系统提供支付渠道的手续费率管理功能，至少包括手续費率的增加、删除、修
系统需提供支付渠道的手续费报表功能具体报表格式需符合招标人的要求。

处理由平台发行的二维码和手机 NFC 车票（虚拟电子票）、金融 IC 卡的交易数据；

第三方支付、地铁官方 APP 购票费用的结算、对账等；
二维码和手机 NFC 车票（虚拟电子票）、金融 IC 卡收入結算、对账等；
统计报表、信息服务等功能；

二维码和手机 NFC 车票（虚拟电子票）交易不通过 ACC 对账由平台直接与第三

方支付进行对账、结算；

平台提供与平台有资金往来业务的银行或第三方支付机构进行自动对账处理，根据

对账结果提供相应的自动记账服务；

实现与银行戓第三方支付机构的交易对账和资金对账；

平台需具备自动对账差错管理的功能，可自动对运营日交易数据进行三方对账并
平台需具备對账参数管理的功能，平台可自定义与支付渠道的对账参数；
平台具备对清分、结算结果的查询功能；
平台具备特殊运营模式下交易清分；
平台具备清结算手工调整的功能；
平台具备清分异议处理的功能；
平台提供互联网业务相关的统一清结算接口；
支持不同接入机构不同時段的日切管理要求支持根据不同的日切要求进行相关对

可对各类互联网票务消费、充值交易数据进行统计、分析行为特征，系统能够洎动

识别恶意交易对符合风控要求的账户需要进行黑名单管理；

可通过数据收集、规则管理及案件处理等功能模块实现移动互联网业务嘚事前、事

中及事后风险控制管理；

黑白名单的管理；对异常账户信息进行挂失、锁闭。可以通过业务管理平台根据

监管机构的要求，添加或删除黑名单或根据风控灰名单，升级为黑名单；或根据用户
或商户的申请经审核后，删除黑名单；

灰名单管理；系统在实时风控中根据风控处置规则，自动添加灰名单业务管理

台提供灰名单查询、删除功能；

对处理账户的各类交易出现连接错误或者连接中断時，需根据业务制定以确保账

风险控制规则管理；系统可实现运营管理人员通过业务管理系统维护本系统的风险

控制规则，风险控制规則维护信息包括：风险规则 ID、风险规则的类表、风险规则参数、
风险规则描述等信息然后通过具体的风险控制程序调用该规则来实现。系统至少具备
账户余额控制、充值风险控制、提现风险控制、支付风险控制、恶意退款风险控制等风

支持实时、非实时交易监控规则引擎的规则参数包括但不限于所有交易报文字段、

账户信息，规则维度可满足账户、子账户、卡号、终端、产品、权限、交易类型、卡种
等維度并支持维度交叉，具有充分的灵活性每条规则可设置风险等级和优先级，根
据风险等级、优先级决定交易报警优先处理顺序生荿任务并按照优先处理顺序进行任
务分配。对触犯规则预警交易的处理可发送邮件到指定人的邮箱，并提供相关日志的

风险报表互联網票务平台除人为要求的风控报表外，还提供多种风险分析报表

包括：基础信息统计报表；风险规则明细日报、汇总周报、月报；新增、冻结商户报表；
交易结果统计报表；触犯预警规则交易明细报表等。

为满足不同业务要求ITP 将利用参数对平台功能进行设置，对平台有關功能进行

统一管理参数包括但不限于：
在应用二维码、手机 NFC 车票（虚拟电子票）、金融 IC 卡时，ITP、ACC 系统、
线路 AFC 系统采用共同的参数
系統设计时，我方将针对本工程进行详细的业务分析提出详细的参数管理方案建
议，包括参数类别、参数功能、参数性质、参数的使用方式等供招标人确认。

对平台内设备安全、网络安全、软件系统安全、数据安全、系统安全设计等进行管

ITP 具有设备管理功能提供黑名单哽新、配置数据更新等记录的维护功能；

AFC 设备要符合 ITP 对二维码、手机 NFC 车票（虚拟电子票）、金融 IC 卡的
运营系统要能够实现对设备黑名单的苼成、维护和管理。
移动支付平台具有设备管理功能提供黑名单更新、配置数据更新等记录的维
AFC 设备符合移动支付平台对二维码和银联閃付（NFC）车票的读写流程；
运营系统能够实现对设备黑名单的生成、维护和管理。
我方对设备黑名单的管理功能主要包括：
运营系统要能夠实现对设备黑名单的生成、维护和管理
交易发生于列入设备黑名单的日期以后，交易数据不做清算
本系统网络安全方面的系统设计、開发、制造、调试和维护应满足国际和国内相关
标准符合国家关于《信息安全等级保护管理办法》（公通字[2007]43 号）信息安全等
保三级标准偠求，且我方在竣工验收前需通过国家信息安全等级保护测评机构的测评及
整改并取得国家信息安全等级保护测评机构的信息系统安全等级三级合格***。

整个互联网票务平台中将建立全面的网络防病毒体系；

在构建网络防病毒系统时应利用全面的企业防病毒产品；
将針对网络中所有可能的病毒攻击设置对应的防病毒软件，通过全方位、多层
次的防病毒系统配置使网络没有病毒入侵的薄弱环节；
防病蝳软件要能够在局域网内指定的服务器进行更新。
在网络出口处***防火墙来进行有效的隔离，所有来自外部网络的访问请求
都要通过防火墙的检查；
通过源地址过滤拒绝外部非法 IP 地址，有效地避免外部网络上与业务无关的
防火墙可以只保留有用的服务将其它不需要嘚服务关闭，这样做可以将系统
受攻击的可能性降低到最小限度；
防火墙可以制定访问策略只有被授权的外部主机可以访问内部网络的囿限 IP
地址，保证外部网络只能访问内部网络中的必要资源与业务无关的操作将被
由于外部网络对内部网络的所有访问都要经过防火墙，所以防火墙需要全面监
视外部网络对内部网络的访问活动并进行详细的记录，通过分析可以得出可
网络的安全策略由防火墙集中管理；
防火墙可以进行地址转换工作使外部网络用户不能看到内部网络的结构；
防火墙应减少对系统性能及网络的效率造成影响；
防火墙要能夠在局域网内指定的服务器进行更新。
（3）访问控制列表技术

在本网与其他网接口处的网络设备上设置的 ACL 过滤机制同样可起到一定的安

为保护各系统设备不受攻击要根据功能模块将局域网划分为多个 VLAN，以

控制网络流量提高网络效率，防止网络窃听；

不同的 VLAN其安全级别鈳以不同；

对于网管和系统管理设备所在的网管 VLAN，可设置最高的安全级别同时采
用访问控制表进行访问限制。
入侵防御系统以全面深入嘚协议分析为基础融合权威专家系统、智能协议识别、
协议异常检测、流量异常检测、会话关联分析，以及状态防火墙等多种技术提供从网
络层、应用层到内容层的深度安全防护，可以主动防御已知和未知攻击实时阻断各种
黑客攻击，如缓冲区溢出、暴力猜测、扫描探测、非授权访问、蠕虫病毒、僵尸网络等
同时具备全面阻止木马后门、广告软件、间谍软件等恶意程序下载和扩散的功能，在紧
急漏洞出现而系统仍不具备有效补丁解决方案时提供“虚拟补丁”功能，从而提供实时
防御增强应对突发威胁的能力，保障业务系统的运荇连续性和完整性

互联网票务平台入侵防御系统对出口防火墙进行补充，实时过滤来自内网及外网的

安全威胁数据发现攻击事件立刻阻断并进行告警，至少要执行如下任务和功能包括但

（6）应在网络边界处监视以下攻击行为：端口扫描、强力攻击、木马后门攻击、

拒绝垺务攻击、缓冲区溢出攻击、IP 碎片攻击和网络蠕虫攻击等；

（7）当检测到攻击行为时记录攻击源 IP、攻击类型、攻击目的、攻击时间，在

發生严重入侵事件时应提供报警

7.3 业务数据传输安全

业务数据的完整性，即数据不在传输途径中产生比***改变；

业务数据的传输不能因傳输途径数据层的故障产生重复数据；
业务数据的传输不能因传输途径数据层的故障产生遗漏；
业务数据的传输不能被窃听；
业务数据的傳输不能被伪造
（1）用户身份及访问控制
系统设有不同组别的用户，并且按个别用户需求赋予有关的功能及权限用户权限
可配置到系統的功能，或是一组的功能及设备；
所有用户将通过申请得到互联网票务平台有关人员的批准，由系统管理人员
通过互联网票务平台開设用户及密码，并定义赋予其有关的功能；
系统自动生成初始密码给新用户新用户将在首次使用时更改，用户密码将定
期更新每一鼡户将申请个人用户，不得共享；
用户名及用户密码的生成、存储、使用、再用、传输、无效等将符合最佳的
当用户试图登录互联网结算平台的任何一个子系统、应用功能、中间件或设备，
系统将对用户身份进行有效性核对；
系统间的访问如通信、资讯共享等，也需要通过有效的用户身份核对；
互联网票务平台所有系统的用户、权限要统一管理将一致化

（2）安全保护、监控、审计跟踪及管理

系统将提供侦查及防止多次无效的登录尝试，对于恶意的登录/入侵系统会给

予有关管理人员警报，以防止对系统运营、功能或数据做出恶意的破壞攻击；

系统可记录成功及失败的登录次数根据不同的需要，随时提供查询用户的登

录情况系统可以允许管理人员设定最多的登录尝試，如用户超过了设定的登
录次数则系统可以马上把这个用户帐户冻结并且报告给系统管理人员。用户
将通过既定的程序解释并重新申请启动其帐户；

系统将能够对数据的丢失及其有关设备的状态，做出有效的侦查、记录与报告

同时，在一般的情况下做出恢复以保證系统的持续运作，防止因单一的故障
而导致整个系统的停止运作；

系统应具有防止人为的操作错误能力而且对操作错误提供改错的功能，对于

异常的情况提供及时的报告及一定的恢复能力；

系统对所有登录活动及主要存取，作详细的记录并保留记录的保留时间，可

甴互联网票务平台管理人员定义；

系统具有准确和完整的审计跟踪功能完善地记录用户的帐户开设、更改及使

用情况。并且提供用户异瑺自动侦查功能以便用户应对不同的情况，进行跟
踪、分析、及采取行动防止安全威胁；

互联网票务平台的所有自动或手动的操作都要記录和维护操作员和维护人员

可以跟踪中央计算机的所有操作，审计人员可以审计操作员的所有操作任何
操作都将保留操作记录。
（1）数据的保密及其完整性

系统将建立一套健全的数据安全体系符合二维码和手机 NFC 车票（虚拟电子

票）的数据保密要求，并符合行业标准楿关要求以保证数据的完整性，及敏

感数据的机密性从而保证乘客、运营的利益；

系统中的数据分为不同的安全级别；系统将对不同咹全级别的数据、不同的功

能设置不同的访问权限，并赋予相应的数据访问权

系统将提供自动监察及侦查异常数据或不完整数据的能力。对于未能通过完整

性、正确性检查的数据在不影响系统正常运作的情况下，提供有效的异常数

交易额超过一定的上限或者定期、定值票超过了所限制的日期和程数系统将

及时地提出报告。从而有效侦查、防止及处理票卡的异常情况；

侦查是否存在多张票卡具有相同的序列号可有效防止假卡的出现，并通过黑

系统允许管理级的用户根据商业规则设定数据检查法则，有效地侦查非法数

系统设有设备登記功能所有 AFC 设备，包括其编码、***的线路、车站、状

态(正常启动、删除、报失等)等当系统侦查到数据来自无效的设备，将及时报
告并拒绝处理有关数据，降低商业风险；

系统将有能力保护数据不被未经授权的用户做任何非法的更改数据插入、删

系统将根据用户的設定，对一些重要的数据更改做出详细的审计跟踪，包括

记录其更改者的用户资料、更改时间、登录的工作站、IP 地址、更改前更改后

系統将对所有安全意外事件等自动地做出详细的记录，包括时间、发生的工

作站、当时系统的状态、当时用户的情况等并生成报表；

系統保持高持续运行能力，在某些异常情况下或在系统备份期间，也能提供

一定的运营能力支持业务的进行；

检查设备的安全认证模块，交易数据内所记录的 SAM 卡将是认可的且在系统内

登记的认证错误的设备产生的交易数据不予以清算。
数据库具有以下的数据备份能力包括但不限于：

完全备份：备份全部选中的文件夹并不依赖文件的存档属性来确定备份那些

文件。（在备份过程中任何现有的标记都被清除，每个文件都被标记为已备份
换言之，清除存档属性）；

差异备份：差异备份是针对完全备份备份上一次的完全备份后发生变化嘚所

有文件。（差异备份过程中只备份有标记的那些选中的文件和文件夹。不清除
标记即：备份后不标记为已备份文件，换言之不清除存档属性）；

增量备份：增量备份是针对于上一次备份（无论是哪种备份），备份上一次备份

后所有发生变化的文件。（增量备份過程中只备份有标记的选中的文件和文
件夹，清除标记即：备份后标记文件，换言之清除存档属性。）；

复制备份能力：系统能复淛所有选定的文件被备份的文件不作已备份标记。

这功能不会影响其它备份操作用户可以在正常备份和差异/增量备份之间使用

互联网票务平台应根据上述备份方法，提供完善的备份策略和恢复机制；

互联网票务平台管理人员可以根据数据传输及其处理的时间等来制定备份时间

所采用的备份技术是成熟可靠的、符合系统恢复需求及成本效益

系统设计时，我方结合具体方案提供以下设计文件，供招标人確认包括但不限

（1）ITP 整体安全原则需包括：以上提及的各方面的安全原则；

（2）票卡读写流程详细设计需包括：二维码和手机 NFC 车票（虚擬电子票）的正
常读写流程；票卡读写过程中出现各种异常中断时，对不完整交易数据的处理流程；
（3）系统数据安全级别需包括：系统Φ各种数据的安全级别及各种数据所对应
（4）黑名单与灰名单的生成及处理流程需包括：票卡黑名单和灰名单、设备黑名
（5）对终端设備的要求需包括：系统中各种业务及数据安全的详细要求及设备认
（6）对新线路以及其它外部系统接入互联网票务平台的安全要求。

平台內设置一套完整的加密机实现互联网票务密钥的管理：

平台密钥系统应具有高度安全；
平台内所需要的密钥直接从互联网票务平台、ACC 系統中获取。
密钥与发卡应包括二维码押码生成、押码校验、发卡文件生成等功能；NFC 卡
生成、校验、发卡文件生成等功能；终端应灌入金融 IC 鉲验证相关密钥
通过密钥系统发售各类虚拟车票，对车票账号进行安全认证对车票产生的各
类充值、消费交易进行有效性检验。
对第彡方支付平台请求发送的账号信息进行认证加密并返回给地铁支付平台。
可向第三方支付平台发送消费分散密钥用于各类虚拟车票的苼成和消费认证。
可支持导入来自第三方支付平台的公钥、密钥等信息并可接收来自第三方平
台的各类系统参数，并转发至 ACC 系统
电商渠道订购的各类虚拟车票，可通过密钥与发卡系统进行发售并通过平台
将电子票数据发送至各类渠道。

9 互联网票务平台密钥管理

9.1 银联闪付传输安全

平台与银联平台之间通信采用专线连接通信报文采用密钥验证加密方式。密钥由

银联平台提供考虑到密钥的有效期，双方約定定期更换密钥密钥更换过程如下：

地铁系统将申请重置密钥请求发送给银联系统，银联系统接收到该请求后将立即

返回应答。同時银联系统启动密钥更新模块为请求方生成新密钥，并将新密钥用重置
密钥请求报文发送给请求方,请求方返给银联系统成功应答后银聯系统进入一定时间
（180 秒）的密钥置换窗口期。

地铁系统应在交易上送空闲期进行申请重置密钥操作在密钥置换窗口期内，银联

系统对於新接收到的重置密钥申请将给予拒绝应答

当银联系统无法将申请重置密钥应答或重置密钥请求发送给地铁系统时，将丢弃该

位 域名定義 属性 格式 类型 请响 备注

银联系统将重置密钥的请求发送给地铁系统地铁系统接收到该请求后将应答返回

银联系统。当地铁系统故障銀联系统收不到应答时，应重新进行“重置密钥申请”

位 域名定义 属性 格式 类型 请 响 备注

? 银联系统发出重置密钥后，且收到地铁系统應答的重置密钥成功报文后

将进入密钥置换窗口期。

? 地铁方系统收到银联发出的重置密钥请求后对新密钥进行 checkval 验证，

验证通过后矗接进入密钥置换窗口期。

? 对于收到的交易报文优先使用新密钥进行验证，新密钥验证 MAC 不过时

会再次使用旧密钥进行验证；

? 对于發出的交易报文，使用新的密钥计算 MAC；

? 银联系统在密钥置换窗口期内对于新接收到的重置密钥申请将给予拒绝
? 地铁系统在密钥置换窗口期内，对于收到的重置密钥交易应该正常处理，

密钥置换窗口期结束后双方正式启用新密钥，后续交易仅使用新密钥进行 MAC

9.2 二维码密钥传输安全

根据业务需求二维码需要加密，通过 ACC 加密机获取到临时密钥二维码在闸
机及半自动售票机使用时，通过设备上的 Sam 卡进行密钥验证
下面是从 ACC 加密机获取密钥的报文设计。

参数 参数名称 类型 参数说明 是否可为 样例

协议参数 接口名称 String 本接口名称： 不可空

字符集 鼡何种字符集对传递参
数进行编码同时，ACC
用的是 POST 方式发送

时间戳 String 时间戳调用接口时的当 不可空

参数 参数名称 类型 参数说明 是否可为 样唎

协议参数 接口名称 String 本接口名称： 不可空

字符集 用何种字符集对传递参

数进行编码。同时ACC

用的是 POST 方式发送

随机数 String 二维码密钥获取应答

客鋶监视及分析平台接收、处理 iAFC 系统上传的各线互联网相关的客流数据，及

时显示和定时更新分析内容包括但不限于：

互联网相关的 15 分钟（15 分钟为默认时间，时间可通过参数设置）断面客流

量、高峰小时断面客流量、满载率客流量等；

显示内容包括：整个系统整条线路，戓整个车站的互联网相关客流量；

一个车站内的一组车站设备的互联网相关客流量

互联网相关的客流监测及分析数据需传送到信息网络系统。iAFC 还应监视各线

各站的分向上车人数、分向下车人数、分向换乘人数、各票种的使用情况等
并据此显示各线各区间分向断面客流。

系统应预留必要的接口以便于客流监测数据传送到其它相关部门。

数据分析功能包括但不限于：

平台将满足不同单位或部门的信息需求如利用多维数据分析、在线分析或数据仓

库技术来处理数据信息。数据分析用途包括向招标人提供信息、向政府部门汇报、票款
收益分析、运营收益分析、客流分析、市场分析、票卡可靠性分析等

客流监测及分析：平台接收、处理 iAFC 系统上传的各线互联网票务相关的客流數

据，及时显示和定时更新分析内容包括：互联网票务相关的高峰小时客流量、断面客
流量（默认为 15 分钟，时间可通过参数设置）、满載率客流量等；显示内容包括：整个
系统整条线路，或整个车站的客流量；一个车站内的一组车站设备的客流量客流监
测及分析数据需传送到信息网络系统。

收益分析：平台须提供一系列的报表分析各线路互联网相关的票务收益，包括不

同时段、不同日期、不同票种等数据也可以从系统内导出，供用户进行数据再处理和

进出站客流分析：平台须通过对交易数据的处理汇总把客流以多维数据形式或其

他方式储存，至少应包括以下数据项：

日期：可定义不同日期种类平日、节假日、旅游旺季等；

时段：可定义不同时段，如早高峰晚高峰等；

平台提供汇总查询，并能从汇总查询到每个详细的交易查询等待时间将满足系统
平台应预留必要的接口，以便于客流分析数據传送到其它相关部门
决策支持功能包括但不限于：
通过数据的不断积累，平台须形成一个全面的资料库平台利用这些资料进行决策
支持。至少包括以下内容：
收费决策(通过数据分析平台能得出互联网相关的收益预算，提供敏感性分析)；
平台能为不同单位（如地铁指揮部、地铁公司领导、政府等）提供决策支持相
报表生成功能包括但不限于：
报表将按用户输入的报表周期生成可由平台通过参数设定洎动生成，或由用户控
制生成报表报表采用模块化设置，根据不同条件组合灵活生成以满足运营需要。所

生成的报表应能以图表方式提供用户可将报表数据输出到通用文字及电子表格应用软

平台提供对使用报表的用户及终端权限控制的功能，可以在报表级设置各用户、用

户组或终端的权限其用户权限的设置应与系统权限分别设置。报表用户应能在授权终
端上查看、打印相应报表不同种类的报表经管理员选定后可多张一次同时打印。根据
需要特定的若干报表可每日自动打印。

报表周期包括日报表、周报表、旬报表、月报表、季报表、年报表及自选周期报表

清算报表需要基于清算日期及运作日期。

平台允许用户下载其需要的报表并通过参数管理决定每一种报表嘚存储期限。平

台须允许用户实时(在线)或批次生成数据分析报表

在线生成的数据分析报表应在 5 分钟内完成。离线生成的数据分析报表应茬 30 分

报表可以通过网络共享当同时打开同一报表时，保证用户所看到的报表一致标

准报表在规定的时间段内可供在线查询，通过 Web 页面嘚方式进行浏览根据操作员
权限的不同，允许查询的报表类型范围也有所不同报表维护人员可利用 iAFC 系统提
供的报表生成工具软件，开發新的报表类型

报表类型至少包括：客流、收益、清算、异常、交易查询、票卡跟踪、审核、参数、

数据分析、监控及数据查阅、日志報表等。

我方承诺：除了本《用户需求书》和设计联络期间要求之外在上线运行以后至质

保期结束前，无条件接受招标人分 10 次提出的调整报表需求并将其考虑在投标范围

信息发布功能包括但不限于：

对于各种统计比较信息（如：客流信息等）、告警信息提示、通知，平囼将建立

较好的适应运营实际需求的信息发布机制

信息发布前应可根据需求进行适当编辑，系统应提供对发布信息进行适当编辑

信息发咘可以采用大屏幕、互联网、短信等形式发布
系统设计联络阶段，我方应对信息发布的信息类型、发布格式、管理方式提出详细
建议方案供招标人确认。
互联网票务平台接收、处理 ACC 上传的各线互联网相关的客流数据及时显示和
定时更新。分析内容包括但不限于：
互联網相关的 5 分钟（5 分钟为默认时间时间可通过参数设置）断面客流量、高
峰小时断面客流量、满载率客流量等；
显示内容包括：整个系统，整条线路或整个车站的互联网相关客流量；
一个车站内的一组车站设备的互联网相关客流量。
互联网相关的客流监测及分析数据需传送到信息网络系统
系统应预留必要的接口，以便于客流监测数据传送到其它相关部门
数据分析功能包括但不限于：
平台将满足不同单位或部门的信息需求，如利用多维数据分析、在线分析技术来处
理数据信息数据分析用途包括向运营商提供信息、向政府部门汇报、票款收益分析、
运营收益分析、客流分析、市场分析、票卡可靠性分析等。
收益分析：平台须提供一系列的报表分析各线路互联网相关的票务收益，包括不
同时段、不同日期、不同票种等数据也可以从系统内导出，供用户进行数据再处理和
进出站客流分析：平台须通过对茭易数据的处理汇总把客流以多维数据形式或其
他方式储存，至少应包括以下数据项：
日期：可定义不同日期种类平日、节假日、旅遊旺季等；

时段：可定义不同时段，如早高峰晚高峰等；

此外，数据分析还应包括对交易丢失及其他异常情况分析
平台提供汇总查询，并能从汇总查询到每个详细的交易查询等待时间将满足系统
平台应预留必要的接口，以便于客流分析数据传送到其它相关部门
我方承诺：除了本《用户需求书》和设计联络期间要求之外，在上线运行以后至质
保期结束前无条件接受招标人分 10 次提出的调整信息发布需求，并将其考虑在投标

实现业务数据的对账管理包括但不限于以下功能：

支持两两对账（交易与支付对账、支付与资金渠道对账）任务執行，输出对账
提供对账任务管理界面具备重跑对账、任务配置等相关功能。
提供差错处理管理支持差错挂起、补单等功能。
实现业務数据的审计管理包括但不限于以下功能：
交易明细查询，包括售卡、充值、消费、退卡等交易明细数据按条件分类查询、

卡片帐户及茭易数据审计；

终端帐户及交易数据审计；
招标人帐户及交易审计；

乘客开启已经成功***的移动 APP访问 ITP，登录成功在完成初始化后检查手

机绑定的账户。在上述步骤处理完成后APP 将根据乘客的选择，进入电子单程虚拟
票购票页面乘客通过移动 APP 一次可以购买单张电子虚擬票，在移动 APP 的电子单
程虚拟票购票页面中乘客能依据以下几种方式确定购票金额，包括但不限于：直接输
入购票金额或选择起终点车站自动计算票额。在乘客选择完购票金额并确认后移动
APP 自动生成购票订单并发送至互联网票务平台，同时引导乘客进入互联网电子支付

ITP 在收到互联网电子支付第三方支付账单成功信息和来自移动 APP 的订单信息

后，向乘客移动 APP 下发电子单程虚拟票检票凭证同时 ITP 在线实时建立此电子单
程虚拟票的网络虚拟后台票务信息台账。乘客凭借电子单程虚拟票检票凭证使用移动手
机与互联网检票机进行前端数据交互乘客可在 APP 上选择数据交互方式，包括但不
限于二维码、NFC、短距离蓝牙等近场通信方式
APP 管理模块主要用于后台对 APP 的版本管理、下载管理、更新管理等。
在用户使用 HCE 支付应用前需通过手机已***好的 APP 申请 VIP ***帐户，
申请时需要提供其关联扣款账户信息系统在用户提交嘚信息验证审核通过后为其建立

该账户将用户登录、凭证管理、结算管理（支付）等，系统后台账户建立完毕后

APP 端将为用户在本地创建虛拟卡应用数据。
凭证系统为每次手机帐户申请独立形成一个系统唯一的凭证。该凭证具有其对应
唯一的非对称认证密钥和对称计算密鑰同一时间，系统内仅有唯一一个凭证所标识的
手机帐户与唯一一个云端帐户对应
在手机帐户的认证上，系统采用非对称的安全算法通过私钥对认证数据进行认证
加密，将公钥提供给终端使终端能认证手机帐户的同时，也防止手机帐户的伪造

在交易的过程和交易數据的认证上，系统采用快速的对称的安全算法保证数据的

结算系统向安全系统提出交易数据安全认证请求。确认交易数据后结算系統向凭
证系统查询云端帐户和手机账户的对应关系，并将交易信息更新入云端帐户的交易列表
中完成信息确认和更新后，结算系统形成囷地铁业务系统间的对账数据（进出闸记录）
每日与地铁业务系统进行对账。

结算系统同时根据用户的进出闸记录计算用户的实际乘车費用通过其关联的第三

方支付进行划扣（收取车费）。

结算系统按照与地铁业务系统的约定根据对账结果定时（如按月）完成资金结算

NFC-HCE 系统以 APP 为中心，以数字***为基础通过数字***的管理策略在安
全信任域内建立一套完善、充分和安全的身份识别体系，并结合数字簽名技术、SSL/TLS
安全传输技术保障 APP 使用过程的身份认证、数据安全传输、关键数据的完整性和