Thiết kế máy #73: Recipe và quản lý model — Đừng để thông số sản xuất trôi khỏi revision
Một recipe chạy được hôm nay chưa chắc là recipe đã được duyệt; cần biết nó thuộc model nào, revision nào và tương thích với machine configuration nào.
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 master, approved và active
Master là nguồn được quản lý; approved là phiên bản đã duyệt; active là bản đang nạp trên máy. Giao diện phải hiển thị rõ ba khái niệm này, không chỉ một tên model.
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. Schema recipe phải có contract
Mỗi field cần đơn vị, range, default, quyền chỉnh và behavior khi thiếu. Khi thêm field mới, phải định nghĩa migration và tương thích ngược.
4. Download không đồng nghĩa activate
Quy trình nên gồm transfer, validation, compatibility check, approval nếu cần, activation và acknowledgement. Không đổi recipe giữa cycle nếu process không cho phép.
5. Manual edit phải được kiểm soát
Ghi ai sửa, sửa gì, lý do, giá trị trước/sau và thời điểm. Các thông số critical cần role hoặc phê duyệt phù hợp.
6. Test model change
Kiểm tra wrong model, stale version, missing field, unit mismatch, power loss khi transfer và đổi model khi còn product trong máy.
7. Thuật ngữ nên dùng
- công thức sản xuất (recipe): tập thông số cho một loại sản phẩm; phải có phiên bản riêng và không sửa trực tiếp trên máy đang chạy.
- phiên bản cấu hình (configuration version): số hiệu gắn với một bộ thông số đã được duyệt, để biết máy đang chạy đúng bộ nào.
- khả năng tương thích (compatibility): điều kiện để một công thức chạy được trên một cấu hình máy nhất định; đổi phần cứng có thể làm công thức cũ không còn hợp lệ.
- dấu vết kiểm toán (audit trail): chuỗi ghi lại ai đổi gì, khi nào và vì sao, đủ để dựng lại lịch sử mà không phải hỏi người trong cuộ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
Recipe và quản lý model — Đừng để thông số sản xuất trôi khỏi revision 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 61512-1:2026
- IEC 62264-1:2013
- ISO 10007:2017
- ISA-TR88.00.02-2022
Xem tất cả bài viết kỹ thuật MINATA