Thiết kế pilot PHM cho thiết bị quay: từ tín hiệu đến quyết định bảo trì

01

Chọn một failure mode và một nhóm thiết bị

Chọn bơm, quạt hoặc máy nén có lịch sử đủ dùng, cơ chế hư hỏng quan sát được và hành động khả thi. Ghi rõ thiết bị nào nằm ngoài phạm vi. Tránh hứa “dự báo mọi hư hỏng” khi cảm biến chỉ nhìn được một phần cơ chế.

02

Thiết kế chuỗi dữ liệu

Lập bản đồ asset ID, tag historian, sampling rate, operating state, work history, inspection và failure event. Đồng bộ thời gian và ghi nhận gap, sensor change, shutdown và chế độ vận hành. Một cảnh báo đúng trong giai đoạn startup có thể là cảnh báo sai nếu mô hình được huấn luyện chỉ trên steady state.

03

Đo theo sự kiện và khả năng hành động

Tách training và validation theo thời gian và theo thiết bị khi có thể. Báo false alarms trên mỗi asset-month, lead time trước sự kiện, tỷ lệ sự kiện phát hiện được, và thời gian kỹ sư cần để xác minh. Độ chính xác tổng hợp một mình không cho biết đội bảo trì có dùng được cảnh báo hay không.

04

Đường đi của một alert

Mỗi alert cần evidence: trend, operating context, cơ chế nghi ngờ và độ tin cậy. Người phụ trách xác minh, ghi disposition, tạo Work Request hoặc Work Order khi cần, và phản hồi kết quả inspection. Không tự động biến mọi anomaly thành Work Order.

05

Tiêu chí mở rộng

Pilot chỉ nên mở rộng khi có baseline, số alert có thể xử lý, luồng phản hồi khép kín và giá trị đo được như tránh dừng máy, giảm kiểm tra không cần thiết hoặc rút thời gian chẩn đoán. Nếu số failure event quá ít, hãy công bố giới hạn đánh giá thay vì suy diễn ROI.

06

Thiết lập baseline và failure event

Trước khi chọn thuật toán, thống nhất thế nào là một failure event: trip, chức năng suy giảm, can thiệp khẩn cấp hay phát hiện khi overhaul. Work Order thường ghi ngày sửa, không phải thời điểm hư hỏng bắt đầu; dùng nó làm nhãn trực tiếp có thể làm sai lead time. Cần một event register do reliability engineer duyệt, liên kết asset ID, failure mode, symptom, thời điểm phát hiện, hành động và kết quả xác minh.

Baseline nên bao gồm số lần dừng máy, thời gian phát hiện và xử lý, khối lượng kiểm tra định kỳ, chi phí can thiệp và số cảnh báo hiện tại. Tách planned shutdown, startup, load change và sensor fault. Nếu lịch sử failure quá ít, pilot có thể đánh giá chất lượng phát hiện bất thường và workflow triage, nhưng chưa đủ bằng chứng để ước lượng recall hay ROI dựa trên sự kiện hiếm.

07

Xây dựng pipeline có thể kiểm toán

Dữ liệu rung, nhiệt độ, áp suất và dòng điện phải gắn với operating state. Một ngưỡng áp dụng cho mọi load thường tạo báo giả. Pipeline cần lưu tag mapping, đơn vị đo, tần suất, bước lọc, quy tắc gap và version của feature. Khi sensor được thay hoặc calibrated, đánh dấu mốc thay đổi để tránh coi biến đổi của phép đo là biến đổi của thiết bị.

Chia dữ liệu huấn luyện và kiểm định theo thời gian, đồng thời kiểm tra rò rỉ thông tin từ cùng một sự kiện qua nhiều cửa sổ dữ liệu. Đánh giá thêm theo từng asset và từng operating mode, vì điểm trung bình tốt có thể che một nhóm thiết bị thường xuyên báo sai. Một case review nên cho kỹ sư xem trend trước và sau alert, điều kiện vận hành, Work Order liên quan và lý do model đưa ra tín hiệu.

08

Biến alert thành quyết định có trách nhiệm

Thiết kế ba mức xử lý ví dụ: cần kiểm tra dữ liệu/cảm biến, cần theo dõi tăng cường, hoặc cần engineering review để lập Work Request. Mỗi mức có thời hạn phản hồi, người chịu trách nhiệm và bằng chứng tối thiểu. Ghi disposition: true concern, process transient, sensor issue, known condition hoặc chưa kết luận. Điều này quan trọng hơn việc có thêm một dashboard vì nó tạo nhãn phản hồi cho các vòng cải tiến.

Go/no-go cần dựa trên khả năng đội vận hành tiếp nhận: số alert mỗi asset-month, thời gian triage, lead time hữu ích, tỷ lệ alert có disposition, tác động lên kế hoạch bảo trì và giới hạn chưa chứng minh. Nếu không có đủ sự kiện để chứng minh lợi ích tài chính, báo kết quả theo bằng chứng quan sát được và đề xuất giai đoạn kéo dài với điều kiện rõ ràng. Không nhân kết quả của một thiết bị lên toàn fleet khi duty cycle và dữ liệu khác nhau.

09

Ví dụ minh họa: cảnh báo trên bơm dự phòng

Giả sử pilot theo dõi một nhóm bơm vận hành luân phiên. Một bơm phát tín hiệu rung cao sau khi đổi chế độ chạy. Pipeline đánh dấu operating state và sensor status; kỹ sư thấy rung chỉ tăng trong startup nên không tạo Work Order ngay. Sau vài chu kỳ, cùng dấu hiệu kéo dài sang steady state và đi kèm nhiệt độ bearing tăng. Alert được nâng mức, kỹ sư mở Work Request kiểm tra lubrication và alignment. Inspection tìm thấy một vấn đề có thể xử lý; kết quả cùng ngày và điều kiện vận hành được trả về event register. Khi báo cáo pilot, nhóm tính số alert cần xử lý, thời gian xác minh, lead time hữu ích và những case không kết luận. Không suy ra độ chính xác dự báo toàn fleet từ riêng sự kiện này.