Series Từ số hóa đến AI #47: AI dự báo hỏng máy – điều kiện dữ liệu, giá trị và giới hạn cần biết

I. Phân biệt preventive, condition-based và predictive maintenance

Preventive maintenance

Bảo trì theo lịch hoặc số giờ chạy. Dễ triển khai, phù hợp hạng mục có chu kỳ rõ nhưng có thể làm quá sớm hoặc quá muộn nếu điều kiện vận hành thay đổi.

Condition-based maintenance

Bảo trì dựa trên tình trạng đo được. Hệ thống cảnh báo khi rung, nhiệt độ, áp suất hoặc chỉ báo khác vượt ngưỡng hoặc xu hướng bất thường.

Predictive maintenance

Sử dụng dữ liệu và mô hình để ước tính rủi ro, thời điểm hoặc xác suất hỏng trong tương lai. Có thể kết hợp machine learning, thống kê, physics và tri thức chuyên gia.

Nhà máy không cần “nhảy” thẳng đến predictive. Một lộ trình tốt thường đi từ dữ liệu đáng tin, ngưỡng/trend, condition monitoring đến mô hình nâng cao khi có business case.

II. Chọn thiết bị bằng criticality, không bằng sự dễ kết nối

Một máy dễ gắn cảm biến nhưng dừng ít ảnh hưởng có thể không tạo ROI. Nên ưu tiên thiết bị mà hỏng hóc gây:

• Mất sản lượng lớn hoặc dừng bottleneck.
• Nguy cơ giao hàng trễ.
• Rủi ro an toàn hoặc môi trường.
• Lỗi chất lượng nghiêm trọng.
• Chi phí sửa chữa cao.
• Lead time phụ tùng dài.
• Khó có thiết bị dự phòng.

Có thể chấm criticality theo Safety, Quality, Delivery, Cost và Maintainability. Chọn 1-3 asset/failure mode đầu tiên thay vì toàn bộ nhà máy.

III. Failure mode phải có tín hiệu có thể quan sát

Câu hỏi quan trọng không phải “máy này hay hỏng không?” mà là “trước khi failure này xảy ra, có tín hiệu nào thay đổi đủ sớm và đủ ổn định không?”.

Ví dụ:

Nếu failure xảy ra đột ngột không có tín hiệu hoặc rất hiếm, AI có thể không phù hợp.

IV. Dữ liệu cần chuẩn bị

Dữ liệu tình trạng

• Sensor signal và sampling rate.
• Timestamp đồng bộ.
• Unit, scaling, calibration.
• Operating regime và load.
• Alarm, setpoint và trạng thái máy.

Dữ liệu sự kiện và bảo trì

• Failure timestamp và failure mode đã xác nhận.
• Work order, triệu chứng, nguyên nhân và hành động.
• Phụ tùng thay thế.
• Thời gian dừng và khôi phục.
• PM/inspection gần trước failure.

Context vận hành

• Sản phẩm, tốc độ, ca, recipe, môi trường.
• Start/stop, changeover và cleaning.
• Maintenance intervention.
• Thay đổi firmware, sensor hoặc cấu hình.

Không có context, mô hình có thể coi thay đổi tải bình thường là bất thường.

V. Chất lượng nhãn hỏng là điểm nghẽn lớn

Supervised model cần biết dữ liệu nào dẫn đến failure nào. Nhưng lịch sử bảo trì thường thiếu hoặc ghi tự do. Cần:

• Chuẩn hóa failure mode và cause code.
• Liên kết work order với asset và sensor timeline.
• Xác nhận ngày/giờ failure thực tế.
• Phân biệt symptom, cause và action.
• Loại dữ liệu sau khi bảo trì/cảm biến lỗi.

Khi chưa có đủ nhãn, anomaly detection hoặc rule/trend có thể là bước đầu, nhưng cảnh báo phải được SME xác nhận để tạo nhãn dần.

VI. Bốn mức trưởng thành của use case

Mức 1: Visibility

Thu dữ liệu, hiển thị trend, kiểm tra missing và xây baseline. Chưa gọi là predictive nhưng tạo nền quan trọng.

Mức 2: Rule và threshold

Cảnh báo theo ngưỡng kỹ thuật, rate-of-change hoặc kết hợp vài điều kiện. Dễ giải thích và kiểm chứng.

Mức 3: Anomaly detection

Mô hình học trạng thái bình thường theo chế độ vận hành và phát hiện lệch. Hữu ích khi failure label ít, nhưng có thể nhiều false positive.

Mức 4: Failure prediction/prognostics

Ước tính xác suất failure hoặc remaining useful life. Cần dữ liệu dài, nhiều failure tương tự và đánh giá nghiêm ngặt.

Không phải mọi asset cần đạt mức 4. Mức 2-3 có thể đủ để tránh sự cố.

VII. Kiến trúc tối thiểu

1. Sensor/PLC/SCADA thu tín hiệu.
2. Edge/gateway buffer, quality check và chuyển dữ liệu.
3. Historian/data platform lưu time series và context.
4. Analytics/model tạo health score hoặc cảnh báo.
5. CMMS nhận cảnh báo, tạo inspection/work order.
6. Kỹ thuật viên kiểm tra, xác nhận và ghi kết quả.
7. Feedback được dùng để điều chỉnh rule/model.

Nếu cảnh báo không đi vào CMMS/workflow, nó dễ nằm trên dashboard mà không ai hành động.

