Thiết kế máy #48: Phân tích nguyên nhân gốc (root cause analysis) — Từ “cảm biến (sensor) lỗi” đến bằng chứng nguyên nhân

Máy dừng. cảnh báo (alarm) báo cảm biến (sensor) không ON. Kỹ thuật viên thay cảm biến (sensor), đặt lại (reset) và máy chạy lại.

Biên bản thường kết thúc bằng một dòng:

Nguyên nhân: cảm biến (sensor) hỏng.

Nhưng cảm biến (sensor) cũ có thật sự hỏng không? Nó mất nguồn, lệch vị trí, bị nhiễu, connector tiếp xúc chập chờn hay đối tượng phát hiện (target) không đến đúng vị trí? Vì sao sự kiện xuất hiện lúc đó? Vì sao hệ thống không phát hiện sớm hơn? Và quan trọng nhất: thay cảm biến (sensor) mới có làm xác suất tái diễn giảm một cách bền vững không?

Khôi phục sản xuất là cần thiết, nhưng phục hồi máy không đồng nghĩa đã tìm được root cause. phân tích nguyên nhân gốc (root cause analysis) (phân tích nguyên nhân gốc (RCA)) là quá trình hậu nghiệm dùng bằng chứng để giải thích một focus event đã xảy ra, kiểm tra các giả thuyết nguyên nhân và chọn action có thể ngăn hoặc giảm khả năng tái diễn.

1. Đừng trộn symptom, dạng sai hỏng (failure mode) và cause

Một phân tích nguyên nhân gốc (RCA) dễ lạc hướng khi mọi khái niệm đều được gọi là “nguyên nhân”.

Focus event: sự kiện cụ thể được chọn để điều tra.
Symptom: điều quan sát được, như cảnh báo (alarm), rung, vết xước hoặc cycle stop.
dạng sai hỏng (failure mode): cách một item không thực hiện chức năng yêu cầu.
Causal factor: yếu tố góp phần tạo chuỗi sự kiện.
Contributing condition: điều kiện làm tăng khả năng hoặc hậu quả nhưng có thể không đủ để tự gây sự kiện.
Root cause: nguyên nhân ở mức mà nếu được xử lý phù hợp sẽ làm giảm đáng kể khả năng tái diễn trong phạm vi hệ thống đang xét.

“cảm biến (sensor) OFF” là trạng thái quan sát. “Mất khả năng phát hiện đối tượng phát hiện (target)” gần với dạng sai hỏng (failure mode). “Bracket dịch chuyển vì joint không giữ được preload trong duty thực tế” mới là một hypothesis nguyên nhân có thể kiểm tra.

Không phải sự kiện nào cũng có đúng một root cause. Có thể tồn tại nhiều nhánh vật lý, thiết kế, quy trình và tổ chức cùng gặp nhau. Mục tiêu không phải tìm một câu thật sâu, mà tìm một causal model đủ evidence và hữu ích cho action.

2. Phục hồi trước, nhưng phải giữ bằng chứng

Trong sản xuất, ưu tiên ban đầu thường là đưa hệ thống về trạng thái an toàn và phục hồi hoạt động. Tuy nhiên, nhiều bằng chứng tốt nhất biến mất ngay khi:

đặt lại (reset) cảnh báo (alarm) hoặc power cycle;
tháo connector;
thay part;
chỉnh vị trí;
xóa buffer log;
ghi đè công thức sản xuất (recipe) hoặc parameter;
vệ sinh dấu vết;
chạy lại mà không ghi trạng thái ban đầu.

Một evidence-preservation routine nên ngắn, rõ và tương xứng với mức độ sự kiện. Có thể gồm:

bảo đảm trạng thái an toàn theo procedure của máy;
ghi thời điểm phát hiện và người ghi nhận;
chụp trạng thái giao diện người–máy (HMI), indicator và vị trí cơ khí nếu được phép;
export log bằng cách không làm thay đổi dữ liệu gốc;
ghi configuration/công thức sản xuất (recipe)/version đang chạy;
nhận dạng và quarantine part tháo ra;
ghi mọi can thiệp trước khi máy phục hồi;
lưu ai thu thập, từ nguồn nào và khi nào.

