前端处理器在综合监控系统的应用及优化

张大千 熊天圣

(上海宝信软件股份有限公司 上海 201900)

随着地铁的建设，自动化系统被越来越多地应用，各系统间的联系也越来越紧密，轨道交通的综合监控系统也就应运而生。由于综合监控系统通过集成众多的子系统来发挥整体优势，实现信息互通、资源共享，达到提高运营效率和可靠性的目的，因此对其提出了更高的要求。综合监控系统服务器既要承担数据处理的任务，又要承担与子系统完成数据交互的任务，这将导致服务器需要高配置，同时投资也将增加，还会造成自身负荷过重，当通信量很大时将花费大量数据处理时间。为避免上述现象，为服务器端配备了前端处理器(front end processor，FEP)，其主要目的就是完成系统间的数据通信任务，降低服务器的负荷，改善服务器的数据处理能力，以提高系统的可靠性。

1 FEP的应用

1.1 功能需求

在综合监控系统中，FEP主要担负综合监控系统与各相连子系统的接口管理。通过协议转换、数据采集和数据下发等功能，完成服务器与子系统设备间的数据交互，从而实现对相连子系统设备的监控。

1.2 功能实现

FEP要完成服务器与子系统间的数据交互(见图1)，其功能及原理分析如下。

1)与子系统设备建立通信连接。在物理链路连通之后，由FEP主动向设备通信主机请求信息，同时设备通信主机返回应答信息，见图1中的①。

2)FEP获取设备状态信息，解析并缓存在本地。FEP交互的信息都缓存在本地的实时数据库中，在登录后可观察一定时间内双方交互的原始报文及解析后的数据。在系统调试初期，这些缓存的报文可辅助检测问题;在系统稳定之后，可以维护FEP稳定高效地运行。

3)服务器端的FEP采取驱动轮询，采集FEP收集的状态数据。为建立FEP与服务器的数据交互通道，在服务器端安装了FEP驱动，FEP上传的数据均由驱动分派至服务器相应的寄存器中，见图1中的②，最终由HMI展现在界面上。

4)控制指令经由FEP驱动下发至FEP。下置数据的顺序与采集数据的顺序相反，会先存储在服务器端相应的寄存器里，再由FEP读取后处理，见图1的③。

5)FEP将控制指令按照协议格式发送给设备。FEP在接收到指令之后，根据接口协议转换成正确的报文格式发送，见图1中的④。

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

1.3 冗余机制

为提高综合监控系统的可靠性，对其主要硬件配置全部采用冗余机制，FEP也不例外，如图2所示。

图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可实现数据的正常交互，从而实现了冗余切换的功能。

2 FEP的应用现状及优化方案研究

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

2.1 硬件可靠性分析研究

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

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

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

2.2 软件可靠性分析研究

在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)等。

2.3 数据通信性能分析研究

当FEP与子系统瞬间数据交互量很大时，FEP的性能肯定会受到一定的影响，轻则造成短时的数据阻塞，重则造成系统出现故障。以接入综合监控系统的列车监控系统(automatic train supervision，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今后的发展一定要越来越适应这种大数据量的接口设备。

2.4 冗余机制分析研究

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

图3 ATS数据交互

2.4.1 冗余方式1

目前的FEP采用设备级的冗余机制居多，如图4所示。

图4 冗余方式1

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

2.4.2 冗余方式2

从综合监控系统建设的角度来看，在冗余功能相同的前提下，整体方案应越简单越好。因此，通过将冗余取决权上交至服务器端FEP驱动的方式，替换FEP内部交换机卡所完成的任务，实现冗余功能，被称为“基于上位驱动的冗余”，如图5所示。

图5 冗余方式2

FEP1和FEP2相对独立，内部不需要配置交换机卡，但FEP要将与每个子系统的连接状态传输给上位的FEP驱动，由FEP驱动根据端口通信情况来决定链路。如图5所示，当FEP1与A系统连接中断、FEP2与B系统连接中断时，上位驱动就会选择FEP1的B系统和FEP2的A系统作为通信链路，实现冗余功能。这种机制的FEP结构较为简单，其实现难度主要集中在上位FEP驱动的开发。与方式1相比，这种机制的优点就是结构简单，由于内部环节比较少，所以维护起来也方便。

2.4.3 两种冗余方式结合

FEP毕竟属于独立设备，服务器无法直接检测端口的真正状态，所以可将两种方式结合起来，如图6所示。

图6 冗余结构

在两台FEP之间建立一条心跳连接，通过“心跳线”，FEP就能了解彼此子系统端口的状态，然后以写入配置文件的方式，指定上位的FEP驱动和哪台FEP的子系统交互数据;只有当“心跳线”中断之后，取决权才上交由上位FEP驱动来选择，这样FEP原有的冗余功能才不会缺失，且提高了多点故障时的数据可靠性。

3 结论

FEP的发展需要跟随综合监控系统未来的走势。未来综合监控子系统集成化会越来越高，这也就要求FEP的功能越来越强大，不仅要具备通信的功能，而且还要具备简单数据处理的功能。另外，系统易维护性的提高也是重中之重的任务。

［1］黄昱旻.地铁综合监控系统结构研究［J］.现代城市轨道交通，2009(4):21-23.

［2］李中.地铁综合监控系统应用技术研究［J］.城市轨道交通研究，2008(10):44-47.

［3］胡泽盛.广州地铁主控系统接口冗余通信分析［J］.都市快轨交通，2009，22(6):86-89.

［4］刘丽.轨道交通综合监控系统的网络设计［J］.都市快轨交通，2010，23(6):40-43.

［5］张慎明，王军.新一代综合监控系统若干问题的研究和探讨［J］.现代城市轨道交通，2010(1):18-21.

［6］姜臻祺.适合轨道交通综合监控系统(ISCS)运营组织体系相关问题的探讨［J］.地下工程与隧道，2009(4):43-45.

［7］谢金华.对城市轨道交通综合监控系统方案的阐述［J］.建材与装饰，2010(7):252-253.