Hệ thống quản lý đội xe AGV: tích hợp nhiều hãng bằng VDA 5050 cho nhà máy tại Thái Lan

Chiếc AGV dẫn hướng bằng băng từ được đưa vào đầu tiên, chiếc AMR của một hãng khác được bổ sung sau, rồi xe nâng tự hành (AGF) đang được cân nhắc. Tại các nhà máy vốn Nhật ở Thái Lan, cảnh xe vận chuyển tự hành của nhiều hãng khác nhau cùng chạy trong một nhà xưởng như vậy không còn hiếm. Thế nhưng phần mềm điều khiển lại tách riêng theo từng hãng, và các xe tranh nhau cùng một lối đi, ngã tư, cửa tự động, thang máy, bộ sạc. Kết quả là nhà máy phải vận hành theo kiểu “chia theo khung giờ”, “dừng một bên” hoặc “người điều phối qua bộ đàm”, và dù tăng số xe thì lượng vận chuyển cũng không tăng như kỳ vọng. Từ đó, phương án được đưa ra cân nhắc là gom xe của nhiều hãng vào một hệ thống quản lý đội xe AGV duy nhất, cùng với VDA 5050, giao diện chung phục vụ cho mục đích đó.

Bài viết này chỉ có một luận điểm. Thành bại khi vận hành AGV/AMR của nhiều hãng trong cùng một nhà máy không nằm ở việc “có hỗ trợ chuẩn truyền thông hay không”, mà nằm ở việc đã quyết định trước ba điều sau hay chưa. ① Ai nắm quyền điều phối khu vực giao cắt và thiết bị dùng chung (một lớp cấp trên không thuộc hệ thống điều khiển của hãng nào, hay dồn về một hãng nhất định). ② Thống nhất bản đồ và hệ tọa độ, từ vựng hành động (action), ý nghĩa của lỗi đến mức nào. ③ Phân định trách nhiệm về an toàn và khi xảy ra sự cố. VDA 5050 thống nhất “cách nói chuyện” giữa hệ thống điều khiển và xe. Nhưng chính tiêu chuẩn này ghi rõ rằng nó không đề cập đến yêu cầu an toàn, logic quản lý giao thông, giao diện với thiết bị ngoại vi và hệ thống IT cấp trên, quy trình dự án và nghiệm thu, việc phân chia trách nhiệm, và an ninh mạng. Những phần đó doanh nghiệp phải tự quyết định.

Dưới đây, để người phụ trách kỹ thuật sản xuất, bảo trì thiết bị, cải tiến logistics, hệ thống thông tin, giám đốc nhà máy, cũng như bộ phận kỹ thuật sản xuất của trụ sở tại Nhật Bản có thể chuẩn bị đủ căn cứ để ra quyết định trong nội bộ, bài viết lần lượt sắp xếp: khác biệt giữa các tầng điều khiển, phạm vi của VDA 5050, những chỗ hay bị dừng khi các hãng chạy lẫn với nhau, so sánh các phương thức điều khiển, phạm vi thống nhất, liên kết với hệ thống cấp trên và thiết bị, an toàn và phân định trách nhiệm, mạng, tính toán chi phí theo mô hình, RFP, PoC và thử nghiệm nghiệm thu. Toàn bộ quy trình triển khai AGV đã được trình bày trong bài “Tích hợp hệ thống AGV tại Thái Lan 2026: RFP, thiết kế và triển khai“, nên bài này chỉ tập trung vào “điều khiển khi có từ 2 hãng trở lên”. Mọi số tiền của nhà máy mô hình trong bài đều là số giả định đặt ra riêng cho bài viết này. Ngoài ra, các phần đề cập đến tiêu chuẩn an toàn và thuế chỉ là giới thiệu thông tin công khai, không phải tư vấn pháp lý hay tư vấn về việc đạt chứng nhận.

Vì sao đến lúc cần xem lại hệ thống quản lý đội xe AGV

Điều gì xảy ra ở nhà máy đưa vào hãng thứ hai

Khi AGV chỉ của một hãng, việc điều khiển có thể giao hết cho phần mềm của hãng đó. Nhường nhau ở ngã tư, thời điểm sạc, gọi thang máy, tất cả đều do hệ thống điều khiển của hãng đó lo. Vấn đề phát sinh khi nhà máy bổ sung xe của hãng khác vì khác biệt về hàng hóa vận chuyển hoặc mục đích sử dụng.

• Hệ thống điều khiển của 2 hãng không biết vị trí xe của nhau, nên ở ngã tư hay lối đi hẹp chỉ còn cách “dừng một bên”
• Tín hiệu gọi cửa tự động và thang máy thành 2 hệ, và phải lập trình thêm logic điều phối tranh chấp trong PLC phía thiết bị
• Bộ sạc chuyên dụng theo từng hãng, nên 2 loại bộ sạc được đặt cạnh nhau dọc cùng một bức tường
• Lệnh vận chuyển từ WMS hay MES đi vào qua các cửa riêng theo từng hãng (API khác nhau, màn hình khác nhau, nút gọi khác nhau)
• Khi có sự cố, mất thời gian để khoanh vùng xem lỗi thuộc về hãng nào

Nếu tình trạng này kéo dài, số xe tăng lên nhưng thời gian chờ ở khu vực giao cắt cũng tăng, và lượng vận chuyển không tăng. Ở Thái Lan, theo một bản tin năm 2021, một công ty tự động hóa nhà máy của Thái Lan ký hợp đồng đại lý phân phối với hãng AGV BlueBotics được cho là đến thời điểm đó đã đưa vào vận hành hơn 80 xe trong nước, nên đã có nền tảng để xe của nhiều hãng và nhiều thế hệ khác nhau cùng vào một nhà máy. Bản thân cách chọn hãng xin xem bài “Chọn nhà sản xuất AGV cho nhà máy Thái Lan: Hướng dẫn RFP“; bài này bắt đầu từ trạng thái “sau khi chọn, kết quả là có nhiều hãng”.

VDA 5050 phiên bản 3.0.0 được công bố vào tháng 3 năm 2026

Khi nói đến giao diện chung để điều khiển xe của nhiều hãng bằng một hệ thống điều khiển, cái tên được nhắc đến nhiều nhất là VDA 5050 của Đức. Phiên bản hiện hành là 3.0.0, do VDA (Hiệp hội Công nghiệp Ô tô Đức) công bố vào tháng 3 năm 2026. Trang chính thức của VDA cũng hiển thị phiên bản hiện hành là “Version 3.0.0, March 2026”.

Ở bản 3.0.0, ngay cả tiêu đề của văn bản tiêu chuẩn cũng đã thay đổi. Đến bản 2.1.0, tiêu đề là “giao diện truyền thông giữa xe vận chuyển tự hành (AGV) và master control”, còn bản 3.0.0 là “giao diện truyền thông giữa robot di động và fleet control”. Thuật ngữ cũng được thay từ “master control / AGV” sang “fleet control / mobile robot”. Trong bài này, hệ thống điều khiển đặt bên trên hệ thống điều khiển riêng của từng hãng để gom xe của nhiều hãng được gọi là “lớp điều khiển cấp trên” (VDA 5050 3.0 gọi là fleet control, các bản cũ gọi là master control).

Về các thay đổi chính của 3.0.0, ghi chú phát hành trên GitHub nêu: hỗ trợ robot di động di chuyển tự do (chia sẻ lộ trình dự kiến, khái niệm vùng), xem lại chế độ vận hành và trạng thái hành động, bổ sung các mức lỗi “URGENT” và “CRITICAL”, bổ sung các hành động tức thời (instant action) như cập nhật chứng chỉ. Hãng AMR idealworks, một trong các công ty tham gia, giải thích trên trang tin của mình rằng 3.0.0 là thành quả của 3 năm làm việc, 32 buổi hội thảo trực tiếp và nhóm nòng cốt 25 người (đây là giải thích của công ty này).

Thử nghiệm khả năng tương tác AMR và thị trường robot vận chuyển

Trang chính thức của VDA giới thiệu “AGV Mesh-Up” là nơi các doanh nghiệp thành viên VDMA thử mức độ tương thích giao diện giữa xe và hệ thống điều khiển của mình. Theo Fraunhofer IML, lần thứ 4 được tổ chức tại Dortmund vào tháng 4 năm 2024, và 8 robot di động của các hãng khác nhau đã được thử nghiệm. Người phụ trách của viện này giải thích rằng trước khi có VDA 5050, không thể vận hành robot di động của các nhà cung cấp khác nhau bằng một master control chung.

