ถ้า Network หลุด AMR จะหยุดทำงานหรือยังสามารถวิ่งต่อได้?

AMR ไม่ได้มีพฤติกรรมเหมือนกันทุกระบบเมื่อ Network หลุด บางระบบอาจทำ Mission ปัจจุบันต่อได้ด้วยระบบประมวลผลบนตัว Robot ขณะที่บาง Function เช่น Fleet Management, Task ใหม่ หรือ Integration อาจหยุดชั่วคราว จึงต้องตรวจ Architecture และทดสอบ Failure Scenario ก่อนใช้งานจริง

คำถามว่า “Wi-Fi หลุดแล้ว AMR จะหยุดไหม?” เป็นหนึ่งในประเด็นสำคัญก่อนนำ AMR (Internal Link → /amr) มาใช้ใน Production

เพราะในโรงงานจริง Network อาจมีช่วงที่สัญญาณอ่อน Access Point มีปัญหา Server ติดต่อไม่ได้ หรือระบบส่วนกลางขาดการเชื่อมต่อชั่วคราว

สิ่งที่ต้องเข้าใจคือ AMR ไม่ได้มี Architecture แบบเดียวกันทั้งหมด

บางระบบสามารถ Navigation และควบคุมการเคลื่อนที่จาก Computer บนตัว Robot ขณะที่ Fleet Management หรือ Task Scheduling อยู่บน Server

ดังนั้นสิ่งที่เกิดขึ้นเมื่อ Network หลุดจึงขึ้นอยู่กับว่า Function ไหนอยู่บน Robot และ Function ไหนต้องพึ่งระบบส่วนกลาง

เมื่อ Network หลุด AMR อาจเกิดอะไรขึ้นได้บ้าง?

สถานการณ์ที่เป็นไปได้มีหลายรูปแบบ ดังนี้

เหตุการณ์	สิ่งที่อาจเกิดขึ้น
Wi-Fi หลุดชั่วคราว	Robot อาจทำ Mission เดิมต่อ หรือเข้าสู่ Safe State
Fleet ติดต่อ Robot ไม่ได้	ระบบส่วนกลางอาจมอง Robot เป็น Offline
Task ปัจจุบันยังอยู่ใน Robot	อาจทำ Mission ต่อได้
ต้องรับ Task ใหม่	อาจต้องรอ Connection กลับมา
Traffic Control หาย	ระบบอาจจำกัดการเคลื่อนที่เพื่อความปลอดภัย
MES/WMS Offline	ไม่สามารถสร้างหรือยืนยัน Task ใหม่ได้
Server Fleet Offline	Robot หลายตัวอาจไม่สามารถ Coordination ได้
Network กลับมา	ระบบต้อง Reconnect และ Sync สถานะ

คำว่า “วิ่งต่อได้หรือไม่” จึงไม่ควรตอบเพียง Yes หรือ No

แต่ควรถามว่า

Function ไหนยังทำงานได้ และ Function ไหนหยุดเมื่อ Network ขาด

AMR สามารถ Navigation ได้เองโดยไม่ใช้ Wi-Fi หรือไม่?

AMR หลายระบบมี Sensor และระบบประมวลผลบนตัว Robot ทำให้ Navigation บางส่วนสามารถทำได้โดยไม่ต้องส่งทุกคำสั่งผ่าน Wi-Fi แต่ความสามารถจริงขึ้นอยู่กับ Architecture ของระบบ

บนตัว Robot อาจมีอุปกรณ์ เช่น

• LiDAR

• Camera

• Encoder

• IMU

• Onboard Computer

ใช้สำหรับตรวจสภาพแวดล้อมและคำนวณตำแหน่ง

ดังนั้นการเคลื่อนที่จากจุด A ไป B ไม่จำเป็นต้องหมายความว่า Server เป็นผู้บังคับ Robot ทุกวินาที

แต่ Fleet Management อาจยังมีหน้าที่

แจก Task → จัด Traffic → กำหนด Priority → Monitor Fleet

ทำให้แม้ Navigation ยังทำงานได้ Function อื่นก็อาจได้รับผลกระทบเมื่อ Network หลุด

