Keeping Diagnostic Models Aligned With Equipment Changes

A correct model can be wrong for the equipment in front of you

A diagnostic model may have been carefully validated against the original design. That does not establish that it remains valid after a wiring change, a controller update or a different equipment option.

The reasoning can still be internally consistent while its assumptions no longer match the machine. A test might expect an output that the revised control logic should now withhold, or clear a dependency that the new design no longer uses.

Model validity belongs to a defined equipment configuration—not simply to a product name.

This article focuses on maintaining that alignment after changes. For the original relationship between drawings, functions and dependencies, see Why a Circuit Diagram Is Not a Diagnostic Model.

Separate equipment identity from diagnostic compatibility

Two units may look identical and still require different test conditions. Conversely, different asset numbers do not necessarily require different diagnostic structures.

Before deciding whether to reuse a model, separate three questions:

Question	Information to establish	Diagnostic significance
Which physical unit is being investigated?	Asset identity, location and relevant service history.	Observations must belong to the intended equipment.
Which configuration is installed?	Relevant hardware, software, options and modifications.	Dependencies, expected behavior and procedures must apply to that configuration.
Which diagnostic application is in use?	The model and runtime files selected for the investigation.	A revised source model does not help a technician still using an earlier generated copy.

This is a recommended engineering check, not a claim that iTech automatically detects every modification or verifies compatibility.

The iTech equipment-configurations guide describes creating instances from a model and storing unique or shared information through class properties. The model-instances guide describes almost identical equipment with variations such as performance or calibration.

Those capabilities support reuse. They do not establish that copying instance data is sufficient for a change to the underlying functional dependencies. Review whether the existing structure and tests still represent the changed equipment.

Review what the change means, not just which part number changed

A replacement with the same physical fit may alter the conditions under which a function works. A software change may alter diagnostic expectations without changing any wiring.

Use a change-impact review such as the following:

Change to investigate	Questions for the diagnostic review
New controller logic or firmware	Have command conditions, operating modes, interlocks or fault indications changed?
Revised wiring or an alternative supply path	Does each modeled dependency remain necessary? Could another path now produce the observed result?
Different sensor or calibration	Are the measurement method, units, tolerances and acceptance criteria still appropriate?
Added equipment option	Which functions and tests apply when the option is present or absent?
Revised access or repair procedure	Can the intended service team still collect the evidence and perform the authorized action?

These are general review questions, not an iTech feature list or a prescribed software migration process. Some changes may require only updated instance information; others may require revised model structure, tests or procedures. The decision needs engineering evidence.

For why dependency changes matter to inference, read What a Passing Test Really Tells You.

Worked example: a new condition for a cooling fan

Illustrative example only—not a customer installation or a recorded iTech session. A cooling fan originally runs whenever the equipment enters a specified operating mode. A validated test checks fan operation in that mode.

A later controller revision introduces an additional temperature condition. Below that condition, the controller intentionally leaves the fan off.

If the earlier procedure is used unchanged, a healthy revised unit may fail the old fan-operation check. The observation is real; the expectation is wrong for this configuration.

The review must establish:

1. Which units have the revised controller behavior.
2. When the fan should run under that behavior.
3. Which approved procedure can establish the required conditions.
4. Whether the modeled command dependencies and test interpretation still apply.
5. How the revised procedure and model will be checked before service use.

Do not simply widen a tolerance or label the fan good to make the discrepancy disappear. Resolve the mismatch between equipment behavior, test conditions and model assumptions.

The example is not permission to force a temperature condition, bypass an interlock or improvise a live test. Follow the equipment's approved safety and operating procedures. Where the required condition cannot safely be established, use an authorized alternative or record the limitation.

Keep observations attached to the correct instance

Even an appropriate model can receive the wrong evidence.

The iTech model-instances guide explicitly instructs the operator to select the correct instance before passing test results to it. The equipment/instance selector guide explains how the editor displays component data for the selected instance.

As a practical service check, confirm the physical unit and selected instance before entering observations. Record enough configuration and operating-state information to interpret those observations later.

A passing result from one unit does not establish the state of another. Likewise, an observation collected before a modification should not automatically be treated as proof of operation after it. Review whether the changed conditions invalidate the earlier conclusion.

These checks concern evidence handling. They are not a claim that iTech provides automatic asset discovery, configuration synchronization or an audit of every operator selection.

Revalidate the affected conclusions

The iTech model-validation guide calls for expert review of structure and tests, simulated troubleshooting using the runtime, and real-system validation where possible.

Apply those activities to the changed equipment and the conclusions that may be affected. Include unchanged behavior where shared dependencies create a plausible regression risk.

A useful validation record can include:

• The equipment configuration and diagnostic model being checked.
• The function, operating state and change under review.
• The expected observations for healthy operation and representative faults.
• The test results and diagnostic conclusions actually obtained.
• Cases where available tests must leave more than one candidate unresolved.
• The reviewer, limitations and approval for the intended service use.

This record is a recommended engineering practice, not a description of an automatic iTech change-management module.

Real-system fault testing must be controlled, authorized and safe. A simulated result can help check the model's reasoning, but it does not establish that a physical procedure is safe or that a measurement works on the actual unit.

Check the runtime copy, not only the edited model

The iTech runtime-file guide describes generating and downloading model files for use by the runtime. Editing a source model and having the intended files available to service personnel are therefore separate activities.

After an approved change, verify that the runtime files intended for use were generated from the reviewed model and checked in the appropriate runtime environment. Identify the configurations to which they apply and how service personnel will distinguish them from superseded copies.

Do not assume that editing the model automatically updates every downloaded copy. The cited guide describes file generation and download; it does not establish automatic distribution or synchronization.

Make alignment a condition of diagnostic use

Before relying on a diagnostic conclusion, ask:

1. Is this the intended physical unit and selected instance?
2. Does the model cover its installed configuration?
3. Do the procedures and expected results match its current behavior?
4. Have relevant changes been reviewed and validated?
5. Is the intended runtime copy actually being used?

If compatibility cannot be established, record the uncertainty and obtain the missing engineering information. Do not treat an unsupported model conclusion as sufficient evidence for a repair.

Maintaining a diagnostic model means maintaining the relationship between equipment, assumptions, tests and justified conclusions—not merely keeping a drawing or parts list current.

For the broader validation task, continue with Design for Testability: Finding Diagnostic Gaps Before Product Launch. To discuss diagnostic model maintenance for your equipment, request an iTech demonstration.