DB11 T 159.1-2023 市政交通一卡通系统技术规范 第1部分：总体要求.pdf

1、 ICS 35.240.15 CCS L 64 DB11 北京市地方标准 DB11/T 159.12023 代替 DB11/T 159.12015市政交通一卡通系统技术规范 第 1 部分：总体要求 Technical specification for municipal administration&communications card systemPart 1:General requirements 2023-12-25 发布 2024-04-01 实施北京市市场监督管理局发 布DB11/T 159.12023 I 目 次 前言.II 引言.IV 1 范围.1 2 规范性引用文件.1

2、3 术语和定义.1 4 缩略语.4 5 系统构成.5 6 系统功能要求.6 6.1 总中心计算机处理系统.6 6.2 分中心或运营实体计算机处理系统.8 6.3 终端.8 6.4 卡片.9 6.5 移动支付系统.10 7 安全要求.11 7.1 基本要求.11 7.2 详细要求.11 8 检测要求.11 9 性能指标.11 9.1 总中心计算机处理系统.11 9.2 分中心或运营实体计算机处理系统.11 9.3 终端的通用性能指标.11 9.4 卡片的性能指标.12 10 通信及传输要求.12 10.1 网络连接.12 10.2 网络协议.13 10.3 传输.13 10.4 数据组织结构.1

3、3 11 应用领域和交易模式.14 11.1 应用领域.14 11.2 交易模式.15 附录 A（规范性）卡片初始化流程.16 附录 B（规范性）卡片编码.17 附录 C（规范性）交易类型编码.18 附录 D（规范性）数据包类型.19 附录 E（规范性）数据包数据项.20 附录 F（规范性）交易记录数据项.21DB11/T 159.12023 II 前 言 本文件按照GB/T 1.12020标准化工作导则 第1部分：标准化文件的结构和起草规则的规定起草。DB11/T 159市政交通一卡通系统技术规范分为以下部分：第1部分：总体要求；第2部分：卡片；第3部分：终端；第4部分：移动支付系统；第5部

4、分：安全；第6部分：检测。本文件是DB11/T 159的第1部分。本文件代替DB11/T 159.12015市政交通一卡通技术规范 第1部分：总则，与DB11/T 159.12015相比，除结构调整和编辑性改动外，主要技术变化如下：a)增加了移动支付系统、安全和检测的内容（见第 5 章）；b)更改了标题“系统功能”为“系统功能要求”（见第 6 章，2015 年版的第 6 章）；c)更改了标题“结算清分”为“清分结算”（见 6.1.3，2015 年版的 6.1.3）；d)增加了数据审计的要求（见 6.1.3）；e)增加了对账功能的要求（见 6.1.4）；f)更改了标题“其他功能”为“运营管理”，

5、以及运营管理的要求（见 6.1.6，2015 年版的 6.1.6）；g)更改了标题“充值类终端”为“充值功能”，以及充值功能的要求（见 6.3.2.1，2015 年版的6.3.2.1）；h)更改了标题“消费类终端”为“消费功能”（见 6.3.2.2，2015 年版的 6.3.2.2）；i)更改了标题“服务类终端”为“服务功能”（见 6.3.2.3，2015 年版的 6.3.2.4）；j)更改了标题“退卡类终端”为“退卡功能”，以及退卡功能的要求（见 6.3.2.4，2015 年版的6.3.2.3）；k)删除了卡片的一卡通卡要求（见 2015 年版的 6.4.1）；l)增加了移动支付系统的要求（

6、见 6.5）；m)更改了“安全要求”（见第 7 章，2015 年版的第 9 章）；n)增加了“检测要求”（见第 8 章）；o)更改了总中心计算机处理系统性能指标的单笔交易后台处理速度（联机交易）、最大并发交易处理数（联机交易）和结算准确率要求（见表 1，2015 年版的表 1）；p)更改了标题“终端技术指标”为“终端的通用性能指标”(见 9.3，2015 年版的 7.3)；q)更改了终端的通用性能指标中项目标题“SAM 卡槽”为“SAM”（见表 2，2015 年版的表 2）；r)更改了终端的通用性能指标的卡片识别要求、IC 卡读卡模块、SAM、数据存储、时钟、可靠性和湿度要求（见表 2，201

