随便乱写的，个人备份

第一版的界面

美化优化后的第二版的界面

目录

第 1 章 绪论... 3

1.1. 背景与意义... 3

1.2. 国内外发展及应用现状... 4

1.2.1. 国内发展现状... 4

1.2.2. 国外发展现状... 5

第 2 章 临时限速服务器（TSRS）系统概述... 5

2.1. CTCS 列控系统与TSRS的定位... 5

2.1.1. CTCS-2/3级列控系统概述... 5

2.1.2. TSRS在列控系统中的作用... 6

2.2. TSRS系统总体要求... 7

2.2.1. 功能性要求... 7

2.2.2. 安全性与可靠性要求... 7

2.3. TSRS设备组成与交互关系... 8

第 3 章 TSRS技术要求与核心功能实现... 10

3.1. TSRS数据模型设计与实现... 10

3.1.1. TSR数据结构... 10

3.1.2. TSR状态管理... 11

3.2. TSRS管理模块功能实现... 12

3.2.1. 限速设置规则与校验（Create/Update TSR）... 12

3.2.1.1. 正线限速设置校验... 13

3.2.1.2. 侧线限速设置校验... 14

3.2.1.3. 时间校验... 15

3.2.2. 限速命令操作要求（Issue/Cancel/Delete TSR）... 15

3.2.3. 限速命令状态周期性判定... 16

3.3. TSRS服务端通信机制... 17

3.3.1. TCP/IP通信协议设计... 17

3.4. TSRM功能模拟... 20

3.4.1. 限速命令列表与详情... 20

3.4.2. 客户端连接状态显示... 21

3.4.3. 操作日志记录... 21

第 4 章 TSRS客户端功能与交互... 21

4.1. 客户端连接管理... 21

4.1.1. 连接与断开... 22

4.1.2. 自动重连机制... 23

4.2. 限速信息接收与展示... 23

4.2.1. TSRS_UPDATE消息处理... 23

4.2.2. 有效限速信息筛选与显示... 24

4.3. 客户端请求与日志... 24

4.3.1. 刷新请求... 24

4.3.2. 客户端操作日志... 25

第 5 章 系统实现与测试... 25

5.1. 编程语言与开发环境... 25

5.2. GUI界面设计... 26

5.2.1. 服务端GUI 26

5.2.2. 客户端GUI 27

5.3. 功能测试与验证... 27

5.3.1. 限速创建与校验测试... 27

5.3.2. 限速生命周期管理测试... 28

5.3.3. 通信与数据同步测试... 29

5.3.4. 异常处理测试... 30

第 6 章 总结与展望... 31

6.1. 研究成果... 31

6.2. 不足之处... 31

6.3. 未来展望... 32

第 1 章 绪论

1.1. 背景与意义

随着中国铁路事业的飞速发展，高速铁路网络的建设和运营达到了前所未有的规模和水平。列车运行控制系统（CTCS）作为高速铁路安全运营的核心保障，其重要性不言而喻。在复杂的铁路运营环境中，除了预设的线路参数外，还经常会遇到因施工、自然灾害、设备故障等突发情况导致的临时性速度限制。这些临时限速（TSR，Temporary Speed Restriction）需要被及时、准确地发布、管理和撤销，以确保列车运行安全，同时最大限度地减少对运输效率的影响。

传统的临时限速管理方式可能依赖人工传达、纸质记录或较为分散的电子系统，这在高速、高密度运营的现代铁路中存在显著的局限性：信息传递效率低、准确性难以保障、管理复杂且易出错，严重影响了列车运行安全和调度指挥的自动化水平。为此，构建一套集中化、自动化、安全可靠的临时限速服务器（TSRS，Temporary Speed Restriction Server）系统显得尤为重要。

TSRS旨在实现对临时限速命令的集中管理和高效分发。它作为列控系统地面设备的重要组成部分，能够接收来自调度中心的限速设置和取消指令，对命令参数进行严格校验，并将有效的限速信息及时、准确地传输给无线闭塞中心（RBC）、列控中心（TCC）等列控地面设备，进而由RBC和TCC将限速信息传递给车载设备，实现对列车的实时速度防护。一个高效、可靠的TSRS系统对于提升铁路运输的安全裕度、优化调度指挥流程、提高整体运营效率具有深远的意义。

本次课程设计正是基于上述背景，旨在通过模拟实现一个简化的TSRS系统，深入理解其核心功能、技术要求以及在列控系统中的作用。通过实际编程，掌握TSRS的数据管理、通信机制、命令处理逻辑和用户界面设计，为今后参与更复杂的铁路信号系统开发打下基础。

1.2. 国内外发展及应用现状

1.2.1. 国内发展现状

我国在列车运行控制系统及相关辅助系统的发展上，始终坚持“引进、消化、吸收、再创新”的路线。早期借鉴欧洲ETCS（European Train Control System）标准，结合自身国情，逐步形成了具有中国特色的CTCS体系。

在临时限速管理方面，国内铁路行业已经认识到集中管理的重要性。早期的列控系统可能通过列控中心（TCC）或RBC直接处理临时限速，但随着线路里程的增长和限速事件的增多，迫切需要一个专门的服务器来集中管理这些动态信息。2012年4月颁布的《临时限速服务器技术规范（暂行）》（以下简称《TSRS技术规范》）正是这一需求的产物。该规范详细定义了TSRS的系统需求、技术要求、技术指标和运行环境要求，为国内TSRS的研制、生产和应用提供了指导性文件。

目前，国内各铁路局和科研单位已普遍部署和使用了TSRS系统，其主要功能包括：

• 集中存储和管理： 将所有临时限速命令统一存储，方便查询、编辑和维护。
• 参数校验： 对输入的限速命令进行严格的合法性校验，例如限速值范围、里程标格式、时间逻辑等，防止非法或冲突的命令进入系统。
• 状态管理： 根据限速命令的生命周期（拟定、下达、取消、失效等）进行状态转换，并提供相应的操作接口。
• 信息分发： 通过标准接口（如与RBC、TCC、CTC的接口）将限速信息下达给相关地面设备。
• 辅助提示： 提供限速设置时机、超时未执行等辅助提示功能，支持调度决策。
• 日志记录： 详细记录所有操作和系统事件，便于问题追溯和责任认定。

这些TSRS系统在实际运营中发挥了关键作用，显著提升了临时限速信息的管理效率和安全性。在仿真测试领域，国内高校和科研机构也开展了相关研究，例如兰州交通大学常峰在2017年完成的硕士论文《CTCS-2级列控仿真培训系统——临时限速子系统的研究》[21]就专门针对临时限速子系统进行了深入探讨和仿真实现，为本次设计提供了重要参考。

1.2.2. 国外发展现状

在国际上，特别是欧洲，临时限速的管理通常集成在ETCS体系中。ETCS L2/L3系统依赖RBC与车载设备进行无线通信，临时限速信息作为行车许可数据的一部分，由RBC通过无线链路直接下发给列车。欧洲的RBC本身就承担了动态数据的管理和下发功能，因此，可能不设独立于RBC之外的“TSRS”实体，而是将临时限速管理逻辑内嵌在RBC或与之紧密耦合的中央管理系统中。

例如，ETCS允许通过Generic Balise Group（通用应答器组）或ETCS无线电网络传输临时限速信息。操作员在中央交通管理系统（TMS，Traffic Management System）中输入临时限速信息，这些信息随后被传输到相关的RBC。RBC在构建行车许可时，会根据这些限速信息动态调整允许速度曲线，并下发给列车。ETCS系统的设计强调了数据的安全性和互操作性，确保不同厂商的设备能够协同工作。

尽管名称和具体实现可能有所差异，但国内外对于临时限速管理的核心需求是共通的：确保动态变化的限速信息能够高效、准确、安全地从管理端传递到列车端，并对列车运行进行实时防护。

第 2 章 临时限速服务器（TSRS）系统概述

2.1. CTCS 列控系统与TSRS的定位

中国列车运行控制系统（CTCS）是保障铁路列车安全高效运行的核心技术系统。根据线路速度等级和功能要求的不同，CTCS系统分为CTCS-0到CTCS-4五个等级。本次课程设计涉及的临时限速服务器（TSRS）主要服务于CTCS-2级和CTCS-3级列控系统，这两个级别都对限速信息的动态管理有较高要求。

2.1.1. CTCS-2/3级列控系统概述

• CTCS-2级列控系统：
  CTCS-2级是基于轨道电路和点式应答器传输列车行车许可信息，并采用目标距离连续速度控制模式监控列车安全运行的列控系统。它面向提速干线和客运专线，适用于多种线路速度区段。其主要特点包括：
  • 地面设备： 采用ZPW-2000系列无绝缘轨道电路检测列车占用、检查列车完整性，并连续向列车传送行车许可、前方空闲闭塞分区数量、车站进路速度等信息。点式应答器（有源/无源）用于提供精确的定位信息、线路基本参数、以及可变信息如临时限速和进路信息。列控中心（TCC）是地面设备的“大脑”，负责处理联锁进路信息、生成行车许可，并通过电子单元（LEU）控制有源应答器下发可变信息。
  • 车载设备： 包含车载安全计算机（VC）、轨道电路信息接收单元（TCR）、应答器传输模块（BTM）、人机界面（DMI）、测速测距单元等。车载设备根据地面发送的控车信息、线路数据和列车自身参数，实时生成目标距离模式曲线，并对列车速度进行连续监控和防护，防止超速。
  • 闭塞方式： 采用准移动闭塞（准连续闭塞）。
• CTCS-3级列控系统：
  CTCS-3级是在CTCS-2级基础上发展而来，其核心是基于无线传输（GSM-R）信息，并采用轨道电路辅助检查列车占用（或只用于检测断轨），点式设备主要用于传送定位信息。CTCS-3级可叠加在CTCS-2级之上，具有更高的传输能力和更灵活的闭塞方式，适用于高速列车运行。其关键区别在于引入了无线闭塞中心（RBC），RBC通过GSM-R网络与车载设备进行双向通信，实时发送行车许可和限速信息，并接收列车位置报告。

2.1.2. TSRS在列控系统中的作用

TSRS在CTCS-2/3级列控系统中扮演着临时限速集中管理和分发中心的角色。它不直接控制列车或信号设备，而是作为辅助系统，为核心列控设备（如RBC、TCC）提供准确、实时的临时限速数据。

根据《TSRS技术规范》，TSRS的主要定位和作用体现在以下几个方面：

