Model-Based Diagnostics vs Static Troubleshooting Trees

Two ways to guide the same investigation

A troubleshooting tree and a diagnostic model can both help an engineer investigate a failure. Their difference is not that one asks questions and the other does not. It is how the next step is determined.

A static tree follows branches written in advance. A model-based strategy uses the current evidence and modeled dependencies to reassess the investigation.

This distinction affects more than the next test. It also affects how much work is needed to create the diagnostic system, how comprehensively it covers faults in complex equipment, and whether it is ready to support a new product before field failures have occurred.

What a static troubleshooting tree does well

A conventional tree might say:

1. Check the supply.
2. If the supply fails, follow the supply branch.
3. If it passes, check the control signal.
4. Follow the next predefined branch according to that result.

A static tree does respond to results: branching is its purpose. “Static” means that the available branches and their sequence were authored ahead of time, not that every incident follows one identical straight line.

For a small, less complex system with well-understood conditions, a troubleshooting tree can be relatively easy to build, clear, and effective. Prewritten procedures are also valuable where a particular action must occur in a fixed order.

The difficulty increases substantially for large, complex systems. Shared dependencies, multiple configurations, interacting symptoms, and alternative test opportunities create many situations that authors must anticipate, represent as branches, and validate.

Achieving comprehensive coverage this way requires much greater authoring and maintenance effort than representing the system's dependencies in a diagnostic model. In practice, the difficulty of writing every relevant route often leaves gaps and results in lower fault coverage. A tree can guide a technician through the situations its authors included; it cannot generate a missing diagnostic route simply because a new combination of symptoms appears.

How the model-based approach differs

An iTech diagnostic model represents the dependencies required for the equipment's functions. Test results change what is known about those dependencies and which components remain suspect.

After evidence is reported, the investigation can be reassessed rather than merely advanced to the next prewritten question.

The approach combines:

• Logical deduction from component relationships.
• Symptoms and optional expert rules.
• Optional failure-history information to improve test prioritization.
• Test and procedure time or cost.

The iTech technique guide describes next-best-test selection as combining probability, elimination of suspects, and time or cost. This is more than choosing the next box in a flowchart.

Fault coverage from the start of a new product launch

Troubleshooting trees are often built from failure history: faults already encountered, the symptoms they produced, and the steps that resolved them. This can be useful for established products, but a new product has little or no field-failure experience. A history-led tree may therefore start with limited coverage and expand as failures are encountered.

Not every tree is history-based; engineers can also write branches from design knowledge. For a large, complex system, however, they still face the effort of explicitly authoring the diagnostic routes needed to cover those potential faults.

iTech does not require prior failure experience to establish its model-based diagnostic capability. Its model describes how the product is intended to work and which dependencies each function requires. From that design knowledge and the available test evidence, it can investigate faults that have never previously occurred.

This makes model-based diagnostics particularly well suited to new product launches: a complete, validated diagnostic model can provide excellent fault coverage from the outset, rather than waiting for a catalogue of field failures to accumulate. Coverage depends on the completeness of the model and the available tests—not on having previously experienced each fault.

Failure history remains useful once the product is in service. It can improve test prioritization without being a prerequisite for structural diagnosis. See How iTech Diagnoses Faults It Has Never Seen Before.

Worked example: evidence arrives from another subsystem

Illustrative example only. Consider two controlled outputs that share a supply and part of a control path. One output works under a validated functional test, while the other fails.

A tree written only around the failed output might begin with a supply check unless its author included a branch for the companion output's result.

A dependency model can use the working output as evidence about the shared path, provided that the test actually demonstrates the required common functions under the relevant conditions. It can then focus on the dependencies specific to the failing output.

Now suppose a later test finds an invalid input to a downstream component. That component's failure to respond is not, by itself, evidence that it is broken. The model can distinguish the suspected upstream cause from the downstream behavior it produces.

The advantage is not a guarantee that every model-based investigation uses fewer tests. It is the ability to use relationships and accumulated evidence when deciding what remains worth testing.

A practical comparison

Question	Static troubleshooting tree	iTech model-based approach
Where is the diagnostic knowledge stored?	Mainly in authored questions, branches, and endpoints.	In modeled dependencies, tests, procedures, and supporting rules.
How does authoring effort change with complexity?	Relatively easy for small systems; much greater effort to create and validate comprehensive branches for large, complex systems.	Represent the system's dependencies and tests rather than prewrite every diagnostic route.
What limits fault coverage?	Unrepresented situations and missing branches; comprehensive coverage becomes difficult as complexity grows.	Missing or inaccurate modeled dependencies and tests that cannot distinguish the remaining suspects.
Is failure history required?	Often built around previously encountered failures, although design-based branches can also be authored.	No prior failure experience is required for structural diagnosis; history can improve prioritization.
How well does it support a new product launch?	A history-led tree begins with limited experience; broader coverage requires anticipating and authoring the missing routes.	A complete, validated model can provide excellent coverage from launch using design knowledge.
How is the next step chosen?	Follow the branch associated with the reported result.	Reassess the remaining suspects and available tests using the current evidence.
How is prior evidence handled?	Through branches or entry points designed to accommodate it.	Through the modeled interpretation of reported symptoms and test results.
How are changes maintained?	Review affected branches and procedures.	Review affected dependencies, configurations, tests, rules, and procedures.
What determines accuracy?	Correct and sufficiently complete branches and observations.	An accurate, validated model and reliable observations.

Neither approach escapes the need for maintenance. Model-based software does not automatically discover every design change or make invalid test results trustworthy.

Rules and fixed procedures still have a place

Dynamic diagnosis does not mean that everything must be optional or rearranged. Safety preparation, equipment isolation, calibration steps, and other required procedures retain their prescribed order.

iTech also supports expert rules that can specify tests to perform in sequence. Its rules documentation explains how these lists can guide testing and skip tests that already have a reported result.

The useful distinction is between an intentional procedural requirement and an unnecessary diagnostic sequence imposed merely because it was written first.

Choose according to the problem, not the label

A static tree may be sufficient—and relatively easy to create—for a small, stable system with a clear set of outcomes. For large, complex systems, the effort of anticipating and maintaining all the required branches can become prohibitive, leaving lower fault coverage.

A model-based approach addresses that scaling problem by representing design dependencies rather than prewriting every diagnostic route. Because it does not require prior failure experience, it is also particularly valuable at a new product launch, when comprehensive diagnostic support is needed but field-failure history does not yet exist.

Both should be judged on the same practical questions: can they retain the true cause among the candidates, distinguish those candidates using available tests, and guide a technician through a safe and usable process?

For the fundamentals, read the practical guide to model-based diagnostics. For the decision process behind an adaptive investigation, read How iTech Chooses the Next Best Test.