Về phía thị trường, Liên đoàn Robot Quốc tế (IFR) trong thông cáo ngày 30 tháng 9 năm 2026 cho biết lượng xuất xưởng robot dịch vụ chuyên nghiệp toàn cầu năm 2025 tăng 24% lên khoảng 250.000 chiếc, và ứng dụng đứng đầu là “vận tải và logistics” với 117.500 chiếc (tăng 21%, chiếm 47%). Đây là số liệu robot dịch vụ trên toàn thế giới, không phải số lượng riêng AGV trong nhà máy, cũng không phải phần của Thái Lan. Dù vậy, có thể dễ hình dung rằng robot vận chuyển tiếp tục tăng và tình trạng xe của nhiều hãng cùng có mặt tại một cơ sở sẽ còn nhiều hơn trong thời gian tới.

Ngành ô tô Thái Lan có ưu đãi đầu tư cho tự động hóa và robot

Trong bối cảnh Thái Lan, thông báo No. 4/2569 của BOI (Ủy ban Đầu tư Thái Lan) đã được đăng công báo ngày 31 tháng 3 năm 2026. Theo phân tích của một hãng luật, đối tượng chỉ giới hạn ở các dự án được khuyến khích thuộc sản xuất ô tô thông thường (ngành 3.6) và sản xuất PHEV và HEV (ngành 3.8), và biện pháp này cho phép miễn thuế nhập khẩu máy móc cùng miễn 50% thuế thu nhập doanh nghiệp trong 3 năm với mức trần bằng số vốn đầu tư (không tính tiền đất và vốn lưu động) cho việc đưa vào hệ thống tự động hóa và robot. Trong một số điều kiện khi có liên quan đến ngành sản xuất máy tự động hóa trong nước Thái Lan, mức này được nâng lên 100%; vốn đầu tư từ 1 triệu baht trở lên, và hạn nộp đơn là cuối năm 2027. Các dự án hiện đang được miễn thuế thu nhập doanh nghiệp không thuộc đối tượng. Đây là biện pháp dành cho ngành ô tô, không áp dụng cho nhà máy nói chung. Các ngành khác có thể có biện pháp riêng, vì vậy hãy xác nhận khả năng áp dụng với BOI hoặc chuyên gia. Bài viết này không phải tư vấn thuế.

Hệ thống quản lý đội xe AGV là gì: khác biệt giữa điều khiển trên xe, điều khiển riêng của hãng, lớp điều khiển cấp trên và WMS/MES

Cụm từ “hệ thống quản lý đội xe AGV” được mỗi người hiểu với phạm vi khác nhau. Phần lớn nguyên nhân khiến thảo luận nội bộ không ăn khớp là các bên đang nói về những tầng khác nhau. Trước hết, hãy tách các tầng.

VDA 5050 3.0.0 nêu các chức năng tối thiểu mà lớp điều khiển cấp trên thực hiện gồm: phân lệnh cho xe, tính lộ trình và dẫn hướng cho robot dẫn hướng theo tuyến (có xét kích thước và khả năng cơ động của từng xe), phát hiện và giải quyết tắc nghẽn (deadlock), quản lý năng lượng (lệnh sạc có thể chen ngang lệnh vận chuyển), điều khiển giao thông (tuyến đệm và vị trí chờ), thay đổi tạm thời môi trường (mở khu vực, thay đổi tốc độ tối đa…), giao tiếp với hệ thống ngoại vi như cửa, cổng, thang máy, và phát hiện và giải quyết lỗi truyền thông. Trong khi đó, các chức năng do robot di động đảm nhận là tự định vị, thực hiện lộ trình, thực hiện hành động và liên tục gửi trạng thái.

Điều cần lưu ý ở đây là việc tiêu chuẩn liệt kê “các chức năng lớp điều khiển cấp trên thực hiện” khác với việc quy định cách hiện thực các chức năng đó. Như sẽ thấy ở phần sau, logic quản lý giao thông và giao diện với thiết bị ngoại vi nằm ngoài phạm vi tiêu chuẩn. Khi đưa vào lớp điều khiển cấp trên, nội dung bên trong (cách quyết định thứ tự ưu tiên ở ngã tư, cách gỡ deadlock, cách kết nối với cửa và thang máy) khác nhau theo từng sản phẩm và từng dự án.

Quan hệ với WMS cũng vậy. WMS quyết định “chở gì”, còn hệ thống điều khiển quyết định “chở bằng xe nào, theo lộ trình nào”. Bản thân việc triển khai WMS được trình bày trong bài “WMS Thái Lan 2026: RFP, PoC 90 ngày và nghiệm thu cho kho đang vận hành“.

VDA 5050 là gì: ai xây dựng, thống nhất những gì và không thống nhất những gì

Ai xây dựng

Theo phần lời nói đầu của VDA 5050 3.0.0, đặc tả do VDA và VDMA (Hiệp hội Cơ khí Đức) cùng xây dựng. Viện Logistics và Vận chuyển vật tư (IFL) của Viện Công nghệ Karlsruhe (KIT) được hai hiệp hội ủy thác điều phối việc phát triển và quản lý kho GitHub chính thức. Đơn vị phát hành là VDA.

Mục 2 Scope của tiêu chuẩn định nghĩa văn bản này là “giao diện truyền thông được chuẩn hóa, trung lập về nhà cung cấp, giữa hệ thống fleet control và robot di động”, với 3 mục đích: ① giảm độ phức tạp khi kết nối robot di động với fleet control, ② cho phép đội xe hỗn hợp gồm robot di động của các hãng khác nhau phối hợp vận hành trong cùng một môi trường vật lý, ③ cung cấp định nghĩa chung dùng được cho robot di động khác nhau về cách di chuyển, kích thước, khả năng bốc dỡ hàng và mức độ tự chủ. Tiêu chuẩn cũng ghi rõ việc sử dụng đặc tả này là tự nguyện, không có tính ràng buộc, và việc áp dụng tùy thuộc vào quyết định của các bên liên quan. Điều khoản miễn trừ nêu rằng bên áp dụng chịu trách nhiệm sử dụng đúng trong từng trường hợp cụ thể, và văn bản không thay thế cho việc diễn giải pháp luật.

Số phiên bản theo semantic versioning: bản chính (x.0.0) thường gồm các thay đổi không tương thích ngược, bản phụ là chức năng mới, bản vá là các chỉnh sửa nhỏ như sửa lỗi văn bản. README trên GitHub ghi rằng thời gian tới dự kiến có 3.0.1 (sửa nhỏ) và 3.1.0 (thay đổi tương thích ngược), còn 4.0.0 hiện chưa được lên kế hoạch. Nội dung và thời điểm của phiên bản tiếp theo không được bàn trong bài này.

Cơ chế truyền thông

Truyền thông được giả định đi qua mạng không dây, và cần tính đến ảnh hưởng của mất kết nối hay mất thông điệp. Giao thức thông điệp là MQTT, dùng kết hợp với định dạng JSON, và phiên bản tối thiểu để đảm bảo tương thích là MQTT 3.1.1. Với broker cục bộ, cấu trúc topic được khuyến nghị là “interfaceName/majorVersion/manufacturer/serialNumber/topic”, tức số phiên bản chính nằm trong topic. Các topic của 3.0.0 như sau.

Bản 2.1.0 có 6 topic là order, instantActions, state, visualization, connection, factsheet; zoneSet và responses được thêm vào ở 3.0.0. Ở bản 2.1.0, các thay đổi chính so với 2.0.0 gồm phạm vi di chuyển tự do trong bề rộng lối đi (corridors), phân phối bản đồ, gợi ý lỗi, và bổ sung thông tin cấu hình xe vào factsheet.

Những gì VDA 5050 thống nhất và không thống nhất

Khi tính đến điều khiển nhiều hãng, sự phân biệt này là quan trọng nhất. Bảng dưới đặt cạnh nhau những gì tiêu chuẩn quy định và những gì chính tiêu chuẩn ghi là “không đề cập”.

6 hạng mục “không thống nhất” được ghi nguyên văn trong mục 2 Scope của tiêu chuẩn. Nói cách khác, dù mua hệ thống điều khiển và xe hỗ trợ VDA 5050, 6 hạng mục này vẫn chưa được quyết định tại thời điểm mua. Các chương RFP và FAT/SAT ở nửa sau bài viết gần như là công việc để doanh nghiệp tự lấp đầy 6 hạng mục này.

Một hãng AGV (BlueBotics) trong bài giải thích của mình nêu các giới hạn của VDA 5050 gồm: không có định dạng bản đồ thống nhất, không quy định việc diễn giải lỗi phức tạp hay điều phối phục hồi, an ninh được giao cho bên tích hợp, và mỗi lần thêm một loại xe mới thì gần như chắc chắn cần phát triển phần mềm riêng ở mức nào đó. Đây là quan điểm của một công ty, nhưng về định dạng tệp bản đồ và an ninh thì không mâu thuẫn với nội dung trong văn bản tiêu chuẩn.