• 集中管理平台： TSRS负责对线路上的所有临时限速命令进行集中管理。这包括限速命令的录入、修改、删除、下达、取消等全生命周期管理。通过一个统一的接口，调度员或维护人员可以方便地操作这些限速信息，避免了信息分散、管理混乱的问题。
• 数据源与分发器： TSRS接收来自调度中心（CTC）的临时限速指令，并将其作为权威数据源进行存储。随后，它根据自身管辖范围，将限速命令拆分并下发给相关的下级执行设备，如无线闭塞中心（RBC）和列控中心（TCC），甚至与相邻的TSRS进行信息交互。这一机制确保了限速信息的“一处录入，多处使用”，减少了数据冗余和不一致的风险。
• 信息校验与一致性保障： TSRS对接收到的限速命令参数进行严格的合法性校验，例如里程标的有效性、限速值的合规性、时间逻辑的正确性等（规范 5.3.1.1）。这在源头上避免了错误或冲突的限速信息进入列控系统。同时，TSRS还负责检测与TCC、RBC等设备的限速命令执行一致性，并在不一致时进行告警或采取刷新措施（规范 5.7.1.5）。
• 辅助决策与提示： TSRS能够根据限速命令的计划开始时间提前向CTC发送激活提示，或对超时未执行的命令提供提示（规范 5.4）。这有助于调度员掌握限速命令的执行状态，并及时采取必要行动。
• 安全与可靠性要求： 考虑到临时限速对列车运行安全的关键影响，TSRS本身必须满足故障-安全原则，达到SIL4（Safety Integrity Level 4）安全完整性等级要求（规范 4.1.1.2）。这意味着TSRS在设计、实现和运行过程中，需要采取严格的安全措施，以防止因系统自身故障导致的安全风险。

总而言之，TSRS是现代高速铁路列车运行控制系统中不可或缺的一环，它通过集中化、自动化、安全可靠的方式，实现了对临时限速信息的全生命周期管理和高效分发，从而为列车运行提供动态、精确的速度防护，保障了铁路运输的安全与效率。

2.2. TSRS系统总体要求

《临时限速服务器技术规范（暂行）》（2012年4月）[CTCS-TSRS-2012-04] 对TSRS的系统总体要求进行了明确规定，这些要求涵盖了系统的功能、硬件、安全性和可靠性等多个方面。本节将依据规范，结合本次课程设计的实现内容，对这些要求进行概述。

2.2.1. 功能性要求

根据《TSRS技术规范》4.4节“功能要求”及5.2节“限速设置规则”、5.3节“限速命令的操作要求”等，TSRS应具备以下核心功能：

• 启动自检与安全侧初始化（规范 4.4.1.1, 5.1）： TSRS启动后应进行周期性设备完整性自检，自检失败则禁止投入运行。同时，应载入本地存储的限速命令信息并初始为未激活状态，并向CTC请求限速初始化确认命令，与CTC时钟同步。
• 临时限速命令管理（规范 4.4.1.2, 5.2, 5.3）： 这是TSRS的核心功能，包括：
  • 存储： 能够存储可执行的临时限速命令，且不存储已删除或已取消的命令（规范 5.6）。
  • 校验： 对来自CTC、相邻TSRS及边界转换站TCC的临时限速命令参数信息进行严格校验（规范 5.3.1.1）。
  • 删除： 只允许删除处于“未执行”状态的限速命令（规范 5.3.1.3），在本次模拟中，“未执行”主要指“拟定”、“已取消”或“已失效”状态。
  • 设置： 临时限速命令应包含调度命令号、线路号、里程标、限速值、计划执行时间等信息。正线和侧线限速有不同的限速值档位和里程标设置规则。正线限速值按八档设置，最低45km/h；侧线限速值设45km/h、80km/h两档（规范 5.2.1.1, 5.2.1.2, 5.2.1.3）。起终点里程标应按线路正向运行方向设置，且不得设置在线路短链点内（规范 5.2.1.6, 5.2.1.7）。
  • 验证与下达执行： 只允许对“未执行”的命令进行验证，并只允许对“验证通过”的命令下达执行（规范 5.3.1.4, 5.3.1.5）。
  • 取消： 只接受已处于“执行状态”的限速设置命令的取消命令的验证或执行操作（规范 5.3.1.7）。取消命令为立即下达方式，且须与要取消的限速设置命令参数一致，不得分段或覆盖取消（规范 5.2.1.8, 5.2.1.9）。
  • 拆分下达： TSRS应根据TCC、RBC及相邻TSRS的临时限速管辖范围，对临时限速命令进行拆分，并发送给相应执行设备（规范 5.5.1.1）。
  • 状态综合与判定： 对限速命令在TCC、RBC及相邻TSRS的验证和执行结果进行判定，并向CTC报告综合结果（规范 5.5.1.3, 5.5.1.4）。
• 限速设置辅助提示（规范 4.4.1.3, 5.4）： TSRS应根据计划开始时间提前发送激活提示，并对超时未执行的命令提供提示。
• 自诊断与维护（规范 4.4.1.4）： 具备设备及各通信接口的故障自诊断和辅助维护功能，故障定位到板级或可更换单元。
• 时钟同步（规范 4.4.1.5, 5.1.1.4）： 具备保持与CTC系统时钟同步功能。

2.2.2. 安全性与可靠性要求

TSRS作为列控系统的重要组成部分，其安全性和可靠性是至关重要的。

• 故障-安全原则与SIL4（规范 4.1.1.2, 8.1.1.4）： TSRS应符合故障-安全原则，满足SIL4（Safety Integrity Level 4）安全完整性等级要求。SIL4是最高级别的安全完整性等级，意味着系统在出现故障时，必须以安全方式失效（如进入安全状态），且其失效概率极低。这通常要求采用冗余、多样性、失效-安全设计等复杂技术。
• 硬件冗余结构（规范 4.1.1.3, 4.3.1.2）： TSRS应采用硬件冗余结构，设备单系故障不应影响系统运用。主机应采用符合故障-安全原则的安全计算机平台进行安全相关逻辑运算和控制，接口单元也应采用硬件冗余。
• RAMS要求（规范 8.1）： TSRS的设计、实现过程应符合GB/T 21562-2008（EN 50126）、EN 50128-2011、EN 50129-2003及TB/T 2615-94等标准的相关要求，涵盖可靠性（Reliability）、可用性（Availability）、可维修性（Maintainability）和安全性（Safety）。其中，平均故障间隔时间（MTBF）应大于或等于10^5小时（规范 8.1.1.3）。
• 安全通信协议（规范 6.1.1.6, 6.1.1.8, 6.1.1.10, 6.1.1.12）： TSRS与CTC、TCC、RBC、相邻TSRS之间应通过信号系统安全数据网连接，并采用铁路信号安全通信协议（如RSSP-I/II）进行信息交互，确保数据传输的完整性、真实性和时效性。
• 电磁兼容与防雷（规范 10）： TSRS应符合GB/T 24338.5等电磁兼容标准，具备良好的抗扰度和低发射能力。同时，应满足TB/T 3074-2003的防雷性能要求，具备对雷电电脉冲的防护能力。
• 电源要求（规范 9）： TSRS设备用电为I级负荷，应使用独立的专用电源，且各冗余模块应采取独立电源模块，保证供电的可靠性。
• 环境要求（规范 11）： TSRS应能在特定的环境温度、湿度和海拔高度范围内稳定工作。

本次课程设计在模拟实现时，主要聚焦于功能性要求的实现，并对部分安全性要求（如通信协议的长度前缀、JSON封装，以及状态校验逻辑）进行了简化模拟。对于硬件冗余、SIL4等级的严格论证和测试，以及复杂的RAMS指标和电磁兼容、防雷等物理层面的要求，受限于仿真环境和时间，并未进行深入实现，但代码设计中体现了模块化、可扩展性的思路，为未来的安全增强预留了空间。

2.3. TSRS设备组成与交互关系

根据《TSRS技术规范》4.2节“设备组成”及6.1节“接口要求”，TSRS系统通常由主机、维护终端（TSRM）和接口单元组成，并与多种外部设备进行信息交互。

TSRS设备组成：

1. 主机： 临时限速服务器的核心，负责实现临时限速命令的存储、校验、管理、拆分、下达等核心逻辑功能。它应采用符合故障-安全原则的安全计算机平台。
2. 维护终端（TSRM）： 用于TSRS的维护与记录功能。通常提供图形用户界面，供调度员或维护人员进行限速命令的拟定、查看、操作，以及查询系统日志、监控系统状态等。TSRM通过以太网与主机进行数据通信。
3. 接口单元： 实现TSRS与外部设备的信息交互功能。接口单元通常采用硬件冗余结构，确保通信的可靠性。

TSRS与其他设备的连接关系与信息交互：

TSRS作为一个中心化的限速管理系统，与列控系统内的多个关键设备紧密相连，形成复杂的通信网络。主要的交互关系如下：

• 与列控中心（CTC）：
  • 连接方式： TSRS与CTC之间通过冗余的专用2M数字通道互连（规范 6.1.1.3）。
  • 信息交互：
    • CTC向TSRS下达临时限速的设置、修改、取消、删除等操作命令（规范 5.2.1.10）。
    • TSRS向CTC报告限速命令的验证结果、执行结果、状态变化（如激活提示、超时未设置提示、未知状态警示等），以及自身的初始化状态（规范 5.3.1.9, 5.4.1.1, 5.5.1.3, 5.5.1.4, 5.5.1.5, 5.7.1.1）。
    • TSRS与CTC时钟同步（规范 5.1.1.4）。
    • 安全协议采用RSSP-II，TSRS为服务器端（规范 6.1.1.6）。应用协议遵循《TSRS-CTC接口规范》。
• 与无线闭塞中心（RBC）：
  • 连接方式： TSRS与RBC之间通过信号系统安全数据网连接（规范 6.1.1.2）。
  • 信息交互： TSRS根据RBC的管辖范围，对限速命令进行拆分后下发给RBC执行。RBC将限速信息传递给车载设备进行防护。TSRS需要判定RBC对限速命令的验证和执行结果（规范 5.5.1.1, 5.5.1.3, 5.5.1.4）。当TSRS重启或通信中断恢复时，需要对RBC限速命令刷新（规范 5.5.1.6）。RBC重启时，TSRS应对其补发限速命令（规范 5.5.1.7）。
  • 安全协议采用RSSP-II，TSRS为服务器端（规范 6.1.1.10）。应用协议遵循《RBC-TSRS接口规范》。
