近期典型故障处理情况通报

第一篇：近期典型故障处理情况通报

近期典型网络故障情况通报

近期处理网络故障较多，综合处理情况，现将几起典型故障处理情况过程通报如下，请各县市分公司能加强管理，提高维护人员的故障处理能力和责任心。

一、传输数据中心在对网络例行检查时发现营业部OA、CMNET、BOSS三网络成环，结合营业部办公楼近期故障较多的情况，安排中移代维人员进行集中查处，具体处理情况见（营业部环路分析报告）,从营业部代维人员的分析报告中可以看出几点问题，请营业部要落实：（1）首先营业部二楼机房网线较乱，营业部是否安排人员对机柜进行整理，其它区域的机柜是否也有类似情况，应安排维护人员对所有的机房机柜进行检查整改；（2）兴马（代理商）为什么会从营业部接入CMNET网络，是否有相关部门的批准，兴马将BOSS与CMNET接入同一交换机，造成CMNET与BOSS成环，是自行接入还是公司维护人员接入的？网络私接乱拉是否有相关的考核办法；（3）舞阳十楼无营业部的相关部门，为什么会有BOSS和OA的网络，请营业部清理相关的IP地址，对不需要使用的进行删除。

二、建始分公司网络成环影响到恩施分公司整个的OA及BOSS网运行情况，在建始分公司报故障的同时也有其它县市报故障，为保证全网正常运行，传输数据中心按业务需求对相应的网络隔离断开连接，按照BOSS大于OA；OA大于CMNET的原则进行处理，请建始分公司结合本公司故障查询情况加强区域管理，对工程建设情况造成的故障，指定随工人员的管理。故障处理经过见（7月8日建始环路故障报告）。

三、巴东分公司处理电视电话会议网络不通的过程中，可发现以下几个问题，请巴东分公司明确整改：（1）巴东分公司领取设备更换后能不能正常使用未进行测试；（2）在巴东需要视频进行监考前才联系州公司说因设备故障不能使用，巴东分公司维护人员在设备到巴东和视频监考开始前这段时间在做什么，故障处理及时率在哪里？维护管理人员是如何安排的（3）巴东分公司视讯会议系统由技术支持中心维护，不能以没有人处理（下乡）为由。

结合以上几个县市分公司出现的问题，请各县市加强网络维护的管理，对私接乱拉的制定相应的考核机制；同时，要加强维护人员的责任心，对故障处理超时、找借口之类的情况实行问责制，对代维人员加强管理，提高代维人员故障处理能力；对于县市分公司维护管理人员故障安排协调不力的情况进行通报。

第二篇：APG典型故障处理小结

APG典型故障处理小结

1、故障：intelligent networks management interface

分析：此告警表明文件系统在处理intelligent networks management interface（INM）接口连接时出错。

此时有两种情况：

1、ACTIVE CONNECTION FILE BUFFER表明缓冲区文件有误；

2、INM LOG FILE 表明INM的LOG文件处理时出错，此种情况比较常见，LOG FILE因为某些偶然原因被删除后就会出现这种情况，例如有时LARGE RESTART或是RELOAD后丢失此子文件。

处理: 用指令ssmpi:sfn=n+1其中SFN:SUBFILE NAME。n为最后一个INMLOG中的子文件的数目，出现这种情况。APG40中可以用CPFLS-S指令直接查看INMLOG 中的子文件情况。

2、故障：APG40系统中文件无法传到OSSDESTx的问题。

分析：多数此类告警都可以用指令CDHLS-L 查看所有路径的OSSDESTx的传输类型和参数定义有否正确。大多数都不会有参数丢失的情况，然后用CDHVER 查看告警制定的OSS路径的状态是否OK,否则用指令CDHVER-M 人工修正使状态变为正常，消除告警。

但是有的告警比较特殊例如:

AP FILE PROCESSING FAULT

CAUSE FILE TRANSFER FAILED TRANSFER QUEUE ALOG DESTINATION SET OSSDESTALOG Problem Data Transfer error 分析处理过程：先试着用以上常规的处理方法即以上指令来设法消除此告警：

1、用acease无法消除告警

2、cdhls-l OSSDESTALOG查看此路径的所有传输参数，一切均正确。

3、用cdhver OSSDESTALOG看其状态，结果显示STATUS OK。

4、于是确认了本地交换机的设置没有问题，怀疑是到OSS的网络不通 但用指令ping 对端oss的IP, 显示网络路径完全正常；后来注意到A3级的一个告警，是由于刚才那个A2级告警引起的：

DATA OUTPUT, AP COMMON DESTINATION HANDLING, DESTINATION FAULT DESTINATIO OSSDESTALOG CAUSE WRITE FAILURE Problem Data The connection to the remote host lost or write access denied

再分析上面的告警要确认了是因为AP 文件没有写到OSS的权限。综上分析可以确定是对端网管的设置问题，导致ALOG文件无法正常传送。所以联系对端协助处理。

总结：此类问题可以从三方面来分析

1、本地设置和定义的参数。

2、网络是否畅通。

3、对端的参数设置问题。

3．故障：APG40中CLUSTER 无法正常启动的问题

分析：APG40中经常出现AP1边的CLUSTER服务无法正常加载启动的问题，一般是当管理员改过普通用户的帐号或者密码时，或者系统升级的遗留问题时会出现。因为启动CLUSTER需要帐号密码的认证。

处理：在AP 模式下，用指令CLUSTER RES 查看具体服务ONLINE /OFFLINE的情况。一般情况下，可以用指令cluster res /on /wait 将某些服务人工ONLINE上；如果告警中涉及到磁盘阵列的问题还要用两条非常有用的指令raidutil-L all 和raidutil-L logical/physical查看逻辑磁盘和物理磁盘的状态。

如果整个CLUSTER无法加载,则查看ACTIVE或是PASSIVE边NODE 的状态就为UNDEFINED。在控制面板中的服务，找到CLUSTER查看属性，把MANUAL改为AUTO加载，然后在ACCOUNT项中改为正确的帐号和密码，然后PRCBOOT后，CLUSTER可以正常启动，解决故障。