7、5 年版的表 2）；s)更改了标题“卡片技术指标”为“卡片的性能指标”（见 9.4，2015 年版的 7.4）；t)删除了卡片的性能指标的调制方式要求（见 2015 年版的表 3）；u)更改了卡片的性能指标中项目标题“频率”为“工作频率”、“通信距离”为“读写距离”、“场强”为“工作场强”、“通信波特率”为“通信速率”、“卡片操作系统”为“操作系统”和“卡片 ATQA 响应时间”为“ATQA 响应时间”（见表 3，2015 年版的表 3）；DB11/T 159.12023 III v)更改了卡片的性能指标的读写距离、数据存储容量和操作系统的要求（见表 3，2015 年版的表3）；w)更改了“通

8、信及传输要求”中网络连接、交易类型编码和数据包结构要求（见第 10 章，2015年版的 8 章）；x)更改了数据组织结构中数据包结构要求，拆分为交易文件数据包结构要求及联机交互报文格式要求（见 10.4.4、10.4.5，2015 年版的 8.4.4）；y)删除了业务规范的业务类型要求（见 2015 年版的 10.1）；z)删除了高速公路应用要求（见 2015 年版的 10.2.1.4）；aa)删除了自行车租赁应用要求（见 2015 年版的 10.2.1.7）；bb)删除了业务规范的应用方式要求（见 2015 年版的 10.4）；cc)更改了标题“业务规范”为“应用领域和交易模式”（见第 11

9、 章，2015 年版的第 10 章）；dd)更改了标题“铁路客运应用”为“市郊客运应用”，以及市郊客运应用内容（见 11.1.1.5，2015 年版的 10.2.1.6）；ee)更改了卡片初始化流程图（见附录 A，2015 版的附录 A）；ff)更改了卡号编码为卡片编码，以及卡片编码要求（见附录 B，2015 版的附录 B)；gg)更改了数据包类型要求（见附录 D，2015 年版的附录 D）；hh)更改了数据包数据项要求（见附录 E，2015 年版的附录 E）；ii)更改了交易记录数据项要求（见附录 F，2015 年版的附录 F）。本文件由北京市交通委员会提出并归口。本文件由北京市交通委员会组

10、织实施。本文件起草单位：北京市智慧交通发展中心、北京市政交通一卡通有限公司、北京市标准化研究院。本文件主要起草人员：田旷、陈文革、罗琳、刘敬光、李佳霖、隋莉颖、王海、蒋金煜、刘世俊、李强、杨雪、刘浩、钟园、周湘鹏、许占富、邢钊、曾正喜、李志宇、樊子风、周巧霖、郁国栋、赵立华、张腾、金方伟、魏振阳、李昂、李真丞。本文件及其所代替文件的历次版本发布情况为：2015年首次发布为DB11/T 159.12015市政交通一卡通技术规范 第1部分：总则；本次为第一次修订。DB11/T 159.12023 IV 引 言 随着智慧城市建设的加速和公共交通的快速发展，市政交通一卡通系统在城市交通运营和民生服务中

11、发挥着越来越重要的作用。为了提高城市公共交通运营效率和民生服务质量，满足市政交通一卡通系统的业务发展要求和民生服务需求，需要进行规范化的技术管理，北京市交通委员会组织编制了统一的技术标准。DB11/T 159市政交通一卡通系统技术规范由6个部分组成：第1部分：总体要求。目的在于明确市政交通一卡通系统的整体构成和要求。第2部分：卡片。目的在于明确市政交通一卡通系统卡片的要求。第3部分：终端。目的在于明确市政交通一卡通系统终端的要求。第4部分：移动支付系统。目的在于明确市政交通一卡通系统移动支付系统的组成和要求。第5部分：安全。目的在于明确市政交通一卡通系统安全的要求。第6部分：检测。目的在于明确

12、市政交通一卡通系统检测的要求。DB11/T 159市政交通一卡通系统技术规范参考了国家及地方的相关法规、行业标准和最佳实践，结合北京市公共交通行业特点和发展需求，以及新技术应用等进行了修订，保证标准具有先进性、安全性和指导性，保障市政交通一卡通系统长期、稳定和健康地发展。DB11/T 159.1市政交通一卡通系统技术规范 第1部分：总体要求给出了市政交通一卡通系统的系统构成，并规定了系统功能、安全、检测、性能指标、通信及传输、应用领域和交易模式的要求，适用于市政交通一卡通系统的设计、开发、检测、实施和运营。DB11/T 159.12023 1 市政交通一卡通系统技术规范 第 1 部分：总体要求

