列车防追尾软件技术和仿真系统
陈 钢
灵芯实验室 (Lingcore Laboratory)
gang dot chen at lingcore dot com
摘要 2011年7月23日，开往温州的动车发生重大追尾事故。事故中D3115列车在减速慢行时，由于信息采集器故障，列车 占用轨道的信息未能传递到控制中心，也没有在该路段后部点亮红灯，致使后面的D301次动车撞上D3115。这类故 障可以归类为分路不良问题，在铁路行业是一个重要的安全隐患。本文说明，软件分析可以发现分路不良的存在， 并自动在故障区开始处点亮红灯。本文主要贡献是研发了这一技术的PLC实现，并且开发了仿真系统进行验证。
关键字 防追尾软件 分路不良 仿真系统 列控系统 CTCS-2
一． 引言
723事故是可以防止的。对于高铁这样的复杂系统，难免出现大大小小的硬件设备故障，但这并不等于一定会发生事 故。在723事件中，如果守候在调度屏幕前的工作人员保持足够的注意力，他会注意到正在开行的列车突然从屏幕上 消失了，这表明出现了设备故障，如果他反应速度足够快，他还能够赶紧通知后方的列车，从而避免一场事故。不 幸的是，留给控制室工作人员的时间非常短暂。下面，我们首先对723事故发生过程做一简短回顾，然后指出通过计 算机分析进行事故预警的方法。
根据国务院调查组的调查报告【0】，723事故发生在永嘉站和温州南站之间的5829AG路段。永嘉站到温州南站总共 只有15.5公里，5829AG距离永嘉站11.9公里。D3115次车20:15从永嘉站发车，约20：21到达5829AG，仅用6分钟多一 点，平均时速接近每小时120公里；到达该地后由于红光带故障而停车。3分钟后调度指示D301次列车从永嘉站出发 。此时，由于信号系统故障，5829区间不亮红灯亮绿灯；5分钟之后，D3115次列车转目视行车；又过半分钟之后， D301次列车赶上D3115次车，发生追尾。追尾时间是20时30分，地点在583公里831米处。下图是调查报告中的有关 图片：
从报告中可以看出，从第一辆列车D3115次20:15发车，到20:30发生追尾事故，总共只有15分钟的时间。从D3115次 发车到20:24时D301发车，只有9分钟时间。在这短短的9分钟里面，调度员张华除了了解设备情况之外还进行了8次 接发车操作，几乎每分钟一次。在这样高强度的工作环境之下，要分析发现各种潜在的危险是比较困难的。
张华在20时24分发出D301是有一定根据的。在D3115用6分钟行驶了12公里，,后面虽有红光带，但是，按照张华指示 ，列车应该以每小时20公里速度通过这一750米地区，所需时间不超过3分钟。后面的3公里路段不需要3分钟即可走 完，此时发出D301要5分钟才到达5829，因此看上去是安全的。但是，他没有料到的是，由于5829AG区轨道电路的 错误，使得D3115滞留在该地直到20时29分过后才启动。
张华在20时26分通过电话了解到D3115还在5829区，此时，D301离开5829区只有3-4分钟的路程，如果张华及时打电话要求D301减速就可以避免这次事故。不过，在正常情况下，有车占用的5829区应 该亮红灯，阻止D301进入。不幸的是，该地LKD2-T1型列控中心设备采集驱动单元采集电路故障，造成信号机显示绿灯。这一设备故障似乎没有被当时的工作人员发 现。
信号故障时，列车应该在屏幕上消失。控制室有机会发现这个问题，但是时间实在太短，而且调度人员要同时对多 辆列车进行调度，处在高强度的工作环境当中。此外，拨号通话也需要时间。因此，在动车系统的快速运作的情况 下，调度人员缺乏充分的时间去分析发现潜在的危险。
这个问题实际上可以用机器智能来解决。让计算机来分析采集到的数据，当发现这些数据有异常情况出现时，立即 发出警报，甚至直接通过列车的ATP系统采取制动措施。这样事故就可以避免。机器处理问题反应速度比人快，而且 不知疲倦。
这一方法的难点在于计算机的分析必须准确，不然的话会在很多正常状况下会发出误报，给铁路运行带来很多烦恼 。2011年8月，京沪高铁上54辆列车被召回，原因就是警报系统过于敏感，时常在不该发警报时发了警报。
智能防撞软件技术早在90年代就已被中国学者提出，后来又被写入列车控制系统技术规范第一稿。然而，列控中心 技术规范的最新版本中，这一技术又被撤销了。主要原因就是误报太多。
开发这些控制软件的主要困难之一是调试问题。软件开发过程的大部分时间是在试错，也就是添加功能，检查运行 ，发现错误，查找错误，改正错误的一个过程。软件开发首先从一个小的原型系统开始，然后逐步给它添加新的功 能，直到成为一个成熟的系统。每增加一个功能或进行一次修改，就要进行系统运行，检查问题，经过多次反复软 件才能成熟。普通软件可以直接在电脑上运行，立即看到结果，但控制软件与此不同，必须安装到被控制的系统中 去运行，对于铁路控制软件，就需要按照到铁路信号系统中，在列车反复开行的过程中去调试。因此，这些控制软 件的调试过程就非常长，代价也很大。正因为如此，不少软件没有经过充分调试就不得不投入使用，因此在使用过 程中就常常出问题，或者干脆被抛弃。
解决这个问题的一个方案是构造仿真系统，用仿真系统去模拟被控制的系统，通过在仿真系统中运行软件来及早发 现问题，提高调试效率。虽然仿真系统不可能完全代替实际系统，但是有很多问题可以在仿真系统中更快更早地发 现，可以大幅度地减少调试时间。此外，仿真系统还可以扩大问题的检查范围，人为构造出现实世界中极少发生的 情景进行测试，从而提升系统的可靠性。
所以，开发一个高可靠性控制软件，首先需要开发一个功能强大的仿真软件，仿真软件的质量直接决定了控制软件 的质量。不过，仿真软件的工作量往往比控制软件本身的工作量大得多。
国内铁路科研机构为列车控制系统做了许多仿真系统方面的研究，其中也包括上述防追尾软件技术的仿真。但是， 针对防追尾技术所开发的仿真系统功能不够强大，许多复杂情形还不能够在现有系统中仿真，有些控制软件的错误 也无法在这样的仿真工具中检查出来。这很可能是防追尾技术未能在高铁系统中投入使用的原因。
我们在控制系统仿真测试软件方面做了长期的研究，开发了包含原创技术的PLC程序测试系统，在这一测试系统的支 持下，我们开发了基于PLC的列车防追尾程序，以及相关的仿真测试系统，防追尾程序成功通过了仿真系统中的测试 。这一仿真系统在直观性和功能全面性方面均超过了文献中所介绍的其他仿真系统。在开发过程中，我们还发现并 纠正了前人工作中的一个失误，在某些情况下，这一失误也会有产生追尾的危险。
下面第二节回顾铁路闭塞系统基本概念以及与723事故有关的分路不良故障；第三节讨论基于出清占用检查的列车防 追尾软件技术；第四节分析列控中心技术规范第一稿中对出清占用检查的描述方法中的一个问题，并指出纠正这一 问题的方法。同时还介绍了我们所开发的基于出清占用技术的PLC防追尾程序，尤其是对于这一程序的仿真演示。
二． 追尾事故与分路不良
铁路划分成一段段闭塞区间，每个闭塞区间有轨道电路判定是否有列车存在，并根据所获得的信息控制信号灯，向 列车和列控中心发出相关代码。区间内有列车通过时，轨道电路会控制信号机亮红灯（HU码），后一区段亮黄灯（ U码），再后面的区段亮黄绿灯（LU码），再后面的区段亮绿灯（L码），L码又分成L1，L2，L3，L4，L5，为简单 起见，下面我们只写L码。
闭塞技术本应防止列车追尾，但是轨道电路有时会发生故障。第一类故障是没有列出通过闭塞区间时误报有车，在 不该亮红灯的情况下亮红灯。这类故障在一些文献中称为“故障占用”【1】。另一类故障是在有列出通过闭塞区 间时 没有发现，从而导致该区段继续亮绿灯，这种情况称为“分路不良”。当发生这种情况时，就有可能出现列车追 尾事 故。7月23日的事故可以看成是分路不良故障造成的一次惨案。
在7月23日追尾事故发生前信号系统发生了两次故障。先是发生故障占用，在没有火车的路段亮红灯，导致前一列车 停车慢行；该车在通过故障路段时，又发生了第二个故障，信息采集器保险丝熔断，在应该亮红灯的地方亮绿灯， 也就是说出现了分路不良，由此导致后一列车撞上前面列车。“故障占用”和“分路不良”均为铁路上尚未根本解 决的 故障，但两种故障相继发生的事件非常罕见。
下图是在我们的仿真系统中演示的“分路不良”故障情形。图中绿色轨道是没有列车占用的区段，红色轨道是正 被列 车占用的区段，蓝色轨道是分路不良的区段。左边的B车行驶在正常区段中，它占用的区段呈红色，不占用的区段呈 绿色。右边的A车行驶在分路不良区段中，在它前后共有三个分路不良区段，用蓝色显示。
控制信号计算程序根据每个闭塞区间上的轨道占用信息产生出信号灯控制信息。在正常的列出占用区段位置之后依 次显示红灯，黄灯，黄绿灯和绿灯。中间三个蓝色区段发生了分路不良，当列车A行驶在这些区段上时，轨道电路没 有检测和报告列车占用信息，因此各个闭塞区间后方信号灯依然是绿灯。由于A车后面没有红灯防护，因此一旦A车 停下，后面的B车就会撞上A车。
仿真系统对这一过程的仿真视频见网址http://www.lingcore.com/rail/collision.swf.html
它显示了列车运行和信号变化的动态过程，其中右边的列车在分路不良区间中停车，没有出现红灯保护，左边列车 最终撞上右边列车。
二．出清占用检查
在铁路行业，分路不良是一个老大难问题，这方面国内科研人员做了大量研究，【2,3,4,5】是其中的一部分。从目 前情况看，在硬件设备方面还无法根本杜绝这一问题。然而，可以采用软件技术防范由分路不良所造成的事故，具 体地说，就是依靠软件自动发现分路不良区间，并且在该区间后部点亮红灯。
这一软件技术的基本思路就是根据列车行驶的历史来分析道路情况。假如计算机发现列车在开行过程中突然“失 踪” ，即可判定铁路上发生了分路不良，如果“失踪”之后又重新出现，则可以判定驶出分路不良区，从而去掉分路 不良 区后面的防护红灯。
具体做法称为“三点检查”，或称“出清占用检查”。比如列车由区段A向区段B运行。那么轨道信号的正常变化顺 序应 该是：1）A占用，B未占用；2）A，B同时占用；3）A未占用，B占用。假如系统发现轨道信号有这样的变化顺序， 就能够判定A,B两个区段的轨道电路正常工作，而且列车已经到达B区段。
假如B后面的区段是C，D，E，F，而且在BC，CD区段上三点检查失败，那么认为C,D发生分路不良。此时，系统将在 B段亮红灯阻止后面列车进入，B点称为“防护点”。假设E,F区段通过了三点检查，又可以判定列车在E,F区段轨道 电路 正常，而且列车已经运行到此处。此时可以把设在B处的防护点红灯去掉，转移到E处，称为防护点前移。
三点检查技术首先在文献【6】中提出。文献【7】建议将其引入到高铁的列车控制系统CTCS-2之中。在2007年的CTCS-2列控中心的第一个技术规范中正式规定必须采用三点检查技术（文件中称为出清占用技术）【8】。然而，在2010 年最新版的列控中心技术规范中又去掉了这一要求【9】。这一转变说明出清占用检查在实现上存在一定的困难，然 而，失去这一检查功能，就增加了事故的风险。假如在CTCS-2中加上这一机制，723事故将不会发生。
下面，我们以7月23日的情形为例来说明三点检查技术如何能够防范当天的事故。
7月23日晚，该段铁路中的一部分区段出现“红光带”，表明发生了“故障占用”。在第一辆列车开出去之后，由于 信号 采集板故障，列车占用情况不能如实传递出来，调度屏幕上显示丢车，发生了“分路不良”故障。此时，左边有 一个 红光带，后面有一个绿光带，调度屏幕上显示第一辆列车丢失。见下图：
此时，“三点检查”在红光地区和绿光地区均未发现列车移动信息，因此它将把防护点设置在第一辆车首次出现 移动 特征的位置，即绿带的开始处。因此，后一辆车必定停在这个位置等待。
当前一辆车穿过红光带，并能够被三点检查技术所发现时，防护点会向前移动到新的位置。此时，先前的防护点红 灯将会熄灭，后车将在一片绿灯指引下到达下一个防护点。而这片绿灯实际上处于信号设备故障区，调度屏幕上会 继续出现丢车信号，但是，由于存在前方防护点，所以并不妨碍列车的安全运行。见下图：
我们开发了基于三点检查技术（也称(出清占用检查）的控制程序。该程序在正常情况下的行为同原来的程序一致， 在列车占用区间时按序发出控制码。但是该程序会记住前一区段列车占用情况，如果前一区段出现列车占用，然后 占用情况消失，同时下一区段又没有检测到列车占用，那么判定该区段出现了分路不良，并且开亮红灯，发出紧急 停车码H。下图是仿真系统中程序运行截图：
截图和视频显示，第一辆车A进入蓝色“分路不良”区域之后，区域始端自动亮红灯，有效阻止了后面车辆B的进 入。
信号控制程序用最基本PLC梯形图语句写成，可以移植到任何一种PLC机,也可以转换成C语言程序，或转换成FPGA 电路实现。程序语句的简单性有助于以后使用形式化方法进行验证。
目前实现的是出清占用检查中的基本功能，未来还将进一步扩展功能，并针对各种情况完善程序。
研发过程显示，信号控制程序虽然不算长，但是存在很多微妙的细节，要考虑周全并写出正确的程序并不容易。这 一开发过程得益于我们自己研发的PLC程序测试系统和开发平台，这些软件工具使我们在开发中能够很方便地进行 程序检测，能够及时发现程序问题并加以纠正。
以往的研发工作曾经提出在发现分路不良区间之后发出HU码，在我们的算法中改为H码。根据规定，司机看到HU码 之后停车2分钟，然后以低于每小时20公里的速度通过该区间。在上面的图片中显示，如果有多个分路不良区存在， 只有第一个区段前能够亮红灯，后面都是绿灯。因此，列车在过了第一区段之后，以后就会以正常速度行驶。因此 ，HU码防护并不安全，所以改成H码。
我们同以往工作的另一个区别是开发了功能更为强大的仿真测试环境。比如，过去的仿真系统只包含8个闭塞区间， 视频中的仿真系统包含14个区间。实际上系统可以很容易地扩展到任意多个区间。以往的仿真测试由于受到区间数 量的限制，仅考虑了一个分路不良区段，因此不能发现上面提到的HU码问题。
四．小结
本文回顾介绍了基于出清占用检查（也称三点检查）的列车防追尾软件技术。这一技术曾经是2007年的CTCS-2列控中心技术规范所规定的一项要求【8】，但是在2010年的列控中心技术规范修改稿中被删除【9】。我们相信这 一变化的主要原因是防追尾软件开发的困难性，主要是缺乏一个良好的仿真系统进行系统调试。针对这一问题，我 们不但重新进行了防追尾程序的开发，而且在我们的PLC程序测试系统基础上开发了专用于防追尾程序调试的仿真 软件，防追尾程序成功通过了仿真测试。在开发过程中，我们发现并纠正了以往文献中的一个安全隐患。
参考文献
【0】 中国国务院“7.23”甬温线特别重大铁路交通事故调查组，“7.23”甬温线特别重大铁路交通事故调查 报告，201 1年12月25日。
【1】 李铭，“客运专线CTCS2级列控中心功能仿真研究”，西南交通大学，硕士论文，2009年。
【3】 罗勇，“浅析轨道电路分路不良的成因及解决方案”，《铁路通信信号工程技术》 2004年第6期。
【4】 王海瑛，“由轨道电路分路不良引起两车同处一个闭塞分区的案例”，《铁道通信信号》 2004年第5期。
【5】 荣健，“轨道电路分路不良及其解决方式分析”，《总裁》，2009年第10期。
【7】 吴江娇，王亚菊，“客运专线列控中心对轨道电路分路不良的防护”，《北京交通大学学报》，第32卷第 3期 ，2008年6月。
【8】 客运专线CTCS-2级列控系统列控中心技术规范（暂行），科技运【2007】158号。
【9】 列控中心技术规范，科技运【2010】138号。
【10】 陈钢，“温州动车追尾事故与CTCS-2技术规范中的安全隐患”，《软件》杂志，2011年第32卷第8期。
三．分路不良区的防护
