Thiết kế máy #49: Dữ liệu thời gian dừng máy (downtime data) — Ghi thế nào để dữ liệu thật sự dẫn tới cải tiến?

Một báo cáo cuối tháng ghi:

thời gian dừng máy (downtime) của máy: 120 phút.

Con số này đủ để biết có tổn thất, nhưng chưa đủ để cải tiến thiết kế. Trong 120 phút đó, máy thực sự hỏng bao lâu? Mất bao lâu để phát hiện và gọi người? Bao lâu để chẩn đoán? Bao lâu chờ phụ tùng, quyền truy cập hoặc sản phẩm test? Sau khi sửa xong, bao lâu để khôi phục (restore) parameter và xác nhận chất lượng?

Nếu toàn bộ được gom thành một ô “machine breakdown”, đội thiết kế không biết nên cải thiện diagnostic, khả năng tiếp cận (accessibility), phụ tùng dự phòng (spare) strategy, software khôi phục (restore) hay chính cơ cấu máy.

dữ liệu thời gian dừng máy (downtime data) tốt không bắt đầu từ dashboard đẹp. Nó bắt đầu từ ranh giới phạm vi (boundary), time model, event lifecycle và taxonomy đủ rõ để những người khác nhau ghi cùng một sự thật theo cùng một cách.

1. Trước chỉ số hiệu suất (KPI), hãy định nghĩa ranh giới phạm vi (boundary)

Cùng một sự kiện có thể tạo thời gian dừng máy (downtime) khác nhau tùy ranh giới phạm vi (boundary):

một cảm biến (sensor) làm station dừng;
station dừng nhưng buffer khiến line vẫn chạy;
line chậm lại nhưng không dừng hoàn toàn;
thiết bị sẵn sàng nhưng không có material;
máy dừng theo kế hoạch để đổi mã (changeover);
production order chưa yêu cầu chạy.

Vì vậy record cần biết đang đo cái gì:

equipment, station, cell hay line;
production mode hay maintenance/setup mode;
scheduled time, planned production time hay calendar time;
order/product nào đang active;
upstream/downstream state;
impact là mất output, giảm rate hay chỉ mất redundancy.

Nếu ranh giới phạm vi (boundary) khác nhau, hai tỷ lệ “độ sẵn sàng (availability)” có thể cùng đúng nhưng không so sánh được. Mọi chỉ số hiệu suất (KPI) phải đi cùng scope, time base, inclusion/exclusion rule và version.

2. State, event, reason, cause và action không phải một

Đây là chỗ nhiều hệ thống dữ liệu bị trộn.

State

Trạng thái tồn tại trong một khoảng thời gian: running, idle, faulted, setup, maintenance, blocked, starved hoặc trạng thái do nhà máy định nghĩa.

Event

Một chuyển đổi hoặc sự kiện có timestamp: running → faulted, cảnh báo (alarm) xuất hiện, operator acknowledge, work order mở, repair complete.

Reason

Nhãn phân loại vì sao state được ghi theo cách đó: planned maintenance, material shortage, equipment lỗi (fault) hoặc waiting for chất lượng (quality) release.

Cause

Causal explanation được hỗ trợ bởi investigation. Cause không nên được tự động suy ra từ cảnh báo (alarm) hoặc reason code.

Action

Điều đã làm: đặt lại (reset), adjustment, replace, repair, software khôi phục (restore), containment hoặc corrective action.

Ví dụ, Input X timeout là cảnh báo (alarm)/event. Equipment fault – sensing có thể là reason tạm thời. Sensing margin không đủ do bracket giữ vị trí kém là causal hypothesis cần phân tích nguyên nhân gốc (RCA). Redesign bracket và verify margin là corrective action.

Nếu database chỉ có một cột “Cause”, người nhập thường nhét cảnh báo (alarm), symptom, action và phỏng đoán vào cùng một nơi. Dữ liệu sau đó không thể tổng hợp đáng tin.

3. Một thời gian dừng máy (downtime) event có nhiều đồng hồ bên trong

Tổng thời gian dừng có thể được phân rã:

Occurrence: điều kiện failure bắt đầu, nếu biết.
Detection: hệ thống hoặc con người phát hiện.
Stop/impact: output bắt đầu bị ảnh hưởng.
Acknowledgement: event được xác nhận.
Response: người có trách nhiệm bắt đầu xử lý.
Diagnosis: failure path đủ rõ để chọn hành động.
Logistic delay: chờ phụ tùng, tool, tài liệu, vendor hoặc quyền truy cập.
Active repair: thao tác sửa/thay thực tế.
Restoration: parameter, calibration, homing, mastering hoặc configuration khôi phục (restore).
kiểm chứng (verification): xác nhận function, an toàn (safety) route và chất lượng (quality).
Release: thiết bị được trả về production.
Output recovery: line trở lại rate/chất lượng (quality) yêu cầu.

Không phải nhà máy nào cũng cần thu đủ mười hai mốc. Nhưng nếu mục tiêu là cải tiến thiết kế, ít nhất phải phân biệt active repair với delay và restoration.

Một thiết bị có thể thay part trong 10 phút nhưng thời gian dừng máy (downtime) 90 phút vì khó chẩn đoán và chờ quyền truy cập. Nếu chỉ nhìn MTTR tổng, nhóm có thể tối ưu access trong khi nút thắt thật là diagnostic hoặc support quy trình (process).

4. Start và end phải có quy tắc

“thời gian dừng máy (downtime) bắt đầu khi nào?” nghe đơn giản nhưng có nhiều lựa chọn:

khi failure condition xuất hiện;
khi controller chuyển lỗi (fault);
khi machine cycle không hoàn thành;
khi line mất output;
khi operator chọn reason;
khi work order được tạo.

Tương tự, end có thể là:

lỗi (fault) cleared;
automatic mode restored;
first good part;
stable production rate;
chất lượng (quality) release.

Không có một cặp start/end đúng cho mọi use case. Điều quan trọng là quy tắc phù hợp mục đích và không thay đổi âm thầm.

Nếu mục tiêu đo equipment repair, fault start → function restored có thể phù hợp. Nếu mục tiêu đo production loss, output impact → stable good output thường có ý nghĩa hơn. Tốt nhất lưu các event nguyên tử rồi tạo nhiều view, thay vì ép mọi nhu cầu vào một duration duy nhất.

5. Taxonomy reason code nên nhiều tầng

Một taxonomy phẳng với 200 mã sẽ khó dùng; một taxonomy quá ngắn như Machine / Material / Man lại không đủ cho action.

Một cấu trúc có thể gồm:

Level 1 — Impact class: planned, unplanned, external/no-demand.
Level 2 — Domain: equipment, quy trình (process)/material, chất lượng (quality), utility, upstream/downstream, organization/support.
Level 3 — Function/subsystem: sensing, motion, gripping, feeding, control, communication, guarding…
Level 4 — dạng sai hỏng (failure mode)/reason detail: no detection, drift, jam, overtravel, lost communication…

Cấu trúc cụ thể phải phù hợp architecture và cách ra quyết định của từng nhà máy. Không nên sao chép taxonomy của một dây chuyền khác chỉ vì phần mềm có sẵn.

Các nguyên tắc quan trọng:

code phải có definition và inclusion/exclusion example;
cho phép unknown khi chưa biết;
other phải dẫn tới review, không trở thành thùng rác;
reason ban đầu có thể được reclassify sau investigation;
mọi correction cần audit trail;
version taxonomy phải được lưu cùng event;
không bắt operator chọn “root cause” trong vài giây.

Unknown là dữ liệu trung thực. Một cause code sai nhưng đầy đủ 100% nguy hiểm hơn 15% event chưa phân loại nhưng có quy trình (process) điều tra.

6. cảnh báo (alarm) không phải thời gian dừng máy (downtime) reason

Một failure có thể tạo hàng chục cảnh báo (alarm) downstream. Nếu mỗi cảnh báo (alarm) trở thành một thời gian dừng máy (downtime) event, count bị phóng đại và Pareto chỉ phản ánh cảnh báo (alarm) cascade.

Cần logic để:

