ความสำเร็จของการเชื่อม AGV กับลิฟต์ไม่ได้วัดจากการเรียก API ได้เพียงครั้งเดียว แต่ขึ้นอยู่กับว่าทุกฝ่ายตกลงกันได้หรือไม่ว่าใครเป็นผู้ยืนยันแต่ละสถานะตั้งแต่การจองจนถึงการปล่อยสิทธิ์ และจะย้อนกลับไปที่จุดใดเมื่อเกิดเหตุขัดข้อง บทความนี้ออกแบบการขนส่งข้ามชั้นเป็น distributed transaction เดียว และเชื่อมข้อกำหนดตั้งแต่ RFP, FAT, SAT ไปจนถึงการส่งมอบงานปฏิบัติการ
คำตอบโดยสรุป: จัดซื้อการเดินทางด้วยลิฟต์เป็นธุรกรรม 9 สถานะ
แนวทางที่ใช้ได้จริงคือกำหนด 9 สถานะ ได้แก่ จอง จัดสรร ยืนยันการมาถึง ขึ้นลิฟต์ ยืนยันว่าอยู่ในห้องโดยสาร เดินทางไปชั้นปลายทาง ลงลิฟต์ ยืนยันการออก และปล่อยสิทธิ์ ในทุกสถานะต้องกำหนดเงื่อนไขเริ่มต้น เงื่อนไขสำเร็จ timeout, retry, idempotency key, การยกเลิก หลักฐาน และผู้รับผิดชอบ RFP ที่ระบุเพียงว่า AGV ต้องเรียกลิฟต์ได้ อาจผ่านการสาธิต แต่ไม่สามารถตัดสินการยอมรับเมื่อการสื่อสารขัดข้องหรือระบบเริ่มใหม่
แม้เลือก VDA 5050 3.0 ก็ไม่ได้ทำให้การเชื่อมต่อกับลิฟต์เป็นมาตรฐานโดยอัตโนมัติ ขอบเขตตามเอกสารของ VDA คือ interface สำหรับแลกเปลี่ยนข้อมูลงานและสถานะระหว่าง mobile robot กับ Fleet Control ส่วน API ของลิฟต์ building gateway โหมดเพลิงไหม้ โหมดซ่อมบำรุง door interlock และสิทธิ์ใช้งานของไซต์เป็นขอบเขตการบูรณาการอีกส่วนหนึ่ง การระบุเส้นแบ่งนี้ให้ชัดคือด่านคุณภาพแรกของการสร้างระบบ AGV
เหตุใดการเชื่อม AGV กับลิฟต์จึงยาก
สำหรับ AGV ชั้นเดียว จุดประสานหลักคือเส้นทาง ทางแยก การชาร์จ และจุดรับส่งโหลด แต่การขนส่งข้ามชั้นเพิ่ม AGV, Fleet Control, WMS/MES, elevator gateway, elevator control, ฝ่ายอาคาร และ EHS แต่ละระบบอาจมองภารกิจเดียวกันอยู่คนละสถานะ ระบบหนึ่งอาจเชื่อว่า AGV อยู่ในลิฟต์ ขณะที่อีกระบบยังบันทึกว่ารออยู่หน้าชั้น ความคลาดเคลื่อนนี้ทำให้เกิดการเรียกซ้ำ ประตูถูกกีดขวาง คำสั่งขนส่งซ้ำ รถติดค้าง และการกู้คืนด้วยมือที่ยาวนาน
ลิฟต์อาจไม่ได้ใช้เฉพาะหุ่นยนต์ หากใช้ร่วมกับคน รถเข็น หรือทีมซ่อมบำรุง การรับคำสั่งเรียกไม่ได้เท่ากับอนุญาตให้ AGV ขึ้นอย่างปลอดภัย โหมดเพลิงไหม้และโหมดตรวจสอบต้องมีลำดับเหนือการจัดส่งงานตามปกติ การบูรณาการจึงต้องทำสองสิ่งพร้อมกัน คือไม่เคลื่อนที่เมื่อพิสูจน์สถานะปัจจุบันไม่ได้ และฟื้นการทำงานด้วยขั้นตอนที่ควบคุมได้เมื่อยืนยันความปลอดภัยแล้ว
ISO 3691-4:2023 ครอบคลุมข้อกำหนดด้านความปลอดภัยและวิธีการตรวจสอบสำหรับรถอุตสาหกรรมไร้คนขับและระบบ รวมถึง AGV และ AMR และระบุว่าสภาพของพื้นที่ปฏิบัติงานมีผลอย่างสำคัญต่อความปลอดภัย บทความนี้ไม่ใช่การรับรองความสอดคล้อง โครงการยังต้องประเมินความเสี่ยงจากรถ อาคาร โหลด การใช้งานร่วมกับคน และข้อกำหนดท้องถิ่นจริง พร้อมการยืนยันจากผู้ผลิตที่เกี่ยวข้อง
ขอบเขตที่ VDA 5050 3.0 ทำให้เป็นมาตรฐานและขอบเขตที่ไม่ได้ครอบคลุม
ประกาศ VDA สำหรับ Version 3.0 อธิบายฐานเปิดสำหรับควบคุม mobile robot หลายผู้ผลิตด้วย master control รวมถึงแนวคิด zone สำหรับ free navigation, path sharing, ข้อมูล error ในภาษาท้องถิ่น และ power-saving action ส่วน หน้าเผยแพร่ VDA 5050 ระบุ Version 3.0.0 ว่าเป็น interface แลกเปลี่ยนข้อมูลงานและสถานะระหว่าง mobile robot กับ Fleet Control repository ทางการบน GitHub มี specification และ JSON schema และระบุว่า PDF ที่ VDA เผยแพร่มีผลเหนือกว่าเมื่อเนื้อหาแตกต่างกัน
ดังนั้น VDA 5050 จึงเป็นตัวเลือกสำคัญสำหรับจัดระเบียบขอบเขตด้านรถใน mixed fleet แต่ไม่ใช่โซลูชันลิฟต์ที่เสร็จสมบูรณ์ ผู้ผลิตลิฟต์เผยแพร่ทรัพยากรสำหรับการบูรณาการ เช่น KONE API Portal, Cloud Robot API ของ Schindler และเอกสารการเชื่อมหุ่นยนต์ของ Otis แต่ไม่ได้หมายความว่า authentication, command, event, ความเข้ากันได้ของอาคาร การให้บริการในแต่ละภูมิภาค หรือเงื่อนไขทางการค้าจะเหมือนกัน ควรประเมินการรองรับ VDA 5050 และการรองรับ API ของลิฟต์เป้าหมายเป็นคนละข้อใน RFP
| ขอบเขต | มาตรฐานหรือ specification ที่เป็นไปได้ | สิ่งที่ RFP ต้องกำหนด |
|---|---|---|
| AGV กับ Fleet Control | VDA 5050 3.0, specification ผู้ผลิต | version, ฟังก์ชันบังคับ, extension, ความหมาย error, compatibility test |
| Fleet Control กับ WMS/MES | REST, message bus, interface เดิม | transport ID, priority, cancel, completion, deduplication, resend |
| Fleet Control กับลิฟต์ | API ผู้ผลิต, building gateway | reservation, call, destination, door, occupancy, event, authentication, limit |
| การควบคุมและความปลอดภัยลิฟต์ | แบบผู้ผลิต, ข้อกำหนดความปลอดภัยไซต์ | โหมดเพลิงไหม้และซ่อมบำรุง, manual priority, สิทธิ์กู้คืน, เงื่อนไขห้าม |
| การปฏิบัติงานหน้างาน | SOP, EHS, ขั้นตอนฝ่ายอาคาร | กฎใช้ร่วม, การเข้าถึง, alarm, training, audit, change control |
หากตารางนี้ยังคลุมเครือ ผู้ขาย AGV อาจโทษ API ลิฟต์ที่ไม่รับคำสั่ง ผู้ขายลิฟต์อาจโทษการอัปเดตสถานะจากหุ่นยนต์ และผู้ใช้ต้องรับภาระตัดสินใจฟื้นระบบเพียงฝ่ายเดียว จึงควรทำแผนที่ขอบเขตก่อนทำสัญญาและมอบหมายทั้ง state owner และ evidence owner สำหรับทุก transition
แยกการเชื่อม AGV กับลิฟต์เป็น 9 สถานะ
9 สถานะเป็นคำศัพท์การปฏิบัติงานที่ไม่ผูกกับยี่ห้อ แม้ชื่อ API ต่างกัน ทุกฝ่ายยังเปรียบเทียบได้ว่าธุรกรรมยืนยันถึงจุดใด หลักฐานว่าได้ส่ง command แล้วไม่เพียงพอ ต้องยืนยันว่าระบบเปลี่ยนไปสถานะถัดไปด้วยหลักฐานที่สังเกตได้
| สถานะ | เงื่อนไขเริ่มต้น | เงื่อนไขสำเร็จ | หลักฐานหลัก | การตอบสนองเมื่อไม่สำเร็จ |
|---|---|---|---|---|
| 1. จอง | transport order และชั้นถูกต้อง | ได้ reservation ID ที่ไม่ซ้ำ | API response, event, audit log | query ด้วย key เดิม ห้ามสร้างใหม่โดยไม่ตรวจ |
| 2. จัดสรร | มีลิฟต์ที่เลือกใช้ได้ | ยืนยัน car หรือ service slot | assignment event, car ID | ใช้กฎเลือกใหม่และยกเลิก |
| 3. ยืนยันการมาถึง | AGV และลิฟต์เดินทางมาจุดขึ้น | ยืนยันทั้งตำแหน่ง AGV และลิฟต์ถึงชั้น | vehicle state, floor event | เลือกรอ เรียกใหม่ หรือ hold |
| 4. ขึ้นลิฟต์ | ประตู เส้นทาง และ occupancy อนุญาต | AGV ถึงตำแหน่งในห้องโดยสาร | position, sensor, completion event | ไม่อนุญาตให้ปิดประตู เข้าสถานะปลอดภัย |
| 5. ยืนยันว่าอยู่ในลิฟต์ | การขึ้นเสร็จ | ยืนยัน AGV ID และ in-car state | AGV pose, in-car detection, correlation ID | ห้ามสั่งเดินทางเมื่อข้อมูลขัดกัน |
| 6. เดินทาง | ปลายทางและ in-car state ถูกต้อง | ถึงชั้นปลายทางและเปิดประตูได้ | floor, motion, arrival event | query โหมดและสถานะอุปกรณ์ แล้ว hold |
| 7. ลงลิฟต์ | เส้นทางปลายทางพร้อม | AGV ถึงจุดพักนอกลิฟต์ | vehicle position, zone release | ถือว่ายังอยู่ในลิฟต์ ห้าม release |
| 8. ยืนยันการออก | AGV อยู่ที่จุดพัก | ยืนยันว่าไม่กีดขวางการปิดประตู | safety zone, exit event | ยืนยันใหม่หรือเข้าสู่ manual verification |
| 9. ปล่อยสิทธิ์ | ยืนยันการออกและ cleanup แล้ว | ปลด reservation, occupancy และ mission lock | release response, final audit log | release แบบ idempotent และเฝ้าระวัง stale lock |
ใช้ correlation ร่วมกันตลอด transition เชื่อม WMS/MES transport order ID, AGV mission ID, elevator reservation ID และ equipment event ID ไว้ใน trace เดียว เพื่อให้ย้อนลำดับภายหลังได้ ID ไม่จำเป็นต้องรวมเป็นค่าเดียว แต่ mapping ระหว่างกันต้องอยู่ใน log
การยืนยันว่าอยู่ในห้องโดยสารสำคัญเป็นพิเศษ การจบ boarding command ไม่ได้พิสูจน์ว่า AGV อยู่ในตำแหน่งถูกต้อง ควรรวมตำแหน่ง AGV การตรวจจับฝั่งลิฟต์ และสิทธิ์ของประตู แล้วประกาศว่าข้อมูลใดเป็น authoritative source หากเพิ่ม sensor อย่าใช้สัญญาณ ON ของ sensor เดียวตัดสินความปลอดภัยทั้งหมด ต้องตกลงพฤติกรรมเมื่อ sensor เสียกับผู้ผลิตอุปกรณ์
ระบุ timeout, retry และ idempotency ใน RFP
ใน distributed system การไม่มี response ไม่ได้แปลว่ายังไม่ประมวลผล หากเส้นทางตอบกลับขาดหลังส่ง reservation request อุปกรณ์อาจจองสำเร็จแล้ว การส่ง request ใหม่อาจทำให้ซ้ำ จึงต้องกำหนด idempotency key สำหรับทุกคำสั่งที่เปลี่ยนสถานะ เพื่อให้การส่ง key เดิมคืนผลเดิม หรือทำให้ระบบ converge ด้วยการ query สถานะปัจจุบัน
ไม่ควรกำหนด timeout เดียวให้ทุกการทำงาน แต่ให้ผู้ขายเสนอเหตุผลแยกตามสถานะ เวลา network response, การรอลิฟต์, การเคลื่อนจริงของ AGV และการทำงานของประตูมีลักษณะต่างกัน หลัง timeout บางสถานะอาจเรียกลิฟต์ตัวอื่นได้ แต่บางสถานะต้องห้ามคำสั่งใหม่จนกว่าคนหรืออุปกรณ์ยืนยัน ต้องตัดสินจากเวลาร่วมกับสถานะปลอดภัยล่าสุดและโหมดอุปกรณ์
องค์ประกอบที่ต้องมีใน retry policy
- command ใดส่งซ้ำได้ ทำได้เพียง query หรือจำเป็นต้องตรวจด้วยคน
- ระยะเวลาที่ idempotency key เดิมมีผล ที่เก็บ และวิธีกู้คืนหลัง restart
- backoff และ retry limit ที่ไม่สร้างภาระเกินให้ API อุปกรณ์
- การจัดการ duplicate, delayed และ out-of-order event
- ลำดับความสำคัญและการแจ้งเตือนเมื่อ cancel แข่งกับ completion
- เงื่อนไขหยุดเมื่อเปลี่ยนเป็นโหมดเพลิงไหม้หรือซ่อมบำรุงระหว่าง timeout
- เงื่อนไขและสิทธิ์เปลี่ยนจาก automatic recovery เป็น Manual Hold และกลับคืน
retry ไม่ได้หมายถึงทำซ้ำจนกว่าจะสำเร็จ เมื่อถึง limit ต้องเข้า Manual Hold AGV จะเคลื่อนไปยังจุดรอที่ปลอดภัยได้เฉพาะเมื่อยืนยันตำแหน่งจริง สถานะอุปกรณ์ และเส้นทางที่ปลอดภัยครบแล้ว หากไม่ทราบสถานะหรือยังอาจอยู่ในลิฟต์ ให้หยุดค้างในตำแหน่งเดิม คง Manual Hold และห้ามปล่อย reservation หรือ occupancy ระบบอัตโนมัติที่ดีจะหยุดได้โดยไม่สร้างสถานะเท็จเพิ่ม และกู้คืนได้ด้วยขั้นตอนสั้นที่ตรวจสอบย้อนหลังได้
state machine สำหรับการสื่อสารขัดข้องและการกู้คืนหลัง restart
การสื่อสารอาจเสียที่ wireless ของ AGV, Fleet Control, network อาคาร, cloud API หรือ elevator gateway การเขียนเพียงว่าระบบจะทำต่ออัตโนมัติเมื่อสื่อสารกลับมาไม่ปลอดภัย process ที่ฟื้นต้อง reconcile ตำแหน่งจริงของ AGV สถานะประตู ชั้น และโหมด ธุรกรรมที่บันทึกถาวร และสถานะ transport ใน WMS/MES แทนการเชื่อ memory ก่อนเหตุขัดข้อง
การกู้คืนเริ่มจากระงับ mission ใหม่และแสดง incomplete transaction ทั้งหมด จากนั้น reconcile ตำแหน่งจริงของ AGV กับชั้น ประตู และ operating mode ของลิฟต์ เมื่อยืนยันทั้งสองฝั่งได้แล้วเท่านั้น จึงให้ operator อนุมัติ transition จาก Recovering กลับไปยังสถานะที่ตรวจสอบแล้วเพียงหนึ่งสถานะใน Waiting, Boarding, In Car หรือ Exiting ห้าม Recovering ย้อนกลับไปสถานะก่อนหน้าใดโดยอัตโนมัติ หาก reconcile แล้วยังยืนยันไม่ได้ transition เดียวจาก Recovering คือ Manual Hold ถ้ายังตัดความเป็นไปได้ว่า AGV อยู่ในลิฟต์ไม่ได้ ห้ามปล่อย reservation และคืนลิฟต์สู่บริการปกติ ต้องให้ฝ่ายอาคารตรวจจริงและปลดด้วยสิทธิ์ที่กำหนด
| จุดขัดข้อง | สิ่งที่ query ตอนกู้คืน | เงื่อนไข automatic recovery | ตัวอย่าง Manual Hold |
|---|---|---|---|
| wireless AGV ขาด | position, mission, speed, error | ยืนยัน safe stop และตำแหน่ง สถานะตรงกัน | ไม่ทราบตำแหน่งหรืออาจอยู่ในลิฟต์ |
| Fleet Control restart | persistent transaction, vehicle, reservation | สร้าง correlation ID และสถานะกลับได้ | สถานะอยู่ใน volatile memory เท่านั้น |
| Gateway restart | reservation, car, mode | query สถานะอุปกรณ์ปัจจุบันได้ | ไม่ทราบว่า request เก่าถูกทำหรือไม่ |
| API link ขาด | last event, current state, credential | read query สำเร็จและไม่ขัดกัน | state change อาจสำเร็จฝ่ายเดียว |
| WMS/MES หยุด | order, cancellation, completion receipt | sync พร้อม deduplication ได้ | order อื่นกำลังจัดการโหลดเดียวกัน |
อย่าจบการทดสอบ recovery ที่ fault จำลองใน FAT เท่านั้น ใน SAT ควรทำ planned interruption ระหว่างแต่ละสถานะผ่าน network อาคาร wireless roaming, gateway และ operator terminal จริง แล้วเก็บหลักฐาน การยอมรับหมายถึงไม่มี reservation ซ้ำผิด ไม่มี business completion มากกว่าหนึ่งครั้ง ไม่มี stale lock และ audit trail อธิบายการตัดสินใจกู้คืนได้ ไม่ใช่เพียงระบบกลับมาเคลื่อนที่
ยกโหมดเพลิงไหม้ โหมดซ่อมบำรุง และการใช้ร่วมกับคนเป็นข้อกำหนดระดับสูง
โหมดเพลิงไหม้และซ่อมบำรุงต้องมีลำดับเหนือการขนส่ง AGV ปกติ แต่พฤติกรรมเฉพาะขึ้นกับผู้ผลิตลิฟต์ แบบอาคาร และข้อกำหนดที่ใช้ จึงไม่ควรให้ทีม AGV กำหนดเองทั้งหมด RFP ต้องขอคำอธิบายที่ผู้ผลิตอนุมัติว่า mode information มาจากไหน เมื่อใดจึงปฏิเสธ AGV request ใครตัดสินเมื่อ AGV อาจอยู่ในห้องโดยสาร และกลับมาทำงานอย่างไรหลังคืนสู่ normal mode
สำหรับลิฟต์ใช้ร่วมกับคน นโยบายมีความสำคัญเท่ากับ robot detection ต้องกำหนดช่วงเวลาหรือ car เฉพาะ อนุญาตให้ใช้ร่วมได้หรือไม่ เงื่อนไข occupancy จุดรอ ความขัดแย้งกับผู้โดยสารกดปุ่ม รถเข็นยื่น และคนหยุดใกล้ประตู ใช้ defense in depth โดยไม่สร้างทางเดินที่ชวนให้ชนกัน มีป้ายและ training และระบุผู้ติดต่อเมื่อผิดปกติ แทนการพึ่งคำกล่าวว่า sensor จะหยุดเอง
ขอบเขตออกแบบมาตรการความปลอดภัย AGV
| หัวข้อ | ฝั่ง AGV/Fleet | ฝั่งลิฟต์ | องค์กรผู้ใช้ |
|---|---|---|---|
| เข้าจุดขึ้น | speed, stop position, route occupancy | door, arrival, permission state | พื้น การเข้าถึง กฎใช้ร่วม |
| ขึ้นและลง | positioning, obstacle detection, mission | door motion, equipment interlock | เงื่อนไขโหลด การกำกับ SOP |
| เคลื่อนในลิฟต์ | หยุดที่ตำแหน่ง in-car | destination motion และ mode precedence | นโยบายใช้ร่วม การติดต่อฉุกเฉิน |
| เพลิงไหม้และซ่อมบำรุง | หยุดคำขอ รอปลอดภัย alarm | พฤติกรรม mode ที่ได้รับอนุมัติ | สิทธิ์ ขั้นตอนอพยพและซ่อม training |
| การกู้คืน | query, resync, ป้องกัน duplicate execution | แสดงสถานะและ availability | ตรวจจริง อนุมัติ และบันทึก |
การแบ่ง safety function ไม่จบในเอกสาร API ตามแนวทางของ ISO 3691-4:2023 ที่เน้น operating zone ต้องตรวจระดับพื้น ช่องธรณีประตู ความแม่นยำตำแหน่ง wireless coverage แสง blind spot ทางอพยพ และความมั่นคงของโหลด แล้วนำผล risk assessment เข้าสู่ SAT และขั้นตอนปฏิบัติ
ความรับผิดชอบตั้งแต่การเชื่อม AGV กับ WMS ถึงการควบคุมอุปกรณ์
WMS/MES กำหนดว่าโหลดใดต้องไปจากที่ใดถึงที่ใดและเมื่อใด ส่วน Fleet Control จัดสรรรถและเส้นทาง elevator gateway แปลง service intent เป็น command และ event ของอุปกรณ์เป้าหมาย ขณะที่ elevator control ทำตาม operating and safety logic ที่อนุมัติ หาก WMS/MES ควบคุม car และ door รายละเอียดโดยตรง ระบบจะ coupled สูงและดูแลยากเมื่อเปลี่ยนอุปกรณ์หรือเพิ่ม car
ต้องตกลงจุด business completion การถึงชั้นปลายทาง การยืนยันออก และการส่งมอบที่กระบวนการถัดไปเป็นคนละสถานะ ในระบบขนส่งอัตโนมัติระหว่างกระบวนการ การผ่านลิฟต์ยังไม่ใช่ผลลัพธ์ทางธุรกิจถ้าโหลดไม่ถึงจุดถัดไป จึงแยก equipment transaction กับ business transaction และเก็บ correlation ระหว่างกัน
ใน RACI ควรแยก Command Owner จาก State Evidence Owner Fleet Control อาจส่ง reservation แต่หลักฐาน authoritative อาจอยู่ที่ elevator gateway ความเป็นเจ้าของ safety interlock อยู่ในขอบเขตออกแบบของผู้ผลิตและ AGV layer ไม่สามารถแทนโดยปริยาย FAT evidence ครอบคลุมช่วง integration รวม simulated equipment ส่วน SAT evidence ครอบคลุมอาคารและการปฏิบัติงานจริงทั้งหมด
ข้อกำหนด RFP ที่นำไปปรับใช้ได้ทันที
เขียน RFP เป็นภาษาสัญญาที่ทดสอบได้ ไม่ใช่ wish list ของ feature ระบุ deliverable ข้อยกเว้น วิธีทดสอบ และหลักฐานผ่านพร้อมกับคำว่าต้องรองรับ แล้วปรับรายการต่อไปนี้ตามโครงการ
1. Architecture และ interface
- ส่งรายการ VDA 5050 version ที่รองรับ ฟังก์ชันที่ใช้ ฟังก์ชันที่ไม่รองรับ และ proprietary extension
- กำหนด VDA 5050 เป็นขอบเขต AGV กับ Fleet Control และส่ง elevator API เป็น specification แยก
- ส่ง logical and physical diagram ของ WMS/MES, Fleet Control, AGV, gateway และ elevator control
- ระบุ authentication, certificate renewal, time synchronization, network route, port, naming และ monitoring point
- กำหนด API command, event, state, error, rate limit, compatibility และ deprecation policy
2. Transaction และ exception handling
- ส่ง entry, success, failure, cancellation, timeout, retry และ idempotency ของทั้ง 9 สถานะใน state diagram
- มีวิธีสร้าง duplicate, delay, out-of-order event, lost response และ partial success เพื่อทดสอบ
- สร้าง incomplete transaction จาก persistent data หลัง restart และ reconcile กับ current state
- กำหนดสิทธิ์และ audit ของ automatic recovery, Manual Hold, physical confirmation, release และ resume
- ตรวจพบ แสดง และปลด stale lock ของ reservation, zone และ transport order
3. Safety, equipment mode และ shared operation
- อธิบายพฤติกรรม AGV request ในโหมดเพลิงไหม้ ซ่อมบำรุง ตรวจสอบ manual priority และ out-of-service
- กำหนดเงื่อนไขอนุญาตและห้ามใช้ร่วมกับคน รถเข็น และหุ่นยนต์อื่น รวมจุดรอและจุดพัก
- แสดง safety function, interlock และ boundary ของ AGV กับลิฟต์ที่ผู้ผลิตอนุมัติ
- ส่ง risk assessment, residual risk, training, signage, PPE, emergency contact และ recovery SOP
- รวม reassessment และ regression test เมื่อ software, equipment หรือ layout เปลี่ยน
4. Monitoring, log และ handover
- ติดตาม timeline เดียวจาก WMS/MES ถึง equipment event ด้วย correlation ร่วม
- ตกลง time base, retention, access, privacy และ export format ของ log
- monitor incomplete duration, Manual Hold, retry, stale reservation และ mode change
- ส่ง procedure, troubleshooting matrix, contact, spare, backup, restore และ training material
- ระบุขอบเขต handover ของ source, configuration, license, API contract, certificate และ admin account
หลักฐานที่ต้องรับจาก FAT และ SAT
FAT ตรวจ logic และ integration ตั้งแต่ต้น ส่วน SAT ยืนยันไซต์จริงรวมอาคาร network คน และวิธีทำงาน การผ่าน FAT ไม่ควรยกเว้น SAT แต่การเลื่อนทุกปัญหาไป SAT จะเพิ่ม rework และ downtime ใช้ simulator หรือ hardware-in-the-loop ทดสอบ exception path ส่วนใหญ่ใน FAT แล้วให้ SAT เน้นเงื่อนไขเฉพาะไซต์และ end-to-end
| ID | การทดสอบ | หลักฐาน FAT | หลักฐาน SAT | แนวคิดการยอมรับ |
|---|---|---|---|---|
| T01 | 9 สถานะปกติ | API trace, state sequence, video | video รถ, equipment log, order record | sequence และ correlation ตรงกัน จบครั้งเดียว |
| T02 | response การจองหาย | blocked response, re-query | planned network interruption | ไม่จองซ้ำ converge สู่สถานะเดิม |
| T03 | duplicate และ out-of-order | message injection record | ทำซ้ำใน monitored setup ที่อนุมัติ | state ไม่ถอยและไม่ false completion |
| T04 | link ขาดขณะขึ้น | simulator และ safe-stop record | planned wireless test ที่ปลอดภัย | หยุดปลอดภัยและคง possible in-car state |
| T05 | Fleet restart | database restore, resync log | restart ระบบเทียบเท่าจริง | สร้างงานค้างกลับโดยไม่ duplicate |
| T06 | Gateway restart | equipment query log | test มีผู้ผลิตเข้าร่วม | ระบุได้ว่า request เก่าถูกทำหรือไม่ |
| T07 | fire และ maintenance mode | simulated mode และ rejected demand | procedure ที่ผู้ผลิตอนุมัติ | อยู่เหนือ request ปกติและเข้าสู่ safe state |
| T08 | ใช้ร่วมกับคน | detection, stop, refuge record | rehearsal บนทางจริง | บังคับ prohibit และ wait ตามนิยาม |
| T09 | ออกจากชั้นปลายทางไม่ได้ | obstacle injection, timeout | test load ปลอดภัยและมีผู้สังเกต | ไม่ release และเข้า Manual Hold |
| T10 | WMS/MES resend | ส่ง transport ID เดิม | upper-system integration test | ไม่ขนโหลดเดิมซ้ำ |
| T11 | monitoring และ notification | alarm, timeline, access | operator terminal และ contact drill | operator ระบุสาเหตุและ next action ได้ |
| T12 | สิ่งค้างหลัง recovery | lock list, release audit | shift-handover confirmation | ไม่มี reservation, zone หรือ order ค้าง |
evidence package ควรมี test specification, approved procedure, configuration version, test data, API trace, device log, screen capture, video, defect record, retest result และ signed disposition log อย่างเดียวไม่บอกตำแหน่งจริง ส่วน video อย่างเดียวไม่บอกลำดับ API จึงต้องเชื่อมด้วยเวลาและ correlation ID ร่วม
หลีกเลี่ยงเกณฑ์ว่าใช้งานได้โดยไม่มีปัญหา สำหรับ T02 ควรใช้เกณฑ์ที่สังเกตได้ เช่น ไม่มี reservation ใหม่ด้วย key เดิม ระบบ converge ผ่าน current-state query และไม่มี stale reservation เมื่อจบ ส่วน threshold ด้านเวลาต้องตั้งจาก equipment specification, transport demand, business requirement และ risk assessment ของไซต์ พร้อมบันทึกเหตุผล
อย่าสับสน PoC ก่อนติดตั้งกับ production acceptance
PoC ช่วยลดความไม่แน่นอนของการเข้าถึง API และการเคลื่อนพื้นฐาน แต่ไม่แทน production acceptance การขึ้นลิฟต์สำเร็จหนึ่งครั้งไม่ได้พิสูจน์ concurrent demand, mode transition, restart, wireless loss, shared use หรือ shift handover รายงานจบ PoC ต้องระบุสิ่งที่ยังไม่ทดสอบ ข้อจำกัด การแก้ไขที่ต้องทำ และ production architecture ที่คาดไว้
ตอนเลือกผู้ขายควรให้น้ำหนัก state diagram, API specification, fault-injection method, log, boundary และการประสานผู้ผลิตลิฟต์ มากกว่าวิดีโอที่สวย สำหรับลิฟต์เดิมให้ผู้ผลิตยืนยันว่าอาคาร car, controller และ software เฉพาะนั้นรองรับ integration การมี public API portal ไม่ได้หมายความว่าลิฟต์ติดตั้งทุกตัวใช้ได้ทันที
หากต้องการภาพรวมทั้งระบบ อ่าน แนวทางรวมระบบ AGV ในประเทศไทย สำหรับทางเลือกการรับส่งโหลด อ่าน การบูรณาการ conveyor-top AMR และหากมีการทำงานกลางคืนแบบไร้คน ให้จัดสิทธิ์ recovery และ callout procedure ให้สอดคล้องกับ แนวทางโรงงานทำงานกลางคืนแบบไร้คน
ระบบขนส่งอัตโนมัติระหว่างกระบวนการและการวางแผน BOI ในไทย
เมื่อวางแผนลงทุน automation ในไทย ควรเดิน technical RFP และการตรวจ incentive คู่กันเพื่อลดงานแก้ในขอบเขตอุปกรณ์ สัญญา หลักฐาน และกำหนดเวลา เอกสาร Smart and Sustainable Industry ของ BOI ระบุโดยต้องยืนยันคุณสมบัติเป็นรายกรณีว่า มีเงินลงทุนขั้นต่ำ 1 ล้าน THB โดยไม่รวมที่ดินและเงินทุนหมุนเวียน และยกเว้นอากรนำเข้าเครื่องจักร สำหรับการยกระดับธุรกิจเดิม ระบุการยกเว้นภาษีเงินได้นิติบุคคล 3 ปีโดยมีเพดาน 50% ของเงินลงทุนที่เข้าเกณฑ์ซึ่งไม่รวมที่ดินและเงินทุนหมุนเวียน หากมูลค่ารวมของเครื่องจักร ระบบ automation หรือ robotics ที่ใช้หรือปรับปรุงในโครงการนี้อย่างน้อย 30% เชื่อมโยงกับอุตสาหกรรม automation ในประเทศ ระบุการยกเว้นภาษีเงินได้นิติบุคคล 3 ปีโดยมีเพดาน 100% ของเงินลงทุนที่เข้าเกณฑ์ซึ่งไม่รวมที่ดินและเงินทุนหมุนเวียน
ข้อมูลนี้เป็นเพียงข้อมูลวางแผน ณ วันที่เผยแพร่ ต้องยืนยันประเภทกิจการ การแบ่งโครงการเดิมหรือใหม่ วิธีคำนวณเงินลงทุน เครื่องจักรที่เข้าเกณฑ์ ความเชื่อมโยง automation ในประเทศ เวลายื่น และเงื่อนไขอนุมัติกับ BOI หรือที่ปรึกษาเป็นรายกรณี การได้ incentive กับความปลอดภัยของ AGV elevator integration เป็นคนละเรื่อง ห้ามตัด safety function, log, FAT/SAT หรือ training เพื่อให้พอดีกับขอบเขตภาษี
แยกใบเสนอราคาสำหรับ AGV, Fleet Control, การแก้ WMS/MES, elevator API และ gateway, งานตู้ควบคุม, network, งานพื้นและจุดขึ้น, test, training และ maintenance ตรวจหางานตาม boundary ที่ไม่มีในใบเสนอราคาของผู้ขายใด การ mapping รายการอุปกรณ์ BOI กับฟังก์ชันและ acceptance item ใน RFP จะช่วยติดตามผลกระทบเมื่อเปลี่ยนแปลง
แผนเริ่ม production แบบแบ่งระยะ
หลีกเลี่ยง big-bang cutover เริ่มจาก digital connectivity แล้วขยายไป AGV ไม่มีโหลด test load ช่วงเวลาจำกัด ชั้นจำกัด และกะปกติ ในแต่ละระยะกำหนด stop condition, rollback, approver และ monitoring กลไกสำคัญคือห้ามข้ามระยะเมื่อ exit condition ยังไม่ครบ
exit criteria ของแต่ละระยะ
| ระยะ | การตรวจหลัก | exit condition |
|---|---|---|
| Connectivity | authentication, time sync, state read, test request | audit trail เชื่อมโยงได้และอุปกรณ์ไม่เคลื่อนผิดคาด |
| ทดสอบไม่มีโหลด | 9 สถานะ จุดหยุด การขึ้นลง การสื่อสาร | normal และ key fault case ผ่าน ไม่มี stale lock |
| Test load | รูปโหลด center of gravity การรับส่ง sill | ไม่ชนหรือไม่เสถียร และสังเกตทุกสถานะได้ |
| Limited operation | ใช้ร่วม alarm manual recovery handover | ทีมไซต์ตรวจพบ หยุด และกู้คืนตาม SOP ได้ |
| Normal operation | priority concurrent demand maintenance change control | ติดตาม KPI และ audit ต่อเนื่อง มี owner ของทุก open risk |
monitor distribution และรายละเอียด fault ไม่ใช่เฉพาะค่าเฉลี่ย แยกเวลา reservation wait, car wait, boarding, travel และ exit บันทึกสาเหตุ Manual Hold, retry, cancellation, stale lock และ mode transition บทความนี้ไม่กำหนด target สากล เพราะ topology อาคาร การใช้ร่วม อัตราใช้งาน car และ peak ของงานต่างกัน ให้เก็บ baseline และตั้งเป้าของไซต์จาก business และ safety requirement
change control ต้องครอบคลุม AGV software, Fleet Control, elevator gateway, controller, network, certificate, WMS/MES และ layout ก่อน update ให้เลือกสถานะและ test case ที่ได้รับผล แล้วทำ regression หลัง update การเปลี่ยน VDA 5050 version ต้องตรวจมากกว่า JSON validity โดยยืนยันว่าความหมายของ action, state, extension และ error ที่โครงการใช้ยังเท่าเดิม
ข้อผิดพลาดในการจัดซื้อ 5 ประการที่ควรหลีกเลี่ยง
ข้อผิดพลาด 1: ถือว่าการเรียกสำเร็จเท่ากับ integration สำเร็จ
HTTP response ที่สำเร็จไม่ได้แสดงว่า AGV ออกจากชั้นปลายทางอย่างปลอดภัย ต้องติดตาม 9 สถานะและแยก exit confirmation จาก release
ข้อผิดพลาด 2: คิดว่า VDA 5050 ทำให้อุปกรณ์อาคารเป็นมาตรฐาน
VDA 5050 3.0 เน้น mobile robot กับ Fleet Control จึงต้องตรวจรับ elevator API, equipment mode และ site interlock ด้วย specification แยก
ข้อผิดพลาด 3: สร้าง request ใหม่หลัง timeout
อุปกรณ์อาจประมวลผลแล้วแม้ response หาย ต้อง converge ด้วย idempotency และ state query และใช้ Manual Hold เมื่อผลไม่แน่นอน
ข้อผิดพลาด 4: ลด SAT หลัง FAT ที่มีแต่ normal path
FAT จำลอง wireless, floor, sill, people flow และ fire/maintenance operation จริงได้ไม่ครบ ใช้ FAT สำหรับ fault injection และ SAT สำหรับเงื่อนไขไซต์
ข้อผิดพลาด 5: ฝึกทีม operation ตอนท้าย
recovery authority, alarm, equipment mode และ sharing rule เป็น input ของการออกแบบ ควรให้ facilities, EHS, IT/OT, production, logistics และ maintenance ร่วม review RFP และ test ตั้งแต่ต้น
คำถามที่พบบ่อย
การเชื่อม AGV กับลิฟต์ต้องรวมอะไรบ้าง?
ต้องรวม transport demand จาก WMS/MES การจัดสรรของ Fleet Control, reservation, car, door, destination และ mode ของลิฟต์ ตลอดจนความปลอดภัยและ recovery ของไซต์ ไม่ใช่เพียง API connection การกำหนด 9 สถานะพร้อมความรับผิดชอบและหลักฐานช่วยบริหาร boundary ระหว่างผู้ขาย
VDA 5050 3.0 ทำให้ API ลิฟต์เหมือนกันหรือไม่?
ไม่ VDA 5050 3.0 ครอบคลุมการสื่อสาร mobile robot กับ central Fleet Control ไม่ได้รวม elevator API หรือ building gateway โดยอัตโนมัติ ต้องยืนยันลิฟต์เป้าหมาย authentication, command, event และ equipment mode พร้อม integration test
RFP สำหรับการสร้างระบบ AGV ควรกำหนดอะไรก่อน?
กำหนด business scope และ completion point, 9 สถานะ, system boundary, owner, safe fault state และหลักฐาน FAT/SAT จัดซื้อจาก whole-system architecture ที่รวมอาคาร network และ operation ไม่ใช่เฉพาะ specification ของรถ
การเชื่อม AGV กับ WMS ควรคืน completion เมื่อใด?
เป็นการตัดสินใจทางธุรกิจ การถึงชั้นปลายทาง การยืนยันออก และการส่งมอบกระบวนการถัดไปเป็นคนละสถานะ แยก equipment และ business transaction แล้วตกลง completion point ที่ไม่ทำให้ inventory หรือ dispatch ซ้ำผิดพลาด
มาตรการความปลอดภัย AGV ให้ restart อัตโนมัติหลัง link failure ได้หรือไม่?
พิจารณาได้เฉพาะเมื่อ last-confirmed safe state ตรงกับ physical state หลังฟื้น และไม่มี pending request หรือ equipment mode ขัดแย้ง หากไม่ทราบ in-car presence หรือผลของ old request ให้คง Manual Hold และฟื้นหลังผู้มีสิทธิ์ตรวจจริง
ควรแบ่ง FAT และ SAT ของระบบขนส่งอัตโนมัติระหว่างกระบวนการอย่างไร?
ใช้ FAT จำลอง state machine, duplicate, delay, outage และ restart ด้วย simulator หรืออุปกรณ์ ใช้ SAT ตรวจลิฟต์ wireless พื้น ประตู โหลด people flow, mode และ handover จริง เก็บ correlated log และ site record ทั้งสองระยะ
สิทธิประโยชน์ BOI ไทยครอบคลุม AGV และการแก้ลิฟต์หรือไม่?
ขึ้นกับกิจการ อุปกรณ์ การแบ่งโครงการ และเวลายื่น เอกสาร BOI ปัจจุบันมีเงื่อนไขด้านเงินลงทุน ภาษี และอากร แต่ต้องยืนยันสิทธิ์รายกรณี mapping technical RFP กับ equipment list และปรึกษา BOI หรือผู้เชี่ยวชาญก่อนยื่น
สรุป
การเชื่อม AGV กับลิฟต์ไม่ใช่สาย API เส้นเดียว แต่เป็น distributed transaction ตั้งแต่จอง จัดสรร ยืนยันมาถึง ขึ้น ยืนยันอยู่ในห้องโดยสาร เดินทาง ลง ยืนยันออก และปล่อยสิทธิ์ โดยต้องกำหนด timeout, retry, idempotency, link loss, restart, โหมดเพลิงไหม้และซ่อมบำรุง และการใช้ร่วมกับคน VDA 5050 3.0 เป็นมาตรฐานที่มีคุณค่าสำหรับขอบเขต AGV กับ Fleet Control แต่ขอบเขตลิฟต์ยังต้องออกแบบและตรวจรับเฉพาะโครงการ ระบุความรับผิดชอบและหลักฐานใน RFP ทดสอบ fault ใน FAT และยืนยันอาคารกับ operation จริงใน SAT เพื่อสร้างระบบขนส่งระหว่างกระบวนการที่ทีมงานกู้คืนได้ใน production