4． 故障：告警AP SYSTEM ANALYSIS

详细描述：A2/APZ “GZMMSC63/JB/0/0” 804 041127 0011 AP SYSTEM ANALYSIS AP APNAME NODE NODENAME 1 GZG13MAP1C A GZG13MAP1A OBJECT

COUNTER

INSTANCE

LIMIT VALUE LogicalDisk % Free Space

C:

<16 15.955

分析:这是一个由于磁盘空间不够引起的告警，此时我们通过LOCAL IP PORT/PCANYWHERE进入AP1 NODE A 查看C盘的属性，发现C盘的剩余空间小于16%。处理办法：C盘空间不足时可删除的文件

1、C:acsdataFtpmktrbuild 该目录存储的是爱立信TR需要的logfile，可以完全删除（一般可在提交给爱立信后即刻删除）。

2、C:Temp 该目录存储的是windows NT系统的临时文件，可以完全删除。

3、C:WINNTsystem32logfilesMSFTPSVC1 C:WINNTsystem32logfilesMSFTPSVC2 C:WINNTsystem32logfilesMSFTPSVC3 该目录存储的是windows NT系统记录的用户登录信息、安全事件信息等

logfiles，可删除较旧的文件，建议至少保留一周之内的文件，如实在空间不足，也可全部删除。

4、C:acslogsfch 该目录下如果有扩展名为.old的文件，形似：acs_fch_activity.old，为系统自动保留的旧版本文件，可删除该.old文件。C:acslogsprc 该目录下如果有扩展名为.old的文件，形似：ACS_PRC_error.old，为系统自动保留的旧版本文件，可删除该.old文件。C:acslogsusa 该目录下如果有扩展名为.old的文件，形似：usa.tmp.old，为系统自动保留的旧版本文件，可删除该.old文件。C:acslogscore 该目录下如果有扩展名为.unknown.x（其中x为一阿拉伯数字）的文件，形似：core.unknown.x，可删除该文件。

5、清空C盘回收站

通过以上方法一般可以消除该告警,如果不能消除的话,在确定C盘空间大于16%情况下,可以用指令ACEASE-O ID号消除.5． 故障：告警AP ANTIVIRUS FUNCTION FAULT 详细描述:Alarm Identifier

Class

Category

Time 8796:0

A2

APZ

Sun Nov 21 07:17:42 2004

Object of Reference LOGFILE/APPLICATION-VIRUS

Alarm Text AP ANTIVIRUS FUNCTION FAULT SIGNATURE FILE DOWNLOAD FAILED

Problem Data

Sun Nov 21 07:17:41 2004 3004 GZG33MAP2A 2 264 InoculateIT EVENTLOG_WARNING_TYPE 07:16:11 11/21/04 176 gzg33map2a 07:17:41 11/21/04 The automatic download has run 4 times unsuccessfully.The next attempt will occur at the regularly scheduled download time.解决方法:在ap1设置eTrust软件,记住沟选Redistribution Server选项, 然后APG2（计费专用）就可以通过“Redistribution Server”的方式从APG1更新病毒库。

6． 故障：AP LOG STATISTICS

详细描述:Alarm Identifier

Class

Category

Time 8799:0

A2

APZ

Mon Nov 29 08:53:45 2004

Object of Reference LOGFILE/SECURITY-LOGON

Alarm Text AP LOG STATISTICS SECURITY VIOLATION ATTEMPT

Problem Data

Mon Nov 29 08:53:45 2004 29697 GZG33MAP1A 644 196 Security EVENTLOG_AUDIT_SUCCESS GZ9912 GZG33MAP1A S-1-5-21-1586019725-754599781-3438223002-1051 SYSTEM NT AUTHORITY(0x

0,0x3E7)-

解决方法:因为多次登陆输入帐号密码错误而导致,用acease消除即可.7、故障：AP PROCESS REINITIATED 详细描述: AP PROCESS REINITIATED AP

APNAME

NODE

NODENAME 1

ZCCBSC1AP1C

B

ZCCBSC1AP1B 分析：这是进程重新启动引起的。

解决办法：当进程起来后，此类故障都可以用APLOC进入AP模式，然后直接用ACEASE

ID消除。

8、故障：AP FAULT

详细描述: AP FAULT AP

APNAME

NODE

NODENAME 1

ZCZ40AP1C

B

ZCZ40AP1B PROBLEM GENERAL ERROR&AP-AP ETHERNET LINK&MIRRORED DISKS NOT REDUNDANT 分析：此类故障是由于APG40 DOWN掉后而引发的一系列告警。

解决办法：当APG40 PRBOOT 或RESET时启会出现此类的告警，当重启成功后（大概五分钟）故障会自动消除。如果没有自动消除可以用APLOC进入AP模式，然后直接用ACEASE

ID消除。

9、故障：AP PROCESS STOPPED

详细描述：AP PROCESS STOPPED AP

APNAME

NODE

NODENAME 1

ZCCBSC1AP1C

B

ZCCBSC1AP1B 分析：此类故障是由于这是进程吊死引起的。

解决办法：此类故障都可以用APLOC进入AP模式，然后用ACEASE

ID消除

10、故障：OSS无法收集到告警 分析：此故障是由于AD-X吊死引起，解决办法：可以在APG40 ACTIVE NODE 做PRCBOOT后，OSS能正常联机

11、故障：DIRECT FILE OUTPUT FAULT 详细描述：

DIRECT FILE OUTPUT FAULT AP

APNAME

NODE

NODENAME 1

ZCCMSCAP1C

A

ZCCMSCAP1A CAUSE BLOCK TRANSFER FAILED FILENAME RCEFILE1

分析：此故障是文件传送失败引起。

解决办法：当确定目的地没有任何故障后，进入“AP LOCAL MODE”下用指令“AFPFTI –F TRANSFERQUEUE”，告警便可以消除。

