โปรโตคอลการสื่อสารและสแต็กเครือข่าย

กำไร:

• ความสามารถในการวิเคราะห์โครงสร้างเฟรม/แพ็กเก็ตของโปรโตคอล เช่น I2C/SPI/UART และ TCP/IP, MQTT พร้อมการรองรับ AI
• ความสามารถในการจำกัดข้อผิดพลาดของโปรโตคอลให้แคบลง (การกำหนดเวลา การกำหนดที่อยู่ การตรวจสอบ) ตามสมมติฐานด้วย AI
• ความสามารถในการตรวจสอบการตีความโปรโตคอลของ AI ด้วยการวัดเอกสารมาตรฐาน เครื่องวิเคราะห์ (ลอจิก/แพ็กเก็ต)

โปรโตคอลคือชุดของกฎที่อุปกรณ์ทั้งสองตกลงกันเพื่อทำความเข้าใจซึ่งกันและกัน: พวกเขาจะสื่อสารด้วยความเร็วเท่าใด ลำดับใด และในรูปแบบใด ไม่ว่าเซ็นเซอร์อุณหภูมิจะพูดคุยกับไมโครคอนโทรลเลอร์ผ่าน I2C หรืออุปกรณ์จะพูดคุยกับเซิร์ฟเวอร์คลาวด์ผ่าน TCP/IP และ MQTT จะขึ้นอยู่กับโปรโตคอล ในหน่วยนี้ คุณจะเห็นวิธีใช้ AI เพื่อวิเคราะห์เฟรม/แพ็กเก็ตโปรโตคอล จำกัดข้อผิดพลาดของโปรโตคอลให้แคบลง และทำความเข้าใจสแต็กการสื่อสาร (เลเยอร์ที่ซ้อนทับกัน จากเลเยอร์กายภาพไปจนถึงแอปพลิเคชัน) AI มีประสิทธิภาพในการอธิบายโปรโตคอลและสร้างสมมติฐาน แต่สิ่งที่สายทำได้จริง ๆ เท่านั้นที่ทราบโดยการวัดตัววิเคราะห์ (ตัววิเคราะห์เชิงตรรกะ ตัววิเคราะห์โปรโตคอล/แพ็คเก็ต) และเอกสารมาตรฐานเท่านั้น

โปรโตคอลแบบอนุกรมที่ฝังตัว: I2C, SPI, UART

โดยทั่วไปชิปบนบอร์ดจะสื่อสารกับโปรโตคอลอนุกรมสามโปรโตคอล:

• UART: สองบรรทัด (TX/RX) ไม่มีสายนาฬิกา ต้องตั้งค่าทั้งสองด้านให้มีความเร็วเท่ากัน (อัตราบอด) เรียบง่าย แต่การซิงโครไนซ์ขึ้นอยู่กับความเร็ว
• SPI: นาฬิกา (SCLK), ข้อมูลอินพุต/เอาท์พุต (MOSI/MISO) และเลือก (CS) เส้น; รวดเร็ว ฟูลดูเพล็กซ์ แต่ต้องใช้พินเพิ่มเติม ขั้ว/เฟสของนาฬิกา (CPOL/CPHA) ต้องตรงกันทั้งสองด้าน
• I2C: สองบรรทัด (SDA/SCL) ตามที่อยู่ อุปกรณ์หลายเครื่องในบรรทัดเดียวกัน ตัวต้านทานแบบดึงขึ้นและสภาพกราวด์ทั่วไป ช้าแต่ประหยัด

AI อธิบายได้เป็นอย่างดีว่าโปรโตคอลเหล่านี้ทำงานอย่างไร โครงสร้างเฟรมเวิร์ก และสาเหตุของความล้มเหลวโดยทั่วไป แสดงรายการสาเหตุที่เป็นไปได้อย่างเป็นระบบ (ที่อยู่ไม่ถูกต้อง การดึงขึ้นหายไป ความเร็วไม่ตรงกัน การไม่มีกราวด์ร่วม การช่วงชิงสาย ความยาว/ความจุของสายเคเบิล) เมื่ออุปกรณ์ I2C ไม่ตอบสนอง แต่สิ่งใดที่เป็นของจริงสามารถเข้าใจได้โดยการวัดเส้นด้วยเครื่องวิเคราะห์ลอจิกและดูที่คลื่น SDA/SCL AI ให้สมมติฐาน การวัดผลจะตัดสิน