13、 1 范围 本文件给出了市政交通一卡通系统的系统构成，并规定了系统功能、安全、检测、性能指标、通信及传输、应用领域和交易模式的要求。本文件适用于市政交通一卡通系统的设计、开发、检测、实施和运营。2 规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 22239 信息安全技术 网络安全等级保护基本要求 JR/T 0025.1 中国金融集成电路（IC）卡规范 第 1 部分：总则 JT/T 978.1 城市公共交通 IC 卡技术规范 第 1 部

14、分：总则 JT/T 978.2 城市公共交通 IC 卡技术规范 第 2 部分：卡片 JT/T 978.6 城市公共交通 IC 卡技术规范 第 6 部分：安全 JT/T 1059.1 交通一卡通移动支付技术规范 第 1 部分：总则 JT/T 1059.6 交通一卡通移动支付技术规范 第 6 部分：可信服务管理系统 DB11/T 159.2 市政交通一卡通系统技术规范 第 2 部分：卡片 DB11/T 159.3 市政交通一卡通系统技术规范 第 3 部分：终端 DB11/T 159.4 市政交通一卡通系统技术规范 第 4 部分：移动支付系统 DB11/T 159.5 市政交通一卡通系统技术规范 第

15、 5 部分：安全 DB11/T 159.6 市政交通一卡通系统技术规范 第 6 部分：检测 3 术语和定义 下列术语和定义适用于本文件。3.1 市政交通一卡通卡 municipal transportation IC card 国家IC卡注册中心注册，北京市指定的发卡机构统一发行，并在市政、交通及其他服务行业应用的IC卡，简称卡片。3.2 市政交通一卡通系统 municipal transportation card system 为市政交通一卡通的应用提供技术支持系统的总和。DB11/T 159.12023 2 3.3 运营实体 operation entity 参与市政交通一卡通系统运营的

16、组织。3.4 发卡机构 card issuer 发行城市公共交通 IC 卡，并对清分结算的跨机构交易数据进行验证的机构。来源：JT/T 978.12015,2.17 3.5 移动支付 mobile payment 用户使用移动支付设备对所消费的服务进行账务支付的一种方式。来源：JT/T 1059.12016,3.2，有修改 3.6 脱机交易 offline transaction 在交易过程中，交易处理全部在终端本地完成的交易。3.7 联机交易 online transaction 在交易过程中，与系统共同完成认证、传输、业务判断和交易处理的交易。3.8 读写器 reader 可以对卡片进行数

17、据交换的设备。3.9 安全单元 secure element 对具有安全认证的交易关键数据的安全存储和运算，且支持多应用管理及运行安全的移动支付安全载体。来源：JT/T 1059.12016,3.12，有修改 3.10 初始化 initialization 由发行机构对卡片或安全单元进行格式化，并写入发行信息的过程。3.11 电子现金应用 the application of electronic cash（EC）电子现金 electronic cash（EC）采用借记/贷记技术设计和非对称和对称密钥结合体系的 IC 卡应用。来源：JT/T 978.12015,2.5 3.12 DB11/T

18、159.12023 3 电子钱包应用 the application of electronic purse（EP）电子钱包 electronic purse（EP）采用对称密钥系统，进行小额消费的城市公共交通IC卡应用。来源：JT/T 978.12015,2.6 3.13 复合应用 complex application 结合电子钱包应用的交通应用模式，适用于使用分时分段扣费、换乘优惠等应用场景。来源：JT/T 978.22023,3.1 3.14 余额 balance 电子钱包内用于消费的可支付金额。3.15 密码算法 cryptographic algorithm 为了隐藏或显现数据信息

19、内容的变换算法。来源：JR/T 0025.12018,3.11 3.16 明文 plaintext 未被加密的信息。3.17 密文 ciphertext 通过密码系统产生的不可理解的文字或信号。3.18 密钥 key 控制加密转换操作的符号序列。来源：JR/T 0025.12018,3.14 3.19 终端 terminal 在交易点安装、用于与卡片配合共同完成交易的设备。应包括接口设备，也可包括其他的部件和接口（如与主机的通讯）。来源：JR/T 0025.12018,3.4，有修改 3.20 授权 authorization 终端通过通信线路向前置系统申请，获得系统认证通过后进行卡片的相关业

