Học Automation cùng MINATA #55: Thiết kế cảnh báo HMI: một alarm tốt phải dẫn tới hành động

Thiết kế cảnh báo HMI: một alarm tốt phải dẫn tới hành động

Một alarm tốt phải dẫn người vận hành tới hành động đúng, không chỉ báo "có gì đó sai". Màn hình đầy alarm cùng mức, tên khó hiểu và không gợi ý xử lý sẽ dạy người vận hành thói quen bấm xác nhận cho hết rồi bỏ qua — kể cả lúc lỗi thật sự quan trọng.

Phân mức ưu tiên theo hậu quả

Không dùng cùng một mức cho mất an toàn, cảnh báo bảo trì và thông báo vận hành. Phân mức theo hậu quả và thời gian phải phản ứng:

Mức	Ý nghĩa	Người vận hành làm gì
Nguy cấp	Mất an toàn, dừng máy	Can thiệp ngay
Cao	Sự cố làm dừng chu trình	Xử lý sớm, có thể cần bảo trì
Cảnh báo	Sắp tới ngưỡng, bảo trì	Theo dõi, lên kế hoạch
Thông tin	Sự kiện vận hành	Ghi nhận, không cần can thiệp

Tên alarm phải nói được ba điều

Tên và nội dung alarm nên nêu: thiết bị nào, điều kiện gì, và bước xử lý đầu tiên. "Băng tải nạp: quá thời gian chờ phôi — kiểm tra cảm biến B3 và nguồn phôi" hữu ích hơn nhiều so với "Error 102". Người ca đêm không có sơ đồ mã lỗi trong đầu.

Chống alarm flood

Khi một sự cố gốc kéo theo hàng loạt alarm phụ, người vận hành mất dấu nguyên nhân. Giảm flood bằng cách: nhóm alarm theo nguyên nhân gốc, thêm trễ hợp lý cho tín hiệu dao động, và không tạo alarm cho những điều kiện không cần can thiệp. Mục tiêu là mỗi alarm còn lại đều đáng để nhìn.

Ghi log để cải tiến

Log thời điểm alarm xuất hiện, được xác nhận và xóa. Dữ liệu này cho biết alarm nào kêu nhiều nhất, alarm nào bị bỏ qua lâu, và chỗ nào nên sửa thiết kế thay vì để người vận hành chịu đựng.

Tình huống kỹ thuật tham khảo

Khi một băng tải bị timeout chờ phôi, HMI hiển thị vị trí băng tải, cảm biến cần kiểm tra và bước máy đang dừng, thay vì chỉ một mã "Error 102". Người vận hành đi thẳng tới điểm cần xem; log alarm sau một tuần cho thấy cảm biến đó kêu nhiều, dẫn tới quyết định chỉnh vị trí lắp.

Danh mục alarm, mức ưu tiên và nội dung cuối cùng phải theo triết lý alarm của hệ thống và yêu cầu vận hành.

Sai lầm thường gặp

Mọi alarm cùng một mức, không phân theo hậu quả.
Tên alarm là mã số, không nêu thiết bị và cách xử lý.
Alarm flood khi một sự cố kéo theo hàng loạt báo phụ.
Tạo alarm cho điều kiện không cần can thiệp, gây nhiễu.
Không log để biết alarm nào cần cải tiến.

Checklist thiết kế cảnh báo HMI

[ ] Alarm phân mức theo hậu quả và thời gian phản ứng.
[ ] Nội dung nêu thiết bị, điều kiện và bước xử lý đầu tiên.
[ ] Có cơ chế chống flood, nhóm theo nguyên nhân gốc.
[ ] Log thời điểm xuất hiện/xác nhận/xóa.
[ ] Rà log định kỳ để cải tiến thiết kế alarm.

Alarm dẫn tới hành động là alarm đáng tin. Bài #56 mở rộng lên giám sát SCADA, biến trạng thái nhiều máy thành thông tin vận hành.

Đọc thêm kiến thức tự động hóa tại MINATA: https://minatavn.com/vi/blog/tu-dong-hoa

Bài liền trước — #54: Sao lưu chương trình PLC: bản backup chỉ có giá trị khi khôi phục được: https://minatavn.com/vi/blog/hoc-automation-cung-minata-54-sao-luu-chuong-trinh-plc

Bài tiếp theo — #56: Giám sát SCADA: biến trạng thái máy thành thông tin vận hành: https://minatavn.com/vi/blog/hoc-automation-cung-minata-56-giam-sat-scada

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