第一篇：近期典型故障處理情況通報
近期典型網(wǎng)絡故障情況通報
近期處理網(wǎng)絡故障較多，綜合處理情況，現(xiàn)將幾起典型故障處理情況過程通報如下，請各縣市分公司能加強管理，提高維護人員的故障處理能力和責任心。
一、傳輸數(shù)據(jù)中心在對網(wǎng)絡例行檢查時發(fā)現(xiàn)營業(yè)部OA、CMNET、BOSS三網(wǎng)絡成環(huán)，結(jié)合營業(yè)部辦公樓近期故障較多的情況，安排中移代維人員進行集中查處，具體處理情況見（營業(yè)部環(huán)路分析報告）,從營業(yè)部代維人員的分析報告中可以看出幾點問題，請營業(yè)部要落實：（1）首先營業(yè)部二樓機房網(wǎng)線較亂，營業(yè)部是否安排人員對機柜進行整理，其它區(qū)域的機柜是否也有類似情況，應安排維護人員對所有的機房機柜進行檢查整改；（2）興馬（代理商）為什么會從營業(yè)部接入CMNET網(wǎng)絡，是否有相關部門的批準，興馬將BOSS與CMNET接入同一交換機，造成CMNET與BOSS成環(huán)，是自行接入還是公司維護人員接入的？網(wǎng)絡私接亂拉是否有相關的考核辦法；（3）舞陽十樓無營業(yè)部的相關部門，為什么會有BOSS和OA的網(wǎng)絡，請營業(yè)部清理相關的IP地址，對不需要使用的進行刪除。
二、建始分公司網(wǎng)絡成環(huán)影響到恩施分公司整個的OA及BOSS網(wǎng)運行情況，在建始分公司報故障的同時也有其它縣市報故障，為保證全網(wǎng)正常運行，傳輸數(shù)據(jù)中心按業(yè)務需求對相應的網(wǎng)絡隔離斷開連接，按照BOSS大于OA；OA大于CMNET的原則進行處理，請建始分公司結(jié)合本公司故障查詢情況加強區(qū)域管理，對工程建設情況造成的故障，指定隨工人員的管理。故障處理經(jīng)過見（7月8日建始環(huán)路故障報告）。
三、巴東分公司處理電視電話會議網(wǎng)絡不通的過程中，可發(fā)現(xiàn)以下幾個問題，請巴東分公司明確整改：（1）巴東分公司領取設備更換后能不能正常使用未進行測試；（2）在巴東需要視頻進行監(jiān)考前才聯(lián)系州公司說因設備故障不能使用，巴東分公司維護人員在設備到巴東和視頻監(jiān)考開始前這段時間在做什么，故障處理及時率在哪里？維護管理人員是如何安排的（3）巴東分公司視訊會議系統(tǒng)由技術支持中心維護，不能以沒有人處理（下鄉(xiāng)）為由。
結(jié)合以上幾個縣市分公司出現(xiàn)的問題，請各縣市加強網(wǎng)絡維護的管理，對私接亂拉的制定相應的考核機制；同時，要加強維護人員的責任心，對故障處理超時、找借口之類的情況實行問責制，對代維人員加強管理，提高代維人員故障處理能力；對于縣市分公司維護管理人員故障安排協(xié)調(diào)不力的情況進行通報。
第二篇：APG典型故障處理小結(jié)
APG典型故障處理小結(jié)
1、故障：intelligent networks management interface
分析：此告警表明文件系統(tǒng)在處理intelligent networks management interface（INM）接口連接時出錯。
此時有兩種情況：
1、ACTIVE CONNECTION FILE BUFFER表明緩沖區(qū)文件有誤；
2、INM LOG FILE 表明INM的LOG文件處理時出錯，此種情況比較常見，LOG FILE因為某些偶然原因被刪除后就會出現(xiàn)這種情況，例如有時LARGE RESTART或是RELOAD后丟失此子文件。
處理: 用指令ssmpi:sfn=n+1其中SFN:SUBFILE NAME。n為最后一個INMLOG中的子文件的數(shù)目，出現(xiàn)這種情況。APG40中可以用CPFLS-S指令直接查看INMLOG 中的子文件情況。
2、故障：APG40系統(tǒng)中文件無法傳到OSSDESTx的問題。
分析：多數(shù)此類告警都可以用指令CDHLS-L 查看所有路徑的OSSDESTx的傳輸類型和參數(shù)定義有否正確。大多數(shù)都不會有參數(shù)丟失的情況，然后用CDHVER 查看告警制定的OSS路徑的狀態(tài)是否OK,否則用指令CDHVER-M 人工修正使狀態(tài)變?yōu)檎?，消除告警?/p>
但是有的告警比較特殊例如:
AP FILE PROCESSING FAULT
CAUSE FILE TRANSFER FAILED TRANSFER QUEUE ALOG DESTINATION SET OSSDESTALOG Problem Data Transfer error 分析處理過程：先試著用以上常規(guī)的處理方法即以上指令來設法消除此告警：
1、用acease無法消除告警
2、cdhls-l OSSDESTALOG查看此路徑的所有傳輸參數(shù)，一切均正確。
3、用cdhver OSSDESTALOG看其狀態(tài)，結(jié)果顯示STATUS OK。
4、于是確認了本地交換機的設置沒有問題，懷疑是到OSS的網(wǎng)絡不通 但用指令ping 對端oss的IP, 顯示網(wǎng)絡路徑完全正常；后來注意到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的權限。綜上分析可以確定是對端網(wǎng)管的設置問題，導致ALOG文件無法正常傳送。所以聯(lián)系對端協(xié)助處理。
總結(jié)：此類問題可以從三方面來分析
1、本地設置和定義的參數(shù)。
2、網(wǎng)絡是否暢通。
3、對端的參數(shù)設置問題。
3．故障：APG40中CLUSTER 無法正常啟動的問題
分析：APG40中經(jīng)常出現(xiàn)AP1邊的CLUSTER服務無法正常加載啟動的問題，一般是當管理員改過普通用戶的帳號或者密碼時，或者系統(tǒng)升級的遺留問題時會出現(xiàn)。因為啟動CLUSTER需要帳號密碼的認證。
處理：在AP 模式下，用指令CLUSTER RES 查看具體服務ONLINE /OFFLINE的情況。一般情況下，可以用指令cluster res
如果整個CLUSTER無法加載,則查看ACTIVE或是PASSIVE邊NODE 的狀態(tài)就為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盤的屬性，發(fā)現(xiàn)C盤的剩余空間小于16%。處理辦法：C盤空間不足時可刪除的文件
1、C:acsdataFtpmktrbuild 該目錄存儲的是愛立信TR需要的logfile，可以完全刪除（一般可在提交給愛立信后即刻刪除）。
2、C:Temp 該目錄存儲的是windows NT系統(tǒng)的臨時文件，可以完全刪除。
3、C:WINNTsystem32logfilesMSFTPSVC1 C:WINNTsystem32logfilesMSFTPSVC2 C:WINNTsystem32logfilesMSFTPSVC3 該目錄存儲的是windows NT系統(tǒng)記錄的用戶登錄信息、安全事件信息等
logfiles，可刪除較舊的文件，建議至少保留一周之內(nèi)的文件，如實在空間不足，也可全部刪除。
4、C:acslogsfch 該目錄下如果有擴展名為.old的文件，形似：acs_fch_activity.old，為系統(tǒng)自動保留的舊版本文件，可刪除該.old文件。C:acslogsprc 該目錄下如果有擴展名為.old的文件，形似：ACS_PRC_error.old，為系統(tǒng)自動保留的舊版本文件，可刪除該.old文件。C:acslogsusa 該目錄下如果有擴展名為.old的文件，形似：usa.tmp.old，為系統(tǒng)自動保留的舊版本文件，可刪除該.old文件。C:acslogscore 該目錄下如果有擴展名為.unknown.x（其中x為一阿拉伯數(shù)字）的文件，形似：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掉后而引發(fā)的一系列告警。
解決辦法：當APG40 PRBOOT 或RESET時啟會出現(xiàn)此類的告警，當重啟成功后（大概五分鐘）故障會自動消除。如果沒有自動消除可以用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能正常聯(lián)機
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斷電后產(chǎn)生的告警，當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軌道電路紅光帶。經(jīng)電務部門處理，22時07分設備恢復正常，影響貨車1列。
（二）故障原因
因地方人員擅自在電纜徑路附近進行取土作業(yè)，挖斷信號電纜，造成3107G、3117G紅光帶故障。
（三）故障定性定責 公安機關偵破后認定追責。
（四）教訓及措施
1.襄陽電務段對工程開通后可能存在的安全隱患預想不足。此次電纜中斷地點在鐵路防護網(wǎng)外，襄陽電務段僅在電纜徑路上按要求設臵電纜標樁，未充分考慮地方上可能存在取土、挖溝等危及信號電纜安全的作業(yè)，未在防護網(wǎng)外的電纜徑路上設臵信號電纜安全警示牌。
2.電纜故障應急處臵預案還需優(yōu)化。部分司機對電纜中斷處所的道路交通線路不熟悉，工區(qū)職工對電纜應急接續(xù)操作不熟練。
3.要求襄陽電務段在全段范圍內(nèi)排查防護網(wǎng)外電纜敷設情況，對網(wǎng)外電纜徑路加設電纜安全防護警示牌。同時利用徒步檢查、添乘檢查等方式，加大電纜徑路的巡查力度，發(fā)現(xiàn)危及信號設備安全的情況及時果斷處臵。
4.優(yōu)化應急預案。特別是城鄉(xiāng)結(jié)合部道路交通圖的繪制要更加 1 精確，盡量減少故障處理的在途時間。同時要經(jīng)常性的組織開展電纜中斷應急演練，提高干部職工應急處臵水平。
二、2015年7月28日京廣高鐵 鄭武中繼18列控中心設備故障通報
（一）事故概況
7月28日，G70次運行至信陽電務段管內(nèi)孝感北至信陽東站間（中繼18）上行線K1039+068處，因ATP行車許可突降為零，觸發(fā)緊急制動停車，后自動恢復正常，17時43分發(fā)生，17時46分自動恢復，延時3分鐘，影響動車3列。
（二）事故原因
列控中心設備TM-425板通信故障造成。
（三）事故定性定責
設備器材不良，定北京和利時公司責任。
（四）教訓及措施
1.要求北京和利時公司進一步分析設備故障原因，采取有效措施，防止同類問題再發(fā)生。
2.信陽電務段加強對列控中心設備等新技術的業(yè)務培訓，熟練判斷處理設備故障。
三、2015年7月28日漢丹線陳家湖站11號道岔故障通報
（一）故障概況
7月28日18時17分,漢丹線陳家湖站11#道岔反位無表示，未影響正線行車，經(jīng)電務部門處理，21時53分設備恢復正常，影響貨車1列。
（二）故障原因
11#-X1（ZYJ7型液壓轉(zhuǎn)轍機）柱塞密封圈破損，導致道岔不能轉(zhuǎn)換。
（三）故障定性定責
設備器材不良，定北京鐵路局太原電務器材廠責任。
（四）教訓及措施
1.襄陽電務段風險研判不足。因柱塞密封圈材質(zhì)不良的故障在外局發(fā)生過，但襄陽電務段未吸取故障教訓，對此項安全風險的危害性認識不足，僅安排了部分道岔柱塞密封圈的抽查，未進行全面排查整治。
2.襄陽電務段組織對全部ZYJ7液壓轉(zhuǎn)轍機柱塞密封圈進行檢查、更換，聯(lián)系生產(chǎn)廠家對ZYJ7液壓轉(zhuǎn)轍機柱塞密封圈進行產(chǎn)品召回處理，杜絕此類故障的再次發(fā)生。
四、2015年7月28日焦柳線郜營站17/19號道岔故障
及機車信號顯示突變故障通報
（一）故障概況
7月28日19時32分，焦柳線郜營站17/19號道岔在列車通過時定位斷表示，造成通過列車機車信號由綠燈突變?yōu)殡p黃燈，列車停車后于19時37分正常發(fā)車，經(jīng)電務部門處理，于20時05分恢復正常，影響客車1列。
（二）故障原因
1.19號道岔B動壓力大，列車經(jīng)過時變形，頂起移位接觸器接點，切斷道岔表示電路。
2.列車壓入19DG（19號道岔所在區(qū)段）后，由于19號道岔斷表示，17/19DBJ落下，切斷SIIF-ZFS綠碼編碼電路，接通雙黃碼編碼電路，導致機車信號由綠燈突變?yōu)殡p黃燈，而司機看到前方地面 4768通過信號機顯示綠燈，故采取停車措施。列車進入4768G（S1LQG）后，正常接收到4768G發(fā)送的綠碼，停車后開車。
（三）故障定性定責
維修不良，定襄陽電務段責任故障。
（四）教訓及措施
1.道岔適應性調(diào)整工作落實存在差距，車間、工區(qū)對道岔特性掌握不足，導致適應性調(diào)整工作缺乏針對性。
2.車間干部對工區(qū)指導不夠。工區(qū)在道岔整治方面經(jīng)驗積累不足，反映出段、車間相關干部沒有給予足夠的關注和指導。
五、2015年7月28日滬蓉線枝江北站10/12號道岔故障通報
（一）故障概況
7月28日19時53分，枝江北站10/12#道岔定反位無表示，經(jīng)電務人員搶修于20時50分恢復，影響客車10列。
（二）故障原因
故障原因為10#-J1電機內(nèi)油泵組故障，造成轉(zhuǎn)轍機不動作。
（三）故障定性定責
設備器材不良，定北京鐵路局太原電務器材廠責任。
（四）教訓及措施
1.電務段7月30日會同太原電務器材廠分解電機進行原因分析。2.電務段舉一反三，加強對電機內(nèi)部的檢查，避免類似問題再次發(fā)生。
六、2015年7月29日滬蓉線利川站10號道岔故障通報
（一）故障概況
7月29日11時39分，利川站10#道岔定反位無表示，經(jīng)電務人 4 員搶修于12時23分恢復，影響客車3列。
（二）故障原因
故障原因為10#道岔J1與J2液壓轉(zhuǎn)轍機連接油管的冷壓接頭處漏油，導致道岔失去轉(zhuǎn)換動力。
（三）故障定性定責
設備器材不良，定北京鐵路局太原電務器材廠責任。
（四）教訓及措施
1.襄陽電務段會同太原電務器材廠對冷壓接頭質(zhì)量進行認真分析，提出整改措施。
2.襄陽電務段舉一反三，根據(jù)季節(jié)變化加強對液壓轉(zhuǎn)轍機油管路檢查，油管保護管包扎時開口朝外，便于日常巡視時檢查，避免類似問題再次發(fā)生。
七、2015年8月1日丹水池聯(lián)絡線丹水池站
電碼化故障通報
（一）故障概況
8月1日17時48分,丹水池聯(lián)絡線D296/7次運行至丹水池站XS進站信號機內(nèi)方后，司機反映收不到碼，17時54分，列車調(diào)度員發(fā)布命令改按LKJ行車，后續(xù)D3256/7次仍然反映收不到碼,發(fā)布命令改按LKJ行車，經(jīng)電務部門處理，于19時40分恢復，影響客車9列。
（二）故障原因
丹水池站機械室7排2架8層組合架側(cè)面04-17#萬可端子配線松脫，造成電碼化發(fā)送通道斷開。
（三）故障定性定責
維修不良，定武漢電務段責任。
（四）教訓及措施 1.灄口車間機械室設備巡視檢查不到位，未能及時發(fā)現(xiàn)配線松動的隱患并加以處臵，導致發(fā)生設備故障。
2.灄口車間應急處臵不到位，造成延時過長?，F(xiàn)場應急人員對站內(nèi)電碼化電路不熟悉，故障發(fā)生后一直以為故障點在3DG，未能及時判明故障范圍和原因。
3.灄口車間組織人員利用天窗點對丹水池站機械室組合架配線進行全面排查，發(fā)現(xiàn)問題及時處理，防止類似故障再次發(fā)生。
4.灄口車間由干部帶隊，對站內(nèi)電碼化電壓、電流等數(shù)據(jù)進行統(tǒng)一測試，制作成參考數(shù)據(jù)在分線盤等主要位臵進行標識，便于日常維護和故障處理。
電務處
二〇一五年八月三日
第四篇：愛立信基站典型故障處理案例[定稿]
愛立信基站典型故障處理案例
案例1：對基站進行IDB的配置總是無法完成，提示為時間超時。當對基站進行IDB數(shù)據(jù)的配置時，因為TRU與DXU軟件版本不一致，或BSC下載軟件的同時進行DXU數(shù)據(jù)配置而產(chǎn)生沖突，或第一次IDB配置電源電壓類型錯誤，或短時間內(nèi)頻繁的對DXU進行IDB配置等原因，偶爾可能導致再進行IDB的數(shù)據(jù)配置時，出現(xiàn)提示為時間超時而無法完成的現(xiàn)象。導致DXU同機架內(nèi)部的通信上存在異?，F(xiàn)象，出現(xiàn)類似機架掉死的現(xiàn)象，更換DXU無效。
解決的辦法是，將DXU（或新的DXU）放到同基站的其它機架上，或另外的基站上，僅對DXU加電，按照存在問題的機架配置進行IDB的重新配置，完成后再安裝到存在問題的機架上，不必再重新配置，對DXU等各模塊加電重起，即可解決問題。
案例2：RBS200基站工作不穩(wěn)定，經(jīng)常退服?；靖鞑考姆€(wěn)定工作離不開穩(wěn)定的時鐘信號，而基站的時鐘信號是從PCM傳輸中提取的，愛立信的基站不提供外部時鐘輸入的端口, RBS200基站是愛立信早期推出的GSM基站產(chǎn)品，這些基站設備是基于采用傳統(tǒng)的PDH傳輸組網(wǎng)方式而設計的，并不非常適用于SDH傳輸組網(wǎng)方式，這就會導致RBS200基站在和某些廠家的SDH傳輸設備配合使用時，導致基站工作不穩(wěn)定，頻繁出現(xiàn)時鐘同步的告警，經(jīng)常退服，嚴重影響了基站的正常運行。
解決辦法有兩種：一種是將RBS200基站使用的SDH傳輸更換為PDH傳輸；另一種是將RBS200基站設備更換為RBS2000基站設備，因為RBS2000對同步要求較RBS200低，能夠很好同SDH傳輸配合工作。
案例3：開始時，馬廠湖基站有部分TS總是無法正常工作，且不固定在某個載頻上，更換TRU、DXU無效，對基站的數(shù)據(jù)進行拆掉重新加載后仍無效，后來整個基站所有的TS均無法正常工作，基站硬件、傳輸、數(shù)據(jù)等均不存在問題。點檢查了基站的所有硬件均不存在故障現(xiàn)象，對懷疑有問題的TRU、DXU進行了更換；對傳輸進行了環(huán)路測量，也未發(fā)現(xiàn)傳輸電路存在質(zhì)量問題；檢查小區(qū)、基站的定義數(shù)據(jù)也都正常。懷疑基站的數(shù)據(jù)存在掉死的現(xiàn)象，但沒有確鑿的證據(jù)。嘗試用另外一種方法進行故障的定位。從BSC的ETC傳輸接口處，即ETRBLT板子2M接口處將馬廠湖基站的傳輸DIP=97同另外一個類似配置的基站裝載機廠的傳輸DIP=98直接進行互換，也就是說互相用對方基站的數(shù)據(jù)來開通基站?；Q后發(fā)現(xiàn)，馬廠湖基站的數(shù)據(jù)在裝載機廠基站上仍然存在同樣的問題，而裝載機廠基站的數(shù)據(jù)在馬廠湖基站上卻能正常工作。這就可以說明，馬廠湖基站的硬件、傳輸均不存在問題，基站數(shù)據(jù)確實存在掉死的現(xiàn)象。
在確認馬廠湖基站的數(shù)據(jù)存在掉死的情況后，重新定義了新的TG數(shù)據(jù)，來替換原先存在掉死現(xiàn)象的TG數(shù)據(jù)，整個基站恢復正常運行。
對上述基站數(shù)據(jù)掉死的解決辦法還有一種是進行BSC的重新啟動，因為需要在晚上進行，因此可能會導致基站退服的時間較長。
案例4：中國銀行基站第2小區(qū)對應的機架為2個CDU C，4個載頻配置，總是在4個載頻全部開起來后，又很快全部退服，現(xiàn)象為第1、2個TRU狀態(tài)為TX not enabled，第3、4個TRU為Fault燈和Operational燈同時亮。每次對DXU進行復位，總是出現(xiàn)上述的同樣現(xiàn)象，整個小區(qū)無法正常運行。
因為第3、4個TRU總是出現(xiàn)故障現(xiàn)象，將這兩個TRU更換，仍然出現(xiàn)同樣的故障現(xiàn)象；更換第3、4個TRU對應的第2個CDU C，仍然出現(xiàn)同樣的故障現(xiàn)象。將第3、4個TRU放到第5、6個TRU的位置上，將第2個CDU放到第3個CDU的位置，這樣載頻的位置為第1、2、5、6，甩開TRU第3、4位置不使用，整個小區(qū)正常運行，不再出現(xiàn)上述故障現(xiàn)象。
根據(jù)以上處理過程進行分析，應該是第2個CDU C對應的CDU BUS總線或第3、4個TRU對應的背板存在問題，導致第2個CDU C不能正常工作，不僅導致第3、4個TRU不能正常工作，而且導致整個小區(qū)不能正常工作。
將第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總線，就不會出現(xiàn)整個小區(qū)開不起來的現(xiàn)象。
案例5：沂水城東基站A小區(qū)擴容一個機架，由6載頻擴容為8載頻。在打開跳頻的情況下，A小區(qū)所有8個載頻的時隙全部正常工作后很快陸續(xù)全部退服，同時出現(xiàn)1A級的XBus Fault告警，但告警很快又消失。對基站A小區(qū)復位或閉解CF，仍然是同樣的故障現(xiàn)象。將A小區(qū)的跳頻關掉后可以正常運行。
針對出現(xiàn)的XBus Fault告警，重點檢查了新增擴的機架TRU和DXU背板跳點設置，CDU BUS的連接情況，均未發(fā)現(xiàn)異常，更換DXU也不能解決問題。考慮到當時是在上午忙時，此小區(qū)承擔的話務量很高，有可能是因為A小區(qū)重起時接入用戶太多導致負荷過高而不能以跳頻方式正常運行，設置A小區(qū)參數(shù)CB=YES禁止待機時手機接入，設置A小區(qū)為Layer=3小區(qū)限制其它小區(qū)手機用戶向A小區(qū)切換，這樣的參數(shù)設置曾經(jīng)解決過類似大容量小區(qū)在打開跳頻的情況下忙時重起困難的問題，但仍不能解決沂水城東A小區(qū)的問題。
懷疑新增擴的2個TRU雖然狀態(tài)顯示正常，但仍然可能存在問題，導致XBbus工作異常。由于A小區(qū)的主架的6個TRU和副架的2個TRU間已多次互相倒換位置來排除TRU的問題，已經(jīng)不能分清哪2個TRU是新增擴的。于是將A小區(qū)的所有8個載頻全部替換，問題解決?？偨Y(jié)：某個存在故障的TRU可以導致其背板連接的總線工作異常，在這個案例中，導致了XBus工作異常，小區(qū)不能打開跳頻，但是此TRU的狀態(tài)顯示完全正常。解決辦法是替換懷疑有問題的TRU，尤其是新增擴的TRU，不要采取在有問題的小區(qū)內(nèi)互相倒換的方式，因為存在故障的TRU無論在那個位置均可以導致同樣的故障現(xiàn)象。應該用其它小區(qū)或新帶來得TRU替換。
還有一個例子也是存在故障的TRU導致其背板連接的總線工作異常的情況：某小區(qū)新擴一個機架，載頻由6個擴容到7個，但是每次啟站時總是很快出現(xiàn)駐波比過高的基站告警，所有載頻全部退服，故障原因是新擴的TRU（在新擴的副架上）存在問題，雖然表面狀態(tài)均很正常，但是把它插到機框內(nèi)加電后，就會干擾背板總線的正常工作，導致出現(xiàn)整個小區(qū)駐波比過高的問題產(chǎn)生。
案例6：付莊基站為3個RBS2202機架級聯(lián)、4/4/4配置，故障現(xiàn)象為B小區(qū)退服，復位后B小區(qū)恢復正常，但幾小時后又再次退服，基站不存在任何告警。如此反復，B小區(qū)工作狀態(tài)很不穩(wěn)定。
因為是在基站運行中出現(xiàn)的故障，所以首先懷疑是B小區(qū)DXU出現(xiàn)故障，但是更換后仍無法解決。檢查B小區(qū)的射頻電纜、PCM傳輸電纜、CDU總線均無異常。通過OMT軟件監(jiān)測付莊基站3個機架DXU的PCM連接狀態(tài)均正常?？紤]到B小區(qū)是級聯(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é)：針對多機架級聯(lián)的基站，第2、3小區(qū)退服的情況，要考慮前一級級聯(lián)的小區(qū)所在的機架是否存在DXU故障、PCM傳輸電纜接錯、IDB數(shù)據(jù)中未定義PCM級聯(lián)等情況。
案例7：某個基站第2小區(qū)有3個時隙LMO狀態(tài)為0800，復位和更換載頻后無效。
檢查基站的定義數(shù)據(jù)，發(fā)現(xiàn)第2小區(qū)對應的TG-139，在定義半永久連接關系時，將RBLT-1309與DCP 28連接是錯誤的，導致DCP 28相對應的4個TS時隙，無法正常工作。應該是RBLT-1308與DCP 28連接，正確修改后，故障解除。類似的故障現(xiàn)象可能還有如下的故障原因：（1）某個基站第2小區(qū)4個時隙LMO狀態(tài)為0800復位和更換載頻無效：用DTIDP指令檢查DIP的定義數(shù)據(jù)，發(fā)現(xiàn)MODE=1是錯誤的。RBS200基站的DIP定義為MODE=1，即傳輸?shù)牡?6時隙僅用于傳信令，不用于傳話音。而此基站為RBS2000基站，正確的定義是MODE=0，如果定義為MODE=1，會導致DCP 16，即傳輸?shù)牡?6時隙不能正常使用，出現(xiàn)上述的故障現(xiàn)象，或者導致用戶占用時出現(xiàn)單通現(xiàn)象。
（2）某個基站第3小區(qū)2個時隙LMO狀態(tài)為0800，復位無效： 第3小區(qū)的2個時隙的故障原因是在定義基站數(shù)據(jù)時，MO CF的參數(shù)SIG=UNCONC錯誤，因為所有的TRX的SIG=CONC，導致TG分配的DCP不夠用。將MO CF的參數(shù)該為SIG=CONC，故障消除。
案例8：某個新建基站傳輸狀態(tài)正常，硬件也不存在問題，但基站開不起來 基站數(shù)據(jù)定義看起來不存在問題，其它檢查也做了很多，但基站仍然不能開起來。重點檢查基站DIP所連接的SNT的DEVICE數(shù)據(jù)定義，會發(fā)現(xiàn)RBLT的狀態(tài)不對，為MBL閉掉的狀態(tài)，試圖解閉，可能還會發(fā)現(xiàn)未完全定義，再用EXDAI、EXDUI指令進行補充定義，解閉此SNT所帶的RBLT，再重新LOAD基站數(shù)據(jù)后問題解決。對新建基站開不起來的情況，還有BSC側(cè)MO=RXOCF的TEI值與基站OMT軟件定義的不一致，導致基站無法同BSC建立聯(lián)系。此種情況較多的出現(xiàn)在級聯(lián)基站上，重新定義，使基站的TEI值同BSC側(cè)定義的TEI值一致便可解決問題。
案例9：盲?；敬嬖谒矓喱F(xiàn)象，導致信道完好率雖然很接近但達不到100%，同時基站傳輸設備也出現(xiàn)傳輸瞬斷的現(xiàn)象。
檢查基站硬件設備，及傳輸設備均未發(fā)現(xiàn)異常，更換DXU也無法解決問題。在基站上進行故障處理時，發(fā)現(xiàn)老式的愛立信開關電源存在模塊損壞的情況，但仍能正常工作。經(jīng)過長時間現(xiàn)場觀察，發(fā)現(xiàn)交流電壓不穩(wěn)定，忽高忽低，當電壓過高時，開關電源的過壓保護器便跳脫保護，愛立信開關電源所有的模塊處在過壓保護的狀態(tài)，同時傳輸設備瞬間復位，導致基站瞬斷。此時就發(fā)現(xiàn)了交流電壓過高可能是導致盲?；舅矓嗟脑?。經(jīng)過分析，老式的愛立信開關電源對交流電電壓波動范圍的適應性較差，當電壓過高超出其限定值時，開關電源的所有模塊出現(xiàn)瞬間的保護而導致其直流輸出電壓異常，從而導致傳輸設備因直流供電不能滿足要求而瞬間復位，導致愛立信基站瞬間退服。
將老式的愛立信開關電源更換為能適應寬范圍交流電壓波動的新式開關電源，問題解決，盲?；驹僖参闯霈F(xiàn)瞬斷的現(xià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成功，導致此基站開不起來。
首先全面檢查基站硬件、傳輸設備、傳輸電纜等均沒有發(fā)現(xiàn)問題，檢查柳行頭基站數(shù)據(jù)、小區(qū)數(shù)據(jù)定義也沒有發(fā)現(xiàn)問題，更換DXU也不能解決問題。
從BSC的ETC傳輸接口處將柳行頭基站的傳輸同另外一個相同配置且正在運行的松峰基站傳輸互換，不必改動任何數(shù)據(jù)，也就是說互相用對方基站的數(shù)據(jù)來開通。柳行頭基站的數(shù)據(jù)在松峰基站上運行正常，而松峰基站的數(shù)據(jù)卻無法在柳行頭基站上運行，這就可以說明柳行頭基站的數(shù)據(jù)不存在錯誤、掉死等異常情況，而從BSC到柳行頭基站的傳輸通路上存在問題，也可能是基站硬件存在問題（這已排除）。
這樣重點懷疑從BSC到柳行頭基站的傳輸通路上存在問題，需要仔細檢查，傳輸維護人員從BSC往基站方向一段一段進行檢查，果然發(fā)現(xiàn)在北園傳輸機房處柳行頭基站的傳輸跳線存在問題，120歐姆4根信號傳輸線中的一根與配線端子處在似接觸非接觸的狀態(tài)，重新卡接后，柳行頭基站CF軟件load成功，基站順利開通，問題解決。
需要注意的是，基站電路環(huán)路時是通的，并不能代表基站電路完全不存在問題，因為還存在類似上述傳輸信號線接觸不好、遠端告警等一些特殊的傳輸故障現(xiàn)象。
案例11：郵政局基站C小區(qū)擴容到主、副架共12個載頻，但是最多只能開起來10個載頻，總有2個載頻無論如何也開不起來，并且這2個開不起來的載頻位置不固定，狀態(tài)表現(xiàn)為僅Tx not enable燈亮。基站不存在告警。更換相應的載頻無效。仔細觀察開不起來的2個載頻的故障現(xiàn)象，發(fā)現(xiàn)總是某一個CU上的2個載頻同時出現(xiàn)開不起來的現(xiàn)象，雖然這個CU也不是固定的。將12個載頻中的某兩個位于同一個CU上的載頻TRX閉掉，其它10個載頻均能正常工作。
根據(jù)以上現(xiàn)象，考慮到愛立信基站載頻相互間發(fā)射部分TX和接收部分RX存在“借用現(xiàn)象”，即載頻A的RX（可能載頻A的TX存在問題）和載頻B的TX可以組成一個完整的正常工作的“載頻”，而載頻A的狀態(tài)可能為正常運行狀態(tài)，而載頻B的狀態(tài)為僅Tx not enable燈亮。
進一步從BSC上觀察郵政局基站C小區(qū)各MO的工作狀態(tài)，發(fā)現(xiàn)最后2個載頻的TX-11&&-12工作狀態(tài)開始時總是NOOP，過一段時間之后狀態(tài)變?yōu)镕AIL，但是考慮到最后2個載頻的TX發(fā)射部分可以借用另外2個載頻的TX發(fā)射部分，即存在TX的“借用現(xiàn)象”，因此狀態(tài)仍有可能是正常運行的。導致TX狀態(tài)為FAIL的原因有發(fā)射通路上的CDU存在問題，連接的天線駐波比過大，TX定義的連接小區(qū)錯誤，TRU的發(fā)射部分存在故障等原因。經(jīng)過排查，重點懷疑是最后2個載頻，即TRX-11&&-12對應連接的CU存在問題，雖然此CU的運行狀態(tài)正常，無故障燈指示。更換此CU后，郵政局C小區(qū)的12個載頻全部開起來，問題解決。這種類型的故障處理，不要被基站各硬件的運行狀態(tài)顯示所迷惑，可能狀態(tài)是正常的，但是也有可能存在問題，就像上面所講的CU的故障現(xiàn)象。
案例12：TX無法正常工作，基站告警為CDU output power limits exceeds 九期工程中，在開通西梁王基站（S2，2，2）時，發(fā)現(xiàn)雖然基站本測過程中,各MO 狀態(tài)正常,均無告警，但是在開站時,當TX打開后, B小區(qū)CDU的Fault 紅燈亮,，小區(qū)不能工作。我們通過OMT查尋告警，監(jiān)測到SO CF 2A:9 :CDU output power limits exceeds。首先我們懷疑天饋系統(tǒng)有問題,用駐波比測試儀測得DTF值1.08,SWR值1.19,均為正常值。隨后更換了CDU及TRU后故障仍未排除。最后我們根據(jù)TX的原理,輸出功率由前向及反向功率的比較得出的(Reference RBS2202),于是檢查對應的Pref,Pfwd饋線,發(fā)現(xiàn)標簽貼反,導致反向功率總大于前向功率，更改后故障消除。
案例13：基站存在SO CF 2A: Timing bus fault告警，TRU無法工作。建工大廈基站(S6,6,6,)在擴為（S8,6,6）時,A小區(qū)擴容的副柜TRU狀態(tài)不對,TRU的Fault在自檢后長亮。此時B,C小區(qū)已正常。用B,C小區(qū)的機柜帶A小區(qū)的副柜無問題,從而證明A小區(qū)的副柜本身無問題。通過OMT查尋告警，監(jiān)測到SO CF 2A: Timing bus fault。更換C5 BUS線后故障仍未排除，于是判定故障點應在A小區(qū)機柜本身之內(nèi)。根據(jù)OMT讀出告警，判斷故障為機柜內(nèi) BUS問題,更換后狀態(tài)正常，A小區(qū)正常工作。
案例14：PSU的排障方法
下面是滿配置的PSU與ECU的光纖連接示意圖： 在基站出現(xiàn)同PSU相關的告警后，到基站上觀察PSU的狀態(tài)，可能有如下兩種情況：第一種是PSU亮紅燈或不亮燈，第二種是PSU面板狀態(tài)正常但可能存在故障。針對第一種情況，首先檢查PSU的-48V直流（PSU-48）或230交流（PSU 230）輸入是否正常，可能存在輸入開關跳脫或熔絲熔斷的情況，如果排除上述情況，那么很可能是亮紅燈或不亮燈的PSU存在故障，進行更換確認。對更換后的新PSU，應該先加-48V直流或230交流輸入（下面的接頭），再連接直流輸出接頭（上面的接頭），否則容易導致新加的PSU因為直流電流倒灌的原因而再次損壞。針對第二種情況，使用逐個排除的方法來找出存在故障但面板顯示正常的PSU。滿配置的PSU數(shù)量一共是4個，與ECU通過光纖串聯(lián)在一起，形成一個環(huán)路。首先甩開左邊第1個PSU，將剩下的3個PSU同ECU通過光纖串形連接，再觀察基站的PSU相關告警是否消除，如果消除，則說明左邊第1個PSU存在故障，進行更換；如果故障仍未消除，可將左邊第2個PSU單獨甩開，將剩下的3個PSU同ECU通過光纖串形連接，需注意的是從左邊第1個PSU直接連接到第3個PSU的光纖需要換成長一點的光纖，再觀察基站的PSU相關告警是否消除，以此類推，逐個排查PSU。除了上述方法，類似的，還可采用每個PSU單獨同ECU串形連接，再觀察基站告警是否消除的方法，逐一進行排查。還有一點需要說明的是，基站對PSU的識別并不是完全根據(jù)PSU的安裝位置，例如最左邊的PSU被識別為PSU-0，向右依次為PSU-
1、PSU-
2、PSU-3，實際上并不是這樣的?；咀R別PSU是通過光纖環(huán)路來識別的，不在這個環(huán)上的PSU將不被識別，同時針對這個不在環(huán)上的PSU基站也不會產(chǎn)生告警。光纖環(huán)路連接最左邊的PSU被識別為PSU-0，然后依據(jù)光纖環(huán)路上的連接，向右依次識別為PSU-
1、PSU-2等，例如PSU-0，它的實際安裝位置可能是從最左邊數(shù)第3個PSU。
有一個故障現(xiàn)象是某個PSU的架頂-48V輸入接口因短路損壞嚴重，不能再使用，并且基站存在相應告警。消除告警的辦法是在PSU與ECU的光纖環(huán)路中，甩開這個損壞嚴重的架頂-48V輸入接口對應的PSU，再從IDB數(shù)據(jù)中刪除多余的PSU（損壞的接口對應的）即可消除告警。
第五篇：電梯典型故障分析及處理方案
電梯典型故障分析及處理方案
摘要：當今社會發(fā)展迅速，高層建筑早已走上時代舞臺，而高層建筑離不開電梯的使用，為了確保電梯的安全、有效運行，完善高層建筑功能，本文總結(jié)分析了時下一些典型電梯故障，并選出其中若干案例，提出了相應的處理方案。為有效的電梯監(jiān)測和高層建筑安全體防護提供一些建議和幫助。關鍵詞：排除故障；電氣系統(tǒng)；電梯故障
社會發(fā)展日新月異，如今電梯正廣泛應用在城市高層建筑當中，便于乘客或貨物的垂直運輸。由于其本身為運輸設備，具有機電一體化的特點，且需要微機監(jiān)控著它運行的系統(tǒng)，電梯運作往往需要軟件和硬件的交叉配合才能起到有效和安全的防護作用。但是，近年來，電梯故障日益增多，電梯出事率正逐漸增加，至此，電梯安全防護問題逐漸受到大家的關注。電梯在運行中所產(chǎn)生的故障主要來自于電氣控制系統(tǒng)，本文從此角度著手，就電梯典型故障展開探討，并提出了相應解決方案。
一、電梯典型故障原因及分析
電氣控制、機械、拖動回路等部分組成了電梯，因此，在查找故障時，應主要從以下幾個方面考慮。1.電氣控制系統(tǒng)故障
通常情況下，乘坐電梯舒適感降低，嚴重時造成人身傷害或設備事故等電梯無法正常工作的故障原因往往在于電氣控制系統(tǒng)，因電氣控制系統(tǒng)的內(nèi)部元件發(fā)生異常，產(chǎn)生故障。電梯的主要故障就來自于電氣系統(tǒng)故障。而電氣系統(tǒng)容易出現(xiàn)的故障包括：①自動關、開門，該故障也是最典型的電氣系統(tǒng)故障，因自動關、開電氣元件接觸不良，就造成無法順利開、關電梯門的故障。②破壞電氣元件絕緣，電梯在長期的運行中，電氣系統(tǒng)電子電氣元件會在老化、失效、受潮等變化中降低絕緣性能，當擊穿絕緣后，電氣系統(tǒng)就會發(fā)生斷路或短路的故障。③接觸點處元件發(fā)生斷路或短路，開關、繼電器、接觸器等若出現(xiàn)短路和斷路現(xiàn)象，失效電路，從而引發(fā)電梯故障。當塵埃阻斷接觸點時，斷路的情況就會出現(xiàn)；當電弧燒蝕接觸點時或者接觸點處電流偏大使，電路短路情況就會發(fā)生。2.機械系統(tǒng)故障
我們分別從以下兩點來看，第一，連接件松脫。在不間斷地、長期運行中，電梯因震動等原因?qū)е滤擅?、松動緊固件的現(xiàn)象，嚴重時，還會發(fā)生位移、滑脫等機械事故，加大部件之間的消耗、磨損，失去了原來的精度，最終導致電梯故障。第二，自然磨損。磨損是機械部件的運作過程中的必然現(xiàn)象，而一定程度的磨損會導致故障的產(chǎn)生，必須要更換新部件。所以，當大檢修電梯時，為了防范于未然，應及時更換容易出現(xiàn)磨損的部件。日常維修電梯時，必須注意保養(yǎng)與調(diào)整部分期間，才能確保電梯繼續(xù)正常、有序的運行。但是，部件磨損情況因滑動、滾動而產(chǎn)生，這就加速磨損機械，電梯故障也就不可避免了。例如：當磨損鋼絲繩達到一定程度后，為了防止發(fā)生安全事故，就需要及時將其更換。除了鋼絲繩，各種運轉(zhuǎn)軸承也必須定期更換，因為這些器件都是容易產(chǎn)生損耗、磨損的。3.主拖動系統(tǒng)故障
通過構(gòu)成主回路的各環(huán)節(jié)來檢查與排除電梯主拖動系統(tǒng)故障。主拖動系統(tǒng)并非連續(xù)的工作狀態(tài)，所以當經(jīng)過一段時間的電梯運行后，就會出現(xiàn)電機軸承磨損、接觸不良、接點脫落、觸電氧化、觸電彈片疲勞、擊穿或燒斷可控硅熱和逆變模塊等等，因此，可以從檢修與排查如上幾部分檢修與排查主拖動系統(tǒng)故障。4.使用不當
在日常生活中，未按運行要求使用電梯，也會導致電梯故障的頻發(fā)。例如：有些乘客在電梯內(nèi)亂扔煙頭等廢棄物、在按電梯的按鈕時過于用力、在按過按鈕的基礎上又反復按、將易燃易爆的物品攜帶入電梯、小孩子在電梯上蹦跳等等，都是導致電梯發(fā)生故障的人為因素。很多乘客雖然天天利用電梯，但是了解電梯故障的人甚少，而不按照正確的流程和方法操作電梯，縮短了電梯的壽命，甚至危機人身安全。5.未較好保養(yǎng)與維護管理
為了確保電梯在運行過程中的持久、正常運轉(zhuǎn)，安裝人員完成電梯安裝后，還應定期對電梯進行保養(yǎng)和維護。但是在實際運行中，一些維護人員玩忽職守，使電梯“病入膏肓”，未能盡早處理故障，導致事故的嚴重發(fā)生，這是值得維護、保養(yǎng)工作人員深思的事情。電梯在長期的運行中因為不同的原因產(chǎn)生了故障，如果帶“病”運行，后果不堪設想。電梯是機械，機械是需要人工維護的。維護人員不僅工作上要嚴格，還應具備高度的職業(yè)操守及專業(yè)技能和知識，這樣才能在
電梯產(chǎn)生問題、故障的初期找到故障，及時、正確地處理故障，才能從根本控制電梯運行中的安全隱患。
二、電梯常見故障案例及處理
電梯的故障有很多種，只有經(jīng)過不斷地實踐，吸取經(jīng)驗，才能真正掌握電梯故障的排除方法
以下列舉部分電梯常見故障案例，并提出了相應快速的解決辦法： 1.電梯不能啟動，樓層不顯示
故障原因分析:電梯失去了正常啟動運作的功能，與電氣控制系統(tǒng)中的電路功能有關，一般情況下，主控系統(tǒng)電路鎖梯功能打開、電源同路中出現(xiàn)電源故障、安全以及制動同路中有短路情祝都可導致電梯不能正常啟動運行。
首先，對鎖梯開關位置進行檢查，若電梯進入鎖梯狀態(tài)，則恢復鎖梯開關電梯運行即可恢復。
其次，要對控制柜內(nèi)的電源電路模塊進行檢查，觀察各設備是否正常運作，檢測供電壓是否正常，排查故障點，進行維修。若一切正常，需對鎖梯功能和安全同路進行驗證。
第三，對安全制動同路進行檢查，控制柜內(nèi)安全接觸器是否吸合、安全同路反饋信號是否正常等，找到故障點，給予修復。
2.電梯運行正常，但平層時誤差過大
故障原因分析:通過對電梯機械故障的原因及現(xiàn)象進行分析，一般來講，平層裝置遮磁板位移、曳引輪繩槽磨損嚴重都是導致電梯平層精度出現(xiàn)誤差的因素。
首先，檢查平層裝置，若轎廂在多層出現(xiàn)同方向的平層誤差，則為平層傳感器位移故障，可根據(jù)誤差尺寸調(diào)整平層傳感器位置；如果只是某一層平層出現(xiàn)誤差，則為遮磁板位移故障，可根據(jù)不平層的誤差尺寸調(diào)整遮磁板位置。
然后對曳引輪繩槽磨損情況進行檢查，如果在電梯運行時曳引輪與鋼茲繩存在相對運動，則應立即更換曳引輪。
三、討論
建筑行業(yè)在我國的興起速度是非?？斓?，其使用率也在不斷增加，以至于電梯故障的發(fā)生也日益增多。電梯故障日益增多，電梯出事率正逐漸增加。總體來
說，排除電梯故障的原則由簡至難、從內(nèi)到外，具體如下：①環(huán)節(jié)排除法，電梯在正常運行的過程中包括了停止再開門、減速運行、開門啟動、層數(shù)選擇等過程，一旦電梯出現(xiàn)故障，可對上述哪一環(huán)節(jié)出現(xiàn)的問題進行有限考慮，為確定發(fā)生故障的詳細位置，對故障電梯逐層進行檢查。②測量法，為確定電壓是否正常、檢查電流回路中顯露的連接狀況是否良好，當將產(chǎn)生電梯故障的位置大致確定后，回路的檢測可利用萬用表，如果檢測結(jié)果出現(xiàn)異常，應開展詳細的排查。③互換法，先替換存在故障的部位，替換后，如果故障部位恢復正常工作狀態(tài)，則故障產(chǎn)生于此處，但是替換后并未恢復，則可以判斷該部位未出現(xiàn)問題。本文針對電梯中出現(xiàn)的典型問題、故障，收集和歸納了快速處理的措施和方法，對提高維修速度以及安全運行水平，防止事故的多發(fā)，具有一定的參考價值。
參考文獻：
[1] 王文, 錢江.電梯懸掛系統(tǒng)在建筑搖晃引起位移激勵下橫向振動分析[J].振動與沖擊, 2013, 32(7): 70-73.[2] 吳從曉, 周云, 吳從永, 等.高位層間隔震結(jié)構(gòu)電梯井核心筒剪力墻處理方法研究[J].振動與沖擊, 2011, 30(10): 77-81.[3] 宗群, 趙占山, 商安娜.基于季節(jié)自回歸單整移動平均模型的電梯交通流遞歸預測方法[J].天津大學學報, 2008, 41(6): 653-659.[4] 楊琴, 袁玲玲, 梁紅艷, 等.基于改進粒子群算法的電梯優(yōu)化調(diào)度研究[J].工業(yè)工程, 2013, 16(2).
點擊咨詢 