เคล็ดลับ: ในความล้มเหลวของโปรโตคอลแบบอนุกรม ให้ถาม AI "จัดอันดับสาเหตุที่เป็นไปได้จากแนวโน้มที่เป็นไปได้มากที่สุดไปยังโอกาสน้อยที่สุด และสิ่งที่ฉันเห็นบนเครื่องวิเคราะห์สำหรับแต่ละรายการได้รับการยืนยันแล้ว" วิธีนี้จะทำให้การวัดเป็นไปตามเป้าหมาย แทนที่จะพยายามหาเหตุผลทีละข้อ มุมมองตัววิเคราะห์จะนำคุณไปยังสาขาที่ถูกต้อง

โปรโตคอลเครือข่าย: TCP/IP, UDP, MQTT, CoAP

โปรโตคอลแบบหลายชั้นเข้ามามีบทบาทเมื่ออุปกรณ์เชื่อมต่อกับเครือข่ายและคลาวด์ โดยพื้นฐานแล้วสแต็ก TCP/IP นั้นมีการแบ่งชั้นกันเป็นชั้น: ลิงก์ทางกายภาพ/ข้อมูล (อีเธอร์เน็ต, Wi-Fi), เครือข่าย (IP: การกำหนดที่อยู่และการกำหนดเส้นทาง), การขนส่ง (TCP: เชื่อถือได้, ต่อเนื่อง, ควบคุมการไหล / UDP: รวดเร็ว, ไม่ไว้วางใจ) และแอปพลิเคชัน (HTTP, MQTT, CoAP) แนวคิดหลัก:

• TCP กับ UDP: TCP ชดเชยการสูญเสียและรับประกันคำสั่งซื้อ แต่แนะนำเวลาแฝงและโอเวอร์เฮด UDP รวดเร็ว แต่ไม่มีการรับประกันการส่งมอบ (เสียง/วิดีโอแบบเรียลไทม์เหมาะสำหรับการวัดและส่งข้อมูลทางไกล)
• MQTT: โปรโตคอลการส่งข้อความ IoT น้ำหนักเบาที่ทำงานร่วมกับโมเดลการเผยแพร่และสมัครสมาชิก การส่งข้อความผ่านหัวข้อผ่านนายหน้า ระดับ QoS กำหนดการรับประกันการส่งมอบ
• CoAP: โปรโตคอลน้ำหนักเบาแบบ HTTP ที่ใช้ UDP สำหรับอุปกรณ์ที่ถูกจำกัด

AI วิเคราะห์โครงสร้างเฟรม/แพ็กเก็ตของโปรโตคอลเหล่านี้ ช่วยคุณตีความการจับ Wireshark (ตัววิเคราะห์แพ็กเก็ต) และตรวจสอบการออกแบบหัวข้อ MQTT แต่สิ่งที่การรับส่งข้อมูลจริงได้รับการตรวจสอบโดยการจับแพ็คเก็ต และพฤติกรรมของเซิร์ฟเวอร์ได้รับการตรวจสอบโดยการทดสอบจริง

เช็คซัม, CRC และเฟรม

โปรโตคอลส่วนใหญ่ใช้เช็คซัมหรือ CRC (Cyclic Redundancy Check) เพื่อตรวจสอบว่าข้อมูลไม่เสียหาย ผู้ส่งจะคำนวณค่าการตรวจสอบจากข้อมูล ผู้รับจะคำนวณและเปรียบเทียบแบบเดียวกัน AI อธิบายและเขียนโค้ดสำหรับการคำนวณ CRC/เช็คซัม แต่รายละเอียดต่างๆ เช่น การเลือกพหุนาม ค่าเอนเดียนเนส ค่าเริ่มต้น ฯลฯ จะเป็นรายละเอียดเฉพาะของมาตรฐาน รหัส CRC ที่สร้างโดย AI จะต้องเปรียบเทียบทุกคำกับคำจำกัดความอย่างเป็นทางการของโปรโตคอล และตรวจสอบกับเวกเตอร์ทดสอบที่รู้จัก

มินิเคสสามอัน

