Use a fault tree to separate power cable network and device causes

What you should be able to do

Organize possible causes of a low-voltage service fault into evidence-based branches. Distinguish what a test demonstrates from what remains unknown.

Scope

The poster is a qualitative troubleshooting tree, not a formal probabilistic reliability analysis. Its categories overlap and are not exhaustive. The fictional top event is “Camera C12 live view unavailable at workstation W1.” No live test, intrusive diagnostic or equipment substitution is authorized by this lesson.

1. Define The Top Event

The top event names the observed function. It does not say C12 lost power, the cable failed or the camera is defective. Those are potential explanations requiring evidence.

Confirm the time, conditions and affected client from the service record. A symptom reported by a user and a symptom personally observed by a technician are different evidence sources; label them. Identify what should occur under the approved operating requirements.

2. Open Four Investigation Branches

Power: What supplies the endpoint, and what evidence shows its state during the event? Relevant approved records might include allocation status, power faults and device restart history. Cable: Which physical path is actually involved? What inspection or suitable test evidence is available for that path? Network: What addressing, permitted communication path and application services are required? Which observations confirm or challenge those requirements? Device: What do endpoint health, boot state, stream settings and client behavior show? Include the viewing application rather than assuming only the camera can fail.

Cisco's Catalyst 9000 PoE troubleshooting guide distinguishes power and data symptoms and asks about scope, timing, device compatibility, available power and logs. [1] Those categories inform this exercise. Its platform-specific commands and intrusive recovery procedures are not general apprentice instructions.

3. Allow Causes To Cross Branches

A cable problem can affect both delivered power and data. A device configuration can interact with network policies. A shared switch can be involved in several branches. Do not force every cause into a single exclusive box.

The tree is a way to organize questions. It does not assign equal probabilities or establish which cause is most likely without evidence. If the situation suggests an omitted dependency, add it. A recording server, authentication service or software license might matter to a particular system even though the poster uses only four broad categories.

4. Understand The Limit Of Each Indicator

A permitted ping reply supports reachability for the tested exchange at that time. It does not demonstrate a working video stream, sufficient sustained performance or correct viewing permissions. A failed ping does not by itself prove a cable is open; the target or path may not permit that traffic.

A link indication does not demonstrate every cable performance requirement. A power allocation entry does not automatically establish endpoint operation through every transient. Read the manufacturer's meanings and the actual test boundaries rather than converting an indicator into a blanket pass.

Record “supported,” “contradicted” or “unknown” beside a specific hypothesis with its evidence. Avoid a broad statement such as “network good” when the only evidence is one response.

6. Control Substitutions

Suppose a supervised trainer works after a patch lead and port are changed together. That result does not isolate which change mattered. The changed setup also may have altered power negotiation, configuration or timing.

A controlled comparison should identify exactly what changed, what remained the same and the observation conditions. Even when a substitution points toward a component or connection, verify the interpretation before claiming root cause. An intermittent symptom might disappear during either test for unrelated reasons.

Protect the working services identified in lesson 462. A test intended to separate hypotheses should not create an unplanned outage elsewhere. Stop and escalate if the approved scope or recovery plan is inadequate.

7. Close With Evidence

Update the top-event record after an authorized correction and verify the intended service under the agreed conditions. Retain unresolved branches and limitations. An immediate recovery is not proof of long-term resolution.

Write a conclusion proportional to the evidence: “The live view returned after the approved mapping correction, and the specified verification passed” is more defensible than asserting a universal failure cause for every future outage.

Practice

Copy the four-branch tree. Add the fictional ping reply to the network evidence and mark video-stream function as still unverified. Write one next observation and explain which hypothesis it would help evaluate. Do not cross out the entire network or cable branch.

Knowledge Check

Sources

Worked through

A permitted ping to C12 replies while W1 shows no picture. Add the reply to the tree as evidence of that exchange, leaving video delivery unknown. Do not eliminate the network branch: stream transport, permissions or client behavior can differ from ping. The responsible technician chooses an authorized comparison of stream status or a second client because that result can distinguish a narrower hypothesis; repeated identical ping checks cannot establish video operation.

Where beginners go wrong