Thiết kế máy #72: Timing budget và timeout — Đừng chọn 5 giây chỉ vì thấy đủ lâu
Timeout không phải một con số chống treo; nó là giới hạn được suy ra từ cơ khí, điều khiển, mạng, tải và cách hệ thống phản ứng khi trễ.
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. Tách thời gian chu kỳ thành các thành phần
Liệt kê command processing, scan, network transfer, actuator response, motion, sensor settle, debounce và confirmation. Tổng danh nghĩa chưa đủ; cần biên trên và nguồn biến thiên.
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. Timeout phải gắn với trạng thái
Cùng một actuator có thể có timeout khác khi homing, production, maintenance hoặc chạy ở nhiệt độ thấp. Timer toàn cục dễ che mất ngữ cảnh.
4. Phân biệt timeout, watchdog và deadline
Timeout giám sát một hoạt động; watchdog phát hiện thành phần không còn hoạt động; deadline là thời điểm kết quả phải có ý nghĩa. Trộn ba khái niệm tạo reaction sai.
5. Đừng dùng retry vô hạn
Retry cần giới hạn, backoff, transaction identity và điều kiện dừng. Nếu retry có thể phát lại chuyển động hoặc tạo thêm sản phẩm, phải thiết kế tính lặp an toàn.
6. Đo trên máy thật
Ghi distribution theo tải, nhiệt độ và network condition. Chọn threshold có margin được giải thích, sau đó alarm phải cho biết đang chờ điều kiện nào và đã trễ bao lâu.
7. Thuật ngữ nên dùng
- ngân sách thời gian (timing budget): tổng thời gian cho một chuỗi, chia sẵn cho từng bước, để thấy bước nào đang ăn mất phần của bước khác khi bị trễ.
- thời gian xấu nhất (worst-case time): thời gian dài nhất một bước có thể mất trong điều kiện bất lợi, không phải thời gian đo được ở lần chạy thuận lợi.
- độ dao động thời gian (jitter): mức chênh lệch giữa các lần thực hiện cùng một bước; jitter lớn làm timeout đặt theo giá trị trung bình mất ý nghĩa.
- thời hạn phản hồi (response deadline): mốc thời gian mà một phản hồi phải tới; quá mốc đó, hệ thống coi là lỗi và chuyển sang xử lý đã định trước.
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
Timing budget và timeout — Đừng chọn 5 giây chỉ vì thấy đủ lâu 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
- IEC 61131-3:2025
- IEC 61784-2
- ISO 22400-2:2014
- OMAC PackML
Xem tất cả bài viết kỹ thuật MINATA