VIII. Thiết kế pilot theo failure mode

Bước 1: Business case

Ước tính downtime, sản lượng mất, chi phí sửa, phụ tùng và rủi ro. Xác định mức lợi ích cần đạt.

Bước 2: Technical feasibility

Kiểm tra failure mode, sensor, sampling, dữ liệu lịch sử, điều kiện vận hành và khả năng lắp đặt.

Bước 3: Baseline và data quality

Thu dữ liệu trong trạng thái bình thường, kiểm tra missing, drift, calibration và time sync.

Bước 4: Rule/model ban đầu

Bắt đầu đơn giản và có thể giải thích. So sánh với đánh giá chuyên gia.

Bước 5: Workflow cảnh báo

Ai nhận, trong bao lâu, kiểm tra gì, mức ưu tiên, khi nào tạo work order và khi nào đóng cảnh báo.

Bước 6: Đánh giá và quyết định mở rộng

Đánh giá kỹ thuật, vận hành và tài chính, không chỉ độ chính xác model.

IX. KPI kỹ thuật và vận hành

Accuracy chung có thể gây hiểu lầm khi failure hiếm. Precision, recall và false alarm phải được đặt trong ngữ cảnh chi phí.

X. Lead time và false alarm quan trọng hơn một con số “độ chính xác”

Một cảnh báo đúng nhưng chỉ đến trước failure vài phút có thể không đủ thời gian chuẩn bị. Một hệ thống phát hiện nhiều bất thường nhưng 90% không cần hành động sẽ làm người dùng bỏ qua.

Cần xác định:

• Lead time tối thiểu để tạo giá trị.
• Chi phí false negative - bỏ sót failure.
• Chi phí false positive - kiểm tra không cần thiết.
• Khả năng kỹ thuật viên xử lý lượng cảnh báo.

Threshold nên được tối ưu theo quyết định vận hành, không chỉ metric data science.

XI. Human-in-the-loop

AI nên gợi ý asset, signal và mức rủi ro; kỹ thuật viên chịu trách nhiệm kiểm tra và quyết định hành động. Giao diện cảnh báo nên cho biết:

• Tín hiệu nào bất thường.
• So với baseline nào.
• Thời điểm và xu hướng.
• Các event liên quan.
• Checklist kiểm tra gợi ý.
• Confidence/uncertainty nếu phù hợp.
• Cách phản hồi đúng/sai.

Feedback của kỹ thuật viên là dữ liệu quan trọng để cải thiện hệ thống.

XII. Tính business case

Một mô hình đơn giản:

Giá trị kỳ vọng = Xác suất tránh được failure × Thiệt hại mỗi failure × Số failure dự kiến - TCO use case

Thiệt hại nên gồm:

• Sản lượng mất.
• Chi phí tăng ca/khôi phục.
• Phế phẩm hoặc lỗi chất lượng.
• Phụ tùng và nhân công khẩn cấp.
• Ảnh hưởng giao hàng/an toàn.

Không nên tính toàn bộ downtime giảm là do AI nếu còn các cải tiến khác. Cần baseline và phương pháp attribution hợp lý.

XIII. Khi nào chưa nên làm predictive maintenance?

• Asset không critical hoặc có dự phòng dễ dàng.
• Failure quá hiếm, không có dữ liệu hoặc tín hiệu.
• PM cơ bản còn bị trễ và work order thiếu dữ liệu.
• Sensor khó lắp, không ổn định hoặc chi phí cao hơn lợi ích.
• Không có người nhận và xử lý cảnh báo.
• Nhà máy chưa biết failure mode cần dự báo.
• Hệ thống hiện tại chưa đo downtime và thiệt hại.

Trong những trường hợp này, ưu tiên CMMS, PM compliance, criticality, condition inspection hoặc rule-based monitoring.

XIV. Những sai lầm thường gặp

• Gắn cảm biến cho mọi máy.
• Chọn asset vì dễ lấy dữ liệu thay vì criticality.
• Không chuẩn hóa failure mode và work order.
• Huấn luyện model từ dữ liệu không đồng bộ thời gian.
• Không tách operating regime.
• Chỉ theo dõi model metric, không theo dõi action.
• Cảnh báo không có owner và SLA.
• Không bảo trì cảm biến.
• Kỳ vọng AI tự tạo ROI mà không thay đổi quy trình.

XV. Câu hỏi thường gặp

Cần bao nhiêu tháng dữ liệu để dự báo hỏng máy?

Không có con số chung. Phụ thuộc tần suất failure, chế độ vận hành và loại mô hình. Quan trọng là có đủ ví dụ trạng thái bình thường và failure đã xác nhận, không chỉ thời gian dài.

Không có nhiều failure label có làm được không?

Có thể bắt đầu bằng rule, trend hoặc anomaly detection, kết hợp chuyên gia xác nhận. Tuy nhiên, không nên gọi đó là dự báo failure chính xác nếu chưa có bằng chứng.

AI có thay thế chuyên gia rung động hoặc bảo trì không?

Không. AI có thể sàng lọc dữ liệu và ưu tiên kiểm tra; chuyên gia vẫn cần diễn giải, xác nhận và quyết định hành động.

Nên kết nối cảnh báo với CMMS không?

Nên nếu cảnh báo cần hành động bảo trì. CMMS giúp giao việc, ghi kết quả, theo dõi SLA và tạo feedback để đánh giá mô hình.