DB13/T 5519.6-2022 轨道交通 AFC 系统线网技术要求 第 6 部 分： 数据传输

ICS45.020

CCSS71

13

河北省地方标准

DB13/T5519.6—2022

轨道交通AFC系统线网技术要求

第6部分：数据传输

TechnicalrequirementsforAFCsystemnetworkofrailtransit

Part6:Thedatatransfer

2022-02-28发布2022-03-31实施

河北省市场监督管理局发布

DB13/T5519.6—2022

目次

前言...............................................................................II

引言..............................................................................III

1范围.............................................................................1

2规范性引用文件...................................................................1

3术语和定义.......................................................................1

4传输方式.........................................................................1

I

DB13/T5519.6—2022

前言

本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规

定起草。

请注意本文件的的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

DB13/T5519-2022《轨道交通AFC系统线网技术要求》分为7个部分：

——第1部分：系统结构及功能；

——第2部分：终端与专用设备；

——第3部分：读写器应用；

——第4部分：人机界面；

——第5部分：票卡应用标准；

——第6部分：数据传输；

——第7部分：数据接口；

本文件是DB13/T5519-2022的第6部分。

本文件由石家庄市市场监督管理局提出并归口。

本文件起草单位：石家庄市轨道交通集团有限责任公司、南京熊猫信息产业有限公司。

本文件主要起草人：王相辉、桑静波、杨俊义、侯璟琨、高申、陈泽、李立勃、李渊、胡天宁、

周晓科、曹明、徐志君。

II

DB13/T5519.6—2022

引言

本文件的编写是为了给河北省内轨道交通AFC系统建设提供参考标准及规范。在这方面，我省

已经初步完成河北省轨道交通AFC系统线网技术要求标准文件的起草、制定和组织工作，拟由七部

分构成。

——第1部分：系统结构及功能。目的在于进一步规范轨道交通AFC系统架构以及功能统一，

确立各层系统互联互通、不同设备接入的相关技术要求。

——第2部分：终端与专用设备。目的在于进一步规范轨道交通AFC系统各类终端设备的技术

要求和功能，方便后期扩展，指导新线有序建设。

——第3部分：读写器应用。目的在于进一步规范轨道交通AFC系统读写器应用，为系统引入

新设备、新票种，实现系统的互联互通提供支持。

——第4部分：人机界面。目的在于进一步规范轨道交通AFC系统各类终端设备人机交互界面

的统一，推动乘客人机交互界面应用的标准化，方便操作员维护，提高乘客使用的体验感。

——第5部分：票卡应用标准。目的在于进一步规范轨道交通AFC系统中使用的实体票卡技术

要求统一，确保满足票卡的兼容性及新设备、新票种（或卡型）引入的要求。

——第6部分：数据传输。目的在于进一步规范轨道交通AFC系统中各级系统之间、设备与系

统之间的数据内容，促进后期建设及扩展的可持续发展。

——第7部分：数据接口。目的在于进一步规范轨道交通AFC系统各线路终端设备与车站计算

机、车站计算机与线路中央计算机、线路中央计算机与中央清分系统，以及城市轨道交通与一卡通

之间的接口。

结合我省实际轨道交通AFC系统事业建设情况，首要任务就是尽快建立明确的地方标准体系。

建设完善的技术规则而起草高质量的标准化文件，有利于保证河北省内轨道交通建设和后续新建线

路的顺利接入，有利于促进河北省轨道交通事业的可持续发展。

III

DB13/T5519.6—2022

轨道交通AFC系统线网技术要求

第6部分：数据传输

1范围

本文件规定了轨道交通AFC系统的数据传输方式，根据数据的传输方式不同，分为实时通信传输

和文件传输。

本文件适用于河北省轨道交通AFC系统规范各层级间数据及文件传输服务，有利于确保数据及文

件传输的正确性和完整性。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用

文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）

适用于本文件。

GB50157-2013地铁设计规范；

GB50381-2018城市轨道交通自动售检票系统工程质量验收规范；

GB/T20907-2007城市轨道交通自动售检票系统技术条件；

CJJ/T162-2011城市轨道交通自动售检票系统检测技术规程。

3术语和定义

本文件没有需要界定的术语和定义。

4传输方式

文件传输

在AFC系统中各层级系统间文件传输主要通过FTP服务完成，应满足如下要求：

a)传输文件应包括交易文件、审计文件、设备事件文件、参数文件、黑名单文件、模式履历

文件、FTP审计文件、结算文件等；

b)上一级系统应向下一级系统提供FTP服务；

c)下一级系统应通过实时通信中的FTP登录申请报文，获取FTP服务的用户名和密码等信息，

之后登录上一级FTP服务器并主动向上一级传输或下载文件；

d)正在上传文件时，应首先将上传的文件的文件名后缀添加tmp。当传输完成后，再将文件改

成正常的文件名。

实时报文传输

在AFC系统中，实时性要求高的上行和下行的数据消息和联机查询请求及应答消息应以TCP/IP

作为底层通信承载协议进行实时报文传输，主要提供ACC-LC-SC-SLE之间联机报文交换功能。

通讯机制

4.3.1协议结构

本接口标准所定义的报文以TCP/IP作为底层通信承载协议，应满足：

a)TCPSocket通讯将在AFC系统各级实时通讯中予以应用，系统中仅相邻的两层可进行通讯

