TCN 项目中基于RS-485通信的工程应用研究

徐蔚中

（株洲中车时代电气股份有限公司，湖南 株洲 412001）

当今列车通信网络（TCN，Train Communication Network）正朝着高速率、多功能、大数据量等方向飞速发展，与现代社会互联网应用和信息科技领域的发展趋势相吻合。目前行业内的TCN 主要是基于多功能车辆总线（MVB，Multifunction Vehicle Bus）和绞线式列车总线（WTB，Wire Train Bus）来实现[1]，并且正朝着基于列车实时数据协议（TRDP，Train Real-time Data Protocol）的以太网通讯网络（ECN，Ethernet Consist Network）方向发展和推广。与此同时，在实际的TCN 应用中，由于技术、成本等原因，还可能存在着其他形式的现场总线网络介质和接口。RS-485 通信就是其中一种，由于其双绞线式总线成本低廉、抗干扰力较强、传输速率较高、便于实现等特点，仍有着较为广泛的应用。本文将结合工程项目中的实践经验，对RS-485主从通信接口转换技术要点进行研究和分析，形成公式，便于理解其技术要点，并助力于工程应用设计开发。

1 基本原理和项目实践介绍

实际项目运用的接口示意简化图如图1 所示，主设备Master 和从设备Slave 均有两个冗余接口（Port1和Port2），接口均为UART（通用异步收发器）。主、从设备上的每个接口均通过RS-485 总线与对方设备的对应接口连接，总线为差分数据传输方式，半双工通信。主、从设备间通过Port1 连接组成通道1，通过Port2连接组成通道2。

图1 RS-485 主从通信接口示意

需要主从通信双方协商确定的接口设置主要有表1所示几项（参数为示例值）。

表1 通信接口主要参数设置

示例为半双工主从通信机制，仅Master 设备能够根据应用层协议，轮询周期每50ms 主动发出一个数据帧，作为通信请求。Slave 设备在收到Master 设备的请求数据帧后，经过呼吸时间延时，根据应用层协议发出响应数据帧进行回复响应[2]。Master 的请求数据帧将同时从通道1 和通道2 发送至Slave 设备，Slave 设备默认从通道1 进行响应回复。Slave 设备如果连续5 个轮询周期（250ms）内均未收到Master 设备的请求数据帧，则切换至通道2 进行回复响应。若Master 设备在连续10 个轮询周期（500ms）内均未收到Slave 设备的响应回复，则视为通信异常。

上述UART 接口配置中的数据格式即为RS-485 通信的数据层协议。每次即将开始传送一个字符时，先发出一位逻辑“0”信号作为起始位，随后开始数据传输（本示例项目为8 位）。奇偶校验位通过将该bit 位置位为逻辑“1”或“0”，来控制数据中的逻辑“1”的数量为偶数（偶校验）或奇数（奇校验），本示例项目不配置奇偶校验位。

本字符传输结束后，随即发出1 位、1.5 位或2 位高电平，作为字符传输结束的标志。由于数据是在传输线上定时的，并且每一个设备都有其自己的时钟，很可能在通信中两台设备间会出现细微的不同步现象。因此停止位不仅仅是表示传输的结束，并且提供设备收发接口校正时钟同步的机会，适用于停止位的位数越多，不同时钟同步的容忍程度越大，但是数据传输率同时也越慢。

实际项目中应用层另需双方定义应用层的数据通信协议，示例Master 设备发送至Slave 设备的请求数据帧协议为30 个字节，Slave 设备发送至Master 设备的响应数据帧协议为10 个字节，帧头和帧尾标识均为固定值，数据帧的序号为0-255 逐帧增加，累计至255后重新赋值为0，以便区分不同数据帧。CRC 校验结果为针对B1 至B26/B6 数据的循环冗余校验结果（具体校验算法可结合实际确定）。

2 存在的问题与初步分析

