บทความเทคนิคต้นฉบับ FCTEL · ทีมเทคนิค FCTEL
เผยแพร่ครั้งแรก: 2026-10-07 · แก้ไขล่าสุด: 2026-10-07
สวิตช์อุตสาหกรรมอาจแสดงว่าลิงก์ทำงานอยู่ ขณะที่ PLC หมดเวลารอเป็นระยะ แต่นั่นยังไม่ยืนยันในทันทีว่าเป็นปัญหาด้านประสิทธิภาพ สายสัญญาณ การเข้าหัวสาย หรือวงจรรับส่งสัญญาณอาจทำให้บิตที่รับมาเปลี่ยนไป ขณะที่ความแออัดอาจทำให้เฟรมที่สมบูรณ์ถูกทิ้งได้ CRC คือวิธีการคำนวณ ส่วน FCS คือฟิลด์ Ethernet ที่ใช้บรรจุผลการคำนวณนั้น การเข้าใจตำแหน่งของทั้งสองในเส้นทางการรับทำให้ตีความตัวนับข้อผิดพลาดได้อย่างมีความหมาย และป้องกันไม่ให้ทุกเหตุการณ์ถูกสรุปรวมด้วยคำอธิบายกว้าง ๆ แบบเดียวกันว่าแพ็กเก็ตสูญหาย บทความนี้อธิบายกลไกทั่วไป ข้อมูลประกอบตัวอย่างไม่ใช่ข้อมูลทดสอบของ FCTEL
เปิดภาพต้นฉบับเพื่อดูรายละเอียด เลื่อนในแนวนอนเพื่ออ่านข้อความกำกับแผนภาพในขนาดเต็ม
เหตุใดเฟรม Ethernet จึงมี FCS อยู่ที่ท้ายเฟรม
MAC ฝั่งส่งประกอบที่อยู่ปลายทาง ที่อยู่ต้นทาง ชนิดหรือความยาว ข้อมูล และข้อมูลเติมเต็มที่จำเป็น จากนั้นจึงต่อท้ายด้วย FCS ขนาดสี่ไบต์ หากมีแท็ก 802.1Q แท็กนั้นจะรวมอยู่ในเนื้อหาเฟรมที่ได้รับการป้องกันด้วย พรีแอมเบิลและตัวคั่นเริ่มต้นเฟรมช่วยในการซิงโครไนซ์ แต่อยู่นอกขอบเขตการป้องกันของ CRC นี้ ช่องว่างระหว่างเฟรมก็ไม่ใช่ข้อมูลที่ได้รับการป้องกันเช่นกัน การวาด FCS ไว้ท้ายเฟรมทำให้เห็นข้อจำกัดสำคัญด้านเวลาอย่างชัดเจน กล่าวคือ ฝั่งรับต้องได้รับฟิลด์ตรวจสอบก่อนจึงจะตรวจสอบเฟรมนี้เสร็จสมบูรณ์ได้
สายทองแดงนำส่งสัญญาณไฟฟ้า ส่วนใยแก้วนำแสงนำส่งสัญญาณแสง PHY กู้คืนบิตจากสัญญาณเหล่านั้น การลดทอน การสะท้อน สัญญาณรบกวนข้ามสาย หรือความขัดข้องของวงจรรับส่งสัญญาณ อาจทำให้บิตศูนย์ที่ส่งมาถูกตีความเป็นหนึ่ง สถานะ Link UP ยืนยันว่ามีการเชื่อมต่อทางกายภาพแล้ว แต่ไม่ได้รับรองทุกเฟรม MAC ฝั่งรับจะคำนวณใหม่และตรวจสอบความสัมพันธ์ด้านความสมบูรณ์ของข้อมูล หากตรวจสอบไม่ผ่าน เฟรมนั้นจะไม่เหมาะสำหรับการส่งมอบข้อมูลอย่างเชื่อถือได้
แยก FCS ออกจากการตรวจสอบในชั้นที่สูงกว่า กลไกนี้ป้องกันเฟรม Ethernet ปัจจุบัน และไม่สามารถทดแทน TCP, UDP หรือกลไกความสมบูรณ์ของข้อมูลระดับแอปพลิเคชันได้ เมื่อสวิตช์เปลี่ยนเนื้อหาที่ได้รับการป้องกัน เช่น แท็ก VLAN ค่า FCS ขาออกต้องสอดคล้องกับเนื้อหาขาออก ดังนั้น การตรวจสอบผ่านที่พอร์ตรับหนึ่งพอร์ตจึงไม่ได้รับรองเส้นทางข้อมูลแอปพลิเคชันทั้งหมด หรือพิสูจน์ว่าผู้ส่งสร้างข้อมูลที่ถูกต้องมาตั้งแต่ต้น
CRC ใช้การเลื่อนบิตและ XOR ไม่ใช่การบวกทั่วไป
แบบจำลองที่ช่วยให้เข้าใจได้คือการมองลำดับบิตเป็นพหุนามฐานสอง และใช้เลขคณิตโมดูโล -2 ร่วมกับพหุนามกำเนิดที่กำหนด การบวกและการลบจะกลายเป็น XOR โดยไม่มีการทดแบบเลขคณิตทั่วไป ฮาร์ดแวร์มักทำงานนี้ด้วยรีจิสเตอร์เลื่อนและเครือข่าย XOR แบบป้อนกลับ โดยอัปเดตสถานะระหว่างที่บิตเข้ามา แทนที่จะให้ซอฟต์แวร์ประมวลผลทุกไบต์ Ethernet ใช้ CRC ขนาด 32 บิต ฝั่งส่งและฝั่งรับต้องใช้พหุนาม สถานะเริ่มต้น ลำดับบิต และกฎการประมวลผลขั้นสุดท้ายที่ตรงกัน การนำไปใช้งานใด ๆ ที่ใช้ชื่อ CRC32 จึงไม่ได้หมายความว่าจะเข้ากันได้โดยอัตโนมัติ
เพื่อการสอน การแสดงให้ฝั่งส่งสร้าง FCS และให้ฝั่งรับคำนวณผลใหม่จากเนื้อหาที่ได้รับแล้วนำมาเปรียบเทียบกันนั้นเข้าใจได้ง่าย แต่วงจรจริงอาจประมวลผลเฟรมรวมถึง FCS ของเฟรม แล้วตรวจสอบว่าค่าเศษที่ได้ตรงกับค่าคงที่ที่กำหนดหรือไม่ ทั้งสองวิธีตรวจสอบความสัมพันธ์เดียวกัน CRC ตรวจจับข้อผิดพลาดของบิตได้หลายประเภท แต่ไม่ได้ระบุว่าบิตใดต้องแก้ไข หรือรับประกันว่าจะตรวจพบรูปแบบข้อผิดพลาดที่เป็นไปได้ทุกแบบ กลไกนี้ไม่มีกุญแจลับ และไม่สามารถทดแทนการเข้ารหัส การยืนยันตัวตน หรือลายเซ็นที่ทนต่อการปลอมแปลงได้
เปิดภาพต้นฉบับเพื่อดูรายละเอียด เลื่อนในแนวนอนเพื่ออ่านข้อความกำกับแผนภาพในขนาดเต็ม
เหตุใดการจับแพ็กเก็ตทั่วไปจึงอาจไม่แสดงเฟรมที่เสียหายเลย
เส้นทางการรับทั่วไปผ่านอินเทอร์เฟซ PHY การตรวจสอบความสมบูรณ์ของข้อมูลโดย MAC บัฟเฟอร์สวิตชิงหรือบัฟเฟอร์รับ และการประมวลผลในชั้นที่สูงกว่า เมื่อ MAC หรือ NIC ปฏิเสธเฟรมที่เสียหายก่อนส่งต่อให้ไดรเวอร์ โปรแกรมจับแพ็กเก็ตทั่วไปจะเห็นเฉพาะข้อมูลที่ผ่านขั้นตอนเหล่านี้มาได้ ดังนั้น การไม่พบข้อผิดพลาด CRC ในข้อมูลที่จับได้จึงไม่ได้ยืนยันว่าลิงก์ไฟฟ้าปราศจากปัญหา NIC จำนวนมากยังนำ FCS ออกด้วย ทำให้ความยาวที่จับได้กับเฟรมบนสายจริงไม่เหมือนกัน ควรเก็บตัวนับขาเข้าของสวิตช์ สถิติ NIC ของอุปกรณ์ปลายทาง และบันทึกการจับแพ็กเก็ตไว้ร่วมกัน
การทำงานแบบ Store-and-forward รับเฟรมให้ครบก่อนตรวจสอบและตัดสินใจส่งต่อ โดยปกติ หากตรวจสอบไม่ผ่าน เฟรมจะถูกปฏิเสธที่ขาเข้า การทำงานแบบ Cut-through อาจเริ่มส่งส่วนหัวก่อนที่ส่วนท้ายจะมาถึง จึงทำให้ข้อมูลที่เสียหายถูกส่งไปยังลิงก์ถัดไปได้ วิธีจัดการและพฤติกรรมของตัวนับขึ้นอยู่กับชิปเซ็ตและเฟิร์มแวร์ อย่าอนุมานโหมดการส่งต่อจากคำว่าสวิตช์อุตสาหกรรมเพียงอย่างเดียว หรือถือว่าข้อผิดพลาดบนอุปกรณ์หลายตัวพิสูจน์ว่ามีความขัดข้องหลายจุดที่เป็นอิสระต่อกัน ให้ยืนยันพฤติกรรมการส่งต่อและความหมายของตัวนับสำหรับรุ่น FCTEL ที่ใช้งานจริง
เปิดภาพต้นฉบับเพื่อดูรายละเอียด เลื่อนในแนวนอนเพื่ออ่านข้อความกำกับแผนภาพในขนาดเต็ม
ตัวนับฝั่งรับชี้ไปยังช่วงลิงก์ ไม่ได้ระบุว่าอุปกรณ์ใดเป็นต้นเหตุ
หาก PLC A ส่งข้อมูลไปยังสวิตช์ B และตัวนับ CRC ขาเข้าของ B เพิ่มขึ้นอย่างต่อเนื่อง ให้ตรวจสอบช่วง A ถึง B ก่อน ได้แก่ ภาคส่งของ A สายแพตช์ จุดต่อสาย และวงจรรับของ B สิ่งที่ B รายงานคือการตรวจสอบความสมบูรณ์ของข้อมูลไม่ผ่าน ตัวนับนั้นเพียงอย่างเดียวไม่สามารถระบุว่า A เป็นต้นเหตุได้ การรับส่งข้อมูลในทิศทางย้อนกลับผ่านเส้นทางรับอีกเส้นหนึ่ง และอาจมีพฤติกรรมต่างกัน การเชื่อมต่อใยแก้วนำแสงแบบดูเพล็กซ์ก็ต้องตรวจสอบแยกกันเช่นกัน ระหว่าง TX ฝั่งท้องถิ่นไปยัง RX ฝั่งระยะไกล และ TX ฝั่งระยะไกลไปยัง RX ฝั่งท้องถิ่น
ใช้ค่าที่เพิ่มขึ้นในช่วงสังเกตการณ์เดียวกัน แทนยอดสะสมตลอดอายุการทำงาน บันทึกค่าฐาน รอตามช่วงเวลาคงที่ แล้วเปรียบเทียบค่าที่เพิ่มขึ้นของ CRC จำนวนเฟรมที่รับเพิ่มขึ้น และการหมดเวลารอของแอปพลิเคชัน ตัวอย่างเพื่อการสอนที่มีเฟรมผิดพลาดใหม่สิบเฟรมไม่ใช่ข้อกำหนดผลิตภัณฑ์ ข้อผิดพลาดขาเข้าอาจรวมถึง CRC ความยาว และสาเหตุอื่น ๆ ส่วนการทิ้งเฟรมอาจเกิดจากการตัดสินใจตามนโยบายหรือทรัพยากร ตัวนับต่าง ๆ ไม่จำเป็นต้องเป็นอิสระต่อกัน ดังนั้น การนำมาบวกรวมโดยไม่พิจารณาจึงไม่ให้ค่าอัตราการสูญเสียโดยรวมที่ถูกต้อง
หลังรีเซ็ตตัวนับ ให้เก็บบันทึกเวลาและการดำเนินการไว้ เพื่อให้ค่าที่เพิ่มขึ้นจากพอร์ตต่าง ๆ อ้างอิงช่วงสังเกตการณ์เดียวกัน
ทดสอบข้อมูลเสียหายและความแออัดเป็นสมมติฐานแยกกัน
เฟรมที่สมบูรณ์ก็ยังอาจถูกทิ้งได้ เมื่อข้อมูลจากหลายขาเข้ามารวมกันที่ขาออกที่ช้ากว่า และคิวไม่มีพื้นที่เหลือ โดยไม่จำเป็นต้องมีข้อผิดพลาดของบิต ตัวนับการทิ้งที่ขาออกหรือตัวนับที่เกี่ยวกับบัฟเฟอร์อาจเพิ่มขึ้น ขณะที่ CRC ไม่เปลี่ยนแปลง ในทางกลับกัน หาก CRC เพิ่มขึ้นขณะโหลดต่ำ ก็ยิ่งสนับสนุนให้ตรวจสอบสาย จุดสัมผัส อินเทอร์เฟซ และสัญญาณรบกวน ค่า CRC เป็นศูนย์ไม่ได้พิสูจน์ว่าเครือข่ายทั้งหมดทำงานเป็นปกติ เพราะข้อผิดพลาดอาจเกิดที่พอร์ตอื่น หรืออุปกรณ์อาจไม่แสดงสถิติที่เกี่ยวข้อง
เริ่มจากสายแพตช์ที่ทราบว่าใช้งานได้ดี เปลี่ยนส่วนประกอบครั้งละหนึ่งชิ้นเท่านั้น และรักษาปริมาณการรับส่งข้อมูลกับระยะเวลาสังเกตการณ์ให้เปรียบเทียบกันได้อย่างเหมาะสม สำหรับสายทองแดง ให้ตรวจสอบการเข้าหัวคู่สาย คุณภาพจุดสัมผัส และการแยกห่างจากสายไฟกำลัง สำหรับใยแก้วนำแสง ให้ตรวจสอบความสะอาดของหน้าสัมผัสปลายใย ทิศทาง TX/RX ความเข้ากันได้ของโมดูล และกำลังสัญญาณเทียบกับข้อกำหนดจริง ค่า DDM เป็นหลักฐานประกอบด้านกำลังสัญญาณ ไม่ใช่สิ่งทดแทนการตรวจสอบความสมบูรณ์ของเฟรม การอ่านค่าเพียงครั้งเดียวไม่ได้พิสูจน์ว่าโมดูลเสีย หากจำเป็น ให้กำหนดช่วงเวลาบำรุงรักษาและเปรียบเทียบการรับส่งข้อมูลแบบควบคุมในทั้งสองทิศทาง
การหมดเวลารออาจเกิดจากงานของแอปพลิเคชันที่ติดค้าง การรีสตาร์ตอุปกรณ์ หรือการกำหนดค่าที่ไม่ถูกต้องได้เช่นกัน ให้เก็บหลักฐานอาการไว้ แล้วระบุชั้นที่สังเกตการณ์: ลิงก์เชื่อมต่อแล้วหรือไม่ เฟรมสมบูรณ์หรือไม่ คิวรับเฟรมนั้นหรือไม่ และแอปพลิเคชันตอบสนองทันเวลาหรือไม่ หากมีเพียงบันทึกของแอปพลิเคชัน ให้ระบุว่ายังไม่ยืนยันสาเหตุ แทนที่จะใช้การเปลี่ยนสวิตช์มาทดแทนการวินิจฉัย
เก็บบันทึกการตรวจรับที่วิศวกรคนอื่นสามารถทดสอบซ้ำได้
สวิตช์แบบจัดการได้ที่ FCTEL เผยแพร่ข้อมูลไว้ ซึ่งมีพอร์ตไฟฟ้า Gigabit จำนวน 24 พอร์ต และตัวเลือกพอร์ตแสง/ไฟฟ้า Gigabit SFP จำนวนสี่พอร์ต เป็นจุดเริ่มต้นที่เกี่ยวข้องสำหรับเอกสารการเชื่อมต่อด้วยสายทองแดงและใยแก้วนำแสงในงานอุตสาหกรรม บทความนี้ไม่ได้รับรองว่าผลิตภัณฑ์นั้นมีคำสั่ง CRC หรือสถาปัตยกรรมชิปเซ็ตที่ยังไม่ได้เผยแพร่ ให้ยืนยันว่าเฟิร์มแวร์ที่ติดตั้งแสดงค่าชี้วัดขาเข้า ขาออก และทางแสงใดบ้าง รวมถึงพฤติกรรมการรีเซ็ต การวนกลับเมื่อค่านับเกินขีดจำกัด และการล้างค่า อย่าล้างตัวนับของระบบที่ใช้งานจริงเพียงเพื่อความสะดวกโดยยังไม่ได้เก็บค่าฐานไว้ก่อน
บันทึกการตรวจรับควรประกอบด้วยโทโพโลยี หมายเลขพอร์ต สื่อและโมดูล ช่วงสังเกตการณ์ สภาวะโหลด ค่าตัวนับก่อนและหลัง การเปลี่ยนชิ้นส่วนแต่ละครั้ง และการกลับมาทำงานของแอปพลิเคชัน การที่จำนวนเฟรมเสียหายหยุดเพิ่มเป็นหลักฐานว่าการส่งข้อมูลดีขึ้น แต่ยังต้องตรวจสอบการหมดเวลารอ ความหน่วง และความต่อเนื่องด้วย ให้ระบุว่าไม่พบข้อผิดพลาดใหม่ภายใต้เงื่อนไขที่ทดสอบ แทนที่จะรับรองว่าแพ็กเก็ตจะไม่มีวันสูญหาย การแยกกลไก สิ่งที่สังเกตได้ และข้อสรุปออกจากกันทำให้การตรวจสอบสามารถทำซ้ำได้
เอกสารอ้างอิงทางเทคนิค: เอกสาร Cisco เกี่ยวกับกลไก CRC/FCS. แหล่งข้อมูล FCTEL ที่เกี่ยวข้อง: บทความทางเทคนิค และ เอกสารผลิตภัณฑ์สวิตช์อุตสาหกรรม.
