整个高铁运行线路按照运行区段进行划分，每个运行区段部署一个防灾监控系统，根据各自区段的不同，每个防灾监控系统所部署的监测基站数目、监测内容以及终端数量都不尽相同。以本文中介绍的应用通信服务器所在的某客专线路防灾监测系统为例：铁路沿线部署了四十个数据监测基站来采集不同的灾害数据，终端包括一个行车调度终端、一个工务调度终端以及若干个工务段终端。
基站采集到的数据类型不尽相同，一定时间内采集到的数据量也是变化的，因此数据流的长度是可变的。此外，在不同的情况下，数据流的目的地可能单一也可能多重。例如，从基站采集到的气象数据需要发往每一个终端，而从终端发往基站的命令则往往只指向一个基站。如果让基站和终端之间直接以点对点的方式建立通信，则整个通信网络结构会变得复杂，如果没有特殊的通信管理，多点连接和重复的数据传输会导致信道拥堵，从而降低监测的实时性和可靠性，这对于关系到铁路运输安全的防灾系统来说是行不通的。
为了使得系统内的通信高效可靠，系统采用了客户端-服务器的模型。我们针对基站和终端之间的通信特点设计了应用通信服务器，负责从基站统一采集数据，经过服务器处理后再统一分发给各终端。终端的控制信息也首先经过应用通信服务器处理后再发送给指定的基站，从而实现对通信过程的简化和良好的控制，系统的高效和可靠的运行也得到了保证。
2  高铁防灾监测系统应用通信服务器的概念
在高铁防灾系统中，所要传输的信息分布在基站的监控单元、显示终端设备以及数据库之间。例如当基站A收集到当地的风速信息后，需要将风速原始数据发送到工务调度终端B和行车调度终端C进行显示，同时还要将数据存入数据库D进行保存；此外，还需要有装置可以根据风速数据进行判断是否报警并传送报警信息至终端和服务器。如果按照点对点的数据传输方式，基站A首先要将数据发送给终端B，然后将相同的数据发送到基站C和数据库D。报警信息的判断可以放在终端或基站来做，但这样每一个基站或终端都必须部署相应的判断程序。这一种方式使得复杂的数据被传送了多次，当数据量大时会造成信道拥堵；此外在每一个基站和终端都部署相同的报警判断程序显然也增加了系统部署的成本和难度，降低了效率和可靠性。这时，如果能有一个程序能够接受基站的数据，并对数据进行判断整合，产生包含报警信息和原始数据的数据包，再统一转发给终端和数据库，则整个通信过程将能得到简化。实现这一功能的程序正是应用通信服务器。
图2.1 高铁防灾监测系统总体结构图
高铁防灾监测系统的总体结构如图2.1所示。从图中结构可以看出灾害数据在系统中的传递模式为：
气象现场传感器实时监测风、雨等气象数据，传至基站中的监控单元(由PLC担负)，由监控单元做初步处理及缓存，将处理结果通过通信通道发送至监控数据处理设备，由监控数据处理设备中的应用通信服务器根据预设的判断原则生成报警信息，并将报警信息以及灾害原始数据传送到各监控终端，同时将数据及报警信息储存至数据库。各基站和终端及数据库之间通过应用服务器进行连接的拓扑结构如图2.2所示。这一通信服务模式采用了星型拓扑结构，基站、终端、数据库以及负责与其它运行区段的防灾系统连接的接口服务器都连接于应用通信服务器，他们之间的通信都通过应用通信服务器进行控制（但终端对数据库的操作并不经过应用通信服务器）。
  高速铁路防灾监测应用通信系统设计(2):http://www.youerw.com/zidonghua/lunwen_18962.html