城市轨道交通综合监控系统数据规模和系统性能分析Word格式.docx

城市轨道交通综合监控系统数据规模和系统性能分析Word格式.docx

《城市轨道交通综合监控系统数据规模和系统性能分析Word格式.docx》由会员分享，可在线阅读，更多相关《城市轨道交通综合监控系统数据规模和系统性能分析Word格式.docx（7页珍藏版）》请在冰点文库上搜索。

ISCS软件平台整体结构应具有灵活性、可扩展性、稳定性的特点。

凭借整体结构的扩展能力，系统应可在未来增加服务器的数量，使系统升级到更高的点数。

为了保证系统的性能和将来扩充，服务器、网络和软件平台的处理能力在上述基础上预留30%以上的裕量。

集成系统实时向ISCS系统传送数据，ISCS系统应支持查询和事件触发方式与集成系统交换数据。

　　3性能分析

　　3.1现场设备控制时间

　　现场设备的控制时间指从操作员发出控制和指令操作开始，到控制和指令操作条件检查返回为止的时间，包括控制和指令传送到FEP、进行处理和激活控制点或信息的时间。

　　中心对现场设备的控制相应信息返回时间不应大于4s。

从中心控制命令发出，到现场设备开始动作的时间不应大于2s。

车站的现场设备的控制时间不应大于2s。

从车站控制命令发出，到现场设备开始动作的时间不应大于1s。

当一个控制命令执行出错时，ISCS系统应能及时作出提示，并且不能影响系统其它功能。

　　3.2系统可用性

　　ISCS系统是一个大型的分层分布式计算机监控系统，系统的有效性一方面依赖于系统充分地无故障正常工作，另一方面依靠系统发生故障时尽快地修复系统恢复正常。

按照可靠性原理，ISCS是一个可修复系统，可修复系统的系统可靠性用有效性或有效度A指标来表示。

系统有效度也就是系统有效性定义为系统考核期内系统正常工作时间与考核期全部时间之比。

　　系统有效性A按如下公式计算：

　　式中：

MTBF为系统平均故障间隔时间；

MTTR为系统平均修复时间，反映了系统的有效工作时间的统计值、后者反映了系统修复恢复正常的时间统计值。

　　下图说明了MTBF与MTTR的含义及关系，也说明了MTBF和MTTR的统计性质。

　　由图可见：

（2）

　　（3）一个系统的MTBF和MTTR是统计计算得出，不是由确定性公式计算出来的。

正像可靠性指标A是一个概率统计值一样，MTBF和MTTR也是一个概率统计值。

　　由

（1）式可见，提高系统有效度（可靠性）的方法是尽可能提高MTBF值和降低MTTR时间。

　　在分析系统有效性时，关键是确定系统在考核期内的正常工作时间和系统故障时间（总时间为两者之和）。

因此，ISCS可用性计算必须统计计算关键设备的主要故障时间。

　　ISCS中，每个子系统的内部设备可以划分为关键设备和非关键设备。

如果一个设备故障影响到整个系统的运行，它被视为关键设备。

例如，ISCS服务器是关键设备，而打印机则是非关键设备。

因为服务器故障会导致系统崩溃（在第二台服务器已故障的前提下），但如果打印机发生故障，仅仅会影响打印功能。

　　每个设备故障分为主要故障和次要故障。

当故障影响到系统的主要功能，则此故障视为主要故障。

比如，对服务器而言，磁盘故障视为主要故障，但是，DVD光驱故障被视为次要故障。

　　在对系统进行有效性考核时，必须考虑以上因素。

按照关键设备的主要故障发生的具体情况判定全系统故障从而来统计计算系统的MTBF和MTTR的值。

系统有效性的考核是一个科学的过程，在考核期内（例如，连续考核数个月或半年）记录关键设备的主要故障并记录考核结果，统计出MTBF与MTTR的值。

　　⑴关键设备的可靠性指标。

以苏州地铁4号线为例，在本项目中，主要设备可靠性指标如下表所示：

　　设备MTBFMTTR

　　工作站5万小时1小时

　　服务器10万小时1小时

　　10万小时1小时

　　磁盘阵列100万小时1小时

　　FEP10万小时1小时

　　交换机20万小时0.5小时

　　⑵MTBF计算

　　ISCS工作站、历史服务器、实时服务器、交换机、FEP都采用完全冗余配置（并联），根据并联系统MTBF计算公式，双份冗余设备的MTBF是单个设备MTBF值的平方，即

　　本系统历史服务器配置了磁盘阵列，冗余历史服务器和磁盘阵列组成了串联的服务器―磁盘阵列系统。

其MTBF值为：

　　历史服务器―磁盘阵列、实时服务器、网管服务器组成了一个服务器权联系统；

其中网管服务器仅对网管工作站提供少量数据，而实时/历史服务器则负责为工作站提供大量的数据，所以网管服务器的权重显然远低于实时/历史服务器，故可忽略，服务器权联系统MTBF值计算如下：

　　所有的调度员工作站组成了一个工作站权联系统。

由于工作站的型号统一，因此

　　工作站权联系统、服务器权联系统、冗余交换机、冗余FEP组成了一个串联的ISCS综合监控系统，整个ISCS综合监控系统的MTBF计算如下：

　　⑶MTTR计算

　　ISCS综合信息系统的平均修复时间MTTR是按系统内各个设备失效率进行加权平均的平均值。

　　根据MTTR计算公式

　　首先计算ISCS综合监控系统各成员的故障率λ，即各成员的MTTR权重：

　　磁盘阵列：

MTRR1=1

　　冗余工作站：

MTRR2=1

　　冗余服务器：

MTRR3=1　　冗余交换机：

MTRR4=1