Khác biệt với các sáng kiến tương tác khác

Ngoài VDA 5050, còn có các sáng kiến khác để cùng vận hành xe của nhiều hãng.

• MassRobotics AMR Interoperability Standard (phiên bản 1.0): do MassRobotics của Mỹ xây dựng. Đây là tiêu chuẩn chia sẻ các thông tin như vị trí, tốc độ, hướng, tình trạng, nhiệm vụ và trạng thái sẵn sàng để AMR của nhiều nhà cung cấp có thể “cùng tồn tại” trên mặt sàn. Truyền tải bằng WebSocket, thông điệp bằng JSON, thông điệp trạng thái được gửi khi có thay đổi với tần suất tối đa 1 lần mỗi giây. Văn bản nêu rằng không được dựa vào tiêu chuẩn này cho các mục đích liên quan đến an toàn, và mỗi hệ thống robot vẫn chịu trách nhiệm về an toàn và di chuyển của chính mình. Trong khi VDA 5050 là giao diện để “hệ thống điều khiển ra lệnh cho xe”, MassRobotics 1.0 chủ yếu là chia sẻ trạng thái và không quy định định dạng lệnh di chuyển.
• Open-RMF: phần mềm mã nguồn mở miễn phí cho phép chia sẻ và tương tác giữa nhiều đội robot với hạ tầng vật lý như cửa, thang máy, hệ thống quản lý tòa nhà. Từ năm 2024, dự án do Open Source Robotics Alliance (OSRA) điều hành. Ban đầu được phát triển cho cơ sở y tế, và được cho là cũng dùng được cho nhà máy và trung tâm logistics.
• openTCS: phần mềm điều khiển vận chuyển mã nguồn mở của Fraunhofer IML. Theo thông báo, kho mã độc lập của bộ chuyển đổi truyền thông VDA 5050 đã được lưu trữ (archive) vào tháng 8 năm 2026 và được tích hợp vào bản thân openTCS (từ 7.4 trở đi).

5 chỗ hay bị dừng khi vận hành đội AMR nhiều hãng

Khi vận hành xe của nhiều hãng trong cùng một nhà máy, những chỗ bị dừng gần như đã định sẵn. Nếu rà soát 5 chỗ này ở giai đoạn kiểm kê, đó sẽ là căn cứ để chọn phương thức điều khiển.

① Khu vực giao cắt

Thường gặp nhất là khu vực giao cắt. Hệ thống điều khiển riêng của hãng có thể cho các xe của chính hãng nhường nhau, nhưng không biết vị trí xe của hãng khác. Vì mỗi xe đều có chức năng an toàn, xe sẽ dừng trước khi va chạm. Nhưng nếu không có ai quyết định sau khi dừng thì bên nào đi trước, cả hai sẽ chờ mãi. Tại hiện trường, vấn đề được giải quyết bằng cách “người di chuyển thủ công một xe”, và điều đó trở thành chuyện thường ngày.

② Thiết bị dùng chung

Cửa tự động và thang máy là tài nguyên mỗi lúc chỉ dùng được cho một xe. Nếu nối tín hiệu gọi của từng hãng vào PLC của thiết bị, phía PLC phải lập trình thêm “nhận lệnh gọi của bên nào trước” và “làm gì khi xe của hãng khác đến trong lúc thiết bị đang được dùng”. Chi tiết liên kết với thang máy xem bài “Tích hợp AGV với thang máy: RFP và nghiệm thu FAT/SAT“, cách chọn bộ sạc xem bài “Chọn hệ thống sạc AGV tự động cho nhà máy Thái Lan“.

③ Lệch bản đồ và tọa độ

Xe của mỗi hãng tạo bản đồ theo cách riêng của hãng. Gốc tọa độ và hướng trục có thể khác nhau theo hãng, nên muốn chồng các bản đồ lên ở lớp cấp trên thì cần chuyển đổi tọa độ. Nếu chuyển đổi sai, có thể xảy ra chuyện trên màn hình cấp trên xe đáng lẽ đang ở trước ngã tư, nhưng thực tế đã nằm trong ngã tư.

④ Khác biệt ý nghĩa của hành động và lỗi

VDA 5050 quy định các hành động mặc định như pick, drop, startCharging, nhưng khi không phù hợp thì hãng có thể định nghĩa hành động riêng. Lỗi cũng đã có mức được quy định, nhưng loại lỗi và nội dung lỗi tùy vào cách hiện thực của hãng. Để tạo được trạng thái “những thứ cùng nghĩa hiển thị giống nhau” trên màn hình cấp trên, cần có bảng đối chiếu.

⑤ Nhiều cửa nhận lệnh vận chuyển

Nếu nguồn lệnh vận chuyển chia ra WMS, MES, nút gọi, người vận hành, và lại đi qua các cửa riêng theo từng hãng, cùng một lệnh vận chuyển có thể bị phát hai lần, hoặc lệnh hủy chỉ đến được một bên. Về cơ chế gọi xe nâng và gọi vận chuyển, có thể tham khảo thêm bài “Hệ thống gọi và điều phối xe nâng: PoC 30 ngày, RFP và nghiệm thu“.

So sánh 4 phương thức kiến trúc của hệ thống điều khiển trung tâm AGV

Ai nắm chỗ nào trong 5 chỗ trên sẽ quyết định phương thức điều khiển. Có thể chia thành 4 phương thức chính để so sánh.

Phương thức A: Thống nhất về 1 hãng

Đơn giản nhất, và trách nhiệm cũng gom về 1 hãng. Tuy nhiên chi phí thay xe hiện có, thời gian dừng trong khi thay, và rủi ro phụ thuộc vào 1 hãng khác nhau rất nhiều tùy nhà máy. Nếu sắp đến lúc thay các AGV băng từ đời cũ, đây là một lựa chọn đáng cân nhắc.

Phương thức B: Điều khiển riêng của hãng + điều phối vùng

Giữ nguyên hệ thống điều khiển của từng hãng, và đặt ở lớp cấp trên một “cổng” cho phép “có được vào hay không” đối với khu vực giao cắt và thiết bị dùng chung. Lớp cấp trên chỉ quản lý việc khu vực còn trống hay không và thứ tự, còn chạy theo lộ trình nào thì giao cho hệ thống điều khiển của từng hãng. Cách kết nối khác nhau theo hãng, như qua API của hệ thống điều khiển của hãng, tín hiệu dừng và chạy lại trước khu vực, hay qua PLC phía thiết bị, nên cần phát triển giao diện riêng cho từng hãng. Nếu chỉ có khoảng 2 hãng và vài khu vực giao cắt, đây là phương thức dễ triển khai.

Phương thức C: Tích hợp vào lớp điều khiển cấp trên bằng giao diện chung

Lớp điều khiển cấp trên hỗ trợ VDA 5050 trực tiếp ra lệnh di chuyển cho xe của từng hãng. Nhiều công ty phần mềm và hãng xe cung cấp sản phẩm theo dạng này. Tất cả đều là tuyên bố của nhà cung cấp (vendor claim), nhưng có thể kể ví dụ các giải thích sau.

• SYNAOS cho biết trên trang web của mình rằng có thể điều khiển tập trung AMR, AGV và xe nâng theo chuẩn VDA 5050, không bị ràng buộc vào hãng nào. Trong ví dụ với ZF, doanh nghiệp công nghệ ô tô, bài giới thiệu nêu việc vận hành xe của các nhà cung cấp phần cứng khác nhau trên một hệ thống, và kế hoạch tích hợp 250 đến 300 xe mỗi năm trong 4 đến 5 năm tới (đây là nội dung trong bài giới thiệu tình huống, không phải kết quả thực tế).
• Navitec Systems cho biết với hệ thống fleet control “Navithor”, xe của bất kỳ nhà cung cấp nào cũng có thể kết hợp trong cùng một đội nhờ VDA 5050, và quảng bá khả năng liên kết với MES, WMS, ERP cũng như với hệ thống bên ngoài như thang máy và cảm biến cửa.
• BlueBotics cho biết phần mềm quản lý đội xe ANT server hỗ trợ VDA 5050, và ngoài AGV/AMR của khách hàng dùng công nghệ của hãng, còn có thể quản lý xe tuân thủ VDA 5050 của các thương hiệu khác.
• KUKA cho biết với phần mềm quản lý đội xe “KUKA.AMR Fleet”, có thể tích hợp AMR của các hãng khác nhau bằng VDA 5050, và liên kết với cửa, thang máy, WMS, ERP/MES, PLC.