Mission ปัจจุบันของ AMR จะทำต่อได้ไหมเมื่อ Network หลุด?

ขึ้นอยู่กับว่า Mission ถูกส่งลง Robot ครบแล้วหรือยัง และระบบถูกออกแบบให้ทำงานแบบ Offline ได้ระดับไหน

ตัวอย่างหนึ่งอาจเป็น

Fleet ส่งคำสั่ง:

ไปรับ Pallet ที่ A → ส่ง B

Robot ได้รับ Mission แล้วและกำลังวิ่งอยู่

หาก Connection ขาด ระบบบางประเภทอาจให้ Robot ทำ Mission ปัจจุบันต่อจนถึง Safe Point

ขณะที่อีกระบบอาจกำหนดให้ Robot ลดความเร็ว หยุด หรือรอการเชื่อมต่อกลับมา

จึงควรถาม Vendor ให้ชัดว่า

“ถ้า Network หลุดระหว่าง Mission Robot จะทำอะไร?”

และไม่ควรสมมติจาก AMR ยี่ห้ออื่น

แล้ว AMR จะรับ Task ใหม่ได้หรือไม่?

หาก Task ถูกสร้างและส่งผ่าน Fleet Management หรือ Server ส่วนกลาง การรับ Task ใหม่มักต้องอาศัยการเชื่อมต่อ Network ตาม Architecture ของระบบ

ดังนั้นแม้ Robot จะทำ Mission เดิมสำเร็จ

แต่เมื่อถึงปลายทางแล้วอาจไม่สามารถรับ Mission ถัดไปได้จนกว่า Connection จะกลับมา

ตัวอย่าง Flow ปกติ:

Fleet → Robot → ทำ Mission → Complete → Fleet ส่ง Task ใหม่

เมื่อ Network หลุด:

Robot → Complete Mission → รอ Connection → รับ Task ใหม่

แต่พฤติกรรมจริงควรตรวจจากระบบที่ใช้งาน

Network หลุดมีผลต่อ Fleet Management อย่างไร?

Fleet Management ต้องรู้สถานะและตำแหน่งของ Robot เพื่อจัด Task และ Traffic ดังนั้น Connection ที่ไม่เสถียรอาจกระทบ Coordination ระหว่าง Robot หลายตัว

ตัวอย่างเช่นมี AMR 10 ตัวใน Warehouse

Fleet ต้องรู้ว่า

ตัวไหนว่างตัวไหนติด Missionตัวไหนกำลัง Chargingตัวไหนอยู่ใน Zone ไหน

หาก Robot ตัวหนึ่งขาดการเชื่อมต่อ Fleet อาจไม่สามารถใช้ข้อมูลสถานะล่าสุดเพื่อวางแผนได้อย่างมั่นใจ

ในบาง Architecture ระบบจึงอาจกำหนดมาตรการ Safety เพื่อลดความเสี่ยงจาก Robot ที่สถานะไม่ชัดเจน

ทำไม AMR หลายตัวจึงได้รับผลจาก Network มากกว่าระบบ Robot ตัวเดียว?

เพราะเมื่อมี Robot หลายตัว ระบบต้อง Coordination เรื่อง Route, Queue, Priority และ Shared Zone มากขึ้น

สมมติมี AMR ตัวเดียววิ่งใน Route ปิด

การตัดสินใจอาจไม่ซับซ้อนมาก

แต่เมื่อมี 20 ตัว ทุกตัวอาจต้องใช้

• ทางแยก

• Narrow Zone

• Charging Station

• Pickup Station

• Drop-off Station

ร่วมกัน

Fleet จึงต้องบริหาร Traffic ระหว่าง Robot

ถ้า Communication ไม่ครบถ้วน ระบบอาจไม่สามารถยืนยันได้ว่า Zone ใดว่างจริง

นี่คือเหตุผลที่ Network Reliability มีความสำคัญมากขึ้นเมื่อ Fleet ขยาย

ถ้า MES หรือ WMS หลุด แต่ AMR ยัง Online จะเกิดอะไรขึ้น?

