城市轨道交通综合监控系统通信协议的设计与实现

‐1‐  城市轨道交通综合监控系统通信协议的设计与实现 陈天皓，沈涤凡（国电南瑞科技股份有限公司，江苏，南京，210061） 摘要：本文简要介绍了城市轨道交通综合监控系统以及通信协议在其中的地位和作用，之后结合开发实际经验和遇到的问题，本着通用性的原则，提出了通信协议开发中若干常见功能的实现方案，并对其中一些方案的适用性进行了对比。 关键词：综合监控；通信协议；连接；数据；报文 Abstract:ThispaperhasintroducedtheIntegratedSupervisingandControlSystemofthemetro,aswellascommunicationprotocolinthisfield.Accordingtotheexperienceandproblemsfacedwhendeveloping,ithasalsoraisedsomeschemesandsuggestionsaboutseveralcommonquestionsinthecourseofcommunicationprotocoldeveloping,andhasmadeacontrasttotheperformanceofsomeschemes.Keyword:ISCS,communicationprotocol,connect,data,message1．引言城市轨道交通自动化系统传统上由许多分立的子系统组成，通常包括有电力监控系统（PSCADA）、环境与设备监控系统（EMS或BAS）、信号系统（SIG）、火灾自动报警系统（FAS）、门禁系统（ACS）、自动售检票系统（AFC）、屏蔽门系统（PSD）、闭路电视监控系统（CCTV）、广播系统（PA）、乘客信息系统（PIS）等。这些分立的子系统按照自身的技术特点，在控制中心都有本专业单独的服务器和其他相关设备，以及各自不同结构的通信网络，采用各不相同的软硬件平台；在各车站也有自己的监控网络，形成了各自相对独立的分立监控系统和网络。随着城市轨道交通客运量的增加、轨道交通监控范围的扩大、业务复杂性、多样性及业务量不断增长，这种传统的、孤立的系统难于满足现代化综合业务管理的需求。因此，在各业务部门系统化的同时，将各系统通过网络有机地连接在一起，集成于一个综合系统，使各部门之间信息共享，达到业务管理的合理化、现代化，我们称上述系统为综合监控系统（ISCS）。2．综合监控系统体系结构ISCS的结构如图1所示。通常包括通信协议模块、专业应用模块、人机界面模块、告警服务模块、以及数据库模块等。通信协议模块（主站端）是整个综合监控系统与系统外设备进行数据交互的总接口，如果在这一环节数据发生严重的了丢失或者错误，那么之后对数据进行的所有处理以及做出的响应都不再有意义。‐2‐  ISCS软件结构通道1专业应用模块人机界面模块PSCADA专业其他各专业BAS/EMS专业告警服务模块通信协议模块(主站端)通道2通道3通道4通道5通道…通道n历史数据库实时数据库数据库管理模块数据库管理模块厂站端的各种设备通道1通道2通道3通道4通道5通道…通道n通信协议模块(厂站端)图1.综合监控系统结构示意图通信协议模块分为两个部分，主站端部分（即作为监控系统）和厂站端部分（即作为被监控方的各种现场设备）。厂站端部分负责接收主站端的系统命令和控制命令、上送本地设备数据报文；主站端负责发送ISCS须递交给厂站的各种命令报文，以及接收厂站端发送的设备数据并转交给ISCS其他相应模块或实时数据库。通信协议模块的两端必须共同配合才能完成好数据的交互。每一种设备会由于数据量、数据类型、传输介质等多种现场条件的限制和要求而采用不尽相同的应用层通信协议。常见的通信协议有IEC60870-5系列协议、Modbus现场总线协议以及设备生产商的私有协议等。3．协议的设计和实现大部分通信协议在安全传输控制和报文收发上都会提出一些功能性的要求，在本文这一部分，将本着通用的原则，必要时以IEC60870-5-104协议为例，简单讨论通信协议中几种常见功能的实现方案。3.1.通信协议接口程序结构在设计通信协议接口程序时，的结构由图2所示的三个部分组成：‐3‐  图2.通信协议接口程序结构示意图（1）协议模块：负责报文的校验、解析与响应，工作在应用层；（2）通讯模块：负责链路管理和数据收发，工作在网络传输层；（3）调度模块：监视协议模块和通讯模块的工作情况，处理其它事务；协议模块和通讯模块间的数据交互通过一对收发队列（IOQueue）实现，通讯模块接收字节流数据，存入InQueue中，协议模块从InQueue取出接收到的数据进行校验、解析，并做出响应（更新本地数据、转发接收数据或者回复）。若须要回复，则由协议模块组好报文后将其存入OutQueue，通讯模块发现OutQueue中有待发送报文时便会将其取出发送。实现时，通讯模块和协议模块可以分别作为一个单独的线程，调度模块可以置于两个线程之一，也可以作为一个单独的线程。如此采用多线程方式实现，在使程序结构清晰的同时，由可以让报文的接收和处理可以同时进行，提高了效率。通信协议接口程序（通讯模块以TCP协议为例）：a．调度模块被执行，启动协议模块（线程）和通信模块（线程）；b．通信模块监听端口的连接请求；c．通讯模块与主站端建立TCP连接，接收到报文；d．通讯模块将报文放入InQueue；e．协议模块从InQueue中检索报文首部，接收一帧报文；f．协议模块解析报文格式和内容，校验其正确性后进行处理和响应；g．协议模块协议模块将待发送数据放入OutQueue；h．通讯模块从OutQueue中取出数据发送。3.2．连接建立与断开控制通信协议通常要求当报文传输发生某些故障时（例如网络超时和丢失报文），TCP连接主动关闭并在稍后再自动尝试建立新的连接。对于这一要求，通过在通讯模块中建立双层循环结构可以实现这一功能。双层循环结构的简要流程如图3。‐4‐  通讯模块标志未清空接收字节流数据连接无异常内循环开始外循环开始初始化，置连接状态标志内循环结束Yes断开TCP连接退出内循环建立或接受TCP连接Yes置连接状态标志标志已置上外循环结束NoYesNoNo图3.用于实现连接控制功能的双层循环在图3所示的双层循环结构中，连接状态标志是实现连接控制功能的关键。程序初始化时置标志位；外循环建立连接后，只要当前连接保持不断开，就一直执行内循环，当通讯模块工作的网络传输层本身发生故障时，程序断开当前连接跳出内循环，之后在外循环中因为连接状态标志没有发生改变，所以稍后会自动重新尝试连接（对应于Client端）或重新开始接受连接（对应于Server端）。如果是通信协议需要控制连接，只要在协议模块中对连接状态标志进行置位或清除即可。3.3．分次获取一帧完整报文由于TCP传输方式的可靠性，有很多基于网络的协议会采用TCP作为网络传输层协议。但是TCP是一个面向字节流数据的协议，所以在开发应用层协议时有必要考虑协议模块从InQueue中分次取出一整帧报文的情况。通常，报文的首部都会指出该帧报文的标称长度。从InQueue中取报文的过程实际上是标称长度的字节流依次出队列存入缓冲区的过程。考虑到TCP协议能够保证字节流按序到达，所以只要InQueue中实际字节长度不小于标称长度就表示可以一次性取得一帧完整的报文，否则表示InQueue中的昀后一帧报文尚未接收完全。这样，想要从InQueue中获取一帧完整报文就有了两种方案：方案一：先读出报文首部，然后等待InQueue中的实际字节长度达到标称长度后，协议模块即可从InQueue中取出一帧完整报文。‐5‐  方案二：先读出报文首部，然后立刻尝试从InQueue中取标称长度的字节数据，并记录实际取出的字节长度，若实际取出的字节数达到标称长度则表示一帧报文取完；若未能达到标称长度则在缓冲区保留已取出的字节，在下一次从InQueue中取数据时尝试取出长度为标称长度与前一次实际取出长度之差的字节，这样直到取完一帧完整报文为止。两种方案中，第1种实现比较简单，可是等待的过程会影响程序运行效率，并且要求InQueue的长度必须不小于所使用的通信协议中昀长报文的长度，否则协议模块会一直等待。第2种方案对InQueue长度的要求没有上述限制，并且对InQueue中的数据随到随取，减少了一帧报文的接收时间。3.4．滑动窗口缓队列在通信协议的安全传输控制机制中，报文确认机制非常常见。就是说，报文发送方要将报文编号，并将一个或几个昀近发送的报文保存到缓冲区中。接收方在收到正确的报文后向发送方发出确认。发送方收到确认后才可以从缓存中删除已经被确认的报文，再接着发送新的报文。如果已发送报文长期不能得到确认，即认为接收方或网络存在故障，以便才去进一步措施。为实现这一功能，可以在协议模块设置一个滑动窗口环形队列用以存储已经发送且尚未被确认的报文。滑动窗口如图4所示。空闲部分协议模块滑动窗口队列通讯模块InQueueOutQueue网络控制协议模块其他部分等待发送已发送等待确认空闲部分指针移动方向图4.滑动窗口队列示意图如图所示，滑动窗口有3个指针用分别以标记入队列报文位置、已发送报文位置和已确认报文位置，如此将滑动窗口分为三个段：已确认指针到已发送指针之间为已发送，等待确认的报文；已发送指针到入队列指针之间为在队列中等待发送的报文；入队列指针到已发送指针之间为队列中的空闲空间。滑动窗口初始化时，3个指针都归零。每当协议模块须要发送报文时，先将报文送至滑动窗口，此时入队列指针根据报文长度累加移动到新位置；当协议模块发现滑动窗口中存有带发送报文时，将报文取出后放入OutQueue以便通讯模块发送，同时已发送指针累加移动一帧报文的位置；当收到接收方对报文的确认时，根据确认序号移动已确认指针，释放队列空间。3.5．厂站端变化数据的比较与查找通信协议中要求厂站端上送变化数据是非常常见的功能，例如IEC60870-5-104协议中要求厂站端不停的刷新本地数据，并且根据不同数据类型将变化数据组织成相应格式的报文‐6‐  主动上送给主站端。既然要判断哪些数据发生了变化，就要将当前时刻数据与前一时刻数据进行比较，也就要备份前一时刻设备的数据，还要标记出哪些数据发生了变化。下面是两种实现方案：方案一：根据设备数据总量设置相同大小的用以存放备份数据的结构（例如一个成员为结构的数组），再为发生变化的数据设置一个新的存储结构（例如一个成员为结构的队列）。这样每次进行比较时将当前数据录入数组以备下次比较之用，同时将发生变化的数据存入队列。上送变化数据时从队列中取出数据，组包上送，释放队列空间。方案二：根据设备数据总量设置相同大小的用以存放备份数据的结构（例如一个成员为结构的数组），不设置存放变化数据的队列，而是在数组中为每一个成员添加一个属性记录其是否在昀近的比较中发现变化。上送变化数据时就取出数组中变化属性被标记的成员，并将其该项属性清除以保证对同一次变化只发送一次。两种方案的对比：方案一的优点在于能够记录每一个数据点的每一次变化，缺点是空间开销太大。并且当发送速率小于数据变化速率时（网络拥塞或产站设备发生故障），队列数据增加的净速率会持续大于0，必须考虑在此情况下是丢弃新数据还是替换掉未及发送的旧数据的策略。方案二的优点在于能够保证上送的数据都是该数据点的昀新值，并且节约了空间开销。缺点是如果某一数据点的值频繁发生变化，当其变化速率超过报文上送速率时，会丢失对该数据点变化过程的监测。这两种方案各有优缺点，在使用时应根据实际的情况合理进行选择。方案一适用于数据点数量较少，且整体变化不至于太剧烈的设备；而方案二适用于单个数据点变化不会过于频繁的设备。4．结语城市轨道交通综合监控系统是以现代计算机技术、网络技术、自动化技术和信息技术为基础的大型计算机集成系统，通信协议模块是直接连接监控系统和被控设备数据的桥梁和枢纽。本文针对通信协议常见功能提出的设计和实现方案具有一定的通用性，但对于不同的协议而言一定存在专用的更好的策略和方案。日前，