在整个流程中，通过①→②完成对设备状态的获取，通过③→④完成对控制指令的下发；对于不同的子系统，区别只是对数据处理的方式。

为提高综合监控系统的可靠性，对其主要硬件配置全部采用冗余机制，FEP也不例外，如图2所示。图2中的FEP1和FEP2各自独立运行，与X系统的通信链路分别为①和②，且FEP1和FEP2均能同时向服务器1和服务器2上传数据。服务器与FEP之间的链路为③～⑥，这样从服务器到X系统设备间就建立了4条链路:链路1，①→③；链路2，①→⑤；链路3，②→④；链路4，②→⑥。当FEP1与X系统(链路①)的通信中断时，服务器1可通过链路4获取X系统的数据，服务器2可通过链路3获取X系统的数据；同理，FEP2故障后，链路1和链路2可实现数据的正常交互，从而实现了冗余切换的功能。

研究目前，全国各城市已有多条综合监控系统上线运行。从FEP的运行情况来看，易造成通信中断级别的故障主要集中在硬件方面，如链路接头松动和接口模块损坏等。除此之外，瞬间大数据量交互对FEP性能也有一定的影响，易造成FEP的CPU、内存利用率居高不下或是暂时性的数据阻塞等，导致系统功能异常。针对这些问题，应优化FEP的设计方案，保证后续线路不会重蹈覆辙。

硬件可靠性分析研究

目前，FEP接口模块只有以太网口和串口两种，传输介质分别为RJ45双绞线和串口线；无论是哪种端口，对接点的数量都与故障率的高低成正比。对于使用网口与FEP对连的设备来说，越来越成熟的网络配线架已将两者之间的对接方式模块化，对接的可靠性已达到很高的水平。相比之下，串口基于其特性，接头处需采用人工接线，稳定性相对于网口自然会低一些；但串口的成本较低，在数据交互频率不高的系统中依然得到了很广泛的应用。尽管如此，串口模块由于工作时存在电平差，所以当数据交互瞬间次数很高时，发热就会很严重，造成整个FEP温度上升，影响系统性能以及设备的使用寿命。

总之，网口和串口模块各有优势。就地铁项目而言，由于子系统的功能有简有繁，对于数据量交互很频繁的系统来说，以太网口是最好的选择；但对于系统数据量交互一般或很少的系统来说，从降低成本的角度出发，可选择使用串口模块。因此，在接口设计初期，可通过预估数据交互频率、数据量大小和用户对链路的日常维护要求，确定接口模块的类型。

FEP硬件能够同时支持多种通信接口模块，即支持很多的网口和串口同时运行。因此，为防止因地址混乱而造成的通信故障，在操作系统安装时就应为每个端口规划其相应的地址，实现网络隔离。除此之外，还需要保证各功能模块具有自诊断和自恢复的功能，保证链路恢复后通信能够自行恢复。

软件可靠性分析

研究在FEP与子系统连接建立的初期，FEP会按照双方约定的协议来检测第一个通信模块，待双方正常通信后，再按照这个步骤来逐个检测剩下的通信模块，直到初始化过程完毕，FEP的各模块才开始轮询采集子系统设备信息，并缓存在本地的寄存器中，实现通过协议转换获取设备信息的功能。

由于双方通信连接的保持是通过不断地收发报文来实现的，而报文是由程序按照协议格式封装而成的，所以协议本身就是报文稳定性的一个关键。根据系统功能定制开发的协议，交互报文的稳定性相比标准协议规定的稳定性要低得多。虽然在数据交互时允许报文出错，且接收方可以根据错误校验丢弃报文，但是浪费了带宽资源。因此，从通用性和易维护性方面来考虑，协议的商定应尽量选择标准的类型，以减少由FEP定制开发所产生的不必要错误。同时，当FEP与设备的链路遭遇通信中断的问题时，对不同的系统应有不同的处理方式；对信息实时性要求较高的系统，在遇到连接中断或阻塞等情况时，FEP必须具备丢弃报文的功能，如广播系统(public address，PA)、导乘信息系统(passenger information system，PIS)、门禁系统(access control system，ACS)等；对信息完整性要求较高的系统，FEP必须在本地缓存这些指令，待链路恢复后继续交互，如电力监控系统(power supervisory control and data acquisition system，PSCADA)的事件顺序记录(sequence of event，SOE)等。

