近期工作汇报与之行收获

1、近期工作1、阅读论文针对线路的综合监控系统与子系统的集成模式、FEP前置机进行了大量的论文阅读，根据调研得到的资料，重新设计接入系统的架构。 前置机FEP(Front End Processor)在中央主机和用户终端(或个人工作站、外围设备)之间实现数据的上传下达工作,不仅可以有效地减轻主机系统的工作负担,提高系统的工作效率,而且也能起到保护主机系统安全的作用。FEP可以作为综合监控系统与各子系统之间的分界面,可以实现主系统和子系统之间的硬件隔离。FEP管理ISCS与各被集成和互联系统的接口,并进行规约转换和初步的数据处理;采用专用工业级产品,并且具有支持多种协议转换、支持多种通信接口的模块;

2、具有足够的网络口、串口,以接入各子系统的数据;各功能模块具有自诊断功能。综合监控系统与子系统的接口种类多、类型复杂, 因此综合监控系统设置了前端处理机对接口进行统一的通信处理。前端处理机( front end processor , FEP)是在线路控制器和多重线路控制器的基础上用于主计算机之间通信的设备,用来代替固定连线的通信控制器,控制大型主机和通信终端之间的数据传输, 完成子系统的全部数据通信任务。FEP可提供 RS232串口、串行( COM )控制口、内置交换机网口,使各子系统数据最终通过以太网接入综合监控系统。 综上所述，FEP以往在地铁系统中主要用于各线路子系统的数据接入到ISCS

3、中去，由于各子系统本身建设时采用的通信方式各异，在将数据采集到综合监控系统之前，需要通过不同的总线接口将数据汇集到FEP，最终通过以太网将数据发送到综合监控系统。可以看出，FEP很大的作用就是进行通信协议的统一。但是在我们的线网指挥平台的设计中，所有的数据都是直接从各线路的OCC获取，那么就区别于线路采集各子系统数据的过程，不用进行协议的转换，直接通过以太网从线路控制中心获取实时数据即可。由此可知，可以由常规的服务器来作为前置机，实现前置机的各种数据处理功能，不需要提供多种总线接口接入不同通信方式的数据。随着计算机硬件技术、网络技术的飞速发展，轨道交通行业应用的服务器、交换机等硬件设备性能越来

4、越好。随着服务器、工作站产品的不断发展，其主频、内存等的性能指标越来越高，完全可以满足融合FEP硬件性能的要求。所以在我们的接入系统中，TCC端设立的FEP不需要采用专门的FEP硬件设备，而采用服务器产品来起到前置机的作用即可。针对我们系统中TCC端FEP的具体硬件选型，仍需要进一步分析调研，通过分析数据量等方面的因素，再进行相应选择。2、根据调研调整接入系统架构之前设计的接入系统的架构如下： 在此架构我们的系统中，主要的工作重心在于OCC接入服务器，而在TCC端还要设立FEP。经过近期的大量论文阅读，比如在一篇论文中分析线路综合监控系统的深度集成模式与顶层集成模式的差别，指出了顶层集成模式下

5、，综合监控系统通过FEP将两个分开的软件平台连接在一起,使得原本可以一次完成数据采集、数据处理和数据表示的一体化软件处理方式,变成先由被集成子系统进行数据采集、数据处理、数据表示后，再转发到综合监控系统,综合监控系统接收到数据后再进行数据转换、数据再处理和数据表示等过程。由此看出,在整个数据处理过程中增加了一个转换和再处理环节,直接导致系统的实时响应性受到拖累。所以再次考虑我们的接入系统，注意到OCC接入系统的功能完全可以由TCC端的FEP来实现，这样省略掉OCC接入系统，就能减少一个转换再处理的环节，系统的实时响应也能得到提高。而OCC接入系统的所有功能则转移到TCC的FEP上进行，在此将这