• 与列控中心（TCC）：
  • 连接方式： TSRS与TCC之间通过信号系统安全数据网连接（规范 6.1.1.2）。
  • 信息交互： 与RBC类似，TSRS向TCC下发拆分后的限速命令，并判定其验证和执行结果。TCC获取限速信息后，可能通过有源应答器下发给列车。
  • 安全协议采用RSSP-I（规范 6.1.1.8）。应用协议遵循《TSRS-TCC接口规范》。
• 与相邻TSRS：
  • 连接方式： TSRS与相邻TSRS之间通过信号系统安全数据网连接（规范 6.1.1.2）。
  • 信息交互： 跨调度台界的临时限速命令需由两侧调度台人工拆分后分别下达（规范 5.2.1.11）。相邻TSRS之间需要进行限速命令的协调和刷新，以保证跨管界限速命令的连贯性和一致性（规范 5.5.1.6, 5.7.1.3）。
  • 安全协议采用RSSP-II，TSRS设备编号较小者为服务器端（规范 6.1.1.12）。应用协议遵循《TSRS-TSRS接口规范》。
• 与现有转换站TCC：
  • 对于设有TSRS的线路与未设TSRS的线路衔接处，TSRS从转换站TCC获取限速命令，并向转换站下达限速命令（规范 5.2.1.12）。

在本次 TSRSui.py 的实现中，我们模拟了TSRS的主机功能，并设计了与维护终端（TSRM）相结合的GUI界面。同时，通过TCP/IP通信模拟了与外部“客户端”（可以代表RBC、TCC或相邻TSRS）的连接，实现了限速命令的创建、管理和向客户端的广播更新。虽然未完全实现所有接口协议的细节（如RSSP-I/II），但采用了长度前缀+JSON的消息封装方式，模拟了应用层消息传输的基本安全要求，并实现了核心的业务逻辑交互。

第 3 章 TSRS技术要求与核心功能实现

TSRSui.py 文件作为本次课程设计的核心实现，主要模拟了《临时限速服务器技术规范（暂行）》中对TSRS主机和部分TSRM的功能要求。本章将详细介绍其数据模型、核心管理逻辑以及通信机制的实现。

3.1. TSRS数据模型设计与实现

为了有效地管理临时限速命令，系统首先需要定义一个清晰、完整的数据结构来表示一个限速命令。在 TSRSui.py 中，TSR 类承担了这一角色。

3.1.1. TSR数据结构

TSR 类（Temporary Speed Restriction）对应了规范 5.2.1.1 中对临时限速命令信息的要求，并增加了系统内部管理所需的字段。

python复制代码

class TSR:

    def __init__(self, data):

        self.id = data.get('id', str(uuid.uuid4()))  # 唯一标识符，使用UUID生成

        self.dispatch_command_no = data.get('dispatch_command_no', '')  # 调度命令号

        self.line = data.get('line', '')  # 线路号 (例如 京沪高铁)

        self.line_type = data.get('line_type', '正线')  # 线路类型: '正线' 或 '侧线'

        self.track = data.get('track', '')  # 股道 (例如 上行正线, 下行侧线)

        self.start_location = data.get('start_location', '')  # 起始里程标 (规范 5.2.1.1)

        self.start_block_section = data.get('start_block_section', '')  # 起始正向闭塞分区号 (规范 5.2.1.1)

        self.end_location = data.get('end_location', '')  # 终点里程标 (规范 5.2.1.1)

        self.end_block_section = data.get('end_block_section', '')  # 终点正向闭塞分区号 (规范 5.2.1.1)

        self.speed_limit = int(data.get('speed_limit', 0))  # 限速值 (规范 5.2.1.1)

        self.station_no = data.get('station_no', '')  # 车站编号 (仅侧线需要, 规范 5.2.1.1)

        # 时间字段处理：从ISO格式字符串或datetime对象转换

        start_time = data.get('start_time')

        if isinstance(start_time, str):

            self.start_time = datetime.fromisoformat(start_time) if start_time else None

        elif isinstance(start_time, datetime):

            self.start_time = start_time

        else:

            self.start_time = None

        end_time = data.get('end_time')

        if isinstance(end_time, str):

            self.end_time = datetime.fromisoformat(end_time) if end_time else None

        elif isinstance(end_time, datetime):

            self.end_time = end_time

        else:

            self.end_time = None

        self.status = data.get('status', '拟定')  # 状态: 拟定, 已下达, 已取消, 已失效, 未知状态

        self.operator = data.get('operator', '未知')  # 操作员

设计要点与规范对应：

• 唯一标识符 id： 使用 uuid.uuid4() 生成，确保每条限速命令在全球范围内的唯一性，便于系统内部管理和跨系统引用。
• 必填信息： dispatch_command_no、line、track、start_location、end_location、speed_limit、start_time、end_time 这些字段直接对应规范 5.2.1.1 的要求。
• 线路类型 line_type： 区分“正线”和“侧线”，这是因为两者在限速值档位和里程标设置上存在差异（规范 5.2.1.2, 5.2.1.3）。
• 里程标与闭塞分区： start_location, end_location, start_block_section, end_block_section 对应规范对限速区段位置的描述。特别地，对于侧线，里程标固定为 K0000+000 和 K9999+999，且需增加 station_no 字段（规范 5.2.1.1）。
• 限速值 speed_limit： 存储限速的具体数值，后续会根据线路类型进行合法性校验。
• 时间字段 start_time 和 end_time： 存储计划执行开始和结束时间。使用 datetime 对象方便进行时间比较和格式化。在数据传输时，会转换为ISO格式的字符串进行序列化。
• 状态 status： 这是一个关键字段，用于表示限速命令的生命周期，包括“拟定”、“已下达”、“已取消”、“已失效”等。这与规范 5.3 节的“限速命令的操作要求”和 5.5.1.4/5.5.1.5 对限速状态的判定紧密相关。
• 操作员 operator： 记录对限速命令进行操作的用户或系统实体，便于追溯。

3.1.2. TSR状态管理

TSR 类中包含了两个辅助方法 is_active() 和 is_expired() 用于判断限速命令的当前状态：

• is_active() 方法：

python复制代码

def is_active(self):

    """判断当前TSR是否在生效时间内且状态为'已下达'"""

    now = datetime.now()

    return (self.status == '已下达' and

            self.start_time and self.end_time and

            self.start_time <= now <= self.end_time)

此方法判断限速命令是否当前正在执行。它要求命令状态为“已下达”，并且当前时间在计划的生效时间范围内。这对于客户端（如模拟的列车运行终端）筛选和显示当前有效的限速信息至关重要。

• is_expired() 方法：

python复制代码

def is_expired(self):

    """判断当前TSR是否已失效"""

    now = datetime.now()

    return self.status == '已下达' and self.end_time and now > self.end_time

此方法用于判断限速命令是否已过期。它主要被 TSRManager 中的周期性检查机制调用，以将过期的“已下达”状态的限速命令自动更新为“已失效”状态，对应规范 5.5.1.4 “TSRS系统自动对限速命令的失效时间进行判定”和 5.5.1.5 “规定了过期限速命令的处理”。

3.2. TSRS管理模块功能实现

TSRManager 类是整个服务端的核心业务逻辑层，负责维护所有 TSR 对象的集合，并提供对这些对象的创建、修改、删除、下达、取消等操作，同时实现对操作的合法性校验和状态管理。它还包含一个定时器，用于周期性地检查限速命令的状态。

python复制代码

class TSRManager(QObject):

    tsr_updated = pyqtSignal() # 定义信号，用于通知GUI或其他模块数据已更新

    def __init__(self):

        super().__init__()

        self.tsrs = [] # 存储TSR对象的列表

        self._check_timer = QTimer(self) # 定时器，用于周期性检查限速状态

        self._check_timer.timeout.connect(self._check_tsr_status)

        self._check_timer.start(5000) # 每5秒检查一次，模拟规范 5.5.1.4

        # 模拟一些初始数据用于演示

        self.create_tsr(...)

        self.create_tsr(...)

关键设计：

• tsrs 列表： 作为内存中的数据库，存储所有 TSR 实例。
• tsr_updated 信号： 这是一个PyQt信号。当 tsrs 列表中的数据发生任何变化（创建、修改、删除、状态改变）时，都会发射此信号。服务端GUI会监听此信号，并调用 refresh_list() 方法更新显示。更重要的是，服务端TCP/IP逻辑也会监听此信号，从而触发向所有连接客户端的限速数据广播（server_instance.broadcast_tsrs()）。
• _check_timer 定时器： 实现了规范 5.5.1.4 中“TSRS系统自动对限速命令的失效时间进行判定”的功能。它每隔5秒调用 _check_tsr_status 方法，检查所有“已下达”且已过期的限速命令，将其状态自动更新为“已失效”。

3.2.1. 限速设置规则与校验（Create/Update TSR）

TSRManager 中的 create_tsr() 和 update_tsr() 方法负责接收新的或修改后的限速命令数据，并进行严格的参数校验，以确保其符合《TSRS技术规范》5.2节的各项规则。

校验逻辑的核心在于识别线路类型（正线或侧线），然后应用相应的规则。任何不符合规则的输入都会导致校验失败，并返回错误信息。

校验实现细节：

create_tsr(self, data, operator='管理中心') 和 update_tsr(self, tsr_id, data, operator='管理中心') 方法中都包含了类似的校验逻辑，它们返回一个元组 (tsr_object, errors_list)。

python复制代码

        errors = []

        # 5.2.1.1 临时限速命令应包括调度命令号、线路号、起始里程标、终点里程标、限速值、计划执行开始时间、计划执行结束时间等信息。

        # 5.2.1.2 最低限速值45km/h，最长限速区长度为TSRS对应的调度台管界范围。

        # 5.2.1.3 侧线临时限速值设45km/h、80km/h两档。

        # 5.2.1.6 临时限速命令的起、终点位置应按线路正向运行方向设置。

        # 5.2.1.7 临时限速命令的起点与终点均不得设置在线路短链点内。(此处简化，仅校验非空)

        # 1. 基础信息非空校验

        if not data.get('dispatch_command_no'):

            errors.append("必须填写调度命令号")

        if not data.get('line'):

            errors.append("必须填写线路")

        if not data.get('track'):

            errors.append("必须填写股道")

        if not data.get('start_time'):

            errors.append("必须填写生效时间")

        if not data.get('end_time'):

            errors.append("必须填写失效时间")

        line_type = data.get('line_type')

        speed_limit = int(data.get('speed_limit', 0)) # 统一转换为整数进行比较