12、故障：EXTERNAL ALARM RECEIVER FAULT 详细描述：

A2/APZ “ZCDMSCCN63/JB/A” 624 040802

0347

EXTERNAL ALARM RECEIVER FAULT AP

APNAME

NODE

NODENAME 1

ZCZ40AP1C

A

ZCZ40AP1A APNODE

FCODE B

FAULT CODE 23 分析：由于APG40断电后产生的告警，当APG40上电后故障消除。

13、故障：AP REBOOT

详细描述： AP REBOOT AP

APNAME

NODE

NODENAME 1

ZCCMSCAP1C

B

ZCCMSCAP1B 分析：此类故障是由于APG40重启（自动或人工）引起。

解决办法：此类故障都可以用APLOC进入AP模式，然后用ACEASE

ID消除。

14、故障：CONNECTION SUPERVISION, AP CDH, CONNECTION TO REMOTE SYSTEM LOST

详细描述：

CONNECTION SUPERVISION, AP CDH, CONNECTION TO REMOTE SYSTEM LOST AP

APNAME

NODE

NODENAME

ZCCMSCAP1C

A

ZCCMSCAP1A DESTINATION BGWRPCMC 分析：这是由于远端设备端口问题引起，此故障会自动恢复

第三篇：典型故障案例通报(第十四期)

典型故障案例通报（第十四期）

一、2015年7月28日汉丹线襄阳东站至汉丹线路所间3107G、3117G轨道电路红光带故障通报

（一）故障概况

7月28日20时10分，汉丹线襄阳东站至汉丹线路所间3107G、3117G轨道电路红光带。经电务部门处理，22时07分设备恢复正常，影响货车1列。

（二）故障原因

因地方人员擅自在电缆径路附近进行取土作业，挖断信号电缆，造成3107G、3117G红光带故障。

（三）故障定性定责 公安机关侦破后认定追责。

（四）教训及措施

1.襄阳电务段对工程开通后可能存在的安全隐患预想不足。此次电缆中断地点在铁路防护网外，襄阳电务段仅在电缆径路上按要求设臵电缆标桩，未充分考虑地方上可能存在取土、挖沟等危及信号电缆安全的作业，未在防护网外的电缆径路上设臵信号电缆安全警示牌。

2.电缆故障应急处臵预案还需优化。部分司机对电缆中断处所的道路交通线路不熟悉，工区职工对电缆应急接续操作不熟练。

3.要求襄阳电务段在全段范围内排查防护网外电缆敷设情况，对网外电缆径路加设电缆安全防护警示牌。同时利用徒步检查、添乘检查等方式，加大电缆径路的巡查力度，发现危及信号设备安全的情况及时果断处臵。

4.优化应急预案。特别是城乡结合部道路交通图的绘制要更加 1 精确，尽量减少故障处理的在途时间。同时要经常性的组织开展电缆中断应急演练，提高干部职工应急处臵水平。

二、2015年7月28日京广高铁 郑武中继18列控中心设备故障通报

（一）事故概况

7月28日，G70次运行至信阳电务段管内孝感北至信阳东站间（中继18）上行线K1039+068处，因ATP行车许可突降为零，触发紧急制动停车，后自动恢复正常，17时43分发生，17时46分自动恢复，延时3分钟，影响动车3列。

（二）事故原因

列控中心设备TM-425板通信故障造成。

（三）事故定性定责

设备器材不良，定北京和利时公司责任。

（四）教训及措施

1.要求北京和利时公司进一步分析设备故障原因，采取有效措施，防止同类问题再发生。

2.信阳电务段加强对列控中心设备等新技术的业务培训，熟练判断处理设备故障。

三、2015年7月28日汉丹线陈家湖站11号道岔故障通报

（一）故障概况

7月28日18时17分,汉丹线陈家湖站11#道岔反位无表示，未影响正线行车，经电务部门处理，21时53分设备恢复正常，影响货车1列。

（二）故障原因

11#-X1（ZYJ7型液压转辙机）柱塞密封圈破损，导致道岔不能转换。

（三）故障定性定责

设备器材不良，定北京铁路局太原电务器材厂责任。

（四）教训及措施

1.襄阳电务段风险研判不足。因柱塞密封圈材质不良的故障在外局发生过，但襄阳电务段未吸取故障教训，对此项安全风险的危害性认识不足，仅安排了部分道岔柱塞密封圈的抽查，未进行全面排查整治。

2.襄阳电务段组织对全部ZYJ7液压转辙机柱塞密封圈进行检查、更换，联系生产厂家对ZYJ7液压转辙机柱塞密封圈进行产品召回处理，杜绝此类故障的再次发生。

四、2015年7月28日焦柳线郜营站17/19号道岔故障

及机车信号显示突变故障通报

（一）故障概况

7月28日19时32分，焦柳线郜营站17/19号道岔在列车通过时定位断表示，造成通过列车机车信号由绿灯突变为双黄灯，列车停车后于19时37分正常发车，经电务部门处理，于20时05分恢复正常，影响客车1列。

（二）故障原因

1.19号道岔B动压力大，列车经过时变形，顶起移位接触器接点，切断道岔表示电路。

2.列车压入19DG（19号道岔所在区段）后，由于19号道岔断表示，17/19DBJ落下，切断SIIF-ZFS绿码编码电路，接通双黄码编码电路，导致机车信号由绿灯突变为双黄灯，而司机看到前方地面 4768通过信号机显示绿灯，故采取停车措施。列车进入4768G（S1LQG）后，正常接收到4768G发送的绿码，停车后开车。

（三）故障定性定责

维修不良，定襄阳电务段责任故障。

（四）教训及措施

1.道岔适应性调整工作落实存在差距，车间、工区对道岔特性掌握不足，导致适应性调整工作缺乏针对性。

2.车间干部对工区指导不够。工区在道岔整治方面经验积累不足，反映出段、车间相关干部没有给予足够的关注和指导。

