How iTech Diagnoses Faults It Has Never Seen Before

A new failure does not always require a new rule

An engineer encounters a fault that nobody on the service team has seen before. There is no matching entry in the fault history and no instruction saying, “If this exact symptom occurs, replace this part.”

That does not necessarily leave the engineer without a way forward. Knowing how the equipment is supposed to work provides another starting point: identify the dependencies required for the failed function, collect evidence, and work out which explanations remain possible.

iTech applies this approach through a diagnostic dependency model. Its logical foundation is knowledge of how the system works, rather than a requirement to have previously recorded every way it can fail.

“Previously unseen” needs an important qualification. A fault can be new to the service history while still affecting components and relationships already represented in the model. This is different from expecting the software to understand an entirely unmodeled component or physical effect.

Design knowledge gives observations meaning

A diagnostic model connects components, functions, inputs, outputs, and available tests. Those connections describe dependencies: what must be working for a particular result to occur?

For example, an actuator may depend on a valid control command, an available supply, a functioning drive stage, and an intact connection. If it does not move, the observation makes those dependencies relevant; it does not immediately prove that the actuator itself is faulty.

The model needs more than a list of connected parts. It must represent the diagnostic meaning of those connections and the conditions under which each test is valid. A physical circuit drawing, a functional overview, and a diagnostic model therefore serve different purposes.

The iTech diagnostic-logic guide describes the basic relationship between good inputs, good outputs, and component condition. Applied within a validated model, these relationships allow observations to support conclusions beyond the point directly tested.

Worked example: an actuator that will not move

This is an illustrative reasoning example, not a customer installation or a measured performance result. Assume a simplified system with one persistent fault in its modeled command, supply, drive, connection, or actuator groups. Its approved tests account for the relevant operating state and load interactions.

The first observation is that the actuator does not move when commanded. Several groups remain suspect.

1. A valid command-path test passes. Under this model's assumptions, the command fault is eliminated from the current explanation.
2. The approved supply test passes under the specified conditions. The relevant supply fault is also eliminated.
3. Further tests establish that the drive stage receives its required inputs, but its specified output test fails.

The evidence now implicates the drive stage at the resolution of this model. A downstream actuator receiving an invalid input is not automatically faulty; its behavior may simply reflect the upstream failure.

No historical case reading “actuator stopped because this drive failed” was needed to reach that conclusion. The dependencies and test results supplied the reasoning.

In a real application, missing interlocks, mechanical constraints, sensor errors, intermittent faults, or multiple failures could change the conclusion. The example is not a procedure for performing live electrical tests; actual work must follow approved equipment procedures and safety controls.

Where experience and expert rules still help

Model-based reasoning does not make experience irrelevant. iTech combines its logical core with additional sources of knowledge:

• Expert rules can introduce useful symptom information or shortcuts for familiar problems.
• Failure history can influence which remaining suspect areas deserve earlier investigation.
• Time or cost information helps choose between available tests and practical repair actions.

These functions answer different questions. The model establishes which explanations are consistent with the evidence. Experience helps make the investigation more efficient.

The rules documentation describes rules as useful additions for known problems, while the automated-learning documentation explains how previous failures can adapt the test pattern.

A component with a strong failure history is still a suspect, not a confirmed diagnosis. Reliable evidence can contradict the initial expectation.

Coverage comes from the model, not from the headline

The ability to investigate new incidents does not mean unlimited fault coverage. A useful model needs:

• The relevant components and dependencies.
• Correct operating conditions and equipment configuration.
• Tests that can distinguish the plausible causes.
• Clear interpretation of measured values and tolerances.
• Validation against representative healthy and faulty behavior.

If two causes produce indistinguishable available evidence, the result may remain an ambiguity group. If observations conflict with the model, the team should investigate the model, measurements, assumptions, and possible omitted causes rather than force a precise answer.

That is why designing for testability remains important even with sophisticated diagnostic reasoning.

Start with how it works, then improve with what fails

Design knowledge makes it possible to begin meaningful diagnosis before an exhaustive fault history exists. Operational experience can then refine the test strategy and identify improvements to the model and support procedures.

The practical distinction is between recognizing a previously recorded case and reasoning about a new incident using established dependencies. iTech's model-based foundation supports the latter, within the scope of the validated model.

For the broader introduction, read What Is Model-Based Diagnostics?. To explore how test evidence changes the investigation, continue with Model-Based Diagnostics vs Static Troubleshooting Trees.