Về phía xe cũng có các hình thức hỗ trợ. MiR (Mobile Industrial Robots) cho biết cung cấp “MiR VDA 5050 Adapter” thông qua SIer được chứng nhận, kết nối REST API của hãng với MQTT để trao đổi thông điệp giữa AMR của MiR và hệ thống quản lý đội xe của bên thứ ba hỗ trợ VDA 5050. Đây là hình thức xe có API riêng và hỗ trợ VDA 5050 qua bộ chuyển đổi (adapter).

Không phải sản phẩm nào cũng công bố rõ ràng phiên bản VDA 5050 được hỗ trợ (2.x hay 3.0) trong thông tin công khai. Khi so sánh sản phẩm, hãy xác nhận phiên bản, các chức năng tùy chọn dùng được, logic quản lý giao thông và liên kết với thiết bị ngoại vi bằng câu trả lời RFP và thử nghiệm nghiệm thu, chứ không phải bằng lời giải thích của nhà cung cấp. Bài viết này không khuyến nghị sản phẩm cụ thể nào.

Một ví dụ về hệ thống điều khiển của hãng Nhật là hệ thống điều khiển tập trung AGV “AOS” của Sharp, được cho là có thể điều phối xe bằng tự động tạo lộ trình ngắn nhất, tránh deadlock, liên kết theo tùy biến với thang máy, cửa tự động, băng tải cũng như MES, WMS, PLC, và cùng tồn tại với AGV và xe vận chuyển của hãng khác (đây là giải thích của công ty). Giữ hệ thống điều khiển của hãng như vậy làm “điều khiển riêng của hãng” trong phương thức B, hay dồn về theo phương thức A, cũng là điều cần cân nhắc.

Phương thức D: Middleware mã nguồn mở

Open-RMF là bộ thư viện và công cụ xây dựng trên ROS 2, có các mảng chức năng gồm lịch giao thông (điều phối giao thông), fleet adapter (cầu nối với hệ thống của từng hãng), adapter hạ tầng cho cửa, thang máy…, và phân phối nhiệm vụ. openTCS là phần mềm điều khiển vận chuyển của Fraunhofer IML, và theo thông báo thì bộ chuyển đổi truyền thông VDA 5050 đã được tích hợp vào bản thân phần mềm (từ 7.4 trở đi). Tuy nhiên, bộ chuyển đổi của openTCS hỗ trợ phiên bản VDA 5050 nào thì lần khảo sát này chưa xác nhận được.

Mã nguồn mở không tốn phí bản quyền, nhưng đổi lại vấn đề là ai chịu việc xây dựng, bảo trì, theo kịp phiên bản và trách nhiệm khi có sự cố. Quyết định dựa trên việc có thể chuẩn bị được, dưới dạng hợp đồng, một cơ chế bảo trì để không làm dừng hoạt động vận chuyển của nhà máy hay không.

Chọn như thế nào

Có 4 trục để quyết định: số hãng, số khu vực giao cắt và thiết bị dùng chung, số hãng có tăng thêm hay không, và xe hiện có có hỗ trợ giao diện chung hay không. Nếu có 2 hãng và ít khu vực giao cắt thì bắt đầu từ phương thức B, và khi đã thấy trước hãng thứ 3 thì cân nhắc phương thức C; đó là thứ tự hợp lý. Căn cứ của thứ tự này sẽ được thể hiện bằng con số trong phần “tính toán chi phí theo mô hình” phía sau.

Quyết định phạm vi thống nhất: bản đồ và hệ tọa độ, node và edge, hành động, lỗi, sạc, thông tin thông số

Dù chọn phương thức C hay chỉ làm điều phối vùng theo phương thức B, cũng cần quyết định trước “thống nhất cái gì, đến mức nào”. Dựa vào các quy định của VDA 5050, hãy xem lần lượt 6 hạng mục.

Bản đồ và hệ tọa độ

Trong VDA 5050, để đảm bảo việc di chuyển nhất quán giữa các loại robot di động khác nhau, vị trí luôn được biểu diễn trong “hệ tọa độ riêng của dự án”. Để phân biệt tầng nhà và tương tự, dùng mapId duy nhất; hệ tọa độ bản đồ là hệ tay phải với trục z hướng lên, chiều quay dương là ngược chiều kim đồng hồ, X, Y, Z tính bằng mét, hướng tính bằng radian. Mỗi tầng có bản đồ riêng, nhưng tất cả bản đồ dùng chung một gốc toàn cục riêng của dự án. Khi chuyển tầng bằng thang máy, xe biến mất khỏi bản đồ tầng xuất phát và xuất hiện tại node thang máy trên bản đồ tầng đến.

Việc phân phối bản đồ cũng có quy định. Tệp bản đồ được đặt trên máy chủ bản đồ mà xe truy cập được, và lớp điều khiển cấp trên ra lệnh tải về bằng hành động tức thời downloadMap. Bản đồ được nhận diện bằng cặp mapId và mapVersion; nếu xe không có bản đồ ứng với mapId trong lệnh, xe sẽ báo “UNKNOWN_MAP_ID”. Và việc đảm bảo bản đồ đúng đang được kích hoạt là trách nhiệm của lớp điều khiển cấp trên. Mặt khác, bản thân định dạng tệp bản đồ không được tiêu chuẩn thống nhất.

Để có tọa độ chung, MassRobotics 1.0 đưa ra cách xác định từ 2 điểm trở lên (khuyến nghị từ 3 điểm) các mốc vật lý trong cơ sở (cột…) làm “Datum Reference Point”, rồi mỗi nhà cung cấp đo cùng các điểm đó trên bản đồ của mình để chuyển đổi tọa độ. Khi thống nhất bằng VDA 5050, cách nghĩ này cũng dùng được cho thử nghiệm nghiệm thu: đo cùng một điểm vật lý trên bản đồ của từng hãng và xác nhận xem có khớp với tọa độ trên lớp điều khiển cấp trên hay không.

Những điều cần quyết định là: gốc tọa độ và hướng trục chung, cách đặt mapId theo từng tầng, ai cập nhật bản đồ, tăng mapVersion thế nào và phân phối cho xe theo thứ tự nào. Thay đổi layout đồng nghĩa với thay đổi phiên bản bản đồ, nên nếu người phụ trách điều khiển tham gia ngay từ giai đoạn thiết kế layout thì sẽ giảm làm lại. Cách nghĩ về layout được trình bày trong bài “Thiết kế layout AGV 2026 – Số lượng xe không do lượng vận chuyển quyết định“.

Node và edge

Lệnh di chuyển của VDA 5050 là một phần của đồ thị gồm node và edge. Toàn bộ đồ thị do lớp điều khiển cấp trên nắm giữ; các ràng buộc như xe nào được đi qua edge nào không được gửi cho xe, mà phía điều khiển chỉ đưa vào lệnh “những edge xe đó được phép đi qua”. Có thể gửi tách riêng đoạn đã giải phóng (base) và đoạn dự kiến chưa giải phóng (horizon).

Điều cần quyết định ở đây là đặt node trước khu vực giao cắt như thế nào, và mỗi lần giải phóng đến đâu. Điều này liên quan đến thử nghiệm “mất kết nối” phía sau: dù mất kết nối với lớp điều khiển cấp trên, xe vẫn thực hiện lệnh cho đến node được giải phóng cuối cùng. Nếu một lần giải phóng đến tận bên trong khu vực giao cắt, khi mất kết nối xe có thể đi vào khu vực đó.

Để nhập tuyến đường, có thể dùng LIF (Layout Interchange Format) của VDMA, hoặc bên vận hành cũng có thể thiết lập thủ công. Tuy nhiên, tiêu chuẩn ghi rõ “việc thiết lập tuyến và mạng tuyến nằm ngoài phạm vi văn bản này”.

Hành động

Các hành động mặc định (pick, drop, startCharging, stopCharging, initializePosition, downloadMap, enableMap, factsheetRequest, waitForTrigger…) được dùng khi năng lực của xe khớp với mô tả. 3 hành động cancelOrder, startPause, stopPause bắt buộc mọi robot di động phải hỗ trợ. Khi không phù hợp, hãng xe có thể định nghĩa thêm hành động.

Vì vậy, khác biệt về từ vựng hành động giữa các hãng không tự biến mất chỉ nhờ tiêu chuẩn. Hãy lập danh sách các hành động dùng trong nhà máy (bốc, dỡ, chờ, sạc, giao nhận với băng tải…) và yêu cầu từng hãng trả lời trong RFP rằng sẽ thực hiện bằng hành động mặc định nào, hoặc bằng hành động riêng nào. Về đặc tả giao nhận với băng tải, có thể tham khảo thêm bài “AMR gắn băng tải: đặc tả giao tiếp và PoC 90 ngày“.

Lỗi và trạng thái

