APG典型故障处理小结

第一篇：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

<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

第二篇：APG40故障处理小结

Page １ of 9

APG40故障处理小结

从维护APG40以来，对APG40故障做了大概的统计，从统计结果看出有以下这些APG故障，下面我将对这些故障进行大概的分析及给出解决的方法：  AP LOG STATISTICS 引起故障的原因：

1、AP VIRUS：APG感染病毒。

处理方法：人工DOWNLOAD更新病毒库后扫描清除病毒（如果是AP2的话，将AP2的ETRUST设置为从AP1更新病毒库），成功后用指令ACEASE手工删除告警。

2、LOGFILE/SECURITY LOGON：多次登陆AP错误告警。

处理方法：因为多次登陆输入帐号密码错误而导致,用acease消除即可.（如因帐户过期引起多次登陆输入帐号密码错误，那应通知交换室对该帐户重新定义帐户、密码，才能真正解决该故障。） AP SYSTEM ANALYSIS 引起故障的原因：

1、The object is LogicalDisk and the counter is % Free Space：硬盘空闲空间低过门限值。

处理方法：检查引起该故障的硬盘的文件，删除该硬盘的临时文件、较旧的备份文件等，并清空回收站。如删除了这些无关重要的文件后，仍无消除故障，此时可能需扩大硬盘空间（或压缩文件）来消除些故障，可打TR提交爱立信，提供解决方案。* C盘空间不足可删C:TEMP 可删C:TEST 可删C:WINNTSYSTEM32LOGFILESMSFTPSVC1（2、3)（保留一个月的文件）

* K盘空间不足

可删K:IMAGESNODEA(保留最新一个备份文件)可删K:IMAGESNODEB(保留最新一个备份文件)

Page ２ of 9 可删K:ACSLOGSALOGLOGFILE(保留7天的文件)可删K:MCSLOGSPDS（保留7天的文件）

K盘主要文件是的网优统计文件，K盘空间不足多是网优统计文件过多所致。建议出K盘空间不足告警时，先联系网优室删除统计文件。网优统计文件所在位置：K:AESDATACDHFTP

* L盘空间不足可删L:TEMP 可删L:FMSBACKUP 可删L:FMSDATATMP 可删L:FMSDATACPFRELVOLUMSWRELCMDHDF（保留2个月的文件）

2、The object is Security Log and the counter is %Used Space：安全记录占用空间超过门限值。

处理方法：连接PCANYWHERE到APG，检查EVENT LOG文件，删除较旧的EVENT LOG文件，直到告警消除。（如有必要，可将这些EVENT LOG备份后再删除）*Select Start | Programs | Administrative Tools | Event Viewer *In the Event Viewer select the Security log.Select Log | Security *Select Log | Clear All Events.*Select 'Yes' in the message box Clear Event Log.*备份的流程：首先要先把EVENT LOG保存到APG，一般先先保存到C:TEMP目录下，再备份到磁盘。保存到C:TEMP目录的步骤：

1、In the Event Viewer select the Security log.Select Log | Security

2、In the field 'Save in' select where to store the security log file.3、In the field 'File name', enter an appropriate .4、In the field 'Save as type', select an appropriate format.5、Select 'Save'.6、In the message box Clear Event Log select 'Yes'.Page ３ of 9  故障描述：OSS无法收集到告警

故障分析：此故障是由于AD-X吊死引起，故障处理：可以在APG40 ACTIVE NODE 做PRCBOOT后，OSS能正常联机  故障描述：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、用AFPLS –L –S ALOG查看是有ALOG文件传送失败，如有则用AFPFTI –F ALOG将传送失败的ALOG文件重传一次，传送成功故障将会消除。

2、如还是传送失败，则cdhls-l OSSDESTALOG查看此路径的所有传输参数，一切均正确。

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

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

DATA OUTPUT, AP COMMON DESTINATION HANDLING, DESTINATION FAULT DESTINATION

Page ４ of 9 OSSDESTALOG CAUSE WRITE FAILURE Problem Data The connection to the remote host lost or write access denied 再分析上面的告警要确认了是因为AP 文件没有写到OSS的权限。综上分析可以确定是对端网管的设置问题，导致ALOG文件无法正常传送。所以应及时联系对端人员(网管组)协助处理。

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

1、人工重传文件。

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

3、网络是否畅通。

4、对端的参数设置。 AP PROCESS REINITIATED 引起故障的原因：

APG进程出现过重启后会出现此故障

处理方法：用指令CLUSTER RES查看所有进程状态是否”ONLINE”，如果不是则用指令（CLUSTER RES **** /ON /WAIT）将进程”ONLINE”，如进程状态为”ONLINE”，用指令ACEASE消除该告警。 AP FAULT 引起故障的原因：

1、MIRRORED DISKS NOT REDUNDANT：磁盘镜像有问题引起。

