Machine Design #45: Engineering Change — What Must Be Rechecked When One Part Changes?

“It is only one small change” is one of the most dangerous sentences in an automation project. A sensor is replaced, a bracket is moved, a parameter is adjusted, or a software block is edited. The machine still appears to run, so the team closes the ticket. Later, a hidden dependency appears at FAT, in production, or during a safety review.

The real question is not how many parts changed. It is:

Which requirements, interfaces, risks, behaviors, evidence, and baselines could have changed because of this change?

Engineering change is a controlled reasoning process. The change request should make the current state, proposed state, impact, verification, deployment, and rollback visible. It does not need bureaucratic language, but it must be strong enough for another engineer to reproduce the decision.

1. Not every “repair” is the same kind of change

Temporary correction

A temporary correction restores operation while the permanent cause is investigated. Record the affected asset, temporary limit, owner, expiry, risk, and follow-up. A temporary workaround must not quietly become the new design baseline.

Permanent engineering change

A permanent change modifies the approved design, software, component, process, or documentation. It needs impact analysis, approval, implementation, and evidence appropriate to the changed scope.

Emergency change

An emergency change protects people, equipment, or production during an urgent event. Speed may compress the review, but it does not remove it. Capture the as-running state and reconcile the emergency action into a controlled baseline afterward.

2. A change request must describe current and proposed states

“Replace sensor X with sensor Y” is not enough. Write what exists now and what will exist after the change:

Item identity, revision, and asset.
Function and operating mode.
Mechanical, electrical, software, and interface boundaries.
Reason for change and known problem.
Proposed component or behavior.
Assumptions and constraints.
Affected documents and configuration items.
Expected benefit and possible new failure modes.

Without a clear before-and-after picture, impact analysis becomes an opinion about a part number.

3. Start from requirements, not from the part number

Ask which requirement the item supports. A proximity sensor may provide position confirmation, permissive logic, collision prevention, sequence timing, quality traceability, or a safety-related input. The same physical sensor can serve several obligations.

Map the requirement ID, acceptance criterion, operating conditions, and verification evidence. If the requirement is vague, the change is an opportunity to clarify it rather than copy the ambiguity into a new component.

4. Use a multi-domain impact map

Review the change across domains instead of checking only the obvious drawing.

Requirement and contract

Check performance, acceptance, customer commitments, applicable standards, and promised deliverables.

Mechanical

Check envelope, datum, stiffness, loads, wear, alignment, access, fasteners, guarding, and service tooling.

Electrical

Check voltage, current, wiring, connectors, protection, grounding, noise, heat, I/O type, and panel space.

Software and control

Check tag names, scaling, debounce, state logic, permissives, alarms, recipes, HMI prompts, diagnostics, and recovery.

Interface

Check upstream and downstream timing, handshake, ownership, data meaning, timeout, compatibility, and resynchronization.

Safety and risk

Check hazard exposure, safety function, diagnostic assumptions, stop behavior, restart, and required validation.

Quality and performance

Check cycle time, accuracy, repeatability, scrap, false rejects, traceability, and test samples.

Lifecycle

Check spare parts, obsolescence, supplier qualification, maintenance task, training, manuals, backup, and future support.

5. Direct, downstream, and shared impact

Direct impact

The changed item or the behavior immediately connected to it: mounting, wiring, parameter, code block, or test case.

Downstream impact

Functions that depend on the changed output: robot sequence, recipe, quality decision, alarm, data export, or operator workflow.

Shared impact

Resources used by several machines or products: a library, interface contract, standard component, safety function, calibration tool, or shared spare.

The change record should show which category applies. “No impact” is a conclusion that needs a reason, not a default checkbox.

6. Interfaces are where changes spread fastest

An interface change can alter signal polarity, state meaning, timing, timeout, ownership, error handling, or recovery. A sensor that changes from normally-open to normally-closed may be mechanically interchangeable yet break a permissive or diagnostic.

Review both sides of every boundary. Read the interface specification, sequence diagram, PLC state model, HMI instruction, and test case. If a supplier owns one side, obtain confirmation in a controlled record rather than relying on a phone call.

7. Classification routes the work; it does not replace impact analysis

Classify a change as minor, major, emergency, safety-related, supplier-driven, or documentation-only to select the review route. Classification does not prove the impact is small. A “minor” bracket can alter guarding or access; a “documentation-only” edit can reveal that the approved baseline is wrong.

Use classification to decide who must approve, which gates apply, and how fast the response is required. Keep the reasoning in the impact record.

8. A change plan needs implementation and rollback

The plan should identify the target asset, required tools, preconditions, backup, isolation, sequence, checks, owner, and communication. It should also state how to return to the previous known-good state if the new configuration fails.

Rollback may require the old software, device parameters, recipe, calibration, wiring, mechanical parts, or a controlled restore. “We can put it back” is not a rollback plan unless the prerequisites and time are known.

9. Direct verification, regression, and revalidation

Direct verification

Proves the changed requirement or behavior: inspect the new bracket, test the sensor distance, compile the revised code, or measure the new cycle time.