五、2015年7月28日沪蓉线枝江北站10/12号道岔故障通报

（一）故障概况

7月28日19时53分，枝江北站10/12#道岔定反位无表示，经电务人员抢修于20时50分恢复，影响客车10列。

（二）故障原因

故障原因为10#-J1电机内油泵组故障，造成转辙机不动作。

（三）故障定性定责

设备器材不良，定北京铁路局太原电务器材厂责任。

（四）教训及措施

1.电务段7月30日会同太原电务器材厂分解电机进行原因分析。2.电务段举一反三，加强对电机内部的检查，避免类似问题再次发生。

六、2015年7月29日沪蓉线利川站10号道岔故障通报

（一）故障概况

7月29日11时39分，利川站10#道岔定反位无表示，经电务人 4 员抢修于12时23分恢复，影响客车3列。

（二）故障原因

故障原因为10#道岔J1与J2液压转辙机连接油管的冷压接头处漏油，导致道岔失去转换动力。

（三）故障定性定责

设备器材不良，定北京铁路局太原电务器材厂责任。

（四）教训及措施

1.襄阳电务段会同太原电务器材厂对冷压接头质量进行认真分析，提出整改措施。

2.襄阳电务段举一反三，根据季节变化加强对液压转辙机油管路检查，油管保护管包扎时开口朝外，便于日常巡视时检查，避免类似问题再次发生。

七、2015年8月1日丹水池联络线丹水池站

电码化故障通报

（一）故障概况

8月1日17时48分,丹水池联络线D296/7次运行至丹水池站XS进站信号机内方后，司机反映收不到码，17时54分，列车调度员发布命令改按LKJ行车，后续D3256/7次仍然反映收不到码,发布命令改按LKJ行车，经电务部门处理，于19时40分恢复，影响客车9列。

（二）故障原因

丹水池站机械室7排2架8层组合架侧面04-17#万可端子配线松脱，造成电码化发送通道断开。

（三）故障定性定责

维修不良，定武汉电务段责任。

（四）教训及措施 1.滠口车间机械室设备巡视检查不到位，未能及时发现配线松动的隐患并加以处臵，导致发生设备故障。

2.滠口车间应急处臵不到位，造成延时过长。现场应急人员对站内电码化电路不熟悉，故障发生后一直以为故障点在3DG，未能及时判明故障范围和原因。

3.滠口车间组织人员利用天窗点对丹水池站机械室组合架配线进行全面排查，发现问题及时处理，防止类似故障再次发生。

4.滠口车间由干部带队，对站内电码化电压、电流等数据进行统一测试，制作成参考数据在分线盘等主要位臵进行标识，便于日常维护和故障处理。

电务处

二〇一五年八月三日

第四篇：爱立信基站典型故障处理案例[定稿]

爱立信基站典型故障处理案例

案例1：对基站进行IDB的配置总是无法完成，提示为时间超时。当对基站进行IDB数据的配置时，因为TRU与DXU软件版本不一致，或BSC下载软件的同时进行DXU数据配置而产生冲突，或第一次IDB配置电源电压类型错误，或短时间内频繁的对DXU进行IDB配置等原因，偶尔可能导致再进行IDB的数据配置时，出现提示为时间超时而无法完成的现象。导致DXU同机架内部的通信上存在异常现象，出现类似机架掉死的现象，更换DXU无效。

解决的办法是，将DXU（或新的DXU）放到同基站的其它机架上，或另外的基站上，仅对DXU加电，按照存在问题的机架配置进行IDB的重新配置，完成后再安装到存在问题的机架上，不必再重新配置，对DXU等各模块加电重起，即可解决问题。

案例2：RBS200基站工作不稳定，经常退服。基站各部件的稳定工作离不开稳定的时钟信号，而基站的时钟信号是从PCM传输中提取的，爱立信的基站不提供外部时钟输入的端口, RBS200基站是爱立信早期推出的GSM基站产品，这些基站设备是基于采用传统的PDH传输组网方式而设计的，并不非常适用于SDH传输组网方式，这就会导致RBS200基站在和某些厂家的SDH传输设备配合使用时，导致基站工作不稳定，频繁出现时钟同步的告警，经常退服，严重影响了基站的正常运行。

解决办法有两种：一种是将RBS200基站使用的SDH传输更换为PDH传输；另一种是将RBS200基站设备更换为RBS2000基站设备，因为RBS2000对同步要求较RBS200低，能够很好同SDH传输配合工作。

案例3：开始时，马厂湖基站有部分TS总是无法正常工作，且不固定在某个载频上，更换TRU、DXU无效，对基站的数据进行拆掉重新加载后仍无效，后来整个基站所有的TS均无法正常工作，基站硬件、传输、数据等均不存在问题。点检查了基站的所有硬件均不存在故障现象，对怀疑有问题的TRU、DXU进行了更换；对传输进行了环路测量，也未发现传输电路存在质量问题；检查小区、基站的定义数据也都正常。怀疑基站的数据存在掉死的现象，但没有确凿的证据。尝试用另外一种方法进行故障的定位。从BSC的ETC传输接口处，即ETRBLT板子2M接口处将马厂湖基站的传输DIP=97同另外一个类似配置的基站装载机厂的传输DIP=98直接进行互换，也就是说互相用对方基站的数据来开通基站。互换后发现，马厂湖基站的数据在装载机厂基站上仍然存在同样的问题，而装载机厂基站的数据在马厂湖基站上却能正常工作。这就可以说明，马厂湖基站的硬件、传输均不存在问题，基站数据确实存在掉死的现象。

在确认马厂湖基站的数据存在掉死的情况后，重新定义了新的TG数据，来替换原先存在掉死现象的TG数据，整个基站恢复正常运行。

对上述基站数据掉死的解决办法还有一种是进行BSC的重新启动，因为需要在晚上进行，因此可能会导致基站退服的时间较长。