20、务。3.21 DB11/T 159.12023 4 认证 authentication 确认一个实体所宣称的身份的措施。来源：JT/T 978.62015,3.7 3.22 证书 certificate 由密钥管理系统使用其私钥对实体的公钥、身份信息以及其他相关信息进行签名，形成的不可伪造的电子数据。来源：JT/T 978.62015,3.8 3.23 可信服务管理 trusted service management 由可信第三方提供的安全载体生命周期管理、应用生命周期管理和应用管理等服务。来源：JT/T 1059.12016,3.18 3.24 安全单元发行方可信服务管理 secure e

21、lement issuer trusted service management 为安全单元发行方提供的承载安全单元生命周期管理服务的可信服务管理。来源：JT/T 1059.12016,3.21 3.25 应用提供方 application provider 提供支付应用的主体。来源：JT/T 1059.12016,3.16 3.26 应用提供方可信服务管理 service provider trusted service management 为用户提供的承载应用生命周期管理服务的可信服务管理。来源：JT/T 1059.12016,3.22 3.27 安全域 security domain

22、负责对某个安全单元外实体（例如安全单元发行方、应用提供方、授权管理者）的管理、安全、通信需求进行支持的安全单元内实体。来源：JT/T 1059.12016,3.14 3.28 客户端 client 用于提供用户接口界面，与安全单元配合实现安全单元管理及应用管理功能的应用软件。来源：JT/T 1059.62016,3.1 4 缩略语 DB11/T 159.12023 5 下列缩略语适用于本文件。ACC：轨道交通 AFC 清算管理中心（AFC Clearing Center）AFC：自动售检票系统（Automatic Fare Collection）ATQA：对 A 型卡请求的应答（Answer

23、To Request，Type A）CSN：芯片序列号（Chip Serial Number）IC：集成电路（Integrated Circuit）IIN：发行机构注册识别码（Institution Identification Number）MTBF：平均无故障工作时间（Mean Time Between Failure）NVM：非易失性存储器（Nonvolatile Memory）PCD：接近耦合设备（Proximity Coupling Device）SAM：安全认证模块（Secure Authentication Module）SE：安全单元（Secure Element）SE-TSM

24、：SE 发行方可信服务管理（SE Issuer Trusted Service Management）SP-TSM：应用提供方可信服务管理（Service Provider Trusted Service Management）SSD：辅助安全域（Supplementary Security Domain）TAC：交易验证码（Transaction Authorization Code）TCP/IP：传输控制协议/网际协议(Transmission Control Protocol/Internet Protocol)TSM：可信服务管理（Trusted Service Management）

25、UDP：用户数据报协议（User Dataprogram Protocol）5 系统构成 市政交通一卡通系统由总中心计算机处理系统、分中心或运营实体计算机处理系统、终端、卡片和移动支付系统构成。移动支付系统由TSM系统、客户端软件和SE组成。总中心计算机处理系统与分中心或运营实体计算机处理系统、TSM系统进行数据交互，主要负责对收集的各类交易数据进行合法性、完整性验证，根据交易验证结果进行清分结算和数据统计，生成各类运行参数及对账数据,下发至分中心或运营实体计算机处理系统、TSM系统。终端或客户端软件作为入口，通过数据接口，完成各类数据上送功能。卡片和SE作为支付介质，通过终端或客户端软件完成

26、各业务功能。通过密钥安全机制和密码算法，保障市政交通一卡通系统各环节整体安全性。依据统一的技术标准、业务流程，以及质量检测要求，确保系统内各部分规范性、稳定性和可靠性。市政交通一卡通系统架构如图 1 所示：DB11/T 159.12023 6 安全检测总中心计算机处理系统分中心或运营实体计算机处理系统终端卡片TSM系统客户端软件SE移动支付系统 图1 市政交通一卡通系统架构 6 系统功能要求 6.1 总中心计算机处理系统 6.1.1 接入与传输 应能为内外部相关系统提供业务接入、数据通讯和数据交互服务等功能，具体要求如下：a)为各业务终端、分中心或运营实体计算机处理系统（采集点、分中心）、清算

27、银行和其他外部相关系统提供脱机或联机业务的功能及通讯接入，具备终端或接入平台进行合法性检查功能；b)接收业务终端、分中心或运营实体计算机处理系统的各类交易数据、终端状态信息和日志数据；c)将结算统计数据、业务对帐数据、系统运行参数数据和运行管理数据发送到分中心或运营实体计算机处理系统。6.1.2 业务处理 应能实现卡片初始化、包级合法性检查、交易合法性验证、终端管理、联机交易服务和异常业务处理等功能，具体要求如下：a)卡片初始化：包括创建卡片数据结构、写入密钥和发行商标识及卡片发行相关信息，只有经过初始化的卡片才可在市政交通一卡通系统中使用。卡片初始化流程符合附录 A 要求；b)包级合法性检查

