How a Vision System Follows a Process Change

A process change invalidates criteria that were correct yesterday, and the system will not say a word about it. It will keep judging to the old standard, confidently and incorrectly, and the verdicts will look exactly as they always did. This is the failure mode that makes change management matter more for vision than for most equipment: a machine that has been altered usually behaves differently and somebody notices, whereas an inspection criterion that no longer matches the process produces plausible output indefinitely. The fix is organisational rather than technical, and it rests on three practices: putting criteria inside the change process, versioning every change, and verifying against fixed samples afterwards.

What counts as a change

• Process change: a step added, removed or reordered, which usually invalidates sequence and presence criteria.
• Product change: a new variant, a revised part, a changed tolerance. The most common trigger and the most often missed.
• Equipment change: a new fixture, a moved camera, a replaced lamp or lens, a station relocated.
• Material change: a new supplier or a new incoming-material revision, which shifts the imaging conditions even when the process is identical.
• Software change: a threshold adjustment, a model update, a system upgrade — including changes made by the supplier from a distance.

Wiring criteria into the change process

Most plants already have an engineering change process, and the practical step is simply to add the vision system to its affected-items list. When a change notice is raised, it should trigger three questions: does this change affect any judgement criterion; does it affect the imaging conditions through material, appearance or layout; and does it require a new standard sample. Those three questions have clear answers and take minutes. Where the process does not exist, the minimum version is a short form: what changed, which criteria are affected, what was adjusted, when, by whom, and what evidence confirms the system still behaves. The last field is the one that gets dropped, and it is the one that matters — without it, a change and a subsequent problem cannot be linked. The process-change question connects directly to judging motion correctness, where criteria become invalid most often.

Verification after every change

Every change should be followed by a run of the fixed standard sample set, and the result should not be worse than before the change. This is cheap and it catches the two failure modes that follow changes. The first is over-correction: a threshold loosened to resolve one false alarm problem lets through a class of misses nobody intended to allow. The second is under-correction, where a change is made but not applied everywhere, leaving two stations judging to different standards. Both are invisible without a fixed reference, and both are expensive once they reach a customer. The standard sample set and its review cycle are described in model drift and recalibration.

Ownership and documentation

Two organisational questions decide whether any of this survives contact with a busy year. Who owns the criteria? If the answer is the supplier, every change needs a service call and the system drifts out of step with the process between them. If it is the plant, the plant needs the criteria in a form it can read and edit, with the supplier handling the underlying system. The second question is where the criteria live. If they exist only inside a supplier's configuration tool, then documentation, version history and audit become dependent on that tool, and a change of supplier becomes a serious problem. Keeping a written criterion list — what is judged, where the boundary sits, what the current version is — is a modest investment that keeps the system explicable for years. Support arrangements are covered in support and response terms.