案例4：中国银行基站第2小区对应的机架为2个CDU C，4个载频配置，总是在4个载频全部开起来后，又很快全部退服，现象为第1、2个TRU状态为TX not enabled，第3、4个TRU为Fault灯和Operational灯同时亮。每次对DXU进行复位，总是出现上述的同样现象，整个小区无法正常运行。

因为第3、4个TRU总是出现故障现象，将这两个TRU更换，仍然出现同样的故障现象；更换第3、4个TRU对应的第2个CDU C，仍然出现同样的故障现象。将第3、4个TRU放到第5、6个TRU的位置上，将第2个CDU放到第3个CDU的位置，这样载频的位置为第1、2、5、6，甩开TRU第3、4位置不使用，整个小区正常运行，不再出现上述故障现象。

根据以上处理过程进行分析，应该是第2个CDU C对应的CDU BUS总线或第3、4个TRU对应的背板存在问题，导致第2个CDU C不能正常工作，不仅导致第3、4个TRU不能正常工作，而且导致整个小区不能正常工作。

将第2个CDU C对应的CDU BUS总线拆下来，更换一新的CDU BUS总线后，故障解决，确认是第2个CDU C对应的CDU BUS总线存在问题。下图是CDU BUS的连接示意图：

还有一种解决办法，就是将CDU C更换为CDU C+，并且使用Y cable，按照如下图连接：

这样就可以不再使用第2个CDU C对应的有问题的CDU BUS总线，就不会出现整个小区开不起来的现象。

案例5：沂水城东基站A小区扩容一个机架，由6载频扩容为8载频。在打开跳频的情况下，A小区所有8个载频的时隙全部正常工作后很快陆续全部退服，同时出现1A级的XBus Fault告警，但告警很快又消失。对基站A小区复位或闭解CF，仍然是同样的故障现象。将A小区的跳频关掉后可以正常运行。

针对出现的XBus Fault告警，重点检查了新增扩的机架TRU和DXU背板跳点设置，CDU BUS的连接情况，均未发现异常，更换DXU也不能解决问题。考虑到当时是在上午忙时，此小区承担的话务量很高，有可能是因为A小区重起时接入用户太多导致负荷过高而不能以跳频方式正常运行，设置A小区参数CB=YES禁止待机时手机接入，设置A小区为Layer=3小区限制其它小区手机用户向A小区切换，这样的参数设置曾经解决过类似大容量小区在打开跳频的情况下忙时重起困难的问题，但仍不能解决沂水城东A小区的问题。

怀疑新增扩的2个TRU虽然状态显示正常，但仍然可能存在问题，导致XBbus工作异常。由于A小区的主架的6个TRU和副架的2个TRU间已多次互相倒换位置来排除TRU的问题，已经不能分清哪2个TRU是新增扩的。于是将A小区的所有8个载频全部替换，问题解决。总结：某个存在故障的TRU可以导致其背板连接的总线工作异常，在这个案例中，导致了XBus工作异常，小区不能打开跳频，但是此TRU的状态显示完全正常。解决办法是替换怀疑有问题的TRU，尤其是新增扩的TRU，不要采取在有问题的小区内互相倒换的方式，因为存在故障的TRU无论在那个位置均可以导致同样的故障现象。应该用其它小区或新带来得TRU替换。

还有一个例子也是存在故障的TRU导致其背板连接的总线工作异常的情况：某小区新扩一个机架，载频由6个扩容到7个，但是每次启站时总是很快出现驻波比过高的基站告警，所有载频全部退服，故障原因是新扩的TRU（在新扩的副架上）存在问题，虽然表面状态均很正常，但是把它插到机框内加电后，就会干扰背板总线的正常工作，导致出现整个小区驻波比过高的问题产生。

案例6：付庄基站为3个RBS2202机架级联、4/4/4配置，故障现象为B小区退服，复位后B小区恢复正常，但几小时后又再次退服，基站不存在任何告警。如此反复，B小区工作状态很不稳定。

因为是在基站运行中出现的故障，所以首先怀疑是B小区DXU出现故障，但是更换后仍无法解决。检查B小区的射频电缆、PCM传输电缆、CDU总线均无异常。通过OMT软件监测付庄基站3个机架DXU的PCM连接状态均正常。考虑到B小区是级联A小区的，即PCM传输电缆从A小区DXU的G.703-2端口连接到B小区DXU的G.703-1端口，这段传输通路是否存在问题？更换这段通路上的所有传输电缆，仍不能解决问题。再向前考虑一步，是不是A小区DXU的G.703-2端口存在问题，虽然没有故障状态显示？更换A小区的DXU，重新配置IDB数据后，问题解决。

总结：针对多机架级联的基站，第2、3小区退服的情况，要考虑前一级级联的小区所在的机架是否存在DXU故障、PCM传输电缆接错、IDB数据中未定义PCM级联等情况。

案例7：某个基站第2小区有3个时隙LMO状态为0800，复位和更换载频后无效。

检查基站的定义数据，发现第2小区对应的TG-139，在定义半永久连接关系时，将RBLT-1309与DCP 28连接是错误的，导致DCP 28相对应的4个TS时隙，无法正常工作。应该是RBLT-1308与DCP 28连接，正确修改后，故障解除。类似的故障现象可能还有如下的故障原因：（1）某个基站第2小区4个时隙LMO状态为0800复位和更换载频无效：用DTIDP指令检查DIP的定义数据，发现MODE=1是错误的。RBS200基站的DIP定义为MODE=1，即传输的第16时隙仅用于传信令，不用于传话音。而此基站为RBS2000基站，正确的定义是MODE=0，如果定义为MODE=1，会导致DCP 16，即传输的第16时隙不能正常使用，出现上述的故障现象，或者导致用户占用时出现单通现象。

（2）某个基站第3小区2个时隙LMO状态为0800，复位无效： 第3小区的2个时隙的故障原因是在定义基站数据时，MO CF的参数SIG=UNCONC错误，因为所有的TRX的SIG=CONC，导致TG分配的DCP不够用。将MO CF的参数该为SIG=CONC，故障消除。

