ตรวจสภาพและบันทึกการบำรุง
บันทึกตรวจสภาพที่ดีทำให้คนอื่นรู้ว่าตรวจอะไร เมื่อใด ด้วยวิธีใด และพบอะไร การไม่มีรอยเสียหายที่มองเห็นไม่ได้แปลว่าพร้อมบิน ต้องใช้รายการและเกณฑ์ของผู้ผลิตสำหรับรุ่นนั้น
M01 · บทฝึกและกรณีศึกษา
บันทึกตรวจสภาพที่ดีทำให้คนอื่นรู้ว่าตรวจอะไร เมื่อใด ด้วยวิธีใด และพบอะไร การไม่มีรอยเสียหายที่มองเห็นไม่ได้แปลว่าพร้อมบิน ต้องใช้รายการและเกณฑ์ของผู้ผลิตสำหรับรุ่นนั้น
ใบงาน PC พร้อมใช้ ส่วนรายการตรวจทางกายภาพรอรุ่นโดรน คู่มือ OEM และผู้สอนที่รับผิดชอบ
อ่านสูตร ตัวอย่างคำนวณ และแบบฝึกเพิ่มเติม ↓
ก่อนเริ่มเรียน
ใช้คอมพิวเตอร์ Windows หรือ Linux อ่าน CSV ด้วยโปรแกรมตารางหรือ text editor และบันทึกไฟล์งานของตนแยกจากต้นฉบับ ชุด Python พื้นฐานใช้ standard library; โปรแกรม AI และ simulator จริงมีขั้นตอนติดตั้งแยก
เมื่อจบบทนี้
- บันทึกสภาพ หมายเลขชิ้นส่วน และประวัติจากหลักฐาน
- แยกข้อบกพร่องที่ต้องหยุดใช้และส่งต่อผู้รับผิดชอบ
โจทย์และขั้นตอนลงมือทำ
ทะเบียนอุปกรณ์ฝึก D-TRAIN-01 มีบันทึก “ตรวจแล้วปกติ” แต่ไม่มีวันที่ ผู้ตรวจ หรือรุ่นคู่มือ อีกใบระบุความผิดปกติที่จุดยึดโดยไม่มีภาพหรือรหัสชิ้นส่วน
แตก ZIP แล้วเปิด M01-guide.md และ M01-worksheet.csv เก็บสมมติฐานกับผลที่ตรวจได้แยกกัน ช่องว่างในใบงานหมายถึงต้องเก็บข้อมูล ไม่ใช่ผ่านแล้ว
- แยกหมายเลขเครื่อง รุ่นอุปกรณ์ และรุ่นคู่มือออกจากคำบรรยายอาการ
- สร้าง defect ID ให้ข้อพบแต่ละรายการ ระบุ observed/unknown แทนการเดาว่าสาเหตุคืออะไร
- เชื่อมข้อพบกับหัวข้อในคู่มือ หากไม่มีคู่มือให้คงสถานะรอตรวจ
- ส่งต่อรายการที่เกินขอบเขตและระบุผู้รับผิดชอบ ไม่เปลี่ยนเป็นพร้อมใช้งานเอง
ชิ้นงานและเกณฑ์ตรวจ
ส่ง: inspection และ defect log
เกณฑ์สำคัญ: บันทึกรุ่น/ชิ้นส่วน/เวลา/ผู้ตรวจครบ; จุดหยุดตามใบโจทย์และ OEM ต้องไม่ตกหล่น
แนบไฟล์ที่เปิดตรวจได้ วันที่ รุ่นข้อมูล และเหตุผลเมื่อยังสรุปไม่ได้ การทำใบงานสำเร็จไม่แทนผลทดลองกับโมเดล อุปกรณ์ หรือการประเมินทักษะจริง
เปิดแนวคำตอบหลังทำใบงาน
ทั้งสองใบยังไม่พอเป็นหลักฐานปล่อยอุปกรณ์กลับใช้งาน ต้องเติมข้อมูลจากแหล่งจริง ไม่ย้อนหลังสร้างชื่อผู้ตรวจหรือผลตรวจที่ไม่ได้ทำ
แผนกิจกรรมสำหรับผู้สอน
ระดับต้นฝึกบันทึกจากกรณีเอกสาร; ระดับสูงตรวจความสอดคล้องหลายรอบและหารูปแบบข้อผิดพลาดซ้ำ สถานีจริงใช้เฉพาะคู่มือรุ่นที่ผู้จัดยืนยัน
คำถามชวนทบทวน: ภาพนี้เพียงพอให้สรุปว่าสภาพใช้งานได้หรือยัง?
| ชุดการเรียน | อธิบาย | ฝึก | ประเมิน | รวมสถานีอุปกรณ์ |
|---|---|---|---|---|
| ช่างซ่อมบำรุง ระดับพื้นฐาน | 180 นาที | 405 นาที | 135 นาที | 240 นาที |
| ช่างซ่อมบำรุง ระดับต่อยอด | 45 นาที | 105 นาที | 30 นาที | 60 นาที |
เวลาสถานีอุปกรณ์เป็นส่วนหนึ่งของเวลารวมในแผน ไม่บวกซ้ำ ผู้สอนแยกผล PC กับ observed task และให้ผู้เรียนอธิบายงานรายคนก่อนเปิดแนวคำตอบ
ดูการจัดกิจกรรมครบสายและส่วนขยายพื้นฐาน →บรรณานุกรมและขอบเขตการอ้างอิง
ตรวจแหล่งเพิ่มเติม 9 กันยายน 2569 กรณีสมมติ ตัวเลข ใบงาน และเกณฑ์กิจกรรมเรียบเรียงใหม่โดย PK-Research
- ArduPilot — Downloading and Analyzing Data Logs
แนวทางดู log; CSV ในชุดฝึกเป็นข้อมูลสมมติ ไม่ใช่ DataFlash log
- NASA — Requirements Verification Matrix
ใช้เชื่อมข้อกำหนดกับวิธีตรวจ; ใบงานและตัวเลขในบทเป็นการออกแบบของเรา
สูตรและแบบฝึกเพิ่มเติม · ปรับปรุง 2026-09-26
F38: นับเหตุและชั่วโมงพร้อมกันก่อนตีความความพร้อม
| ตัวแปร | ความหมายและหน่วยเข้า → ออก | ช่วง/แหล่งค่า |
|---|---|---|
| N_events | จำนวนเหตุไม่ซ้ำตามนิยาม (เข้า) | จำนวนเต็ม ≥ 0; event log ที่ปิดหน้าต่างแล้ว |
| H_exposure | ชั่วโมงเดินระบบที่สังเกต (เข้า) | > 0; นิยาม fleet/asset และช่วงเดียวกับเหตุ |
| H_up,H_down | ชั่วโมงพร้อม/ไม่พร้อมในหน้าต่างบริการ (เข้า) | ≥ 0; ไม่ซ้อนกัน ครอบคลุมหน้าต่างทั้งหมด และผลรวม > 0 |
| rate,A_obs | observed rate 1/h และ availability ไร้หน่วย (ออก) | rate ≥ 0; A_obs 0–1 คูณ100เป็น% |
ระดับพื้นฐาน · คำถาม: ในช่วงที่เก็บข้อมูล พบเหตุต่อชั่วโมงเท่าใดและพร้อมให้บริการกี่ส่วนของเวลา?
event_rate = N_events/H_exposure
A_observed = H_up/(H_up + H_down)
ก่อนนับกำหนดว่าเหตุคืออะไร เช่น fault ที่ต้องหยุดภารกิจหนึ่งครั้ง หลาย alarm จากเหตุเดียวกันไม่เพิ่มจำนวนโดยอัตโนมัติ ระบุ asset, เวลาเริ่มจบ, การตัดเหตุซ้ำ และช่วง log ขาดหาย แยก operating exposure จากหน้าต่างบริการ; uptime อาจรวมเวลารอที่พร้อมใช้งาน จึงไม่จำเป็นต้องเท่าชั่วโมงเดินระบบ
ตัวอย่าง availability นับ planned maintenance เป็น downtime และถือว่ารู้สถานะครบทุกชั่วโมง หากมี unknown ต้องรายงานช่องว่างก่อน ไม่ยัดเป็น up โดยเงียบ ๆ NIST แยกอัตราการเกิดเหตุของระบบซ่อมได้ออกจาก hazard ของอายุการใช้งาน บทนี้รายงานสัดส่วนที่สังเกตเท่านั้น ไม่ฟิต hazard และไม่เรียกส่วนกลับของ rate ว่า MTBF โดยอัตโนมัติ
ตัวอย่างแทนค่า
บัญชี exposure หนึ่งชุดพบ2เหตุใน100 operating h ให้ rate=2/100=0.02/h หรือ2เหตุ/100 h แยกตัวอย่างหน้าต่างบริการ100 h ที่ up90 h/down10 h ให้ A_obs=90/(90+10)=0.9=90% ตัวเลขสองบัญชีใช้ฝึกนิยาม ไม่อ้างว่าเป็นประวัติบินจริงชุดเดียวกัน
แบบฝึกเปลี่ยนค่า
เปลี่ยนจำนวนเหตุเป็น0 โดยคง exposure100 h และบัญชี availability เดิม แปลผลอย่างไร?
เปิดเฉลย F38
observed rate=0/100=0/h และ A_obs=90% คงเดิม ยอมรับ ±0.000001 ต่อค่า การไม่พบเหตุใน100 h ไม่ได้พิสูจน์ความเสี่ยงประชากรเป็นศูนย์ และไม่ควรรายงาน MTBF เป็นอนันต์
อ้างอิง: NIST/SEMATECH Engineering Statistics Handbook §8.1.2.1 (P3E10); ตรวจ 26 กันยายน 2569
ดาวน์โหลดชุดฝึกสูตรวิศวกรรมและเซนเซอร์ (CSV/JSON พร้อมเฉลย) · ข้อมูลสังเคราะห์สำหรับเปรียบเทียบคำตอบและหน่วย