กรณีที่ 1 — การดึงขึ้นที่ไม่สมบูรณ์ ทีมไม่สามารถใช้งานเซ็นเซอร์ I2C บนเขียงหั่นขนมได้ ไม่รับทราบที่อยู่อุปกรณ์ (ไม่มี ACK) AI แสดงรายการตัวต้านทานแบบดึงขึ้นและกราวด์ทั่วไปที่หายไปว่าเป็นสาเหตุที่เป็นไปได้มากที่สุด เมื่อดูที่เส้น SDA ด้วยเครื่องวิเคราะห์เชิงตรรกะ จะเห็นว่าสัญญาณไม่สามารถไปถึงระดับสูงได้เต็มที่ การสื่อสารเริ่มต้นเมื่อมีการเพิ่มตัวต้านทานแบบดึงขึ้น บทเรียน: AI เน้นสาเหตุที่เป็นไปได้มากที่สุด โดยผู้วิเคราะห์ยืนยันแล้ว

กรณีที่ 2 — โหมด SPI ผิด วิศวกรอ่านข้อมูลที่ไม่มีความหมายจากอุปกรณ์ SPI AI แนะนำว่าขั้วนาฬิกา/เฟส (CPOL/CPHA) ไม่ตรงกันเป็นสาเหตุที่เป็นไปได้ ในตัววิเคราะห์ นาฬิกาดูเหมือนจะสุ่มตัวอย่างแตกต่างจากขอบที่อุปกรณ์คาดหวัง เมื่อโหมดได้รับการแก้ไข ข้อมูลจะมีความหมาย บทเรียน: อาการ "ข้อมูลแต่ไร้สาระ" ใน SPI มักเกิดจากโหมดไม่ตรงกัน การวัดทำให้สิ่งนี้ชัดเจน

กรณีที่ 3 — ความเข้าใจผิดของ MQTT QoS เด็กฝึกงานส่งข้อมูลระยะไกลผ่าน MQTT แต่เห็นว่าข้อความบางส่วนหายไปจึงถาม AI AI ระบุว่า QoS 0 คือ “ไม่รับประกันการจัดส่งสูงสุดหนึ่งครั้ง”; อธิบายว่าจำเป็นต้องใช้ QoS 1/2 เพื่อรับประกันการส่งมอบ แต่สิ่งนี้ทำให้เกิดโอเวอร์เฮดและความล่าช้า ผู้ฝึกงานจะเปลี่ยนไปใช้ QoS 1 โดยอิงจากวิกฤตทางไกลและตรวจสอบพฤติกรรมของนายหน้าด้วยการทดสอบจริง บทเรียน: อธิบายตัวเลือกโปรโตคอล AI ตัวเลือกที่ถูกต้องนั้นทำตามการใช้งานและตรวจสอบโดยการทดสอบ

เทมเพลตพร้อมท์ที่คัดลอกได้

PROTOCOL FAILURE NAVIGATION TEMPLATE"[การสื่อสาร I2C/SPI/UART/TCP/MQTT] มีอาการต่อไปนี้: [อาการ] จัดอันดับสาเหตุที่เป็นไปได้จาก MOST LIKELY ไป Least ที่เป็นไปได้ สำหรับแต่ละสาเหตุ: (1) เหตุใดจึงทำให้เกิดอาการนี้ (2) สิ่งใดก็ตามที่ฉันเห็นในตัววิเคราะห์/การตรวจวัดได้รับการยืนยันแล้ว (3) สิ่งใดก็ตามที่ฉันเห็นถูกกำจัดออกไป อย่าทำ การวินิจฉัยขั้นสุดท้าย ฉันจำกัดขอบเขตโดยการวัดผล

เทมเพลตการวิเคราะห์กรอบงาน/แพ็กเก็ต "แบ่งเนื้อหา [I2C/SPI/UART byte array / packet capture] ต่อไปนี้ลงในฟิลด์ต่างๆ และอธิบายแต่ละฟิลด์ (ที่อยู่ คำสั่ง ข้อมูล เช็คซัม/CRC แฟล็ก) ระบุสมมติฐานของคุณเกี่ยวกับจุดสิ้นสุดและลำดับบิตอย่างชัดเจน โปรดทราบว่าฉันต้องตรวจสอบความคิดเห็นของคุณด้วยคำอธิบายอย่างเป็นทางการของโปรโตคอลและเวกเตอร์ทดสอบ ข้อมูล: [วาง]"

