Why a Circuit Diagram Is Not a Diagnostic Model

Connections are a starting point, not a complete explanation

An engineer has an accurate circuit diagram showing the controller, switching devices, wiring and actuator. Is that enough to build a diagnostic application?

It is valuable source material, but it is not the finished diagnostic model.

A circuit diagram shows how electrical elements are connected. Troubleshooting also requires an understanding of what those elements must do, under which conditions they must do it, and what a particular observation can establish about them.

Physical connectivity describes the arrangement. Functional behavior describes the required operation. Diagnostic dependencies describe the relationships that make test evidence useful.

These views support one another, but they are not interchangeable.

Three views of the same equipment

View	Main question	Typical information
Physical connectivity	What is connected to what?	Components, terminals, conductors, junctions and electrical paths.
Functional behavior	What must happen for the required function to work?	Inputs, outputs, commands, interlocks, operating modes and performance requirements.
Diagnostic dependencies	What must work for this observation to be valid, and what can we conclude from it?	Required functional relationships, test conditions, tolerances and the scope of supported conclusions.

A schematic may include substantial functional information, and an experienced engineer may infer behavior from it. The distinction is not that drawings contain no engineering knowledge. It is that a diagnostic application needs the relevant knowledge represented explicitly rather than left for the technician to reconstruct.

For the broader approach, see What Is Model-Based Diagnostics?.

Start with the function the technician needs to restore

A physical assembly can support several functions. A single function can depend on elements distributed across several assemblies.

For example, releasing a brake may require an operator command, appropriate safety conditions, controller logic, an output channel, switching devices and electrical power. Those dependencies do not necessarily fit neatly within one enclosure or one drawing sheet.

The iTech functional-breakdown guide starts with major equipment functions and breaks them into sub-functions before modeling the components that support them. Its brake-control example also considers which controller inputs influence the relevant output.

That is an important difference from simply reproducing the physical arrangement. The diagnostic question is not only “Which wire reaches this terminal?” It is also “Which conditions must be satisfied for this output to be expected?”

Software-controlled behavior matters here. A connection from a controller to an output does not, by itself, explain when the control software should activate that output.

Worked example: an actuator does not move

Illustrative example only—not a customer installation or a recorded iTech session. Consider an actuator controlled through a switching device. A controller issues the movement command only when the required operating mode and safety permissions are satisfied.

The circuit diagram identifies the electrical path. To interpret a failed movement test, the diagnostic model and procedure must also establish:

• Whether movement was requested in the correct operating mode.
• Whether the required permissions were satisfied.
• Whether the controller should therefore have produced the command.
• Whether the required supply and switching path were available.
• Whether the actuator's response met the specified requirement under the test conditions.

Suppose the switching device does not energize. If the controller has correctly withheld its command because a required permission is absent, that observation does not establish a faulty switching device.

Likewise, if a required input is bad, the actuator's lack of movement does not prove that the actuator itself is faulty. Its condition may remain indeterminate until suitable inputs or an approved alternative test allow it to be assessed.

The drawing helps locate the path. The functional relationships explain what should happen. The diagnostic dependencies determine which conclusions the available observations support.

All real-system testing must follow approved safety and operating procedures. An expected absence of a safety permission is not a reason to bypass an interlock.

A diagnostic link is a claim about dependence

Two elements being connected does not mean that every function of one depends on every function of the other.

A controller may have several outputs with different enabling conditions. Testing one output does not automatically establish the health of another. A shared supply can support several branches, but a passing test on one branch does not prove that every branch works under its required load.

Alternative paths need equal care. If a function can operate through either of two paths, a successful result does not establish that both paths are healthy.

Each diagnostic dependency therefore makes a substantive claim: the represented function requires another represented function under the relevant conditions.

Missing a genuine dependency can prevent useful inference and lead to unnecessary testing. Adding a dependency that is not genuinely required can support an incorrect conclusion, such as clearing an item that the test never exercised.

For the limits of upstream inference, read What a Passing Test Really Tells You.

Modeling structure is not the same as circuit topology

The iTech serial-and-parallel modeling guide explains that the way dependencies are represented affects what the diagnostic system can infer.

When a valid dependency chain is modeled, evidence about a downstream function can support conclusions about the functions it necessarily requires. Representing those same items without the dependency links loses that chained inference.

“Serial” and “parallel” in this modeling context should not simply be substituted for the electrical meanings of series and parallel wiring. The modeling decision concerns diagnostic relationships, not just the geometry or topology of a circuit.

The aim is to capture the dependencies that are both correct and useful. A more detailed model is not automatically a better one if its relationships cannot be justified or maintained.

Match the model to the available tests and repair boundaries

A drawing may show every internal component of a module. A field technician may be authorized only to test and replace the complete module.

That difference affects the useful diagnostic resolution. Modeling internal detail does not create access to internal test points, authorize component-level repairs or guarantee that the available evidence can distinguish every possible fault.

A practical diagnostic model needs to account for:

• The level at which faults can be distinguished with the available tests.
• The assemblies or components the service team can repair or replace.
• The access, equipment, setup and operating conditions needed for each test.
• The product configuration being investigated.
• The uncertainty that remains when two causes cannot be separated.

If the evidence supports only an assembly-level conclusion, the diagnostic result should not imply certainty about an untested internal component.

This connects modeling to design for testability: adding a useful measurement or improving access can make a distinction possible that no rearrangement of the existing model could establish.

Organize the model without losing cross-system relationships

Functions are often easier to understand when represented separately. But separating them must not erase dependencies between them.

The iTech virtual-links guide describes maintaining continuity across separately organized functions, such as controls, a controller and the equipment it operates.

This allows a model to remain readable without treating each functional group as independent. A link across groups preserves the relevant relationship; it does not represent an additional physical wire.

The same principle applies when reviewing a model against several drawings: page boundaries and assembly boundaries must not become accidental gaps in the diagnostic reasoning.

Validate the conclusions, not just the copied connections

Checking that component names and connections match the drawings is necessary, but it is not sufficient.

The iTech model-validation guide calls for expert review of model structure and tests, simulated troubleshooting sessions and real-system validation where possible. Any real-system fault testing must be controlled, authorized and safe.

A useful review asks:

1. Does the model represent the intended function and relevant configuration?
2. Are required inputs, software-controlled conditions and alternative paths represented appropriately?
3. Does each test have meaningful prerequisites, tolerances and outcomes?
4. Do passing and failing observations support the conclusions the model draws?
5. Does the diagnostic resolution match the evidence and the approved repair strategy?

The strongest check is not whether the model resembles the drawing. It is whether representative evidence leads to justified conclusions, including an explicit unresolved result when the available tests cannot isolate a fault.

Use the drawing as evidence, not as the finished model

Circuit diagrams remain essential engineering references. They help identify components, trace connections and verify the physical basis of the model.

The additional work is to make functional knowledge and diagnostic reasoning explicit: what depends on what, under which conditions, and what the available tests can actually establish.

A useful diagnostic model is not a redrawn circuit diagram. It is a validated representation of the dependencies and evidence needed to troubleshoot the equipment at a practical repair level.

For how those relationships guide the investigation after a symptom is selected, continue with How iTech Chooses the Next Best Test.