Đây không phải yêu cầu “đóng băng máy bằng mọi giá”. Mức preserve phải cân bằng an toàn (safety), production và investigation value. Nhưng nếu không giữ gì, nhóm phân tích nguyên nhân gốc (RCA) sẽ buộc phải suy luận từ ký ức sau sự kiện.

Với sự kiện an toàn (safety), security, pháp lý hoặc có thương tích, phải kích hoạt procedure chuyên ngành và người có thẩm quyền. Bài viết này không thay thế điều tra tai nạn, điều tra mạng hay yêu cầu pháp lý.

3. Viết problem statement đủ hẹp để điều tra

Một câu như “máy hay lỗi cảm biến (sensor)” quá rộng. Problem statement tốt hơn cần trả lời:

What: chức năng hoặc output nào không đạt?
Where: station, mode, giao diện kết nối (interface) hoặc vùng nào?
When: thời điểm, phase của cycle và điều kiện trước đó?
Extent: một lần, nhiều lần, một máy hay cả population?
Impact: thời gian dừng máy (downtime), chất lượng (quality), an toàn (safety) hoặc recovery consequence nào?
Expected: behavior được yêu cầu là gì?
Known ranh giới phạm vi (boundary): điều gì đã kiểm tra, điều gì chưa biết?

Ví dụ:

Trong automatic mode, tại bước xác nhận kẹp (clamp)-closed, tín hiệu xác nhận chuyển OFF trong một số chu kỳ sau khi máy đã chạy ổn định; controller dừng sequence theo thiết kế. Chưa xác định mất tín hiệu xuất phát từ đối tượng phát hiện (target) position, sensing path, power/wiring hay logic interpretation.

Câu này chưa gán nguyên nhân. Nó giữ investigation space mở và định rõ event ranh giới phạm vi (boundary).

4. Timeline phải ghi cả độ tin cậy của thời gian

Timeline không chỉ là danh sách cảnh báo (alarm). Nó cần ghép:

controller event log;
giao diện người–máy (HMI) cảnh báo (alarm) history;
drive/cảm biến (sensor) diagnostic;
chất lượng (quality) result;
maintenance intervention;
operator observation;
video hoặc historian nếu có;
environmental/quy trình (process) change;
configuration change.

Vấn đề là đồng hồ các nguồn có thể không đồng bộ. Một timestamp chính xác đến millisecond trên màn hình không có nghĩa nó đúng tuyệt đối. Record nên ghi:

nguồn thời gian;
timezone;
resolution;
clock offset đã biết;
dữ liệu có thể bị buffer hoặc ghi trễ;
khoảng uncertainty.

Thay vì khẳng định “cảnh báo (alarm) B xảy ra sau A 120 ms”, có thể phải nói “theo controller clock B xuất hiện sau A; offset với giao diện người–máy (HMI) chưa được xác nhận”. Sự trung thực này ngăn causal chain giả được tạo ra chỉ vì hai đồng hồ khác nhau.

Timeline cũng nên có change points: lần bảo trì gần nhất, thay công thức sản xuất (recipe), update programme, thay lot vật liệu, thay ca, đổi nhiệt độ hoặc tăng tốc độ. Change point là đầu mối, chưa phải bằng chứng nguyên nhân.

5. Evidence không đồng nghĩa với interpretation

Một record phân tích nguyên nhân gốc (RCA) nên tách:

Loại	Ví dụ
Observation	Input chuyển OFF tại một timestamp
Source	Controller event buffer
Integrity	File export nguyên gốc, hash hoặc quyền truy cập phù hợp
Limitation	Sample rate không bắt được pulse rất ngắn
Interpretation	Có khả năng sensing path bị gián đoạn
Alternative	Logic mapping hoặc communication cũng có thể tạo trạng thái OFF

Ảnh chụp, log, measurement và lời kể đều có giá trị khác nhau. Lời kể không nên bị loại bỏ, nhưng phải phân biệt với dữ liệu instrumented. Một measurement cũng có thể sai do bandwidth, calibration, probe loading hoặc đo nhầm reference.

Evidence mạnh là evidence liên quan trực tiếp, có provenance, còn nguyên vẹn và đủ chất lượng để phân biệt giữa các hypothesis cạnh tranh.

6. Tạo nhiều hypothesis trước khi chọn một

Với failure “không xác nhận được đối tượng phát hiện (target)”, các nhánh ban đầu có thể gồm:

đối tượng phát hiện (target) không đến vị trí;
cảm biến (sensor)/đối tượng phát hiện (target) alignment không ổn định;
sensing face bị contamination;
nguồn hoặc common bị gián đoạn;
connector/wiring intermittent;
cảm biến (sensor) output hỏng;
input module hoặc network path lỗi;
mapping/logic đọc sai signal;
timing window không phù hợp với variation thực;
configuration khác baseline.

Danh sách không cần vô hạn. Nó cần bao phủ những mechanism hợp lý theo function và architecture.

Một hypothesis matrix giúp tránh “yêu hypothesis đầu tiên”:

Hypothesis	Dự đoán nếu đúng	Evidence ủng hộ	Evidence phản bác	Test phân biệt	Trạng thái
Alignment dịch	Margin giảm theo vị trí	Vết dịch, tín hiệu phụ thuộc rung	Bracket còn chuẩn định vị (datum) ổn định	Đo margin/position an toàn	Mở
Connector intermittent	Mất tín hiệu khi harness chịu motion	Diagnostic power drop	Không có dấu tiếp xúc	Inspect và test harness theo procedure	Mở
cảm biến (sensor) internal lỗi (fault)	Output sai dù đối tượng phát hiện (target)/power đúng	Bench test fail	cảm biến (sensor) cũ test ổn	Controlled substitution/test	Mở

“cảm biến (sensor) mới chạy được” chỉ ủng hộ một số hypothesis. Trong quá trình thay, người kỹ thuật cũng đã tháo connector, chỉnh bracket và route lại cable. Vì vậy substitution có nhiều biến cùng thay đổi.

7. 5 Why là câu hỏi, không phải bằng chứng

5 Why hữu ích để mở rộng tư duy:

Vì sao máy dừng? Vì mất điều kiện cho phép (permissive).
Vì sao mất điều kiện cho phép (permissive)? Vì input OFF.
Vì sao input OFF? Vì cảm biến (sensor) lệch.
Vì sao cảm biến (sensor) lệch? Vì bolt lỏng.
Vì sao bolt lỏng? Vì siết không đúng.

Chuỗi này nghe hợp lý nhưng mỗi “vì” có thể chỉ là phỏng đoán. Bolt có thật lỏng không? Joint có được thiết kế giữ preload không? Surface, vibration và duty có phù hợp không? Torque record có đáng tin không? “Siết không đúng” có phải do tool, access, instruction, training, đặc tả (specification) hay joint design?

5 Why không ép sự kiện phức tạp thành đúng năm tầng. Mỗi liên kết cần evidence hoặc được giữ trạng thái hypothesis. Khi có nhánh song song, cause map, lỗi (fault) tree hoặc event-and-causal-factor chart thường diễn đạt tốt hơn một đường thẳng.

8. Không dừng ở “operator lỗi (error)”

Con người là một phần của hệ thống vận hành. Nếu một action của operator có liên quan, phân tích nguyên nhân gốc (RCA) vẫn phải hỏi:

task có rõ và khả thi trong thời gian thực không?
giao diện người–máy (HMI) có làm trạng thái và hậu quả dễ hiểu không?
mode, control và feedback có nhất quán không?
procedure có phản ánh máy hiện tại không?
training có đúng task và đúng variation không?
workload, handover và staffing có tạo điều kiện lỗi không?
hệ thống có lỗi (error)-proofing hoặc recovery phù hợp không?
cùng một action có thể lặp lại với người có năng lực khác không?

Gắn nhãn “operator lỗi (error)” thường mô tả người cuối cùng chạm vào hệ thống, không giải thích vì sao system cho phép hoặc không bắt được sai lệch. Điều đó không có nghĩa mọi cá nhân đều không chịu trách nhiệm trong mọi bối cảnh; nó có nghĩa phân tích nguyên nhân gốc (RCA) kỹ thuật không được dùng để thay quy trình HR, pháp lý hoặc xác định liability.

9. Test hypothesis mà không tạo thêm rủi ro

Test tốt phải phân biệt được ít nhất hai hypothesis. Trước test cần xác định:

prediction nếu hypothesis đúng;
prediction nếu sai;
measurement và acceptance criterion;
configuration cần giữ cố định;
risk của việc tái tạo;
quyền phê duyệt;
cách khôi phục (restore) baseline sau test.

