Thiết kế máy #71: Sequence và phục hồi sau fault — Đừng dùng Reset để xóa mọi dấu vết
Khi máy lỗi giữa chu kỳ, câu hỏi quan trọng không phải chỉ là “làm sao chạy lại”, mà là trạng thái vật lý, phôi và quyền sở hữu đang nằm ở đâu.
Bài viết tiếp nối nhóm state machine/interface control, tập trung vào contract vận hành và bằng chứng cần giữ trong toàn bộ vòng đời máy.
1. Vì sao chủ đề này dễ bị làm quá đơn giản?
Trong giai đoạn chạy thử, nhóm dự án thường ưu tiên đưa máy về trạng thái chạy được. Các ngoại lệ, dữ liệu và quyền truy cập được xử lý bằng timer, bit reset hoặc hướng dẫn miệng. Khi máy sang production, những quyết định tạm thời trở thành behavior thật nhưng không có owner và tiêu chí kiểm chứng.
Một thiết kế có thể bảo trì cần trả lời: trạng thái nào tồn tại, ai có quyền ra quyết định, dữ liệu nào là nguồn sự thật, failure được phản ứng ra sao và bằng chứng nào chứng minh hệ thống đã trở về baseline.
2. Fault không đồng nghĩa quay về bước đầu
Nếu mọi fault đều đưa StepNo về 0, chương trình đánh mất vị trí đã xác nhận, phôi đang giữ, tài nguyên đã cấp và hành động đã hoàn thành. Recovery phải bắt đầu bằng việc bảo toàn context, không phải xóa context.
Các quyết định cần được ghi trong requirement, architecture, configuration hoặc test case tương ứng; không để chỉ tồn tại trong comment PLC hay kinh nghiệm của một người.
3. Phân loại trạng thái sau lỗi
Tách ba nhóm: trạng thái nhất quán có thể tiếp tục; trạng thái mơ hồ nhưng có thể xác minh; và trạng thái không xác định cần can thiệp. Mỗi nhóm có quyền chuyển động, yêu cầu xác nhận và đường thoát khác nhau.
4. Checkpoint phải có ý nghĩa vật lý
Checkpoint tốt gắn với bằng chứng: phôi đã qua mặt chuẩn, gripper đã xác nhận, station sau đã nhận transaction. Không nên đặt checkpoint chỉ vì code vừa chạy hết một đoạn.
5. Recovery procedure là một sequence riêng
Nó có entry condition, giới hạn chuyển động, quyền operator, timeout, tiêu chí hoàn tất và target state. Không gọi lại sequence sản xuất với vài bit bypass.
6. Test fault tại từng boundary
Ngắt sensor, mất khí, mất truyền thông và power cycle tại các phase quan trọng. Kiểm tra cả duplicate command, fault lặp và lỗi xảy ra trong lúc đang recovery.
7. Thuật ngữ nên dùng
- điểm kiểm soát (checkpoint): vị trí trong chuỗi mà máy ghi lại trạng thái đã đạt, để sau lỗi biết bắt đầu lại từ đâu thay vì chạy lại từ đầu.
- đối soát trạng thái (state reconciliation): bước so trạng thái trong chương trình với vị trí thật của cơ cấu và cảm biến khi khởi động lại, trước khi cho phép chuyển động.
- trạng thái không xác định (unknown state): trạng thái mà chương trình không chứng minh được vị trí hoặc điều kiện thật; phải xử lý như nguy hiểm, không được đoán.
- phục hồi có kiểm soát (controlled recovery): đường trở về trạng thái an toàn đã thiết kế trước, có điều kiện và bằng chứng — khác với việc bấm Reset để xóa dấu vết lỗi.
8. Verification matrix mẫu
| Yêu cầu | Bằng chứng thiết kế | Test |
|---|
| Không mất context khi lỗi/kết nối gián đoạn | State, transaction và ownership model | Fault injection tại từng phase |
| Chỉ người có quyền mới được thay đổi | Role, authorization và audit trail | Positive/negative permission test |
| Restart không tạo action ngoài ý muốn | Startup reconciliation | Power cycle ở boundary |
| Dữ liệu không bị nhân đôi hoặc mất im lặng | ID, buffer và duplicate policy | Network loss/reconnect |
| Engineering change xác định được phạm vi ảnh hưởng | Configuration baseline và trace | Change-impact review |
9. Checklist review
- Scope và boundary đã được định nghĩa.
- Trạng thái bình thường, bất thường và restart đều có behavior.
- Thuật ngữ khó đã viết theo dạng tiếng Việt (English).
- Quyền thao tác và owner của quyết định đã rõ.
- Timeout, retry, reset hoặc bypass có giới hạn và log.
- Dữ liệu có identity, timestamp và version phù hợp.
- Có negative test và fault injection, không chỉ happy path.
- Có kế hoạch rollback/recovery và tiêu chí trở về baseline.
- Tài liệu, code, HMI và procedure dùng cùng vocabulary.
- Những điểm liên quan safety/security đã được chuyên gia phù hợp duyệt.
Kết luận
Sequence và phục hồi sau fault — Đừng dùng Reset để xóa mọi dấu vết là bài toán architecture và vòng đời, không phải một đoạn logic bổ sung ở cuối dự án. Khi state, identity, quyền thao tác, dữ liệu và recovery có contract rõ ràng, máy dễ vận hành, điều tra và thay đổi hơn mà không phụ thuộc vào trí nhớ của người đã viết chương trình ban đầu.
Nguồn tham khảo
- ISO 12100:2010
- ISO 14118:2017
- IEC 60204-1:2016+A1:2021
- ISA-TR88.00.02-2022
Xem tất cả bài viết kỹ thuật MINATA