Predictive maintenance: đi từ cảm biến rung đến work order mà kỹ thuật viên chịu làm

Thử hình dung tuần thứ ba sau khi hệ thống giám sát rung đi vào chạy thật. Người lập kế hoạch bảo trì của nhà máy đã đặt một bộ lọc email chuyển hết cảnh báo vào một thư mục riêng, và anh ấy không mở thư mục đó nữa. Dashboard vẫn xanh đỏ đầy đủ, mô hình vẫn chạy, nhưng chẳng còn ai làm theo nó.

Kịch bản đó khớp với hai nguyên nhân thất bại mà giới bảo trì hay nhắc tới, và cả hai đều không nằm ở mô hình. Reliable Magazine nhận định báo động giả quá nhiều là một trong những nguyên nhân hàng đầu khiến chương trình PdM thất bại. Chương trình cũng hay đổ vỡ khi kỹ thuật viên và kỹ sư không được kéo vào quá trình triển khai.

Nếu bạn là FDE được cử đến nhà máy, phần việc quyết định thành bại không nằm ở notebook. Nó nằm ở khâu biến một con số rung thành một work order mà kỹ thuật viên tin là đáng làm. Khâu này hoàn toàn dựng được, với điều kiện bạn làm từng bước theo đúng thứ tự.

Thu thập dữ liệu chưa phải là chiến lược bảo trì

GroundUp chỉ ra một lỗi gốc: nhiều chương trình nhầm việc thu thập dữ liệu với chiến lược bảo trì. Cảm biến được lắp, dữ liệu đổ về, rồi số đo rơi vào tay một kỹ sư vốn đã quá tải, phải tự diễn giải một mình, thường đúng lúc tệ nhất.

Vì thế sản phẩm thật của bạn là một chuỗi quyết định chứ không phải mô hình. Mỗi số đo phải đi qua ba cửa trước khi thành việc cho người khác: có bất thường không, bất thường đó đã được xác nhận chưa, và rủi ro có đủ lớn để lên lịch sửa không.

IVC Technologies diễn đạt nguyên tắc này rất gọn: work order được tạo từ rủi ro đã xác nhận, không phải từ tín hiệu sơ bộ.

Ngưỡng nào thì đúng cho máy nào?

Cửa đầu tiên cần một ngưỡng, và đây là chỗ nhiều đội làm sai ngay từ đầu. ISO 20816 là tiêu chuẩn hiện hành để đánh giá rung cơ khí đo trên các bộ phận không quay của máy, có các phần riêng cho từng nhóm máy.

James Otremba của Acoem USA nhấn mạnh rằng giới hạn ISO nên được dùng làm hướng dẫn đánh giá, không phải con số đạt/trượt áp cho mọi máy.

Cách tốt hơn là kết hợp hai lớp. Lớp thứ nhất là ngưỡng theo loại máy, vì một máy bơm và một quạt lớn không rung giống nhau. Lớp thứ hai là cảnh báo thống kê hoặc theo baseline, đặt giới hạn quanh hành vi thực tế của chính máy đó.

ISO 20816 còn cho bạn một mốc rất hữu ích để ánh xạ sang quy trình bảo trì.

Tiêu chuẩn chia mức rung thành các vùng A, B, C, D. Vùng C nghĩa là máy không còn đạt để chạy liên tục, nhưng có thể chạy thêm một thời gian giới hạn cho đến khi lên lịch khắc phục được.

Mô tả đó khớp gần như hoàn hảo với một work order có kế hoạch.

Ví dụ: một máy bơm nước làm mát

Hãy thử với một con số. Giả sử cảm biến không dây trên máy bơm P-101 đo 10 phút một lần, tức 144 lần mỗi ngày. Nếu chỉ 2% số lần đo vượt ngưỡng vì nhiễu, mỗi ngày máy này đã sinh gần 3 cảnh báo; nhân lên 20 máy là gần 58 cảnh báo một ngày.

Nếu mỗi cảnh báo đều thành work order, backlog sẽ phình ra trong một tuần và planner sẽ đặt bộ lọc email như trong đoạn mở đầu. IVC Technologies khuyên đặt quy tắc rõ ràng cho việc khi nào cảnh báo trở thành work request, chính là để tránh phình backlog và quá tải người lập kế hoạch. Đây là một phiên bản đơn giản của quy tắc ấy:

def decide(asset, readings, route_check):
    limit = asset.baseline_limit  # học từ lịch sử của chính máy này
    recent = readings[-6:]        # 6 lần đo gần nhất, khoảng 1 giờ
    over = [r for r in recent if r.velocity > limit]

    if len(over) < 4:
        return "WATCH"            # thoáng qua: ghi nhận, không tạo việc
    if route_check is None:
        return "REQUEST_ROUTE"    # nhờ kỹ thuật viên đo tay ở ca tới
    if route_check.confirms and route_check.zone == "D":
        return "ESCALATE"         # không bao giờ để rơi về WATCH: báo ngay người phụ trách
    if route_check.confirms and route_check.zone == "C":
        return "PLANNED_WO"       # rủi ro đã xác nhận: lên lịch sửa
    return "WATCH"