Không tái tạo hazardous event trên máy sản xuất chỉ để “xem có lặp lại không”. Có thể dùng:

bench test trên part đã quarantine;
simulation hoặc offline analysis;
controlled substitution;
inspection/metrology;
log có sampling tốt hơn;
test fixture;
comparison với population tương đương;
safe reduced-energy mode nếu machine-specific đánh giá rủi ro (risk assessment) và procedure cho phép.

Nếu không thể test trực tiếp, causal confidence phải phản ánh giới hạn đó. “Probable cause” có evidence và uncertainty rõ vẫn tốt hơn một “root cause confirmed” giả.

10. Containment, correction và corrective action khác nhau

Containment

Giảm hậu quả tức thời hoặc ngăn sản phẩm nghi ngờ đi tiếp. Ví dụ tăng kiểm tra tạm thời, cô lập population bị ảnh hưởng hoặc giữ một mode vận hành.

Correction

Khôi phục item hiện tại: chỉnh lại bracket, thay connector hoặc khôi phục (restore) parameter.

Corrective action

Thay đổi causal mechanism để giảm tái diễn: redesign joint, thêm chuẩn định vị (datum)/lỗi (error)-proofing, thay route cable, cải thiện diagnostic, sửa đặc tả (specification) hoặc cập nhật maintenance task.

Preventive/systemic action

Mở rộng bài học sang population hoặc quy trình (process) tương tự: update design standard, checklist, phân tích dạng sai hỏng và tác động (FMEA) library, supplier yêu cầu (requirement) hoặc training.

Một action mạnh phải map về causal factor đã chứng minh. “Nhắc nhở cẩn thận hơn” hiếm khi xử lý được joint design, ambiguous giao diện người–máy (HMI) hoặc missing diagnostic.

11. kiểm chứng (verification) khác effectiveness review

kiểm chứng (verification) trả lời: action đã được thực hiện đúng chưa?

drawing/BOM/programme đã update?
part đúng revision đã lắp?
test theo protocol đạt?
baseline và bản sao lưu (backup) đã cập nhật?
người liên quan đã nhận tài liệu?

Effectiveness review trả lời: action có giảm recurrence risk trong vận hành thật không?

event có tái diễn theo exposure tương đương không?
leading indicator có cải thiện không?
có side effect mới không?
failure chuyển sang mode khác không?
observation period có đủ cycle, load và environment không?

“Không lỗi trong một tuần” không có ý nghĩa nếu trước đó lỗi mỗi sáu tháng. Effectiveness criterion phải liên quan exposure và pattern gốc. Nếu volume nhỏ, có thể cần kết hợp field observation, stress test, margin evidence và population data.

12. Feed bài học trở lại lifecycle

phân tích nguyên nhân gốc (RCA) chỉ tạo giá trị khi kết quả quay lại hệ thống:

phân tích dạng sai hỏng và tác động (FMEA): thêm hoặc cập nhật dạng sai hỏng (failure mode), cause, control và treatment.
cảnh báo (alarm)/diagnostic: tăng khả năng phân biệt failure path.
Maintenance: sửa inspection, criterion, tool và evidence.
Configuration: cập nhật as-running baseline và khôi phục (restore) package.
phụ tùng dự phòng (spare): cập nhật mức độ quan trọng (criticality), equivalent hoặc repair route.
yêu cầu (requirement)/nghiệm thu tại xưởng / nghiệm thu tại hiện trường (FAT/SAT): bổ sung tiêu chí nếu gap xuất phát từ acceptance.
Design rule: commonize bài học cho machine family.
Training/giao diện người–máy (HMI): chỉ cập nhật khi causal analysis cho thấy thực sự cần.

Action người phụ trách (owner), due date, evidence, approval và closure condition phải được theo dõi. Nếu phân tích nguyên nhân gốc (RCA) kết thúc bằng một PDF không nối với change system, cùng một failure có thể quay lại dưới tên khác.

13. Ví dụ giả định: tín hiệu cảm biến (sensor) chập chờn

Focus event

Máy dừng tại bước xác nhận vị trí. Input OFF trong một khoảng ngắn; không có thiệt hại và chức năng an toàn (safety function) hoạt động theo thiết kế.

Evidence ban đầu