3.2.1.1. 正线限速设置校验

针对 line_type == '正线' 的情况，校验逻辑如下：

• 里程标与闭塞分区非空： 规范 5.2.1.1 要求正线限速命令包含起始里程标、终点里程标、起始正向闭塞分区号、终点正向闭塞分区号。因此，这些字段必须填写。

python复制代码

        if not data.get('start_location'):

            errors.append("正线必须填写起始里程标")

        if not data.get('end_location'):

            errors.append("正线必须填写终点里程标")

        if not data.get('start_block_section'):

            errors.append("正线必须填写起始闭塞分区号")

        if not data.get('end_block_section'):

            errors.append("正线必须填写终点闭塞分区号")

• 限速值档位与范围： 规范 5.2.1.2 规定正线限速值按八档（45、60、80、100、120、160、200、250km/h）设置，最低限速值45km/h。代码中虽然推荐这些档位，但允许用户输入这些范围内的任意值，并进行提示，但如果超出最低或最高限制，则直接报错。

python复制代码

        valid_speeds_main_line = [45, 60, 80, 100, 120, 160, 200, 250]

        if speed_limit not in valid_speeds_main_line:

            if speed_limit < 45 or speed_limit > 250:

                errors.append(

                    f"正线限速值必须在 {min(valid_speeds_main_line)} 到 {max(valid_speeds_main_line)} 之间。")

            elif speed_limit not in valid_speeds_main_line:

                errors.append(f"正线限速值推荐为 {','.join(map(str, valid_speeds_main_line))} 中的一档。")

• 里程标顺序： 规范 5.2.1.6 规定临时限速命令的起、终点位置应按线路正向运行方向设置。虽然未进行复杂的里程标解析和比较，但至少保证起终点里程标不能相同（简化处理）。

python复制代码

        if data.get('start_location') == data.get('end_location') and data.get('start_location') != '':

            errors.append("起始里程标和终点里程标不能相同。")

• 短链点（简化）： 规范 5.2.1.7 规定起点与终点均不得设置在线路短链点内。此处仅通过非空校验间接模拟，未进行实际短链点检测。

3.2.1.2. 侧线限速设置校验

针对 line_type == '侧线' 的情况，校验逻辑如下：

• 车站编号必填： 规范 5.2.1.1 规定侧线临时限速命令应增加车站编号信息。

python复制代码

        if not data.get('station_no'):

            errors.append("侧线必须填写车站编号")

• 里程标固定值： 规范 5.2.1.1 规定侧线起点与终点里程标固定为 K0000+000 和 K9999+999。代码中强制校验这两个值。

python复制代码

        if data.get('start_location') != 'K0000+000' or data.get('end_location') != 'K9999+999':

            errors.append("侧线起始里程标和终点里程标必须固定为'K0000+000'和'K9999+999'。")

为了用户体验，TSRDetailDialog 在选择“侧线”时，会自动将这两个里程标填入并设置为只读，减少用户输入错误。

• 限速值档位： 规范 5.2.1.3 规定侧线临时限速值设45km/h、80km/h两档。代码中强制校验只能是这两个值。

python复制代码

        valid_speeds_side_line = [45, 80]

        if speed_limit not in valid_speeds_side_line:

            errors.append(f"侧线限速值必须为 {','.join(map(str, valid_speeds_side_line))} 中的一档。")

同样，TSRDetailDialog 在选择“侧线”时，会限制限速值的可选范围。

3.2.1.3. 时间校验

• 生效时间早于失效时间： 无论是正线还是侧线限速，计划执行开始时间都必须早于计划执行结束时间。

python复制代码

    if data.get('start_time') and data.get('end_time') and data['start_time'] >= data['end_time']:

        errors.append("生效时间必须早于失效时间")

所有校验完成后，如果 errors 列表非空，则返回 (None, errors)，表示创建或更新失败；否则，创建/更新 TSR 对象，添加到列表中，并返回 (tsr, [])。

3.2.2. 限速命令操作要求（Issue/Cancel/Delete TSR）

TSRManager 实现了对限速命令生命周期中的关键操作，并严格遵循规范中对操作状态的限制。

3.2.2.1. 删除限速命令

• delete_tsr(self, tsr_id, operator='管理中心')：
  • 规范 5.3.1.3： “TSRS只允许删除未执行的限速命令。”
  • 实现： 代码中将“未执行”扩展为 '拟定'、'已取消' 和 '已失效'。因为已取消的限速不再对列车产生作用，已失效的限速也已自动过期不再执行。这些状态下的限速命令通常是需要被清理的。

python复制代码

    for i, tsr in enumerate(self.tsrs):

        if tsr.id == tsr_id:

            if tsr.status not in ['拟定', '已取消', '已失效']:

                return False, "只有'拟定'、'已取消'或'已失效'状态的限速可以删除"

            del self.tsrs[i]

            self._notify_update()

            return True, "删除成功"

    return False, "未找到指定限速"

删除成功后，会通知数据更新，从而触发客户端的限速列表刷新。

3.2.2.2. 验证与下达限速命令

• issue_tsr(self, tsr_id, operator='管理中心')：
  • 规范 5.3.1.4： “TSRS只允许对未执行的限速命令验证。”（代码中简化为编辑完成后直接下达，隐含了验证通过）
  • 规范 5.3.1.5： “TSRS只允许对验证通过的限速命令下达执行。”
  • 实现： 只有状态为 '拟定' 的限速命令可以被下达。一旦下达，其状态变为 '已下达'。

python复制代码

    for tsr in self.tsrs:

        if tsr.id == tsr_id:

            if tsr.status == '拟定':

                tsr.status = '已下达'

                tsr.operator = operator

                self._notify_update()

                return True, "下达成功"

            return False, "只能下达'拟定'状态的限速"

    return False, "未找到指定限速"

这模拟了调度员对限速命令的最终确认，并使其生效。

3.2.2.3. 取消限速命令

• cancel_tsr(self, tsr_id, operator='管理中心')：
  • 规范 5.3.1.7： “TSRS只接受已处于执行状态的限速设置命令的取消命令的验证或执行操作。”
  • 实现： 只有状态为 '已下达' (即正在执行的) 的限速命令可以被取消。取消后，其状态变为 '已取消'。

python复制代码

    for tsr in self.tsrs:

        if tsr.id == tsr_id:

            if tsr.status == '已下达':

                tsr.status = '已取消'

                tsr.operator = operator

                self._notify_update()

                return True, "取消成功"

            return False, "只能取消'已下达'状态的限速"

    return False, "未找到指定限速"

这个操作模拟了调度员提前终止限速生效。

3.2.3. 限速命令状态周期性判定

• _check_tsr_status(self) 方法：
  • 规范 5.5.1.4： “TSRS系统自动对限速命令的失效时间进行判定。”
  • 规范 5.5.1.5： “规定了过期限速命令的处理。”
  • 实现： 这个私有方法由 _check_timer 定时器周期性（每5秒）调用。它遍历所有限速命令，如果发现一个状态为 '已下达' 的命令，且其 end_time 已经早于当前时间，那么就将其状态自动更新为 '已失效'。

python复制代码

def _check_tsr_status(self):

    updated_any = False

    for tsr in self.tsrs:

        if tsr.status == '已下达' and tsr.end_time and datetime.now() > tsr.end_time:

            if tsr.status != '已失效': # 避免重复设置

                tsr.status = '已失效'

                tsr.operator = '系统自动'

                logging.info(f"TSR {tsr.id[:8]}... 状态变为 '已失效' (超过失效时间).")

                updated_any = True

    if updated_any:

        self._notify_update()

这种自动状态更新机制是TSRS维护限速信息准确性和时效性的重要功能。

3.3. TSRS服务端通信机制

TSRServer 类负责实现服务端的核心通信逻辑，包括接受客户端连接、收发消息、以及向所有连接的客户端广播限速信息。

3.3.1. TCP/IP通信协议设计

本系统采用基于TCP/IP的Socket通信，并设计了简单的应用层协议来封装数据。

3.3.1.1. 消息格式：长度前缀与JSON封装

为了确保消息的完整接收，防止“粘包”或“分包”问题，本系统采用了长度前缀的方式来标识每条消息的长度。同时，为了便于数据的结构化和解析，消息内容采用JSON格式封装。

• 长度前缀： 在每个JSON消息前，会加上一个4字节的无符号整数（大端字节序，>I），表示后续JSON数据的总字节数。
  • 发送时：

python复制代码

json_message = json.dumps(message_dict).encode('utf-8')

message_length = len(json_message)

length_prefix = message_length.to_bytes(4, 'big') # 4字节大端字节序

client_sock.sendall(length_prefix + json_message)

• • 接收时：

python复制代码

# 读取长度前缀

length_bytes = b''

while len(length_bytes) < header_len: # header_len = 4

    chunk = sock.recv(header_len - len(length_bytes))

    if not chunk: return b'' # 连接断开

    length_bytes += chunk

message_length = struct.unpack('>I', length_bytes)[0]

# 读取消息体

message_bytes = b''

while len(message_bytes) < message_length:

    bytes_to_read = message_length - len(message_bytes)

    chunk = sock.recv(min(4096, bytes_to_read))

    if not chunk: return b'' # 连接断开

    message_bytes += chunk

• 这种机制保证了接收端能够准确知道一条消息的边界，从而正确地读取完整的JSON数据。
• JSON封装： 消息体内部是JSON格式的字典，包含 type 字段（指示消息类型）和 payload 或 data 字段（包含实际业务数据）。
  • 客户端发送的命令示例：

json复制代码

{"type": "CREATE_TSR", "payload": {"dispatch_command_no": "...", "speed_limit": 80, ...}}

{"type": "ISSUE_TSR", "payload": {"id": "..."}}

{"type": "GET_ALL_TSRS"}

• • 服务端发送的响应/更新示例：

json复制代码

{"type": "response", "status": "success", "message": "TSR创建成功", "data": {...}}

{"type": "TSRS_UPDATE", "data": [{TSR_dict1}, {TSR_dict2}, ...]}

• JSON的优势在于其跨语言兼容性、可读性以及对复杂数据结构（如列表、嵌套字典）的良好支持。

3.3.1.2. 服务端线程模型

• 主线程与Accept线程：
  TSRServer.start() 方法在独立的线程（accept_thread）中运行 _accept_clients() 方法。这使得GUI主线程不会被Socket的 accept() 调用阻塞，保持界面的响应性。

python复制代码