6、种FEP称为TCC接入系统服务器，将主要接入数据的工作都集中到TCC接入系统上。因而再次设计系统的架构如下：3、进行编码工作针对架构的改变，进行相应代码的调整，开始着手调研冗余备份的知识，下一步准备进行TCC接入系统冗余备份模块的实现工作。由于前期方便开发，采用在Windows下使用VS开发平台进行编码工作，随着项目的深入，需要涉及到越来越多的系统层内容，所以将项目从windows平台向unix平台进行移植。在移植过程中也遇到了大量的问题，进行了一一解决。4、数据标准工作针对数据标准工作，进行了调研，深入研究李美玲师姐针对广州地铁城轨线网数据标准统一的毕业论文，经过小组开会讨论，对广州地铁城轨

7、线网数据标准的统一方案进行了深入的探讨，针对业务层、技术层、数据元层数据标准统一的方法进行了商讨，确定数据标准统一的流程。参考小组讨论的结果，定出数据标准统一的指导方法，针对TIS（列车信息系统）的数据标准，进行了其数据标准的统一。Ps：TIS系统只有APM线的数据点表，所以统计的标准仍待修改。北京调研在北京调研的过程中，主要针对北京TCC关于数据接入部分进行关注，认真听取、记录了北京TCC数据接入相关内容。奔迅公司的工作重点是指挥控制平台，也就是北京TCC的一期工程，进行全线网的实时监控，从对方介绍可知，此项目是由包括北交大、同济等几百人的团队完成的；而北京TCC的二期工程即信息中心，主要针

8、对的是历史数据的再次开发、利用。线网指挥平台和信息中心的数据都是从TCC的FEP上获取得到，TCC的FEP负责接入各条线路的实时数据，因此在我们的接入系统中，数据接入的主要工作就放在这个FEP上，即我们所说的TCC接入系统。线网指挥平台主要是针对行车、客流和设备三个方面进行重点监控，但主要只是进行监视，而不进行控制，其核心作用是在突发事件发生时的应急指挥功能，而控制的功能主要是由各线路的OCC来完成的。依赖业务的需要，进行TCC和OCC的接口设计，接口设计需要进行折合，在不影响OCC数据的基础上进行，数据的接入和转换都是以线路为单位。在进行数据接入的时候，采用什么协议来传输相应专业的数据，北京

9、TCC考虑现实情况进行选择，比如历史遗留原因等。大部分专业数据的传输采用Modbus TCP协议，SIG系统采用自定义的事件驱动报文2.0协议，这是一种纯报文协议；北京使用MQ来传输客流信息数据，可能是历史原因，而且MQ满足业务需要；PIDS和CCTV采用的都是自定义的协议。PIDS的不同线路采用不同的协议，可能是历史遗留问题，总之TCC给定一个标准，通过代理来实现统一。采用这些不同协议的原因是，TCC更加关注行车信息和设备信息，对客流信息实时性要求不高，主要是看客流趋势，起到预警作用，进行后期分析工作，不是特别考虑监视作用，而是决策作用，所以采用MQ。行车信息和设备信息实时性要求较高，行车信

10、息的SIG采用事件驱动型协议，数据变一次推一次。设备信息采用MODBUS每500ms向OCC拿一次全量数据，只拿快照，拿到全量数据后，只处理其中变化的数据。北京TCC在进行实时数据接入的时候，由TCC提供标准给各条线路的OCC，OCC为了接入数据，按TCC规定的格式将数据放入内存中，TCC的FEP来这块内存中取数据。OCC对线路本身的所有专业进行接入，OCC根据TCC所提供的接口要求，发布相应的数据到内存中。关于TCC接入系统冗余切换的设计，切换模块不能是单向请求，应该采用双主动模式来保证成功切换。主的机器是固定的某台机器，如果主坏了，备机暂时顶上，当主机修好之后，继续使用主机作为主运行。如果两台都是主的话，客户端到底从哪里来获得数据，不好，所以主机和备机要分清。经过北京调研，对接入的思路有了更清晰的认识，对我们的工作主要由以下几方面的指导：1、在我们的接入系统中，关于接口设计，由于现在线网中心与线路中心的接口没有拟定，需要模拟出线路数据在线网中数据点地址的转换接口，来开展我们的工作。2、在我们设计的时候，所有数据的接入都应该是TCC端的FEP即TCC接入系统向OCC的子系统请求，从OCC子系统的服务器的内存中取数据。如下图所示：3、在指挥平台中，主要进行监控，所以TCC只去OC