Đoạn code này chỉ thiết kế kỹ cho vùng C, vì đó là vùng ánh xạ tự nhiên sang work order có kế hoạch.

Nhánh vùng D chỉ làm một việc: không để một số đo đã xác nhận ở vùng nặng nhất lặng lẽ quay về WATCH, mà chuyển ngay cho kỹ sư phụ trách quyết định.

Bước REQUEST_ROUTE không phải chuyện thừa. IVC Technologies cho rằng chương trình lai, kết hợp cảm biến không dây với đo tay theo tuyến, giúp tránh tạo work order cho những tình trạng thoáng qua hoặc không quan trọng. Kỹ thuật viên đi đo cũng có lý do để tin kết quả, vì chính họ đã xác nhận nó.

Cảnh báo phải tự giải thích được

Qua đủ ba cửa rồi, cảnh báo vẫn còn một bước nữa trước khi đến tay kỹ thuật viên: viết nó ra sao cho người đọc hiểu ngay.

Reliable Magazine nhận xét đội bảo trì hiếm khi tin mô hình hộp đen, còn LLumin cho rằng cảnh báo không có ngữ cảnh chỉ là tiếng ồn: muốn hành động được thì phát hiện bất thường phải giải thích được.

Một work order cho P-101 nên đọc như thế này:

P-101, ổ trục phía motor. Rung vượt baseline của chính máy ở 4/6 lần đo trong giờ qua, xu hướng tăng dần. Đo tay ca sáng xác nhận vùng C theo ISO 20816. Đề xuất kiểm tra ổ trục trong lần dừng máy theo kế hoạch gần nhất.

Khi đóng việc, kỹ thuật viên chọn một trong ba mã: tìm thấy lỗi như dự đoán, tìm thấy lỗi khác, hoặc không thấy gì.

LLumin mô tả việc đưa dữ liệu kết quả này ngược lại hệ thống cảnh báo là cách để cảnh báo sau chính xác hơn. Mã “không thấy gì” có giá trị nhất, vì nó cho bạn biết baseline của máy nào đang đặt quá chặt.

Làm từng bước tại khách hàng

Việc đầu tiên là ngồi với kỹ thuật viên và người lập kế hoạch bảo trì trước khi viết dòng code nào. Hỏi họ máy nào hay hỏng, họ đang đo tay theo tuyến ra sao, và một tuần họ xử lý được bao nhiêu work request. Con số cuối cùng chính là ngân sách cảnh báo của bạn.

Sau đó, nhóm tài sản theo loại máy để áp phần ISO 20816 phù hợp làm hướng dẫn. Cho hệ thống học baseline của từng máy trong một khoảng thời gian chạy ổn định. Rồi viết quy tắc chuyển cảnh báo thành work request cùng planner, để họ là người đồng sở hữu chứ không phải người chịu trận.

Nhánh ESCALATE cũng cần được chốt bằng văn bản với khách hàng, vì code chỉ chuyển tiếp chứ không quyết định thay ai. Nên thống nhất ba điều: ai nhận cảnh báo vùng D ở từng ca, họ phải phản hồi trong bao lâu, và ai có quyền quyết định dừng máy. Để trống ba điều đó, cảnh báo nghiêm trọng nhất lại dễ rơi vào khoảng không nhất.

Cuối cùng, chốt mẫu cảnh báo và bộ mã kết quả trong CMMS trước ngày go-live. Nếu khách hàng chưa có trường để ghi kết quả, hãy đề xuất thêm ngay từ đầu, vì thiếu nó thì vòng phản hồi không bao giờ khép lại.

Những lỗi khiến cả chương trình mất uy tín

Lỗi hay gặp nhất là bật cảnh báo cho mọi máy cùng một lúc với cùng một ngưỡng ISO. Kế đến là đẩy cảnh báo thẳng vào CMMS mà không qua bước xác nhận. Rồi gửi một con số trần trụi kèm biểu đồ và chờ kỹ sư tự hiểu.

Cả ba lỗi đều tốn kém hơn vẻ ngoài của chúng. GroundUp cảnh báo rằng niềm tin một khi đã mất thì rất khó lấy lại. Vì thế nên bắt đầu với vài máy quan trọng, ít cảnh báo nhưng cảnh báo nào cũng đúng, rồi mới mở rộng.

Đây cũng là kỹ năng bạn nên làm cho nhìn thấy được khi đi xin việc. Nếu nhắm tới vai FDE trong mảng công nghiệp, hãy đọc kỹ mô tả công việc xem có nhắc đến CMMS, IIoT hay phân tích rung không, rồi kể trong CV một lần bạn biến tín hiệu thành việc mà người vận hành thật sự làm theo.

Thước đo của một deployment PdM không nằm ở độ chính xác trên tập test. Nó nằm ở chuyện sáu tháng sau, planner còn mở email cảnh báo hay không.