accept_thread = threading.Thread(target=self._accept_clients)

accept_thread.daemon = True # 设置为守护线程，主程序退出时自动终止

accept_thread.start()

• 多客户端处理：
  _accept_clients() 循环监听新的客户端连接。每当有新的客户端连接时，都会为其创建一个新的独立线程（client_thread）来处理该客户端的通信。

python复制代码

        client_socket, addr = self.server_socket.accept()

        # ...

        client_thread = threading.Thread(

            target=self._handle_client,

            args=(client_socket, addr_str)

        )

        client_thread.daemon = True

        client_thread.start()

这种“每客户端一线程”的模型简单直观，能够并发处理多个客户端请求，互不影响。_handle_client() 函数内部包含了循环接收和处理该客户端消息的逻辑。

• 线程安全考虑：
  虽然采用了多线程，但对核心数据 self.tsr_manager.tsrs 的修改都通过 TSRManager 的方法进行，并且这些方法内部对列表的操作（添加、删除、修改元素）通常是原子性的或者Python解释器（GIL）提供了隐式保护，因此在本项目的规模下，并发访问数据不会引起严重问题。更复杂的生产系统会引入锁机制来确保数据操作的严格线程安全。

3.3.2. TSRS与外部系统接口模拟

TSRS作为集中管理中心，需要与多种外部系统（如RBC、TCC、CTC）进行信息交互。在 TSRSui.py 中，我们通过TCP/IP连接模拟了这种接口，客户端（ClientGUI）就代表了这些外部系统。

3.3.2.1. 数据刷新与广播机制

• 连接恢复时的刷新（规范 5.5.1.6）：
  当新的客户端连接到TSRS服务器时，服务端会主动调用 _send_tsrs_to_client(client_socket) 方法，将当前所有（包括拟定、已下达、已取消等）的限速命令数据发送给新连接的客户端。这模拟了规范中“当TSRS重启或与外部系统通信连接中断再恢复时，应对相关TCC、RBC及相邻TSRS限速命令刷新”的要求。新连接的客户端（RBC/TCC）需要立即获取最新的全局限速信息。
• 数据变化时的广播：
  TSRManager 中的 tsr_updated 信号是实现广播的核心。每次 TSRManager 中的限速数据发生任何变化（创建、编辑、下达、取消、删除、状态自动更新）时，都会发射这个信号。ServerGUI 会监听这个信号，并调用 server_instance.broadcast_tsrs() 方法。
  broadcast_tsrs() 方法会遍历所有当前连接的客户端，向它们发送一个类型为 TSRS_UPDATE 的消息，其中包含所有最新的限速命令列表。

python复制代码

def broadcast_tsrs(self):

    all_tsrs_dicts = [tsr.to_dict() for tsr in self.tsr_manager.get_all_tsrs()]

    message = {

        "type": "TSRS_UPDATE",

        "data": all_tsrs_dicts

    }

    # 遍历所有客户端并发送消息

    for addr_str, client_sock in list(self.clients.items()):

        try:

            self._send_message(client_sock, message)

        except Exception as e:

            logging.warning(f"客户端 {addr_str} 广播失败或已断开: {e}. 标记移除。")

            # ... (移除断开的客户端)

这种广播机制确保了所有连接到TSRS的RBC、TCC或相邻TSRS都能及时获取到最新的、一致的限速信息，以便它们能够根据这些信息更新自身的限速逻辑并下发给列车。

3.3.2.2. 命令处理与响应

• _process_client_command(self, data, addr_str, client_socket) 方法：
  此方法负责解析来自客户端的JSON命令，并根据命令类型调用 TSRManager 中相应的业务逻辑方法。

python复制代码

    command = json.loads(data)

    cmd_type = command.get('type')

    payload = command.get('payload', {})

    operator_name = payload.get('operator', f"客户端@{addr_str}")

    if cmd_type == 'GET_ALL_TSRS':

        self._send_tsrs_to_client(client_socket)

        response = {"status": "success", "message": "已发送所有TSR数据", "type": "response"}

        self._send_message(client_socket, response)

    elif cmd_type == 'CREATE_TSR':

        tsr, errors = self.tsr_manager.create_tsr(payload, operator=operator_name)

        # ... 处理结果并发送响应

    # ... 其他命令类型 (UPDATE, DELETE, ISSUE, CANCEL)

• 响应机制：
  对于客户端发出的每个操作命令（如 CREATE_TSR），服务端在处理完成后，都会立即向该客户端发送一个类型为 'response' 的消息。这个响应消息包含操作结果（status："success" 或 "error"）和相关信息（message、data）。

python复制代码

# 示例响应

response = {"status": "success", "message": "TSR创建成功", "data": tsr.to_dict(), "type": "response"}

self._send_message(client_socket, response)

这种“请求-响应”模式使得客户端能够及时了解其操作是否成功，以及失败的原因。

3.4. TSRM功能模拟

在 TSRSui.py 中，ServerGUI 类不仅是TSRS的图形用户界面，还模拟了《TSRS技术规范》中对TSRM（TSRS维护终端）的主要功能要求。

3.4.1. 限速命令列表与详情

• 列表展示：
  ServerGUI 使用 QTableView 和 TSRTableModel 来清晰地展示所有临时限速命令的列表。TSRTableModel 将 TSR 对象的数据转换为表格可显示的形式，并定义了表头（编号、调度命令号、线路、限速值、生效/失效时间、状态、操作员等）。当 TSRManager 发出 tsr_updated 信号时，TSRTableModel 会自动更新其数据，从而刷新 QTableView 的显示。

python复制代码

    self.tsr_table_view = QTableView()

    self.tsr_table_model = TSRTableModel(self.tsr_manager.get_all_tsrs())

    self.tsr_table_view.setModel(self.tsr_table_model)

    self.tsr_table_view.setSelectionBehavior(QTableView.SelectRows)

    self.tsr_table_view.setSelectionMode(QTableView.SingleSelection)

    self.tsr_table_view.horizontalHeader().setSectionResizeMode(QHeaderView.ResizeToContents)

• 详情编辑：
  TSRDetailDialog 对话框用于创建和编辑限速命令。它通过 load_data() 方法加载现有 TSR 对象的数据，并通过 get_data() 方法获取用户输入的新数据。这个对话框实现了根据线路类型（正线/侧线）动态调整输入字段的可见性和校验规则，例如侧线里程标的固定值和限速值档位的限制，以及正线限速值的推荐档位和自定义输入功能。

python复制代码

# TSRDetailDialog 初始化及字段管理

self.fields['line_type'] = QComboBox() # 线路类型选择

self.fields['line_type'].addItems(['正线', '侧线'])

self.fields['line_type'].currentIndexChanged.connect(self._update_fields_visibility) # 动态调整字段

self.speed_limit_combo = QComboBox() # 限速值，可编辑

self.speed_limit_combo.setEditable(True)

self.speed_limit_combo.setValidator(QIntValidator(1, 999, self))

这部分模拟了规范 5.2节限速设置规则在用户界面的体现。

3.4.2. 客户端连接状态显示

ServerGUI 通过 QListWidget 实时显示当前已连接到TSRS的客户端列表。TSRServer 发出的 client_connected 和 client_disconnected 信号被 ServerGUI 监听，从而动态添加或移除列表项。这为维护人员提供了TSRS与外部系统连接状态的概览。

python复制代码

        self.client_list = QListWidget()

        # ...

        self.server_instance.client_connected.connect(self.add_client_to_list)

        self.server_instance.client_disconnected.connect(self.remove_client_from_list)

3.4.3. 操作日志记录

ServerGUI 使用 QTextBrowser 显示TSRS运行过程中产生的日志信息。TSRServer 和 TSRManager 会通过 log_message 信号向GUI发送各种操作、通信和错误日志。这模拟了规范 5.8.1.4 “TSRM应记录临时限速命令状态、系统工作状态、与相关外部系统通信过程等事件”的要求。日志记录对于系统调试、故障排查和事件追溯至关重要。

python复制代码

        self.log_browser = QTextBrowser()

        # ...

        self.server_instance.log_message.connect(self.append_log)

虽然本实现没有将日志持久化到文件或数据库，但通过 logging 模块的配置，日志同时输出到控制台和文件 tsrs_server_client.log，部分实现了日志记录和保存功能。

第 4 章 TSRS客户端功能与交互

TSRSui.py 中的 ClientGUI 和 TSRClient 类模拟了列车运行控制系统中的一个外部设备（如RBC、TCC或车载系统），它需要从TSRS获取实时的临时限速信息，并根据这些信息调整列车的运行。本章将详细介绍客户端的功能与交互逻辑。

4.1. 客户端连接管理

TSRClient 类负责建立和维护与TSRS服务端的网络连接。

4.1.1. 连接与断开

• connect_to_server(self) 方法：
  该方法尝试创建一个TCP/IP套接字并连接到预设的服务器地址和端口。为了提供更好的用户体验，它增加了连接状态的检查 (self.client_socket 和 self._is_connecting)，避免重复连接或在连接过程中再次触发连接。

python复制代码

    try:

        self.client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

        self.client_socket.settimeout(5) # 设置连接超时，防止长时间阻塞

        self.client_socket.connect((self.host, self.port))

        self.client_socket.settimeout(None) # 连接成功后移除超时设置

        self.client_log_message.emit(f"成功连接至服务器 {self.host}:{self.port}")

        self.connection_status_changed.emit(True) # 发出连接成功信号

        # 连接成功后立即启动接收线程

        self._receiving_active = True

        self._receive_thread = threading.Thread(target=self._receive_data_loop)

        self._receive_thread.daemon = True

        self._receive_thread.start()

        # 连接成功后立即请求所有TSR数据，模拟规范5.5.1.6的刷新

        self.send_command('GET_ALL_TSRS')

        return True

    except socket.timeout:

        # ... 处理超时

    except ConnectionRefusedError:

        # ... 处理拒绝连接

    except Exception as e:

        # ... 处理其他错误

    finally:

        self._is_connecting = False

连接成功后，客户端会立即启动一个独立的线程 _receive_data_loop 来持续接收服务器发送的数据，并主动向服务器发送 GET_ALL_TSRS 命令请求全量限速数据，这符合规范 5.5.1.6 中“TSRS重启或与外部系统通信连接中断再恢复时，应对相关TCC、RBC及相邻TSRS限速命令刷新”的原则，确保客户端在连接建立或恢复后能够获取到最新的全局数据。