处理方法：用指令“RAIDUTIL –L LOGICAL”查看，如果地址为D0B0T0D0的RAID-1的状态为DEGRADED，则用指令“RAIDUTIL –A REBUILD D0B0T0D0”重建RAID-1。等过一段时间后，地址为D0B0T0D0的RAID-1的状态恢复正常OPTIMAL，故障消除。如果用指令“RAIDUTIL –L LOGICAL”查看所有状态均为OPTIMAL，则直接用指令ACEASE消除该告警。

2、GENERAL ERROR：AP故障引起。

处理方法：用指令ALIST查看告警列表，如有其他AP故障，先修复其他故障，然后再用指令ACEASE消除告警。

3、AP-AP LINK ALARM：一般由AP NOT REDUNDANT故障引起。

处理方法：恢复AP NOT REDUNDANT故障（详情看AP NOT REDUNDANT），如

Page ５ of 9 用指令ALIST没列出AP NOT REDUNDANT故障，可用ACEASE消除故障。

4、AP EXTERNAL LINK ALARM：一般由AP PROCESS STOPPED故障引起。处理方法：恢复AP PROCESS STOPPED故障（详情看AP PROCESS STOPPED），如用指令ALIST没列出AP PROCESS STOPPED故障，可用ACEASE消除故障。 AP NOT REDUNDENT：引起故障的原因：

APG其中一个NODE DOWN掉引起。

处理方法：如果APG状态正常，直接指令ACEASE清除告警，如果状态不正常，按OPI流程：AP，System, Repair处理。过往处理经验大概操作：（借鉴）

1、在DOWN掉的NODE先做下一个REBOOT，看能否把NODE UP起来（做REBOOT前需用指令NET ACCOUNTS /SYNC做一下帐号同步）。

2、用指令NET START CLUSSVC重启CLUSTER RES。

3、如执行上两步都无法修复的话，可连上PCANYWHERE，查检各SERVICES的设置（特别是ACS PRC开头的），跟其他正常运作的网元对比，看是否有设置不一样，如有，改正后再做此边的REBOOT。

4、如还不能恢复，可打TR提交爱立信，提供解决方案。 AP PROCESS STOP 引起故障的原因：

进程人工停止或者遇到故障自动停止引起。

处理方法：查看该进程状态是否“ONLINE”，如该进程状态为“ONLINE”，用指令ACEASE消除该告警。如果不是则用指令CLUSTER RES *** /ON /WAIT将该进程“ONLINE”，如不成功，可对此NODE做个REBOOT解决。 IO STORAGE SPACE WARNING 引起故障的原因： IO存储空间不足引起

处理方法：CPDLIST –P查看IO文件存放的目录，用DOS命令DEL删除多余的IO文件。IO文件形如：AD-0_20041102_0005.LOG  AP REBOOT

Page ６ of 9 引起故障的原因： APG重启后的事件告警。

处理方法：检查该AP状态是否为“ACTIVE”, 如不正常，则按AP NOT REDUNDENT流程处理。检查“CLUSTER GROUP”、“CLUSTER RES”是否“ONLINE”，如不正常，用指令将该进程”ONLINE”，如不成功，则按AP PROCESS STOP流程处理。检查APG恢复正常后，需用指令ACEASE消除该告警。 CP AP COMMUNICATION FAULT 引起故障的原因： CP与AP通信中断引起。

处理方法：一般重启APG或做CP SMALL可以恢复。注意：装载补丁、APG重启或CP重启期间会出现该告警。 AP ANTIVIRUS FUNCTION FAULT 引起故障的原因：

AP的NT系统的杀毒软件设定了定期更新病毒库，如果四次请求下载更新病毒库不成功则会出现告警。

处理方法：故障处理:在ap1设置eTrust软件,选Redistribution Server选项,然后APG2（计费专用）就可以通过“Redistribution Server”的方式从APG1更新病毒库。人工DOWNDLOAD流程看附件：

 AP NOT AVAILABLE 引起故障的原因：

此故障通常是进程吊死OFFLINE或NODE DOWN掉起引APG不可用。处理方法：

1、指令CLUSTER RES查看各进程状态，如有进程为OFFLINE，即将进程Bring Online（CLUSTER RES *** /ON /WAIT），如不成功，做该NODE的REBOOT。

2、如还不行，可参照AP NOT REDUNDANT的故障处理。注：具体操作流程按照OPI：AP NOT AVAILABLE处理。

Page ７ of 9  AP SYSTEM CLOCK NOT SYNCHRONIZED 引起故障的原因：

1、Difference between CP and AP time exceeds 600 s-APZ alarm.There was a jump in AP/CP time：由于CP与AP之间的时钟相差600秒引起。处理方法：拔打010117，用指令CACLP核对CP时钟，同是也用AP指令time /T及date /T核对AP的时钟，并对有误差的时钟进行校正。

