标准规范下载简介
DB13／T 5519.6-2022 轨道交通 AFC 系统线网技术要求 第6部分：数据传输.pdf简介：
DB13/T 5519.6-2022 是中国轨道交通行业标准，它详细规定了轨道交通自动售检票系统（AFC）的线网技术要求，其中第六部分主要关注数据传输。这一部分可能包括以下几个方面：
1. 数据传输协议：规定了系统内部以及与外部系统（如中央计算机系统、支付网关等）之间的数据交换格式、通信协议和标准，以确保数据的准确性和一致性。
2. 数据安全性：强调数据传输过程中的加密和保护措施，以防止数据在传输过程中被截取或篡改，保护乘客信息和个人隐私。
3. 数据传输速率：定义了系统在不同场景下（如高峰期、低峰期）的数据传输速率要求，以满足系统的实时性和效率需求。
4. 数据备份与恢复：规定了对关键数据的备份策略以及数据恢复的响应时间，以保证系统的连续性和可用性。
5. 远程管理和监控：可能涉及到数据传输对于远程监控系统、故障诊断和远程维护的支持。
6. 网络架构：可能对线网内的数据传输网络结构、节点分布和容错机制有详细的规定。
请注意，由于具体标准的内容可能需要查阅原文，上述内容仅为一般性的推测。对于详细的技术要求，建议阅读DB13/T 5519.6-2022 的完整文本。
DB13／T 5519.6-2022 轨道交通 AFC 系统线网技术要求 第6部分：数据传输.pdf部分内容预览：
DB13/T5519.62022
本文件的编写是为了给河北省内轨道交通AFC系统建设提供参考标准及规范。在这方面，我省 已经初步完成河北省轨道交通AFC系统线网技术要求标准文件的起草、制定和组织工作，拟由七部 分构成。 第1部分：系统结构及功能。目的在于进一步规范轨道交通AFC系统架构以及功能统一， 确立各层系统互联互通、不同设备接入的相关技术要求。 第2部分：终端与专用设备。目的在于进一步规范轨道交通AFC系统各类终端设备的技术 要求和功能，方便后期扩展，指导新线有序建设。 一第3部分：读写器应用。目的在于进一步规范轨道交通AFC系统读写器应用，为系统引入 新设备、新票种，实现系统的互联互通提供支持。 第4部分：人机界面。目的在于进一步规范轨道交通AFC系统各类终端设备人机交互界面 的统一，推动乘客人机交互界面应用的标准化，方便操作员维护，提高乘客使用的体验感。 第5部分：票卡应用标准。目的在于进一步规范轨道交通AFC系统中使用的实体票卡技术 要求统一，确保满足票卡的兼容性及新设备、新票种（或卡型）引入的要求。 一第6部分：数据传输。目的在于进一步规范轨道交通AFC系统中各级系统之间、设备与系 统之间的数据内容，促进后期建设及扩展的可持续发展。 一第7部分：数据接口。目的在于进一步规范轨道交通AFC系统各线路终端设备与车站计算 机、车站计算机与线路中央计算机、线路中央计算机与中央清分系统，以及城市轨道交通与一卡通 之间的接口。 结合我省实际轨道交通AFC系统事业建设情况，首要任务就是尽快建立明确的地方标准体系。 建设完善的技术规则而起草高质量的标准化文件，有利于保证河北省内轨道交通建设和后续新建线 路的顺利接入，有利于促进河北省轨道交通事业的可持续发展。
SYT 7419-2018 低温管道绝热工程设计、施工和验收规范.pdfDB 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消息中间件架构
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
4.10.3.4侦听器配置
ACC端的侦听器命名规则如下：
表8ACC队列管理器中侦听器列表
DB 13/T 5519. 62022
4.10.3.5队列定义
表9队列命名规则字段
通过使用MQMD结构GB／T 39115-2020标准下载，应可访问消息中的控制信息。 消息描述符结构见表10。
表10消息描述符结构
DB 13/T5519.62022
表10消息描述符结构（续）
CJJT229-2015 城镇给水微污染水预处理技术规程(缺首页)4.10.4. 2消息种类
4.10.4. 2消息种类
主要利用WebSphereMQ传送实时通信报文实现，ACC与LC之间传输的实时报文结构与线路内的报 文结构一致。