Robot อาจยัง Online กับ Fleet แต่ไม่สามารถรับ Business Task ใหม่จาก MES หรือ WMS ได้ หาก Task Generation พึ่งระบบเหล่านั้น

ตัวอย่าง Flow:

MES → สั่ง Replenishment → Fleet → AMR

ถ้า MES Offline:

MES ✕ → ไม่มี Request ใหม่ → Fleet ไม่มี Task → Robot รอ

Robot ไม่ได้เสีย

Network ของ Robot ก็ไม่ได้เสีย

แต่ Business Workflow หยุด

จึงต้องแยกให้ชัดว่า Incident อยู่ที่

Robot, Network, Fleet หรือ Business System

ถ้า Fleet Server ล่ม AMR จะเกิดอะไรขึ้น?

ผลขึ้นอยู่กับ Architecture ของ Fleet Management แต่ Function ที่เกี่ยวกับ Task Scheduling, Traffic Coordination และ Central Monitoring มีโอกาสได้รับผลกระทบ

จึงควรถามก่อนติดตั้งว่า

• Fleet Server อยู่ที่ไหน

• มี Redundancy หรือไม่

• Backup ทำอย่างไร

• Restart ใช้ Procedure แบบใด

• Robot Behavior ตอน Server Offline เป็นอย่างไร

• หลัง Server กลับมา Sync Status อย่างไร

โดยเฉพาะโรงงานที่พึ่ง AMR กับ Critical Material Flow

Fleet Management ควรถูกมองเป็นส่วนหนึ่งของ Production Infrastructure

ไม่ใช่เพียง Dashboard

Safe State ของ AMR คืออะไร?

Safe State คือพฤติกรรมที่ระบบกำหนดเมื่อไม่สามารถยืนยันเงื่อนไขบางอย่างได้ เช่น Network หรือระบบควบคุมขาดการเชื่อมต่อ โดยเป้าหมายคือไม่ให้ Robot ทำงานต่อในสถานการณ์ที่มีความเสี่ยง

Safe State อาจแตกต่างกัน เช่น

ลดความเร็ว

หยุดในตำแหน่งปัจจุบัน

ไปยัง Safe Location

จบ Mission ปัจจุบัน

หรือรอ Connection

ไม่มีรูปแบบเดียวที่ถูกต้องสำหรับทุก Process

เพราะ Robot ที่ขนสินค้าใน Warehouse กับ Robot ที่วิ่งผ่าน Production Line อาจต้องการ Fail-safe Behavior ต่างกัน

Network กลับมาแล้ว AMR จะทำงานต่ออัตโนมัติหรือไม่?

ขึ้นอยู่กับ Recovery Logic ของระบบ บางระบบสามารถ Reconnect และ Sync สถานะโดยอัตโนมัติ ขณะที่บางเหตุการณ์อาจต้องมีการตรวจสอบหรือยืนยันจาก Operator

หลัง Connection กลับมา ระบบต้องตอบคำถามหลายอย่าง เช่น

Robot อยู่ที่ไหน?

Mission เดิมเสร็จหรือยัง?

Pallet ถูกส่งแล้วหรือไม่?

Task ถูกบันทึก Complete หรือยัง?

Fleet มี Task ซ้ำหรือไม่?

หาก Recovery Logic ไม่ชัด อาจเกิด Duplicate Task หรือ Status ไม่ตรงกันได้

ดังนั้น Reconnect เป็นเพียงจุดเริ่ม

สิ่งสำคัญคือ Data และ Task State ต้องกลับมาตรงกัน

ทำไม Recovery สำคัญพอ ๆ กับการป้องกัน Network หลุด?

เพราะไม่มี Infrastructure ใดรับประกันได้ว่า Incident จะไม่เกิดขึ้นเลย ระบบที่ดีจึงต้องรู้ว่าจะกลับเข้าสู่ Production อย่างไรเมื่อเหตุการณ์จบลง

มีสองแนวคิดที่ต้องวางพร้อมกัน

Prevent

ลดโอกาส Network Failure

และ

Recover

กลับมาทำงานอย่างถูกต้องเมื่อ Failure เกิด