在实际项目运用中，发现存在偶发性通信异常问题，导致应用业务故障，获取实际总线数据发现数据存在错乱的情况。

正常情况下在50ms 的轮询周期中，应为Normal所示每个轮询周期一帧请求数据后跟随一帧响应数据的情况。而异常情况下，会出现Error 所示三种情形：1、请求数据后跟随多帧响应数据；2、请求数据后无响应数据；3、数据错乱，数据帧不完整。

结合基本原理和项目实际情况分析，由于RS-485半双工通信的特点，总线上同一时间仅能够供给1 个设备发送数据，所以需采用主从轮询的方式进行通信[3]。某一设备在检测到总线上有数据传输时，应不允许自身数据发送。若同一时间双方或多方设备同时发送数据，则在总线上会出现数据碰撞的情况，导致数据错乱。此处的异常情形3即为主从双方设备同时发送数据，导致主设备的轮询数据无帧头（数据碰撞导致数据错乱）。异常情形1 为从设备自身未考虑半双工通信的特点，在收到主设备请求数据后多次重复发送响应数据。异常情形2 为从设备采样检测请求数据周期不满足要求，以及接收到的主设备请求数据错误或不完整，导致无法正确发出响应数据。

因此在实际的运用实践中，需结合通信方式和实际配置的特点，对涉及的接口参数和程序开发形成正确引导[4]，故对此类通信接口的特性展开研究是很关键的。

3 细化分析与研究

示例的半双工主从通信过程示意图如图2 所示，描述了一个通用示例周期的主从通信过程。在每个通信轮询周期中，主设备传输完一帧请求数据，且从设备正确接收后，应反馈且仅反馈一次响应数据帧。图中标出了各个关键时间参数，其值为示例值。图中参数具体含义如表2 所示。

图2 RS-485 通信过程通用示意

表2 通信过程时间参数说明

由于实际的程序运行和数据传输时间等都存在难以避免的误差，所以实际情况下上述所有参数都是理论值。尤其是主设备的tRound 与从设备的tCheck 之间不可能完全同步，导致二者时间会存在着各种程度的错位（图中体现为tCheck 与tRound 开始、结束时间点的错位），因此需考虑最差情况下的通信情形，以明确tCheck 的参数设置要求。

分析可知，各参数之间应满足以下关系：

tBlind+n*tCheck+tResponse≤tRound（n ≥1）

tResponse≥tBreath+tAck

另外，理论上tBlind≤tReq，最差情况下出于预留应考虑tBlind ≥tReq。

现拟定拟定tBlind=tReq tCheck，tResponse=tBreath+tAck，可得知tCheck 应满足：

tCheck ≤（tRound-tBlind-tResponse）/n（n ≥1）

其中tReq 与tAck 需根据通信接口波特率设置、数据传输格式和应用层协议数据帧长度进行计算。例如示例项目波特率为38.4kbps，传输每个字符（Byte）需消耗1 个起始位，8 个数据位和1 个停止位，共计10bit。请求数据帧为30Byte，响应数据帧为10Byte，可得知传输请求数据帧和响应数据帧分别需要7.8125ms 和2.6042ms。

为便于计算与预留时间余量，设定tReq=10ms，tBreath+tAck=10ms，则示例中tCheck 最大设置值（n=1时）应满足tCheck ≤30ms。且从设备应保证每次正确接收完请求数据后仅发送一帧响应数据。

4 结语

通过对RS-485 通信的原理及应用情景介绍和研究，深入了解了其在实际应用中的实现方式和技术要点，结合工程实践指出了在工程项目实践中需要避免的问题点，分析研究了通信接口应用参数的关系，最终以公式化的形式总结出其限制条件，对应用开发形成了引导性结论。在应用实践中可参考本文内容进行设计和问题排查，避免工程应用中出现设计问题导致的通信故障和功能缺陷，提高应用工程的效率和稳定性，保障实践应用的安全。