controller log cho thấy input mất trước thời gian chờ (timeout);
camera không đủ frame rate để kết luận đối tượng phát hiện (target) motion;
cảm biến (sensor) cũ được tháo và quarantine;
bracket có dấu witness cho thấy vị trí đã thay đổi;
cable inspection chưa thấy hư hỏng rõ;
sự kiện tập trung sau giai đoạn máy chạy ở duty cao.

Hypothesis

cảm biến (sensor) internal intermittent;
bracket mất vị trí do joint margin thấp;
cable/connector intermittent;
đối tượng phát hiện (target) motion variation vượt sensing margin;
input/network interpretation.

Test và kết quả giả định

Bench test không tái tạo lỗi cảm biến (sensor). Metrology cho thấy bracket có thể dịch trong tolerance lắp hiện tại; signal margin giảm đáng kể ở một biên đối tượng phát hiện (target) variation. Inspection joint cho thấy preload control và chuẩn định vị (datum) chưa đủ rõ. Cable test và diagnostic path không tìm được evidence ủng hộ.

Kết luận phù hợp không phải “cảm biến (sensor) tốt nên chắc chắn bracket lỗi”. Nó có thể là:

Evidence hiện tại ủng hộ mạnh cơ chế sensing margin không đủ do kết hợp variation của đối tượng phát hiện (target) và khả năng giữ vị trí bracket; chưa có evidence ủng hộ internal cảm biến (sensor) failure. Corrective action tập trung vào chuẩn định vị (datum)/joint và kiểm chứng (verification) margin, đồng thời tăng diagnostic để phân biệt nếu sự kiện tái diễn.

Sau redesign, nhóm cần verify joint, margin và function; sau đó review effectiveness trên exposure phù hợp. cảm biến (sensor) cũ chỉ trở lại kho nếu qua qualification, không dựa trên cảm giác “có vẻ vẫn dùng được”.

14. Checklist phân tích nguyên nhân gốc (RCA) cho máy tự động

Focus event có được mô tả trung lập và đủ hẹp không?
an toàn (safety)/security/legal route có cần kích hoạt không?
Evidence có được preserve trước đặt lại (reset)/thay part không?
Mỗi evidence có source, timestamp, integrity và limitation không?
Timeline có ghi clock uncertainty không?
Symptom, dạng sai hỏng (failure mode) và cause có bị trộn không?
Có nhiều hypothesis hợp lý không?
Mỗi hypothesis có prediction, evidence ủng hộ/phản bác và test phân biệt không?
Có tránh dùng correlation như proof không?
Human action có được xem trong task/giao diện kết nối (interface)/organization context không?
Test có risk ranh giới phạm vi (boundary) và khôi phục (restore) plan không?
Containment, correction và corrective action có phân biệt không?
Action có map về causal mechanism không?
kiểm chứng (verification) và effectiveness criterion có tách riêng không?
Kết quả có feed về phân tích dạng sai hỏng và tác động (FMEA), cảnh báo (alarm), maintenance, baseline và change quy trình (process) không?

Kết luận

phân tích nguyên nhân gốc (RCA) không phải nghệ thuật kể một câu chuyện hợp lý sau khi máy chạy lại. Nó là kỷ luật chuyển từ focus event sang causal model bằng evidence có provenance, hypothesis có thể bị phản bác và test có ranh giới an toàn.

Nếu chỉ thay part và ghi “cảm biến (sensor) lỗi”, tổ chức có thể phục hồi một ca sản xuất nhưng không học được gì. Khi evidence, action và effectiveness được nối về phân tích dạng sai hỏng và tác động (FMEA), configuration và design quy trình (process), mỗi failure mới thực sự trở thành dữ liệu cải tiến thiết kế.

Nguồn tham khảo

IEC 62740:2015 — phân tích nguyên nhân gốc (root cause analysis): https://webstore.iec.ch/en/publication/21810
IEC 60812:2018 — phân tích dạng sai hỏng và tác động (FMEA)/FMECA: https://webstore.iec.ch/en/publication/26359
IEC 62960:2020 — Dependability reviews during the life cycle: https://webstore.iec.ch/en/publication/29052
IEC 62508:2025 — Human aspects of dependability: https://webstore.iec.ch/en/publication/75198
ASQ — phân tích nguyên nhân gốc (root cause analysis): https://asq.org/chất lượng (quality)-resources/root-cause-analysis

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