标准规范下载简介
DB13／T 5519.6-2022 轨道交通 AFC 系统线网技术要求 第6部分：数据传输.pdfICS45.020 CCS s. 71
DB 13/T 5519. 62022
轨道交通AFC系统线网技术要求
DB31／T 747-2013标准下载河北省市场监督管理局 发布
DB 13/T5519.62022
引言 H 范围 规范性引用文件 术语和定义 传输方式
DB 13/T 5519. 62022
DB13/T5519.62022
本文件的编写是为了给河北省内轨道交通AFC系统建设提供参考标准及规范。在这方面，我省 已经初步完成河北省轨道交通AFC系统线网技术要求标准文件的起草、制定和组织工作，拟由七部 分构成。 第1部分：系统结构及功能。目的在于进一步规范轨道交通AFC系统架构以及功能统一， 确立各层系统互联互通、不同设备接入的相关技术要求。 第2部分：终端与专用设备。目的在于进一步规范轨道交通AFC系统各类终端设备的技术 要求和功能，方便后期扩展，指导新线有序建设。 一第3部分：读写器应用。目的在于进一步规范轨道交通AFC系统读写器应用，为系统引入 新设备、新票种，实现系统的互联互通提供支持。 第4部分：人机界面。目的在于进一步规范轨道交通AFC系统各类终端设备人机交互界面 的统一，推动乘客人机交互界面应用的标准化，方便操作员维护，提高乘客使用的体验感。 第5部分：票卡应用标准。目的在于进一步规范轨道交通AFC系统中使用的实体票卡技术 要求统一，确保满足票卡的兼容性及新设备、新票种（或卡型）引入的要求。 一第6部分：数据传输。目的在于进一步规范轨道交通AFC系统中各级系统之间、设备与系 统之间的数据内容，促进后期建设及扩展的可持续发展。 一第7部分：数据接口。目的在于进一步规范轨道交通AFC系统各线路终端设备与车站计算 机、车站计算机与线路中央计算机、线路中央计算机与中央清分系统，以及城市轨道交通与一卡通 之间的接口。 结合我省实际轨道交通AFC系统事业建设情况，首要任务就是尽快建立明确的地方标准体系。 建设完善的技术规则而起草高质量的标准化文件，有利于保证河北省内轨道交通建设和后续新建线 路的顺利接入，有利于促进河北省轨道交通事业的可持续发展。
DB 13/T5519.62022
轨道交通AFC系统线网技术要求
本文件规定了轨道交通AFC系统的数据传输方式，根据数据的传输方式不同，分为实时通信传输 和文件传输。 本文件适用于河北省轨道交通AFC系统规范各层级间数据及文件传输服务，有利于确保数据及文 件传输的正确性和完整性，
文件没有需要界定的术语
本文件没有需要界定的术语和定义。
本接口标准所定义的报文以TCP/IP TCPSocket通讯将在AFC系统各级实时通讯中予以应用，系统中仅相邻的两层可进行通 交互； b）实时通讯双方上层为Socket服务器，下层为客户端：
DB 13/T 5519. 62022
c）LC/SC之间以LC为上层系统，SC为下层系统； d）SC/SLE之间以SC为上层系统，SLE为下层系统。
4.3.2连接方式与报文格式
4. 3.2. 1通信链路的建立与响应
客户端与服务器端通信链路的建立与响应，应满足： 客户端在启动时，应主动向服务器端发起连接请求； 若在规定的时间内无法与服务器端建立连接，则客户端应产生报警并主动取消连接请求； C 服务器端不应主动断开与客户端的连接； Q 若客户端与服务端连接中断或客户端与服务端没有建立连接，则客户端应产生报警并等待 段时间后重新向服务端发起连接请求； e 以上流程直至双方成功建立了通信链路为止
4.3.2. 3数据交换
通信链路建立以后，连接的双方均可以连续向对方发送多条命令并接收应答。 报文传输方式见图1
DB 13/T5519.62022
为避免实时通信过程中跨层响应的不确定性，应采用相邻层直接给出消息应答（MACK）的机制， 消息请求内容的最终回复由最终接收方重启一条消息请求报文。 任何一端发出数据包后，若在时限内没有收到对方确认的MACK应答，则发送方应在等待一定的 时间间隔后需重复发出该数据包。 重复发送对方没有确认的数据包示例见图2
图2重复发送对方没有确认的数据包示例
数据包重复发出次数由实时通信参数RetryTimes设定，应满足： 8 若数据包按照设定次数重复发出后，对方仍然没有反应，发送方则停止发送；（例如，假 设RetryTimes=3，则重复发出3次，加上第一次共发送数据4次） 停止重发报文时，不应断开当前连接，但应产生告警； C 重要报文应在下次重新建立起连接后补发或保存到文件中，通过数据备份介质导入或导出 数据。
4. 3. 2. 4 心跳与通信中断
心跳与通信中断的机制及参数设定，应满足： 处于通讯的下级节点在一段无通讯报文上送时，应主动发送心跳报文； 心跳周期，由实时通信参数AlivePeriod设定： 若实时通信应答超时后，未收到目的节点反馈的应答消息，则表示应答失败，应重新发起 心跳报文： d 实时通信应答周期，由实时通信参数TimeoutwithoutAnswer设定； 处于通讯的下级节点连续MaxIdlePeriodAmount次后仍应答超时，心跳报文发送失败，则 认为通信故障，下层节点应主动断开当前连接，重新发起连接请求； 最大空闲周期数，由实时通信参数MaxIdlePeriodAmount设定； 处于通信的上级节点在检测到一条连接长时间空闲时，上级节点应主动断开连接： 服务器端或客户端在连续接收到MaxInvalidMessageAmount次无效报文后，应主动断开当 前连接，客户端在与服务端连接中断时，应主动向服务器端发起连接请求； 最多连续无效报文数，由实时通信参数MaxInvalidMessageAmount设定。
4.4通用报文结构定义
4.4通用报文结构定义
4.4.1报文格式定义
接口》，报文格式应满足： a）所有报文中的字段均采用大端格式存储； b）所有报文采用单包，且最大长度为8K字节
DB13/T5519.62022
发送方发出的报文必须满足请求报文格式，如请求代码、发送信息、接收信息等； 报文的完整性验证； 根据CRC算法来验证报文中的数据没有发生丢失和被篡改； CRC算法分为CRC8，CRC16,CRC16F以及CRC32等几种算法； AFC系统中的CRC算法采用CRC16校验方式： g CRC校验码根据数据包（报文头+报文体，不包含CRC校验字段本身）的内容生成，应先将 Header+Body导入内存流，然后计算CRC校验，最后将CRC赋值到结构体的CRC字段。
AFC系统各层级系统间的实时通信，应包括： ACC与LC之间的实时通信，ACC与LC应互为服务，任何一方有报文发送需要时都可以立即 向对方发送： b) LC与SC之间的实时通信，与ACC与LC的实时通信基本一致，更加侧重于与设备级的通信： 主要增加了设备模块的状态上传和查询，设备钱箱和票箱信息的上传和查询： C SLE与SC之间的实时通信，与SC与LC的实时通信基本一致，主要是客流统计数据
DB 13/T 5519. 62022
表4通讯报文列表（续
设备重启时、日始和网络恢复时，设备均应发起设备签到。 设备签到流程，应包括： a）第一步，时钟同步； b） 第二步，建立通信连接； c) 第三步，SC下发当前车站运营模式； d) 第四步，参数同步； e) 第五步，上传所属车站模式、参数版本、设备状态、软件版本； f） 第六步，上传文件。 ACC级EOD参数、TP参数如果不能同步，则该设备须进入暂停服务，并发报警信息， 其他参数不能同步时仅发报警信息
ACC与LC之间采用通信中间件作为实时数据传输的通道， 应在ACC通信服务器上部署中间件服务管理器，各条线路中心部署中间件客户端，通过中间件建 立的通道进行实时数据交换。
4. 10. 1物理接口
连接方式应由ACC与LC协商决定。
之间的通信传递宜采用支持互联互通的通信中间
4.10.3消息中间件架构
JC／T 2313-2015标准下载4. 10. 3. 1队列部署
4. 10.3.2队列管理器定义
DB 13/T5519.62022
表5需构建的队列管理
4.10.3.3通道配置
通道命名规则：QCH.LC.ACC.<线路编号> 端口约定，例如：端口号=1500+线路编号大桥主桥合拢及体系转换工程施工组织设计，则按此约定：一号线端口号1501，二号线端口号1502， 三号线端口号1503 通道配置举例见表7