案例8：某个新建基站传输状态正常，硬件也不存在问题，但基站开不起来 基站数据定义看起来不存在问题，其它检查也做了很多，但基站仍然不能开起来。重点检查基站DIP所连接的SNT的DEVICE数据定义，会发现RBLT的状态不对，为MBL闭掉的状态，试图解闭，可能还会发现未完全定义，再用EXDAI、EXDUI指令进行补充定义，解闭此SNT所带的RBLT，再重新LOAD基站数据后问题解决。对新建基站开不起来的情况，还有BSC侧MO=RXOCF的TEI值与基站OMT软件定义的不一致，导致基站无法同BSC建立联系。此种情况较多的出现在级联基站上，重新定义，使基站的TEI值同BSC侧定义的TEI值一致便可解决问题。

案例9：盲校基站存在瞬断现象，导致信道完好率虽然很接近但达不到100%，同时基站传输设备也出现传输瞬断的现象。

检查基站硬件设备，及传输设备均未发现异常，更换DXU也无法解决问题。在基站上进行故障处理时，发现老式的爱立信开关电源存在模块损坏的情况，但仍能正常工作。经过长时间现场观察，发现交流电压不稳定，忽高忽低，当电压过高时，开关电源的过压保护器便跳脱保护，爱立信开关电源所有的模块处在过压保护的状态，同时传输设备瞬间复位，导致基站瞬断。此时就发现了交流电压过高可能是导致盲校基站瞬断的原因。经过分析，老式的爱立信开关电源对交流电电压波动范围的适应性较差，当电压过高超出其限定值时，开关电源的所有模块出现瞬间的保护而导致其直流输出电压异常，从而导致传输设备因直流供电不能满足要求而瞬间复位，导致爱立信基站瞬间退服。

将老式的爱立信开关电源更换为能适应宽范围交流电压波动的新式开关电源，问题解决，盲校基站再也未出现瞬断的现象。这样的情况也存在于其它部分型号的、对交流电压波动适应性差的老式开关电源上。

案例10：柳行头基站为九期新建全向2载频基站，传输环路状态正常，不存在滑码、误码等传输质量差的情况，基站硬件状态正常，不存在任何告警，但将传输头子接到DXU的G.703-1接口后，BSC侧传输状态显示WO正常状态，但是DXU黑灯，所有的指示灯均不亮。从BSC侧观察是CF无法Load成功，导致此基站开不起来。

首先全面检查基站硬件、传输设备、传输电缆等均没有发现问题，检查柳行头基站数据、小区数据定义也没有发现问题，更换DXU也不能解决问题。

从BSC的ETC传输接口处将柳行头基站的传输同另外一个相同配置且正在运行的松峰基站传输互换，不必改动任何数据，也就是说互相用对方基站的数据来开通。柳行头基站的数据在松峰基站上运行正常，而松峰基站的数据却无法在柳行头基站上运行，这就可以说明柳行头基站的数据不存在错误、掉死等异常情况，而从BSC到柳行头基站的传输通路上存在问题，也可能是基站硬件存在问题（这已排除）。

这样重点怀疑从BSC到柳行头基站的传输通路上存在问题，需要仔细检查，传输维护人员从BSC往基站方向一段一段进行检查，果然发现在北园传输机房处柳行头基站的传输跳线存在问题，120欧姆4根信号传输线中的一根与配线端子处在似接触非接触的状态，重新卡接后，柳行头基站CF软件load成功，基站顺利开通，问题解决。

需要注意的是，基站电路环路时是通的，并不能代表基站电路完全不存在问题，因为还存在类似上述传输信号线接触不好、远端告警等一些特殊的传输故障现象。

案例11：邮政局基站C小区扩容到主、副架共12个载频，但是最多只能开起来10个载频，总有2个载频无论如何也开不起来，并且这2个开不起来的载频位置不固定，状态表现为仅Tx not enable灯亮。基站不存在告警。更换相应的载频无效。仔细观察开不起来的2个载频的故障现象，发现总是某一个CU上的2个载频同时出现开不起来的现象，虽然这个CU也不是固定的。将12个载频中的某两个位于同一个CU上的载频TRX闭掉，其它10个载频均能正常工作。

根据以上现象，考虑到爱立信基站载频相互间发射部分TX和接收部分RX存在“借用现象”，即载频A的RX（可能载频A的TX存在问题）和载频B的TX可以组成一个完整的正常工作的“载频”，而载频A的状态可能为正常运行状态，而载频B的状态为仅Tx not enable灯亮。

进一步从BSC上观察邮政局基站C小区各MO的工作状态，发现最后2个载频的TX-11&&-12工作状态开始时总是NOOP，过一段时间之后状态变为FAIL，但是考虑到最后2个载频的TX发射部分可以借用另外2个载频的TX发射部分，即存在TX的“借用现象”，因此状态仍有可能是正常运行的。导致TX状态为FAIL的原因有发射通路上的CDU存在问题，连接的天线驻波比过大，TX定义的连接小区错误，TRU的发射部分存在故障等原因。经过排查，重点怀疑是最后2个载频，即TRX-11&&-12对应连接的CU存在问题，虽然此CU的运行状态正常，无故障灯指示。更换此CU后，邮政局C小区的12个载频全部开起来，问题解决。这种类型的故障处理，不要被基站各硬件的运行状态显示所迷惑，可能状态是正常的，但是也有可能存在问题，就像上面所讲的CU的故障现象。

案例12：TX无法正常工作，基站告警为CDU output power limits exceeds 九期工程中，在开通西梁王基站（S2，2，2）时，发现虽然基站本测过程中,各MO 状态正常,均无告警，但是在开站时,当TX打开后, B小区CDU的Fault 红灯亮,，小区不能工作。我们通过OMT查寻告警，监测到SO CF 2A:9 :CDU output power limits exceeds。首先我们怀疑天馈系统有问题,用驻波比测试仪测得DTF值1.08,SWR值1.19,均为正常值。随后更换了CDU及TRU后故障仍未排除。最后我们根据TX的原理,输出功率由前向及反向功率的比较得出的(Reference RBS2202),于是检查对应的Pref,Pfwd馈线,发现标签贴反,导致反向功率总大于前向功率，更改后故障消除。

