Một hệ thống chạy tốt trên bàn thí nghiệm chưa nói lên nó chạy được trong xưởng. Không phải vì kỹ thuật kém, mà vì môi trường sản xuất áp thêm năm ràng buộc mà phòng lab không có.
Ràng buộc một: độ tin cậy tính theo tháng
Trong nghiên cứu, một hệ thống chạy được vài chục lần liên tiếp là kết quả tốt. Trong sản xuất, nó phải chạy hàng nghìn chu kỳ mỗi ngày, nhiều tháng liền.
Ở quy mô đó, các sự cố hiếm trở thành thường xuyên. Một lỗi xảy ra một lần trong một nghìn chu kỳ nghĩa là vài lần mỗi ngày.
Hệ quả thiết kế: mọi tình huống bất thường đều phải có đường xử lý xác định, kể cả những tình huống bạn nghĩ sẽ không bao giờ gặp. Trong sản xuất, chúng sẽ gặp.
Ràng buộc hai: nhịp là một yêu cầu, không phải mong muốn
Phòng lab không đo thời gian chu kỳ; nhà máy thì có, và nó nằm trong hợp đồng.
Nhiều kỹ thuật hiệu quả trong nghiên cứu trở nên không dùng được vì quá chậm: dò tìm nhiều bước khi tiếp xúc, chụp lại ảnh trước mỗi thao tác, gọi mô hình lớn ở mỗi bước.
Cách xử lý thường là tách hai chế độ: đường nhanh cho các tình huống thông thường đã biết, và đường chậm có mô hình lớn tham gia chỉ khi đường nhanh không xử lý được. Phần lớn chu kỳ đi theo đường nhanh, nên nhịp trung bình vẫn đạt.
Ràng buộc ba: an toàn phải chứng minh được
Trong phòng lab, an toàn được đảm bảo bằng việc có người đứng cạnh với tay trên nút dừng. Trong sản xuất, phải có hồ sơ.
Đây là khó khăn đặc thù của hệ có hành vi sinh từ mô hình: bạn không liệt kê được toàn bộ hành vi có thể xảy ra.
Lời giải được chấp nhận hiện nay là tách lớp: hành vi có thể do mô hình sinh ra, nhưng ranh giới an toàn — giới hạn không gian, giới hạn lực, giới hạn tốc độ — nằm trong mạch an toàn độc lập và không phụ thuộc mô hình.
Nhờ đó, hồ sơ an toàn chứng minh cho lớp giới hạn chứ không phải cho mô hình, và đó là điều làm được.
Ràng buộc bốn: ai bảo trì hệ này
Trong nghiên cứu, người xây hệ cũng là người sửa hệ. Trong nhà máy, người sửa là kỹ thuật viên bảo trì lúc hai giờ sáng.
Điều này đặt ra yêu cầu về chẩn đoán: khi hệ thống dừng, nó phải nói được vì sao bằng ngôn ngữ người vận hành hiểu. Thông báo lỗi kiểu mã số nội bộ hoặc số liệu của mô hình là vô dụng.
Cũng cần một quy trình rõ ràng cho việc khi nào thì gọi hỗ trợ. Không có ranh giới đó, kỹ thuật viên hoặc sẽ thử sửa những thứ không nên đụng, hoặc sẽ gọi hỗ trợ cho mọi lỗi vặt.
Ràng buộc năm: người vận hành phải tin hệ thống
Đây là ràng buộc mềm nhưng quyết định số phận nhiều dự án.
Một hệ thống thỉnh thoảng làm điều khó hiểu sẽ khiến người vận hành mất tin tưởng, và họ sẽ tìm cách vô hiệu hoá nó hoặc quay lại làm tay.
Ba việc giúp xây dựng niềm tin: hành vi nhất quán — thà chậm mà đoán trước được còn hơn nhanh mà thất thường; giải thích được — hiển thị hệ thống đang định làm gì; và quyền dừng — người vận hành luôn có cách dừng và chuyển sang thủ công.
Trong thực tế, một hệ thống có tỉ lệ thành công thấp hơn nhưng hành xử dễ đoán thường được chấp nhận tốt hơn nhiều so với hệ ngược lại.
Câu hỏi thường gặp
Nên bắt đầu triển khai ở khâu nào?
Khâu không nằm trên đường găng của sản xuất, để sự cố không làm dừng cả dây chuyền. Khâu có nhịp không quá gấp và có thể quay về làm tay dễ dàng cũng là lựa chọn tốt cho lần triển khai đầu tiên.
Có nên chạy song song với phương án cũ không?
Rất nên trong giai đoạn đầu. Chạy song song cho phép so sánh trực tiếp trên cùng điều kiện và có đường lui khi hệ mới gặp vấn đề. Chi phí thêm thường nhỏ so với rủi ro dừng sản xuất.
Làm sao thuyết phục bộ phận sản xuất chấp nhận hệ mới?
Bằng số liệu đo trên chính dây chuyền của họ chứ không phải bằng kết quả ở nơi khác, và bằng việc cho họ quyền dừng hệ thống bất cứ lúc nào. Cho người vận hành tham gia từ giai đoạn thử nghiệm cũng hiệu quả hơn nhiều so với bàn giao xong mới đào tạo.
Cần bao lâu từ thử nghiệm tới vận hành ổn định?
Phụ thuộc chủ yếu vào số lượng tình huống bất thường của công đoạn. Công đoạn ít ngoại lệ có thể ổn định trong vài tuần; công đoạn nhiều biến thể có thể mất nhiều tháng để xử lý hết các trường hợp biên.
Đọc thêm trong Robot hiện thân là gì và Dữ liệu thao tác & điều khiển từ xa.