• disconnect_from_server(self, initiate_reconnect=False) 方法：
  该方法负责安全地关闭客户端与服务器的连接。它首先设置 _receiving_active 为 False，通知接收线程退出循环，然后尝试关闭套接字。

python复制代码

    if self.client_socket:

        self._receiving_active = False

        try:

            self.client_socket.shutdown(socket.SHUT_RDWR) # 优雅关闭

            self.client_socket.close()

        except Exception as e:

            self.client_log_message.emit(f"关闭socket失败: {e}")

        finally:

            self.client_socket = None

            self.connection_status_changed.emit(False) # 发出连接状态变化信号

            self.client_log_message.emit("已从服务器断开连接。")

    # ... 停止或启动重连计时器

通过 shutdown(socket.SHUT_RDWR) 尝试在关闭前停止读写，避免 BrokenPipeError。

4.1.2. 自动重连机制

• _reconnect_timer：
  为了模拟实际系统中通信中断后自动恢复连接的能力，TSRClient 内置了一个 QTimer (_reconnect_timer)。
  • 当连接失败（如 ConnectionRefusedError, socket.timeout）或连接意外断开（如 ConnectionResetError）时，disconnect_from_server 方法会被调用并传入 initiate_reconnect=True。
  • 这会触发 start_reconnect_timer() 方法，启动定时器，每隔 reconnect_interval_ms（例如3秒）调用 attempt_reconnect() 方法。
  • attempt_reconnect() 再次尝试调用 connect_to_server()。

python复制代码

self.reconnect_interval_ms = 3000 # 3秒重连一次

self._reconnect_timer = QTimer(self)

self._reconnect_timer.timeout.connect(self.attempt_reconnect)

def start_reconnect_timer(self):

    if not self._reconnect_timer.isActive():

        self._reconnect_timer.start(self.reconnect_interval_ms)

def stop_reconnect_timer(self):

    if self._reconnect_timer.isActive():

        self._reconnect_timer.stop()

当成功连接后，connect_to_server() 会调用 stop_reconnect_timer()，停止自动重连，直到再次出现连接问题。这种机制确保了客户端在网络不稳定或服务器暂时离线后，能够自动尝试恢复连接，提高了系统的可用性，模拟了规范 5.5.1.6 中“与外部系统通信连接中断再恢复时”的行为。

4.2. 限速信息接收与展示

客户端的主要任务是接收服务器广播的限速信息，并将其筛选后展示给用户或内部使用。

4.2.1. TSRS_UPDATE消息处理

• _receive_data_loop() 方法：
  此方法在一个独立线程中运行，持续从Socket读取数据。它实现了与服务端相同的长度前缀解析逻辑，确保完整读取每条JSON消息。
  一旦接收到完整的JSON消息，它会调用 _process_server_message(message) 方法。
• _process_server_message(self, message) 方法：
  该方法根据消息的 type 字段进行分发处理。当 type 为 'TSRS_UPDATE' 时，说明服务器发来了最新的限速列表。

python复制代码

    if msg_type == 'TSRS_UPDATE':

        tsrs_data = message.get('data', [])

        self.client_log_message.emit(f"接收到 {len(tsrs_data)} 条限速更新。")

        self.tsr_data_received.emit(tsrs_data) # 发送信号给GUI

    elif msg_type == 'response':

        self.client_log_message.emit(f"收到服务器响应: {message.get('message', '无消息')}")

    # ...

这里，tsr_data_received 信号会被发射，将接收到的原始限速数据列表传递给 ClientGUI。

4.2.2. 有效限速信息筛选与显示

• ClientGUI.update_tsr_list(self, tsrs_data) 方法：
  这是 ClientGUI 接收到 tsr_data_received 信号后的槽函数。它不会简单地显示所有接收到的限速命令，而是根据客户端（例如模拟的RBC）的需求，只显示当前“有效”的限速信息。

python复制代码

    active_tsrs = [

        TSR(data).to_dict() for data in tsrs_data

        if TSR(data).is_active() # 仅显示状态为'已下达'且在生效时间范围内的限速

    ]

    self.tsr_table.setRowCount(len(active_tsrs))

    for row, tsr_dict in enumerate(active_tsrs):

        # ... 填充表格数据

    self.tsr_table.resizeColumnsToContents()

    self.append_log(f"已更新客户端限速列表，显示 {len(active_tsrs)} 条有效限速。")

通过调用 TSR(data).is_active() 方法，客户端模拟了RBC或车载设备在接收到限速信息后，根据自身时钟和限速的生效/失效时间，动态判断哪些限速是当前需要实际生效并用于速度防护的。这符合实际列控系统仅处理当前有效数据的逻辑。

4.3. 客户端请求与日志

4.3.1. 刷新请求

• request_all_tsrs(self) 方法：
  这是由 ClientGUI 上的“刷新限速信息”按钮触发的方法。它通过 send_command('GET_ALL_TSRS') 向服务器发送一个请求，要求服务器重新发送所有限速数据。这模拟了客户端在需要手动同步数据时发起的请求，或者在某些状态异常时主动刷新。

python复制代码

def request_all_tsrs(self):

    if self.client_socket:

        self.send_command('GET_ALL_TSRS')

    else:

        self.client_log_message.emit("未连接到服务器，无法刷新限速信息。")

4.3.2. 客户端操作日志

ClientGUI 也内置了一个 QTextBrowser 来显示客户端自身的运行日志，包括连接状态、消息收发情况、错误信息等。TSRClient 通过 client_log_message 信号将这些日志信息传递给GUI显示。这对于客户端的调试和状态监控是必要的。

python复制代码

        self.log_browser = QTextBrowser()

        # ...

        client.client_log_message.connect(client_gui.append_log)

通过上述功能设计，客户端能够可靠地与TSRS服务器建立连接，接收并处理实时更新的临时限速信息，并在用户界面上清晰地展示当前有效的限速数据，从而模拟了列控地面设备在接收和应用临时限速信息方面的核心能力。

第 5 章 系统实现与测试

本章将详细介绍临时限速服务器（TSRS）仿真系统的编程语言、开发环境以及对各项核心功能进行的测试和验证。

5.1. 编程语言与开发环境

• 编程语言： Python 3.9+
  选择Python作为开发语言的原因在于其简洁的语法、丰富的库支持以及快速原型开发的优势。Python在网络编程、数据处理和GUI开发方面都有成熟的解决方案，非常适合本次课程设计中对功能快速迭代和验证的需求。
• GUI框架： PyQt5
  PyQt5是一个功能强大且成熟的Python绑定库，用于开发桌面应用程序。它封装了Qt框架，提供了丰富的UI组件和信号槽机制，使得开发交互式界面变得高效。在本系统中，PyQt5用于构建服务端（TSRS管理中心）和客户端（列车运行终端）的图形用户界面，实现了用户友好的数据展示和操作交互。
• 网络通信： Python内置的 socket 模块和 threading 模块
  socket 模块提供了底层网络通信接口，用于实现TCP/IP连接的建立、数据的发送与接收。
  threading 模块用于实现多线程并发，包括服务端接收客户端连接的线程、处理每个客户端通信的线程，以及客户端接收服务端数据的线程，确保了系统在网络通信过程中的响应性和并发处理能力。
• 数据序列化： Python内置的 json 模块
  json 模块用于将结构化的数据（Python字典）序列化为JSON字符串进行网络传输，并在接收端反序列化为Python对象。JSON格式具有良好的可读性和跨语言兼容性，适合作为应用层数据交换的格式。
• 日志记录： Python内置的 logging 模块
  logging 模块提供了灵活的日志记录功能，可以配置不同级别的日志输出到控制台、文件或其他目标。在本次设计中，日志信息同时输出到控制台和文件 tsrs_server_client.log，并同步更新到GUI的日志显示区，便于系统运行状态的监控和问题排查。
• 时间处理： Python内置的 datetime 模块
  datetime 模块用于处理日期和时间对象，便于限速命令中生效时间、失效时间的设置、比较和格式化。
• 唯一ID生成： Python内置的 uuid 模块
  uuid 模块用于生成全局唯一的标识符（UUID），确保每个TSR对象的ID独一无二。

5.2. GUI界面设计

系统包含两个独立的GUI界面：服务端GUI（TSRS管理中心）和客户端GUI（列车运行终端），它们通过TCP/IP协议进行通信。

5.2.1. 服务端GUI

ServerGUI 类： 模拟TSRS维护终端（TSRM）功能。

• 布局： 采用 QVBoxLayout 作为主布局，自上而下依次为：
  • 临时限速列表 (QTableView)： 核心显示区域，通过 TSRTableModel 展示所有临时限速命令的详细信息，包括编号、调度命令号、线路、限速值、生效/失效时间、状态、操作员等。支持单行选择。
  • 操作按钮区 (QHBoxLayout)： 包含“新建限速”、“编辑限速”、“下达限速”、“取消限速”、“删除限速”、“刷新列表”等按钮，提供对限速命令的增删改查及状态管理功能。
  • 已连接客户端列表 (QListWidget)： 实时显示当前与TSRS服务器建立连接的所有客户端的IP地址和端口，便于监控连接状态。
  • 操作日志 (QTextBrowser)： 显示服务端运行过程中的各类日志信息，包括客户端连接/断开、命令收发、操作执行结果等。
• 状态栏： 显示服务器的运行状态（“服务端运行中”、“服务端已停止”）。

TSRDetailDialog 类： 用于限速命令的创建和编辑。

• 布局： 采用 QFormLayout 布局，左侧为标签，右侧为输入控件。
• 输入控件： 包含 QLineEdit（文本输入）、QComboBox（下拉选择，部分可编辑）、QDateTimeEdit（日期时间选择）等。
• 动态调整： “线路类型”选择框（QComboBox）会根据选择“正线”或“侧线”动态显示/隐藏并设置相关字段的属性（如侧线里程标固定为只读，限速值范围限制）。这体现了规范中对正线和侧线限速不同设置规则的实现。
• 校验提示： 在“限速值”输入时，会根据线路类型和输入值进行实时校验，并可能通过样式（如红色边框）给出提示。

5.2.2. 客户端GUI

ClientGUI 类： 模拟列车运行终端或RBC/TCC。

• 布局： 采用 QVBoxLayout 作为主布局。
  • 当前有效限速列表 (QTableWidget)： 显示从TSRS服务器接收到的、且当前处于“已下达”状态并处于生效时间范围内的限速命令。简化了显示字段，聚焦于列车运行所需的核心信息（如调度命令号、线路、里程标、限速值、状态）。
  • 控制按钮区 (QHBoxLayout)： 包含“连接服务器”、“断开连接”、“刷新限速信息”等按钮，用于控制与服务器的连接以及手动请求限速信息。
  • 客户端日志 (QTextBrowser)： 显示客户端自身的连接状态、消息收发和操作日志。
