เริ่มจาก requirement ที่วัดได้
แยก requirement, acceptance criterion, procedure และ evidence เช่น “เวลาไม่ต่ำกว่า20นาที ภายใต้ payload และสภาพแวดล้อมที่กำหนด” ต้องระบุวิธีเริ่ม/หยุดจับเวลาและจำนวนครั้งด้วย คำว่าไม่ต่ำกว่ากับไม่เกินให้ทิศทางการทดสอบต่างกัน
ลำดับการตรวจ
เริ่ม software simulation → bench → integration → controlled field test ตามความพร้อมและวิธีทดสอบที่เหมาะสม แต่ละขั้นตอบข้อสงสัยต่างกัน Simulator ไม่ใช่ผลรับรอง environmental/EMC และผล FEM ไม่ใช่หลักฐานชิ้นงานจริง
เลือก log ให้ตรงคำถาม
ArduPilot DataFlash/TLOG และ PX4 ULog ไม่ใช่ไฟล์ชนิดเดียวกัน pyulog ใช้อ่าน ULog; MAVExplorer และ WebTools มีเส้นทางสำหรับ ArduPilot ตรวจหัวข้อและ sample rate ก่อนคาดหวังว่าจะเห็น IMU spectrum หรือ PID analysis ได้ครบ
FilterReview/PIDReview ใช้ช่วยอ่าน response และผลของค่าตั้งแบบ offline ค่าที่ดูดีในเครื่องมือยังต้องตรวจบนระบบเป้าหมาย อย่าอ้างว่า SITL มี vibration เหมือนลำจริง
สถิติและความไม่แน่นอน
ค่าเฉลี่ยบอกตำแหน่งกลางของข้อมูล แต่ไม่บอกความกระจายทั้งหมด รายงานจำนวนครั้ง mean, SD และช่วงความเชื่อมั่นตามคำถาม พร้อมสภาพแวดล้อมและความไม่แน่นอนเครื่องมือวัด
One-sided test เหมาะเมื่อคำถามมีทิศทางที่กำหนดล่วงหน้า ส่วน two-sided test ถามความต่างสองทิศ ไม่เลือกวิธีหลังเห็นผลเพื่อให้ผ่านเกณฑ์
Confidence interval ของค่าเฉลี่ยกับ tolerance interval ตอบคนละเรื่อง ข้อมูลที่สนับสนุนว่าค่าเฉลี่ยเกินเกณฑ์ยังไม่รับรองว่าเที่ยวบินส่วนใหญ่หรือทุกเที่ยวบินผ่าน
แบบบันทึกที่ควรมี
| ช่องข้อมูล | ตัวอย่างสิ่งที่บันทึก |
|---|---|
| Test ID/requirement | ข้อที่ต้องพิสูจน์และทิศเกณฑ์ |
| Environment | payload, battery, ลม, อุณหภูมิ |
| Configuration | firmware, parameters, model/version |
| Raw evidence | log/CSV และหน่วย |
| Analysis | วิธีคำนวณ สมมติฐาน CI และ outlier |
| Conclusion | สิ่งที่สนับสนุนได้และข้อจำกัด |
ตรวจอากาศยานก่อนและหลังงาน
การตรวจความพร้อมเป็นส่วนหนึ่งของหลักฐาน ไม่ใช่เพียงการติ๊กช่องให้ครบ ใช้คู่มือของรุ่นที่ใช้งานกำหนดรายละเอียด จุดยึด ใบพัด แบตเตอรี่ เซนเซอร์ และรายการบำรุงรักษา ถ้าพบความผิดปกติที่ยังประเมินไม่ได้ ให้ระบุสถานะรอตรวจ ไม่เปลี่ยนสถานะเป็นพร้อมใช้งานเพราะเปิดเครื่องติด
| ช่วง | สิ่งที่ตรวจและบันทึก |
|---|---|
| ก่อนงาน | รุ่น/หมายเลขลำ configuration ประวัติ defect ที่ยังไม่ปิด สภาพชิ้นส่วนและการยึด payload |
| ก่อนเริ่มการทดสอบ | เงื่อนไขพื้นที่ คน อากาศ พลังงาน การสื่อสาร และเกณฑ์หยุดตามแผน |
| หลังงาน | ความเสียหายหรือความร้อนผิดปกติ สภาพแบตเตอรี่ ชั่วโมง/รอบใช้งาน log และข้อสังเกต |
| ก่อนกลับมาใช้งาน | วิธีแก้ ผู้รับผิดชอบ ผลตรวจซ้ำ และการยืนยันตามขั้นตอนของอุปกรณ์ |
การตรวจบนโต๊ะควรจัดการพลังงานและส่วนหมุนตามคู่มือ ไม่ใช้การสั่งหมุนใบพัดในพื้นที่ทำงานเป็นวิธีตรวจทั่วไป อายุแบตเตอรี่หรือใบพัดไม่ควรกำหนดเป็นตัวเลขเดียวสำหรับทุกรุ่น
บันทึกข้อบกพร่องให้ตรวจย้อนกลับได้
บันทึกวันที่ อุปกรณ์/รุ่น revision อาการ เงื่อนไขที่พบ หลักฐาน สถานะ และผู้รับผิดชอบ แยก “พบอาการ” ออกจาก “วิเคราะห์สาเหตุ” เช่น การสั่นใน log ยังไม่ยืนยันว่าเกิดจากใบพัดเพียงสาเหตุเดียว หลังแก้ให้ทดสอบเงื่อนไขที่เกี่ยวข้องและอ้างถึงไฟล์ผลใหม่ก่อนปิดรายการ
แบบฝึกบนคอมพิวเตอร์: สร้างรายการ defect สมมติสามรายการ แล้วเชื่อมแต่ละรายการกับ test ID วิธีตรวจซ้ำ และเกณฑ์ปิดรายการ ผู้ตรวจอีกคนควรตามหลักฐานได้โดยไม่ต้องถามผู้สร้างบันทึก
อ่านต่อและแหล่งอ้างอิง
- เอกสารตั้งต้น: DTI, การทดสอบ UAV ต้นแบบขั้นสูง
- ArduPilot WebTools
- SciPy one-sample t-test
- NIST confidence limits
- NIST tolerance intervals
- ดาวน์โหลดแบบบันทึกการทดลอง CSV
เนื้อหานี้เรียบเรียงจากเอกสารที่ DTI เอื้อเฟื้อและแหล่งอ้างอิงข้างต้น ตัวอย่างตัวเลขเป็นกรณีเพื่อการเรียนรู้ อ่านกิตติกรรมประกาศและที่มาของเนื้อหา