เทมเพลตการตรวจสอบ CRC/CHECKSUM" อธิบายการคำนวณ CRC/เช็คซัมสำหรับ [โปรโตคอล]: พหุนาม ค่าเริ่มต้น ลำดับบิต สุดท้าย

เทมเพลตการเลือกโปรโตคอล"ดำเนินการเปรียบเทียบโปรโตคอลการขนส่ง/แอปพลิเคชันสำหรับแอปพลิเคชันต่อไปนี้: [ข้อกำหนด: การรับประกันการส่งมอบ เวลาแฝง พลังงาน แบนด์วิดท์ ข้อจำกัดของอุปกรณ์] เปรียบเทียบตัวเลือก TCP/UDP และ MQTT/CoAP/HTTP ด้วยเกณฑ์เหล่านี้ อย่ากำหนดตัวเลือกที่ชัดเจน สร้างสมดุลระหว่างตัวเลือกแต่ละรายการและระบุว่าตัวเลือกควรได้รับการตรวจสอบโดยการทดสอบจริง"

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

ข้อความแจ้งที่อ่อนแอ: "I2C ไม่ทำงาน เพราะเหตุใด"

ข้อความแจ้งที่รัดกุม: "เซ็นเซอร์ I2C ของฉันไม่ ACK (ไม่ระบุที่อยู่) ระบุสาเหตุที่เป็นไปได้โดยเริ่มจากสาเหตุที่เป็นไปได้มากที่สุด: การดึงขึ้น อาการทั่วไป ที่อยู่ผิด ความเร็ว ความจุของสายเคเบิล การโต้แย้ง สำหรับแต่ละสาเหตุ เขียนสิ่งที่ฉันเห็นใน SDA/SCL ในตัววิเคราะห์ลอจิกได้รับการยืนยันแล้ว สิ่งที่ฉันเห็นจะถูกกำจัดออกไป อย่าทำการวินิจฉัย ฉันต้องการรายการที่แคบลงตามการวัด"

การแจ้งเตือนที่อ่อนแอทำให้เกิดการเดาเพียงครั้งเดียว ข้อความแจ้งอันทรงพลังจัดเตรียมแผนผังการวินิจฉัยที่สามารถจำกัดให้แคบลงเหลือเพียงการวัด สั่งซื้อ และตรวจสอบได้

แผนภูมิเปรียบเทียบโปรโตคอล

โปรโตคอล

ประเภท

จุดแข็ง

เครื่องมือตรวจสอบ

ยูอาร์ที

ซีรีส์ไม่มีนาฬิกา

ง่ายๆ สองบรรทัด

เครื่องวิเคราะห์เชิงตรรกะ

เอสพีไอ

อนุกรมโอเวอร์คล็อก

รวดเร็ว ดูเพล็กซ์เต็มรูปแบบ

เครื่องวิเคราะห์เชิงตรรกะ (CPOL/CPHA)

ไอทูซี

อนุกรม, แอดเดรสได้

อุปกรณ์เยอะ พินน้อย

เครื่องวิเคราะห์ (ACK, พูลอัพ)

TCP

เครือข่ายการขนส่ง

เชื่อถือได้ตามลำดับ

เครื่องวิเคราะห์แพ็คเก็ต (Wireshark)

ยูดีพี

เครือข่ายการขนส่ง

รวดเร็ว เวลาแฝงต่ำ

เครื่องวิเคราะห์แพ็คเก็ต

มคต

ใบสมัคร

น้ำหนักเบา ผับ/ย่อย QoS

บันทึกของนายหน้า + การดักจับแพ็กเก็ต

ข้อควรระวัง: การให้ AI ตีความการจับโปรโตคอลนั้นรวดเร็ว แต่ AI อาจถือว่าลำดับบิตหรือขอบเขตฟิลด์ไม่ถูกต้อง ตรวจสอบการวิเคราะห์แต่ละรายการโดยเทียบกับคำอธิบายอย่างเป็นทางการของโปรโตคอลและเวกเตอร์การทดสอบที่รู้จัก

ข้อผิดพลาดทั่วไป

