Thiết kế máy #39: Cảnh báo (alarm) cho bảo trì — Đừng chỉ báo “lỗi (error)”

Khi máy dừng, màn hình hiện “Cylinder lỗi (error)”. Người vận hành gọi bảo trì. Bảo trì mở giao diện người–máy (HMI), xem tủ điện, kiểm tra áp suất, dò cảm biến rồi hỏi: cylinder nào, đang chạy bước nào, lệnh đã phát chưa, tín hiệu nào không về?

Thông báo có vẻ đúng, nhưng gần như không giúp chẩn đoán.

Một hệ thống cảnh báo (alarm) tốt không chỉ nói rằng máy đang có lỗi. Nó giúp con người hiểu điều gì bất thường, ở đâu, máy đang mong đợi điều gì và bước kiểm tra an toàn tiếp theo là gì. Với máy tự động, chất lượng cảnh báo (alarm) ảnh hưởng trực tiếp đến thời gian dừng máy, nguy cơ thao tác nhầm và khả năng học từ lỗi lặp lại.

Bài này trình bày một khung thiết kế cảnh báo (alarm) thực dụng cho máy rời rạc. Đây không phải công thức gán priority hoặc chứng nhận tuân thủ. Mỗi máy vẫn cần cảnh báo (alarm) philosophy, đánh giá rủi ro và thẩm định (validation) phù hợp với ứng dụng thực tế.

1. Trước hết: không phải thông báo nào cũng là cảnh báo (alarm)

Nếu mọi trạng thái đều được gọi là cảnh báo (alarm), người dùng sẽ nhận quá nhiều thông báo và không còn biết điều gì thật sự cần phản ứng.

Có thể tách tối thiểu năm nhóm:

Loại	Ý nghĩa	Ví dụ
cảnh báo (alarm)	Điều kiện bất thường cần người vận hành hoặc bảo trì phản ứng trong thời gian xác định	Cơ cấu không đạt vị trí sau khi đã có lệnh
Event	Sự kiện cần lưu để truy vết, không nhất thiết cần hành động ngay	Chuyển Auto sang Manual
Status	Trạng thái hiện tại của máy	Đang chờ phôi
Prompt	Hướng dẫn người dùng hoàn thành một bước	Đóng cửa và nhấn xác nhận
Maintenance reminder	Nhắc việc bảo trì theo điều kiện hoặc chu kỳ	Kiểm tra bộ lọc sau số giờ vận hành

Một tín hiệu “cửa đang mở” khi máy ở chế độ nạp phôi có thể chỉ là status. Cùng tín hiệu đó, nếu chu trình tự động đang yêu cầu vùng nguy hiểm được bảo vệ, có thể tạo điều kiện dừng và thông báo cần phản ứng. Ý nghĩa phụ thuộc vào trạng thái máy và mục đích của thông báo, không chỉ phụ thuộc vào tên input.

2. Vì sao “Cylinder lỗi (error)” là một cảnh báo (alarm) yếu?

Thông báo này thiếu gần như toàn bộ context mà người xử lý cần:

Không chỉ rõ cơ cấu hoặc vị trí.
Không nói lệnh nào đã được phát.
Không nói feedback nào đang thiếu hoặc mâu thuẫn.
Không cho biết thời gian chờ (timeout) bao lâu và xảy ra ở bước nào.
Không phân biệt nguyên nhân đầu tiên với các lỗi phát sinh sau đó.
Không đề xuất điểm kiểm tra tiếp theo.

Kết quả là thời gian khôi phục phụ thuộc vào trí nhớ của một vài người có kinh nghiệm. Khi họ không có mặt, đội bảo trì phải dựng lại trạng thái máy từ đầu.

cảnh báo (alarm) tốt biến tri thức chẩn đoán thành một phần của thiết kế máy.

3. Cấu trúc một thông điệp có thể hành động

Một mẫu thực dụng là:

[Đối tượng] — [trạng thái bất thường]. Mong đợi [điều kiện]. Kiểm tra [bước an toàn tiếp theo].

Ví dụ yếu:

Cylinder lỗi (error).

Ví dụ tốt hơn:

Cụm chặn phôi đầu vào — chưa xác nhận vị trí nâng sau lệnh nâng. Kiểm tra áp suất cấp và cảm biến vị trí nâng.

Ví dụ tốt hơn nữa khi giao diện người–máy (HMI) có vùng chi tiết:

Đối tượng: Cụm chặn phôi đầu vào.
Command tại thời điểm lỗi: Nâng.
Feedback mong đợi: Vị trí nâng.
Feedback thực tế: Vị trí hạ vẫn ON.
Bước máy: Chờ cố định phôi.
Gợi ý: Kiểm tra áp suất, kẹt cơ khí và trạng thái cảm biến từ ngoài vùng nguy hiểm.

Gợi ý không nên biến thành hướng dẫn tháo lắp hoặc vượt qua biện pháp bảo vệ. giao diện người–máy (HMI) chỉ nên đưa người dùng tới bước chẩn đoán an toàn kế tiếp, còn quy trình can thiệp phải nằm trong tài liệu và thẩm quyền phù hợp.

4. cảnh báo (alarm) nên giữ context tại đúng thời điểm xảy ra lỗi

Nếu chỉ hiển thị trạng thái hiện tại, bằng chứng có thể mất ngay sau khi máy dừng hoặc người dùng chuyển mode.

Khi cảnh báo (alarm) xuất hiện, nên lưu một context snapshot phù hợp:

Thời gian xảy ra.
Mode và trạng thái chu trình.
Step hoặc phase đang chạy.
Command liên quan.
Feedback mong đợi và feedback thực tế.
Giá trị timer tại thời điểm thời gian chờ (timeout).
Model, công thức sản xuất (recipe) hoặc mã cấu hình đang dùng.
Trạng thái các điều kiện cho phép (permissive) liên quan.
cảnh báo (alarm) gốc và các cảnh báo (alarm) phát sinh sau đó.

Không nhất thiết đưa tất cả lên dòng cảnh báo (alarm) chính. giao diện người–máy (HMI) có thể tổ chức theo ba lớp:

Danh sách cảnh báo (alarm): ngắn, dễ quét.
Chi tiết cảnh báo (alarm): context và gợi ý kiểm tra.
Lịch sử/chẩn đoán: dữ liệu phục vụ phân tích sâu.

Tách lớp giúp màn hình vận hành không bị biến thành trang debug, đồng thời bảo trì vẫn có đủ dữ liệu khi cần.

5. Giữ “cảnh báo đầu tiên (first-out)”: đừng để hậu quả che mất nguyên nhân

Một lỗi gốc có thể tạo ra hàng loạt cảnh báo (alarm):

Cụm nâng không đạt vị trí.
Robot không được phép vào.
Chu trình thời gian chờ (timeout).
Trạm sau thiếu phôi.
Máy tổng dừng.

Nếu danh sách chỉ sắp theo thời gian mới nhất, người dùng có thể thấy “trạm sau thiếu phôi” trước và đi kiểm tra sai chỗ.

Thiết kế nên nhận diện và giữ cảnh báo đầu tiên (first-out) — điều kiện đầu tiên khiến chuỗi vận hành thất bại. Các cảnh báo (alarm) hậu quả vẫn có thể được ghi nhận, nhưng phải liên kết hoặc phân nhóm để nguyên nhân ban đầu không bị chìm.

Điều này không có nghĩa cảnh báo (alarm) đầu tiên luôn là root cause vật lý. “Cụm nâng không đạt vị trí” vẫn có thể do mất khí, kẹt cơ khí, cảm biến lệch hoặc đầu ra không hoạt động. cảnh báo đầu tiên (first-out) giúp thu hẹp điểm bắt đầu chẩn đoán, không thay thế việc điều tra nguyên nhân.

6. Phân biệt acknowledge, condition clear và đặt lại (reset)

Ba hành động này thường bị trộn lẫn:

Acknowledge: người dùng xác nhận đã nhận biết cảnh báo (alarm).
Condition clear: điều kiện gây cảnh báo (alarm) không còn tồn tại.
đặt lại (reset): hệ thống thực hiện bước khôi phục trạng thái logic theo thiết kế.

Acknowledge không làm lỗi vật lý biến mất. Condition clear không tự động chứng minh máy đã an toàn để chạy. đặt lại (reset) cũng không nên mặc nhiên tạo lệnh khởi động ngoài ý muốn.

giao diện người–máy (HMI) nên thể hiện rõ:

cảnh báo (alarm) chưa được nhận biết.
cảnh báo (alarm) đã được nhận biết nhưng điều kiện vẫn còn.
Điều kiện đã hết nhưng cần đặt lại (reset).
Máy đã sẵn sàng và vẫn cần lệnh start riêng.

