ที่มาและขอบเขต Log

ก่อนเริ่มฝึก

วัตถุประสงค์: ตรวจคู่ CSV/JSON และแยกสิ่งที่ผู้จัดทำระบุจากสิ่งที่สังเกตได้ พื้นฐาน: ผ่านการวินิจฉัย Log และเข้าใจยอดสะสมกับ delta เวลาฝึกโดยประมาณ: 45 นาที เป็นเวลาที่ผู้จัดทำเสนอ ยังไม่ได้วัดกับผู้เรียนจริง

ตรวจความเข้าใจ: ตรวจสี่กรณี อธิบายแฮชและขอบเขตหลักฐานที่ยังไม่ยืนยัน ใช้ผลชุดเดิมประกอบการเรียน การคอมไพล์หรือการจำลองที่ผ่านยังไม่ยืนยันบอร์ดหรือการบินจริง

ดูเส้นทางเรียนทั้งหมด · ทบทวนเซนเซอร์และการสื่อสาร

ชุดฝึก: บันทึกที่มาและขอบเขต Log

ใช้เพื่ออะไร: ต่อจาก การวินิจฉัย Log เพื่อเก็บ CSV กับใบกำกับ JSON เป็นคู่ที่ตรวจย้อนหลังได้ ระบุชุดต้นทาง ชื่อรอบ เวลาฝั่งคอมพิวเตอร์ และ SHA-256 ของไบต์เดิม ก่อนคำนวณ delta เฉพาะช่วงที่เห็น ช่วยลดการหยิบไฟล์สลับหรืออ่านยอดสะสมเป็นข้อมูลที่หายใหม่

ผู้เรียนควรอ่าน CSV หกช่องและแยก stale/overflow/dropped ได้แล้ว ใช้ Python 3.11+ บน PC ไม่ต้องติดตั้ง package เพิ่ม ตัวอย่างทั้งสี่เป็น ข้อมูลและเวลาสังเคราะห์ ใช้ analyzer รุ่น 1.15.8 เดิม ไม่มีเฟิร์มแวร์หรือการรับ UART ใหม่ ชื่อรอบที่ผู้จัดทำตั้งยังไม่ใช่ boot ID ที่ยืนยันจากบอร์ด

ไดอะแกรมใบกำกับและขอบเขตการตีความ ในธีมเดียวกับคลังความรู้: แฮชผูกไบต์ แต่ไม่ยืนยันผู้ส่งหรือการบันทึกครบ · เปิดไดอะแกรมใบกำกับขนาดเต็ม

ดาวน์โหลด: ZIP ชุดฝึกที่มาและขอบเขต Log · ใบงานขอบเขต CSV · เฉลยใบกำกับ Markdown · คำตอบใบกำกับ JSON · Manifest และแฮชชุดใบกำกับ

ขั้นตอนผูกใบกำกับกับไฟล์บน PC

1. แตก ZIP ในโฟลเดอร์ใหม่ อ่าน README.md แล้วเปิด synthetic/normal.json คู่กับ normal.csv กรอกใบงานก่อนเปิดเฉลย
2. รัน python validate_capture.py synthetic/normal.json บน Linux ใช้ python3; Windows ที่ใช้ Launcher ใช้ py -3 ได้ อ่านสิ่งที่ใบกำกับระบุแยกจากผลที่ CSV บอก
3. เปลี่ยนเป็น synthetic/historical.json เทียบ counter แรก/สุดท้ายที่เห็น: overflow 7 และ dropped 3 คงเดิม จึงมี delta ของช่วง 0/0 ไม่ใช่เพิ่งหาย 7/3
4. รัน synthetic/wrong-hash.json และ synthetic/reversed-time.json ทีละไฟล์ ต้องคืน exit code 2 ตรวจข้อความและต้นฉบับก่อนแก้ ห้ามเดาเปลี่ยน digest เพื่อให้คู่ไฟล์ที่สลับกันผ่าน
5. เทียบกับ answers.json/answers.md รัน python test_capture.py แล้วลองแก้หนึ่งไบต์ใน สำเนา CSV โดยคงใบกำกับเดิม จะถูกปฏิเสธ เก็บไฟล์ต้นฉบับไว้

อ่านผลและแยก clock domain

กรณี	ผลที่ควรได้	ความหมายเฉพาะที่ตรวจได้
normal.json	PASS; fresh 1/stale 2; delta rejection/unsent 0/0	รูปแบบ/แฮชตรงและแถวที่เห็นสอดคล้องกัน แต่ยังมี stale
historical.json	PASS; fresh 2/stale 0; delta 0/0	ยอดสะสม 7/3 มีอยู่ตั้งแต่แถวแรก ไม่ใช่ loss ใหม่ในคู่ที่เห็น
wrong-hash.json	ปฏิเสธ: CSV SHA-256 mismatch	ใบกำกับไม่ผูกกับไบต์ไฟล์ปัจจุบัน ต้องตรวจว่าไฟล์เปลี่ยนหรือหยิบสลับ
reversed-time.json	ปฏิเสธ: end ก่อน start	เวลาฝั่ง host ที่ผู้จัดทำระบุผิดลำดับ ยังบอกไม่ได้ว่า MCU clock มีปัญหา