28、：系统对上传的数据包进行合法性检查，主要包含：包接收单位有效性检查、包类型有效性检查、包重复性检查、包格式有效性检查、包完整性检查和包版本有效性检查等；c)交易合法性验证：系统对上传的交易记录进行合法性检查，主要包括：数据格式检查、重复性检查、逾期检查、卡片账户和黑名单检查等，验证各类交易记录的 TAC；d)终端管理：系统对终端进行管理，包括为终端提供联机授权认证、参数下载功能；DB11/T 159.12023 7 e)联机交易服务：具备为联机交易提供交易认证、后台合法性检查和交易处理的功能，包括：开卡、发售、充值、消费、退卡退资、激活、查询和卡片迁卡等联机交易；f)异常业务处理：具备终端、卡

29、片账户和交易记录等异常数据处理的功能。6.1.3 清分结算 应能实现清分结算、查询统计、数据分析和数据审计等功能，具体要求如下：a)结算对帐：完成总中心计算机处理系统收到的各类交易数据的清分，并产生资金结算数据和报表，完成与分中心或运营实体的数据对帐，并生成划账信息；b)查询统计：具备交易数据分类查询统计的功能；c)数据分析：具备对交易数据、历史数据和各类统计数据分析的功能；d)数据审计：具备对交易数据及结算数据完整性的审核功能。6.1.4 综合管理 应能实现操作员管理、授权额度管理、报表和对账等功能，具体要求如下：a)操作员管理：设置、管理和维护总中心计算机处理系统的操作员及权限的管理功能；

30、b)授权额度管理：对具有发售充值功能的终端、商户、分中心或运营实体实现后台交易额度的控制和管理；c)报表功能：提供查询、分析和统计数据的报表功能；d)对账功能：提供总中心计算机处理系统与分中心或运营实体计算机处理系统资金的对帐、划账功能。6.1.5 基础数据管理 应能实现卡片账户管理、参数管理、黑名单管理、分中心或运营实体管理和终端信息管理等功能，具体要求如下：a)卡片账户管理：具备卡片账户管理及维护的功能；b)参数管理：对总中心计算机处理系统的运行参数进行管理和维护；应对分中心或运营实体运营参数进行管理和维护；c)黑名单管理：具备黑名单的收集、生成、跟踪、下发和维护的功能；d)分中心或运营实

31、体管理：对分中心或运营实体基础信息进行管理及维护，包括：行业、单位、商户和网点结算手续费率等；e)终端信息管理：对终端基础信息进行管理及维护，包括终端基本信息管理、参数维护、状态监控和额度控制等。6.1.6 运营管理 能实现风险管理、行为审计、监控和数据挖掘等功能，具体要求如下：a)风险管理：支持对联机交易、脱机交易进行风险控制；b)行为审计：支持对交易数据进行审计，以及时发现异常的交易数据或交易行为；c)监控：具备网络状态、设备运行状态、物理环境和数据传输状态监控等功能；d)数据挖掘：可支持对历史累计数据进行统计分析，深度挖掘潜在信息。6.1.7 备份与恢复 应具备各类交易数据、结算统计数据

32、、系统运行参数、管理数据等存储、备份和恢复功能。应建设总中心计算机处理系统的容灾备份系统，以保障灾难发生时的业务连续性和数据完整性。DB11/T 159.12023 8 6.2 分中心或运营实体计算机处理系统 6.2.1 数据采集 应及时、完整采集所属范围内终端的各类交易数据。6.2.2 数据传输 应将各类交易数据发送到总中心计算机处理系统，并具备重传功能。应接收总中心计算机处理系统的结算统计数据、业务对帐数据、系统运行参数数据和运行管理数据，并能将黑名单、相关参数及时发送到分中心或运营实体计算机处理系统及系统内的所有终端。6.2.3 数据接口 应按总中心计算机处理系统的数据组织结构要求实现数

33、据接口。6.2.4 数据结算及对帐 应实现分中心或运营实体内交易数据的清分，并能完成分中心或运营实体内资金结算。应实现与总中心计算机处理系统结算数据的对帐和异常数据处理。应实现对分中心或运营实体内交易数据及统计数据完整性的审核功能。6.2.5 数据存储 应具备各类交易数据、结算统计数据、系统运行参数数据、运行管理数据的存储、备份和恢复功能。6.3 终端 6.3.1 终端应用通用要求 符合 DB11/T 159.3 中的相关要求，具体功能要求如下：a)应满足市政交通一卡通系统的运营要求，功能具有可扩展性；b)应能实现总中心计算机处理系统各类参数的下载，包括通讯类参数、业务类参数和管理类参数等；c