案例13：基站存在SO CF 2A: Timing bus fault告警，TRU无法工作。建工大厦基站(S6,6,6,)在扩为（S8,6,6）时,A小区扩容的副柜TRU状态不对,TRU的Fault在自检后长亮。此时B,C小区已正常。用B,C小区的机柜带A小区的副柜无问题,从而证明A小区的副柜本身无问题。通过OMT查寻告警，监测到SO CF 2A: Timing bus fault。更换C5 BUS线后故障仍未排除，于是判定故障点应在A小区机柜本身之内。根据OMT读出告警，判断故障为机柜内 BUS问题,更换后状态正常，A小区正常工作。

案例14：PSU的排障方法

下面是满配置的PSU与ECU的光纤连接示意图： 在基站出现同PSU相关的告警后，到基站上观察PSU的状态，可能有如下两种情况：第一种是PSU亮红灯或不亮灯，第二种是PSU面板状态正常但可能存在故障。针对第一种情况，首先检查PSU的-48V直流（PSU-48）或230交流（PSU 230）输入是否正常，可能存在输入开关跳脱或熔丝熔断的情况，如果排除上述情况，那么很可能是亮红灯或不亮灯的PSU存在故障，进行更换确认。对更换后的新PSU，应该先加-48V直流或230交流输入（下面的接头），再连接直流输出接头（上面的接头），否则容易导致新加的PSU因为直流电流倒灌的原因而再次损坏。针对第二种情况，使用逐个排除的方法来找出存在故障但面板显示正常的PSU。满配置的PSU数量一共是4个，与ECU通过光纤串联在一起，形成一个环路。首先甩开左边第1个PSU，将剩下的3个PSU同ECU通过光纤串形连接，再观察基站的PSU相关告警是否消除，如果消除，则说明左边第1个PSU存在故障，进行更换；如果故障仍未消除，可将左边第2个PSU单独甩开，将剩下的3个PSU同ECU通过光纤串形连接，需注意的是从左边第1个PSU直接连接到第3个PSU的光纤需要换成长一点的光纤，再观察基站的PSU相关告警是否消除，以此类推，逐个排查PSU。除了上述方法，类似的，还可采用每个PSU单独同ECU串形连接，再观察基站告警是否消除的方法，逐一进行排查。还有一点需要说明的是，基站对PSU的识别并不是完全根据PSU的安装位置，例如最左边的PSU被识别为PSU-0，向右依次为PSU-

1、PSU-

2、PSU-3，实际上并不是这样的。基站识别PSU是通过光纤环路来识别的，不在这个环上的PSU将不被识别，同时针对这个不在环上的PSU基站也不会产生告警。光纤环路连接最左边的PSU被识别为PSU-0，然后依据光纤环路上的连接，向右依次识别为PSU-

1、PSU-2等，例如PSU-0，它的实际安装位置可能是从最左边数第3个PSU。

有一个故障现象是某个PSU的架顶-48V输入接口因短路损坏严重，不能再使用，并且基站存在相应告警。消除告警的办法是在PSU与ECU的光纤环路中，甩开这个损坏严重的架顶-48V输入接口对应的PSU，再从IDB数据中删除多余的PSU（损坏的接口对应的）即可消除告警。

第五篇：电梯典型故障分析及处理方案

电梯典型故障分析及处理方案

摘要：当今社会发展迅速，高层建筑早已走上时代舞台，而高层建筑离不开电梯的使用，为了确保电梯的安全、有效运行，完善高层建筑功能，本文总结分析了时下一些典型电梯故障，并选出其中若干案例，提出了相应的处理方案。为有效的电梯监测和高层建筑安全体防护提供一些建议和帮助。关键词：排除故障；电气系统；电梯故障

社会发展日新月异，如今电梯正广泛应用在城市高层建筑当中，便于乘客或货物的垂直运输。由于其本身为运输设备，具有机电一体化的特点，且需要微机监控着它运行的系统，电梯运作往往需要软件和硬件的交叉配合才能起到有效和安全的防护作用。但是，近年来，电梯故障日益增多，电梯出事率正逐渐增加，至此，电梯安全防护问题逐渐受到大家的关注。电梯在运行中所产生的故障主要来自于电气控制系统，本文从此角度着手，就电梯典型故障展开探讨，并提出了相应解决方案。

一、电梯典型故障原因及分析

电气控制、机械、拖动回路等部分组成了电梯，因此，在查找故障时，应主要从以下几个方面考虑。1.电气控制系统故障

通常情况下，乘坐电梯舒适感降低，严重时造成人身伤害或设备事故等电梯无法正常工作的故障原因往往在于电气控制系统，因电气控制系统的内部元件发生异常，产生故障。电梯的主要故障就来自于电气系统故障。而电气系统容易出现的故障包括：①自动关、开门，该故障也是最典型的电气系统故障，因自动关、开电气元件接触不良，就造成无法顺利开、关电梯门的故障。②破坏电气元件绝缘，电梯在长期的运行中，电气系统电子电气元件会在老化、失效、受潮等变化中降低绝缘性能，当击穿绝缘后，电气系统就会发生断路或短路的故障。③接触点处元件发生断路或短路，开关、继电器、接触器等若出现短路和断路现象，失效电路，从而引发电梯故障。当尘埃阻断接触点时，断路的情况就会出现；当电弧烧蚀接触点时或者接触点处电流偏大使，电路短路情况就会发生。2.机械系统故障

