|
Faultfinding and trouble shooting are an essential skill for
the communications system engineer. As the systems become
more complex the methods required to locate a fault also become
more complex.
Whilst the basics of fault finding can be taught, the best
training is experience and resolution of real faults on existing
systems. Examples developed for training cannot fully incorporate
all the dynamics found in a live system.
This section is intended only as a guide to fault finding
and cannot be a comprehensive manual.
Before attending site check to see if that fault has been
seen on other examples of the system and if so what the resolution
was. There is no point re-discovering a known solution.
The maintenance engineer will require system manuals and a
tool kit appropriate to the system being examined. As a minimum
this should include a test telephone, multi-meter, line simulator
or network tester and IDC insertion tool. Comprehensive screwdriver
and pliers sets will also be useful. This is a smaller kit
than the installer would have since there will not usually
be a need to re-route or re-install large portions of the
system.
In addition to the tools the engineer will require a selection
of spare parts. These should be sufficient to enable
replacement of the major system components or be available
for immediate delivery from their stores should they be required.
The first step in the fault finding process is the verification
and location of the fault. This will entail a visit to site
to examine the fault first hand by a qualified engineer. Very
often the description of the fault will provide a clue to
the affected part of the system. In cases where there is no
clear indication then the following sequence should lead to
the fault being located and its cause identified.
The first item for examination when tracing a fault, especially
when working with a new system, is user operation. It is common
for the users to expect the features to be accessible in the
same way as their previous system.
Ask the users to demonstrate the fault and ensure that they
are using the correct operational process for the system.
Errors should be corrected and the customer informed of the
mistake then trained in the correct procedure.
If the system operation is correct then the investigation
must move on to the system itself.
If operation can be eliminated as the cause then the installation
is the next item to check. Begin by verifying the power supplies
and fuses, replacing any found to be faulty or in poor condition.
Next examine the wiring and connections, ensure that they
are correctly and securely connected. Move on to the IDF and
MDF connections.
The site records will be useful when they include the installation
records and notes.
If the fault cannot be traced to the operation or installation
of the equipment then system hardware will require
examination.
Begin with the CCU and check for any warning tell-tales indicating
a fault condition. Then work out from the CCU to all auxiliary
equipment connected to the system.
The order of checking is not important provided all equipment
is examined. It is usually easier to begin with the optional
equipment as this is usually fitted locally to the CCU. Then
check each of the incoming line ports or cards and the extensions
themselves.
In a large or busy system it will be necessary to wait for
a convenient time before the lines and extensions can be disconnected
for testing and further disruption should be kept to a minimum
during this procedure.
Hardware faults usually manifest themselves as an inconsistent
response to certain actions or conditions.
Assuming that the checks so far have revealed no problems
check the system software and the software of the auxiliary
equipment. Begin by ensuring that the most up to date versions
are installed. If old software is in use the updated versions
must be fitted as they may include a resolution to the problem
and manufacturers do not resolve faults on obsolete software
versions.
Next ensure that the system has been correctly programmed.
The programming records will be vital for this.
Software faults will usually be identified as an unexpected,
yet consistent, response to a certain set of actions or conditions.
 |
 |
|