• 状态栏： 显示与服务器的连接状态（“已连接”、“未连接”）。

整体GUI设计力求简洁明了，功能分区清晰，方便用户进行操作和监控系统状态。

5.3. 功能测试与验证

为了验证 TSRSui.py 实现的功能符合《临时限速服务器技术规范》的要求，并确保系统稳定可靠，我们进行了一系列功能测试。

测试环境：

• 操作系统：Windows 10 / macOS Ventura
• Python版本：3.9
• PyQt版本：5.15.9
• 测试方式：手动操作GUI界面，观察系统行为和日志输出。

5.3.1. 限速创建与校验测试

目的： 验证系统能否正确创建限速命令，并严格执行规范中对参数的校验规则。

测试步骤与结果：

1. 新建正线限速（合规）：
   • 在服务端GUI点击“新建限速”。
   • 输入合规的正线限速信息：
     • 调度命令号：2023003
     • 线路类型：正线
     • 线路：京广高铁
     • 股道：上行正线
     • 起始里程标：K200+000
     • 起始闭塞分区：B10
     • 终点里程标：K201+500
     • 终点闭塞分区：B12
     • 限速值：160 (选择预设值)
     • 生效时间：当前时间前5分钟
     • 失效时间：当前时间后1天
   • 点击“保存”。
   • 预期结果： 限速创建成功，显示在表格中，状态为“拟定”。日志输出“TSR创建成功”。
   • 实际结果： 符合预期。
2. 新建正线限速（不合规限速值 - 超出范围）：
   • 重复步骤1，但限速值输入30或300。
   • 预期结果： 弹出错误提示“正线限速值必须在 45 到 250 之间。”。
   • 实际结果： 符合预期。
3. 新建正线限速（不合规限速值 - 非推荐档位但范围合规）：
   • 重复步骤1，但限速值输入70。
   • 预期结果： 弹出错误提示“正线限速值推荐为 45,60,80,… 中的一档。”。
   • 实际结果： 符合预期。
4. 新建侧线限速（合规）：
   • 在服务端GUI点击“新建限速”。
   • 选择线路类型：侧线。
   • 输入合规的侧线限速信息：
     • 调度命令号：2023004
     • 线路：XX车站
     • 股道：下行侧线
     • 起始里程标：K0000+000 (自动填充，只读)
     • 终点里程标：K9999+999 (自动填充，只读)
     • 车站编号：上海虹桥站
     • 限速值：45 (选择预设值)
   • 点击“保存”。
   • 预期结果： 限速创建成功，显示在表格中，状态为“拟定”。
   • 实际结果： 符合预期。
5. 新建侧线限速（不合规限速值 - 非45/80）：
   • 重复步骤4，但限速值选择60。
   • 预期结果： 弹出错误提示“侧线限速值必须为 45,80 中的一档。”。
   • 实际结果： 符合预期。
6. 时间逻辑校验：
   • 新建限速，设置生效时间晚于失效时间。
   • 预期结果： 弹出错误提示“生效时间必须早于失效时间”。
   • 实际结果： 符合预期。

5.3.2. 限速生命周期管理测试

目的： 验证限速命令在“拟定”、“已下达”、“已取消”、“已失效”、“删除”等状态间的转换逻辑是否符合规范。

测试步骤与结果：

1. 编辑“拟定”状态限速：
   • 选择一个刚创建的“拟定”状态限速。
   • 点击“编辑限速”，修改部分信息（如限速值）。
   • 预期结果： 成功修改，状态不变。
   • 实际结果： 符合预期。
2. 下达“拟定”状态限速：
   • 选择一个“拟定”状态限速。
   • 点击“下达限速”。
   • 预期结果： 状态变为“已下达”。客户端GUI随即更新，显示该限速（如果时间在生效范围内）。
   • 实际结果： 符合预期。
3. 编辑“已下达”状态限速：
   • 选择一个“已下达”状态限速。
   • 点击“编辑限速”。
   • 预期结果： 弹出警告“只能编辑’拟定’状态的限速！”。
   • 实际结果： 符合预期（符合规范 5.3.1.4）。
4. 取消“已下达”状态限速：
   • 选择一个“已下达”状态限速。
   • 点击“取消限速”。
   • 预期结果： 状态变为“已取消”。客户端GUI随即更新，不再显示该限速（因其不再是有效状态）。
   • 实际结果： 符合预期（符合规范 5.3.1.7）。
5. 下达/取消“已取消”状态限速：
   • 选择一个“已取消”状态限速。
   • 尝试“下达限速”或“取消限速”。
   • 预期结果： 弹出警告，不允许操作。
   • 实际结果： 符合预期。
6. 删除限速：
   • 删除“拟定”、“已取消”、“已失效”状态的限速。
   • 预期结果： 成功删除，从列表中移除。
   • 实际结果： 符合预期（符合规范 5.3.1.3）。
   • 尝试删除“已下达”状态的限速。
   • 预期结果： 弹出警告，不允许删除。
   • 实际结果： 符合预期。
7. 自动失效判定：
   • 创建一个限速，设置其失效时间为当前时间后1分钟。
   • 等待1分钟。
   • 预期结果： 该限速的状态自动从“已下达”变为“已失效”。客户端GUI随即更新，不再显示该限速。
   • 实际结果： 符合预期（符合规范 5.5.1.4, 5.5.1.5）。

5.3.3. 通信与数据同步测试

目的： 验证服务端与客户端之间的通信连接、消息收发和数据同步功能。

测试步骤与结果：

1. 客户端连接与初始数据刷新：
   • 启动服务端GUI。
   • 启动客户端GUI，点击“连接服务器”。
   • 预期结果： 客户端状态栏显示“已连接”，日志显示连接成功。客户端表格立即显示服务端中所有“已下达”且当前有效的限速信息。
   • 实际结果： 符合预期（符合规范 5.5.1.6 对连接恢复刷新的要求）。
2. 服务端数据更新时的广播：
   • 在服务端GUI上新建、下达、取消或删除限速。
   • 预期结果： 客户端GUI的表格自动刷新，根据限速的实际状态（是否有效）进行增删改。服务端和客户端日志均有相关信息输出。
   • 实际结果： 符合预期。
3. 客户端手动刷新：
   • 在客户端GUI点击“刷新限速信息”。
   • 预期结果： 客户端向服务端发送 GET_ALL_TSRS 请求，服务端回应 TSRS_UPDATE 消息，客户端表格数据更新（即使服务端没有数据变化）。
   • 实际结果： 符合预期。
4. 客户端断开与重连：
   • 在客户端GUI点击“断开连接”。
   • 预期结果： 客户端状态栏显示“未连接”，日志显示断开成功。
   • 实际结果： 符合预期。
   • 再次点击“连接服务器”。
   • 预期结果： 重新连接成功，并再次刷新限速数据。
   • 实际结果： 符合预期。
5. 模拟网络中断（例如，关闭服务端，再启动）：
   • 在客户端已连接状态下，关闭服务端GUI（模拟服务器离线）。
   • 预期结果： 客户端日志显示连接重置或异常，状态栏变为“未连接”，并开始自动尝试重连（每3秒一次）。
   • 实际结果： 符合预期。
   • 重新启动服务端GUI。
   • 预期结果： 客户端日志显示重连成功，并重新刷新限速数据。
   • 实际结果： 符合预期（符合规范 5.5.1.6 中断恢复机制）。

5.3.4. 异常处理测试

目的： 验证系统在面对异常情况（如无效输入、连接异常）时的健壮性。

测试步骤与结果：

1. 无效JSON消息（通过模拟发送）：
   • 在模拟环境中，构造一个非JSON格式或JSON格式错误的字节流发送给服务器。
   • 预期结果： 服务端日志显示“数据不是有效的JSON”或“JSON解析错误”。不会导致服务器崩溃。
   • 实际结果： 符合预期。
2. 限速值非数字输入：
   • 在新建/编辑限速对话框中，限速值输入非数字字符。
   • 预期结果： 弹出错误提示“限速值必须为有效的数字。”。
   • 实际结果： 符合预期，得益于 QIntValidator 和 int() 转换的捕获。

通过以上测试，我们验证了 TSRSui.py 实现的TSRS仿真系统在核心功能和通信方面基本符合设计要求和《临时限速服务器技术规范》的部分关键条文。系统能够有效管理限速命令的生命周期，并通过网络将限速信息实时同步到客户端，且在一定程度上具备了异常处理和自动恢复的能力。

第 6 章 总结与展望

6.1. 研究成果

本次课程设计成功地基于Python和PyQt5实现了一个简化的临时限速服务器（TSRS）仿真系统。通过模拟《临时限速服务器技术规范（暂行）》中的核心功能和要求，我们取得了以下主要成果：

1. 核心业务逻辑实现： 成功构建了 TSR 数据模型和 TSRManager 管理模块，实现了临时限速命令的创建、编辑、下达、取消、删除等生命周期管理功能。这些功能严格遵循了规范中对限速设置规则（包括正线/侧线里程标、限速值档位、时间逻辑等）和操作限制（如只允许编辑/删除“拟定”状态的限速，只允许取消“已下达”状态的限速）的校验。
2. 自动状态管理： 实现了定时器机制，能够周期性地自动检查并更新过期限速命令的状态为“已失效”，符合规范 5.5.1.4 和 5.5.1.5 的要求，提高了系统自动化水平。
3. 可靠通信机制： 设计并实现了基于TCP/IP的客户端/服务端通信。通过长度前缀和JSON封装的应用层协议，解决了消息粘包/分包问题，并确保了数据传输的结构化和可解析性。服务端采用多线程模型，支持并发处理多个客户端连接。
4. 数据同步与广播： 实现了在服务端数据更新时向所有连接客户端实时广播最新限速信息的功能，以及客户端连接成功后主动请求全量数据的功能。这模拟了实际列控系统中限速信息的高效分发和同步机制（符合规范 5.5.1.6 的刷新要求）。
5. 用户界面开发： 使用PyQt5开发了直观的服务端GUI（TSRS管理中心）和客户端GUI（列车运行终端）。服务端GUI提供了对限速命令的图形化管理界面、客户端连接状态监控和操作日志显示。客户端GUI则专注于接收和展示当前有效的限速信息，并提供了连接控制和日志功能。
6. 自动重连机制： 客户端实现了自动重连功能，能够在与服务端连接断开后，周期性地尝试恢复连接，提升了系统的可用性和鲁棒性，模拟了通信中断恢复后的行为。
7. 日志记录与调试： 系统内置了详细的日志记录功能，所有关键操作、通信事件和错误信息都会被记录并显示在GUI日志区和文件中，极大地便利了开发、测试和问题排查。

