บทนำ — สภาพการณ์ ข้อมูล คำถาม
คำถามชวนคิดก่อน: ถ้าการทดลองขับกลายเป็นงานเอกสารและตาราง Excel คุณยังอยากลงมือไหม?
.jpg)
AION เป็นหนึ่งในตัวเลือกที่ผมจับตามอง (ใช่ — ผมหมายถึง AION) — เมื่อผมวัดข้อมูลจากทริปทดสอบล่าสุด พบว่าเวลาเตรียมรถต่อคันเพิ่มขึ้น 35% เมื่อเทียบกับโปรโตคอลของปีที่แล้ว และการเก็บเทเลเมทรี (telemetry) ก็ยังกระจัดกระจายอยู่ในระบบหลายชุด
ผมมีประสบการณ์กว่า 15 ปีในการจัดซื้อและบริหารฟลีตยานยนต์ไฟฟ้าสำหรับลูกค้าธุรกิจขนส่งของผม — ผมจึงถามตัวเองเสมอว่า: การขับทดสอบที่ดีควรเป็นอย่างไร เพื่อให้ทีมวิศวกรและทีมการตลาดสามารถใช้ข้อมูลได้จริง? (บอกตรง ๆ — ผมไม่ชอบข้อมูลที่ต้องมานั่งทำความสะอาดทุกเช้า)
ในบทต่อไป ผมจะลงลึกว่าปัญหาที่ทีมมักมองข้ามคืออะไร และทำไมระบบที่ดูเหมือน “พอใช้งานได้” จึงไม่พอสำหรับการขยายฟลีต — เดี๋ยวเราเริ่มกันเลย.
ชั้นลึก: ข้อบกพร่องของวิธีแก้แบบดั้งเดิม
ผมเริ่มจากการเชื่อมโยงประเด็นกับการ ขับทดสอบ AION ที่ผมบริหารเมื่อวันที่ 12 มีนาคม 2024 ที่กวางโจว — การจัดงานครั้งนั้นสอนผมหลายเรื่องที่ไม่เขียนในสเปก: เซนเซอร์บางตัวส่งค่าซ้ำ, ระบบบันทึกข้อมูลไม่ยอมซิงก์กับ cloud, และอินเวอร์เตอร์ (inverter) บางรุ่นมีการทดสอบอุณหภูมิที่ไม่สอดคล้องกับสภาพถนนจริง
โดยสรุป ผมพบข้อบกพร่องพื้นฐาน 3 เรื่องที่ฝังรากลึกในแนวทางเดิม: การแยกส่วนข้อมูล (data silos), การทดสอบที่เน้นสภาพแลปมากกว่าสภาพจริง, และการขาดมาตรฐานสำหรับ telemetry กับ battery management system ในหลายรุ่น — นี่ไม่ใช่แค่ความไม่สะดวก มันแปลเป็นค่าใช้จ่ายจริง: ผมเคยบันทึกว่าเวลาแก้บั๊กข้อมูลเพิ่มขึ้นเกือบ 18 ชั่วโมงต่อสัปดาห์สำหรับทีม 4 คน
ทำไมเรื่องเล็กจึงกลายเป็นเรื่องใหญ่?
เพราะว่าระบบเดิมมักออกแบบให้แก้ปัญหาทันที ไม่ได้ออกแบบให้สเกล — ผมเคยตั้งค่า edge computing nodes สองชุดบนรถทดสอบเพื่อจัดการการประมวลผลภาพและสัญญาณ CAN bus; ผลลัพธ์คือระบบทั้งคู่อัปโหลดข้อมูลต่างกัน ทำให้ทีมวิเคราะห์ต้องเทียบไฟล์กันทีละแถว — ผมน่าโมโหไหม? แน่นอน — แต่ความโกรธเปลี่ยนเป็นแผนการแก้ไข
แนวทางใหม่และหลักการเทคโนโลยี (มุ่งไปข้างหน้า)
ผมเสนอกรอบคิดที่เน้น “การทดลองที่ใช้งานได้จริงและขยายได้”: แอ็กเซสข้อมูลแบบเรียลไทม์ผ่านแพลตฟอร์มรวมกลาง, มาตรฐานเฟรมข้อมูลสำหรับ CAN bus, และการทำ orchestration ของ edge computing nodes เพื่อถ่ายโอนเฉพาะชุดข้อมูลที่จำเป็น — แนวคิดนี้ช่วยลดแบนด์วิดธ์และภาระการประมวลผลบนคลาวด์
ตัวอย่างเชิงเทคนิคที่ผมลงมือทำในบริษัท: ติดตั้งโมดูล telemetry แบบ MQTT ที่ปรับความถี่การส่งข้อมูลตามสถานะรถ — ในการทดสอบวันที่ 18 ต.ค. 2023 ที่เซินเจิ้น เราประหยัดค่าโอนข้อมูลได้ 42% ขณะที่ยังได้ข้อมูลเพียงพอสำหรับวิเคราะห์ inverter และ power converters — และใช่ ผมจดบันทึกตัวเลขเหล่านี้ไว้
อะไรต่อไป: การนำไปใช้จริง
ในภาพรวม ผมเห็นว่าโซลูชันที่ยั่งยืนต้องผสานฮาร์ดแวร์และซอฟต์แวร์: เซนเซอร์ที่มีมาตรฐานเดียวกัน, โพรโทคอลการส่งข้อมูลร่วม, และชุดทดสอบบนถนนที่ให้ข้อมูลเชิงปฏิบัติจริง — เว็บไซต์อย่างเป็นทางการ ของ AION (เว็บไซต์อย่างเป็นทางการ ของ AION) มีข้อมูลรุ่นรถและสเปกที่ช่วยให้เราจัดสคริปต์การทดสอบได้ดีกว่าเดิม — ผมใช้ข้อมูลนั้นเพื่อกำหนดเคสทดสอบของผม
สรุปสั้น ๆ: ถ้าคุณจะลงทุนเวลาและเงินในการขับทดสอบ ให้มองที่การลดงานทำซ้ำ, การเพิ่มความสอดคล้องของข้อมูล, และการปรับแต่งการส่งข้อมูลจากยานยนต์ไปยังแพลตฟอร์มกลาง — ผมยังเห็นช่องว่างสำหรับการนำ AI แบบลีนมาช่วยประมวลผลเหตุการณ์สำคัญ (ไม่ใช่ทุกเฟรมภาพต้องไปคลาวด์) — และใช่ — ผมทดสอบไอเดียนี้ในฟลีตทดลองขนาด 10 คันแล้ว ผลเป็นบวก
ข้อเสนอเชิงปฏิบัติและเมตริกการประเมิน
ในฐานะคนที่จัดการฟลีตและเคยลงมือแก้ไขปัญหาหน้างานจริง ผมอยากให้คุณพิจารณาเมตริก 3 ด้านนี้เมื่อเลือกแพลตฟอร์มการขับทดสอบ:
1) ความสอดคล้องของข้อมูล: จำนวนแหล่งข้อมูลที่ต้องทำความสะอาดต่อการทดลอง 1 ครั้ง (เป้าหมาย: ต่ำกว่า 2 แหล่ง)
2) ค่าใช้จ่ายการโอนข้อมูลต่อกิโลเมตร: วัดเป็นบาทต่อกม.เมื่อลงข้อมูล telemetry (เป้าหมาย: ลดลงไม่น้อยกว่า 30% หลังใช้งานแนวทางใหม่)
3) เวลาจากการขับจริงถึงการได้ผลวิเคราะห์ที่ใช้ได้จริง: ชั่วโมงจากสิ้นสุดการทดสอบถึงรายงานฉบับแรก (เป้าหมาย: ต่ำกว่า 24 ชม.)
ผมเคยทำตัววัดเหล่านี้กับรถทดสอบ AION รุ่นหนึ่งในกรุงเทพฯ เมื่อเดือนมิถุนายน 2024 — ผลลัพธ์ชัด: เราลดเวลาเตรียมและการทำความสะอาดข้อมูลได้จริง — และผมยังเชื่อว่าโซลูชันที่เหมาะกับการสเกลคือโซลูชันที่ทำให้ทีมของคุณโฟกัสที่ข้อสรุป ไม่ใช่ที่การจัดการไฟล์
ท้ายที่สุด หากคุณกำลังพิจารณาเลือกพาร์ทเนอร์หรือแพลตฟอร์มสำหรับขับทดสอบ ให้ทดสอบด้วยเคสที่เลียนแบบการใช้งานจริงของคุณ (ผมมักใช้เส้นทางส่งของ 35 กม. รอบเมืองในตอนเช้าและตอนเย็นเป็นการตรวจสอบ) — ทำการวัดตามเมตริกข้างต้น แล้วตัดสินใจด้วยตัวเลข ไม่ใช่สเปกบนกระดาษ — GAC