Thiết kế máy #45: Thay đổi kỹ thuật (engineering change) — Sửa một chi tiết, phải kiểm tra lại những gì?

Một cảm biến tiệm cận (proximity sensor) ngừng bán. Đội dự án chọn model thay thế “cùng kích thước, cùng điện áp”, sửa BOM rồi cho rằng change đã xong.

Nhưng cảm biến (sensor) mới có:

Vùng phát hiện khác.
Connector khác orientation.
Response/filter khác.
đối tượng phát hiện (target) cũ nằm sát giới hạn.
phụ tùng dự phòng (spare) tại site chưa cập nhật.
Logic thời gian chờ (timeout) và diagnostic vẫn dựa trên behavior cũ.

Một thay đổi nhỏ ở danh mục mua hàng đã lan sang cơ khí, điện, phần mềm, maintenance và test.

thay đổi kỹ thuật (engineering change) không nên được đánh giá bằng số lượng dòng sửa. Nó cần được đánh giá bằng dependency và impact:

Change trigger → affected items/interfaces → yêu cầu (requirement)/risk impact → implementation → kiểm chứng (verification)/regression/thẩm định lại (revalidation) → deployment → baseline/status

Bài này trình bày cách kiểm soát change cho máy tự động theo hướng đủ chặt để bảo vệ chất lượng, an toàn và khả năng phục hồi, nhưng không biến mọi thay đổi thành một dự án khổng lồ.

1. Không phải mọi “sửa chữa” đều là cùng một loại change

Correction tạm thời

Mục tiêu là khôi phục operation nhanh trong phạm vi được phép:

Điều chỉnh parameter tạm.
Thay part tương đương đã được phê duyệt.
Workaround có thời hạn.

Correction tạm cần người phụ trách (owner), expiry/closure route và giới hạn áp dụng. Nó không tự động trở thành permanent baseline.

Permanent thay đổi kỹ thuật (engineering change)

Thay đổi được review, implement, verify và release:

Đổi component.
Sửa geometry.
Sửa sequence.
Thay cảnh báo (alarm)/recovery.
Thay giao diện kết nối (interface).
Thêm model.

Emergency change

Thay đổi gấp để xử lý sự cố hoặc risk cấp thời:

Authorization rút gọn theo quy trình.
Scope/rollback rõ.
Capture as-running.
Bắt buộc hậu kiểm và reconciliation.

Urgency có thể thay đổi thứ tự công việc, nhưng không xóa audit trail và thẩm định (validation) obligation.

2. Change request phải mô tả current state và proposed state

Một change request yếu:

Thay cảm biến (sensor) model mới.

Một change request hữu ích hơn có:

Change ID.
Trigger/reason.
Current state/baseline.
Proposed state.
Affected asset/model/site.
Desired outcome.
Urgency.
Requester/người phụ trách (owner).
Constraint.
Initial risk/impact hypothesis.
Evidence nguồn: lỗi thời (obsolescence) notice, defect data, field failure, customer request.

Nếu không biết current baseline, change analysis bắt đầu trên một nền không chắc chắn.

3. Bắt đầu từ yêu cầu (requirement), không bắt đầu từ part number

Trước khi hỏi “part mới có lắp vừa không”, hãy hỏi:

Component cũ đang thực hiện function nào?
yêu cầu (requirement) nào phụ thuộc?
Acceptance criterion nào đã được chứng minh?
dạng sai hỏng (failure mode) nào đã được phân tích?
giao diện kết nối (interface) nào đang dùng behavior của nó?

Ví dụ cảm biến (sensor):

Xác nhận presence hay seating?
Là quy trình (process) diagnostic hay an toàn (safety)-related input?
Dùng để start timer, cấp điều kiện cho phép (permissive) hay chỉ display?
Sensing margin bao nhiêu?
Response time ảnh hưởng sequence nào?
Maintenance có procedure adjustment nào?

Một replacement “tương đương” chỉ có nghĩa khi so theo function và yêu cầu (requirement) trong application.

4. Dùng impact map đa miền

yêu cầu (requirement) và contract

yêu cầu (requirement) có thay đổi không?
Scope/model/customer acceptance có bị ảnh hưởng không?
Assumption nào không còn đúng?
Cần approval từ ai?

Mechanical

Envelope, mounting, tolerance.
Load path, stiffness, wear.
Access và khả năng thay thế (replaceability).
Material/surface/environment.
Interference và clearance.

Electrical

Voltage/current/output.
Connector/pin/cable.
Protection/grounding.
Power budget.
Panel/terminal/I/O.

Software/control