Regression

Checks existing behavior that could be disturbed by the change: adjacent sequence states, alarms, recipes, interfaces, restart, and normal/abnormal paths.

Revalidation

Confirms that the machine and process still meet the stakeholder need in the use context. It may include production trial, safety validation, customer acceptance, or a site workflow review.

A direct test can pass while a shared interface fails. Select all three routes where the impact justifies them.

10. Is the old test still valid?

Do not copy the previous test plan without review. Ask whether the test still covers the new component, condition, tolerance, failure mode, environment, and evidence. A test that measured the old sensor’s switching point may not verify the new sensor’s hysteresis, response time, or diagnostic behavior.

Retire obsolete steps, add missing cases, update samples and acceptance criteria, and record why a test remains applicable. Test validity is itself part of the change decision.

11. Choose regression scope using dependency

A practical scope has layers:

Changed item and direct function.
Same sequence and adjacent states.
Shared library, interface, or safety function.
Product variants, recipes, and operating modes.
Site integration and recovery behavior.

The wider the dependency, the stronger the case for regression. Do not use a fixed percentage of tests as a substitute for understanding the architecture.

12. Example: replacing a proximity sensor

Current function

The sensor confirms that a clamp is fully closed before motion. Its signal also feeds an alarm and a production trace event.

Direct comparison

Compare sensing distance, target material, mounting, connector, voltage, output type, response, hysteresis, environmental rating, and diagnostics.

Impact

Check clamp timing, permissive logic, false-close risk, alarm wording, trace timestamps, robot handshake, safety assumptions, spare identity, and the validation sample. The replacement is complete only when the required behavior and evidence are complete—not when the new part is physically installed.

13. A software change that compiles is not verified

Compile success proves syntax and tool compatibility. It does not prove sequence behavior, timing, state transitions, alarms, data, safety, or recovery. A software change needs a controlled build identity, deployment record, test result, and updated configuration baseline.

Review online edits and retained parameters separately. A project file can compile while the running controller still contains an older or tuned value.

14. A supplier change is not only procurement

When a supplier changes a component, resin, firmware, library, or manufacturing site, request the technical delta, qualification evidence, compatibility statement, obsolescence date, and affected documentation. Compare the new item against the requirement and as-running configuration.

Purchasing approval does not replace engineering approval. The machine owner must know whether the new item changes behavior, support, spare strategy, or validation.

15. Rollout across assets needs a compatibility plan

The same change may be safe on one asset and unsafe on another because of firmware, wiring, tooling, product mix, or installed options. Define the asset list, prerequisite versions, pilot order, rollback inventory, training, and post-deploy checks.

Do not update a fleet from a single unverified file. A fleet baseline must identify which assets received which release and evidence.

16. When is a change closed?

A change is not closed when the part is installed. Close it when the approved scope is implemented, direct and required regression tests pass, revalidation is complete where needed, deviations are owned, documents and configuration records are updated, operators and maintainers are informed, the new baseline is protected, and rollback or recovery evidence is available.

The change owner should sign the closure with links to evidence. Open assumptions must have an owner and due date rather than disappear into the notes.

17. Review effectiveness after deployment

Some changes pass the test but fail in real operation. After deployment, review the expected benefit, repeat failures, alarms, maintenance time, quality, downtime, and user feedback over an agreed period. If the result differs from the hypothesis, open a new corrective change instead of forcing the old record to look successful.

18. Configuration status accounting

Track proposed, approved, implemented, tested, deployed, documented, and closed states. Link each status to an asset, release, evidence, and deviation. This prevents the common condition where code changed but the drawing, manual, spare list, and training did not.

19. Engineering-change checklist

[ ] Current and proposed states are explicit.
[ ] The change is linked to requirements and acceptance criteria.
[ ] Mechanical, electrical, software, interface, safety, quality, and lifecycle impacts were reviewed.
[ ] Direct, downstream, and shared impacts are identified.
[ ] Classification selected the route but did not replace analysis.
[ ] Backup, implementation, verification, rollback, and communication are planned.
[ ] Direct verification and justified regression/revalidation are complete.
[ ] Test validity and sample conditions were reviewed.
[ ] Supplier and fleet compatibility were checked where applicable.
[ ] Baseline, documents, training, and status records were updated.
[ ] Effectiveness will be reviewed after deployment.

Conclusion

Engineering change is a system change even when the physical change is small. Start with the current and proposed states, trace the changed item to requirements and dependencies, examine interfaces and safety, select verification by impact, and close the loop through deployment, evidence, status accounting, and a protected baseline.

The discipline is not paperwork for its own sake. It is how MINATA keeps a machine understandable after years of repairs, supplier substitutions, online tuning, and production pressure.

References

ISO 10007:2017 — Guidelines for configuration management: https://www.iso.org/standard/70400.html
ISO 9001:2015 — Quality management systems: https://www.iso.org/standard/62085.html
ISO 12100:2010 — Risk assessment and risk reduction: https://www.iso.org/standard/51528.html

View all MINATA technical articles