DGEMSC由于硬件故障而频繁发生自动小启，甚至大启。下面介绍一下在处理此故障过程中的一点经验。
此故障最早是出现“COMMON CHARGING OUTPUT ERROR”的告警，且是瞬时的，出了告警后很快又会消失。根据以往经验，出现这种告警经常是由于用于储存计费文件信息的几个SIZE如466，600和601的CHVIEW BLOCK出现拥塞引起的，于是要求值班人员扩这几个SIZE。很快值班人员反映这几个SIZE扩到最大了，但仍然偶尔有这个告警出现，可见问题不在SIZE拥塞上。
第二天，DGEMSC开始出现自动小启，原因为“PROGRAM HANDLING ERROR”，且重启的幅度很频繁，有时候会上升到自动大启甚至RELOAD。用SYELP指令查看，每次重启之前错误值都为0，结合SYRIP指令打印重启的EVENT LOG，可知重启是由于交换机的硬件错误引起的。
从DIRCP指令打印CP的EVENT LOG，可以看出RP1，5，6都有出错。根据爱立信工程师的建议，首先更换了POWC板（CP33的POWC板R2C一下都有隐患，许多时候硬件错误都是由于POWC板引起，而且POWC板也会参与处理RP到CP的信号），但是没有效果，CP仍然频繁的出现重启。
重新检查交换局的各种状态，偶然的用EXSLP指令检查IOG的LINK的状态，发觉SPG1的LINK1工作不稳定，有时是WO，有时是ABL，这一下就基本知道出现“COMMON CHARGING OUTPUT ERROR”告警的原因了。因为串行RP BUS是两边RP BUS轮流作为ACTIVE边的，二IOG的LINK实际上就是第一条RP BUS，当LINK1为主用边的时候，若ABL的时间过长就会影响计费文件的生成（此时计费文件存放在CP的内存中），从而出现告警。用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可以看出，每隔几秒就出现一次“CP-SP link disconnected”的告警。到此时，故障原因已经非常清楚了，是由于RP BUS的工作不稳定引起的，在CP中，负责RP BUS工作的有POWC，SPU和RPIRS板，首先更换SPU，更换后再用IMALP检查IOG的告警，仍然有上述告警出现。再更换第一块RPIRS板后问题仍然存在，可见问题不在CP上，所以需要更换IOG上RPV2，即IOG跟CP连接的RP。由于工作不稳定的是SPG1的LINK1，所以直接更换NODE B的RPV2板，更换后再查看LINK的状态和IOG的告警，状态正常，问题得到解决。从这次故障中，有以下几点经验值得总结：
在故障过程中，曾经由于无法生成计费文件而导致计费停止的故障，值班人员按照经验打开SPG0上的计费文件，但由于在打开前没有检查清楚，结果打开的仍然是SPG1上的TTFILE，然后再打开SPG0上的文件结果计费文件仍然无法生成，在把SPG1上的TTFILE全部关闭后才正常生成计费文件。根据以往的经验，同时打开两个TTFILE是可以正常生成计费信息的，从这次操作可以看出，同时打开三个TTFILE有可能导致不能正常生成计费信息。所以以后若出现SPG1故障要打开SPG0的TTFILE时，一定要确认清楚要打开的TTFILE是在SPG0上。
在知道故障原因是由于SPG1的LINK1不稳定造成时，应该及时人工闭塞这条LINK，这样做能避免CP的RESTART，当时有可能能够避免出现计费生成错误的告警，从而避免上文提到的计费停止的故障。
串行RP BUS中，一个简单的RP故障都很有可能影响到CP的稳定运行，这在以往的多次故障中都得到验证，必须加以重视。而在处理这次故障中，使用IMALP指令检查IOG的EVENT则是发现故障原因的重要工具，尤其是更换完硬件以后，我们无法即时判断CP是否仍然会发生重启，而从此EVENT LOG则可以即时发现CP与IOG的连接是否正常，从而判断更换硬件后故障是否消除。