数据通信性能分析研究

当FEP与子系统瞬间数据交互量很大时，FEP的性能肯定会受到一定的影响，轻则造成短时的数据阻塞，重则造成系统出现故障。以接入综合监控系统的列车监控系统(automatictrainsupervision，ATS)为例，全线约2000个信息点，按照2次/min数据交换计算，全天交互高达500万个信息点，这个数据量对任何服务器都是个挑战。因此，针对这种大数据量的接口设备，从数据传输的角度来考虑，采用块传输的效率肯定高于采用点传输的效率，但缺点是数据的可读性会随之下降。对此，可以采用折中的办法，FEP采用块传输的方式传输数据，数据的解析通过外接维护工作站来实现，调试人员可以在维护工作站上观察双方的数据交互情况，这样FEP本身的负荷会小很多，数据传输效率自然会随之提高。

从数据处理的角度来考虑，对于不需经过服务器处理的数据，最好由FEP直接协议转换并转发，以降低中转的环节，提高整个综合监控系统的工作效率。图3中(a)是某地铁综合监控系统ATS信息转发PIS的方案:FEP在接收到ATS上传的数据之后，将数据传输至服务器进行处理，再将数据返回给FEP，由FEP传输至PIS系统，整个流程一共要进行4次数据收发。图3中(b)是FEP具备协议转换功能之后的优化方案:ATS的数据上传至FEP后，直接由FEP转发给PIS系统，中间减少了2次数据收发，不仅减少了系统的故障点，而且还提高了系统的可靠性。因此，FEP今后的发展一定要越来越适应这种大数据量的接口设备。

冗余机制分析研究

综合监控系统的接口数量多，接口方式也多种多样，因此接口性能的稳定是综合监控系统与子系统之间保持正常通信的关键，但接口设备不可能达到100%的无故障率。当系统间的某个部件发生故障时，可通过备用部件进行正常的数据收发，使系统的可靠性得到保障，这就是目前提高系统可靠性最普遍的做法—--冗余切换。每个综合监控系统采用的冗余机制都不尽相同，但都有共同的目的，就是在系统结构更简单的同时，冗余的可靠性更高。

冗余方式1

目前的FEP采用设备级的冗余机制居多，如图4所示。FEP通过计算与其通信正常的子系统数量来设置冗余标志位，多的设置为“主”，少的设置为“备”。当FEP1与A子系统的通信中断之后，FEP1通过其内部的交换机卡1连接FEP2的交换机卡2，完成与A子系统的通信建立，实现冗余切换。这种机制的FEP结构较为复杂，内部需配置交换机卡，其实现难度主要集中在两台FEP之间的路由转换，因此被称为“基于FEP本身的冗余”。

冗余方式2

从综合监控系统建设的角度来看，在冗余功能相同的前提下，整体方案应越简单越好。因此，通过将冗余取决权上交至服务器端FEP驱动的方式，替换FEP内部交换机卡所完成的任务，实现冗余功能，被称为“基于上位驱动的冗余”，如图5所示。FEP1和FEP2相对独立，内部不需要配置交换机卡，但FEP要将与每个子系统的连接状态传输给上位的FEP驱动，由FEP驱动根据端口通信情况来决定链路。如图5所示，当FEP1与A系统连接中断、FEP2与B系统连接中断时，上位驱动就会选择FEP1的B系统和FEP2的A系统作为通信链路，实现冗余功能。这种机制的FEP结构较为简单，其实现难度主要集中在上位FEP驱动的开发。与方式1相比，这种机制的优点就是结构简单，由于内部环节比较少，所以维护起来也方便。

两种冗余方式结合

FEP毕竟属于独立设备，服务器无法直接检测端口的真正状态，所以可将两种方式结合起来，如图6所示。在两台FEP之间建立一条心跳连接，通过“心跳线”，FEP就能了解彼此子系统端口的状态，然后以写入配置文件的方式，指定上位的FEP驱动和哪台FEP的子系统交互数据；只有当“心跳线”中断之后，取决权才上交由上位FEP驱动来选择，这样FEP原有的冗余功能才不会缺失，且提高了多点故障时的数据可靠性。