UNIT 3

CTSM
TROUBLESHOOTING STEPS
TROUBLESHOOTING STEPS

FAULT DIAGNOSIS TREE ------------

logs

Layman checks
Visual inspection

manuals

Tools s/w and h/w

FAULT FINDING AIDS
FAULT FINDING AIDS
FAULT FINDING AIDS
FAULT FINDING AIDS
VISUAL INSPECTION
 Visual inspection is a common method of quality control, data
acquisition, and data analysis.
 Visual Inspection, used in maintenance of facilities, mean
inspection of equipment and structures using either or all of raw
human senses such as vision, hearing, touch and smell and/or
any non-specialized inspection equipment.
VISUAL INSPECTION - ROLE
VISUAL INSPECTION – OPTICAL AIDS
VISUAL INSPECTION – OPTICAL AIDS
VISUAL INSPECTION - What to Look for ?
 In general terms we are inspecting the installation with regard to personal safety,
equipment age, deterioration, equipment corrosion and overload. Suitability and
external influence to the power system should also be included. At this point it is a good
idea to get from the client any documentation that is relevant to the installation (like
plans, drawings, previous test results and certification/if any, fuse charts and so on.
 The first part of a visual inspection is to ensure that the system is safe to test and that you
have enough information to be able to carry out the test safely. Eg:· Your first impression
will be important – has care been taken over the terminations of cables (neat and not
too much exposed conductor)?
 ·The type of power supply
 ·Are the seals broken on supply equipment? If they are it could indicate that the system has
been tampered with since it was first installed and perhaps closer investigation is required.
 · Are all cables terminated and all connections tight (no loose ends)?
 · Are there any signs of overheating?
 · Is there a mixture of protective devices?
 · Are there any rubber cables?
 · Are there any damaged cables (perished or cut)?
LAYMAN CHECKS

 Without Systematic approach some problems can be quickly

resolved by adopting few shortcuts. These are known as
"LAYMAN" checks. The LAYMAN check can be applied even by
non technical persons.
 The following list provides some important LAYMAN checks:-
 Is the Main AC power is on?
 Does the SMPS switch is on?
 Is SMPS fan working?
 Is SMPS connector properly connected on motherboard?
 Is AC power plug connected?
LAYMAN CHECKS

 Is the CMOS setup parameters correct?

 Is monitor contrast control in maximum?
 Is monitor brightness control in maximum?
 Is monitor power switch on?
 Is monitor cable to display adapter connected?
 Is monitor getting enough power?
 Is Hard disk connected?
ERROR LOGGING AND ITS USE
 An error log is a log of errors encountered by a system. There
are a number of different ways in which error logs can be used,
and they can be extremely useful tools for people who need to
diagnose and manage systems such as web servers, office
networks, and so forth.
 Accessing the error log may require special administrative
permissions which are designed as a security measure to
prevent unauthorized people from seeing documentation of
errors.
 Some error logs list every single error which occurs. Others may
be programmed to selectively save information about errors,
listing only certain error codes.
ERROR LOGGING AND ITS USE
 Each entry in the error log includes an error code, a time, and
may add other information such as an action someone was
trying to complete, someone's location, and whether or not the
error was resolved.
 The logs can be searched to identify specific patterns or errors
encountered by a particular user.
 The logs can also provide information about hacking attempts,
as hackers may cause errors on the server while they attempt
to compromise the system.
 Some systems will maintain an error log up to a certain number
of entries, while others archive logs so they can be consulted at
any time.
ERROR LOGGING AND ITS USE
 For systems like office networks, logs are used to keep track of
problems encountered by users and to try and determine what
causes these errors.
 An error log on an individual system or piece of equipment can
also be useful, especially if someone reports problems. By
viewing the log, a technician can get more information about
the problems encountered and what, exactly, happened. The
technician can resolve the error or provide the user with
information about where he or she went wrong.
TYPES OF ERROR LOGS
 Fatal/Critical: Overall application or system failure that
should be investigated immediately. Yes, wake up the
SysAdmin. Since we prefer our SysAdmins alert and
well-rested, this severity should be used very
infrequently. If it's happening daily and that's not a BFD,
it's lost it's meaning. Typically, a Fatal error only occurs
once in the process lifetime, so if the log file is tied to
the process, this is typically the last message in the log.
TYPES OF ERROR LOGS
 Error: Definitely a problem that should be investigated.
SysAdmin should be notified automatically, but doesn't
need to be dragged out of bed. By filtering a log to
look at errors and above you get an overview of error
frequency and can quickly identify the initiating failure
that might have resulted in a cascade of additional
errors. Tracking error rates as versus application usage
can yield useful quality metrics such as MTBF which can
be used to assess overall quality. For example, this
metric might help inform decisions about whether or
not another beta testing cycle is needed before a
release.
TYPES OF ERROR LOGS
 Warning: This MIGHT be problem, or might not. For
example, expected transient environmental conditions
such as short loss of network or database connectivity
should be logged as Warnings, not Errors. Viewing a log
filtered to show only warnings and errors may give
quick insight into early hints at the root cause of a
subsequent error. Warnings should be used sparingly so
that they don't become meaningless. For example, loss
of network access should be a warning or even an
error in a server application, but might be just an Info in
a desktop app designed for occassionally
disconnected laptop users.
TYPES OF ERROR LOGS
 Info: This is important information that should be logged
under normal conditions such as successful initialization,
services starting and stopping or successful completion
of significant transactions. Viewing a log showing Info
and above should give a quick overview of major state
changes in the process providing top-level context for
understanding any warnings or errors that also occur.
Don't have too many Info messages. We typically have
< 5% Info messages relative to Trace.
TYPES OF ERROR LOGS
 Trace: Trace is by far the most commonly used severity and
should provide context to understand the steps leading up to
errors and warnings. Having the right density of Trace messages
makes software much more maintainable but requires some
diligence because the value of individual Trace statements
may change over time as programs evolve. The best way to
achieve this is by getting the dev team in the habit of regularly
reviewing logs as a standard part of troubleshooting customer
reported issues. Encourage the team to prune out Trace
messages that no longer provide useful context and to add
messages where needed to understand the context of
subsequent messages. For example, it is often helpful to log
user input such as changing displays or tabs.
TYPES OF ERROR LOGS
 Debug: We consider Debug < Trace. The distinction being that
Debug messages are compiled out of Release builds. That said,
we discourage use of Debug messages. Allowing Debug
messages tends to lead to more and more Debug messages
being added and none ever removed. In time, this makes log
files almost useless because it's too hard to filter signal from
noise. That causes devs to not use the logs which continues the
death spiral. In contrast, constantly pruning Trace messages
encourages devs to use them which results in a virtuous spiral.
Also, this eliminates the possibility of bugs introduced because
of needed side-effects in debug code that isn't included in the
release build.