• เปลี่ยนแปลงตามการคาดการณ์ของ AI โดยไม่วัดสาเหตุของข้อผิดพลาด มุมมองเครื่องวิเคราะห์จะนำคุณไปสู่สาเหตุที่ถูกต้อง
• ละเว้นการปฏิบัติตาม CPOL/CPHA ใน SPI "มีข้อมูลแต่เรื่องไร้สาระ" มักเป็นโหมดที่เข้ากันไม่ได้
• ลืมการดึงขึ้นและจุดร่วมทั่วไปใน I2C เป็นสาเหตุที่พบบ่อยที่สุดของการ "ไม่ทำงานเลย"
• สมมติว่าพารามิเตอร์ CRC พหุนาม, เริ่มต้น, ลำดับบิตมีความเฉพาะเจาะจงกับมาตรฐาน; ได้รับการตรวจสอบด้วยเวกเตอร์ทดสอบ
• สร้างความสับสนให้กับ MQTT QoS ด้วยการรับประกันการจัดส่ง QoS 0 ไม่รับประกัน; การคัดเลือกจะทำและทดสอบตามการใช้งาน

โดยสรุป

ในหน่วยนี้ คุณได้ใช้ AI เป็นตัวช่วยที่มีประสิทธิภาพในการอธิบายโปรโตคอล เช่น I2C/SPI/UART และ TCP/IP, MQTT, การวิเคราะห์เฟรม/แพ็คเก็ต และการลดสาเหตุข้อผิดพลาดให้แคบลงอย่างเป็นระบบ แต่โปรโตคอลนั้นแม่นยำและอยู่ในขอบเขตมาตรฐาน: สิ่งที่เส้นทำจริง ๆ จะถูกกำหนดโดยตัววิเคราะห์ลอจิก/แพ็กเก็ต ความแม่นยำของการวิเคราะห์จะถูกกำหนดโดยคำจำกัดความอย่างเป็นทางการและเวกเตอร์ทดสอบ สาเหตุของความผิดปกติจะถูกกำหนดโดยการวัด สั่งให้ AI ให้ “สาเหตุที่เป็นไปได้มากที่สุดและการวัดผลเพื่อยืนยัน”; ให้ผู้วิเคราะห์และมาตรฐานตัดสินใจ

งานสมัคร

เลือกสถานการณ์ความล้มเหลวของโปรโตคอลอนุกรม (เช่น ไม่มี I2C ACK) ขอแผนที่การวินิจฉัยตามลำดับและตรวจสอบการวัดได้จาก AI ด้วยเทมเพลต "การจำกัดข้อบกพร่องของโปรโตคอล" จากนั้นนำอาร์เรย์ไบต์ตัวอย่าง (เช่น เฟรมการอ่านเซ็นเซอร์) และเว้นวรรคด้วยรูปแบบ "การแยกวิเคราะห์เฟรม/แพ็กเก็ต" และจดบันทึกสมมติฐานความเป็นเอนเดียนเนส สุดท้าย ตรวจสอบรหัส CRC กับเวกเตอร์ทดสอบที่รู้จักด้วยเทมเพลต "การตรวจสอบ CRC/การตรวจสอบผลรวมตรวจสอบ"

รายการตรวจสอบ

• [ ] ฉันยืนยันสาเหตุของความล้มเหลวโดยการวัดด้วยเครื่องวิเคราะห์ ไม่ใช่โดยการทำนายของ AI
• [ ] ฉันแสดงรายการ CPOL/CPHA บน SPI ที่อยู่/pull-up/การควบคุมภาคพื้นดินทั่วไปบน I2C
• [ ] ฉันเปรียบเทียบการแยกวิเคราะห์เฟรม/แพ็กเก็ตกับคำจำกัดความโปรโตคอลอย่างเป็นทางการ
• [ ] ฉันตรวจสอบพารามิเตอร์ CRC/เช็คซัมด้วยเวกเตอร์ทดสอบ
• [ ] ฉันเลือกโปรโตคอลการขนส่ง/แอปพลิเคชันตามความต้องการ และทดสอบด้วยการทดสอบจริง
• [ ] ฉันได้ตีความความหมายของการรับประกันการจัดส่งของ MQTT QoS อย่างถูกต้องแล้ว