Cách tách này giúp vận hành hiểu đúng trạng thái, đồng thời tránh dùng nút đặt lại (reset) như một thao tác “thử chạy lại xem sao”.

7. Priority phải dựa trên phản ứng cần thiết

Màu đỏ cho mọi lỗi là một thiết kế dễ làm nhưng ít giá trị. Priority nên phản ánh:

Hậu quả nếu không phản ứng.
Thời gian còn lại để phản ứng.
Hành động cụ thể mà người nhận phải làm.
Vai trò nào có khả năng thực hiện hành động đó.

Không nên sao chép cứng một bảng priority từ dự án khác. Một cảnh báo quan trọng trong nhà máy quá trình có thể không tương đương với một cảnh báo (alarm) trên máy lắp ráp rời rạc. Ngưỡng và quy tắc cần được định nghĩa trong cảnh báo (alarm) philosophy của hệ thống.

Nguyên tắc đơn giản để rà soát: nếu không xác định được người nhận, thời gian phản ứng và hành động mong đợi, có thể đó chưa phải cảnh báo (alarm) — có thể chỉ là event, status hoặc diagnostic.

8. Thiết kế theo ownership: ai sẽ xử lý?

Một cảnh báo (alarm) tốt cần phù hợp với vai trò:

Người vận hành

Nhìn thấy đối tượng và trạng thái bất thường.
Thực hiện được bước kiểm tra bên ngoài vùng nguy hiểm.
Biết khi nào không được tiếp tục đặt lại (reset).
Biết khi nào phải gọi bảo trì.

Bảo trì

Có context snapshot và cảnh báo đầu tiên (first-out).
Phân biệt được command, feedback, thời gian chờ (timeout) và điều kiện cho phép (permissive).
Xem được lịch sử lỗi lặp lại.
Tiếp cận tài liệu chẩn đoán đã được phê duyệt.

Kỹ thuật/engineering

Có dữ liệu để tìm pattern theo model, step hoặc điều kiện vận hành.
Biết cảnh báo (alarm) nào thường xuyên xuất hiện nhưng không tạo hành động.
Quản lý thay đổi message, logic, priority và delay.
Có thể kiểm tra lại sau khi sửa thiết kế.

Không nên hiển thị cùng một lượng chi tiết cho mọi người. Nhưng hệ thống phải giữ một chuỗi thông tin nhất quán, tránh tình trạng màn hình vận hành nói một kiểu còn chương trình hoặc tài liệu bảo trì dùng tên khác.

9. thời gian chờ (timeout) cần gắn với vật lý, không chỉ là một con số

cảnh báo (alarm) thời gian chờ (timeout) thường được viết theo mẫu: phát lệnh, đợi tín hiệu, quá thời gian thì báo lỗi. Vấn đề là timer dễ trở thành “con số chỉnh đến khi máy chạy”.

Trước khi đặt thời gian chờ (timeout), cần hiểu:

Thời gian chuyển động bình thường và độ phân tán.
Ảnh hưởng của tải, áp suất, nhiệt độ và model.
Thời gian đáp ứng của cảm biến (sensor) và bộ điều khiển.
Điều kiện nào khiến timer được bắt đầu, tạm dừng hoặc hủy.
Khi thời gian chờ (timeout) xảy ra, cơ cấu đang ở trạng thái năng lượng nào.

Delay quá ngắn tạo nuisance cảnh báo (alarm). Delay quá dài làm tăng thời gian phát hiện lỗi và có thể kéo theo va chạm hoặc mất nhịp sản xuất. Giá trị phải được xác minh bằng thử nghiệm phù hợp, không suy đoán từ một chu kỳ đẹp nhất.

10. Đừng chỉ lưu cảnh báo (alarm); hãy học từ lịch sử

cảnh báo (alarm) history có giá trị khi trả lời được câu hỏi vận hành:

cảnh báo (alarm) nào xuất hiện nhiều nhất?
cảnh báo (alarm) nào tồn tại lâu nhất?
cảnh báo (alarm) nào thường xuất hiện cùng nhau?
Model hoặc công đoạn nào có tỷ lệ cảnh báo (alarm) cao?
Sau acknowledge mất bao lâu để condition clear?
Sau condition clear mất bao lâu để máy trở lại sản xuất?
cảnh báo (alarm) nào bị lặp lại sau đặt lại (reset)?

Một số nhóm cần theo dõi:

Nuisance cảnh báo (alarm): xuất hiện nhưng hiếm khi cần hành động.
Chattering cảnh báo (alarm): bật/tắt liên tục.
Standing cảnh báo (alarm): tồn tại quá lâu và bị xem như trạng thái bình thường.
Repeated cảnh báo (alarm): lặp lại theo cùng điều kiện vận hành.
Stale message: mô tả không còn đúng sau khi máy đã được sửa đổi.

Mục tiêu không phải làm dashboard thật nhiều. Mục tiêu là tạo một vòng lặp: đo — chọn vấn đề — tìm nguyên nhân — sửa — xác minh — quản lý thay đổi.

11. Checklist thiết kế cảnh báo (alarm) cho một cơ cấu

Trước khi phát hành, có thể kiểm tra:

Đây thực sự là cảnh báo (alarm) hay chỉ là event/status/prompt?
Có người hoặc vai trò rõ ràng phải phản ứng không?
Thông điệp chỉ rõ đối tượng và trạng thái bất thường chưa?
Có nêu điều kiện mong đợi không?
Có bước kiểm tra an toàn tiếp theo không?
Có lưu command và feedback tại thời điểm lỗi không?
Có lưu mode, step, model/công thức sản xuất (recipe) liên quan không?
Có xác định cảnh báo đầu tiên (first-out) và quan hệ với cảnh báo (alarm) hậu quả không?
Acknowledge, condition clear và đặt lại (reset) có được tách rõ không?
thời gian chờ (timeout) đã được xác minh theo điều kiện thực tế chưa?
Priority có theo cảnh báo (alarm) philosophy và phản ứng cần thiết không?
cảnh báo (alarm) có thể được tìm kiếm trong history bằng tên nhất quán không?
Thay đổi cảnh báo (alarm) có nằm trong quản lý thay đổi không?

Checklist không thay thế thử nghiệm. Nó chỉ giúp phát hiện sớm những thông báo mơ hồ trước khi máy đi vào vận hành.

12. Nghiệm thu bằng kịch bản lỗi có kiểm soát

Đừng chờ tới sản xuất mới biết cảnh báo (alarm) có hữu ích hay không. Trong kế hoạch thẩm định (validation), hãy chuẩn bị các kịch bản lỗi đại diện và thực hiện trong điều kiện được kiểm soát bởi người có thẩm quyền.

Với mỗi kịch bản, kiểm tra:

Máy phản ứng đúng theo thiết kế.
cảnh báo (alarm) gốc xuất hiện đúng thời điểm.
Thông điệp xác định đúng đối tượng.
Context snapshot giữ được command và feedback cần thiết.
cảnh báo (alarm) hậu quả không che mất cảnh báo đầu tiên (first-out).
Hướng dẫn không khuyến khích thao tác không an toàn.
Acknowledge và đặt lại (reset) hoạt động đúng vai trò.
History ghi đủ dữ liệu để điều tra sau đó.

Mời chính người vận hành và bảo trì tham gia review. Một message rõ với lập trình viên chưa chắc đã rõ với người đang đứng trước máy lúc 2 giờ sáng.

Kết luận

cảnh báo (alarm) không phải phần trang trí thêm vào sau khi logic máy đã xong. Nó là giao diện giữa trạng thái kỹ thuật của máy và quyết định của con người.

Một cảnh báo (alarm) có giá trị cần trả lời bốn câu hỏi:

Điều gì bất thường?
Nó xảy ra ở đâu và trong context nào?
Máy đã mong đợi điều gì?
Bước kiểm tra an toàn tiếp theo là gì?

Khi kết hợp thông điệp có thể hành động, context snapshot, cảnh báo đầu tiên (first-out), ownership rõ ràng và review lịch sử, đội bảo trì không còn phải bắt đầu từ một chữ “lỗi (error)”. Họ có một điểm xuất phát đáng tin cậy để phục hồi máy nhanh hơn và ngăn lỗi lặp lại.

Nguồn tham khảo

IEC 62682:2022 — Management of cảnh báo (alarm) systems for the quy trình (process) industries: https://webstore.iec.ch/en/publication/65543
ISA-18 Series of Standards: https://www.isa.org/standards-and-publications/isa-standards/isa-18-series-of-standards
EEMUA Publication 191, Fourth Edition — cảnh báo (alarm) systems: a guide to design, management and procurement: https://eemua.org/products/publications/digital/eemua-publication-191
EEMUA cảnh báo (alarm)-philosophy checklist: https://www.eemua.org/products/publications/checklists/eemua-alarms-checklist

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