I/O mapping.
Polarity.
Filter/debounce.
Scaling.
Timing/thời gian chờ (timeout).
Sequence/state.
cảnh báo (alarm)/diagnostic.
Data logging.

giao diện kết nối (interface)

Upstream/downstream trao đổi tín hiệu (handshake).
Robot/vision/bộ điều khiển logic lập trình (PLC)/giao diện người–máy (HMI).
Mechanical chuẩn định vị (datum).
Data schema/version.
Ownership và recovery.

an toàn (safety) và risk

mối nguy (hazard) hoặc exposure có thay đổi không?
Risk reduction measure bị ảnh hưởng không?
chức năng an toàn (safety function)/response time/diagnostic có đổi không?
đánh giá rủi ro (risk assessment) và thẩm định (validation) nào phải xem lại?

chất lượng (quality) và hiệu năng (performance)

Accuracy/repeatability.
Cycle time.
Yield/reject.
Product/model variation.
Measurement method.

Lifecycle

phụ tùng dự phòng (spare)/chi tiết hao mòn (wear parts).
Maintenance/training.
lỗi thời (obsolescence).
Supplier/lead time.
Tool/license dependency.
Drawings/BOM/manual.
bản sao lưu (backup)/mốc cấu hình chuẩn (configuration baseline).

Impact map giúp tránh tình trạng mỗi discipline chỉ review phần của mình.

5. Direct, downstream và shared impact

Direct impact

Item bị sửa trực tiếp:

cảm biến (sensor).
Bracket.
bộ điều khiển logic lập trình (PLC) logic.

Downstream impact

Consumer phụ thuộc:

thời gian chờ (timeout).
Robot điều kiện cho phép (permissive).
cảnh báo (alarm).
chất lượng (quality) decision.
Cycle time.

Shared impact

Phần dùng chung:

Function block.
Library.
Common công thức sản xuất (recipe).
Standard bracket.
Platform BOM.

Một sửa common library cho một trạm có thể ảnh hưởng nhiều máy/model. Regression scope phải xét reuse, không chỉ asset nơi bug được phát hiện.

6. giao diện kết nối (interface) là nơi change lan nhanh nhất

Một thay đổi cơ khí có thể ảnh hưởng:

cảm biến (sensor) đối tượng phát hiện (target).
Cable routing.
Robot point.
Vision field of view.
tấm chắn bảo vệ (guard) clearance.
Maintenance access.

Một thay đổi phần mềm có thể ảnh hưởng:

giao diện người–máy (HMI) message.
MES data.
Upstream/downstream thời gian chờ (timeout).
Recovery after communication loss.

Review giao diện kết nối (interface) nên hỏi:

Producer thay đổi output gì?
Consumer nào dùng output đó?
Contract/assumption của giao diện kết nối (interface) có đổi không?
Compatibility với phiên bản cũ thế nào?
Coexistence trong rollout có cần không?

7. Classification giúp route, không thay phân tích ảnh hưởng (impact analysis)

Tổ chức có thể phân class:

Standard/low-risk change.
Major change.
an toàn (safety)/security-related change.
Emergency change.

Classification hỗ trợ:

Approval authority.
Required reviewers.
Documentation.
Test depth.
Deployment control.

Nhưng nhãn “minor” không chứng minh impact nhỏ. Một dòng parameter có thể thay behavior critical; một bracket lớn có thể chỉ là cosmetic. Class phải dựa trên câu hỏi impact, không dựa trên effort coding.

8. Change plan cần implementation và rollback

Trước deploy, cần:

Item/version sẽ thay.
Asset/model/site.
Sequence implementation.
Precondition.
Required thời gian dừng máy (downtime).
bản sao lưu (backup)/baseline trước change.
Tool/phụ tùng dự phòng (spare)/personnel.
kiểm chứng (verification) steps.
Abort condition.
Rollback method.
Communication.

Rollback không chỉ là “download file cũ”. Với change cơ khí hoặc dữ liệu, rollback có thể cần:

Part cũ còn khả dụng.
khôi phục (restore) parameter/công thức sản xuất (recipe).
Recalibration.
Re-mastering.
thẩm định lại (revalidation).

Nếu rollback không khả thi, risk và approval route phải phản ánh điều đó.

9. Direct kiểm chứng (verification), regression và thẩm định lại (revalidation)

Direct kiểm chứng (verification)

Chứng minh item vừa thay đáp ứng yêu cầu (requirement) trực tiếp.

Ví dụ:

cảm biến (sensor) mới phát hiện đối tượng phát hiện (target) trong condition đã xác định.

Regression

Chứng minh các behavior đã từng đạt nhưng có dependency không bị hỏng.

Ví dụ:

Auto/manual mode.
cảnh báo (alarm)/recovery.
Model khác dùng common logic.
Robot điều kiện cho phép (permissive).
Cycle time.

thẩm định lại (revalidation)

Xác nhận system vẫn đáp ứng stakeholder need/use context và, khi liên quan, chức năng an toàn (safety function)/risk reduction.

Cần xem thẩm định lại (revalidation) khi:

Operating context đổi.
Intended use/ranh giới phạm vi (boundary) đổi.
mối nguy (hazard)/risk-control đổi.
User/workflow đổi.
an toàn (safety)-related part/function đổi.
Assumption nền của evidence cũ không còn đúng.

Không nên dùng một từ “kiểm tra lại (retest)” cho cả ba mà không nói mục tiêu.

10. Test cũ còn hiệu lực không?

Mỗi evidence dựa trên:

Configuration.
Precondition.
Tool/method.
Assumption.
Environment.
Model/material.

Sau change, hỏi:

hạng mục cấu hình (configuration item) nào trong evidence đã đổi?
Precondition/assumption còn đúng không?
Method vẫn đo đúng đặc tính không?
Sample/test data còn đại diện không?
giao diện kết nối (interface) version có tương thích không?

Evidence không hết hạn chỉ vì thời gian; nó mất hiệu lực khi nền tảng chứng minh bị thay đổi.

11. Chọn regression scope bằng dependency

Một decision tree:

yêu cầu (requirement) nào bị tác động?
Item/giao diện kết nối (interface) nào đổi trực tiếp?
Consumer/downstream nào phụ thuộc?
Common component/library/model nào dùng chung?
mối nguy (hazard)/an toàn (safety)/security nào có thể đổi?
Evidence cũ nào dựa trên phần vừa thay?
Mode, model, site nào cần đại diện?
Direct test, regression và thẩm định lại (revalidation) nào cần?

Mục tiêu không phải test lại toàn máy theo thói quen. Mục tiêu là không bỏ sót behavior có dependency.

12. Ví dụ: thay cảm biến tiệm cận (proximity sensor)

Current function

Xác nhận cơ cấu đã đạt vị trí trước khi cấp điều kiện cho phép của quy trình (process permissive).

Direct comparison

Sensing principle/range.
đối tượng phát hiện (target) material/geometry.
Mounting và adjustment.
Electrical output/connector.
Response/filter.
Environment/rating.

Impact

Mechanical

Bracket và đối tượng phát hiện (target).
Tolerance/margin.
Access adjustment.

Electrical

Wiring/pin.
I/O compatibility.

Control

Polarity.
Debounce.
thời gian chờ (timeout).
tính hợp lý (plausibility).

Diagnostics

cảnh báo (alarm) wording.
cảnh báo đầu tiên (first-out)/context.

Maintenance

phụ tùng dự phòng (spare).
Replacement/adjustment procedure.

Documentation

BOM.
Drawing.
I/O list.
Manual.

Test

ranh giới phạm vi (boundary) position.
All affected modes/models.
Failure/thời gian chờ (timeout).
Recovery.
Cycle behavior.

Nếu input ảnh hưởng an toàn (safety)-related function, change phải được route qua an toàn (safety) analysis và thẩm định lại (revalidation) phù hợp; không coi là replacement quy trình (process) cảm biến (sensor) bình thường.

13. Software change: compile pass chưa phải kiểm chứng (verification)

Compile/build success chỉ chứng minh một phần:

Syntax/type/dependency phù hợp.

Nó không chứng minh:

Sequence đúng.
Timing đúng.
cảnh báo (alarm)/recovery đúng.
giao diện kết nối (interface) tương thích.
Runtime parameter đúng.
Machine behavior đúng.

Software change cần:

Code review phù hợp.
Unit/simulation khi khả thi.
tích hợp (integration) test.
Representative machine test.
Regression theo dependency.
Deployment/as-running evidence.

Online edit phải được reconcile về source và baseline.

14. Supplier change không chỉ là procurement

Supplier thay vật liệu, quy trình (process), firmware hoặc subcomponent có thể ảnh hưởng:

Fit/function.
Reliability.
Surface/friction.
Calibration.
EMC/electrical behavior.
Certificate/document.
phụ tùng dự phòng (spare) interchangeability.

Change notification cần được route tới engineering người phụ trách (owner). “Cùng part number” không luôn đồng nghĩa configuration behavior không đổi.

15. Rollout nhiều asset cần compatibility plan

Nếu có nhiều machine:

Tất cả nâng cùng lúc?
Phiên bản cũ và mới có coexist không?
giao diện người–máy (HMI)/bộ điều khiển logic lập trình (PLC)/robot version matrix?
phụ tùng dự phòng (spare) dùng chung?
Training/document khác nhau?
Data/giao diện kết nối (interface) backward compatible?
Asset nào đã deploy?

Status accounting phải theo asset. Không nên ghi “đã update line” khi mới hoàn thành một máy.

16. Đóng change khi nào?

Không đóng chỉ vì source đã sửa.

Definition of done có thể gồm:

phân tích ảnh hưởng (impact analysis) approved.
Implementation complete.
Direct kiểm chứng (verification) pass.
Regression/thẩm định lại (revalidation) theo scope pass.
điểm sai lệch (deviation) xử lý.
Deployed đúng asset.
As-running captured/compared.
Drawings/BOM/manual/test updated.
Baseline release.
phụ tùng dự phòng (spare)/training/maintenance updated.
Effectiveness review scheduled hoặc completed khi cần.

Change không hoàn tất nếu field asset vẫn chạy phiên bản khác mà status không rõ.

17. Effectiveness review sau deploy

Một change pass test vẫn có thể không đạt mục tiêu dài hạn.

Theo dõi:

Defect có tái diễn không?
cảnh báo (alarm)/thời gian dừng máy (downtime) có giảm không?
Có dạng sai hỏng (failure mode) mới không?
Maintenance time thay đổi không?
chất lượng (quality)/cycle bị ảnh hưởng không?
Operator có workaround mới không?

Effectiveness criterion nên được xác định trước khi change được phê duyệt, không chỉ nhìn dữ liệu thuận lợi sau đó.

18. Configuration status accounting

Một bảng gọn:

Change	Approved	Source updated	Released	Deployed asset	Verified	Baseline updated
EC-xxx	Trạng thái	Trạng thái	Release	Asset list	Evidence	Baseline

Nó giúp phát hiện:

Source đã sửa, chưa deploy.
Deploy rồi, chưa test.
Test rồi, chưa cập nhật drawing.
Một asset bị bỏ lại.
Emergency fix chưa reconcile.

19. Checklist thay đổi kỹ thuật (engineering change)

Current baseline đã xác định chưa?
Trigger và desired outcome có bằng chứng không?
Current/proposed state rõ chưa?
yêu cầu (requirement) và assumption nào bị tác động?
Mechanical/electrical/software/data impact đã review chưa?
giao diện kết nối (interface) producer/consumer đã review chưa?
an toàn (safety)/risk/security impact đã route chưa?
chất lượng (quality)/hiệu năng (performance)/khả năng bảo trì (maintainability)/phụ tùng dự phòng (spare) impact đã xem chưa?
Shared/common item và nhiều model/asset đã xem chưa?
Implementation, abort và rollback plan có chưa?
Direct kiểm chứng (verification), regression và thẩm định lại (revalidation) đã tách chưa?
Evidence cũ nào mất hiệu lực?
Deployment/as-running evidence có chưa?
Drawing/BOM/manual/test/baseline đã cập nhật chưa?
Emergency change đã reconcile chưa?
Effectiveness sau deploy được kiểm tra thế nào?

Kết luận

thay đổi kỹ thuật (engineering change) không được đo bằng số file đã sửa. Nó được đo bằng khả năng kiểm soát tác động xuyên lifecycle.

Một change chỉ nên đóng khi:

Biết baseline ban đầu.
Biết yêu cầu (requirement), item và giao diện kết nối (interface) bị tác động.
an toàn (safety)/risk/security đã được route đúng.
Direct kiểm chứng (verification), regression và thẩm định lại (revalidation) có phạm vi hợp lý.
Deployment trên từng asset được ghi nhận.
Tài liệu và baseline đã reconcile.
Có bằng chứng change thực sự đạt mục tiêu.

Khi làm được chuỗi đó, đội kỹ thuật có thể thay đổi nhanh mà không dựa vào may mắn và không phải test lại toàn máy một cách mù quáng.

Nguồn tham khảo

ISO 10007:2017 — Configuration management: https://www.iso.org/standard/70400.html
ISO/IEC/IEEE 15288:2023 — System life cycle processes: https://www.iso.org/standard/81702.html
ISO 12100:2010 — Machinery đánh giá rủi ro (risk assessment) and risk reduction: https://www.iso.org/standard/51528.html
ISO/TR 14121-2:2012 — Practical machinery risk-assessment guidance: https://www.iso.org/standard/57180.html
ISO 13849-2:2012 — thẩm định (validation) of an toàn (safety)-related control systems: https://www.iso.org/standard/53640.html

Xem tất cả bài viết kỹ thuật MINATA