ใบกำกับรุ่น 1 รับ source_kit=stm32-data-freshness@1.15.8, origin=synthetic หรือ user-supplied, ป้าย run_label 1–64 ตัวอักษร ASCII/ตัวเลข/_/-, ชื่อ CSV ในโฟลเดอร์เดียวกัน และ SHA-256 lowercase 64 ตัว เวลาต้องเป็น UTC แบบ YYYY-MM-DDTHH:MM:SS[.ffffff]Z จริง โดย end ไม่ก่อน start ค่าเหล่านี้เป็น คำประกาศของผู้จัดทำ ไม่มีการยืนยันที่มาจากบอร์ดหรือผู้ส่ง

declared_host_span_us=1,000,000 ในสองกรณีที่ผ่านเป็นผลต่างเวลาตัวอย่างในใบกำกับ ไม่ใช่ระยะเวลาที่วัดจริง อย่านำไปลบกับ age_us ของ callback เพราะคนละ clock domain ไม่ใช้รับรอง IRQ latency/end-to-end deadline และ host clock อาจถูกปรับได้

ตัวตรวจจำกัด JSON 16,384 ไบต์/CSV 10,000,000 ไบต์ ปฏิเสธ keys ซ้ำ/ช่องเกิน/path นอกโฟลเดอร์ ใช้ byte snapshot เดียวกันทั้งแฮชและ analyzer เดิม ซึ่งยังจำกัด 100,000 observations และสัญญา CSV ของชุดก่อน แฮชรวม BOM/line endings ด้วย การแปลง CRLF/LF อาจทำให้แฮชต่างแม้ข้อความดูเหมือนเดิม

ข้อจำกัดและคำแนะนำเรื่องหลักฐาน

PASS แปลว่าใบกำกับกับไบต์ไฟล์และข้อมูลที่ตรวจสอดคล้องกันเท่านั้น SHA-256 ไม่ใช่ลายเซ็น ถ้ามีคนแก้ทั้ง CSV และใบกำกับก็สร้างคู่ที่ตรงกันได้ ผลจึงคง capture_completeness=not_proven และ boot_identity=operator_label_only_not_verified ไม่มีหลักฐานว่าไม่ขาดแถว ไม่ reboot หรือครอบคลุม counter ตอนจบ capture จริง

เก็บไฟล์เดิมกับรุ่นเครื่องมือ แยกโฟลเดอร์แต่ละรอบ ระบุ clock source/ความละเอียด/วิธี sync ก่อนเทียบเวลา เมื่อมีอุปกรณ์ต้องออกแบบ boot ID, capture sequence และ boundary snapshots ที่ต้นทาง/ตัวบันทึกออกให้จริงก่อนอ้าง capture ครบ ชุดนี้ยังไม่เพิ่มข้อมูลเหล่านั้นในเฟิร์มแวร์ ให้กรณีละ 3 คะแนนสำหรับผลถูก แยก observed/declared ได้ และระบุหลักฐานที่ขาด รวม 12 คะแนนเป็น rubric ฝึก ยังไม่มีผลผู้เรียนจริง

ดูวิธีคำนวณแฮชใน Python hashlib และการแยก aware/naive time ใน Python datetime ข้อจำกัดของผลมาจากสัญญาชุดฝึกนี้ ไม่มีการวัดบอร์ด เซนเซอร์ หรือการบินจริง

เรียนต่อและทบทวน

ทบทวน วินิจฉัย Log ของ STM32 · เรียนต่อ PID, Failsafe และเฟิร์มแวร์ · กลับภาพรวมขั้นสูง

เตรียมเก็บหลักฐานจากบอร์ดจริง

คู่มือเตรียมทดลอง UNO/ESP32/STM32 พร้อมใบงาน ตรวจรุ่น wiring source/core clock และไฟล์ดิบก่อนสรุปผล คู่มือพร้อมใช้ แต่การ upload/วัดจริงยังรออุปกรณ์

ฝึกตรวจคู่ไฟล์และแยกชั้นหลักฐาน

วัตถุประสงค์: ตรวจว่า CSV กับใบกำกับ JSON ผูกไบต์กัน แล้วแยกสิ่งที่คำนวณจากไฟล์ สิ่งที่ผู้จัดทำระบุ และสิ่งที่ยังพิสูจน์ไม่ได้ พื้นฐาน: อ่าน CSV หกช่องและผ่าน Log Diagnostics เวลาเสนอ: 45–60 นาที ยังไม่ได้วัดกับผู้เรียนจริง ใช้กระดาษหรือโปรแกรมอ่าน CSV/JSON ไม่ต้องมีบอร์ดหรือติดตั้งเพิ่ม