nhóm cảnh báo (alarm) trong cùng episode;
giữ cảnh báo đầu tiên (first-out) hoặc initiating evidence nếu architecture hỗ trợ;
phân biệt primary event và consequence;
tránh mở event mới khi machine vẫn ở cùng một stop episode;
xử lý clear/reappear do bouncing;
giữ raw cảnh báo (alarm) riêng với curated thời gian dừng máy (downtime) record.

First cảnh báo (alarm) cũng không tự động là root cause. Nó chỉ là đầu mối có giá trị hơn nếu timestamp và logic đủ đáng tin. phân tích nguyên nhân gốc (RCA) vẫn phải kiểm tra mechanism.

7. Blocked, starved và line attribution

Trong line nhiều station, một station có thể idle vì:

upstream không cấp phôi;
downstream không nhận được;
buffer đầy hoặc rỗng;
line control đang giữ;
station local lỗi (fault);
planned stop ở station khác.

Nếu mọi idle đều tính là local thời gian dừng máy (downtime), station ở giữa line sẽ mang lỗi của cả hệ thống. Nếu chỉ ghi line stop, lại mất thông tin về propagation.

Một data model tốt nên tách:

local equipment state;
material-flow state;
line/production state;
initiating station hoặc event nếu xác định được;
affected duration ở từng ranh giới phạm vi (boundary);
overlap rule.

Tổng thời gian dừng máy (downtime) của các station không nhất thiết bằng thời gian dừng máy (downtime) của line. Cộng trực tiếp các duration chồng lấn có thể tạo “300 phút station loss” trong một ca chỉ dài 240 phút. Con số đó có thể hữu ích như lost-equipment-time, nhưng phải được đặt tên và không trình bày như line elapsed thời gian dừng máy (downtime).

8. Microstop cần treatment riêng

Microstop ngắn thường:

xảy ra nhiều lần;
tự recover hoặc operator đặt lại (reset) nhanh;
không mở work order;
bị lọc khỏi report theo threshold;
gây mất rate đáng kể khi cộng dồn.

Pareto theo duration có thể che chúng. Pareto theo count lại có thể làm một microstop 2 giây quan trọng hơn một breakdown 2 giờ.

Nên xem ít nhất:

count;
cumulative duration;
median và high-percentile duration;
event rate theo cycle/exposure;
distribution theo product, shift, speed, environment;
recurrence pattern;
output loss.

Threshold lọc microstop phải có version và lý do. Nếu thay threshold giữa hai tháng mà không ghi, trend trở nên vô nghĩa.

9. Data-chất lượng (quality) gate trước dashboard

Một hệ thống tự động thu thập vẫn có thể cho dữ liệu sai.

Timestamp

clock có đồng bộ không?
timezone và daylight-saving xử lý thế nào?
timestamp là lúc occurrence hay lúc message được ghi?
resolution và jitter bao nhiêu?

Completeness

có missing start hoặc missing end?
data gap do network/server khởi động lại (restart)?
manual event có bị bỏ qua?

Uniqueness

event có duplicate do retry?
cảnh báo (alarm) bounce tạo nhiều episode giả?

Consistency

có hai state loại trừ nhau cùng active?
end trước start?
equipment running trong khi reason vẫn là faulted?

Referential integrity

equipment ID, taxonomy version, product/order và configuration có tồn tại?
ID có bị tái sử dụng sau cải tạo máy (retrofit)?

Human-entered data

reason được chọn khi nào?
có default bias vì một code dễ bấm hơn?
correction có người và lý do?

Dashboard cần hiển thị data-chất lượng (quality) coverage, không chỉ chỉ số hiệu suất (KPI). Một trend “tốt lên” có thể do 20% event không ghi được sau khi gateway thay đổi.

10. chỉ số hiệu suất (KPI) chỉ so sánh được khi mẫu số giống nhau

Các chỉ số hiệu suất (KPI) độ sẵn sàng (availability), utilization, hiệu năng (performance) hoặc maintenance đều phụ thuộc time model và denominator. Cùng tên nhưng khác:

planned production time;
scheduled time;
loading time;
calendar time;
excluded planned stop;
treatment của no-demand;
treatment của blocked/starved;
minimum event duration;
aggregation theo asset hay line.