34、)应能实现总中心计算机处理系统黑名单参数实时下载；d)应依据总中心计算机处理系统下载的各类参数进行准确的业务判断，对黑名单卡须进行锁卡；e)应依据业务规则对卡片进行处理，交易成功后应生成符合市政交通一卡通系统格式标准的交易数据；f)应保证各类交易数据的完整性、准确性；g)应保证卡片内数据的完整性；h)应保证卡片内敏感信息的安全性；i)同一终端的不同应用之间不应互相影响；j)宜支持在线升级功能；k)应支持交易数据查询、数据采集和数据上传功能。6.3.2 终端业务功能要求 6.3.2.1 充值功能 至少实现以下功能：a)应具有发售、充值和激活功能；DB11/T 159.12023 9 b)应支持在

35、线配置业务功能；c)应实现不同权限控制；d)发售、充值和激活交易应采用联机方式进行；e)交易数据应实时上传总中心计算机处理系统；f)根据业务需求，可与其他业务功能进行组合应用。6.3.2.2 消费功能 至少实现以下功能：a)应具有消费、缴费功能；b)消费交易可采用脱机方式进行，对于安全性要求较高的行业及应用，应采用联机方式进行；c)交易数据应及时上传总中心计算机处理系统；d)根据业务需求，可与其他业务功能进行组合应用。6.3.2.3 服务功能 至少实现以下功能：a)应具有查询、补票和修复功能；b)交易数据应及时上传总中心计算机处理系统；c)根据业务需求，可与其他业务功能进行组合应用。6.3.2

36、.4 退卡功能 至少实现以下功能：a)应具有退卡、退资功能；b)应支持在线配置业务功能；c)应实现不同权限控制；d)退卡、退资交易应采用联机方式进行；e)交易数据应实时上传总中心计算机处理系统；f)根据业务需求，可与其他业务功能进行组合应用。6.4 卡片 6.4.1 应用类型 应用类型编码应支持 256 种类型。6.4.2 发售 已初始化的卡片，应在授权的终端上发售。6.4.3 充值 已发售的卡片，应在授权的终端上充值，使用过程中可多次充值。6.4.4 消费 已充值的卡片，应在一卡通应用领域的终端上缴费。6.4.5 服务 DB11/T 159.12023 10 在使用过程中，应在授权的终端上办

37、理查询、补票、修复和激活等服务业务。锁定后的黑名单卡不能再使用。6.4.6 退卡 在使用过程中，若卡片出现故障不能继续使用，或持卡人终止卡片使用，应在授权的终端上办理退卡或退资业务。6.4.7 回用 对回收后的卡片，应在授权的终端上进行分拣、处理后，进行重新使用。总中心计算机处理系统应对回用卡片的后台信息进行核销，并进入初始状态。6.4.8 销毁 对回收的卡片，应在授权的终端或系统上进行分拣、并对不能再次使用的卡片进行销毁。总中心计算机处理系统应对销毁卡片的后台信息进行核销。6.5 移动支付系统 6.5.1 可信服务管理系统 TSM 系统由 SE-TSM 和 SP-TSM 组成，应符合 DB1

38、1/T 159.4 中的相关要求，应至少实现以下功能：a)机构接入；b)应用注册；c)SE 可信管理；d)SE 开放共享；e)SE 载体管理；f)多应用管理；g)应用管理。6.5.2 客户端软件 应符合DB11/T 159.4中的相关要求，应至少实现以下功能：a)注册；b)开卡；c)充值；d)消费；e)退卡；f)迁卡；g)默认应用设置；h)信息查询；i)密码管理；j)版本升级。6.5.3 安全单元 应符合DB11/T 159.4中的相关要求，应至少实现以下功能：a)为移动支付各参与方提供 SE 信息；DB11/T 159.12023 11 b)为应用提供方提供 SSD 管理、移动支付应用下载授

