Resolve Switching Alarm

8/11/2019 Resolve Switching Alarm

1/8

Resolve Switching Alarm T036-G

NokiaS/W Revision : MS/!"R M#

$S S%

&M/NMS'000 T(0

!/W Revision : )*'00

&+,ective

To handle the switching alarm in systematical way and to understand the switching alarm behavior in eachfault group.

A+stract

This document describes the procedure of how to resolve switching alarms. Switching alarms are the alarmswhich are generated within the switching system. These alarms can be caused either by software faults (forexample, program block failures, incompatible or wrong data in the system data files) or can be caused byhardware faults (for example, plug in unit failure).

The surveillance engineer is responsible for repairing some of the faults. Faults like this involve, for instance,replacing the faulty program block or data file when software fault occurs. n case of hardware alarms, heneed to identify the failing plug!in unit. f a site visit is needed to replace a faulty plug!in unit, he should theninform the Field "aintenance personnel.

rere.isite

The alarm system handles the fault and disturbance observations occurring in the exchange. The alarmsystem is part of the exchange#s maintenance system. The supervision system detects the faults and reportsthem to the alarm system. $larms can be caused by both the hardware and the software. The alarm systemtries to specify the functional unit in which the fault or disturbance has occurred, whereupon recovery actions

can be activated for it. The user is informed of the fault situation by alarm printouts and lamp panel controls.The recovery system eliminates the effect of the fault by separating the faulty unit from the rest of the systemand, if possible, by replacing it with a back!up unit. %nce the fault has been eliminated, the fault diagnosis isactivated automatically. The fault diagnosis indicates the suspect plug!in unit.

&osition of alarm system in system maintenance of the exchange

$larm print!outs are divided into ' categories. These are notices (%T*), disturbance print!outs (+ST-),and failure print!outs ($$-").

From the user#s point of view, the most important information produced about alarms is the urgency level. t isoutput in connection with all alarms with the exception of notices. The urgency levels are/

+ocument o/ %0"!&1S234!T5'6!7!okia $S 0 okia onfidential -ev./$2 +ate/489529:: &age 49;


2/8


3/8



$S S%

&M/NMS'000 T(0


existent logical file, hardware configuration data not consistent with the actual physical hardwareconfiguration of the e=uipment, invalid &" configuration), then the detecting program block informs thealarm system about this and gives the identity of the failing data file. $n alarm is then generated and reportedby the alarm system.

7eneration of hardware alarms/

The alarm system also monitors the functioning of the hardware units in a +@255 switch. 3hen the alarmsystem detects an hardware fault, it tries to specify the functional unit in which the fault or disturbance hasoccurred, then informs the recovery system about the fault situation. The recovery system then automaticallyactivates the recovery actions on the failing unit. The user is informed of the fault situation by alarm printoutsand lamp panel controls. The recovery system eliminates the effect of the fault by separating the faulty unitfrom the rest of the system and, if possible, by replacing it with a back!up unit. %nce the fault has been

eliminated, the fault diagnosis is activated automatically on the failing functional unit. The fault diagnosisindicates the suspect plug!in unit within the functional unit.

Structure of alarm printout in +@255 systems/

+escription of the alarm printout fields/

4. Type of alarm printoutStandard alarm printoutD&+TE $larm update printout

2. *xchange dentification

'. -emote subscriber stage ( characters) &rinted only if the obGect of the alarm is in a remote subscriber stage.

The remote subscriber stage (-SS) is a system used in +@225 (Fixed ine switch). t refers to afunctional unit that is considered as an extension part of the Fixed ine switch. The -SS consist of

hardware units enclosed in its own cabinet frame and is located physically away from the Fixedine switch. The -SS is controlled remotely by the Fixed etwork Switch through aninterconnecting &" link.

The -SS is used only in +@245 and +@225 Fixed ine switches and is never used in +@2557S"9+S switches.

. omputer nit sending the alarm

H. $larm e=uipment type

+ocument o/ %0"!&1S234!T5'6!7!okia $S 0 okia onfidential -ev./$2 +ate/489529:: &age '9;


4/8



$S S%

&M/NMS'000 T(0


S3TC switching e=uipment%0" operation and maintenace e=uipmentT-$S" transmission e=uipment&%3*- power e=uipment*@T*- external e=uipmentnknown e=uipment type is printed as IIIIII

6. +ate and time Start time or termination time of the alarm Dyyyy!mm!ddE Dhh/mm/ssE

;. rgency level


5/8



$S S%

&M/NMS'000 T(0


4. Source information f the alarm is set before the start!up of the distributed part of the alarm system, this field displays

1.