　　冗余FEP：

MTRR5=1

　　经计算，

　　据可用率公式：

　　3.3系统可靠性

　　系统服务器、前端处理器的主机、备机的切换时间不大于3秒钟，切换时间从软件或硬件被检测出故障开始算起，到ISCS完全可用为止。

　　数据库服务器的主机、备机的切换时间不大于15s。

　　缓存区已满不引起ISCS的崩溃。

　　任何网络设备，包括操作员工作站、服务器、交换机等，如果发生单点故障，不影响ISCS的正常工作。

　　对ISCS进行的可靠性设计主要表现在对系统关键设备的冗余设计上。

在ISCS中，对系统的三级网络（MNS、中央监控网、车站监控网、现场总线）、中央服务器、车站服务器、FEP、操作员工作站、环境与设备监控子系统的PLC进行了双重冗余设计。

　　网络及主要控制器都采取了双重冗余，极大地提供了系统的可靠性。

　　按照现代可靠性理论，关于双重冗余系统的可靠性计算分析如下：

　　若一个单系统未采取双重冗余时的故障率为λ，修复率为μ，按照可靠性理论：

　　可修复系统的运行过程是一个由正常工作过程到故障过程，经过修复恢复正常工作过程的不断反复的随机过程，此随机过程可近似为一个马尔柯夫随机过程（平稳随机过程）。

采用平稳随机过程状态转移矩阵的分析方法，可以计算出正常状态和故障状态的概率，从而计算出各个可靠性指标。

系统冗余配置时，其随机过程的状态转移可以用马尔柯夫图表示。

　　图中S0为主备系统都正常状态，S1为一个系统故障状态，S2为两个系统都故障状态。

按照马尔柯夫过程的随机状态转移原理，其状态转移矩阵为：

　　其中P0为冗余系统都正常时的概率；

P1为主系统故障备用系统正常的概率；

P2为主备系统都故障的概率，

　　且

　　P0为两冗余系统都正常的概率

　　P1为冗余系统其中一个正常，一个故障的概率

　　P2为两个冗余系统都故障的概率

　　系统正常得概率为P0+P1，即系统可用度：

　　与单系统相比，冗余系统可靠度大大提高，一般有效度可提高一个“数量级”，即如果单系统A=90%，则双重冗余系统的A=99%。

单系统A=99%，双重冗余系统的A=99.9%。

　　以苏州4号线为例，ISCS的高可靠性解决方案如下：

　　⑴冗余、热备中央服务器：

当主服务器发生故障（包括软件或硬件故障），备份服务器自动接管主服务器功能。

服务器切换时，没有数据丢失。

　　⑵冗余系统网络：

系统网络上每台关键设备和两个网络都有连接，避免一个网络故障，影响数据通信。

当一台交换机故障时，另一台交换机根据网络拓扑，动态切换到网络中最短的路径。

　　⑶冗余、热备车站服务器：

　　软件开发和实施过程进行严格质量控制，采用有效的错误分析和跟踪方法，确保每一个提交的软件部件都通过仔细的测试和代码分析；

　　以上这些方法在多个领域的监控系统都已经得到了成功应用，确保了系统连续运营。

　　3.4系统扩展性

　　鉴于苏州市轨道交通建设处于高速发展阶段，多条线路同时建设，相继投入运营。

因此要求综合监控系统具有良好的扩展性，综合监控系统具有如下特点：

　　⑴系统设备模块化，软件组件化，可以实现灵活拼装。

　　⑵硬件配置和数据组织形式以车站综合监控系统为单位，一个车站就是一个模块，是基础的数据源。

车站综合监控系统可以向多个中心同时提供数据服务，支持多中心结构。

　　⑶采用通用以太网设备和开放的通讯协议，网络系统扩展性好，允许平滑扩展。

　　⑷采用中间件技术，对于应用软件屏蔽具体的物理连接和位置，对于任何数据对象访问，均可以用线路名-站名-点名逐级检索，每个数据对象的命名在整个苏州轨道交通是唯一的。

　　考虑为4号线及支线延伸线预留一定的条件，建议方案如下：

　　⑴增加新站：

单独调试新站的车站ISCS，在完成后，将该站本地ISCS网络连入骨干网，将该站数据库配置组态数据加入控制中心数据库，在中心操作站增加新站画面。

　　⑵增加换乘站：

修改数据库，增加被监控设备的组态配置数据，通过开放的数据接口获得新建部分的数据，同时向另一条线路的ISCS提供既有系统的信息，在车站和中心增加部分画面。

　　ISCS系统支持服务器群集（CLUSTER）的扩展方式，在现有服务器性能不能满足系统扩展需要时，能够通过配置新的服务器，分布式管理新建车站或其他扩展要求，由多组服务器共同完成ISCS的监控功能。

新旧服务器可以是不同厂家和型号的设备，通过CORBA实现异构分布式数据环境下的远程对象调用，满足系统扩展性的要求。

　　系统软件提供多种开放的协议，第三方厂商可以通过网络接口，在得到授权后，获取ISCS数据。

系统软件还能够增加各种数据接口，实现与其他系统的数据共享。

　　[参考文献]

　　[1]魏晓东.地铁综合监控系统建设关键问题分析[J].现代城市轨道交通.2009（06）.

　　[2]黄昱?

F.地铁综合监控系统结构研究[J].现代城市轨道交通.2009（04）.

　　[3]张森，蔡昌俊，何正友，于敏.地铁综合监控系统可靠性分析与数据管理软件研制[J].交通运输工程与信息学报.2007（04）.

　　[4]徐杰，贾利民，秦勇，王艳辉，王卓.城市轨道交通综合监控平台系统集成的研究[J].铁道学报.2007（03）.