VDA 5050 3.0.0 có 4 mức lỗi.

Ở mọi mức, xe không được xóa lệnh với lý do có lỗi. Mức lỗi được thống nhất, nhưng loại lỗi và câu chữ tùy vào cách hiện thực của hãng. Hãy yêu cầu từng hãng nộp danh sách lỗi và lập bảng đối chiếu với cách xử lý của nhà máy (người nhận thông báo, chuyển xe, con người can thiệp).

Trạng thái được gom vào một topic để gửi, khi có sự kiện liên quan xảy ra hoặc ít nhất mỗi 30 giây. Có 7 chế độ vận hành: AUTOMATIC, SEMIAUTOMATIC, INTERVENED, MANUAL, STARTUP, SERVICE, TEACH_IN; hệ thống điều khiển chỉ điều khiển xe ở AUTOMATIC và SEMIAUTOMATIC. Ở MANUAL, SERVICE, TEACH_IN, hệ thống điều khiển không được gửi lệnh hay hành động, và khi vào các chế độ này xe xóa lệnh hiện tại. Cũng cần quyết định trước khi nhân viên bảo trì chuyển xe sang chế độ thủ công thì phía lớp điều khiển cấp trên và WMS xử lý lệnh vận chuyển đó thế nào.

Sạc

Trong các chức năng của lớp điều khiển cấp trên có nêu quản lý năng lượng (lệnh sạc có thể chen ngang lệnh vận chuyển), và trong các hành động cũng có startCharging và stopCharging. Mặt khác, bản thân bộ sạc có thể là sản phẩm chuyên dụng của từng hãng. Những điều cần quyết định là: tách bộ sạc theo hãng hay dùng chung, cho xe đi sạc ở mức pin nào và theo phán đoán của ai, thứ tự khi xe của 2 hãng cùng lúc pin yếu.

Thông tin thông số (factsheet)

factsheet là thông tin cơ bản của dòng kiểu xe, dùng được cả như tài liệu cho người đọc lẫn như JSON để máy xử lý mà hệ thống điều khiển nạp vào. Các mục gồm loại và năng lực của xe, đặc tính vật lý, giới hạn độ dài của định danh và mảng, các tham số tùy chọn và hành động được hỗ trợ, hình dạng xe, đặc tả hàng hóa, phiên bản phần mềm và phần cứng… Những gì không có trong danh sách tham số tùy chọn được hỗ trợ thì được coi là “không hỗ trợ”. Ở 3.0.0, loại vùng mà từng xe hiểu được cũng được thông báo qua factsheet (vì có xe không xử lý được vùng, hoặc chỉ xử lý được một phần).

Có thể dùng factsheet theo cách yêu cầu từng hãng nộp ở giai đoạn RFP, rồi đối chiếu với bản lấy từ xe thực ở giai đoạn nghiệm thu. Nếu tốc độ tối đa, tải trọng, các hành động dùng được, phiên bản phần mềm khác nhau giữa giấy tờ và xe thực, lớp điều khiển cấp trên sẽ ra lệnh dựa trên tiền đề sai.

Tích hợp AGV với WMS, MES và thiết bị: gom cửa nhận lệnh vận chuyển về một

VDA 5050 coi giao diện với thiết bị ngoại vi, thiết bị hạ tầng và hệ thống IT bên ngoài là nằm ngoài phạm vi. Dù “giao tiếp với hệ thống ngoại vi như cửa, cổng, thang máy” được nêu là một chức năng của lớp điều khiển cấp trên, cách kết nối nằm ngoài tiêu chuẩn. Tức là cả liên kết với WMS và MES lẫn liên kết với cửa, thang máy, băng tải đều phải viết đặc tả theo từng dự án.

Lệnh vận chuyển từ WMS và MES

Ở nhà máy có xe của nhiều hãng, điều đầu tiên nên quyết định là “gom cửa nhận lệnh vận chuyển về một”. WMS hay MES chỉ đưa ra yêu cầu vận chuyển “chở hàng này, từ đây đến đây, trước lúc này” mà không cần biết xe của hãng nào sẽ chở. Gán cho xe nào là do hệ thống điều khiển quyết định. Với hình thức này, dù số hãng tăng thì việc sửa đổi phía WMS cũng không tăng.

Với phương thức C, lớp điều khiển cấp trên trở thành cửa nhận lệnh vận chuyển. Với phương thức B, ngoài điều phối vùng ở lớp cấp trên, cần thêm một lớp phân phối yêu cầu vận chuyển cho hệ thống điều khiển của từng hãng. Trường hợp nào thì những điều cần quyết định cũng giống nhau.

• Đơn vị và định danh của yêu cầu vận chuyển (khi cùng một yêu cầu đến hai lần thì có phân biệt được không)
• Cách xử lý hủy và thay đổi (việc hủy sau khi xe đã bắt đầu chạy được tiếp nhận ở đâu, bởi ai)
• Báo cáo hoàn thành và thất bại (dịch chuyển tồn kho trên WMS có lệch với dịch chuyển hàng thực tế không)
• Đưa nút gọi và chỉ thị của người vào cùng cửa với yêu cầu từ WMS và MES, hay tách riêng

Ngoài ra, trong các hành động của tiêu chuẩn, cancelOrder là hành động mọi robot di động bắt buộc phải hỗ trợ. Tức là có phương tiện hủy từ lớp cấp trên xuống xe, nhưng nối lệnh hủy trên WMS thành lệnh hủy đến xe ở thời điểm nào là điều phải quyết định theo dự án.

Cửa, thang máy, băng tải

Tiêu chuẩn nêu rằng ở giai đoạn triển khai, cần định nghĩa trong mạng tuyến các điểm bốc dỡ, trạm sạc, môi trường xung quanh (cổng, thang máy, rào chắn), vị trí chờ, vùng đệm… Trên cơ sở đó, viết thành đặc tả: cách trao đổi tín hiệu với thiết bị (tín hiệu PLC hay truyền thông cấp trên), điều kiện interlock (xác nhận cửa đã mở hết bằng gì, xác nhận cabin thang máy đã dừng đúng tầng bằng gì), và cho xe chờ ở đâu khi thiết bị hỏng.

Đặc biệt quan trọng khi có nhiều hãng là phát lệnh gọi thiết bị từ một chỗ duy nhất. Nếu nối tín hiệu của từng hãng vào thiết bị, phía thiết bị phải lập trình thêm logic điều phối tranh chấp, và mỗi lần thêm hãng lại phải sửa thiết bị. Nếu lớp điều khiển cấp trên (phương thức C) hoặc điều phối vùng (phương thức B) gom lệnh gọi thiết bị về một mối, để nhìn từ phía thiết bị thì “bên gọi luôn chỉ là một”, đặc tả phía thiết bị sẽ đơn giản hơn. Việc Open-RMF có thành phần “adapter hạ tầng” cho cửa và thang máy cũng gần với cách nghĩ này.

Yêu cầu, trả lời và timeout

Ở 3.0.0, khi cần sự cho phép của hệ thống điều khiển, chẳng hạn để vào một vùng, cơ chế mới được bổ sung là xe đưa ra yêu cầu trong trạng thái, và hệ thống điều khiển trả về “GRANTED”, “QUEUED”, “REJECTED” hoặc “REVOKED” qua topic responses. Sự cho phép có thể kèm thời hạn hiệu lực. Nếu câu trả lời không đến trong thời gian quy định, xe hành xử như chưa được cho phép và không thực hiện thao tác đó. Tiêu chuẩn ghi rằng cách xử lý timeout và thử lại được quyết định khi tích hợp, và không có con số nào về việc chờ bao nhiêu giây hay thử lại bao nhiêu lần. Hãy quyết định theo dự án, khớp với thời gian phản hồi của thiết bị.

An toàn và phân định trách nhiệm: những gì nằm ngoài phạm vi VDA 5050

Hỗ trợ chuẩn truyền thông không đảm bảo an toàn

VDA 5050 ghi rõ không được coi bản thân nó là tiêu chuẩn an toàn hay áp dụng như tiêu chuẩn an toàn. MassRobotics 1.0 cũng nêu không được dựa vào cho các mục đích liên quan đến an toàn. Tức là dù hỗ trợ tiêu chuẩn nào, chỉ riêng điều đó không đảm bảo an toàn. Chức năng an toàn của từng xe (giảm tốc và dừng nhờ máy quét laser an toàn, dừng khẩn cấp…) vẫn thuộc thiết kế và trách nhiệm của từng hãng xe. Cách chọn và nghiệm thu máy quét laser an toàn được trình bày trong bài “Chọn máy quét laser an toàn cho nhà máy Thái Lan: từ khảo sát đến nghiệm thu“.