หาก Network กลับมาใน 1 นาที แต่ต้องใช้คน Reset ระบบอีก 30 นาที

ผลกระทบต่อ Production ก็ยังสูง

จึงควรทดสอบ Recovery Time ด้วย

ควรมี Manual Backup เมื่อระบบ AMR ใช้งานไม่ได้หรือไม่?

ควรพิจารณาตาม Criticality ของ Process โดยเฉพาะ Material Flow ที่ถ้าหยุดแล้ว Production ต้องหยุดตาม

ตัวอย่าง Backup อาจเป็น

Forklift

Hand Pallet

Manual Cart

Manual Task Assignment

Alternate Route

ไม่ได้หมายความว่าต้องเตรียมคนจำนวนเท่ากับระบบเดิมตลอดเวลา

แต่ควรตอบได้ว่า

ถ้า Automation ใช้งานไม่ได้ชั่วคราว โรงงานจะเดินต่ออย่างไร?

Business Continuity ของ AMR ควรวางอย่างไร?

ควรวิเคราะห์จากระยะเวลาที่ Process สามารถหยุดได้ก่อนกระทบ Production แล้วจึงกำหนด Backup และ Recovery ให้สัมพันธ์กับความเสี่ยง

ตัวอย่าง:

Process	ผลกระทบถ้าหยุด	Backup ที่อาจพิจารณา
ส่ง Material เข้า Line	Production ขาดวัตถุดิบ	Manual Transport
Empty Pallet Return	กระทบช้ากว่า	รอ Recovery ได้
Finished Goods Transport	Buffer เต็ม	Forklift Backup
Non-critical Internal Delivery	ผลกระทบต่ำ	รอระบบกลับมา

ไม่จำเป็นต้องให้ทุก Mission มีระดับ Criticality เท่ากัน

การแบ่ง Priority ทำให้วาง Backup ได้เหมาะสมกว่า

Network Redundancy จำเป็นกับ AMR หรือไม่?

ขึ้นอยู่กับความสำคัญของระบบและผลกระทบเมื่อ Network ล้มเหลว โรงงานควรให้ทีม Network และ Automation ประเมินร่วมกัน

ระบบ Critical อาจต้องพิจารณา

• Redundant Network Component

• Backup Link

• High Availability

• Server Redundancy

• UPS

• Network Monitoring

แต่ไม่ควรเพิ่ม Redundancy โดยไม่มีการประเมินความเสี่ยง

เพราะต้นทุน Infrastructure ควรสัมพันธ์กับ Business Impact

จะรู้ได้อย่างไรว่าปัญหาเกิดจาก Wi-Fi หรือ Robot?

ต้องมี Monitoring และ Log ที่สามารถเทียบเหตุการณ์จากหลายระบบในช่วงเวลาเดียวกันได้

หาก AMR หยุดเวลา 14:05

ควรตรวจได้ว่า

Robot Log บอกอะไร

Wi-Fi มี Disconnect หรือไม่

Access Point มี Event หรือไม่

Fleet เห็น Robot Offline หรือไม่

Server มี Error หรือไม่

MES ส่ง Task สำเร็จหรือไม่

วิธีนี้ช่วยหา Root Cause ได้เร็วกว่าเริ่มจาก Restart Robot ทุกครั้ง

ควรทดสอบ Network Failure แบบไหนก่อน Go Live?

ควรทดสอบเหตุการณ์ที่อาจเกิดจริงโดยควบคุมให้ปลอดภัย เพื่อดูทั้ง Robot Behavior และ Recovery Procedure

ตัวอย่าง Scenario ที่ควรเตรียม ได้แก่

Scenario	สิ่งที่ต้องตรวจ
Wi-Fi หลุดกลาง Mission	Robot ทำอะไร
Connection กลับมา	Reconnect ถูกต้องหรือไม่
Fleet Offline	Robot Behavior
MES/WMS Offline	Task Flow
AP มีปัญหา	Roaming / Coverage
Server Restart	Recovery
Robot Offline 1 ตัว	Fleet จัดการอย่างไร
Network หลุดหลาย Robot	Traffic Control
Task ค้าง	Duplicate เกิดหรือไม่

