天天躁夜夜踩很很踩2022,久久国产精品99国产精,ā片在线观看免费看无码

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

久久99精品久久久久久琪琪,久久人人爽人人爽人人片亞洲,熟妇人妻无码中文字幕,亚洲精品无码久久久久久久

APG典型故障處理小結

第一篇：APG典型故障處理小結

第二篇：APG40故障處理小結

第三篇：近期典型故障處理情況通報

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

第五篇：電梯典型故障分析及處理方案

相關范文推薦

電梯典型故障分析及處理方案

燃氣輪機運行典型故障分析及其處理

故障處理及典型案例分析講義..

皮帶輸送機典型故障的分析及處理

攪拌站人員必備37個攪拌站典型故障問題處理

電梯典型故障分析及處理方案1

電梯典型故障分析及處理方案2

水電廠典型故障與事故處理練習題