2、除了第一种原因处，其他原因可提交TR爱立信，提供解决方案。 AP DIAGNOSTIC FAULT 引起故障的原因：AP诊断错误

处理方法：用指令ALIST查看告警列表，看是否列出告警号为8701和告警参考数据为：C:ACSlogsUSAusa.temp.I/O error : Missing parameter，如果是，即删除文件C:ACSlogsUSAusa.temp，并做该AP的REBOOT，如不能解决或其他原因，可提交TR爱立信，提供解决方案。 BILLING，AP DISK，FILES SPACE LIMIT REACHED 引起故障的原因：

计费容量不足，通常当计费文件的大小达到或超过硬盘分配给CHARGING目录大小的80%门限值时，就会出现计费文件空间达到限制值的告警。可能会引起计费文件的丢失。

处理方法：通过减小计费文件在硬盘的保存时间来解决该告警问题，可依照OPI“APG40, Soft Function Change, Parameter,Change”进行对计费参数的修改，由于此操作涉及到计费参数修改，可申请爱立信现场支持。出现此故障，我们可先做以下预处理：

1、检查询问计费中心能否收到此网元的计费文件，如不能，即重启RDT_Server进程（Cluster res Cluster res RDT_Server /off /wait Cluster res RDT_server /on /wait）。

2、将计费文件备份到磁盘，在硬件上删除掉已备份到磁盘并传到计费中心的计费文件。

3、在紧急情况下，也可向交换室申请将计费倒到AP1上。 AUDIT LOG DEACTIVATED

Page ８ of 9 引起故障的原因： Audit Log文件被去活。

处理方法：用alogact指令激活Audit Log。

 BILLING, AP OUTPUT, CONNECTION TO EXTERNAL HOST LO 引起故障的原因：

由于APG网元与省公司计费业务中心的FTP配置不一样所致，双方的接收协议存在区别，但该故障不影响计费文件的产生及接收。

处理方法：修改APG网元SecureDestinationHost的参数或计费中心修改FTP的配置参数。

 FILE NOTIFICATION, AP CDH, ACKNOWLEDGEMENT NOT REC 引起故障的原因：

APG数据输出到外部系统失败，一般都为临时性故障。

处理方法：一般临时故障会自已恢复；用指令cdhver –m destination核验DEST是否正常。

 CONNECTION SUPERVISION, AP CDH, CONNECTION TO REMO 引起故障的原因：同上处理方法：同上

APG在日常维护中遇到的另类问题：

 PCANYWHERE连接到APG后，点击桌面上的图标后没有反应，用显示器和键盘直接连到APG上点击还是一样，爱立信认为有可能是病毒的问题，但最后都未有结论。

处理方法：做一个reboot是可以暂时解决问题。

 在做例行TEST LOAD时，文件LOAD入不成功出IO FAULT 15的结果。

处理方法：在CP模式中用ocsip看到IPNAOS的版本为CXC1060053R2B01，但是在AP模式下看到的版本为CXC1060053R2C，按照OPI流程Inter-Platform Network Software, Change对IPN进行function change后，问题解决。

 曾经出现有些网元APG REBOOT后，有两个进程ACS_PRC_ClusterControl_1，ACS_PRC_EventAnalyser_1的状态为OFFLINE，将这两个进程BRING ONLINE

Page ９ of 9 的时候会引起APG40的循环REBOOT。

处理方法：此问题是Acs_prc_eventanalyser 和 Acs_prc_clustercontrol这个两个进程的参数设置有错误引起，只要修改这两项的设置就可以解决进程不能online的问题。具体是通过pcanywhere连到APG的ap1 passive node，在控制面板－SERVICES里面找到这两项进程，将其设置由原来ATUOMATIC改为Manual，并把ACS_PRC_ eventanalyser的LOG ON AS改为System Account".进行完这两步之后可以在该node重启进程。用同样的方法在ACTIVE Node完成该操作。现在APG的问题可以解决。

以后类似进程不能重启的问题可以先找一个正常的APG系统找到该进程将两者的参数设置比较一下，是否设置错误的问题。 在一边node做reboot后不能恢复的问题。

处理方法：主要是raid磁盘的问题，操作步骤是参照OPI: APG40, Node, Change。

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

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

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

一、传输数据中心在对网络例行检查时发现营业部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）巴东分公司视讯会议系统由技术支持中心维护，不能以没有人处理（下乡）为由。

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

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

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

案例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).

APG典型故障处理小结

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

第二篇：APG40故障处理小结

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

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

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

相关范文推荐

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

燃气轮机运行典型故障分析及其处理

故障处理及典型案例分析讲义..

皮带输送机典型故障的分析及处理

搅拌站人员必备37个搅拌站典型故障问题处理

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

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

水电厂典型故障与事故处理练习题