Test Case ควรมี Expected Result ชัดเจนก่อนเริ่มทดสอบ

FAT และ SAT ควรมี Network Failure Test หรือไม่?

สำหรับระบบที่ Network มีผลต่อ Operation ควรกำหนด Failure และ Recovery Scenario ไว้ในแผนทดสอบตาม Requirement ของโครงการ

ไม่ควรตรวจรับเพียง

Robot วิ่ง A → B ได้

แต่ควรดูว่า

เมื่อเกิดเหตุผิดปกติ ระบบตอบสนองอย่างไร

เพราะ Production จริงไม่ได้มีเฉพาะ Normal Condition

การทดสอบนี้ช่วยให้ทีม Operation เข้าใจพฤติกรรมของระบบก่อน Go Live

Operator ควรทำอะไรเมื่อ AMR Offline?

ควรมี SOP ที่ระบุชัดว่าต้องตรวจอะไร ติดต่อใคร และเมื่อใดที่สามารถจัดการเองได้

ตัวอย่าง Flow:

AMR Offline↓ตรวจสถานะ Fleet↓ตรวจว่าเป็น Robot เดียวหรือหลายตัว↓ตรวจ Network / System Alarm↓ใช้ Recovery Procedure↓หากไม่สำเร็จ Escalate ทีม Technical

จุดสำคัญคือไม่ควรให้แต่ละกะใช้วิธีแก้แตกต่างกัน

เพราะอาจสร้างปัญหาเพิ่มขึ้น

Monitoring Dashboard ควรแสดงอะไรเพื่อช่วยรับมือ Network Failure?

อย่างน้อยควรทำให้ทีมดูสถานะ Robot และระบบสำคัญได้ง่าย เพื่อแยก Incident ได้เร็วขึ้น

ข้อมูลที่มีประโยชน์ เช่น

ข้อมูล	ประโยชน์
Robot Online/Offline	เห็นสถานะ Fleet
Last Connection	รู้ว่าหลุดเมื่อไร
Current Mission	เช็ก Task ค้าง
Position	หา Robot
Error Code	ช่วย Troubleshoot
Fleet Status	ตรวจระบบกลาง
Mission Queue	เช็ก Task
System Event	เทียบเหตุการณ์

หากเชื่อมข้อมูลกับระบบ Monitoring อื่นได้ จะช่วยให้ทีม IT และ Automation ทำงานร่วมกันง่ายขึ้น

Network Failure ส่งผลต่อ OEE หรือไม่?

ถ้า AMR เป็นส่วนหนึ่งของ Material Flow ที่เชื่อมกับ Production ปัญหา Network สามารถสร้าง Waiting และ Downtime ทางอ้อม ซึ่งอาจกระทบประสิทธิภาพของกระบวนการผลิตได้

ตัวอย่างเช่น

Machine พร้อมผลิต

แต่ Material ไม่มาถึงเพราะ AMR System หยุด

Machine จึง Wait

แม้เครื่องจักรไม่ได้เสียเองก็ตาม

นี่คือเหตุผลว่าทำไม Infrastructure ที่อยู่รอบ Automation มีผลต่อ Production Performance

สำหรับโรงงานที่กำลังพัฒนา Smart Factory (Internal Link → /smart-factory) จึงควรวาง Robot, Software และ Network เป็น Architecture เดียวกัน

ก่อนซื้อ AMR ควรถาม Vendor เรื่อง Network อะไรบ้าง?

คำถามสำคัญคือให้ Vendor อธิบาย Behavior ของระบบเมื่อเกิด Failure ไม่ใช่ตอบเพียงว่า “รองรับ Wi-Fi”

ตัวอย่างประเด็นที่ควรถาม:

ประเด็น	สิ่งที่ต้องการรู้
Wi-Fi หลุด	Robot Behavior
Fleet หลุด	Mission ทำต่อไหม
Server ล่ม	Backup เป็นอย่างไร
Reconnect	Auto หรือ Manual
Task ค้าง	Recover อย่างไร
Traffic	Offline Robot กระทบ Fleet หรือไม่
Network Requirement	ต้องเตรียม Infrastructure อะไร
Log	ตรวจย้อนหลังได้หรือไม่
Support	Incident ติดต่อใคร

