DGEMSC由于硬件故障而頻繁發(fā)生自動小啟，甚至大啟。下面介紹一下在處理此故障過程中的一點經(jīng)驗。
此故障最早是出現(xiàn)“COMMON CHARGING OUTPUT ERROR”的告警，且是瞬時的，出了告警后很快又會消失。根據(jù)以往經(jīng)驗，出現(xiàn)這種告警經(jīng)常是由于用于儲存計費文件信息的幾個SIZE如466，600和601的CHVIEW BLOCK出現(xiàn)擁塞引起的，于是要求值班人員擴這幾個SIZE。很快值班人員反映這幾個SIZE擴到最大了，但仍然偶爾有這個告警出現(xiàn)，可見問題不在SIZE擁塞上。
第二天，DGEMSC開始出現(xiàn)自動小啟，原因為“PROGRAM HANDLING ERROR”，且重啟的幅度很頻繁，有時候會上升到自動大啟甚至RELOAD。用SYELP指令查看，每次重啟之前錯誤值都為0，結合SYRIP指令打印重啟的EVENT LOG，可知重啟是由于交換機的硬件錯誤引起的。
從DIRCP指令打印CP的EVENT LOG，可以看出RP1，5，6都有出錯。根據(jù)愛立信工程師的建議，首先更換了POWC板（CP33的POWC板R2C一下都有隱患，許多時候硬件錯誤都是由于POWC板引起，而且POWC板也會參與處理RP到CP的信號），但是沒有效果，CP仍然頻繁的出現(xiàn)重啟。
重新檢查交換局的各種狀態(tài)，偶然的用EXSLP指令檢查IOG的LINK的狀態(tài)，發(fā)覺SPG1的LINK1工作不穩(wěn)定，有時是WO，有時是ABL，這一下就基本知道出現(xiàn)“COMMON CHARGING OUTPUT ERROR”告警的原因了。因為串行RP BUS是兩邊RP BUS輪流作為ACTIVE邊的，二IOG的LINK實際上就是第一條RP BUS，當LINK1為主用邊的時候，若ABL的時間過長就會影響計費文件的生成（此時計費文件存放在CP的內存中），從而出現(xiàn)告警。用IMALP指令查看IOG的告警就完全證實這種推測：
IMMCT:SPG=1;
:IMALP:NODE=A,FRDATE=040724;
ORDERED
:END;
EXECUTED
< SPS EVENT LOG
SPGNODEFR DATEFR TIMETO DATETO TIMEMINCODMAXCOD
1 A2004-07-240000002004-08-112246231 9999
*** OBSERVATION O1/22004-07-28185313
IOP SLOGAN NOT DEFINED
CODESPGNODEUNITINFO
55071 ARPVDR.AC2RPV DUMP FAILED(4078)
ADD INFO:
Open main file error
*** OBSERVATION O1/22004-07-28185313
IOP SLOGAN NOT DEFINED
CODESPGNODEUNITINFO
55001 ARPVDR CP-SP link disconnected
ADD INFO:
TRANSCODE IDNO
04649
SENDER :
REGION NODE UNITIDNO
017RPVDR.AC2 4649
*** OBSERVATION O1/22004-07-28185426
IOP SLOGAN NOT DEFINED
CODESPGNODEUNITINFO
55001 ARPVDR CP-SP link disconnected
ADD INFO:
TRANSCODE IDNO
04636
SENDER :
REGION NODE UNITIDNO
017RPVDR.AC2 4636
*** OBSERVATION CEASINGO1/22004-07-28185433
IOP SLOGAN NOT DEFINED
CODESPGNODEUNITINFO
55001 ARPVDR CP-SP link connected
ADD INFO:
TRANSCODE IDNO
04668
SENDER :
REGION NODE UNITIDNO
017RPVDR.AC2 4668
*** OBSERVATION O1/22004-07-28185439
IOP SLOGAN NOT DEFINED
CODESPGNODEUNITINFO
55001 ARPVDR CP-SP link disconnected
ADD INFO:
TRANSCODE IDNO
04636
SENDER :
REGION NODE UNITIDNO
017RPVDR.AC2 4636
從以上的LOG可以看出，每隔幾秒就出現(xiàn)一次“CP-SP link disconnected”的告警。到此時，故障原因已經(jīng)非常清楚了，是由于RP BUS的工作不穩(wěn)定引起的，在CP中，負責RP BUS工作的有POWC，SPU和RPIRS板，首先更換SPU，更換后再用IMALP檢查IOG的告警，仍然有上述告警出現(xiàn)。再更換第一塊RPIRS板后問題仍然存在，可見問題不在CP上，所以需要更換IOG上RPV2，即IOG跟CP連接的RP。由于工作不穩(wěn)定的是SPG1的LINK1，所以直接更換NODE B的RPV2板，更換后再查看LINK的狀態(tài)和IOG的告警，狀態(tài)正常，問題得到解決。從這次故障中，有以下幾點經(jīng)驗值得總結：
在故障過程中，曾經(jīng)由于無法生成計費文件而導致計費停止的故障，值班人員按照經(jīng)驗打開SPG0上的計費文件，但由于在打開前沒有檢查清楚，結果打開的仍然是SPG1上的TTFILE，然后再打開SPG0上的文件結果計費文件仍然無法生成，在把SPG1上的TTFILE全部關閉后才正常生成計費文件。根據(jù)以往的經(jīng)驗，同時打開兩個TTFILE是可以正常生成計費信息的，從這次操作可以看出，同時打開三個TTFILE有可能導致不能正常生成計費信息。所以以后若出現(xiàn)SPG1故障要打開SPG0的TTFILE時，一定要確認清楚要打開的TTFILE是在SPG0上。
在知道故障原因是由于SPG1的LINK1不穩(wěn)定造成時，應該及時人工閉塞這條LINK，這樣做能避免CP的RESTART，當時有可能能夠避免出現(xiàn)計費生成錯誤的告警，從而避免上文提到的計費停止的故障。
串行RP BUS中，一個簡單的RP故障都很有可能影響到CP的穩(wěn)定運行，這在以往的多次故障中都得到驗證，必須加以重視。而在處理這次故障中，使用IMALP指令檢查IOG的EVENT則是發(fā)現(xiàn)故障原因的重要工具，尤其是更換完硬件以后，我們無法即時判斷CP是否仍然會發(fā)生重啟，而從此EVENT LOG則可以即時發(fā)現(xiàn)CP與IOG的連接是否正常，從而判斷更換硬件后故障是否消除。