39、权等功能；c)负责存储密钥、证书等机密信息，进行密码计算。7 安全要求 7.1 基本要求 7.1.1 系统安全不应低于 GB/T 22239 中第三级的相关要求。7.1.2 终端应正确生成和完整保存交易数据，并将交易数据实时上传至总中心计算机处理系统，交易数据应包含 TAC。7.1.3 卡片应采用一卡一密的密钥管理体系，对称密钥采用两级密钥管理体系，分别为城市分散密钥、卡片分散密钥。7.1.4 交易验证应通过内置在终端的 SAM 卡或总中心计算机处理系统实现。7.2 详细要求 详细要求应符合DB11/T 159.5中的相关要求。8 检测要求 检测要求应符合DB11/T 159.6中的相关要求。

40、9 性能指标 9.1 总中心计算机处理系统 总中心计算机处理系统性能指标应满足表 1 的要求。表1 总中心计算机处理系统性能指标 项目 指标 清分结算处理性能 每小时 1000 万笔交易 单笔交易后台处理速度（联机交易）1 秒 最大并发交易处理数（联机交易）5000 笔 结算准确率 100%系统平均无故障时间 8751 小时 各类统计数据保存时间 10 年 交易数据保存时间 在线保存2 年，离线永久保存 9.2 分中心或运营实体计算机处理系统 分中心或运营实体计算机处理系统性能指标根据系统的应用规模和级别，可参照总中心计算机处理系统性能指标。9.3 终端的通用性能指标 终端的通用性能指标应满足

41、表 2 的要求。DB11/T 159.12023 12 表2 终端的通用性能指标 项目 指标 卡片识别要求 应识别符合 DB11/T 159.2 的卡片 SAM 支持不少于 4 个 SAM 卡，其中不少于 2 个使用卡座支持 IC 卡读卡模块 可支持 0mm100mm，应无盲区 数据存储 交易数据存储容量 8MB 黑名单容量 5MB 存储器寿命 10 年 时钟 支持时钟同步，误差1 秒/日，校准时钟频次间隔不低于 1800 秒 可靠性 除非特殊部件另有规定，MTBF 不低于 10,000 小时 温度 存储温度-4070 工作温度-2070 湿度 存储湿度 5%95%（非凝露）工作湿度 10%9

42、5%（非凝露）使用寿命 5 年 9.4 卡片的性能指标 卡片的性能指标应满足表 3 的要求。表3 卡片的性能指标 项目 指标 工作频率 13.56MHz7kHz 读写距离 卡片与读写器之间感应距离在 0mm100mm 应正常通信 工作场强 当 PCD 组件的激励频率为 13.56 MHz，场强最小为 1.5A/m 最大为 7.5A/m 时，卡应正常应答 通信速率 卡片与读写器之间采用半双工通讯协议，其最低通信速率规定为 106kbps 或 106kbps 的倍频 数据存储容量 芯片内 NVM 的数据容量支持电子钱包应用的数据空间不应小于 20kB，支持电子现金应用的数据空间不应小于 10kB，

43、并应预留足够存储空间，用于应用扩展 芯片使用寿命 芯片内 NVM 的擦写无故障次数不应少于 10 万次，数据存储保证 10 年不丢失 操作系统 卡片操作系统符合 JT/T 978.2 的相关要求 ATQA 响应时间 卡片在进入天线感应区后，ATQA 响应的时间应小于 3ms 10 通信及传输要求 10.1 网络连接 总中心计算机处理系统和分中心或运营实体计算机处理系统、移动支付系统网络连接具体要求如下：a)总中心计算机处理系统和分中心或运营实体计算机处理系统之间应统一规划，采用安全、可靠的网络实现，可使用各种电信运营商提供的专线，相互之间也可建立 VPN 专用网络；b)总中心计算机处理系统和分

44、中心或运营实体计算机处理系统之间的网络连接的带宽应满足数据传输的要求；DB11/T 159.12023 13 c)总中心计算机处理系统和分中心或运营实体计算机处理系统之间的网络物理连接应有备份线路；d)总中心计算机处理系统和移动支付系统可通过局域网、专线实现；e)直接与总中心计算机处理系统连接的设备 IP 地址应统一规划和分配，并支持 IPV6。10.2 网络协议 总中心计算机处理系统和与其连接的计算机系统、终端之间的数据传输协议应至少支持TCP/IP协议或UDP协议。10.3 传输 总中心计算机处理系统和分中心或运营实体计算机处理系统间传输要求如下：a)计算机处理系统相互之间的数据传输应基于