คำตอบเหล่านี้ควรถูกบันทึกเป็น Requirement ของโครงการ

สรุป ถ้า Network หลุด AMR จะหยุดหรือวิ่งต่อ?

คำตอบคือขึ้นอยู่กับ Architecture ของ AMR และ Fleet Management บาง Function อาจทำงานต่อได้จากระบบบนตัว Robot ขณะที่ Task ใหม่, Traffic Coordination หรือ Integration อาจต้องรอ Network กลับมา

จึงไม่ควรถามเพียง

“AMR ใช้งาน Offline ได้ไหม?”

แต่ควรถามแยกเป็น

Navigation ยังทำงานไหม?Mission เดิมทำต่อไหม?รับ Task ใหม่ได้ไหม?Fleet ยังควบคุม Traffic ได้ไหม?MES/WMS ยังส่งงานได้ไหม?Reconnect แล้ว Recover อย่างไร?

และนำคำตอบเหล่านี้ไปทดสอบจริงก่อน Go Live

แนวทางที่ดีคือ

Prevent → Detect → Safe State → Recover → Backup

เพื่อให้ Network Failure ไม่กลายเป็น Incident ที่ทำให้ Material Flow และ Production หยุดโดยไม่มีแผนรองรับ

คำถามที่พบบ่อยเกี่ยวกับ AMR เมื่อ Network หลุด

AMR วิ่งต่อได้หรือไม่ถ้า Wi-Fi หลุด?

ขึ้นอยู่กับ Architecture ของระบบ บาง AMR อาจทำ Mission ปัจจุบันต่อได้ ขณะที่บางระบบอาจเข้าสู่ Safe State ควรตรวจ Specification และทดสอบระบบจริง

AMR Navigation ต้องใช้ Internet หรือไม่?

AMR หลายระบบใช้การประมวลผลบนตัว Robot สำหรับ Navigation แต่ Network ภายในโรงงานอาจยังจำเป็นสำหรับ Fleet, Task, Monitoring และ Integration ส่วน Internet ภายนอกขึ้นอยู่กับ Architecture ของระบบ

ถ้า Fleet Server ล่ม Robot ทุกตัวจะหยุดหรือไม่?

ขึ้นอยู่กับระบบที่เลือกใช้ ไม่ควรสมมติ ควรกำหนด Fleet Failure Scenario และ Expected Behavior ไว้ตั้งแต่ขั้นออกแบบ

Network กลับมาแล้ว AMR จะทำงานต่อเองหรือไม่?

บางระบบสามารถ Reconnect อัตโนมัติ แต่ต้องตรวจด้วยว่า Mission และ Task Status ถูก Sync กลับอย่างถูกต้องหรือไม่

โรงงานควรมีระบบ Manual Backup หรือไม่?

ควรพิจารณาสำหรับ Process ที่ Critical หาก AMR หยุดแล้ว Production ได้รับผลกระทบ เพื่อให้โรงงานสามารถเดินงานต่อระหว่าง Recovery ได้

ต้องการออกแบบ AMR ให้รองรับ Network Failure ในโรงงาน?

การวาง AMR สำหรับ Production ควรออกแบบมากกว่าสถานการณ์ปกติ โดยต้องเข้าใจทั้ง Robot Behavior, Fleet Management, Network Infrastructure, Integration และ Recovery Process เมื่อระบบบางส่วนใช้งานไม่ได้

IDIO TECH ให้บริการด้าน Robotic Automation และ System Integration จึงสามารถพิจารณา Robot, Software และ Network Infrastructure ร่วมกัน เพื่อออกแบบระบบให้สัมพันธ์กับ Process และ Infrastructure ของโรงงาน

ติดต่อทีม IDIO TECH เพื่อประเมิน Architecture และวางระบบ AMR ให้พร้อมทั้ง Normal Operation และ Failure Scenario