คงภาพเสมือนจริงและไดอะแกรมเดิม ใช้ใบกำกับสังเคราะห์สี่กรณีและ CSV สองไฟล์รวม 5 แถวเดิม ไม่มีผลรันตัวตรวจหรือบอร์ดใหม่

ดาวน์โหลด วิธีฝึกตรวจที่มา, ใบงาน 8 ข้อ, ตารางคู่ไฟล์ว่าง, ข้อมูลอ้างอิงเดิมและตัวอย่างแปลงไบต์ และ แบบรายงานสามชั้นว่าง ทำก่อนเปิด เฉลยพร้อมเหตุผล, เฉลยคู่ไฟล์ กับ คำตอบ JSON เดิม ตรวจที่มา/SHA-256 จาก manifest

1. ตรวจคู่ CSV/JSON · Q1–Q3

กรอกตารางสี่คู่ normal/historical/wrong-hash/reversed-time โดยตรวจแฮชกับลำดับเวลาแยกกัน แล้วนับเฉพาะแถวที่เห็นและคำนวณ delta ของ counter ในไฟล์เดียวกัน คำแนะนำ: ยอด 7→7 และ 3→3 ไม่ใช่การเพิ่มใหม่ 7/3 ในช่วงนี้ หากแฮชผิดหรือเวลาย้อนกลับ ให้เก็บต้นฉบับและตรวจประวัติไฟล์ก่อนแก้ ไม่เปลี่ยน digest เพื่อกลบคู่ที่สลับกัน

2. แยกคำประกาศกับสิ่งที่สังเกต · Q4–Q5

อ่าน origin/source_kit/run_label และ UTC จากใบกำกับ ระบุว่าเป็นคำประกาศเกี่ยวกับต้นทาง แม้เห็นข้อความนั้นอยู่ในไฟล์จริง คำนวณ host span พร้อมหน่วย แต่ห้ามนำไปลบกับ age_us ของ callback เพื่ออ้าง latency คำแนะนำ: ป้ายชื่อที่ผู้จัดทำตั้งไม่ยืนยัน boot ID ที่บอร์ดออกให้

3. ไบต์เปลี่ยนและหลักฐานที่ยังขาด · Q6–Q7

อ่านตัวอย่างที่ประกาศการแปลง LF→CRLF บนสำเนาใน source-records: ไบต์ 105→109 ข้อความแต่ละบรรทัดเหมือนเดิม แต่แฮชต่าง เป็นการคำนวณในหน่วยความจำบน PC ไม่แก้ไฟล์ต้นทางและไม่รัน validator ใหม่ จากนั้นอธิบายว่าคู่ไบต์ที่ตรงยังไม่ยืนยันผู้ส่ง capture ครบ หรือ boot จริง และเขียนหลักฐานที่ต้องออกแบบเพิ่มเติมก่อนอ้างสิ่งเหล่านั้น

4. เขียนรายงานสามชั้น · Q8

เลือก normal หรือ historical แล้วกรอกแบบรายงาน: ตรวจจากไฟล์ได้ → ผู้จัดทำระบุ → ยังไม่พิสูจน์/หลักฐานเพิ่ม อ้างไฟล์ ช่อง แถว และขอบหน้าต่างให้ตรวจย้อนกลับได้ คำแนะนำ: source-records มี metadata เพิ่มเพื่ออ่านประกอบ ไม่ใช้แทนไฟล์ต้นทางของตัวตรวจเดิม และไม่รวมคู่ที่ถูกปฏิเสธเพื่อรับรองผล capture

ตรวจตนเอง: ชุดนำทางนี้เสนอข้อละ 2 (คำตอบ 1 + เหตุผล/หน่วย/ขอบ 1) รวม 16 แยกจากเกณฑ์สี่กรณี×3=12 ของชุดเดิม ใช้เลือกทบทวน ไม่ใช่ผลผู้เรียนจริง รอบนี้ตรวจที่มา/ไบต์/ตัวเลขและคำอธิบาย ไม่มีผลรัน validator/analyzer/compile/firmware/SITL/UART หรือทดลองบอร์ดใหม่ เมื่ออธิบายได้ให้ต่อ PID, Failsafe และเฟิร์มแวร์

เลือกชุดฝึกหรือทบทวนต่อ

กลับสารบัญชุดฝึก MCU 10 ชุด เพื่อเลือกโจทย์ตามเป้าหมายและพื้นฐานที่ควรรู้ หรือ ทำแบบประเมินความเข้าใจ 12 ข้อ เพื่อหาหัวข้อที่ควรทบทวน

หลังตรวจเฉลย ให้บันทึกคำตอบที่แก้ เหตุผล และสิ่งที่หลักฐานยังไม่ยืนยัน แล้วเลือกชุดถัดไปที่ช่วยตอบคำถามนั้น คะแนนใบงานกับแบบประเมินเป็นคนละส่วน ใช้เลือกทบทวนด้วยตนเอง