45、统一的应用层通信接口；b)计算机处理系统相互之间的数据传输在应用层应符合 10.4.4、10.4.5 格式的要求；c)数据包内最大交易记录的数量不应超过 65535 条记录；d)发送到总中心计算机处理系统的数据包的传输时间、间隔可通过参数设置。10.4 数据组织结构 10.4.1 卡片编码 市政交通一卡通系统发行的每张卡片应设置唯一的编码，编码规则应符合附录 B 要求。10.4.2 运营实体 市政交通一卡通系统中的每个运营实体应设置唯一的编码。10.4.3 交易类型编码 主要交易类型包括开卡、发售、充值、消费、补票、锁卡、退卡、退资和激活等，并可根据应用的需要进行扩展。应支持 256 种交易应

46、用。已定义的主要交易类型编码应符合附录 C 要求。10.4.4 交易文件数据包结构 交易文件数据包格式应符合下列要求：a)数据包结构包括包头和包体两部分；b)包头包括公共部分和个性类型；c)包体包括若干条数据记录和个性化信息。交易文件数据包结构如图2所示：公共部分个性类型第一条记录第N条记录包头包体个性化信息个性化信息 图2 交易文件数据包结构图 DB11/T 159.12023 14 10.4.5 联机交互报文格式要求 联机交互报文格式应符合以下要求：a)交互报文由消息包头、消息包体和签名数据三部分组成；b)消息包头分为包长度、同步信息和压缩算法标志三部分；c)消息包体包含明文部分和密文部分

47、。联机交互报文格式如图 3 所示：包长度同步信息压缩算法包体明文包体密文签名数据消息包头消息包体签名数据 图3 联机交互报文格式 10.4.6 数据包类型 总中心计算机处理系统接收及下发的数据包类型包括管理数据、黑名单数据、各类参数、各类交易数据和统计对帐数据等。数据包类型应符合附录D要求。10.4.7 数据包数据项 数据包的数据内容包含数据包版本号、数据包编号、产生时间、发送方编码、接收方编码、数据包中记录的数量和数据包长度等，数据项应符合附录E要求。10.4.8 交易记录数据项 交易记录的数据项应符合附录 F 要求。11 应用领域和交易模式 11.1 应用领域 11.1.1 交通领域 11

48、.1.1.1 公共汽电车应用 通过车载、壁挂或手持式等终端，应实现公共汽电车单一票制、分段票制和计次票制等缴费要求。11.1.1.2 城市轨道应用 应与城市轨道交通 ACC/AFC 结合，以储值票或计次票的方式，实现轨道交通计程、计时缴费要求。11.1.1.3 出租汽车应用 应与出租汽车收费终端相结合，实现出租汽车缴费的要求。11.1.1.4 停车场应用 DB11/T 159.12023 15 能与封闭式停车场和路侧停车场的消费终端结合，实现停车场缴费的要求。11.1.1.5 市郊客运应用 应与市郊客运消费终端结合，实现市郊客运交通缴费要求。11.1.2 市政领域 11.1.2.1 水、电、气

49、缴费应用 应实现供水、供电、供气和供热应用缴费的要求。11.1.2.2 公园及旅游景点应用 应实现公园及旅游景点缴费的要求。11.1.2.3 文化体育场馆应用 应实现文化体育场馆缴费的要求。11.1.2.4 公共电话亭 应实现拨打公共电话缴费的要求。11.1.3 商业应用领域 应通过市政交通一卡通系统终端或与系统兼容的终端，实现超市、商场、连锁店、书报亭、菜市场和快餐店等应用的要求。应实现网络缴费的要求。11.1.4 信息管理领域 应与楼宇、酒店、校园、企业和园区等管理系统相结合，实现将卡片作为身份识别及信息管理介质的要求。11.2 交易模式 11.2.1 脱机交易 在交易过程中，终端可不与后

50、台进行实时通信，终端和卡片之间的密钥认证、数据传输、业务判断和处理全部在终端本地完成，交易记录数据暂存在终端内部的数据存储区内，定时或定期上传至总中心计算机处理系统进行清分结算。脱机交易模式宜用于网络实时通讯较为困难，且要求快速通行的交通领域，如公共汽电车、城市轨道和出租汽车等。11.2.2 联机交易 在交易过程中，终端应与后台进行实时通信，密钥认证、数据传输、业务判断和处理，由终端、总中心计算机处理系统、卡片共同完成，交易记录数据应实时上传至总中心计算机处理系统进行清分结算。联机交易模式宜用于网络条件较好、交易安全性要求较高的行业及应用，如：开卡、发售、充值、退卡和退资类交易，部分消费类交易