Do đó một chỉ số hiệu suất (KPI) definition nên lưu:

tên và mục đích;
formula;
input elements;
scope/ranh giới phạm vi (boundary);
inclusion/exclusion;
sampling/aggregation;
unit;
người phụ trách (owner);
version/effective date;
data-chất lượng (quality) yêu cầu (requirement).

ISO 22400 cung cấp framework và chỉ số hiệu suất (KPI) definitions cho manufacturing operations management. Tuy nhiên ISO 22400-2:2014 đang trong quá trình revision tại thời điểm bài này được viết. Khi triển khai, cần kiểm tra edition/status mới nhất và quản lý version, không đóng cứng hệ thống theo một bản cũ.

11. Pareto cần nhiều góc nhìn

Một Pareto duy nhất hiếm khi đủ. Hãy xem:

theo tổng duration: tìm nguồn mất thời gian lớn;
theo event count: tìm recurrence;
theo median/percentile: tách event thường và tail event;
theo exposure: event trên cycle, giờ chạy hoặc unit;
theo consequence: output, scrap, an toàn (safety) escalation;
theo recovery phase: diagnosis, wait, repair, restoration;
theo configuration/product: tìm interaction;
theo age/time since maintenance: tìm pattern lifecycle.

Ví dụ, subsystem A gây 40% thời gian dừng máy (downtime) vì một sự kiện chờ phụ tùng dự phòng (spare) rất dài. Subsystem B chỉ gây 20% phút nhưng lặp hàng trăm lần. A có thể cần phụ tùng dự phòng (spare)/lỗi thời (obsolescence) action; B có thể cần design-margin hoặc diagnostic action.

Chỉ nhìn “top 1 theo phút” sẽ bỏ lỡ một trong hai.

12. Correlation không phải root cause

Dashboard có thể cho thấy event tăng ở ca đêm, sản phẩm B hoặc nhiệt độ cao. Đây là hypothesis lead, không phải causal proof.

Cần hỏi:

exposure có khác không?
mix sản phẩm và speed có thay đổi không?
data coverage có đều không?
maintenance/change nào trùng thời điểm?
variable có thực sự đi trước event không?
có confounder nào cùng thay đổi?
mechanism kỹ thuật có hợp lý không?

Các case có consequence cao, recurrence đáng kể hoặc causal uncertainty nên được chuyển sang phân tích nguyên nhân gốc (RCA). Reason code và chart giúp ưu tiên; chúng không thay quá trình preserve evidence, test hypothesis và review effectiveness.

13. Từ dữ liệu thời gian dừng máy (downtime data) đến hành động thiết kế (design action)

Data có giá trị khi tạo được một chain:

Event pattern → hypothesis → investigation → action → kiểm chứng (verification) → effectiveness

Một số mapping điển hình:

Pattern dữ liệu	Câu hỏi thiết kế
Diagnosis time dài	cảnh báo (alarm)/diagnostic có phân biệt failure path không?
Wait-for-part dài	mức độ quan trọng (criticality), stock, repair loop hoặc lỗi thời (obsolescence) có sai không?
Active repair dài	Access, tool envelope, modularity hoặc fastener strategy?
Restoration dài	Baseline, parameter, calibration, mastering và test công thức sản xuất (recipe)?
kiểm chứng (verification) dài	Acceptance criterion hoặc test access có thiếu?
Microstop lặp nhiều	Margin, sensing, timing, feeding hoặc variation?
Event tăng sau change	Impact assessment/regression có bỏ sót?

Sau action, cùng data model phải giúp đánh giá effectiveness. Nếu taxonomy hoặc threshold bị đổi giữa chừng, trend phải được re-baseline hoặc chú thích rõ.

14. Ví dụ giả định: một station cấp phôi

Trong một tháng giả định, station có:

một breakdown dài do chờ module;
nhiều microstop do phôi không vào đúng;
vài khoảng blocked do downstream;
một planned adjustment.

Nếu gom tất cả thành Feeder downtime, kết luận có thể là “thay feeder”.

Phân rã cho thấy:

breakdown dài chủ yếu là logistic delay, active replacement ngắn;
microstop tương quan với một product geometry nhưng cần phân tích nguyên nhân gốc (RCA) để xác nhận mechanism;
blocked không phải local equipment failure;
planned adjustment thuộc planned state.

Action trở nên khác:

review phụ tùng dự phòng (spare) strategy và approved equivalent cho module;
mở phân tích nguyên nhân gốc (RCA) cho microstop với measurement về feeding margin;
giữ blocked trong line-flow analysis;
không trộn planned adjustment vào unplanned reliability.

Không cần một chỉ số hiệu suất (KPI) phức tạp để có insight này. Cần đúng ranh giới phạm vi (boundary) và đúng event anatomy.

15. Minimum event schema

Một schema tối thiểu có thể gồm:

event ID bất biến;
asset/station/line ID;
ranh giới phạm vi (boundary) và state transition;
start/end và nguồn timestamp;
taxonomy version;
reason initial/final;
cảnh báo (alarm)/raw-event references;
product/order/configuration context;
initiating/affected relationship;
recovery phase timestamps nếu có;
action và part/work-order reference;
data-chất lượng (quality) flag;
người/hệ thống tạo và lịch sử correction;
phân tích nguyên nhân gốc (RCA)/change reference;
closure/effectiveness status.

Không phải trường nào cũng public hoặc nằm trong cùng database. Quyền truy cập, retention và dữ liệu cá nhân phải theo mục đích thực sự. Không thu thập tên người chỉ vì “sau này có thể cần”; ưu tiên role/quy trình (process) data khi đủ cho phân tích.

16. Checklist triển khai

ranh giới phạm vi (boundary) equipment/station/line đã rõ chưa?
Time base và planned/unplanned rule có version không?
State, event, reason, cause và action đã tách chưa?
Start/end có định nghĩa theo use case không?
Có thể phân rã detection, diagnosis, wait, repair, restoration và kiểm chứng (verification) không?
Taxonomy có controlled definition, unknown và audit trail không?
cảnh báo (alarm) cascade có được nhóm thành episode không?
Blocked/starved có tách local lỗi (fault) không?
Microstop có count, duration và exposure view không?
Clock, missing, duplicate, overlap và coverage có chất lượng (quality) gate không?
chỉ số hiệu suất (KPI) có formula, denominator, scope và version không?
Pareto có nhiều chiều thay vì chỉ tổng phút không?
Reason code có bị dùng như root cause không?
Dữ liệu có nối sang phân tích nguyên nhân gốc (RCA), phân tích dạng sai hỏng và tác động (FMEA), phụ tùng dự phòng (spare), baseline và change không?
Privacy, access và retention có phù hợp mục đích không?

Kết luận

dữ liệu thời gian dừng máy (downtime data) không chỉ để báo cáo máy dừng bao lâu. Nó phải cho biết thời gian đã đi đâu, ranh giới phạm vi (boundary) nào bị ảnh hưởng và phần nào của năng lực phục hồi cần cải tiến.

Khi state, event, reason, cause và action được tách rõ; timestamp có chất lượng (quality) gate; chỉ số hiệu suất (KPI) có denominator và version; dữ liệu mới có thể dẫn từ một pattern trên dashboard đến hypothesis, phân tích nguyên nhân gốc (RCA) và hành động thiết kế (design action) có thể kiểm chứng.

Một dashboard ít biểu đồ nhưng giữ đúng causal ranh giới phạm vi (boundary) có giá trị hơn một “control tower” đẹp mắt xây trên reason code lẫn lộn.

Nguồn tham khảo

ISO 22400-1:2014 — chỉ số hiệu suất (KPI) overview, concepts and terminology: https://www.iso.org/standard/56847.html
ISO 22400-2:2014 — chỉ số hiệu suất (KPI) definitions and descriptions: https://www.iso.org/standard/54497.html
ISO/TR 22400-10:2018 — Operational sequence of data acquisition: https://www.iso.org/standard/71283.html
ISO 14224:2016 — Reliability and maintenance data: https://www.iso.org/standard/64076.html
IEC 62740:2015 — phân tích nguyên nhân gốc (root cause analysis): https://webstore.iec.ch/en/publication/21810

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