4H. onsecutive number Failure printouts (


6/8



$S S%

&M/NMS'000 T(0


plug!in unit (in case of hardware alarms).

4. -esolving software alarms/

Software alarms are generated due to malfunctions in the execution of program block(s) or data file(s) ina computer unit of the exchange. Software alarms can be identified by looking at the supplementaryinformation fields of a specific alarm number in =uestion. The supplementary information field gives theidentity of the malfunctioning program block or data file.

4.4. 3hen the alarm is due to a software fault, identify the failing program block or data file. Thisinformation is contained in the supplementary information fields of the alarm printout. -efer to theSS M4Nor 1SM2N*+ +ocumentation (section >$larm -eference "anual?) for the alarm descriptionand interpretation of the supplementary information fields. The alarm description can be referenced

from the *+ +ocumentation by using the alarm number as the index to the >$larm -eference"anual?.

4.2. f the alarm description (from the >$larm -eference "anual?) mentions that a program block hadfailed, and that the failing program block is occuring on one of the winchester disk units, then replacethe faulty program block by copying from the other winchester disk unit. f the failing program block isoccuring on both winchester disk units, then replace the faulty program block by copying it from thefloppy diskettes. The floppy diskettes can be found from the respective Software -elease 1indersdelivered for each Software evel ("S "8 or 1S S;) M'NMN.

-efer to the *+ +ocumentation M4NM2N (section >ommand -eference "anual?) on how to copy files.ook for the description and syntax of the file copying commands ("" commands ZIWYand ZIBC).

4.'. f the alarm description (from the >$larm -eference "anual?) mentions that a data file had failed, andthat the failing data file is occuring to one of the winchester disk units, then replace the the faulty datafile by copying from the other winchester disk unit. f the failing data file is occuring on bothwinchester disk units, then correct the erroneous data within the file (for example, if the erroneousdata is a base station data, then it can be corrected by deleting and re!creating the base stationO ifthe erroneous data is hardware configuration data, it can be corrected by deleting non!existentfunctional units or adding functional units in accordance with the actual physical hardwareconfiguration).

-efer to the *+ +ocumentation M4NM2N (section >ommand -eference "anual?) on how to copy files.ook for the description and syntax of the file copying commands ("" commands ZIWYand ZIBC).

4.. $fter the replacement of the faulty program block or data file, verify whether the alarm previously

generated by the fault needs manual cancelling (see the cancelling instruction from the alarmdescription in the >$larm -eference "anual?) and manually cancel the alarm if necessary.

2. -esolving hardware alarms/

Cardware alarms are generated due to occurences of failure in plug!in unit(s) in the exchange. Cardwarealarms can be identified by looking at the supplementary information fields of a specific alarm number in=uestion. The supplementary information field gives the identity of the faulty plug!in unit.

2.4. 3hen the alarm is due to a hardware fault, identify the failing plug!in unit. This information iscontained in the supplementary information fields of the alarm printout. -efer to SS M4Nor 1SM2N



7/8



$S S%

&M/NMS'000 T(0


*+ +ocumentation (section >$larm -eference "anual?) for the alarm description and interpretationof the supplementary information fields. The alarm description can be referenced from the *++ocumentation by using the alarm number as the index to the >$larm -eference "anual?.

2.2. f the alarm description (from the >$larm -eference "anual?) cannot clearly specify the faulty plug!inunit, then refer to the printout of the diagnostic results on the failing unit. The diagnostic routine isautomatically activated by the recovery system when a fault is detected on a functional unit. Thediagnostic printout identifies the faulty plug!in unit within the failing functional unit. $dvise the Field"aintenance personnel to replace the faulty plug!in unit.

2.'. f the state of the functional unit is in T*!*@ or S*!%, then try changing its state either to 3%!*@or S&!*@ (if the functional unit is a spare unit). This will cause the unit to restart. $ny active alarm onthe unit will be temporarily cancelled during the restart. f the unit fails again after the restart, the

alarm is generated once more and the unit state goes to T*!*@ and then to S*!%. The Field"aintenance personnel then need to be informed to replace the faulty plug!in unit. The faulty plug!inunit can be identified from the supplementary information of the alarm printout.

-efer to the *+ +ocumentation M4NM2N(section >ommand -eference "anual?) on how to change thestate of the functional unit. ook for the unit state handling commands ("" commands ZUSC).

2.. $fter the replacement of the faulty plug!in unit, the alarms previously generated by the unit will beautomatically cancelled. For related alarms which does not cancel, verify whether the alarm needsmanual cancelling (see the cancelling instruction from the alarm description in the >$larm -eference"anual?) and manually cancel the alarm(s) if necessary.

Re1erence

M4N *+ +ocumentation ! "S 0 C- (software version "8).M2N *+ +ocumentation P 1S (software version S;).M'N "S 0 C- Software -elease 1inders (software version "8).MN 1S Software -elease 1inders (software version S;).

+ocument o/ %0"!&1S234!T5'6!7!okia $S 0 okia onfidential -ev./$2 +ate/489529:: &age ;9;


8/8



$S S%

&M/NMS'000 T(0


2ne

!


Documents

Resolve Switching Alarm