Khi hệ thống kho tự động đã lắp xong và có thể chạy nhập – xuất hàng, nhiều doanh nghiệp dễ xem đó là dấu hiệu dự án đã sẵn sàng bàn giao. Tuy nhiên, “chạy được” và “đủ điều kiện nghiệm thu” là hai việc khác nhau.
Một hệ thống vẫn có thể hoàn thành vài chu kỳ thử nhưng phát sinh lỗi khi chạy liên tục, xử lý nhiều lệnh đồng thời, mất kết nối WMS/WCS, pallet sai quy cách hoặc phải phục hồi sau sự cố. Nếu những tình huống này chưa được kiểm tra, rủi ro thường chỉ lộ ra sau khi kho đã đi vào vận hành thực tế.
FAT kiểm tra thiết bị và chức năng trước khi đưa đến hiện trường; SAT xác nhận hệ thống sau khi lắp đặt tại site; còn nghiệm thu là bước xác nhận toàn bộ tiêu chí kỹ thuật, hiệu suất, an toàn, dữ liệu và hồ sơ bàn giao đã đạt yêu cầu.
Checklist dưới đây tập trung vào những điểm doanh nghiệp nên kiểm chứng trước khi ký biên bản bàn giao kho tự động, thay vì chỉ xác nhận máy móc đã hoạt động.
FAT, SAT và nghiệm thu kho tự động khác nhau ở đâu?
FAT, SAT và nghiệm thu có liên quan chặt chẽ nhưng không thay thế cho nhau. Mỗi bước trả lời một câu hỏi khác nhau của dự án.
| Giai đoạn | Câu hỏi cần trả lời | Trọng tâm kiểm tra | Kết quả cần có |
|---|---|---|---|
| FAT | Thiết bị và logic đã đúng trước khi đưa đến site chưa? | Cơ khí, điện, PLC, HMI, I/O, alarm, interlock, safety, interface mô phỏng | FAT report, lỗi tồn đọng, xác nhận cho phép xuất xưởng |
| SAT | Hệ thống sau khi lắp thực tế có hoạt động đúng không? | Luồng hàng, WMS/WCS/PLC, thiết bị thực tế, mạng, safety, recovery | SAT report, punch list, kết quả test tại site |
| Nghiệm thu | Hệ thống đã đáp ứng phạm vi bàn giao chưa? | Chức năng, hiệu suất, an toàn, dữ liệu, tài liệu, đào tạo | Biên bản nghiệm thu hoặc danh sách điều kiện còn phải hoàn thành |
UAT – User Acceptance Test – có thể được thực hiện sau SAT hoặc lồng trong giai đoạn chạy thử tùy cấu trúc dự án. UAT chủ yếu xác nhận hệ thống phù hợp với quy trình sử dụng thực tế của người vận hành, nhưng không nên dùng UAT để thay cho FAT hoặc SAT.
Trước khi làm FAT và SAT phải chốt tiêu chí Pass/Fail
Một checklist chỉ thực sự có giá trị khi mỗi test case đều xác định trước thế nào là đạt và thế nào là không đạt. Nếu tiêu chí chỉ ghi chung chung như “máy chạy ổn định” hoặc “hệ thống hoạt động tốt”, hai bên rất dễ tranh luận khi nghiệm thu.
Thông thường, tiêu chí nên truy ngược về các tài liệu đã thống nhất của dự án như URS, Functional Specification, bản vẽ approved, scope of supply, contract specification hoặc test protocol.
Ngay từ giai đoạn đầu, những thông tin như loại pallet, kích thước hàng, tải trọng, lưu lượng nhập xuất và operating scenario cũng phải được thống nhất. Các dữ liệu đầu vào khi thiết kế kho chính là cơ sở để xác định một hệ thống sau này có thực sự đạt yêu cầu hay không.
Mỗi test case nên có tối thiểu:
- Mã test case.
- Hạng mục hoặc chức năng được kiểm tra.
- Điều kiện trước khi test.
- Các bước thực hiện.
- Kết quả mong đợi.
- Kết quả thực tế.
- Pass hoặc Fail.
- Bằng chứng kèm theo.
- Người thực hiện và người xác nhận.
- Mã lỗi hoặc punch list nếu không đạt.
Nguyên tắc quan trọng: không nên thay đổi tiêu chí Pass/Fail sau khi đã thấy kết quả test chỉ để hệ thống được nghiệm thu dễ hơn.
Checklist FAT kho tự động trước khi xuất xưởng
FAT nên phát hiện càng nhiều lỗi càng tốt trước khi thiết bị được vận chuyển đến công trình. Những vấn đề xử lý được tại khu vực tích hợp thường ít ảnh hưởng tiến độ và chi phí hơn khi phải sửa sau khi hệ thống đã lắp hoàn chỉnh.
| Hạng mục FAT | Cách kiểm tra | Tiêu chí Pass | Bằng chứng |
|---|---|---|---|
| Cơ khí | Đo kích thước, hành trình, kiểm tra cụm truyền động và liên kết | Phù hợp bản vẽ và specification | Checklist, hình ảnh, biên bản đo |
| Tủ điện | Kiểm tra component, đấu dây, nhãn, bảo vệ | Đúng electrical drawing và BOM được duyệt | Electrical checklist |
| I/O | Kích hoạt từng sensor, actuator và tín hiệu | Đúng địa chỉ và đúng trạng thái PLC/HMI | I/O test sheet |
| PLC | Chạy từng sequence và điều kiện chuyển bước | Logic đúng Functional Specification | Test report |
| HMI | Kiểm tra màn hình, mode, status, alarm | Thông tin đúng và thao tác đúng phân quyền | Ảnh hoặc video test |
| Alarm | Chủ động tạo các lỗi đại diện | Alarm đúng nguyên nhân và trạng thái | Alarm test sheet |
| Interlock | Tạo điều kiện không cho phép vận hành | Thiết bị bị khóa đúng logic | Interlock test report |
| Safety | Test E-stop, safety door, safety circuit | Phản ứng đúng thiết kế an toàn | Safety test record |
| Interface | Mô phỏng dữ liệu từ hệ thống bên ngoài | Gửi, nhận và xử lý đúng trạng thái | Log hoặc interface report |
FAT không nên chỉ test chế độ Auto
Trong thực tế bảo trì, kỹ thuật viên thường phải dùng Manual, Maintenance hoặc Local mode. Vì vậy, ngoài Auto sequence, FAT nên kiểm tra các mode vận hành được phép sử dụng, quyền truy cập và interlock tương ứng.
Một thiết bị chạy đúng Auto nhưng Manual mode có thể bỏ qua một interlock quan trọng vẫn là một rủi ro cần xử lý.
Cần chủ động tạo lỗi thay vì chờ lỗi xuất hiện
Alarm test có giá trị nhất khi đội dự án cố tình tạo ra tình huống lỗi có kiểm soát: sensor không nhận tín hiệu, motor không ready, pallet chưa đúng vị trí, cửa safety mở hoặc communication bị ngắt.
Điều cần kiểm chứng không chỉ là “có alarm” mà còn gồm:
- Alarm có đúng tên và nguyên nhân hay không.
- Thiết bị có dừng ở trạng thái an toàn hay không.
- Người vận hành có biết vị trí lỗi hay không.
- Reset có yêu cầu điều kiện hợp lý hay không.
- Sau reset, sequence có tiếp tục đúng trạng thái hay không.
Chốt backup tại thời điểm FAT
Sau khi FAT đạt, nên lưu lại đúng phiên bản PLC, HMI, drive parameter và các cấu hình liên quan. Việc này giúp tránh tình trạng chương trình bị thay đổi tại site nhưng không xác định được phiên bản nào đã từng được FAT xác nhận.
Checklist SAT sau khi lắp đặt tại hiện trường
SAT không đơn thuần là chạy lại FAT tại một địa điểm khác. Mục tiêu của SAT là kiểm tra cách toàn bộ hệ thống hoạt động khi đã đặt vào điều kiện thực tế của nhà máy hoặc trung tâm phân phối.
Đối chiếu hệ thống thực tế với bản vẽ approved
Trước khi chạy hàng, cần kiểm tra lại vị trí thiết bị, aisle, buffer, lift, conveyor, điểm nhập – xuất, rack, hàng rào và vùng safety.
Đối với hệ thống AS/RS, sai lệch nhỏ tại rail, rack hoặc transfer point có thể không xuất hiện ngay trong vài chu kỳ đầu nhưng gây lỗi lặp lại khi vận hành lâu dài. Việc đối chiếu cách đọc layout kho tự động với bản vẽ hoàn công giúp đội nghiệm thu xác định rõ các điểm giao tiếp cần được kiểm tra tại site.
Test một luồng inbound hoàn chỉnh
Không nên chỉ chạy từng thiết bị riêng lẻ. Một test inbound hoàn chỉnh cần đi từ điểm nhận hàng đến khi hệ thống xác nhận hàng đã nằm đúng location và dữ liệu tồn kho được cập nhật.
Nên có test case cho:
- Pallet hoặc tote hợp lệ.
- Barcode không đọc được.
- Mã hàng không tồn tại.
- Pallet quá cao hoặc quá rộng nếu có dimension check.
- Tải trọng vượt giới hạn nếu hệ thống có kiểm tra tải.
- Không còn location phù hợp.
- Thiết bị đích đang fault.
- Lệnh bị dừng giữa sequence.
Test một luồng outbound từ lệnh đến hàng thực tế
Outbound phải kiểm chứng được cả luồng vật lý và luồng dữ liệu. Không chỉ xác nhận pallet được lấy khỏi rack mà phải kiểm tra đúng ID, đúng location, đúng điểm xuất và trạng thái tồn kho sau khi hoàn thành.
Nếu hệ thống có ưu tiên FIFO, FEFO, batch, wave hoặc sequencing, các quy tắc này cũng cần được đưa vào test case thay vì chỉ chạy một lệnh đơn giản.
Test nhiều lệnh đồng thời
Một lỗi thường không xuất hiện khi chạy từng lệnh riêng lẻ nhưng lại xảy ra khi nhiều thiết bị tranh chấp tài nguyên hoặc nhiều pallet cùng hướng đến một buffer.
Do đó, SAT nên có kịch bản tạo đồng thời inbound, outbound và relocation nếu đây là cách kho sẽ vận hành thực tế.
Kiểm tra WMS – WCS – PLC: đúng dữ liệu quan trọng không kém đúng chuyển động
Một stacker crane có thể đưa pallet đến đúng vị trí nhưng nếu WMS ghi sai location thì hệ thống vẫn chưa đạt. Trong kho tự động, luồng vật lý và luồng dữ liệu phải khớp nhau.
Đội nghiệm thu nên đối chiếu ít nhất:
| Tình huống | Điểm cần xác nhận |
|---|---|
| Tạo lệnh | WMS phát đúng ID, nguồn, đích và loại nhiệm vụ |
| Điều phối | WCS chọn đúng thiết bị và route |
| Thực thi | PLC thực hiện đúng sequence |
| Hoàn tất | Trạng thái completion trả ngược đầy đủ |
| Timeout | Không tạo lệnh trùng hoặc mất trạng thái |
| Retry | Lệnh được thử lại theo đúng logic |
| Fault | Dữ liệu không báo completion khi chuyển động chưa hoàn tất |
| Recovery | Dữ liệu sau phục hồi khớp với vị trí hàng thực tế |
Một kiểm tra thực tế hữu ích là chọn ngẫu nhiên một số pallet sau bài test, đối chiếu đồng thời vị trí vật lý, PLC/WCS status và location trên WMS. Nếu ba nguồn không khớp, cần tìm nguyên nhân trước khi nghiệm thu.
Test throughput thế nào để kết quả có giá trị nghiệm thu?
Throughput không nên được chứng minh bằng cách chạy vài pallet rồi lấy cycle time nhân lên thành công suất một giờ. Cách tính đó dễ bỏ qua thời gian chờ, tranh chấp thiết bị, giao cắt luồng và các khoảng trễ của hệ thống.
Một bài performance test nên ghi rõ:
- Số lệnh hoặc số pallet được dùng.
- Thời gian chạy test.
- Tỷ lệ inbound và outbound.
- Phân bố vị trí nguồn và đích.
- Số thiết bị đang hoạt động.
- Loại pallet hoặc tote sử dụng.
- Điều kiện hệ thống trước khi bắt đầu.
- Thời gian downtime nếu phát sinh.
| KPI | Ý nghĩa khi nghiệm thu |
|---|---|
| Throughput | Số đơn vị hàng thực tế xử lý trong khoảng thời gian test |
| Cycle time | Thời gian hoàn thành một chu kỳ hoặc một loại nhiệm vụ |
| Accuracy | Tỷ lệ hàng, location và dữ liệu xử lý chính xác |
| Availability | Mức độ hệ thống sẵn sàng trong thời gian thử nghiệm |
| Recovery time | Thời gian cần để đưa hệ thống trở lại vận hành sau lỗi |
Không có một mức throughput chung áp dụng cho mọi kho tự động. Giá trị Pass phải được so với công suất đã thống nhất của chính dự án và phải test trong điều kiện đủ gần với operating scenario dùng khi thiết kế hệ thống.
6 tình huống recovery nên thử trước khi bàn giao
Khả năng xử lý sự cố thường phản ánh mức độ hoàn thiện của hệ thống rõ hơn việc chạy Auto trong điều kiện lý tưởng. Một dự án chưa kiểm chứng recovery thì vẫn còn rủi ro lớn khi đưa vào sản xuất.
Mất điện khi thiết bị đang di chuyển
Kiểm tra vị trí thiết bị và pallet sau khi cấp điện trở lại. Hệ thống phải xác định được trạng thái thực tế trước khi cho phép tiếp tục Auto.
Mất kết nối WMS hoặc WCS
Cần xác nhận lệnh đang chạy được giữ, hủy hay hoàn tất theo logic nào; đồng thời kiểm tra nguy cơ phát sinh duplicate command khi kết nối phục hồi.
PLC mất communication với thiết bị
Thiết bị liên quan phải chuyển sang trạng thái kiểm soát được và hệ thống không được mặc định rằng nhiệm vụ đã hoàn thành.
Cảm biến không nhận pallet
Kiểm tra alarm, interlock và cách recovery. Không nên cho phép reset đơn giản nếu pallet thực tế vẫn nằm ở vị trí có nguy cơ va chạm.
Pallet dừng giữa hai thiết bị
Đây là tình huống quan trọng tại transfer point giữa conveyor – lift, conveyor – stacker crane hoặc các module khác. Cần xác định thiết bị nào sở hữu pallet và sequence nào được phép tiếp tục.
Khởi động lại toàn hệ thống
Sau restart, hệ thống phải đồng bộ lại trạng thái thiết bị, pallet và task trước khi chạy Auto. Đây là lúc dễ phát sinh tình trạng phần mềm nghĩ pallet ở một nơi nhưng hàng thực tế đang ở vị trí khác.
Punch list: không phải lỗi nào cũng có thể để xử lý sau
Trong dự án thực tế, việc SAT kết thúc mà vẫn còn punch list không phải điều bất thường. Điều quan trọng là phân loại mức độ ảnh hưởng thay vì gom tất cả lỗi vào một danh sách giống nhau.
| Mức độ | Ví dụ | Khuyến nghị nghiệm thu |
|---|---|---|
| Critical | Safety không hoạt động, nguy cơ va chạm, mất kiểm soát dữ liệu nghiêm trọng | Không nên nghiệm thu |
| Major | Chức năng chính lỗi, throughput không đạt, recovery không ổn định | Cần xử lý hoặc có điều kiện chấp thuận rõ ràng |
| Minor | Nhãn, giao diện nhỏ, một số chi tiết hoàn thiện không ảnh hưởng vận hành | Có thể đóng sau nếu hai bên thống nhất |
Mỗi punch item nên có mô tả lỗi, mức độ, thiết bị liên quan, người chịu trách nhiệm, thời hạn hoàn thành và bằng chứng đóng lỗi. Không nên dùng mô tả chung như “chỉnh lại phần mềm” vì rất khó xác nhận sau này.
Checklist nghiệm thu cuối cùng trước khi ký bàn giao
Sau khi FAT và SAT hoàn tất, nên có một checklist tổng hợp để đội dự án nhìn được trạng thái cuối cùng của toàn hệ thống thay vì phải đọc lại hàng chục test sheet rời rạc.
| Hạng mục | Điều kiện nên đạt |
|---|---|
| Scope | Các hạng mục trong phạm vi hợp đồng đã hoàn thành |
| FAT | Test case yêu cầu đã Pass hoặc có deviation được chấp thuận |
| SAT | Luồng vận hành thực tế đã được kiểm chứng |
| Safety | Không còn lỗi safety mở |
| Dữ liệu | WMS/WCS/PLC và hàng thực tế đối soát chính xác |
| Performance | Throughput và KPI nghiệm thu đạt yêu cầu |
| Recovery | Các kịch bản lỗi quan trọng đã test |
| Punch list | Không còn lỗi critical chưa xử lý |
| Tài liệu | Hồ sơ kỹ thuật và backup đã bàn giao |
| Đào tạo | Nhân sự vận hành, bảo trì đã được hướng dẫn |
Khi cần đối chiếu phạm vi từng nhóm thiết bị và chức năng trong một dự án hoàn chỉnh, doanh nghiệp có thể tham khảo tổng quan giải pháp kho tự động để tránh bỏ sót những phân hệ nằm ngoài phần cơ khí chính.
Hồ sơ nào phải nhận trước khi đóng dự án?
Thiết bị có thể vận hành nhiều năm sau khi nhà cung cấp hoàn tất dự án, vì vậy chất lượng bộ hồ sơ bàn giao ảnh hưởng trực tiếp đến khả năng bảo trì, troubleshooting và nâng cấp về sau.
Tùy phạm vi dự án, doanh nghiệp nên kiểm tra tối thiểu:
- FAT protocol và FAT report.
- SAT protocol và SAT report.
- Biên bản nghiệm thu.
- Punch list và bằng chứng đóng lỗi.
- As-built layout.
- Mechanical drawing cần thiết cho bảo trì.
- Electrical as-built drawing.
- I/O list.
- Danh sách alarm.
- Backup PLC.
- Backup HMI.
- Drive parameter và configuration liên quan.
- Tài liệu interface WMS/WCS thuộc phạm vi bàn giao.
- Operation Manual.
- Maintenance Manual.
- SOP xử lý các lỗi phổ biến.
- Danh sách spare parts khuyến nghị.
- Lịch preventive maintenance.
- Danh sách tài khoản và phân quyền cần bàn giao.
- Biên bản đào tạo vận hành và bảo trì.
Phạm vi tài liệu, quyền truy cập phần mềm và điều kiện bàn giao nên được xác định từ giai đoạn thiết kế và lắp đặt kho tự động, thay vì chờ đến cuối dự án mới thống nhất.
Khi nào chưa nên ký nghiệm thu kho tự động?
Ngày bàn giao đã được lên lịch không có nghĩa hệ thống bắt buộc phải được nghiệm thu. Nếu những điều kiện ảnh hưởng trực tiếp đến an toàn, dữ liệu hoặc khả năng vận hành chưa đạt, doanh nghiệp nên yêu cầu xử lý hoặc ghi rõ điều kiện nghiệm thu.
Chưa nên ký nghiệm thu cuối cùng khi còn một trong các vấn đề sau:
- Safety function chưa test hoặc đang Fail.
- Còn lỗi có nguy cơ gây va chạm thiết bị.
- Dữ liệu WMS/WCS không khớp vị trí hàng thực tế.
- Throughput chưa đạt tiêu chí đã cam kết.
- Lỗi chính xuất hiện lặp lại nhưng chưa xác định root cause.
- Recovery sau mất điện hoặc mất mạng chưa ổn định.
- Còn punch item mức Critical.
- Chưa bàn giao backup chương trình cần thiết.
- Chưa có as-built drawing.
- Đội vận hành chưa được đào tạo các tình huống bất thường.
Nếu phải bàn giao theo từng giai đoạn, biên bản cần ghi rõ những hạng mục chưa hoàn thành, trách nhiệm của từng bên, thời hạn xử lý và điều kiện để chuyển sang nghiệm thu cuối cùng.
Checklist Go/No-Go trước ngày đưa kho vào vận hành
Ngay trước thời điểm go-live, đội dự án nên thực hiện một vòng kiểm tra ngắn. Đây không thay thế SAT nhưng giúp phát hiện những thay đổi hoặc lỗi mới xuất hiện sau giai đoạn test.
- GO: Không còn lỗi safety hoặc lỗi Critical.
- GO: Inbound và outbound chạy ổn định.
- GO: Location vật lý khớp dữ liệu WMS/WCS.
- GO: Throughput đạt tiêu chí nghiệm thu.
- GO: Recovery các tình huống chính đã được xác nhận.
- GO: Backup mới nhất đã được lưu và bàn giao.
- GO: Nhân sự vận hành biết cách xử lý alarm thông thường.
- GO: Đội bảo trì có tài liệu và quyền truy cập cần thiết.
- NO-GO: Còn bất kỳ lỗi nào có nguy cơ gây mất an toàn, sai tồn kho hoặc mất kiểm soát hệ thống.
Điểm quan trọng nhất của FAT, SAT và nghiệm thu không nằm ở số lượng biểu mẫu đã ký, mà ở việc mỗi yêu cầu quan trọng của hệ thống đều có thể truy ngược tới một test case và một bằng chứng xác nhận. Khi tiêu chí rõ ngay từ đầu, đội dự án sẽ dễ phân biệt đâu là lỗi phải xử lý trước bàn giao và đâu là hạng mục có thể đóng sau mà không ảnh hưởng vận hành.
Câu hỏi thường gặp về FAT, SAT và nghiệm thu kho tự động
Dưới đây là những vấn đề doanh nghiệp thường cần làm rõ trước khi thống nhất kế hoạch kiểm thử và bàn giao hệ thống.
FAT kho tự động là gì?
FAT – Factory Acceptance Test – là quá trình kiểm tra thiết bị, phần mềm điều khiển và các chức năng có thể xác nhận trước khi thiết bị được vận chuyển đến công trình. Mục tiêu là phát hiện lỗi càng sớm càng tốt trước giai đoạn lắp đặt tại site.
SAT kho tự động là gì?
SAT – Site Acceptance Test – là quá trình kiểm tra hệ thống sau khi đã lắp đặt tại hiện trường, bao gồm luồng hàng thực tế, giao tiếp WMS/WCS/PLC, thiết bị, mạng, safety và các tình huống recovery.
FAT đạt thì SAT có chắc chắn đạt không?
Không. FAT chỉ xác nhận những nội dung được kiểm tra trong điều kiện FAT. Sau khi lắp tại site vẫn có thể xuất hiện lỗi alignment, wiring, communication, dữ liệu, pallet thực tế hoặc tương tác giữa nhiều phân hệ.
Có bắt buộc phải test throughput trước khi nghiệm thu không?
Nếu throughput là một KPI hoặc điều kiện cam kết của dự án thì cần có bài test đủ đại diện để chứng minh. Chạy thành công vài pallet không thể thay thế cho performance test.
Có thể nghiệm thu khi vẫn còn punch list không?
Có thể tùy điều khoản dự án và mức độ lỗi. Các lỗi Minor không ảnh hưởng an toàn hoặc chức năng chính có thể được thống nhất hoàn thiện sau. Lỗi Critical liên quan safety, dữ liệu hoặc nguy cơ va chạm không nên để tồn tại khi nghiệm thu cuối cùng.
Ai nên tham gia FAT và SAT?
Tùy dự án, thành phần thường gồm đại diện chủ đầu tư, system integrator, automation, IT/WMS, vận hành, bảo trì và bộ phận an toàn. Những người chịu trách nhiệm vận hành sau này nên tham gia SAT để hiểu cả hoạt động bình thường lẫn recovery.
Tiêu chí nghiệm thu nên được xác định khi nào?
Nên xác định từ giai đoạn yêu cầu và thiết kế, sau đó thể hiện trong URS, specification, hợp đồng hoặc test protocol. Đợi đến khi SAT mới thống nhất tiêu chí Pass/Fail thường dẫn đến tranh luận và kéo dài thời gian bàn giao.
