第一篇：APG典型故障處理小結(jié)
APG典型故障處理小結(jié)
1、故障：intelligent networks management interface
分析：此告警表明文件系統(tǒng)在處理intelligent networks management interface（INM）接口連接時(shí)出錯(cuò)。
此時(shí)有兩種情況：
1、ACTIVE CONNECTION FILE BUFFER表明緩沖區(qū)文件有誤；
2、INM LOG FILE 表明INM的LOG文件處理時(shí)出錯(cuò)，此種情況比較常見，LOG FILE因?yàn)槟承┡既辉虮粍h除后就會(huì)出現(xiàn)這種情況，例如有時(shí)LARGE RESTART或是RELOAD后丟失此子文件。
處理: 用指令ssmpi:sfn=n+1其中SFN:SUBFILE NAME。n為最后一個(gè)INMLOG中的子文件的數(shù)目，出現(xiàn)這種情況。APG40中可以用CPFLS-S指令直接查看INMLOG 中的子文件情況。
2、故障：APG40系統(tǒng)中文件無法傳到OSSDESTx的問題。
分析：多數(shù)此類告警都可以用指令CDHLS-L 查看所有路徑的OSSDESTx的傳輸類型和參數(shù)定義有否正確。大多數(shù)都不會(huì)有參數(shù)丟失的情況，然后用CDHVER 查看告警制定的OSS路徑的狀態(tài)是否OK,否則用指令CDHVER-M 人工修正使?fàn)顟B(tài)變?yōu)檎?，消除告警?/p>
但是有的告警比較特殊例如:
AP FILE PROCESSING FAULT
CAUSE FILE TRANSFER FAILED TRANSFER QUEUE ALOG DESTINATION SET OSSDESTALOG Problem Data Transfer error 分析處理過程：先試著用以上常規(guī)的處理方法即以上指令來設(shè)法消除此告警：
1、用acease無法消除告警
2、cdhls-l OSSDESTALOG查看此路徑的所有傳輸參數(shù)，一切均正確。
3、用cdhver OSSDESTALOG看其狀態(tài)，結(jié)果顯示STATUS OK。
4、于是確認(rèn)了本地交換機(jī)的設(shè)置沒有問題，懷疑是到OSS的網(wǎng)絡(luò)不通 但用指令ping 對(duì)端oss的IP, 顯示網(wǎng)絡(luò)路徑完全正常；后來注意到A3級(jí)的一個(gè)告警，是由于剛才那個(gè)A2級(jí)告警引起的：
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
再分析上面的告警要確認(rèn)了是因?yàn)锳P 文件沒有寫到OSS的權(quán)限。綜上分析可以確定是對(duì)端網(wǎng)管的設(shè)置問題，導(dǎo)致ALOG文件無法正常傳送。所以聯(lián)系對(duì)端協(xié)助處理。
總結(jié)：此類問題可以從三方面來分析
1、本地設(shè)置和定義的參數(shù)。
2、網(wǎng)絡(luò)是否暢通。
3、對(duì)端的參數(shù)設(shè)置問題。
3．故障：APG40中CLUSTER 無法正常啟動(dòng)的問題
分析：APG40中經(jīng)常出現(xiàn)AP1邊的CLUSTER服務(wù)無法正常加載啟動(dòng)的問題，一般是當(dāng)管理員改過普通用戶的帳號(hào)或者密碼時(shí)，或者系統(tǒng)升級(jí)的遺留問題時(shí)會(huì)出現(xiàn)。因?yàn)閱?dòng)CLUSTER需要帳號(hào)密碼的認(rèn)證。
處理：在AP 模式下，用指令CLUSTER RES 查看具體服務(wù)ONLINE /OFFLINE的情況。一般情況下，可以用指令cluster res
如果整個(gè)CLUSTER無法加載,則查看ACTIVE或是PASSIVE邊NODE 的狀態(tài)就為UNDEFINED。在控制面板中的服務(wù)，找到CLUSTER查看屬性，把MANUAL改為AUTO加載，然后在ACCOUNT項(xiàng)中改為正確的帳號(hào)和密碼，然后PRCBOOT后，CLUSTER可以正常啟動(dòng)，解決故障。
4． 故障：告警AP SYSTEM ANALYSIS
詳細(xì)描述：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
分析:這是一個(gè)由于磁盤空間不夠引起的告警，此時(shí)我們通過LOCAL IP PORT/PCANYWHERE進(jìn)入AP1 NODE A 查看C盤的屬性，發(fā)現(xiàn)C盤的剩余空間小于16%。處理辦法：C盤空間不足時(shí)可刪除的文件
1、C:acsdataFtpmktrbuild 該目錄存儲(chǔ)的是愛立信TR需要的logfile，可以完全刪除（一般可在提交給愛立信后即刻刪除）。
2、C:Temp 該目錄存儲(chǔ)的是windows NT系統(tǒng)的臨時(shí)文件，可以完全刪除。
3、C:WINNTsystem32logfilesMSFTPSVC1 C:WINNTsystem32logfilesMSFTPSVC2 C:WINNTsystem32logfilesMSFTPSVC3 該目錄存儲(chǔ)的是windows NT系統(tǒng)記錄的用戶登錄信息、安全事件信息等
logfiles，可刪除較舊的文件，建議至少保留一周之內(nèi)的文件，如實(shí)在空間不足，也可全部刪除。
4、C:acslogsfch 該目錄下如果有擴(kuò)展名為.old的文件，形似：acs_fch_activity.old，為系統(tǒng)自動(dòng)保留的舊版本文件，可刪除該.old文件。C:acslogsprc 該目錄下如果有擴(kuò)展名為.old的文件，形似：ACS_PRC_error.old，為系統(tǒng)自動(dòng)保留的舊版本文件，可刪除該.old文件。C:acslogsusa 該目錄下如果有擴(kuò)展名為.old的文件，形似：usa.tmp.old，為系統(tǒng)自動(dòng)保留的舊版本文件，可刪除該.old文件。C:acslogscore 該目錄下如果有擴(kuò)展名為.unknown.x（其中x為一阿拉伯?dāng)?shù)字）的文件，形似：core.unknown.x，可刪除該文件。
5、清空C盤回收站
通過以上方法一般可以消除該告警,如果不能消除的話,在確定C盤空間大于16%情況下,可以用指令A(yù)CEASE-O ID號(hào)消除.5． 故障：告警AP ANTIVIRUS FUNCTION FAULT 詳細(xì)描述: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設(shè)置eTrust軟件,記住溝選Redistribution Server選項(xiàng), 然后APG2（計(jì)費(fèi)專用）就可以通過“Redistribution Server”的方式從APG1更新病毒庫(kù)。
6． 故障：AP LOG STATISTICS
詳細(xì)描述: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)-
解決方法:因?yàn)槎啻蔚顷戄斎霂ぬ?hào)密碼錯(cuò)誤而導(dǎo)致,用acease消除即可.7、故障：AP PROCESS REINITIATED 詳細(xì)描述: AP PROCESS REINITIATED AP
APNAME
NODE
NODENAME 1
ZCCBSC1AP1C
B
ZCCBSC1AP1B 分析：這是進(jìn)程重新啟動(dòng)引起的。
解決辦法：當(dāng)進(jìn)程起來后，此類故障都可以用APLOC進(jìn)入AP模式，然后直接用ACEASE
ID消除。
8、故障：AP FAULT
詳細(xì)描述: AP FAULT AP
APNAME
NODE
NODENAME 1
ZCZ40AP1C
B
ZCZ40AP1B PROBLEM GENERAL ERROR&AP-AP ETHERNET LINK&MIRRORED DISKS NOT REDUNDANT 分析：此類故障是由于APG40 DOWN掉后而引發(fā)的一系列告警。
解決辦法：當(dāng)APG40 PRBOOT 或RESET時(shí)啟會(huì)出現(xiàn)此類的告警，當(dāng)重啟成功后（大概五分鐘）故障會(huì)自動(dòng)消除。如果沒有自動(dòng)消除可以用APLOC進(jìn)入AP模式，然后直接用ACEASE
ID消除。
9、故障：AP PROCESS STOPPED
詳細(xì)描述：AP PROCESS STOPPED AP
APNAME
NODE
NODENAME 1
ZCCBSC1AP1C
B
ZCCBSC1AP1B 分析：此類故障是由于這是進(jìn)程吊死引起的。
解決辦法：此類故障都可以用APLOC進(jìn)入AP模式，然后用ACEASE
ID消除
10、故障：OSS無法收集到告警 分析：此故障是由于AD-X吊死引起，解決辦法：可以在APG40 ACTIVE NODE 做PRCBOOT后，OSS能正常聯(lián)機(jī)
11、故障：DIRECT FILE OUTPUT FAULT 詳細(xì)描述：
DIRECT FILE OUTPUT FAULT AP
APNAME
NODE
NODENAME 1
ZCCMSCAP1C
A
ZCCMSCAP1A CAUSE BLOCK TRANSFER FAILED FILENAME RCEFILE1
分析：此故障是文件傳送失敗引起。
解決辦法：當(dāng)確定目的地沒有任何故障后，進(jìn)入“AP LOCAL MODE”下用指令“AFPFTI –F TRANSFERQUEUE”，告警便可以消除。
12、故障：EXTERNAL ALARM RECEIVER FAULT 詳細(xì)描述：
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斷電后產(chǎn)生的告警，當(dāng)APG40上電后故障消除。
13、故障：AP REBOOT
詳細(xì)描述： AP REBOOT AP
APNAME
NODE
NODENAME 1
ZCCMSCAP1C
B
ZCCMSCAP1B 分析：此類故障是由于APG40重啟（自動(dòng)或人工）引起。
解決辦法：此類故障都可以用APLOC進(jìn)入AP模式，然后用ACEASE
ID消除。
14、故障：CONNECTION SUPERVISION, AP CDH, CONNECTION TO REMOTE SYSTEM LOST
詳細(xì)描述：
CONNECTION SUPERVISION, AP CDH, CONNECTION TO REMOTE SYSTEM LOST AP
APNAME
NODE
NODENAME
ZCCMSCAP1C
A
ZCCMSCAP1A DESTINATION BGWRPCMC 分析：這是由于遠(yuǎn)端設(shè)備端口問題引起，此故障會(huì)自動(dòng)恢復(fù)
第二篇：APG40故障處理小結(jié)
Page １ of 9
APG40故障處理小結(jié)
從維護(hù)APG40以來，對(duì)APG40故障做了大概的統(tǒng)計(jì)，從統(tǒng)計(jì)結(jié)果看出有以下這些APG故障，下面我將對(duì)這些故障進(jìn)行大概的分析及給出解決的方法： ? AP LOG STATISTICS 引起故障的原因：
1、AP VIRUS：APG感染病毒。
處理方法：人工DOWNLOAD更新病毒庫(kù)后掃描清除病毒（如果是AP2的話，將AP2的ETRUST設(shè)置為從AP1更新病毒庫(kù)），成功后用指令A(yù)CEASE手工刪除告警。
2、LOGFILE/SECURITY LOGON：多次登陸AP錯(cuò)誤告警。
處理方法：因?yàn)槎啻蔚顷戄斎霂ぬ?hào)密碼錯(cuò)誤而導(dǎo)致,用acease消除即可.（如因帳戶過期引起多次登陸輸入帳號(hào)密碼錯(cuò)誤，那應(yīng)通知交換室對(duì)該帳戶重新定義帳戶、密碼，才能真正解決該故障。）? AP SYSTEM ANALYSIS 引起故障的原因：
1、The object is LogicalDisk and the counter is % Free Space：硬盤空閑空間低過門限值。
處理方法：檢查引起該故障的硬盤的文件，刪除該硬盤的臨時(shí)文件、較舊的備份文件等，并清空回收站。如刪除了這些無關(guān)重要的文件后，仍無消除故障，此時(shí)可能需擴(kuò)大硬盤空間（或壓縮文件）來消除些故障，可打TR提交愛立信，提供解決方案。* C盤空間不足 可刪C:TEMP 可刪C:TEST 可刪C:WINNTSYSTEM32LOGFILESMSFTPSVC1（2、3)（保留一個(gè)月的文件）
* K盤空間不足
可刪K:IMAGESNODEA(保留最新一個(gè)備份文件)可刪K:IMAGESNODEB(保留最新一個(gè)備份文件)
Page ２ of 9 可刪K:ACSLOGSALOGLOGFILE(保留7天的文件)可刪K:MCSLOGSPDS（保留7天的文件）
K盤主要文件是的網(wǎng)優(yōu)統(tǒng)計(jì)文件，K盤空間不足多是網(wǎng)優(yōu)統(tǒng)計(jì)文件過多所致。建議出K盤空間不足告警時(shí)，先聯(lián)系網(wǎng)優(yōu)室刪除統(tǒng)計(jì)文件。網(wǎng)優(yōu)統(tǒng)計(jì)文件所在位置：K:AESDATACDHFTP
* L盤空間不足 可刪L:TEMP 可刪L:FMSBACKUP 可刪L:FMSDATATMP 可刪L:FMSDATACPFRELVOLUMSWRELCMDHDF（保留2個(gè)月的文件）
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
故障分析：此故障是由于AD-X吊死引起，故障處理：可以在APG40 ACTIVE NODE 做PRCBOOT后，OSS能正常聯(lián)機(jī) ? 故障描述：APG40系統(tǒng)中文件無法傳到OSSDESTx的問題。
故障分析：多數(shù)此類告警都可以用指令CDHLS-L 查看所有路徑的OSSDESTx的傳輸類型和參數(shù)定義是否正確。大多數(shù)都不會(huì)有參數(shù)丟失的情況，然后用CDHVER 查看告警制定的OSS路徑的狀態(tài)是否OK,否則用指令CDHVER-M 人工修正使?fàn)顟B(tài)變?yōu)檎?，消除告警。但是有的告警比較特殊例如: AP FILE PROCESSING FAULT CAUSE FILE TRANSFER FAILED TRANSFER QUEUE ALOG DESTINATION SET OSSDESTALOG Problem Data Transfer error 故障處理：先嘗試著用以上常規(guī)的處理方法即指令來設(shè)法消除此告警：
1、用AFPLS –L –S ALOG查看是有ALOG文件傳送失敗，如有則用AFPFTI –F ALOG將傳送失敗的ALOG文件重傳一次，傳送成功故障將會(huì)消除。
2、如還是傳送失敗，則cdhls-l OSSDESTALOG查看此路徑的所有傳輸參數(shù)，一切均正確。
3、用cdhver OSSDESTALOG看其狀態(tài)，結(jié)果顯示STATUS OK。
4、于是確認(rèn)了本地交換機(jī)的設(shè)置沒有問題，懷疑是到OSS的網(wǎng)絡(luò)不通 但用指令ping 132.97.19.1來ping 對(duì)端的IP, 顯示網(wǎng)絡(luò)路徑完全正常；后來注意到A3級(jí)的一個(gè)告警，是由于剛才那個(gè)A2級(jí)告警引起的：
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 再分析上面的告警要確認(rèn)了是因?yàn)锳P 文件沒有寫到OSS的權(quán)限。綜上分析可以確定是對(duì)端網(wǎng)管的設(shè)置問題，導(dǎo)致ALOG文件無法正常傳送。所以應(yīng)及時(shí)聯(lián)系對(duì)端人員(網(wǎng)管組)協(xié)助處理。
總結(jié)：此類問題可以從三方面來分析
1、人工重傳文件。
2、本地設(shè)置和定義的參數(shù)。
3、網(wǎng)絡(luò)是否暢通。
4、對(duì)端的參數(shù)設(shè)置。? AP PROCESS REINITIATED 引起故障的原因：
APG進(jìn)程出現(xiàn)過重啟后會(huì)出現(xiàn)此故障
處理方法：用指令CLUSTER RES查看所有進(jìn)程狀態(tài)是否”O(jiān)NLINE”，如果不是則用指令（CLUSTER RES **** /ON /WAIT）將進(jìn)程”O(jiān)NLINE”，如進(jìn)程狀態(tài)為”O(jiān)NLINE”，用指令A(yù)CEASE消除該告警。? AP FAULT 引起故障的原因：
1、MIRRORED DISKS NOT REDUNDANT：磁盤鏡像有問題引起。
處理方法：用指令“RAIDUTIL –L LOGICAL”查看，如果地址為D0B0T0D0的RAID-1的狀態(tài)為DEGRADED，則用指令“RAIDUTIL –A REBUILD D0B0T0D0”重建RAID-1。等過一段時(shí)間后，地址為D0B0T0D0的RAID-1的狀態(tài)恢復(fù)正常OPTIMAL，故障消除。如果用指令“RAIDUTIL –L LOGICAL”查看所有狀態(tài)均為OPTIMAL，則直接用指令A(yù)CEASE消除該告警。
2、GENERAL ERROR：AP故障引起。
處理方法：用指令A(yù)LIST查看告警列表，如有其他AP故障，先修復(fù)其他故障，然后再用指令A(yù)CEASE消除告警。
3、AP-AP LINK ALARM：一般由AP NOT REDUNDANT故障引起。
處理方法：恢復(fù)AP NOT REDUNDANT故障（詳情看AP NOT REDUNDANT），如
Page ５ of 9 用指令A(yù)LIST沒列出AP NOT REDUNDANT故障，可用ACEASE消除故障。
4、AP EXTERNAL LINK ALARM：一般由AP PROCESS STOPPED故障引起。處理方法：恢復(fù)AP PROCESS STOPPED故障（詳情看AP PROCESS STOPPED），如用指令A(yù)LIST沒列出AP PROCESS STOPPED故障，可用ACEASE消除故障。? AP NOT REDUNDENT： 引起故障的原因：
APG其中一個(gè)NODE DOWN掉引起。
處理方法：如果APG狀態(tài)正常，直接指令A(yù)CEASE清除告警，如果狀態(tài)不正常，按OPI流程：AP，System, Repair處理。過往處理經(jīng)驗(yàn)大概操作：（借鑒）
1、在DOWN掉的NODE先做下一個(gè)REBOOT，看能否把NODE UP起來（做REBOOT前需用指令NET ACCOUNTS /SYNC做一下帳號(hào)同步）。
2、用指令NET START CLUSSVC重啟CLUSTER RES。
3、如執(zhí)行上兩步都無法修復(fù)的話，可連上PCANYWHERE，查檢各SERVICES的設(shè)置（特別是ACS PRC開頭的），跟其他正常運(yùn)作的網(wǎng)元對(duì)比，看是否有設(shè)置不一樣，如有，改正后再做此邊的REBOOT。
4、如還不能恢復(fù)，可打TR提交愛立信，提供解決方案。? AP PROCESS STOP 引起故障的原因：
進(jìn)程人工停止或者遇到故障自動(dòng)停止引起。
處理方法：查看該進(jìn)程狀態(tài)是否“ONLINE”，如該進(jìn)程狀態(tài)為“ONLINE”，用指令A(yù)CEASE消除該告警。如果不是則用指令CLUSTER RES *** /ON /WAIT將該進(jìn)程“ONLINE”，如不成功，可對(duì)此NODE做個(gè)REBOOT解決。? IO STORAGE SPACE WARNING 引起故障的原因： IO存儲(chǔ)空間不足引起
處理方法：CPDLIST –P查看IO文件存放的目錄，用DOS命令DEL刪除多余的IO文件。IO文件形如：AD-0_20041102_0005.LOG ? AP REBOOT
Page ６ of 9 引起故障的原因： APG重啟后的事件告警。
處理方法：檢查該AP狀態(tài)是否為“ACTIVE”, 如不正常，則按AP NOT REDUNDENT流程處理。檢查“CLUSTER GROUP”、“CLUSTER RES”是否“ONLINE”，如不正常，用指令將該進(jìn)程”O(jiān)NLINE”，如不成功，則按AP PROCESS STOP流程處理。檢查APG恢復(fù)正常后，需用指令A(yù)CEASE消除該告警。? CP AP COMMUNICATION FAULT 引起故障的原因： CP與AP通信中斷引起。
處理方法：一般重啟APG或做CP SMALL可以恢復(fù)。注意：裝載補(bǔ)丁、APG重啟或CP重啟期間會(huì)出現(xiàn)該告警。? AP ANTIVIRUS FUNCTION FAULT 引起故障的原因：
AP的NT系統(tǒng)的殺毒軟件設(shè)定了定期更新病毒庫(kù)，如果四次請(qǐng)求下載更新病毒庫(kù)不成功則會(huì)出現(xiàn)告警。
處理方法：故障處理:在ap1設(shè)置eTrust軟件,選Redistribution Server選項(xiàng),然后APG2（計(jì)費(fèi)專用）就可以通過“Redistribution Server”的方式從APG1更新病毒庫(kù)。人工DOWNDLOAD流程看附件：
? AP NOT AVAILABLE 引起故障的原因：
此故障通常是進(jìn)程吊死OFFLINE或NODE DOWN掉起引APG不可用。處理方法：
1、指令CLUSTER RES查看各進(jìn)程狀態(tài)，如有進(jìn)程為OFFLINE，即將進(jìn)程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之間的時(shí)鐘相差600秒引起。處理方法：拔打010117，用指令CACLP核對(duì)CP時(shí)鐘，同是也用AP指令time /T及date /T核對(duì)AP的時(shí)鐘，并對(duì)有誤差的時(shí)鐘進(jìn)行校正。
2、除了第一種原因處，其他原因可提交TR愛立信，提供解決方案。? AP DIAGNOSTIC FAULT 引起故障的原因：AP診斷錯(cuò)誤
處理方法：用指令A(yù)LIST查看告警列表，看是否列出告警號(hào)為8701和告警參考數(shù)據(jù)為：C:ACSlogsUSAusa.temp.I/O error : Missing parameter，如果是，即刪除文件C:ACSlogsUSAusa.temp，并做該AP的REBOOT，如不能解決或其他原因，可提交TR愛立信，提供解決方案。? BILLING，AP DISK，F(xiàn)ILES SPACE LIMIT REACHED 引起故障的原因：
計(jì)費(fèi)容量不足，通常當(dāng)計(jì)費(fèi)文件的大小達(dá)到或超過硬盤分配給CHARGING目錄大小的80%門限值時(shí)，就會(huì)出現(xiàn)計(jì)費(fèi)文件空間達(dá)到限制值的告警。可能會(huì)引起計(jì)費(fèi)文件的丟失。
處理方法：通過減小計(jì)費(fèi)文件在硬盤的保存時(shí)間來解決該告警問題，可依照OPI“APG40, Soft Function Change, Parameter,Change”進(jìn)行對(duì)計(jì)費(fèi)參數(shù)的修改，由于此操作涉及到計(jì)費(fèi)參數(shù)修改，可申請(qǐng)愛立信現(xiàn)場(chǎng)支持。出現(xiàn)此故障，我們可先做以下預(yù)處理：
1、檢查詢問計(jì)費(fèi)中心能否收到此網(wǎng)元的計(jì)費(fèi)文件，如不能，即重啟RDT_Server進(jìn)程（Cluster res Cluster res RDT_Server /off /wait Cluster res RDT_server /on /wait）。
2、將計(jì)費(fèi)文件備份到磁盤，在硬件上刪除掉已備份到磁盤并傳到計(jì)費(fèi)中心的計(jì)費(fèi)文件。
3、在緊急情況下，也可向交換室申請(qǐng)將計(jì)費(fèi)倒到AP1上。? AUDIT LOG DEACTIVATED
Page ８ of 9 引起故障的原因： Audit Log文件被去活。
處理方法：用alogact指令激活A(yù)udit Log。
? BILLING, AP OUTPUT, CONNECTION TO EXTERNAL HOST LO 引起故障的原因：
由于APG網(wǎng)元與省公司計(jì)費(fèi)業(yè)務(wù)中心的FTP配置不一樣所致，雙方的接收協(xié)議存在區(qū)別，但該故障不影響計(jì)費(fèi)文件的產(chǎn)生及接收。
處理方法：修改APG網(wǎng)元SecureDestinationHost的參數(shù)或計(jì)費(fèi)中心修改FTP的配置參數(shù)。
? FILE NOTIFICATION, AP CDH, ACKNOWLEDGEMENT NOT REC 引起故障的原因：
APG數(shù)據(jù)輸出到外部系統(tǒng)失敗，一般都為臨時(shí)性故障。
處理方法：一般臨時(shí)故障會(huì)自已恢復(fù)；用指令cdhver –m destination核驗(yàn)DEST是否正常。
? CONNECTION SUPERVISION, AP CDH, CONNECTION TO REMO 引起故障的原因：同上 處理方法：同上
APG在日常維護(hù)中遇到的另類問題：
? PCANYWHERE連接到APG后，點(diǎn)擊桌面上的圖標(biāo)后沒有反應(yīng)，用顯示器和鍵盤直接連到APG上點(diǎn)擊還是一樣，愛立信認(rèn)為有可能是病毒的問題，但最后都未有結(jié)論。
處理方法：做一個(gè)reboot是可以暫時(shí)解決問題。
? 在做例行TEST LOAD時(shí)，文件LOAD入不成功出IO FAULT 15的結(jié)果。
處理方法：在CP模式中用ocsip看到IPNAOS的版本為CXC1060053R2B01，但是在AP模式下看到的版本為CXC1060053R2C，按照OPI流程Inter-Platform Network Software, Change對(duì)IPN進(jìn)行function change后，問題解決。
? 曾經(jīng)出現(xiàn)有些網(wǎng)元APG REBOOT后，有兩個(gè)進(jìn)程ACS_PRC_ClusterControl_1，ACS_PRC_EventAnalyser_1的狀態(tài)為OFFLINE，將這兩個(gè)進(jìn)程BRING ONLINE
Page ９ of 9 的時(shí)候會(huì)引起APG40的循環(huán)REBOOT。
處理方法：此問題是Acs_prc_eventanalyser 和 Acs_prc_clustercontrol這個(gè)兩個(gè)進(jìn)程的參數(shù)設(shè)置有錯(cuò)誤引起，只要修改這兩項(xiàng)的設(shè)置就可以解決進(jìn)程不能online的問題。具體是通過pcanywhere連到APG的ap1 passive node，在控制面板－SERVICES里面找到這兩項(xiàng)進(jìn)程，將其設(shè)置由原來ATUOMATIC改為Manual，并把ACS_PRC_ eventanalyser的LOG ON AS改為System Account".進(jìn)行完這兩步之后可以在該node重啟進(jìn)程。用同樣的方法在ACTIVE Node完成該操作?，F(xiàn)在APG的問題可以解決。
以后類似進(jìn)程不能重啟的問題可以先找一個(gè)正常的APG系統(tǒng)找到該進(jìn)程將兩者的參數(shù)設(shè)置比較一下，是否設(shè)置錯(cuò)誤的問題。? 在一邊node做reboot后不能恢復(fù)的問題。
處理方法：主要是raid磁盤的問題，操作步驟是參照OPI: APG40, Node, Change。
第三篇：近期典型故障處理情況通報(bào)
近期典型網(wǎng)絡(luò)故障情況通報(bào)
近期處理網(wǎng)絡(luò)故障較多，綜合處理情況，現(xiàn)將幾起典型故障處理情況過程通報(bào)如下，請(qǐng)各縣市分公司能加強(qiáng)管理，提高維護(hù)人員的故障處理能力和責(zé)任心。
一、傳輸數(shù)據(jù)中心在對(duì)網(wǎng)絡(luò)例行檢查時(shí)發(fā)現(xiàn)營(yíng)業(yè)部OA、CMNET、BOSS三網(wǎng)絡(luò)成環(huán)，結(jié)合營(yíng)業(yè)部辦公樓近期故障較多的情況，安排中移代維人員進(jìn)行集中查處，具體處理情況見（營(yíng)業(yè)部環(huán)路分析報(bào)告）,從營(yíng)業(yè)部代維人員的分析報(bào)告中可以看出幾點(diǎn)問題，請(qǐng)營(yíng)業(yè)部要落實(shí)：（1）首先營(yíng)業(yè)部二樓機(jī)房網(wǎng)線較亂，營(yíng)業(yè)部是否安排人員對(duì)機(jī)柜進(jìn)行整理，其它區(qū)域的機(jī)柜是否也有類似情況，應(yīng)安排維護(hù)人員對(duì)所有的機(jī)房機(jī)柜進(jìn)行檢查整改；（2）興馬（代理商）為什么會(huì)從營(yíng)業(yè)部接入CMNET網(wǎng)絡(luò)，是否有相關(guān)部門的批準(zhǔn)，興馬將BOSS與CMNET接入同一交換機(jī)，造成CMNET與BOSS成環(huán)，是自行接入還是公司維護(hù)人員接入的？網(wǎng)絡(luò)私接亂拉是否有相關(guān)的考核辦法；（3）舞陽(yáng)十樓無營(yíng)業(yè)部的相關(guān)部門，為什么會(huì)有BOSS和OA的網(wǎng)絡(luò)，請(qǐng)營(yíng)業(yè)部清理相關(guān)的IP地址，對(duì)不需要使用的進(jìn)行刪除。
二、建始分公司網(wǎng)絡(luò)成環(huán)影響到恩施分公司整個(gè)的OA及BOSS網(wǎng)運(yùn)行情況，在建始分公司報(bào)故障的同時(shí)也有其它縣市報(bào)故障，為保證全網(wǎng)正常運(yùn)行，傳輸數(shù)據(jù)中心按業(yè)務(wù)需求對(duì)相應(yīng)的網(wǎng)絡(luò)隔離斷開連接，按照BOSS大于OA；OA大于CMNET的原則進(jìn)行處理，請(qǐng)建始分公司結(jié)合本公司故障查詢情況加強(qiáng)區(qū)域管理，對(duì)工程建設(shè)情況造成的故障，指定隨工人員的管理。故障處理經(jīng)過見（7月8日建始環(huán)路故障報(bào)告）。
三、巴東分公司處理電視電話會(huì)議網(wǎng)絡(luò)不通的過程中，可發(fā)現(xiàn)以下幾個(gè)問題，請(qǐng)巴東分公司明確整改：（1）巴東分公司領(lǐng)取設(shè)備更換后能不能正常使用未進(jìn)行測(cè)試；（2）在巴東需要視頻進(jìn)行監(jiān)考前才聯(lián)系州公司說因設(shè)備故障不能使用，巴東分公司維護(hù)人員在設(shè)備到巴東和視頻監(jiān)考開始前這段時(shí)間在做什么，故障處理及時(shí)率在哪里？維護(hù)管理人員是如何安排的（3）巴東分公司視訊會(huì)議系統(tǒng)由技術(shù)支持中心維護(hù)，不能以沒有人處理（下鄉(xiāng)）為由。
結(jié)合以上幾個(gè)縣市分公司出現(xiàn)的問題，請(qǐng)各縣市加強(qiáng)網(wǎng)絡(luò)維護(hù)的管理，對(duì)私接亂拉的制定相應(yīng)的考核機(jī)制；同時(shí)，要加強(qiáng)維護(hù)人員的責(zé)任心，對(duì)故障處理超時(shí)、找借口之類的情況實(shí)行問責(zé)制，對(duì)代維人員加強(qiáng)管理，提高代維人員故障處理能力；對(duì)于縣市分公司維護(hù)管理人員故障安排協(xié)調(diào)不力的情況進(jìn)行通報(bào)。
第四篇：愛立信基站典型故障處理案例[定稿]
愛立信基站典型故障處理案例
案例1：對(duì)基站進(jìn)行IDB的配置總是無法完成，提示為時(shí)間超時(shí)。當(dāng)對(duì)基站進(jìn)行IDB數(shù)據(jù)的配置時(shí)，因?yàn)門RU與DXU軟件版本不一致，或BSC下載軟件的同時(shí)進(jìn)行DXU數(shù)據(jù)配置而產(chǎn)生沖突，或第一次IDB配置電源電壓類型錯(cuò)誤，或短時(shí)間內(nèi)頻繁的對(duì)DXU進(jìn)行IDB配置等原因，偶爾可能導(dǎo)致再進(jìn)行IDB的數(shù)據(jù)配置時(shí)，出現(xiàn)提示為時(shí)間超時(shí)而無法完成的現(xiàn)象。導(dǎo)致DXU同機(jī)架內(nèi)部的通信上存在異?，F(xiàn)象，出現(xiàn)類似機(jī)架掉死的現(xiàn)象，更換DXU無效。
解決的辦法是，將DXU（或新的DXU）放到同基站的其它機(jī)架上，或另外的基站上，僅對(duì)DXU加電，按照存在問題的機(jī)架配置進(jìn)行IDB的重新配置，完成后再安裝到存在問題的機(jī)架上，不必再重新配置，對(duì)DXU等各模塊加電重起，即可解決問題。
案例2：RBS200基站工作不穩(wěn)定，經(jīng)常退服?；靖鞑考姆€(wěn)定工作離不開穩(wěn)定的時(shí)鐘信號(hào)，而基站的時(shí)鐘信號(hào)是從PCM傳輸中提取的，愛立信的基站不提供外部時(shí)鐘輸入的端口, RBS200基站是愛立信早期推出的GSM基站產(chǎn)品，這些基站設(shè)備是基于采用傳統(tǒng)的PDH傳輸組網(wǎng)方式而設(shè)計(jì)的，并不非常適用于SDH傳輸組網(wǎng)方式，這就會(huì)導(dǎo)致RBS200基站在和某些廠家的SDH傳輸設(shè)備配合使用時(shí)，導(dǎo)致基站工作不穩(wěn)定，頻繁出現(xiàn)時(shí)鐘同步的告警，經(jīng)常退服，嚴(yán)重影響了基站的正常運(yùn)行。
解決辦法有兩種：一種是將RBS200基站使用的SDH傳輸更換為PDH傳輸；另一種是將RBS200基站設(shè)備更換為RBS2000基站設(shè)備，因?yàn)镽BS2000對(duì)同步要求較RBS200低，能夠很好同SDH傳輸配合工作。
案例3：開始時(shí)，馬廠湖基站有部分TS總是無法正常工作，且不固定在某個(gè)載頻上，更換TRU、DXU無效，對(duì)基站的數(shù)據(jù)進(jìn)行拆掉重新加載后仍無效，后來整個(gè)基站所有的TS均無法正常工作，基站硬件、傳輸、數(shù)據(jù)等均不存在問題。點(diǎn)檢查了基站的所有硬件均不存在故障現(xiàn)象，對(duì)懷疑有問題的TRU、DXU進(jìn)行了更換；對(duì)傳輸進(jìn)行了環(huán)路測(cè)量，也未發(fā)現(xiàn)傳輸電路存在質(zhì)量問題；檢查小區(qū)、基站的定義數(shù)據(jù)也都正常。懷疑基站的數(shù)據(jù)存在掉死的現(xiàn)象，但沒有確鑿的證據(jù)。嘗試用另外一種方法進(jìn)行故障的定位。從BSC的ETC傳輸接口處，即ETRBLT板子2M接口處將馬廠湖基站的傳輸DIP=97同另外一個(gè)類似配置的基站裝載機(jī)廠的傳輸DIP=98直接進(jìn)行互換，也就是說互相用對(duì)方基站的數(shù)據(jù)來開通基站?；Q后發(fā)現(xiàn)，馬廠湖基站的數(shù)據(jù)在裝載機(jī)廠基站上仍然存在同樣的問題，而裝載機(jī)廠基站的數(shù)據(jù)在馬廠湖基站上卻能正常工作。這就可以說明，馬廠湖基站的硬件、傳輸均不存在問題，基站數(shù)據(jù)確實(shí)存在掉死的現(xiàn)象。
在確認(rèn)馬廠湖基站的數(shù)據(jù)存在掉死的情況后，重新定義了新的TG數(shù)據(jù)，來替換原先存在掉死現(xiàn)象的TG數(shù)據(jù)，整個(gè)基站恢復(fù)正常運(yùn)行。
對(duì)上述基站數(shù)據(jù)掉死的解決辦法還有一種是進(jìn)行BSC的重新啟動(dòng)，因?yàn)樾枰谕砩线M(jìn)行，因此可能會(huì)導(dǎo)致基站退服的時(shí)間較長(zhǎng)。
案例4：中國(guó)銀行基站第2小區(qū)對(duì)應(yīng)的機(jī)架為2個(gè)CDU C，4個(gè)載頻配置，總是在4個(gè)載頻全部開起來后，又很快全部退服，現(xiàn)象為第1、2個(gè)TRU狀態(tài)為TX not enabled，第3、4個(gè)TRU為Fault燈和Operational燈同時(shí)亮。每次對(duì)DXU進(jìn)行復(fù)位，總是出現(xiàn)上述的同樣現(xiàn)象，整個(gè)小區(qū)無法正常運(yùn)行。
因?yàn)榈?、4個(gè)TRU總是出現(xiàn)故障現(xiàn)象，將這兩個(gè)TRU更換，仍然出現(xiàn)同樣的故障現(xiàn)象；更換第3、4個(gè)TRU對(duì)應(yīng)的第2個(gè)CDU C，仍然出現(xiàn)同樣的故障現(xiàn)象。將第3、4個(gè)TRU放到第5、6個(gè)TRU的位置上，將第2個(gè)CDU放到第3個(gè)CDU的位置，這樣載頻的位置為第1、2、5、6，甩開TRU第3、4位置不使用，整個(gè)小區(qū)正常運(yùn)行，不再出現(xiàn)上述故障現(xiàn)象。
根據(jù)以上處理過程進(jìn)行分析，應(yīng)該是第2個(gè)CDU C對(duì)應(yīng)的CDU BUS總線或第3、4個(gè)TRU對(duì)應(yīng)的背板存在問題，導(dǎo)致第2個(gè)CDU C不能正常工作，不僅導(dǎo)致第3、4個(gè)TRU不能正常工作，而且導(dǎo)致整個(gè)小區(qū)不能正常工作。
將第2個(gè)CDU C對(duì)應(yīng)的CDU BUS總線拆下來，更換一新的CDU BUS總線后，故障解決，確認(rèn)是第2個(gè)CDU C對(duì)應(yīng)的CDU BUS總線存在問題。下圖是CDU BUS的連接示意圖：
還有一種解決辦法，就是將CDU C更換為CDU C+，并且使用Y cable，按照如下圖連接：
這樣就可以不再使用第2個(gè)CDU C對(duì)應(yīng)的有問題的CDU BUS總線，就不會(huì)出現(xiàn)整個(gè)小區(qū)開不起來的現(xiàn)象。
案例5：沂水城東基站A小區(qū)擴(kuò)容一個(gè)機(jī)架，由6載頻擴(kuò)容為8載頻。在打開跳頻的情況下，A小區(qū)所有8個(gè)載頻的時(shí)隙全部正常工作后很快陸續(xù)全部退服，同時(shí)出現(xiàn)1A級(jí)的XBus Fault告警，但告警很快又消失。對(duì)基站A小區(qū)復(fù)位或閉解CF，仍然是同樣的故障現(xiàn)象。將A小區(qū)的跳頻關(guān)掉后可以正常運(yùn)行。
針對(duì)出現(xiàn)的XBus Fault告警，重點(diǎn)檢查了新增擴(kuò)的機(jī)架TRU和DXU背板跳點(diǎn)設(shè)置，CDU BUS的連接情況，均未發(fā)現(xiàn)異常，更換DXU也不能解決問題?？紤]到當(dāng)時(shí)是在上午忙時(shí)，此小區(qū)承擔(dān)的話務(wù)量很高，有可能是因?yàn)锳小區(qū)重起時(shí)接入用戶太多導(dǎo)致負(fù)荷過高而不能以跳頻方式正常運(yùn)行，設(shè)置A小區(qū)參數(shù)CB=YES禁止待機(jī)時(shí)手機(jī)接入，設(shè)置A小區(qū)為L(zhǎng)ayer=3小區(qū)限制其它小區(qū)手機(jī)用戶向A小區(qū)切換，這樣的參數(shù)設(shè)置曾經(jīng)解決過類似大容量小區(qū)在打開跳頻的情況下忙時(shí)重起困難的問題，但仍不能解決沂水城東A小區(qū)的問題。
懷疑新增擴(kuò)的2個(gè)TRU雖然狀態(tài)顯示正常，但仍然可能存在問題，導(dǎo)致XBbus工作異常。由于A小區(qū)的主架的6個(gè)TRU和副架的2個(gè)TRU間已多次互相倒換位置來排除TRU的問題，已經(jīng)不能分清哪2個(gè)TRU是新增擴(kuò)的。于是將A小區(qū)的所有8個(gè)載頻全部替換，問題解決?？偨Y(jié)：某個(gè)存在故障的TRU可以導(dǎo)致其背板連接的總線工作異常，在這個(gè)案例中，導(dǎo)致了XBus工作異常，小區(qū)不能打開跳頻，但是此TRU的狀態(tài)顯示完全正常。解決辦法是替換懷疑有問題的TRU，尤其是新增擴(kuò)的TRU，不要采取在有問題的小區(qū)內(nèi)互相倒換的方式，因?yàn)榇嬖诠收系腡RU無論在那個(gè)位置均可以導(dǎo)致同樣的故障現(xiàn)象。應(yīng)該用其它小區(qū)或新帶來得TRU替換。
還有一個(gè)例子也是存在故障的TRU導(dǎo)致其背板連接的總線工作異常的情況：某小區(qū)新擴(kuò)一個(gè)機(jī)架，載頻由6個(gè)擴(kuò)容到7個(gè)，但是每次啟站時(shí)總是很快出現(xiàn)駐波比過高的基站告警，所有載頻全部退服，故障原因是新擴(kuò)的TRU（在新擴(kuò)的副架上）存在問題，雖然表面狀態(tài)均很正常，但是把它插到機(jī)框內(nèi)加電后，就會(huì)干擾背板總線的正常工作，導(dǎo)致出現(xiàn)整個(gè)小區(qū)駐波比過高的問題產(chǎn)生。
案例6：付莊基站為3個(gè)RBS2202機(jī)架級(jí)聯(lián)、4/4/4配置，故障現(xiàn)象為B小區(qū)退服，復(fù)位后B小區(qū)恢復(fù)正常，但幾小時(shí)后又再次退服，基站不存在任何告警。如此反復(fù)，B小區(qū)工作狀態(tài)很不穩(wěn)定。
因?yàn)槭窃诨具\(yùn)行中出現(xiàn)的故障，所以首先懷疑是B小區(qū)DXU出現(xiàn)故障，但是更換后仍無法解決。檢查B小區(qū)的射頻電纜、PCM傳輸電纜、CDU總線均無異常。通過OMT軟件監(jiān)測(cè)付莊基站3個(gè)機(jī)架DXU的PCM連接狀態(tài)均正常。考慮到B小區(qū)是級(jí)聯(lián)A小區(qū)的，即PCM傳輸電纜從A小區(qū)DXU的G.703-2端口連接到B小區(qū)DXU的G.703-1端口，這段傳輸通路是否存在問題？更換這段通路上的所有傳輸電纜，仍不能解決問題。再向前考慮一步，是不是A小區(qū)DXU的G.703-2端口存在問題，雖然沒有故障狀態(tài)顯示？更換A小區(qū)的DXU，重新配置IDB數(shù)據(jù)后，問題解決。
總結(jié)：針對(duì)多機(jī)架級(jí)聯(lián)的基站，第2、3小區(qū)退服的情況，要考慮前一級(jí)級(jí)聯(lián)的小區(qū)所在的機(jī)架是否存在DXU故障、PCM傳輸電纜接錯(cuò)、IDB數(shù)據(jù)中未定義PCM級(jí)聯(lián)等情況。
案例7：某個(gè)基站第2小區(qū)有3個(gè)時(shí)隙LMO狀態(tài)為0800，復(fù)位和更換載頻后無效。
檢查基站的定義數(shù)據(jù)，發(fā)現(xiàn)第2小區(qū)對(duì)應(yīng)的TG-139，在定義半永久連接關(guān)系時(shí)，將RBLT-1309與DCP 28連接是錯(cuò)誤的，導(dǎo)致DCP 28相對(duì)應(yīng)的4個(gè)TS時(shí)隙，無法正常工作。應(yīng)該是RBLT-1308與DCP 28連接，正確修改后，故障解除。類似的故障現(xiàn)象可能還有如下的故障原因：（1）某個(gè)基站第2小區(qū)4個(gè)時(shí)隙LMO狀態(tài)為0800復(fù)位和更換載頻無效：用DTIDP指令檢查DIP的定義數(shù)據(jù)，發(fā)現(xiàn)MODE=1是錯(cuò)誤的。RBS200基站的DIP定義為MODE=1，即傳輸?shù)牡?6時(shí)隙僅用于傳信令，不用于傳話音。而此基站為RBS2000基站，正確的定義是MODE=0，如果定義為MODE=1，會(huì)導(dǎo)致DCP 16，即傳輸?shù)牡?6時(shí)隙不能正常使用，出現(xiàn)上述的故障現(xiàn)象，或者導(dǎo)致用戶占用時(shí)出現(xiàn)單通現(xiàn)象。
（2）某個(gè)基站第3小區(qū)2個(gè)時(shí)隙LMO狀態(tài)為0800，復(fù)位無效： 第3小區(qū)的2個(gè)時(shí)隙的故障原因是在定義基站數(shù)據(jù)時(shí)，MO CF的參數(shù)SIG=UNCONC錯(cuò)誤，因?yàn)樗械腡RX的SIG=CONC，導(dǎo)致TG分配的DCP不夠用。將MO CF的參數(shù)該為SIG=CONC，故障消除。
案例8：某個(gè)新建基站傳輸狀態(tài)正常，硬件也不存在問題，但基站開不起來 基站數(shù)據(jù)定義看起來不存在問題，其它檢查也做了很多，但基站仍然不能開起來。重點(diǎn)檢查基站DIP所連接的SNT的DEVICE數(shù)據(jù)定義，會(huì)發(fā)現(xiàn)RBLT的狀態(tài)不對(duì)，為MBL閉掉的狀態(tài)，試圖解閉，可能還會(huì)發(fā)現(xiàn)未完全定義，再用EXDAI、EXDUI指令進(jìn)行補(bǔ)充定義，解閉此SNT所帶的RBLT，再重新LOAD基站數(shù)據(jù)后問題解決。對(duì)新建基站開不起來的情況，還有BSC側(cè)MO=RXOCF的TEI值與基站OMT軟件定義的不一致，導(dǎo)致基站無法同BSC建立聯(lián)系。此種情況較多的出現(xiàn)在級(jí)聯(lián)基站上，重新定義，使基站的TEI值同BSC側(cè)定義的TEI值一致便可解決問題。
案例9：盲?；敬嬖谒矓喱F(xiàn)象，導(dǎo)致信道完好率雖然很接近但達(dá)不到100%，同時(shí)基站傳輸設(shè)備也出現(xiàn)傳輸瞬斷的現(xiàn)象。
檢查基站硬件設(shè)備，及傳輸設(shè)備均未發(fā)現(xiàn)異常，更換DXU也無法解決問題。在基站上進(jìn)行故障處理時(shí)，發(fā)現(xiàn)老式的愛立信開關(guān)電源存在模塊損壞的情況，但仍能正常工作。經(jīng)過長(zhǎng)時(shí)間現(xiàn)場(chǎng)觀察，發(fā)現(xiàn)交流電壓不穩(wěn)定，忽高忽低，當(dāng)電壓過高時(shí)，開關(guān)電源的過壓保護(hù)器便跳脫保護(hù)，愛立信開關(guān)電源所有的模塊處在過壓保護(hù)的狀態(tài)，同時(shí)傳輸設(shè)備瞬間復(fù)位，導(dǎo)致基站瞬斷。此時(shí)就發(fā)現(xiàn)了交流電壓過高可能是導(dǎo)致盲?；舅矓嗟脑?。經(jīng)過分析，老式的愛立信開關(guān)電源對(duì)交流電電壓波動(dòng)范圍的適應(yīng)性較差，當(dāng)電壓過高超出其限定值時(shí)，開關(guān)電源的所有模塊出現(xiàn)瞬間的保護(hù)而導(dǎo)致其直流輸出電壓異常，從而導(dǎo)致傳輸設(shè)備因直流供電不能滿足要求而瞬間復(fù)位，導(dǎo)致愛立信基站瞬間退服。
將老式的愛立信開關(guān)電源更換為能適應(yīng)寬范圍交流電壓波動(dòng)的新式開關(guān)電源，問題解決，盲?；驹僖参闯霈F(xiàn)瞬斷的現(xiàn)象。這樣的情況也存在于其它部分型號(hào)的、對(duì)交流電壓波動(dòng)適應(yīng)性差的老式開關(guān)電源上。
案例10：柳行頭基站為九期新建全向2載頻基站，傳輸環(huán)路狀態(tài)正常，不存在滑碼、誤碼等傳輸質(zhì)量差的情況，基站硬件狀態(tài)正常，不存在任何告警，但將傳輸頭子接到DXU的G.703-1接口后，BSC側(cè)傳輸狀態(tài)顯示W(wǎng)O正常狀態(tài)，但是DXU黑燈，所有的指示燈均不亮。從BSC側(cè)觀察是CF無法Load成功，導(dǎo)致此基站開不起來。
首先全面檢查基站硬件、傳輸設(shè)備、傳輸電纜等均沒有發(fā)現(xiàn)問題，檢查柳行頭基站數(shù)據(jù)、小區(qū)數(shù)據(jù)定義也沒有發(fā)現(xiàn)問題，更換DXU也不能解決問題。
從BSC的ETC傳輸接口處將柳行頭基站的傳輸同另外一個(gè)相同配置且正在運(yùn)行的松峰基站傳輸互換，不必改動(dòng)任何數(shù)據(jù)，也就是說互相用對(duì)方基站的數(shù)據(jù)來開通。柳行頭基站的數(shù)據(jù)在松峰基站上運(yùn)行正常，而松峰基站的數(shù)據(jù)卻無法在柳行頭基站上運(yùn)行，這就可以說明柳行頭基站的數(shù)據(jù)不存在錯(cuò)誤、掉死等異常情況，而從BSC到柳行頭基站的傳輸通路上存在問題，也可能是基站硬件存在問題（這已排除）。
這樣重點(diǎn)懷疑從BSC到柳行頭基站的傳輸通路上存在問題，需要仔細(xì)檢查，傳輸維護(hù)人員從BSC往基站方向一段一段進(jìn)行檢查，果然發(fā)現(xiàn)在北園傳輸機(jī)房處柳行頭基站的傳輸跳線存在問題，120歐姆4根信號(hào)傳輸線中的一根與配線端子處在似接觸非接觸的狀態(tài)，重新卡接后，柳行頭基站CF軟件load成功，基站順利開通，問題解決。
需要注意的是，基站電路環(huán)路時(shí)是通的，并不能代表基站電路完全不存在問題，因?yàn)檫€存在類似上述傳輸信號(hào)線接觸不好、遠(yuǎn)端告警等一些特殊的傳輸故障現(xiàn)象。
案例11：郵政局基站C小區(qū)擴(kuò)容到主、副架共12個(gè)載頻，但是最多只能開起來10個(gè)載頻，總有2個(gè)載頻無論如何也開不起來，并且這2個(gè)開不起來的載頻位置不固定，狀態(tài)表現(xiàn)為僅Tx not enable燈亮。基站不存在告警。更換相應(yīng)的載頻無效。仔細(xì)觀察開不起來的2個(gè)載頻的故障現(xiàn)象，發(fā)現(xiàn)總是某一個(gè)CU上的2個(gè)載頻同時(shí)出現(xiàn)開不起來的現(xiàn)象，雖然這個(gè)CU也不是固定的。將12個(gè)載頻中的某兩個(gè)位于同一個(gè)CU上的載頻TRX閉掉，其它10個(gè)載頻均能正常工作。
根據(jù)以上現(xiàn)象，考慮到愛立信基站載頻相互間發(fā)射部分TX和接收部分RX存在“借用現(xiàn)象”，即載頻A的RX（可能載頻A的TX存在問題）和載頻B的TX可以組成一個(gè)完整的正常工作的“載頻”，而載頻A的狀態(tài)可能為正常運(yùn)行狀態(tài)，而載頻B的狀態(tài)為僅Tx not enable燈亮。
進(jìn)一步從BSC上觀察郵政局基站C小區(qū)各MO的工作狀態(tài)，發(fā)現(xiàn)最后2個(gè)載頻的TX-11&&-12工作狀態(tài)開始時(shí)總是NOOP，過一段時(shí)間之后狀態(tài)變?yōu)镕AIL，但是考慮到最后2個(gè)載頻的TX發(fā)射部分可以借用另外2個(gè)載頻的TX發(fā)射部分，即存在TX的“借用現(xiàn)象”，因此狀態(tài)仍有可能是正常運(yùn)行的。導(dǎo)致TX狀態(tài)為FAIL的原因有發(fā)射通路上的CDU存在問題，連接的天線駐波比過大，TX定義的連接小區(qū)錯(cuò)誤，TRU的發(fā)射部分存在故障等原因。經(jīng)過排查，重點(diǎn)懷疑是最后2個(gè)載頻，即TRX-11&&-12對(duì)應(yīng)連接的CU存在問題，雖然此CU的運(yùn)行狀態(tài)正常，無故障燈指示。更換此CU后，郵政局C小區(qū)的12個(gè)載頻全部開起來，問題解決。這種類型的故障處理，不要被基站各硬件的運(yùn)行狀態(tài)顯示所迷惑，可能狀態(tài)是正常的，但是也有可能存在問題，就像上面所講的CU的故障現(xiàn)象。
案例12：TX無法正常工作，基站告警為CDU output power limits exceeds 九期工程中，在開通西梁王基站（S2，2，2）時(shí)，發(fā)現(xiàn)雖然基站本測(cè)過程中,各MO 狀態(tài)正常,均無告警，但是在開站時(shí),當(dāng)TX打開后, B小區(qū)CDU的Fault 紅燈亮,，小區(qū)不能工作。我們通過OMT查尋告警，監(jiān)測(cè)到SO CF 2A:9 :CDU output power limits exceeds。首先我們懷疑天饋系統(tǒng)有問題,用駐波比測(cè)試儀測(cè)得DTF值1.08,SWR值1.19,均為正常值。隨后更換了CDU及TRU后故障仍未排除。最后我們根據(jù)TX的原理,輸出功率由前向及反向功率的比較得出的(Reference RBS2202),于是檢查對(duì)應(yīng)的Pref,Pfwd饋線,發(fā)現(xiàn)標(biāo)簽貼反,導(dǎo)致反向功率總大于前向功率，更改后故障消除。
案例13：基站存在SO CF 2A: Timing bus fault告警，TRU無法工作。建工大廈基站(S6,6,6,)在擴(kuò)為（S8,6,6）時(shí),A小區(qū)擴(kuò)容的副柜TRU狀態(tài)不對(duì),TRU的Fault在自檢后長(zhǎng)亮。此時(shí)B,C小區(qū)已正常。用B,C小區(qū)的機(jī)柜帶A小區(qū)的副柜無問題,從而證明A小區(qū)的副柜本身無問題。通過OMT查尋告警，監(jiān)測(cè)到SO CF 2A: Timing bus fault。更換C5 BUS線后故障仍未排除，于是判定故障點(diǎn)應(yīng)在A小區(qū)機(jī)柜本身之內(nèi)。根據(jù)OMT讀出告警，判斷故障為機(jī)柜內(nèi) BUS問題,更換后狀態(tài)正常，A小區(qū)正常工作。
案例14：PSU的排障方法
下面是滿配置的PSU與ECU的光纖連接示意圖： 在基站出現(xiàn)同PSU相關(guān)的告警后，到基站上觀察PSU的狀態(tài)，可能有如下兩種情況：第一種是PSU亮紅燈或不亮燈，第二種是PSU面板狀態(tài)正常但可能存在故障。針對(duì)第一種情況，首先檢查PSU的-48V直流（PSU-48）或230交流（PSU 230）輸入是否正常，可能存在輸入開關(guān)跳脫或熔絲熔斷的情況，如果排除上述情況，那么很可能是亮紅燈或不亮燈的PSU存在故障，進(jìn)行更換確認(rèn)。對(duì)更換后的新PSU，應(yīng)該先加-48V直流或230交流輸入（下面的接頭），再連接直流輸出接頭（上面的接頭），否則容易導(dǎo)致新加的PSU因?yàn)橹绷麟娏鞯构嗟脑蚨俅螕p壞。針對(duì)第二種情況，使用逐個(gè)排除的方法來找出存在故障但面板顯示正常的PSU。滿配置的PSU數(shù)量一共是4個(gè)，與ECU通過光纖串聯(lián)在一起，形成一個(gè)環(huán)路。首先甩開左邊第1個(gè)PSU，將剩下的3個(gè)PSU同ECU通過光纖串形連接，再觀察基站的PSU相關(guān)告警是否消除，如果消除，則說明左邊第1個(gè)PSU存在故障，進(jìn)行更換；如果故障仍未消除，可將左邊第2個(gè)PSU單獨(dú)甩開，將剩下的3個(gè)PSU同ECU通過光纖串形連接，需注意的是從左邊第1個(gè)PSU直接連接到第3個(gè)PSU的光纖需要換成長(zhǎng)一點(diǎn)的光纖，再觀察基站的PSU相關(guān)告警是否消除，以此類推，逐個(gè)排查PSU。除了上述方法，類似的，還可采用每個(gè)PSU單獨(dú)同ECU串形連接，再觀察基站告警是否消除的方法，逐一進(jìn)行排查。還有一點(diǎn)需要說明的是，基站對(duì)PSU的識(shí)別并不是完全根據(jù)PSU的安裝位置，例如最左邊的PSU被識(shí)別為PSU-0，向右依次為PSU-
1、PSU-
2、PSU-3，實(shí)際上并不是這樣的。基站識(shí)別PSU是通過光纖環(huán)路來識(shí)別的，不在這個(gè)環(huán)上的PSU將不被識(shí)別，同時(shí)針對(duì)這個(gè)不在環(huán)上的PSU基站也不會(huì)產(chǎn)生告警。光纖環(huán)路連接最左邊的PSU被識(shí)別為PSU-0，然后依據(jù)光纖環(huán)路上的連接，向右依次識(shí)別為PSU-
1、PSU-2等，例如PSU-0，它的實(shí)際安裝位置可能是從最左邊數(shù)第3個(gè)PSU。
有一個(gè)故障現(xiàn)象是某個(gè)PSU的架頂-48V輸入接口因短路損壞嚴(yán)重，不能再使用，并且基站存在相應(yīng)告警。消除告警的辦法是在PSU與ECU的光纖環(huán)路中，甩開這個(gè)損壞嚴(yán)重的架頂-48V輸入接口對(duì)應(yīng)的PSU，再?gòu)腎DB數(shù)據(jù)中刪除多余的PSU（損壞的接口對(duì)應(yīng)的）即可消除告警。
第五篇：電梯典型故障分析及處理方案
電梯典型故障分析及處理方案
摘要：當(dāng)今社會(huì)發(fā)展迅速，高層建筑早已走上時(shí)代舞臺(tái)，而高層建筑離不開電梯的使用，為了確保電梯的安全、有效運(yùn)行，完善高層建筑功能，本文總結(jié)分析了時(shí)下一些典型電梯故障，并選出其中若干案例，提出了相應(yīng)的處理方案。為有效的電梯監(jiān)測(cè)和高層建筑安全體防護(hù)提供一些建議和幫助。關(guān)鍵詞：排除故障；電氣系統(tǒng)；電梯故障
社會(huì)發(fā)展日新月異，如今電梯正廣泛應(yīng)用在城市高層建筑當(dāng)中，便于乘客或貨物的垂直運(yùn)輸。由于其本身為運(yùn)輸設(shè)備，具有機(jī)電一體化的特點(diǎn)，且需要微機(jī)監(jiān)控著它運(yùn)行的系統(tǒng)，電梯運(yùn)作往往需要軟件和硬件的交叉配合才能起到有效和安全的防護(hù)作用。但是，近年來，電梯故障日益增多，電梯出事率正逐漸增加，至此，電梯安全防護(hù)問題逐漸受到大家的關(guān)注。電梯在運(yùn)行中所產(chǎn)生的故障主要來自于電氣控制系統(tǒng)，本文從此角度著手，就電梯典型故障展開探討，并提出了相應(yīng)解決方案。
一、電梯典型故障原因及分析
電氣控制、機(jī)械、拖動(dòng)回路等部分組成了電梯，因此，在查找故障時(shí)，應(yīng)主要從以下幾個(gè)方面考慮。1.電氣控制系統(tǒng)故障
通常情況下，乘坐電梯舒適感降低，嚴(yán)重時(shí)造成人身傷害或設(shè)備事故等電梯無法正常工作的故障原因往往在于電氣控制系統(tǒng)，因電氣控制系統(tǒng)的內(nèi)部元件發(fā)生異常，產(chǎn)生故障。電梯的主要故障就來自于電氣系統(tǒng)故障。而電氣系統(tǒng)容易出現(xiàn)的故障包括：①自動(dòng)關(guān)、開門，該故障也是最典型的電氣系統(tǒng)故障，因自動(dòng)關(guān)、開電氣元件接觸不良，就造成無法順利開、關(guān)電梯門的故障。②破壞電氣元件絕緣，電梯在長(zhǎng)期的運(yùn)行中，電氣系統(tǒng)電子電氣元件會(huì)在老化、失效、受潮等變化中降低絕緣性能，當(dāng)擊穿絕緣后，電氣系統(tǒng)就會(huì)發(fā)生斷路或短路的故障。③接觸點(diǎn)處元件發(fā)生斷路或短路，開關(guān)、繼電器、接觸器等若出現(xiàn)短路和斷路現(xiàn)象，失效電路，從而引發(fā)電梯故障。當(dāng)塵埃阻斷接觸點(diǎn)時(shí)，斷路的情況就會(huì)出現(xiàn)；當(dāng)電弧燒蝕接觸點(diǎn)時(shí)或者接觸點(diǎn)處電流偏大使，電路短路情況就會(huì)發(fā)生。2.機(jī)械系統(tǒng)故障
我們分別從以下兩點(diǎn)來看，第一，連接件松脫。在不間斷地、長(zhǎng)期運(yùn)行中，電梯因震動(dòng)等原因?qū)е滤擅摗⑺蓜?dòng)緊固件的現(xiàn)象，嚴(yán)重時(shí)，還會(huì)發(fā)生位移、滑脫等機(jī)械事故，加大部件之間的消耗、磨損，失去了原來的精度，最終導(dǎo)致電梯故障。第二，自然磨損。磨損是機(jī)械部件的運(yùn)作過程中的必然現(xiàn)象，而一定程度的磨損會(huì)導(dǎo)致故障的產(chǎn)生，必須要更換新部件。所以，當(dāng)大檢修電梯時(shí)，為了防范于未然，應(yīng)及時(shí)更換容易出現(xiàn)磨損的部件。日常維修電梯時(shí)，必須注意保養(yǎng)與調(diào)整部分期間，才能確保電梯繼續(xù)正常、有序的運(yùn)行。但是，部件磨損情況因滑動(dòng)、滾動(dòng)而產(chǎn)生，這就加速磨損機(jī)械，電梯故障也就不可避免了。例如：當(dāng)磨損鋼絲繩達(dá)到一定程度后，為了防止發(fā)生安全事故，就需要及時(shí)將其更換。除了鋼絲繩，各種運(yùn)轉(zhuǎn)軸承也必須定期更換，因?yàn)檫@些器件都是容易產(chǎn)生損耗、磨損的。3.主拖動(dòng)系統(tǒng)故障
通過構(gòu)成主回路的各環(huán)節(jié)來檢查與排除電梯主拖動(dòng)系統(tǒng)故障。主拖動(dòng)系統(tǒng)并非連續(xù)的工作狀態(tài)，所以當(dāng)經(jīng)過一段時(shí)間的電梯運(yùn)行后，就會(huì)出現(xiàn)電機(jī)軸承磨損、接觸不良、接點(diǎn)脫落、觸電氧化、觸電彈片疲勞、擊穿或燒斷可控硅熱和逆變模塊等等，因此，可以從檢修與排查如上幾部分檢修與排查主拖動(dòng)系統(tǒng)故障。4.使用不當(dāng)
在日常生活中，未按運(yùn)行要求使用電梯，也會(huì)導(dǎo)致電梯故障的頻發(fā)。例如：有些乘客在電梯內(nèi)亂扔煙頭等廢棄物、在按電梯的按鈕時(shí)過于用力、在按過按鈕的基礎(chǔ)上又反復(fù)按、將易燃易爆的物品攜帶入電梯、小孩子在電梯上蹦跳等等，都是導(dǎo)致電梯發(fā)生故障的人為因素。很多乘客雖然天天利用電梯，但是了解電梯故障的人甚少，而不按照正確的流程和方法操作電梯，縮短了電梯的壽命，甚至危機(jī)人身安全。5.未較好保養(yǎng)與維護(hù)管理
為了確保電梯在運(yùn)行過程中的持久、正常運(yùn)轉(zhuǎn)，安裝人員完成電梯安裝后，還應(yīng)定期對(duì)電梯進(jìn)行保養(yǎng)和維護(hù)。但是在實(shí)際運(yùn)行中，一些維護(hù)人員玩忽職守，使電梯“病入膏肓”，未能盡早處理故障，導(dǎo)致事故的嚴(yán)重發(fā)生，這是值得維護(hù)、保養(yǎng)工作人員深思的事情。電梯在長(zhǎng)期的運(yùn)行中因?yàn)椴煌脑虍a(chǎn)生了故障，如果帶“病”運(yùn)行，后果不堪設(shè)想。電梯是機(jī)械，機(jī)械是需要人工維護(hù)的。維護(hù)人員不僅工作上要嚴(yán)格，還應(yīng)具備高度的職業(yè)操守及專業(yè)技能和知識(shí)，這樣才能在
電梯產(chǎn)生問題、故障的初期找到故障，及時(shí)、正確地處理故障，才能從根本控制電梯運(yùn)行中的安全隱患。
二、電梯常見故障案例及處理
電梯的故障有很多種，只有經(jīng)過不斷地實(shí)踐，吸取經(jīng)驗(yàn)，才能真正掌握電梯故障的排除方法
以下列舉部分電梯常見故障案例，并提出了相應(yīng)快速的解決辦法： 1.電梯不能啟動(dòng)，樓層不顯示
故障原因分析:電梯失去了正常啟動(dòng)運(yùn)作的功能，與電氣控制系統(tǒng)中的電路功能有關(guān)，一般情況下，主控系統(tǒng)電路鎖梯功能打開、電源同路中出現(xiàn)電源故障、安全以及制動(dòng)同路中有短路情祝都可導(dǎo)致電梯不能正常啟動(dòng)運(yùn)行。
首先，對(duì)鎖梯開關(guān)位置進(jìn)行檢查，若電梯進(jìn)入鎖梯狀態(tài)，則恢復(fù)鎖梯開關(guān)電梯運(yùn)行即可恢復(fù)。
其次，要對(duì)控制柜內(nèi)的電源電路模塊進(jìn)行檢查，觀察各設(shè)備是否正常運(yùn)作，檢測(cè)供電壓是否正常，排查故障點(diǎn)，進(jìn)行維修。若一切正常，需對(duì)鎖梯功能和安全同路進(jìn)行驗(yàn)證。
第三，對(duì)安全制動(dòng)同路進(jìn)行檢查，控制柜內(nèi)安全接觸器是否吸合、安全同路反饋信號(hào)是否正常等，找到故障點(diǎn)，給予修復(fù)。
2.電梯運(yùn)行正常，但平層時(shí)誤差過大
故障原因分析:通過對(duì)電梯機(jī)械故障的原因及現(xiàn)象進(jìn)行分析，一般來講，平層裝置遮磁板位移、曳引輪繩槽磨損嚴(yán)重都是導(dǎo)致電梯平層精度出現(xiàn)誤差的因素。
首先，檢查平層裝置，若轎廂在多層出現(xiàn)同方向的平層誤差，則為平層傳感器位移故障，可根據(jù)誤差尺寸調(diào)整平層傳感器位置；如果只是某一層平層出現(xiàn)誤差，則為遮磁板位移故障，可根據(jù)不平層的誤差尺寸調(diào)整遮磁板位置。
然后對(duì)曳引輪繩槽磨損情況進(jìn)行檢查，如果在電梯運(yùn)行時(shí)曳引輪與鋼茲繩存在相對(duì)運(yùn)動(dòng)，則應(yīng)立即更換曳引輪。
三、討論
建筑行業(yè)在我國(guó)的興起速度是非常快的，其使用率也在不斷增加，以至于電梯故障的發(fā)生也日益增多。電梯故障日益增多，電梯出事率正逐漸增加?？傮w來
說，排除電梯故障的原則由簡(jiǎn)至難、從內(nèi)到外，具體如下：①環(huán)節(jié)排除法，電梯在正常運(yùn)行的過程中包括了停止再開門、減速運(yùn)行、開門啟動(dòng)、層數(shù)選擇等過程，一旦電梯出現(xiàn)故障，可對(duì)上述哪一環(huán)節(jié)出現(xiàn)的問題進(jìn)行有限考慮，為確定發(fā)生故障的詳細(xì)位置，對(duì)故障電梯逐層進(jìn)行檢查。②測(cè)量法，為確定電壓是否正常、檢查電流回路中顯露的連接狀況是否良好，當(dāng)將產(chǎn)生電梯故障的位置大致確定后，回路的檢測(cè)可利用萬用表，如果檢測(cè)結(jié)果出現(xiàn)異常，應(yīng)開展詳細(xì)的排查。③互換法，先替換存在故障的部位，替換后，如果故障部位恢復(fù)正常工作狀態(tài)，則故障產(chǎn)生于此處，但是替換后并未恢復(fù)，則可以判斷該部位未出現(xiàn)問題。本文針對(duì)電梯中出現(xiàn)的典型問題、故障，收集和歸納了快速處理的措施和方法，對(duì)提高維修速度以及安全運(yùn)行水平，防止事故的多發(fā)，具有一定的參考價(jià)值。
參考文獻(xiàn)：
[1] 王文, 錢江.電梯懸掛系統(tǒng)在建筑搖晃引起位移激勵(lì)下橫向振動(dòng)分析[J].振動(dòng)與沖擊, 2013, 32(7): 70-73.[2] 吳從曉, 周云, 吳從永, 等.高位層間隔震結(jié)構(gòu)電梯井核心筒剪力墻處理方法研究[J].振動(dòng)與沖擊, 2011, 30(10): 77-81.[3] 宗群, 趙占山, 商安娜.基于季節(jié)自回歸單整移動(dòng)平均模型的電梯交通流遞歸預(yù)測(cè)方法[J].天津大學(xué)學(xué)報(bào), 2008, 41(6): 653-659.[4] 楊琴, 袁玲玲, 梁紅艷, 等.基于改進(jìn)粒子群算法的電梯優(yōu)化調(diào)度研究[J].工業(yè)工程, 2013, 16(2).
點(diǎn)擊咨詢 