交互；

b)实时通讯双方上层为Socket服务器，下层为客户端；

1

DB13/T5519.6—2022

c)LC/SC之间以LC为上层系统，SC为下层系统；

d)SC/SLE之间以SC为上层系统，SLE为下层系统。

4.3.2连接方式与报文格式

通信链路的建立与响应

客户端与服务器端通信链路的建立与响应，应满足：

a)客户端在启动时，应主动向服务器端发起连接请求；

b)若在规定的时间内无法与服务器端建立连接，则客户端应产生报警并主动取消连接请求；

c)服务器端不应主动断开与客户端的连接；

d)若客户端与服务端连接中断或客户端与服务端没有建立连接，则客户端应产生报警并等待

一段时间后重新向服务端发起连接请求；

e)以上流程直至双方成功建立了通信链路为止。

链接方式

客户端与服务器端通信链路的链接方式具有单链路、长链路和异步工作模式的特性。

a)单链路

1)相连两层之间只建立一条通信链路，双方的请求和应答数据都在这条链路上交互；

2)建立链路时上层作为通讯服务器端应建立监听端口；

3)下层作为通信服务器客户端应主动向上层发起链接请求。

b)长链接

1)客户端向服务器端发起连接请求，服务器端应接受请求，建立连接；

2)此连接应作为服务器和客户端间的唯一报文传输链路，连接建立成功后一般不断开连

接。

c)异步工作模式

1)消息发送端发送一个请求消息后，不等待其应答返回，即可接着发送下一个请求消息，

同时应可接收对方返回的应答消息；

2)消息接收端收到请求消息后，在对其进行业务处理的同时，应可接收下一条请求消息；

3)在此工作模式下，报文应采用二进制格式,大端格式存储。

BOM直连ACC采用WebService方式,数据格式采用XML格式。

数据交换

通信链路建立以后，连接的双方均可以连续向对方发送多条命令并接收应答。

报文传输方式见图1。

注：数据双方采用A和B描述，表明A或B可以是通讯服务器或客户端的任一方，体现了端与端协议对等的设计原

则。

图1报文传输方式

2

DB13/T5519.6—2022

为避免实时通信过程中跨层响应的不确定性，应采用相邻层直接给出消息应答(MACK)的机制，

消息请求内容的最终回复由最终接收方重启一条消息请求报文。

任何一端发出数据包后，若在时限内没有收到对方确认的MACK应答，则发送方应在等待一定的

时间间隔后需重复发出该数据包。

重复发送对方没有确认的数据包示例见图2。

图2重复发送对方没有确认的数据包示例

数据包重复发出次数由实时通信参数RetryTimes设定，应满足：

a)若数据包按照设定次数重复发出后，对方仍然没有反应，发送方则停止发送；（例如，假

设RetryTimes=3，则重复发出3次，加上第一次共发送数据4次）

b)停止重发报文时，不应断开当前连接，但应产生告警；

c)重要报文应在下次重新建立起连接后补发或保存到文件中，通过数据备份介质导入或导出

数据。

心跳与通信中断

心跳与通信中断的机制及参数设定，应满足：

a)处于通讯的下级节点在一段无通讯报文上送时，应主动发送心跳报文；

b)心跳周期，由实时通信参数AlivePeriod设定；

c)若实时通信应答超时后，未收到目的节点反馈的应答消息，则表示应答失败，应重新发起

心跳报文；

d)实时通信应答周期，由实时通信参数TimeoutWithoutAnswer设定；

e)处于通讯的下级节点连续MaxIdlePeriodAmount次后仍应答超时，心跳报文发送失败，则

认为通信故障，下层节点应主动断开当前连接，重新发起连接请求；

f)最大空闲周期数，由实时通信参数MaxIdlePeriodAmount设定；

g)处于通信的上级节点在检测到一条连接长时间空闲时，上级节点应主动断开连接；

h)服务器端或客户端在连续接收到MaxInvalidMessageAmount次无效报文后，应主动断开当

前连接，客户端在与服务端连接中断时，应主动向服务器端发起连接请求；

i)最多连续无效报文数，由实时通信参数MaxInvalidMessageAmount设定。

通用报文结构定义

4.4.1报文格式定义

所有报文字段数据类型的定义及取值范围均参见《轨道交通AFC系统线网技术要求第7部分：数

据接口》，报文格式应满足：

a)所有报文中的字段均采用大端格式存储；

b)所有报文采用单包，且最大长度为8K字节；

3

DB13/T5519.6—2022

c)帧体采用二进制格式。

实时报文格式见表1。

表1实时报文格式

结构块编号字段类型长度备注

长度帧体长度TU162

包头1数据块

帧体包体2数据块

CRC值3消息验证码TU162包头+包体的CRC校验码

4.4.2包头定义

包头格式见表2。

表2包头格式

结构块编号字段名称类型长度备注

MessageTypeTMessageTy参见《第九册数据字典及编码规则》

12

消息类型码pe之消息类型

ProtocalVer定义为Const，由ACC发布新版时维

2sionTU324护，协议应用方直接填入该数字。

协议版本号新版本兼容老版本(仅限内容变化)

SenderID节点标识码，表明会话的请求方。（应

3发起方标识TDeviceID4答与请求一致），转发时需修改为自身的

码