天津市城市轨道交通自动售检票
系统技术标准
Technical standard for automatic fare collection system of urban rail transit in Tianjin
2026-1-21 发布 2026-6-1 实施
天津市工程建设标准
天津市城市轨道交通自动售检票系统
技术标准
Technical standard for automatic fare collection system of urban rail transit in Tianjin
DB/T29-231-2026
J12940-2026
主编部门：天津轨道交通线网管理有限公司
批准部门：天津市住房和城乡建设委员会
实施日期：2026 年 6 月 1 日
天津市住房和城乡建设委员会
津住建设函〔2026〕5 号
市住房城乡建设委关于发布《天津市城市轨道交
通自动售检票系统技术标准》的通知各有关单位：
根据《市住房城乡建设委关于公布 2020 年度天津市工程建设地方标准复审结果的通知》 (津住建设〔2021〕21 号)要求，天津轨道交通线网管理有限公司等单位修订完成了《天津市城市轨道交通自动售检票系统技术标准》 ，经市住房城乡建设委组织专家评审通过，现批准为天津市工程建设地方标准，编号为 DB/T 29-231-2026 ， 自 2026 年 6 月 1 日起实施。原《城市轨道交通自动售检票系统技术标准》(DB/T29-231-2015)同时废止。
各相关单位在实施过程中如有意见和建议，请及时反馈给天津轨道交通线网管理有限公司。
本标准由天津市住房和城乡建设委员会负责管理， 由天津轨道交通线网管理有限公司负责具体技术内容的解释。
天津市住房和城乡建设委员会
2026 年 1 月 21 日
前 言
根据《市住房城乡建设委关于公布 2020 年度天津市工程建设地方标准复审结果的通知》 (津住建设[2021]21 号)文件要求，结合天津轨道交通的实际情况，修订《城市轨道交通自动售检票系统技术标准》(DB/T29-231-2015)。
本标准代替《城市轨道交通自动售检票系统技术标准》 (DB /T 29-231-2015)，与原标准相比，除编辑性修改外主要技术变化如下：
——增加了基本规定(见第 3 章);
——增加了系统架构(见第4 章);
——修改了系统编码定义(见第 5 章);
——修改了通信接口定义(见第 6 章) ，补充自定义结构体定义(见第 6 章);
——修改了交易数据定义 ，新增票卡交易结构体(见第 7章);
——修改了系统参数定义 ，新增 CPU 卡管理参数(见第 8章);
——删除了单程票技术要求(DB/T 29-231-2015 第 7 章);
——修改了附录 A 设备状态定义;
——删除了附录 B 通用算法说明;
——删除了附录 C 单程票检测方法。
本标准的主要技术内容用于指导天津城市轨道交通自动售检票系统的设计、开发、测试、系统联通。标准共设 8 章，包括：总则、术语和缩略语、基本规定、系统架构、系统编码定义、通
信接口定义、交易数据定义、系统参数定义。
本标准由天津市住房和城乡建设委员会负责管理， 由天津轨道交通线网管理有限公司负责具体技术内容的解释。执行过程中如有意见和建议，请反馈至天津轨道交通线网管理有限公司(地址：天津市西青区才智道 36 号，邮编：300392)
本 标 准 主 编 单 位 ：天津轨道交通线网管理有限公司
本 标 准 参 编 单 位 ：天津市地下铁道集团有限公司
天津轨道交通运营集团有限公司
本标准主要起草人员：徐道强 王宇嵚 李荫楼 程海鹏齐 麟 杨从鹏 陈 云 夏宝山朱 伟 田 澜 田淑玉 段艳丽谢卫华 邱旭亮 张立鹏 李 娜李 博 李唯珂 贺小鹏 姚禹铭赵银柏
本标准主要审查人员：冯进峰 张 标 于喜林 朱咏辉郭华军 赵 峰 杨艳君 张 挺
1 总 则
1.0.1 为满足天津城市轨道交通线路网络化发展的需求，规范天津
市自动售检票系统工程建设，实现轨道交通多线路互联互通，特制订本标准。
1.0.2 本标准适用于天津市行政区域范围内的轨道交通自动售检票
系统的设计、开发、建设、运营及更新改造，市域铁路参照本标准执行。
1.0.3 应天津城市轨道交通运营需要而开发，在轨道交通路网内互
联互通的其他自动售检票系统，也应符合本标准的相关规定。
1.0.4 天津城市轨道交通自动售检票系统的建设除应符合本标准的
规定外， 尚应符合现行国家及本市有关标准的规定。
2 术语和缩略语
2. 1 术 语
2.1.1 自动售检票系统 Automatic Fare Collection System
基于计算机、通信网络、 自动控制、 自动识别、精密机械和传动等技术，实现城市轨道交通售票、检票、计费、收费、统计、清分、管理等全过程的自动化系统。
2.1.2 线网中心系统 AFC Network Control Center System
用于向所管辖范围内所有线路的自动售检票系统提供清分清算、票卡发行、智能化票务、线网标准化终端设备管理、生物识别票务应用服务，且具有线网唯一特性的线网级系统，包含清分中心系统(ACC) 、智能支付系统(SPT) 、线网标准化终端设备管理云平台(IMT)、线网人工智能生物识别管理系统(AIS)。
2.1.3 清分系统 AFC Central Clearing System
用于发行和管理城市轨道交通专用车票，对不同线路的票款
以及城市轨道交通线网内其他车票的使用消费进行清分和结算，并具有与一卡通公司进行清算功能的线网级中心平台信息系统。
2.1.4 智能支付系统 Smart Payment Technology System
提供电子虚拟票管理、用户管理、行程管理、支付管理、优惠管理等功能的线网级中心平台信息系统。
2.1.5 线 网标 准化 终端 设 备 管 理 云平 台 Integrated Ticketing
Management Technology Platform
提供标准化 BOM 和 iBOM 设备业务交互、交易管理、通信管理、参数管理、权限管理、监控管理、库存管理、结算管理、票务管理等功能的线网级中心平台信息系统。
2.1.6 线网人工智能生物识别管理系统 AI System
提供生物识别电子票管理功能的线网级中心平台信息系统。
2.1.7 线路中央计算机系统 Line Central Computer System
管理和控制城市轨道交通单线路或多线路自动售检票系统的信息系统。
2.1.8 车站计算机系统 Station Computer System
管理车站票务、运行、客流统计的信息系统。
2.1.9 车站终端设备 Station Level Equipment
用于售票、检票、退票、补票、充值和查询等交易处理的车站设备。
2.1.10 自动售票机 Ticket Vending Machine
用于现场自助发售、赋值有效车票，具备自动处理支付和找零功能的车站终端设备。
2.1.11 半自动售票机 Booking Office Machine
用于现场人工辅助发售、赋值有效车票，具备补票、退票、查询、更新等票务处理功能的车站终端设备。
2.1.12 非现金自动售票机 Ticket Fetching Machine
用于现场自助发售、赋值有效车票，具备自动处理非现金支付的车站终端设备。
2.1.13 自动检票机 Automatic Gate Machine
对车票进行自动检验和处理，放行或阻挡乘客出入付费区的车站终端设备。
2.1.14 自助票务服务终端 Intelligent Booking Office Machine
提供自助票务服务的车站终端设备。
2.1.15 便携式检验票机 Portable Card Analyzer
对乘客使用的车票进行检票和验票的移动终端设备。
2.1.16 票卡读写器 Ticket Reader-Writer
对车票的发售、检票、充值和验票分析作读写处理的设备。
2.1.17 二维码扫描器 QR Code Scanner
通过扫描读取二维码，并将解码后的二进制数据发送给读写器的设备。
2.1.18 单程票 Single Journey Ticket
在限定时间内一次性使用的车票。
2.1.19 储值票 Storage Value Ticket
能重复充值使用的车票。
2.1.20 非接触式 IC 卡 Contactless IC Card
无触点的集成电路卡。
2.1.21 "一卡通"车票 Multi Pass Card
由外部发卡公司发行的能储值金额，并能在轨道交通线网内使用的车票。
2.1.22 黑名单 Black List
根据管理要求对异常车票进行特殊控制的数据列表。
2.1.23 白名单 White List
根据管理要求对许可车票进行特殊控制的数据列表。
2.1.24 付费区、非付费区 Pay Area 、Non-Pay Area
付费区是指在车站内进站检票机与出站检票机及护栏之间的封闭区域，包括站厅、站台密封区、运营的列车车厢内区域等;
非付费区是指付费区以外的区域。
2.2 缩 略 语
表 2.2缩略语定义
续表2.2缩略语定义
3 基本规定
3.0.1 城市轨道交通自动售检票系统应具备安全性、可靠性、可
用性、可维修性及可扩展性，应采用成熟、先进、安全的技术方案，并满足轨道交通及 AFC 行业的发展要求。
3.0.2 城市轨道交通自动售检票系统宜融合大数据、互联网、人工智能等智慧化技术，应满足智慧票务应用要求。
3.0.3 城市轨道交通自动售检票系统应实现轨道交通线网范围内
一票通、一卡通及一码通的票务应用，宜支持跨城市轨道交通制式的票务应用。
3.0.4 城市轨道交通新建线路的自动售检票系统既应充分兼容线
网既有的票制和票务功能，也应该支持地铁公交联程优惠、站外换线联程优惠、站外换乘等特殊票务服务功能。
3.0.5 与轨道交通线网互联互通一票换乘的线路自动售检票系统
均应接入线网中心系统以及后继建设的具有线网属性的线网中心系统。
3.0.6 城市轨道交通自动售检票系统应执行线网AFC 标准化要求，线网标准化的设备及软件宜接入 IMT 统一管理。
3.0.7 城市轨道交通应设置统一的线网清分系统，具备线网清分
清算、实体票卡及虚拟票卡发行、密钥管理、数据管理、运营参数管理、时钟管理等功能。
3.0.8 城市轨道交通应设置统一的线网智能支付系统，具备线网
虚拟票卡/码的账户管理、行程管理、支付管理、安全管理功能以及线网非现金支付接口功能。
3.0.9 城市轨道交通应设置统一的线网人工智能生物识别管理系
统，结合运营要求宜具备人脸生物识别电子票管理、安全管理功能，鼓励开展掌静脉、指纹等其他人工智能生物识别研究。
3.0.10 城市轨道交通自动售检票系统线路中央系统应具备系统管理、数据管理、运营管理、线路中央业务管理功能。
3.0.11 城市轨道交通自动售检票系统车站计算机系统应具备系统管理、数据管理、运营管理、车站业务管理功能。
3.0.12 车站终端设备种类及数量配置应满足乘客购票、检票、验
票、补票及引导等服务需求。车站终端设备宜满足标准化及互换性需求。
3.0.13 自动售检票系统终端设备交易数据应同时支持 Socket 实时上传和 FTP 交易文件传输两种方式。
3.0.14 自动售票机应具备单程票发售功能，可支持纸质二维码单程票发售功能。
3.0.15 自动检票机应支持单程票检票、回收，储值票检票，二维
码及 NFC 虚拟卡等电子票检票，生物识别电子票检票功能，可按照运营要求配置一定比例全功能闸机和仅支持部分票种的新型闸机。
3.0.16 半自动售票机应支持票卡分析、更新、补票、票卡发售、
储值票充值、二次发行及年检等常规票务功能，也可支持信息查询、非现金退票提示等客服辅助功能。
3.0.17 自助票务服务终端应安装于车站付费区和非付费区，支持
自助票卡分析、更新、补票、纸质或电子票卡发售、 自助充值、二次发行及年检等业务，应支持自助信息查询等辅助服务功能。
3.0.18 城市轨道交通自动售检票系统票卡读写设备应符合线网标准化相关要求。
3.0.19 城市轨道交通车票应包括实体票和虚拟票，虚拟票宜包括NFC 模拟卡、二维码票和生物特征票等。
3.0.20 城市轨道交通自动售检票系统应支持现金、非现金等多元化支付方式。
3.0.21 新建线路自动售检票系统接入线网前应完成线网互联互通
测试环境测试及生产环境测试。应由线网中心系统管理单位开展接入技术评估、票务评估、清算对账评估。
3.0.22 城市轨道交通线路级系统自动售检票系统信息安全等级保
护应符合现行国家标准《信息安全技术 网络安全等级保护基本要求》GB/T22239 和《信息安全技术 网络安全等级保护安全设计技术要求》GB/T25070 的规定，ANCC 网络安全等级保护不应低于三级，LCC 和 SC 网络安全等级保护不应低于二级。
4 系统架构
4.0.1 城市轨道交通自动售检票系统的逻辑架构、网络架构和业务架构应符合本标准要求。
4.0.2 城市轨道交通自动售检票系统逻辑架构应分为五个层次。
第一层为车票/票卡读写设备;第二层为车站终端设备;第三层为车站计算机系统;第四层为线路中央计算机系统;第五层为轨道交通线网中心系统。
4.0.3 城市轨道交通自动售检票系统网络架构应根据线网建设规
模、建设规划及运营管理模式设置不同的网络架构。LCC 宜设置多线路中央计算机系统或区域多线路中央计算机系统 ， 宜将ANCC 与 LCC 融合设置，可将 ANCC 、LCC 、SC 融合设置。
4.0.4 城市轨道交通自动售检票系统业务架构分为设备管理业务、票务业务和数据业务，可结合具体业务灵活设置。
4.0.5 城市轨道交通自动售检票系统架构应符合图 4.0.5 规定：
图 4.0.5 城市轨道交通自动售检票系统架构
4.0.6 设备管理业务可由线路中央计算机系统、车站计算机系统
承担，也可根据业务需要按照二层架构方式由线网中心系统承担，并向线路及车站开放设备管理操作功能。
4.0.7 票务业务应具备灵活性和可扩展性，应按照票卡读写设备
至线网中心系统二层执行，宜根据业务需要增加降级业务承担层，降级业务宜由车站计算机系统承担。
4.0.8 车站计算机系统、线路中央计算机系统应具备采集票务业务数据的能力。
4.0.9 车站终端设备的票务业务应由线网标准化票卡读写设备承担。
4.0.10 城市轨道交通自动售检票系统应严格保障系统安全、网络
安全，应由线网中心系统统一与第三方支付平台及一卡通本地或跨区域结算系统及其他外部系统对接。
4.0.11 线网中心系统应设置主中心、灾备中心和互联互通测试中心，互联互通测试中心可多系统合并设置。
4.0.12 线路中央计算机系统应设置主中心，可设置灾备中心，并
在线网互联互通测试中心设置线路级测试设备，测试设备应满足全功能测试要求。
4.0.13 线网中心系统应结合业务扩展及线路 AFC 系统接入，及时开展线网中心系统扩容、更新、改造。
4.0.14 线网中心系统、线路中央计算机系统、车站计算机系统的
物理运行平台应具备稳定可靠、可扩展性，可采用云平台、虚拟化等新技术。
5 系统编码定义
5. 1 通用定义
5.1.1 本标准编码格式分为 XDR 和自定义结构体。
5.1.2 XDR 编码采用大端字节序，所有数据类型采用 4 的倍数字节。
5.1.3 XDR 基础数据格式应符合 INETRNET 通用协议中 XDR数据协议 RFC1832 的规定。
5.1.4 自定义结构体的报文和文件以相应报文及文件中定义的结构和类型为准。
5.2 核心基本数据
5.2.1 核心基本数据定义应符合表5.2. 1的规定：
表 5.2. 1 核心基本数据
续表5.2. 1 核心基本数据
5.3 系统基本数据
5.3.1 消息类型代码字段 MessageType_t 应符合以下规定：
1 定义方式：TypedefU16_t MessageType_t;
2 取值方式：按照表5.3. 1固定取值;
3 取值范围定义：取值范围应符合表5.3. 1的规定。
表 5.3. 1 MessageType_t 取值范围定义
续表 5.3. 1 MessageType_t 取值范围定义
续表 5.3. 1 MessageType_t 取值范围定义
5.3.2 交易类型字段 TransactionType_t 应符合以下规定：
1 定义方式：TypedefU8_t TransactionType_t;
2 取值方式：按照表 5.3.2- 1 和 5.3.2-2 固定取值;
3 取值范围定义：取值范围应符合表5.3.2- 1 和 5.3.2-2 的规定。表 5.3.2- 1 TransactionType_t 取值范围定义
续表 5.3.2- 1 TransactionType_t 取值范围定义
续表 5.3.2- 1 TransactionType_t 取值范围定义
表 5.3.2-2 TransactionType_t 取值范围定义(SPT)
5.3.3 线路编号字段 LineID_t 应符合以下规定：
1 定义方式：Typedef U8_t LineID_t;
2 取值方式：本字段取值应执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.3的规定。表 5.3.3 LineID_t 取值范围定义
5.3.4 车站编号 StationID_t 应符合以下规定：
1 定义方式：TypedefU16_t StationID_t;
2 取值方式：取值时应执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.4的规定。表 5.3.4 StationID_t 取值范围定义
5.3.5 区域编号 ZoneID_t 应符合以下规定：
1 定义方式：TypedefU8_t ZoneID_t;
2 取值方式：取值时应执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.5的规定。
表 5.3.5 ZoneID_t 取值范围定义
5.3.6 区段编号 SectionID_t 应符合以下规定：
1 定义方式：TypedefU8_t SectionID_t;
2 取值方式：具体取值时应执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.6的规定。表 5.3.6 SectionID_t 取值范围定义
5.3.7 区段里程类别 SectionTypeID_t 应符合以下规定：
1 定义方式：TypedefU8_t SectionTypeID_t;
2 取值方式：取值时应执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.7的规定。表 5.3.7 SectionTypeID_t 取值范围定义
5.3.8 车票有效使用范围 AreaTicketFlag_t 应符合以下规定：
1 定义方式：TypedefU8_t AreaTicketFlag_t;
2 取值方式：按照表5.3.8固定取值;
3 取值范围定义：取值范围应符合表5.3.8的规定。
表 5.3.8AreaTicketFlag_t 取值范围定义
5.3.9 设备类型 DeviceType_t 应符合以下规定：
1 定义方式：TypedefU8_t DeviceType_t;
2 取值方式：按照表5.3.9固定取值;
3 取值范围定义：取值范围应符合表5.3.9的规定。
表 5.3.9 DeviceType_t 取值范围定义
5.3.10 设备子类型 DeviceSubType_t 应符合以下规定：
1 定义方式：TypedefU8_t DeviceSubType_t;
2 取值方式：按照表5.3.10固定取值;
3 取值范围定义：取值范围应符合表5.3.10的规定。表 5.3.10 DeviceSubType_t 取值范围定义
续表 5.3.10 DeviceSubType_t 取值范围定义
5.3.11 设备编号 DeviceID_t 应符合以下规定：
1 定义方式：TypedefU32_t DeviceID_t;
2 取值方式：取值时应执行线路参数定义;
3 取值范围定义：取值范围应符合表5.3. 11的规定。表 5.3. 11 DeviceID_t 取值范围定义
注：线路、车站、类型、编号中的取值范围为[0,255] ，其中 1～255 用于具体节点编码使用，值 1 约定为各级系统所属层级的通信前置机设备序号，值 0 在通信时做路由使用，表示该节点层次下的所有节点，取值规定举例如下：
1 09021101：表示 1 号线 2 号车站的通信前置机;
2 09020605：表示 1 号线 2 号车站的 05 号设备(类型为自动检票机);
3 09020000：表示 1 号线 2 号车站的所有设备;
4 09020600：表示 1 号线 2 号车站的所有自动检票机;
5 涉及到 APP 作为设备时，DeviceID 设定为 88001500。
5.3.12 SAM 卡编号 SAMID_t 应符合以下规定：
1 定义方式：TypedefU32_t SAMID_t;
2 取值方式：取值应根据应用生成;
3 取值范围定义：取值范围应符合表5.3. 12的规定。表 5.3. 12 SAMID_t 取值范围定义
5.3.13 操作员编号 OperatorID_t 应符合以下规定：
1 定义方式：TypedefU32_t OperatorID_t;
2 取值方式：取值应根据应用生成;
3 取值范围定义：取值范围应符合表5.3.13的规定。表 5.3.13 OperatorID_t 取值范围定义
5.3.14 BOM 班次号 BOMShiftID_t 应符合以下规定：
1 定义方式：TypedefU32_t BOMShiftID_t;
2 取值方式：取值应根据应用生成;
3 取值范围定义：取值范围应符合表5.3. 14的规定。表 5.3. 14 BOMShiftID_t 取值范围定义
5.3.15 票卡测试标志位 TestFlag_t 应符合以下规定：
1 定义方式：TypedefU8_t TestFlag_t;
2 取值方式：应按照表5.3.15取值;
3 取值范围定义：取值范围应符合表5.3.15的规定。
表 5.3.15 TestFlag_t 取值范围定义
5.3.16 票种基本类型(大类分类)TicketFamily_t 应符合以下规定：
1 定义方式：TypedefU8_t TicketFamily_t;
2 取值方式：应按照表5.3.16取值;
3 取值范围定义：取值范围应符合表5.3.16的规定。表 5.3.16 TicketFamily_t 取值范围定义
5.3.17 车票类型 TicketType_t 应符合以下规定：
1 定义方式：TypedefU8_t TicketType_t;
2 取值方式：取值时应执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.17的规定。
表 5.3.17 TicketType_t 取值范围定义
5.3.18 票卡介质芯片类型 ChipType_t 应符合以下规定：
1 定义方式：TypedefU8_t ChipType_t;
2 取值方式：应按照表5.3.18取值;
3 取值范围定义：取值范围应符合表5.3.18的规定。表 5.3.18 ChipType_t 取值范围定义
5.3.19 票卡流水号 TicketSN_t 应符合以下规定：
1 定义方式：TypedefU32_t TicketSN_t;
2 取值方式：取值应根据应用生成;
3 取值范围定义：取值范围应符合表5.3.19的规定。表 5.3.19 TicketSN_t 取值范围定义
5.3.20 票卡封面类型 MediaType_t 应符合以下规定：
1 定义方式：TypedefU8_t MediaType_t;
2 取值方式：应按照表5.3.20取值;
3 取值范围定义：取值范围应符合表5.3.20规定。表 5.3.20 MediaType_t 取值范围定义
5.3.21 票卡逻辑号 TicketLogicalID_t 应符合以下规定：
1 定义方式：TypedefU32_t TicketLogicalID_t;
2 取值方式：应根据应用生成;
3 取值范围定义：取值范围应符合表5.3.21规定。表 5.3.21 TicketLogicalID_t 取值范围定义
5.3.22 票卡物理编号 TicketPhyID_t 应符合以下规定：
1 定义方式：TypedefU32_t[2] TicketPhyID_t;
2 取值方式：取值应根据应用生成;
3 取值范围定义：取值范围应符合表5.3.22规定。
表 5.3.22 TicketPhyID_t 取值范围定义
5.3.23 一卡通储值票卡面号 TicketPrintID_t 应符合以下规定：
1 定义方式：Typedef String TicketPrintID_t;
2 取值方式：取值应根据应用生成;
3 取值范围定义：取值范围应符合表5.3.23规定。表 5.3.23 TicketPrintID_t 取值范围定义
5.3.24 设备交易流水号 SN_t 应符合以下规定：
1 定义方式：TypedefU32_t SN_t;
2 取值方式：取值应根据应用生成;
3 取值范围定义：取值范围应符合表5.3.24规定。表 5.3.24 SN_t 取值范围定义
5.3.25 车站模式 ModeCode_t 应符合以下规定：
1 定义方式：TypedefU16_t ModeCode_t;
2 取值方式：应按照表5.3.25取值;
3 取值范围定义：取值范围应符合表5.3.25的规定。表 5.3.25 ModeCode_t 取值范围定义
5.3.26 乘客类型分类 PassengerTypeID_t 应符合以下规定：
1 定义方式：TypedefU8_t PassengerTypeID_t;
2 取值方式：应按照表5.3.26取值;
3 取值范围定义：取值范围应符合表5.3.26的规定。表 5.3.26 PassengerTypeID_t 取值范围定义
5.3.27 自动检票机车票处理提示音类别 SoundDisplayID_t 应符合以下规定：
1 定义方式：TypedefU8_t SoundDisplayID_t;
2 取值方式：取值时应执行线路中心参数定义;
3 取值范围定义：取值范围应符合表5.3.27的规定。表 5.3.27 SoundDisplayID_t 取值范围定义
5.3.28 自动检票机灯光显示代码 ConcessionalLampID_t 应符合以下规定：
1 定义方式：TypedefU8_t ConcessionalLampID_t;
2 取值方式：取值时应执行线路中心参数定义;
表 5.3.28 ConcessionalLampID_t 取值范围定义
5.3.29 设备交易 TAC 码 TAC_t 应符合以下规定：
1 定义方式：TypedefU32_t TAC_t;
2 取值方式：取值时应根据应用生成;
3 取值范围定义：取值范围应符合表5.3.29的规定。表 5.3.29 TAC_t 取值范围定义
5.3.30 单程票回收标志 RecycleSJTFlag_t 应符合以下规定：
1 定义方式：TypedefU8_t RecycleSJTFlag_t;
2 取值方式：应按照表5.3.30取值;
3 取值范围定义：取值范围应符合表5.3.30的规定。
表 5.3.30 RecycleSJTFlag_t 取值范围定义
5.3.31 乘车里程/区间等级 FareTier_t 应符合以下规定：
1 定义方式：TypedefU8_t FareTier_t;
2 取值方式：取值时应执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.31的规定。表 5.3.31 FareTier_t 取值范围定义
5.3.32 车票有效期类别 DurationMode_t 应符合以下规定：
1 定义方式：TypedefU8_t DurationMode_t;
2 取值方式：应按照表5.3.32取值;
3 取值范围定义：取值范围应符合表5.3.32的规定。
表 5.3.32 DurationMode_t 取值范围定义
5.3.33 车票有效期时间段(天)Duration_t 应符合以下规定：
1 定义方式：TypedefU16_t Duration_t;
2 取值方式：取值时应根据应用生成;
3 取值范围定义：取值范围应符合表5.3.33的规定。表 5.3.33 Duration_t 取值范围定义
5.3.34 拒绝车票过闸错误代码 RejectCode_t 应符合以下规定：
1 定义方式：TypedefU8_t RejectCode_t;
2 取值方式：应按照表5.3.34取值;
3 取值范围定义：取值范围应符合表5.3.34的规定。
表 5.3.34 RejectCode_t 取值范围定义
5.3.35 锁卡原因 BlockReasonCode_t 应符合以下规定：
1 定义方式：TypedefU8_t BlockReasonCode_t;
2 取值方式：应按照表5.3.35取值;
3 取值范围定义：取值范围应符合表5.3.35的规定。表 5.3.35 BlockReasonCode_t 取值范围定义
5.3.36 日期类型 DateTypeID_t 应符合以下规定：
1 定义方式：TypedefU8_t DateTypeID_t;
2 取值方式：应按照表5.3.36取值;
3 取值范围定义：取值范围应符合表5.3.36的规定。表 5.3.36 DateTypeID_t 取值范围定义
5.3.37 数据定义 TicketFareTypeID_t 应符合以下规定：
1 定义方式：TypedefU8_t TicketFareTypeID_t;
2 取值方式：取值时应执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.37的规定。表 5.3.37 TicketFareTypeID_t 取值范围定义
5.3.38 时间段代码 TimeIntervalID_t 应符合以下规定：
1 定义方式：TypedefU8_t TimeIntervalID_t;
2 取值方式：具体取值时执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.38的规定。表 5.3.38 TimelntervalID_t 取值范围定义
5.3.39 车票费率组代码 FareGroupID_t 应符合以下规定：
1 定义方式：TypedefU8_t FareGroupID_t;
2 取值方式：取值时应执行清分中心参数定义;
3 取值范围定义：取值范围应符合表5.3.39的规定。表 5.3.39 FareGroupID_t 取值范围定义
5.3.40 运营商编号 SP_t 应符合以下规定：
1 定义方式：TypedefU8_t SP_t;
2 取值方式：应按照表5.3.40取值;
3 取值范围定义：取值范围应符合表5.3.40的规定。表 5.3.40 SP_t 取值范围定义
5.3.41 AR 文件类型 ARFileTag_t 应符合以下规定：
1 定义方式：TypedefU8_tARFileTag_t;
2 取值方式：应按照表5.3.41取值;
3 取值范围定义：取值范围应符合表5.3.41的规定。表 5.3.41ARFileTag_t 取值范围定义
5.3.42 购票支付方式 Paymentmeans_t 应符合以下规定：
1 定义方式：TypedefU8_t Paymentmeans_t;
2 取值方式：应按照表5.3.42取值;
3 取值范围定义：取值范围应符合表5.3.42的规定。表 5.3.42 Paymentmeans_t 取值范围定义
5.3.43 MD5_t 验证码应符合以下规定：
1 定义方式：MD5_t 算法输出为 16 个字节长度编码，采用 U32_t[4]进行定义，U32_t 从高位到低位分别表示第 0 到第 3 个字节;
2 取值方式：具体取值时根据应用生成;
3 取值范围定义：取值范围应符合表5.3.43的规定。表 5.3.43 MD5_t 取值范围定义
5.3.44 Unicode 字符串 UnicodeString_t 应符合以下规定：
1 定义方式：Typedef opaque<> UnicodeString_t;
2 取值方式：应取值时根据应用生成;
3 取值范围定义：取值范围应符合表5.3.44的规定。
表 5.3.44 UnicodeString_t 取值范围定义
5.3.45 消息确认码 MACK_t 应符合以下规定：
1 定义方式：TypedefU8_t MACK_t;
2 取值方式：应按照表5.3.45取值;
3 取值范围定义：取值范围应符合表5.3.45的规定。表 5.3.45 MACK_t 取值范围定义
5.3.46 文件服务器文件目录类别 FilePathType_t 应符合以下规定：
1 定义方式：TypedefU8_t FilePathType_t;
2 取值方式：应按照表5.3.46取值;
3 取值范围定义：取值范围应符合表5.3.46的规定。表 5.3.46 FilePathType_t 取值范围
续表 5.3.46 FilePathType_t 取值范围
5.3.47 交易对账流水号 ReconcileSeqNo_t 应符合以下规定：
1 定义方式：TypedefU32_t[2] ReconcileSeqNo_t;
2 取值方式：具体取值由应用系统生成;
3 取值范围定义：取值范围应符合表5.3.47的规定。
表 5.3.47 ReconcileSeqNo_t 取值范围定义
注：SLE 与 SC 、SC 与 LCC 、LCC 与 ACC 进行交易对账时，不再在各对账点生成本地对账流水号，统一采用ReconcileSeqNo_t 用以定位系统中唯一交易，ReconcileSeqNo_t 信息均来自产生交易的终端设备。
5.3.48 票卡逻辑号(2)TicketLogID_t 应符合以下规定：
1 定义方式：TypedefU32_t[3] TicketLogID_t;
2 取值方式：应按照表5.3.48取值;
3 取值范围定义：取值范围应符合表5.3.48的规定。
表 5.3.48 TicketLogID_t 取值范围定义
5.3.49 终端机编号 TerminalID_t 应符合以下规定：
1 定义方式：TypedefU32_t[2] TerminalID_t;
2 取值方式：应按照表5.3.49取值;
3 取值范围定义：取值范围应符合表5.3.49的规定。表 5.3.49 TerminalID_t 取值范围定义
5.3.50 票卡目录编号 TicketCatalogID_t 应符合以下规定：
1 定义方式：TypedefU16_t TicketCatalogID_t;
2 取值方式：具体取值由应用系统生成;
3 取值范围定义：取值范围应符合表5.3.50的规定。表 5.3.50 TicketCatalogID_t 取值范围定义
5.3.51 箱子类型编码 BoxType_t 应符合以下规定：
1 定义方式：TypedefU8_t BoxType_t;
2 取值方式：应按照表5.3.51取值;
3 取值范围定义：取值范围应符合表5.3.51的规定。表 5.3.51 BoxType_t 取值范围定义
5.3.52 钱箱和票箱编号 BoxID_t 应符合以下规定：
1 定义方式：TypedefU32_t BoxID_t;
2 取值方式：应按照表5.3.52取值;
3 取值范围定义：取值范围应符合表5.3.52的规定。表 5.3.52 BoxID_t 取值范围定义
注：取值规定举例如下：
1 03029999 表示：车站编号为 02 的 TVM 废票箱，编号为 9999;
2 04030501 表示：车站编号为 03 ，05 号 TVM ，01 号车票 HOPPER。
5.3.53 设备部件类型 DevicePartType_t 应符合以下规定：
1 定义方式：TypedefU8_t DevicePartType_t;
2 取值方式：应按照表 5.3.53- 1 和表 5.3.53-2 取值;
3 取值范围定义：取值范围应符合表 5.3.53- 1 和表 5.3.53-2 的规定。
表 5.3.53- 1 DevicePartType_t 取值范围定义
表 5.3.53-2
注：取值规定举例如下：
1 02039999 表示：车站编号为 02 的 TVM 废票箱，编号为 9999;
2 03040501 表示：车站编号为 03 ，05 号 TVM ，01 号车票 HOPPER。
5.3.54 币种类型 CashType_t 应符合以下规定：
1 定义方式：TypedefU8_t CashType_t;
2 取值方式：应按照表5.3.54取值;
3 取值范围定义：取值范围应符合表5.3.54的规定。表 5.3.54 CashType_t 取值范围定义
5.3.55 设备工作模式 WorkMode_t 应符合以下规定：
1 定义方式：TypedefU32_t WorkMode_t;
2 取值方式：应按照表 5.3.55- 1 和 5.3.55-2 取值;
3 取值范围定义：取值范围应符合表 5.3.55- 1 和 5.3.55-2 的规定。
表 5.3.55- 1 AGM 和 BOM 取值范围定义
表 5.3.55-2 TVM 专用取值范围定义
注：TVM 的工作模式由4 个字节组成，分别是：找零状态+现金支付状态+二维码支付状态+工作状态
5.3.56 文件所包含的交易笔数 Filenumber_t 应符合以下规定：
1 定义方式：TypedefU32_t Filenumber_t;
2 取值方式：具体取值由应用系统生成;
3 取值范围定义：取值范围应符合表5.3.56的规定。表 5.3.56 Filenumber_t 取值范围定义
5.3.57 功能编码 FunctionID_t 应符合以下规定：
1 定义方式：TypedefU32_t FunctionID_t;
2 取值方式：应按照表5.3.57取值;
3 取值范围定义：取值范围应符合表5.3.57的规定。表 5.3.57 FunctionID_t 取值范围定义
5.3.58 位置状态编码 BoxPositionstatus_t 应符合以下规定：
1 定义方式：TypedefU8_t BoxPositionstatus_t;
2 取值方式：应按照表5.3.58取值;
3 取值范围定义：取值范围应符合表5.3.58的规定。表 5.3.58 BoxPositionstatus_t 取值范围定义
6 通信接口定义
6. 1 文件传输协议通用规定
6.1.1 文件传输协议使用范围应符合以下规定：
1 AFC 系统各层之间的文件传输协议(FTP)、实时报文协议(TCP Socket)及时间同步协议(NTP)和简单时间同步协议(SNTP)应基于 TCP/IP 协议。
2 由终端设备产生并通过 SC 、LCC 逐层上传的交易数据、收益数据、审计数据、设备事件数据应使用FTP 协议传输。
3 上级系统的运营参数、设备配置参数、结算对账数据、各类程序文件以及资源文件应使用FTP 协议传输到下级系统。
6.1.2 文件传输协议的结构层次应满足以下原则：
1 ACC 系统与 SPT 系统、ACC 系统与LCC 系统、LCC 系统与 SC 系统、SC 系统与 SLE 之间的文件传输宜使用FTP 协议。
2 ACC 与 SPT 之间的数据传输以 ACC 为 FTP 服务器，SPT为客户端。
3 ACC 与 LCC 之间的数据传输应以 ACC 为 FTP 服务器， LCC 为客户端。
4 LCC 与 SC 之间的数据传输应以LCC 为 FTP 服务器，SC为客户端。
5 SC 与 SLE 之间的数据传输应以 SC 为 FTP 服务器，SLE 为客户端。
6.1.3 文件传输协议应符合以下规定：
1 跨层系统首次通信连接时，应由下层系统向上层系统发起通信连接申请，上层系统应通过报文应答方式将 FTP 服务器访问信息返回给客户端。
2 当 FTP 客户端产生数据文件需要上传服务器时，客户端应主动访问服务器，并将文件上传到指定的 FTP 工作目录。
3 当 FTP 服务器端产生数据文件，需要下发至客户端时，服务器应首先将数据文件复制到 FTP 工作目录，然后通过消息号为0x1002 的 Socket 报文通知客户端下载文件。客户端接到 Socket 指令信息后，立刻访问指定的 FTP 服务器，下载相关数据文件。
4 对特定的业务需求，客户端应轮询(定期查找)服务器端指定的 FTP 工作目录，下载相关数据文件。
5 FTP 服务器端应负责维护本地 FTP 工作目录内的所有数据文件。FTP 服务器端检测到客户端上传的文件后，应立刻处理并从工作目录移走。FTP 服务器端工作目录下供客户端下载的数据文件，服务器端应定期整理。
6 客户端应将上传中的文件的文件名增加扩展名“ .tmp” ，文件上传完成后，应修改 FTP 服务器端文件名，取消“.tmp”后缀。
6.1.4 文件传输协议的传输审计应符合以下规定：
1 系统应使用数据文件传输审计功能确保文件传输的完整性。
2 上层系统在日终结算时应根据对本地处理过的接收文件进行信息汇总，下发到下层系统。下层系统应根据本地文件上传记录，找出差异信息，并对丢失的文件进行补传。补传的文件在下一个结算日进行审计。若次日审计仍然显示差异，则继续重新补传，直至上层系统接收方成功处理此文件。
6.1.5 文件传输协议的文件通用格式应符合表6. 1.5的规定：
表 6. 1.5 文件传输协议的文件通用格式(FileHeader_t)
续表6. 1.5 文件传输协议的文件通用格式(FileHeader_t)
6.1.6 文件传输协议的文件命名规范应符合以下规定：
1 文件名称应包含文件类型代码，8 位 HEX 字符的设备编码，文件生成的年月日时分秒字符串，文件序列号，HEX 的协议版本号。
2 编辑格式应为：
AAAA|NodeID|YYYYMMDDHHMISS|FileSN.VV。
6.2 TCP 联机报文通用规定
6.2.1 数据同步请求、车站模式信息传输、设备监控、客流监控等对实时性要求高的上行和下行消息应采用TCP 联机报文方式
传送。
6.2.2 联机报文的结构层级应符合以下规定：
1 AFC 系统各层级之间的实时通信应使用 TCP Socket 方式，实时通信双方可互为 Socket 服务器和客户端。
2 SPT/TPU 之间以 SPT 为上层系统，TPU 为下层系统。
3 IMT/TPU 之间以IMT 为上层系统，TPU 为下层系统。
4 ACC 与 LCC 之间以 ACC 为上层系统，LCC 为下层系统。
5 LCC 与 SC 之间以LCC 为上层系统，SC 为下层系统。
6 SC 与 SLE 之间以 SC 为上层系统，SLE 为下层系统。
7 当上层系统启动以后，本地的 TCP Socket服务器应立刻启动，并等待下层发起的 Socket 连接请求。
8 下层系统启动后，应首先将本地的 TCP 服务器打开，根据本地配置的上层系统 TCP Socket通信服务器的IP 和端口地址，发起主动连接请求。连接成功后，上层系统记录下层系统的信息，
信息应包含 IP 及节点编号，同时上层系统的上下文信息传递给下层系统，包括 FTP 服务器目录信息与访问账号信息等。
9 完整通信接口业务流程应包括报文发送、报文处理、结果应答。
10 报文通信过程中如果报文格式正确，则开始处理相关业务，系统应在业务处理完毕后发送业务处理结果报文。如果报文解析 异常，应以 MACK 报文返回发送方，并填写具体的错误代码。
11 数据消息的发送者应作为客户端向接收者设置的TCP 服务器发起 TCP 连接请求，接收者接受连接请求，建立 TCP 连接。发送者发出请求消息报文，接收者返回应答消息。
12 Socket 服务器端不应主动断开连接。
13 当数据消息的发送者在发出请求消息后，在业务规定的时间内未收到应答时，应按数据消息的业务要求，决定是否对其进行重发。重发的请求应和原始的请求消息完全相同。超时时间和重试次数应按照清分中心参数定义进行取值。
6.2.3 联机报文的同步工作方式应符合以下规定：
1 同步方式应满足：交互 1 请求-交互 1 处理-交互 1 应答
-交互 2 请求-交互 2 处理-交互 2 应答 依次进行的工作方式。
2 在此方式下，通信节点不能并行工作，通信客户端在未收到服务器端响应时，将进行阻塞等待，只有在超时重试失败后，才允许下次业务请求。
6.2.4 联机报文的异步工作方式应符合以下规定：
1 异步方式应满足：交互 1 请求-交互 2 请求-交互 3 请求 依次进行;同时，交互 1 处理-交互 2 处理-交互 3 处理 依次进行;同时，交互 1 应答-交互 2 应答-交互 3 应答 依次进行。
2 在此方式下，通信客户端将根据应答报文中的报文号和会话号对原请求进行匹配处理，请求、处理和应答按非阻塞的方式进行处理。
6.2.5 联机报文的规范约定应符合以下原则：
1 系统间进行 Socket 实时通信时，上层系统和下层系统维护各自的通信链路。
2 LCC/SC/SLE 之间发起的业务请求均采用异步长连接通信规程。
3 ACC/LCC 之间下层系统向上层系统发起的业务请求采用异步长连接通信规程，上层系统向下层系统发起的业务请求采用同步短连接通信规程。
4 SPT/TPU 、IMT/TPU 之间发起的业务请求均采用同步短连接通信规程。
6.2.6 XDR 联机报文的通用报文结构应符合以下规定：
1 报文格式定义应符合以下规定：
1)所有报文字段数据类型的定义及取值范围均参见第 5 章系统编码定义。
2)所有报文中的字段均采用大端格式存储。
3)所有报文采用单包，且最大长度为 8K 字节。
2 XDR 通信报文通用结构应符合表6.2.6-2 的规定：
表 6.2.6-2XDR 通信报文通用格式定义
3 包头结构应符合表的6.2.6-3 规定：
表 6.2.6-3 包头结构(PacketHeader_t)
续表 6.2.6-3 包头结构(PacketHeader_t)
4 MACK 应答包结构体应按以下步骤执行：
1)当应答消息内容仅包含应答码时，称此应答为 MACK。
2)MACK 应答报文的包头按照原请求报文的消息类型进行
编码。
3)MACK 应答包结构体应符合表6.2.6-4 的定义：
表 6.2.6-4 MACK 应答包结构体(PacketBodyData)
6.2.7 自定义结构体联机报文的通用报文结构应符合以下规定：
1 自定义结构体报文格式定义应符合表6.2.7的规定：
表 6.2.7 自定义结构体报文包格式定义
注：完整的报文包括包头、包体和 MD5 校验。
6.2.8 包头定义应符合表6.2.8的规定：
表 6.2.8 包头定义
6.3 NTP 时钟同步协议通用规定
6.3.1 LCC 和 IMT 应主动与 ACC 进行时钟同步。
6.3.2 由 LCC 管理的下层系统应与 LCC 系统时钟进行同步，由 SC 管理的下层系统应与 SC 系统时钟进行同步， 由 IMT 管理
的下层系统应与IMT 系统时钟进行同步。
6.3.3 时钟同步协议采用 NTP 协议，应符合 INTERNET 通用协议中网络时间协议 RFC1305 的规定。
6.3.4 NTP 协议使用单播进行工作。下层系统主动访问上层系统指定的时钟同步服务器，从服务器获得准确的时间信息，并调
整自己的系统时钟。
6.3.5 NTP 服务端和客户端设置应符合以下规定：
1 ACC 系统以下的系统层级应设置 NTP 客户端，并将 NTP服务器地址设置为其相邻上层系统的地址。各个层级系统开机时或每小时的0 分， 自动从其所设定的 NTP 服务器获取当前时间。
2 对于无法使用NTP 协议进行时间同步的车站终端设备，应使用应用层的 100E 报文(时钟强制同步指令)交互实现。
3 ACC 、IMT 、LCC 、SC 可配置成 NTP 服务器，接收来自其下层的时间询问请求，并返回含有其系统时间信息的应答。
6.4 通信业务定义
6.4.1 交易文件类型和传输范围及方向和编码格式定义应符合
表 6.4. 1的规定：
表 6.4. 1文件类型列表
续表6.4. 1文件类型列表
续表6.4. 1文件类型列表
6.4.2 交易文件定义应符合本标准第 7 章的规定。
6.4.3 参数文件定义应符合本标准第 8 章的规定。
6.4.4 FTP 审计文件结构体(6001)应符合表 6.4.4的规定：
表 6.4.4 FTP 审计文件结构体(FileBodyData_t)
续表 6.4.4 FTP 审计文件结构体(FileBodyData_t)
6.4.5 交易对账文件结构体(6002)应符合表6.4.5的规定：
表 6.4.5 交易对账文件结构体(FileBodyData_t)
续表 6.4.5 交易对账文件结构体(FileBodyData_t)
6.4.6 可疑交易调整文件结构体(6003)应符合表6.4.6的规定：
表 6.4.6 可疑交易调整文件结构体(FileBodyData_t)
续表 6.4.6 可疑交易调整文件结构体(FileBodyData_t)
6.4.7 清分数据文件结构体(6004)应符合表6.4.7的规定：
表 6.4.7 清分数据文件结构体(FileBodyData_t)
续表 6.4.7 清分数据文件结构体(FileBodyData_t)
续表 6.4.7 清分数据文件结构体(FileBodyData_t)
6.4.8 SPT 平台 FTP 审计文件结构体(6005)应符合表 6.4.8的
规定：
表 6.4.8 SPT 平台 FTP 审计文件结构体(FileBodyData_t)
6.4.9 SPT 平台交易对账文件结构体(6006)应符合表 6.4.9的
规定：
表 6.4.9 SPT 平台交易对账文件结构体(FileBodyData_t)
续表 6.4.9 SPT 平台交易对账文件结构体(FileBodyData_t)
6.4.10 SPT 平台可疑交易调整文件结构体(6007) 应符合表
6.4.10的规定：
表 6.4.10 SPT 平台可疑交易调整文件结构体(FileBodyData_t)
6.4.11 清分数据明细文件结构体(6008)应符合表 6.4. 11的规
定：
表 6.4. 11 清分数据明细文件结构体(FileBodyData_t)
6.4.12 日终库存快照文件结构体(5001)应符合表 6.4. 12的规
定：
表 6.4. 12 日终库存快照结构体(FileBodyData_t)
6.4.13 设备交易审计文件结构体(6009)应符合表 6.4.13的规
定：
表 6.4.13 设备交易审计文件结构体(FileBodyData_t)
6.4.14 设备交易对账文件结构体(6010)应符合表 6.4. 14的规
定：
表 6.4. 14 设备交易对账文件结构体(FileBodyData_t)
6.4.15 设备可疑交易调整文件结构体(6011)应符合表 6.4.15
的规定：
表 6.4.15 设备可疑交易调整文件结构体(FileBodyData_t)
续表 6.4.15 设备可疑交易调整文件结构体(FileBodyData_t)
6.5 XDR 实时报文规范
6.5.1 XDR 通信报文类型和传输范围及方向、编码格式应符合
表 6.5. 1的规定：
评论