Các tiêu chuẩn an toàn liên quan (trong phạm vi đã xác nhận)

R15.08 là tiêu chuẩn của Mỹ, và chúng tôi chưa xác nhận liệu nó có trở thành nghĩa vụ pháp lý tại Thái Lan hay không. Ngoài ra, văn bản ISO 3691-4 và R15.08 là có phí, ở đây chỉ giới thiệu trong phạm vi tóm tắt công khai, thông cáo báo chí và bài báo. Bài viết này không phải tư vấn về đạt chứng nhận hay tuân thủ pháp luật. Hãy xác nhận tiêu chuẩn và thủ tục cần áp dụng với tổ chức chứng nhận hoặc chuyên gia.

Việc R15.08 chia các phần theo vai trò (nhà sản xuất, nhà tích hợp, người sử dụng) là gợi ý khi suy nghĩ về phân định trách nhiệm trong môi trường nhiều hãng: an toàn của từng xe là của hãng, an toàn của kết quả tích hợp là của nhà tích hợp, duy trì an toàn trong vận hành là của người sử dụng.

Ai thực hiện đánh giá rủi ro sau khi tích hợp

Trong phạm vi đã xác nhận lần này, chúng tôi không tìm thấy điều khoản nào trực tiếp quy định ai thực hiện đánh giá rủi ro sau khi vận hành xe của nhiều hãng bằng một hệ thống điều khiển. VDA 5050 ghi rõ không phân chia trách nhiệm giữa bên vận hành, SIer, hãng xe và bên cung cấp hệ thống điều khiển. Do đó, đây là điều phải quyết định trong hợp đồng. Ít nhất hãy ghi các điểm sau vào hợp đồng và RFP.

• Ai thực hiện đánh giá rủi ro cho toàn bộ hệ thống sau khi tích hợp, và ai phê duyệt
• Mỗi lần thêm hãng, thay đổi layout hay bản đồ, thay đổi thiết lập của lớp điều khiển cấp trên, ai đánh giá lại
• Có được thay đổi thiết lập chức năng an toàn của từng xe (phạm vi giảm tốc và dừng…) vì yêu cầu của lớp điều khiển cấp trên hay không, và khi thay đổi thì ai phê duyệt

Khoanh vùng ban đầu khi có sự cố

Trong cấu hình nhiều hãng, khi xảy ra sự cố, không thể biết ngay “vấn đề nằm ở đâu”: xe, hệ thống điều khiển của hãng, lớp điều khiển cấp trên, broker, mạng không dây, thiết bị hay WMS. Hãy quyết định quy trình khoanh vùng ban đầu, và ghi thành văn bản ai xem log nào, liên lạc với ai. Trạng thái xe do lớp điều khiển cấp trên đưa ra (chế độ vận hành, lỗi, trạng thái kết nối) là căn cứ đầu tiên để khoanh vùng. Ngay ở giai đoạn RFP, hãy yêu cầu từng hãng trả lời thời gian phản hồi kể từ khi nhận thông báo sự cố, và cách tính chi phí khi cùng điều tra với công ty cung cấp lớp điều khiển cấp trên.

Mạng và an ninh mạng: MQTT broker, mạng không dây, phân quyền

VDA 5050 ghi rõ không quy định cơ chế, công nghệ và quy trình về an toàn truyền thông và bảo vệ dữ liệu. Tiêu chuẩn cũng viết “cần xem xét an ninh của giao thức trong cấu hình broker, nhưng hướng dẫn này không đề cập”. Dưới đây tách riêng những gì được viết trong tiêu chuẩn và những lưu ý thiết kế chung.

Những gì được viết trong tiêu chuẩn

• Truyền thông được giả định đi qua mạng không dây, cần tính đến ảnh hưởng của mất kết nối và mất thông điệp
• Dùng MQTT 3.1.1 trở lên
• QoS là 0 (Best Effort) cho order, instantActions, state…, và 1 (At Least Once) cho connection
• Khi kết nối với broker, xe thiết lập “Last Will”, và khi bị ngắt kết nối bất ngờ thì “CONNECTION_BROKEN” được phát trên topic connection. Khi ngắt kết nối bình thường xe gửi “OFFLINE”, khi kết nối gửi “ONLINE”, và các thông điệp này được gửi kèm cờ retained
• Dù xe bị ngắt khỏi broker, xe vẫn giữ lệnh đã nhận và thực hiện cho đến node được giải phóng cuối cùng
• Với MQTT broker trên đám mây, có thể cần điều chỉnh cấu trúc topic
• Ở 3.0.0, hành động tức thời updateCertificate để cập nhật chứng chỉ của xe được bổ sung

QoS 0 là thiết lập dựa trên tiền đề có thể có thông điệp không đến nơi. Khi lệnh di chuyển không đến, xe và lớp điều khiển cấp trên hành xử thế nào là đối tượng cần xác nhận trong thử nghiệm nghiệm thu.

Lưu ý thiết kế chung

Phần dưới đây không phải quy định của tiêu chuẩn, mà là cách nghĩ thiết kế chung.

• Vị trí đặt broker: đặt trong mạng hệ thống điều khiển của nhà máy hay trên đám mây. Nếu đặt trên đám mây, cần xem xét liệu khi đứt đường truyền internet thì hoạt động vận chuyển của nhà máy có bị dừng không
• Xác thực và phân quyền: tách thông tin xác thực theo từng xe, giới hạn quyền để mỗi xe chỉ đọc ghi được topic của chính mình. Không để bên nào khác ngoài lớp điều khiển cấp trên phát được order hay instantActions
• Cập nhật chứng chỉ: quyết định ai quản lý thời hạn và quy trình cập nhật chứng chỉ
• Mạng không dây: xác nhận bằng xe thực rằng trên toàn bộ tuyến vận chuyển không có chỗ mất sóng, và khi chuyển vùng (roaming) thì truyền thông không bị gián đoạn
• Bảo trì từ xa: ai cho phép và ghi nhận đường truy cập từ xa của từng hãng vào xe hay hệ thống điều khiển

Cách đưa yêu cầu an ninh mạng cho SIer FA được trình bày trong bài “An ninh mạng cho FA SIer — Hướng dẫn RFP và bằng chứng nghiệm thu tại Thái Lan 2026“. Các con số cụ thể (độ dài mật khẩu, chu kỳ cập nhật…) hãy quyết định theo chính sách an ninh thông tin của doanh nghiệp.

Tính toán chi phí theo mô hình: so sánh tổng 5 năm của phương thức B và C theo số hãng (số giả định)

Từ đây, bài viết dùng một nhà máy mô hình để thể hiện cấu trúc của phép tính, so sánh tổng chi phí 5 năm của phương thức B (điều khiển riêng của hãng + điều phối vùng) và phương thức C (tích hợp vào lớp điều khiển cấp trên bằng giao diện chung). Mọi số tiền dưới đây đều là số giả định đặt ra cho bài viết này. Không phải giá của nhà cung cấp, cũng không phải số liệu khảo sát. Hãy thay bằng báo giá của doanh nghiệp mình khi sử dụng.

Tiền đề của nhà máy mô hình

Giả sử một cơ sở của doanh nghiệp sản xuất vốn Nhật tại Thái Lan, đưa vào AGV/AMR từ nhiều hãng, và có khu vực giao cắt cùng thiết bị dùng chung. Đơn vị tiền tệ là baht Thái (THB), thời kỳ 5 năm. Số hãng xe được ký hiệu là V.

Phương thức B có chi phí cố định nhỏ và chi phí theo hãng lớn. Phương thức C thì ngược lại, chi phí cố định lớn và chi phí theo hãng nhỏ. Từ công thức, mỗi khi tăng thêm 1 hãng, tổng 5 năm tăng 1.000.000 THB với phương thức B và 250.000 THB với phương thức C.

Khi thay đổi số hãng, phương thức nào rẻ hơn

Điểm hòa vốn tính từ 300.000 + 1.000.000V = 2.500.000 + 250.000V, suy ra 750.000V = 2.200.000, V ≈ 2,93. Với các tiền đề giả định này, tổng 5 năm của phương thức B và phương thức C đảo chiều vào khoảng lúc đưa vào hãng thứ 3. Với 2 hãng, phương thức B rẻ hơn 700.000 THB; với 3 hãng gần như bằng nhau (phương thức C rẻ hơn 50.000 THB); với 4 hãng, phương thức C rẻ hơn 800.000 THB, và với 5 hãng rẻ hơn 1.550.000 THB.

Phương thức A (thống nhất về 1 hãng) không được quy ra tiền. Lý do là chi phí thay xe hiện có, thời gian dừng trong khi thay và rủi ro phụ thuộc 1 hãng khác nhau quá nhiều giữa các nhà máy.