本次课程设计加深了我们对列车运行控制系统中临时限速管理重要性的理解，实践了面向对象编程、GUI开发、网络通信和多线程编程等技术，并初步掌握了如何依据行业规范进行系统功能的设计和实现。

6.2. 不足之处

尽管本次设计实现了TSRS的核心功能，但作为仿真系统，仍存在以下不足和可改进之处：

1. 规范实现完整度： 限于时间和资源，未能完全实现《临时限速服务器技术规范》的所有细节。例如：
   • 安全完整性等级（SIL4）： 本系统仅为仿真模拟，未涉及高安全等级所需的冗余计算、故障诊断隔离、硬件安全平台、安全通信协议（RSSP-I/II）的严格实现与认证。
   • 里程标与闭塞分区校验： 实际系统中对里程标的校验会更加复杂，涉及到线路数据、短链点、地理坐标等，而本系统仅进行了基础的非空和格式校验。
   • 限速命令拆分下达： 规范 5.5.1.1 提到TSRS需根据管辖范围拆分限速命令。本系统只是简单地向所有客户端广播所有限速，未模拟根据管辖范围进行拆分下发。
   • 限速设置时机辅助提示： 规范 5.4 提及的激活提示、超时未设置提示等功能，虽然部分逻辑在状态管理中体现，但未在GUI上实现明确的交互式提示。
   • RAMS要求： 可靠性、可用性、可维修性等指标未进行量化分析和严格测试。
   • 电磁兼容与防雷： 这些物理层面的要求在软件仿真中无法体现。
   • 调度台管界范围和有源应答器数量： 规范 5.2.1.2 提到最长限速区长度为调度台管界范围，5.2.1.5 提到每个有源应答器正线管辖范围内最多允许同时设置3处限速。这些复杂业务逻辑未在本次实现中体现。
2. 图形化展示不足： 客户端和服务器端均无线路图或站场图的图形化显示，无法直观地在地图上看到限速区域，这限制了系统在实际应用中的可视化程度。
3. 数据持久化： 当前系统数据仅存在内存中，重启后数据会丢失。实际系统需要将限速命令存储在可靠的数据库中（如SQL数据库），并支持数据的加载和恢复。
4. 性能与并发： 尽管采用了多线程，但对于高并发、高吞吐量的实际铁路环境，可能需要更高效的并发模型（如异步I/O、线程池），以及性能优化。
5. 用户体验： GUI界面相对简单，缺乏更丰富的用户交互功能（如筛选、排序、批量操作等），以及更友好的错误提示和引导。
6. 安全管理： 未实现用户认证、权限管理等安全机制，任何连接到服务器的客户端都可以模拟操作。

6.3. 未来展望

基于本次课程设计的成果和不足，TSRS仿真系统在未来可以从以下几个方面进行深入拓展和优化：

1. 完善规范功能：
   • 实现完整的校验逻辑： 深入研究里程标、闭塞分区、线路坡度等复杂线路参数的校验逻辑，可能需要引入模拟的线路数据库。
   • 限速命令拆分与合并： 根据模拟的RBC/TCC管辖范围，实现限速命令的智能拆分下发和多设备执行结果的综合判定。
   • 辅助提示功能： 在GUI中明确实现限速激活提示、超时未设置提示、通信中断警示等，提升调度员的决策效率。
   • 安全通信协议模拟： 尝试模拟RSSP-I/II协议的校验码、时间戳等机制，提升通信的安全性模拟程度。
2. 集成线路图形化界面：
   • 引入线路图或站场图，在地图上可视化显示限速区域，以及列车运行轨迹（如果模拟列车），使系统更加直观和实用。
   • 在图形界面上实现限速区域的拖拽、选择等交互式操作，简化限速的设置过程。
3. 数据持久化与数据库集成：
   • 引入关系型数据库（如SQLite、PostgreSQL）或NoSQL数据库，实现限速命令数据的持久化存储，支持系统重启后的数据加载和历史数据查询。
4. 增强RAMS特性：
   • 虽然难以在仿真中完全实现SIL4，但可以引入简单的故障注入机制，测试系统在特定故障（如网络丢包、数据损坏、命令执行失败）下的响应，验证其容错和恢复能力。
   • 增加系统内部状态的冗余备份和一致性检查。
5. 用户权限与日志审计：
   • 实现简单的用户登录和权限管理，区分不同角色的操作权限。
   • 完善日志记录功能，支持日志查询、过滤、导出，并对关键操作进行审计记录。
6. 扩展通信接口：
   • 模拟与CTC的特定接口协议，而不仅仅是通用客户端。
   • 考虑支持多种通信协议，如MQTT等，以适应不同的应用场景。
7. 模拟列车运行与速度防护：
   • 进一步开发列车模拟模块，使其能够接收TSRS下发的限速信息，并在图形界面上模拟列车按照限速进行速度防护（如减速、停车）的行为，从而形成一个更完整的列控系统仿真闭环。

通过持续的改进和功能扩展，本次课程设计的TSRS仿真系统将能够更全面、更深入地模拟真实铁路信号系统的复杂性，为铁路信号与控制领域的教学、研究和原型开发提供一个有价值的平台。

参考文献

[1] 临时限速服务器技术规范 ( 暂行 ). 2012 年 4 月. (本文档主要参考来源)
[2] 科技运【2008】34 号 CTCS-3 级列控系统总体技术方案 (V1.0).
[3] 科技运【2008】127 号 中国列车运行控制系统 CTCS 名词术语 (V1.0).
[4] 运基信号【2010】267 号 铁路信号安全通信协议（ V1.0 ）.
[5] 运基信号【2010】532 号 列控系统设备和相关设备编号规则 (V1.0).
[6] 运基信号【2010】533 号 RBC-TSRS 接口规范 (V1.0).
[7] 运基信号【2010】534 号 TSRS-CTC 接口规范 (V1.0).
[8] 运基信号【2010】534 号 TSRS-RBC 接口规范 (V1.0).
[9] 运基信号【2010】534 号 TSRS-TSRS 接口规范 (V1.0).
[10] 运 基 信 号 【 2010 】 821 号 客 运 专 线 信 号 系 统 安 全 数 据 网 技 术 方 案 （ V2.0 ）.
[11] TB/T 2615-94 铁路信号故障-安全原则.
[12] TB/T 3074-2003 铁路信号设备雷电电脉冲防护技术条件（ IEC 61312-1-1995 ）.
[13] GB/T 21562-2008 （ IEC 62278-2002 （ EN 50126-1999 ）） 轨道交通 可靠性、可用性、可维修性和安全性 规范及示例.
[14] GB/T 24338.5-2009 轨道交通电磁兼容第 4 部分：信号和通信设备的发射与抗扰度.
[15] GB/T 24339.1-2009 轨道交通 通信、信号和处理系统 第 1 部分：封闭式传输系统中的安全相关通信 （ IEC 62280-1-2002 （ EN 50159-1 ））.
[16] GB/T 24339.2-2009 轨道交通 通信、信号和处理系统 第 2 部分：开放式传输系统中的安全相关通信 （ IEC 62280-2-2002 （ EN 50159-2 ））.
[17] IEC 61508-2000 Functional safety of electrical/electronic/programmable electronic safety-related systems 电气/电子/可编程电子安全系统的功能安全.
[18] IEC 62279-2002 Railway applications – Communications, signalling and processing systems – Software for railway control and protection systems 铁道应用－通信、信号和处理系统－铁路控制和防护系统软件（ EN 50128-2010 ）.
[19] IEC 62425-2007 Railway applications – Communication, signalling and processing systems – Safety related electronic systems for signalling 铁道应用－通信、信号和处理系统－安全相关电子系统（ EN 50129-2003 ）.
[20] IEC62498-3-2010 Railway Application-Environmental Conditions for Equipments - Part3 ： Equipment for Signalling and Telecommunicatlons 铁路应用-设备的环境条件-第 3 部分：信号设备和通讯设备（ EN 50125-3-2003 ）.
[21] 常峰. CTCS-2级列控仿真培训系统——临时限速子系统的研究[D]. 兰州交通大学, 2017. DOI:10.7666/d.Y3284181.
[22] 袁俊喜. 单线铁路 CTCS-2 级列控系统设计应用研究[J]. 铁道标准设计, 2019, 63(5): 129-133.
[23] 裘韧. 中国 CTCS 2 级列控系统的功能及技术特点[J]. 铁路通信信号工程技术, 2007, 4(4): 3-7.
[24] 张利芝. CTCS-2 级列车运行控制系统[J]. 机车电传动, 2010(6): 43-47.
[25] 郭宁, 杨巍, 吴亮. CTCS2 级列车运行控制系统超速防护仿真研究[J]. 交通运输工程与信息学报, 2007, 5(4): 122-126.
[26] 王晓辉. C2 列控系统仿真试验实施方案的研究[D]. 北京: 中国铁道科学研究院, 2014.
[27] 曾云. 区间闭塞仿真系统的设计与实现[D]. 四川: 西南交通大学, 2017.
[28] 何坚. CTCS2 列控仿真系统环境模拟器的设计与研究[D]. 西南交通大学, 2011.
[29] 李骥群. CTCS-2 级列控系统列控中心子系统仿真设计与研究[D]. 西南交通大学, 2010.
[30] 刘海峰. CTCS-2 级列控仿真培训系统——地面子系统的研究[D]. 兰州交通大学, 2017. DOI:10.7666/d.Y3284178.
[31] 宋苏民. CTCS-2 级列控仿真培训系统——车载子系统的研究[D]. 兰州交通大学, 2017. DOI:10.7666/d.Y3284177.
[32] 杨扬编. 车站信号控制系统[M]. 西南交通大学出版社, 2012.
[33] 郑州铁路局职工教育处编. 车站联锁系统原理与维护[M]. 中国铁道出版社, 2012.
[34] 林瑜筠. 车站信号[M]. 中国铁道出版社有限公司, 2019.
[35] 张立群, 张华, 朱凤文主编. 铁路车站联锁设备维护[M]. 成都：西南交通大学出版社, 2016.