我们分别从以下两点来看，第一，连接件松脱。在不间断地、长期运行中，电梯因震动等原因导致松脱、松动紧固件的现象，严重时，还会发生位移、滑脱等机械事故，加大部件之间的消耗、磨损，失去了原来的精度，最终导致电梯故障。第二，自然磨损。磨损是机械部件的运作过程中的必然现象，而一定程度的磨损会导致故障的产生，必须要更换新部件。所以，当大检修电梯时，为了防范于未然，应及时更换容易出现磨损的部件。日常维修电梯时，必须注意保养与调整部分期间，才能确保电梯继续正常、有序的运行。但是，部件磨损情况因滑动、滚动而产生，这就加速磨损机械，电梯故障也就不可避免了。例如：当磨损钢丝绳达到一定程度后，为了防止发生安全事故，就需要及时将其更换。除了钢丝绳，各种运转轴承也必须定期更换，因为这些器件都是容易产生损耗、磨损的。3.主拖动系统故障

通过构成主回路的各环节来检查与排除电梯主拖动系统故障。主拖动系统并非连续的工作状态，所以当经过一段时间的电梯运行后，就会出现电机轴承磨损、接触不良、接点脱落、触电氧化、触电弹片疲劳、击穿或烧断可控硅热和逆变模块等等，因此，可以从检修与排查如上几部分检修与排查主拖动系统故障。4.使用不当

在日常生活中，未按运行要求使用电梯，也会导致电梯故障的频发。例如：有些乘客在电梯内乱扔烟头等废弃物、在按电梯的按钮时过于用力、在按过按钮的基础上又反复按、将易燃易爆的物品携带入电梯、小孩子在电梯上蹦跳等等，都是导致电梯发生故障的人为因素。很多乘客虽然天天利用电梯，但是了解电梯故障的人甚少，而不按照正确的流程和方法操作电梯，缩短了电梯的寿命，甚至危机人身安全。5.未较好保养与维护管理

为了确保电梯在运行过程中的持久、正常运转，安装人员完成电梯安装后，还应定期对电梯进行保养和维护。但是在实际运行中，一些维护人员玩忽职守，使电梯“病入膏肓”，未能尽早处理故障，导致事故的严重发生，这是值得维护、保养工作人员深思的事情。电梯在长期的运行中因为不同的原因产生了故障，如果带“病”运行，后果不堪设想。电梯是机械，机械是需要人工维护的。维护人员不仅工作上要严格，还应具备高度的职业操守及专业技能和知识，这样才能在

电梯产生问题、故障的初期找到故障，及时、正确地处理故障，才能从根本控制电梯运行中的安全隐患。

二、电梯常见故障案例及处理

电梯的故障有很多种，只有经过不断地实践，吸取经验，才能真正掌握电梯故障的排除方法

以下列举部分电梯常见故障案例，并提出了相应快速的解决办法： 1.电梯不能启动，楼层不显示

故障原因分析:电梯失去了正常启动运作的功能，与电气控制系统中的电路功能有关，一般情况下，主控系统电路锁梯功能打开、电源同路中出现电源故障、安全以及制动同路中有短路情祝都可导致电梯不能正常启动运行。

首先，对锁梯开关位置进行检查，若电梯进入锁梯状态，则恢复锁梯开关电梯运行即可恢复。

其次，要对控制柜内的电源电路模块进行检查，观察各设备是否正常运作，检测供电压是否正常，排查故障点，进行维修。若一切正常，需对锁梯功能和安全同路进行验证。

第三，对安全制动同路进行检查，控制柜内安全接触器是否吸合、安全同路反馈信号是否正常等，找到故障点，给予修复。

2.电梯运行正常，但平层时误差过大

故障原因分析:通过对电梯机械故障的原因及现象进行分析，一般来讲，平层装置遮磁板位移、曳引轮绳槽磨损严重都是导致电梯平层精度出现误差的因素。

首先，检查平层装置，若轿厢在多层出现同方向的平层误差，则为平层传感器位移故障，可根据误差尺寸调整平层传感器位置；如果只是某一层平层出现误差，则为遮磁板位移故障，可根据不平层的误差尺寸调整遮磁板位置。

然后对曳引轮绳槽磨损情况进行检查，如果在电梯运行时曳引轮与钢兹绳存在相对运动，则应立即更换曳引轮。

三、讨论

建筑行业在我国的兴起速度是非常快的，其使用率也在不断增加，以至于电梯故障的发生也日益增多。电梯故障日益增多，电梯出事率正逐渐增加。总体来

说，排除电梯故障的原则由简至难、从内到外，具体如下：①环节排除法，电梯在正常运行的过程中包括了停止再开门、减速运行、开门启动、层数选择等过程，一旦电梯出现故障，可对上述哪一环节出现的问题进行有限考虑，为确定发生故障的详细位置，对故障电梯逐层进行检查。②测量法，为确定电压是否正常、检查电流回路中显露的连接状况是否良好，当将产生电梯故障的位置大致确定后，回路的检测可利用万用表，如果检测结果出现异常，应开展详细的排查。③互换法，先替换存在故障的部位，替换后，如果故障部位恢复正常工作状态，则故障产生于此处，但是替换后并未恢复，则可以判断该部位未出现问题。本文针对电梯中出现的典型问题、故障，收集和归纳了快速处理的措施和方法，对提高维修速度以及安全运行水平，防止事故的多发，具有一定的参考价值。

参考文献：

[1] 王文, 钱江.电梯悬挂系统在建筑摇晃引起位移激励下横向振动分析[J].振动与冲击, 2013, 32(7): 70-73.[2] 吴从晓, 周云, 吴从永, 等.高位层间隔震结构电梯井核心筒剪力墙处理方法研究[J].振动与冲击, 2011, 30(10): 77-81.[3] 宗群, 赵占山, 商安娜.基于季节自回归单整移动平均模型的电梯交通流递归预测方法[J].天津大学学报, 2008, 41(6): 653-659.[4] 杨琴, 袁玲玲, 梁红艳, 等.基于改进粒子群算法的电梯优化调度研究[J].工业工程, 2013, 16(2).