Những gì không đưa vào phép tính này

• Mức tăng lượng vận chuyển hay việc giảm số xe cần thiết nhờ giảm thời gian chờ ở khu vực giao cắt (vì thay đổi rất nhiều theo luồng di chuyển của từng nhà máy)
• Chi phí cải tạo hay bộ chuyển đổi khi xe hiện có không hỗ trợ giao diện chung
• Khả năng không dùng được ở lớp điều khiển cấp trên các tối ưu (chức năng khai thác hiệu năng của xe) mà hệ thống điều khiển riêng của hãng có
• Thời gian khoanh vùng sự cố tăng hay giảm

Đặc biệt, mục thứ nhất là mục có lợi hơn cho phương thức C. Phương thức B chỉ nắm quyền độc chiếm khu vực mà không tối ưu hóa giao thông, nên thời gian chờ ở khu vực giao cắt vẫn còn ở mức nào đó. Ngược lại, mục thứ ba là mục bất lợi cho phương thức C. Vì cả hai đều không được quy ra tiền, đừng quyết định chỉ dựa vào chênh lệch trong bảng trên, mà hãy đặt 4 mục này cạnh nhau một cách định tính để phán đoán.

Phép tính cho thấy điều gì

Từ các tiền đề giả định này có thể rút ra thứ tự: nếu chỉ đến 2 hãng thì bắt đầu bằng phương thức B (điều phối vùng), và khi đã thấy trước việc thêm hãng thứ 3 thì cân nhắc phương thức C. Tuy nhiên, dù hãng thứ 3 chưa được xác định, chúng tôi khuyến nghị với những xe sắp mua mới, hãy yêu cầu trong RFP việc hỗ trợ giao diện chung (và phiên bản). Làm như vậy, khi chuyển sang phương thức C sau này, chi phí cải tạo hay bộ chuyển đổi cho xe hiện có sẽ giảm (hiệu quả này không được quy ra tiền). Cách nghĩ về chi phí của bản thân AGV và AMR được trình bày trong bài “Giá AGV và AMR: hướng dẫn TCO 5 năm cho nhà máy Thái Lan“.

Các hạng mục cần ghi trong RFP hệ thống quản lý đội xe AGV

Trong RFP, chỉ hỏi “có hỗ trợ VDA 5050 không” là chưa đủ. Hãy thiết kế để tự lấp đầy 6 hạng mục mà tiêu chuẩn không đề cập. Yêu cầu công ty cung cấp lớp điều khiển cấp trên, từng hãng xe và SIer cùng trả lời theo những hạng mục giống nhau.

Mục số 3 “phiên bản hỗ trợ” đặc biệt quan trọng. Số phiên bản chính nằm trong cấu trúc topic, và thay đổi phiên bản chính thường gồm các thay đổi không tương thích ngược. Việc tổ hợp xe và hệ thống điều khiển khác phiên bản có thực sự chạy được hay không thì không thể nói từ tiêu chuẩn, mà là điều cần xác nhận theo từng sản phẩm. Với câu trả lời chỉ ghi “hỗ trợ VDA 5050”, hãy tạm hoãn đánh giá cho đến khi biết phiên bản.

Những gì cần xác nhận trong PoC và FAT/SAT: thử nghiệm nghiệm thu cố ý tạo bất thường

Trong PoC và thử nghiệm nghiệm thu, không chỉ xác nhận xe có chạy khi mọi thứ bình thường hay không, mà còn phải xác nhận khi cố ý tạo bất thường, xe có dừng ở phía an toàn, trạng thái có hiển thị đúng ở lớp cấp trên, có phục hồi được đúng theo tài liệu, và có truy được nguyên nhân bằng log hay không. Một khi tiêu chuẩn đã ghi rõ không đề cập đến “quy trình kiểm tra xác nhận và nghiệm thu”, nội dung thử nghiệm chỉ có thể do doanh nghiệp tự quyết định. Chia thành thử nghiệm tại môi trường của nhà cung cấp hoặc SIer (FAT) và thử nghiệm tại nhà máy của mình, kết nối với mạng không dây, thiết bị và WMS thực tế (SAT).

7 tình huống cố ý thử

1. 2 hãng cùng lúc vào khu vực giao cắt: cho xe của 2 hãng chạy sao cho cùng lúc đến một khu vực giao cắt. Có phải chỉ một bên vào, bên kia chờ ở vị trí định sẵn phía trước hay không. Có rơi vào deadlock không.
2. Mất kết nối giữa lớp điều khiển cấp trên và xe: tạo vùng mất sóng, hoặc tắt access point. Vì xe thực hiện lệnh đến node được giải phóng cuối cùng, hãy xác nhận không giải phóng đến tận bên trong khu vực giao cắt. Màn hình cấp trên có hiển thị “CONNECTION_BROKEN” không.
3. Khởi động lại broker (hoặc máy chủ của lớp điều khiển cấp trên): khởi động lại trong lúc đang vận hành. Sau khi kết nối lại, trạng thái xe có trở về đúng ở lớp cấp trên không (trạng thái được gửi ít nhất mỗi 30 giây), có phát sinh lệnh trùng không.
4. factsheet không khớp với xe thực: tốc độ tối đa, tải trọng, các hành động dùng được trên giấy tờ có khớp với factsheet lấy từ xe thực không. Khi có mục không khớp, lớp điều khiển cấp trên có ra lệnh sai không.
5. Kết nối lại sau khi một hãng cập nhật phần mềm (firmware): cập nhật phần mềm cho xe của một bên và cho kết nối lại. Thông tin phiên bản trong factsheet có được cập nhật không. Cách xử lý hành động, lỗi, vùng có thay đổi không.
6. Tranh chấp bộ sạc: cho xe của 2 hãng cùng lúc pin yếu (tương đương URGENT). Thứ tự sạc có đúng như đã quyết định không. Việc chen ngang với lệnh vận chuyển có hoạt động đúng không.
7. Lệnh vận chuyển trùng lặp và hủy từ cấp trên (WMS và MES): gửi hai lần cùng một yêu cầu vận chuyển, hủy trong lúc xe đang chạy. Các lệnh trùng có được gộp thành 1 không. Lệnh hủy có đến được xe và không lệch với dịch chuyển tồn kho trên WMS không.

5 hạng mục cần xác nhận

Với mỗi tình huống, xác nhận 5 hạng mục sau.

Nếu lập bảng kết hợp 7 tình huống với 5 hạng mục và lưu kết quả đạt/không đạt cùng bằng chứng (ghi màn hình, log, video) ở từng ô, sẽ dễ so sánh kết quả FAT và SAT. Không phải tình huống nào cũng liên quan đến mọi hạng mục với cùng mức độ. Ví dụ, với tình huống cùng lúc vào khu vực giao cắt, trọng tâm là “dừng và chờ có ở phía an toàn không”, còn với kết nối lại sau cập nhật phần mềm, trọng tâm là “trạng thái có hiển thị đúng ở lớp cấp trên không” và “có truy được nguyên nhân bằng log không”.

Phân chia FAT và SAT

Trong FAT, chạy qua một lượt 7 tình huống tại bãi thử, xác nhận các mục lệnh, trạng thái, lỗi, log của tổ hợp lớp điều khiển cấp trên và xe của từng hãng. Trong SAT, chạy cùng các tình huống tại nhà máy của mình, trong trạng thái đã kết nối với mạng không dây, cửa, thang máy, bộ sạc, WMS thực tế. Mất kết nối và vùng mất sóng chỉ có thể xác nhận trong môi trường thực tế của nhà máy. Việc khớp tọa độ cũng được xác nhận bằng cách đo cùng một điểm vật lý trong nhà máy trên bản đồ của từng hãng.

Số giây timeout, số lần thử lại, và khi mất kết nối thì được giải phóng đến đâu đều không có con số trong tiêu chuẩn. Hãy quyết định dựa trên kết quả FAT, xác nhận trong SAT, và lưu các giá trị đã quyết định vào tài liệu. Sau khi đưa vào vận hành, mỗi lần hãng cập nhật phần mềm hay thay đổi bản đồ, hãy chạy lại thử nghiệm với trọng tâm là tình huống 4 và 5. Về cách triển khai AMR tại nhà máy hiện hữu, có thể tham khảo thêm bài “Nghiên cứu tình huống triển khai AMR: 6 mô hình cho nhà máy hiện hữu và PoC 90 ngày“.

Câu hỏi thường gặp

VDA 5050 là gì?

Là giao diện truyền thông giữa lớp điều khiển cấp trên (fleet control) và robot di động (AGV/AMR), do VDA và VDMA của Đức cùng xây dựng. Phiên bản hiện hành là 3.0.0 được công bố vào tháng 3 năm 2026, dùng MQTT và JSON, quy định định dạng của lệnh di chuyển, trạng thái, lỗi, hành động, phân phối bản đồ, thông tin thông số xe (factsheet)… Việc sử dụng là tự nguyện, không có tính ràng buộc.

