What Is Model-Based Diagnostics? A Practical Guide for Complex Systems

A symptom is the beginning of a diagnosis

A machine reports an abnormal condition. The operator can see what is wrong at the system level, but not necessarily which component caused it. A low-flow indication, for example, might originate in the power supply, a switching device, the pump itself, or the measurement path.

Model-based diagnostics uses a representation of the system together with observations and test results to identify explanations that remain consistent with the evidence. Rather than treating every symptom as a direct instruction to replace a part, it asks: which component states could produce these observations, and which test would distinguish between them?

The approach is useful when components depend on one another and a failure in one place can affect measurements somewhere else. It does not make the model complete, the sensors infallible, or the diagnosis automatically certain.

What the model represents

A diagnostic model describes relevant components, their functional relationships, and the behavior expected under stated operating conditions. Depending on the implementation, those relationships can be represented through dependency structures, rules, constraints, or more detailed behavioral models.

Three inputs matter:

• System knowledge: what supplies, controls, measures, or depends on what.
• Evidence: symptoms, operating state, observations, and completed tests.
• Assumptions: the model boundary, permitted failure modes, and whether single or multiple faults are considered.

A physical drawing alone is not enough. A connection needs diagnostic meaning: what should be observed if a component is working, and how could a failure influence a downstream test?

The foundational literature describes diagnosis in terms of a system description, observations, and assumptions about component behavior. Raymond Reiter's A Theory of Diagnosis from First Principles is one source for this consistency-based perspective. It is background theory, not a specification of every commercial diagnostic tool.

Worked example: a pump with no flow

Illustrative example, not a customer case or a measured iTech result. Consider a simplified pump system with three modeled groups: an upstream power path, a switched drive path, and a pump assembly.

For this example, assume that the inlet is clear, the flow measurement has been independently checked, the operating command is valid, and there is one persistent fault within those three groups. These assumptions deliberately make the example small; a real model must address other credible causes.

Evidence collected	Diagnostic interpretation under the stated assumptions
Expected flow is absent	All three groups remain plausible. The symptom alone does not isolate the fault.
The approved supply-output test passes under the specified operating load	The modeled supply failure is inconsistent with the evidence. The drive path and pump assembly remain candidates.
The approved pump-input test confirms the required electrical conditions during the command	The modeled drive-path failure is also inconsistent. Attention moves to the pump assembly.
The specified pump functional test fails despite valid inputs	The pump assembly is implicated at the resolution of this model. Its internal parts are not automatically distinguished.

Notice the difference between narrowing a candidate set and proving that every part of a component is healthy. Passing one test establishes only what that test can demonstrate under its conditions. A voltage observation taken under the wrong load, or a misleading flow sensor, could invalidate the reasoning.

All real tests must follow the equipment's approved procedures and applicable safety controls. The table is a reasoning example, not an instruction to conduct live electrical work.

From test results to the next decision

After each reliable result, the remaining candidate set can be updated. If several candidates remain, another test should provide useful discrimination between them.

Choosing a test is not only about information. Access time, required equipment, machine state, safety, and the consequences of disturbing a connector or replacing an assembly also matter. A short test is useful only if its result is trustworthy and changes the next decision.

Sometimes there is no available test that separates the candidates. The honest output is then an ambiguous diagnosis, not a falsely precise replacement instruction. Improving that situation may require a design change, a new measurement point, or a revised service procedure.

Build and maintain the model across the lifecycle

Start with the system boundary and the diagnostic questions the team needs to answer. Map the relevant functions and components, define tests and expected results, and connect the model to the actual hardware and software configuration.

Then validate it against representative evidence:

1. Confirm expected behavior for a healthy system.
2. Exercise representative failure conditions using safe, approved methods.
3. Check that the true modeled cause remains among the candidates.
4. Identify candidate groups that cannot yet be separated.
5. Investigate misleading measurements, unavailable tests, and unsupported conditions.
6. Repeat relevant checks when the product or its procedures change.

Failure analysis can supply useful inputs, but it must be translated into operational test knowledge. See turning FMECA into troubleshooting and finding testability gaps before launch.

Know the limits before relying on the answer

An omitted failure mode, an incorrect dependency, an intermittent fault, or an unmodeled operating state can undermine a diagnosis. Multiple faults may require different reasoning from a single-fault example. Human observations can also be uncertain or recorded incorrectly.

Useful diagnostic output therefore needs context: the evidence used, the assumptions in force, the unresolved candidates, and the conditions under which the conclusion applies. If the evidence conflicts with the model, investigate the conflict rather than forcing an answer.

For a related explanation, read why error codes are not enough to isolate a fault. To explore the approach in the context of your own equipment, see iTech's model-based technology or request a demonstration.