Nếu hỗ trợ VDA 5050 thì AMR của các hãng khác nhau có chạy chung ngay được không?

Không hẳn là ngay được. Những gì VDA 5050 thống nhất là “cách nói chuyện” giữa hệ thống điều khiển và xe. Yêu cầu an toàn, logic quản lý giao thông, giao diện với thiết bị ngoại vi và IT cấp trên, quy trình nghiệm thu, phân chia trách nhiệm, an ninh mạng được chính tiêu chuẩn ghi rõ là không đề cập. Hơn nữa, hành động riêng, các mục tùy chọn được hỗ trợ, định dạng tệp bản đồ, phiên bản được hỗ trợ vẫn có thể còn khác biệt giữa các hãng. Việc hợp nhất bản đồ và hệ tọa độ, bảng đối chiếu hành động và lỗi, thử nghiệm nghiệm thu cần được thực hiện riêng.

Chi phí của hệ thống quản lý đội xe AGV là bao nhiêu?

Vì khác nhau rất nhiều theo sản phẩm và cấu hình, không thể đưa ra mức giá chung. Trong tính toán theo mô hình (giả định) của bài này, tổng 5 năm của phương thức B (điều khiển riêng của hãng + điều phối vùng) là 2.300.000 THB với 2 hãng và 3.300.000 THB với 3 hãng, của phương thức C (tích hợp vào lớp điều khiển cấp trên) là 3.000.000 THB với 2 hãng và 3.250.000 THB với 3 hãng; điểm hòa vốn là V ≈ 2,93, tức là đảo chiều vào khoảng hãng thứ 3. Hãy áp báo giá của doanh nghiệp mình vào cùng công thức.

Nếu AGV hiện có không hỗ trợ VDA 5050 thì sao?

Có một số lựa chọn: dùng bộ chuyển đổi nếu hãng có cung cấp (ví dụ MiR cho biết cung cấp bộ chuyển đổi VDA 5050 cho AMR của hãng), giữ xe hiện có với hệ thống điều khiển của hãng theo phương thức B và chỉ để lớp cấp trên nắm quyền độc chiếm khu vực giao cắt, kết nối bằng cơ chế như fleet adapter của Open-RMF, hoặc thay mới theo kỳ thay thế… Với cách nào cũng vậy, hãy xác nhận phiên bản được hỗ trợ và phạm vi chức năng dùng được. Với xe sắp mua mới, nếu yêu cầu việc hỗ trợ và phiên bản trong RFP, các lựa chọn sau này sẽ rộng hơn.

Tích hợp AGV với WMS thì kết nối ở đâu?

VDA 5050 coi giao diện với các hệ thống IT bên ngoài như WMS là nằm ngoài phạm vi, nên cách kết nối được quyết định theo dự án. Khi có nhiều hãng, nếu để WMS và MES chỉ đưa ra yêu cầu vận chuyển mà không cần biết hãng nào, và lấy lớp điều khiển cấp trên (hoặc lớp phân phối) làm cửa nhận lệnh vận chuyển, thì dù số hãng tăng, việc sửa đổi phía WMS cũng khó tăng lên. Cách xử lý trùng lặp và hủy nhất định phải được xác nhận trong thử nghiệm nghiệm thu.

Tổng kết

Khi vận hành AGV/AMR của các hãng khác nhau trong cùng một nhà máy, câu hỏi đầu tiên không phải là “có hỗ trợ VDA 5050 không”. Mà là ba điều: ① ai nắm quyền điều phối khu vực giao cắt và thiết bị dùng chung, ② thống nhất bản đồ và hệ tọa độ, hành động, ý nghĩa của lỗi đến mức nào, ③ phân chia trách nhiệm về an toàn và khi có sự cố ra sao. VDA 5050 là bản 3.0.0 công bố vào tháng 3 năm 2026, thống nhất cách nói chuyện giữa lớp điều khiển cấp trên và xe, nhưng ghi rõ không đề cập đến yêu cầu an toàn, logic quản lý giao thông, giao diện với thiết bị ngoại vi và IT cấp trên, quy trình nghiệm thu, phân chia trách nhiệm, an ninh mạng. Lấp đầy những phần đó bằng RFP và thử nghiệm nghiệm thu là việc của bên triển khai.

Cách tiến hành gồm 5 bước: kiểm kê vận chuyển, chọn phương thức điều khiển, quyết định phạm vi thống nhất, liên kết với hệ thống cấp trên và thiết bị, phân định trách nhiệm và thử nghiệm nghiệm thu. Trong tính toán theo mô hình (giả định), tổng 5 năm của phương thức B và C lần lượt là 2.300.000 THB và 3.000.000 THB với 2 hãng, 3.300.000 THB và 3.250.000 THB với 3 hãng, 4.300.000 THB và 3.500.000 THB với 4 hãng, 5.300.000 THB và 3.750.000 THB với 5 hãng, V ≈ 2,93, tức là đảo chiều vào khoảng lúc đưa vào hãng thứ 3. Đến 2 hãng thì bắt đầu bằng điều phối vùng, khi đã thấy trước hãng thứ 3 thì cân nhắc tích hợp vào lớp điều khiển cấp trên. Trên cơ sở đó, với những xe sắp mua, hãy yêu cầu trong RFP việc hỗ trợ giao diện chung và phiên bản. Quyết định theo thứ tự này sẽ làm rõ cần mua gì và doanh nghiệp phải tự quyết định gì.

TOMAS TECH hỗ trợ các nhà máy vốn Nhật tại Thái Lan tự động hóa vận chuyển, cũng như liên kết AGV, AMR với hệ thống cấp trên. Ngay cả ở giai đoạn chưa quyết định sản phẩm hay phương thức, chẳng hạn khi kiểm kê vận chuyển hoặc khi quyết định chọn phương thức điều khiển nào, quý vị cũng có thể trao đổi với chúng tôi. Vui lòng liên hệ qua biểu mẫu này.

Tài liệu tham khảo

• VDA5050/VDA5050 – Release VDA 5050 3.0.0 (GitHub)
• VDA5050/VDA5050 – Releases (GitHub)
• VDA5050/VDA5050 – README (GitHub)
• VDA5050/VDA5050 – VDA5050_EN.md (v3.0.0, nhánh main)
• VDA5050/VDA5050 – VDA5050_EN.md (tag v2.1.0)
• Verband der Automobilindustrie (VDA) – VDA 5050
• idealworks – VDA 5050 3.0.0 release (tháng 3 năm 2026)
• MassRobotics – Mass Robotics Interoperability Standard – Version 1.0 (GitHub)
• Open-RMF
• Open Robotics – Programming Multiple Robots with ROS 2 — Introduction
• openTCS – opentcs-commadapter-vda5050 (GitHub)
• Swedish Institute for Standards (SIS) – SS-EN ISO 3691-4:2023
• Association for Advancing Automation (A3) – ANSI/A3 R15.08-2 Safety Standard for Industrial Mobile Robot Systems and Applications Now Available (ngày 9 tháng 10 năm 2023)
• Robotics & Automation News – Industry body A3 releases final part of safety standard for industrial mobile robots (ngày 2 tháng 10 năm 2026)
• Robotics 24/7 – A3 announces R15.08 Part 3 safety standard for industrial mobile robot users is now available (ngày 4 tháng 10 năm 2026)
• Fraunhofer IML – Saying Goodbye to Communication Problems (discover logistics 25, 2024)
• SYNAOS
• IoT Use Case – Steering heterogeneous AGV fleets vendor-neutrally via VDA 5050 (ngày 25 tháng 8 năm 2026)
• Navitec Systems – Universal Fleet Control – Navithor
• BlueBotics – VDA 5050 Explained – An Overview of the Evolving AGV Communication Standard (cập nhật tháng 4 năm 2026)
• Mobile Industrial Robots – MiR Supports interoperability with new VDA5050 Adapter (ngày 11 tháng 3 năm 2025)
• KUKA – KUKA.AMR Fleet
• Sharp – AGV Operating System (AOS)
• International Federation of Robotics (IFR) – Global Sales of Professional Service Robots Surge 24% (ngày 30 tháng 9 năm 2026)
• Tilleke & Gibbins – Thailand Unveils New Incentives for Automotive and HEV/PHEV Manufacturing (ngày 21 tháng 4 năm 2026)
• American Journal of Transportation (AJOT) – BlueBotics and Planet T & S enter into distribution agreement to grow Thai AGV market (ngày 4 tháng 10 năm 2021)