บทความเทคนิคต้นฉบับ FCTEL · ทีมเทคนิค FCTEL
เผยแพร่ครั้งแรก: 2026-10-04 · แก้ไขล่าสุด: 2026-10-04
หลังจากเชื่อมต่ออุปกรณ์ RS232 หรือ RS485 เข้ากับ Ethernet ข้อมูลที่ได้จากการอ่านหนึ่งครั้งไม่จำเป็นต้องเป็นข้อความที่ครบถ้วนหนึ่งข้อความจากอุปกรณ์นั้น การแยกและรวมข้อความมักสะท้อนถึงขอบเขตที่ต่างกันในชั้นอนุกรม เครือข่าย และแอปพลิเคชัน มากกว่าจะเป็นข้อมูลสูญหาย การเข้าใจชั้นเหล่านี้ช่วยให้สร้างตัวแยกวิเคราะห์ที่เชื่อถือได้และค้นหาสาเหตุที่แท้จริงของข้อขัดข้องได้ บทความนี้อธิบายกลไกทั่วไป ส่วนโหมดที่รองรับ พฤติกรรมของบัฟเฟอร์ และช่วงค่าพารามิเตอร์ของผลิตภัณฑ์ FCTEL แต่ละรุ่น ต้องตรวจสอบจากคู่มือของผลิตภัณฑ์นั้น
เปิดภาพต้นฉบับเพื่อดูรายละเอียด เลื่อนแผนภาพในแนวนอนเพื่ออ่านข้อความกำกับทั้งหมดในขนาดเต็ม
UART จัดเฟรมอักขระ ส่วนโปรโตคอลชั้นแอปพลิเคชันกำหนดข้อความ
โดยปกติ UART เริ่มอักขระด้วยบิตเริ่มต้น ส่งบิตข้อมูลตามจำนวนที่ตกลงกัน อาจเพิ่มบิตพาริตี และจบด้วยบิตหยุด ตัวรับประกอบอักขระกลับคืนโดยใช้อัตราบอดและรูปแบบที่ตั้งค่าไว้ อัตราบอด บิตข้อมูล พาริตี และบิตหยุดต้องตรงกัน ดังนั้น ระดับสัญญาณที่ไม่ถูกต้อง สัญญาณรบกวน หรือความผิดพลาดในการสุ่มตัวอย่างจึงอาจทำให้อักขระผิดพลาดได้ก่อนที่จะเกี่ยวข้องกับเครือข่าย
เมื่อใช้ 8N1 ไบต์ขนาดแปดบิตยังต้องมีบิตเริ่มต้นหนึ่งบิตและบิตหยุดหนึ่งบิต รวมเป็นระยะเวลาสิบบิต ที่อัตราตัวอย่าง 9,600 บิต/วินาที อักขระหนึ่งตัวใช้เวลาประมาณ 1.04 มิลลิวินาที นี่เป็นตัวอย่างการคำนวณ ไม่ใช่ข้อกำหนดสมรรถนะของผลิตภัณฑ์ ตัวอย่างนี้อธิบายว่าเหตุใดอัตราการส่งผ่านไบต์ที่ใช้งานได้จึงต่ำกว่าอัตราบิตที่ระบุ และเหตุใดบัฟเฟอร์จึงต้องรองรับอักขระที่เข้ามา
RS232, RS422 และ RS485 อธิบายอินเทอร์เฟซทางไฟฟ้าและรูปแบบการเชื่อมต่อที่ต่างกัน ส่วน UART อธิบายจังหวะเวลาของอักขระ ไม่มีสิ่งใดในนี้กำหนดข้อความชั้นแอปพลิเคชันได้ด้วยตัวเอง คำสั่งสอบถามอุณหภูมิอาจมีหลายไบต์ อุปกรณ์ต้องกำหนดขอบเขตข้อความแยกต่างหาก โดยใช้ความยาว ตัวคั่น รูปแบบตายตัว หรือช่วงเวลาที่โปรโตคอลกำหนด
เซิร์ฟเวอร์อุปกรณ์อนุกรมเชื่อมกลไกทั้งสองอย่างไร
ในทิศทางรับ อินเทอร์เฟซอนุกรมจะประกอบไบต์กลับคืนจากสัญญาณไฟฟ้าก่อน จากนั้นไบต์เข้าสู่ FIFO หรือบัฟเฟอร์ซอฟต์แวร์ ตรรกะการจัดแพ็กเก็ตจึงส่งข้อมูลส่วนหนึ่งไปยังสแตกเครือข่ายตามเงื่อนไขความยาวหรือการรอที่นำมาใช้ ในอีกทิศทางหนึ่ง ไบต์ออกจากบัฟเฟอร์รับของเครือข่ายและถูกส่งทีละอักขระโดย UART แต่ละทิศทางมีการบัฟเฟอร์และการจัดตารางการทำงานของตนเอง
ข้อความชั้นแอปพลิเคชันหนึ่งข้อความอาจครอบคลุมข้อมูลที่รับทางอนุกรมหลายชุด และข้อมูลหนึ่งชุดอาจมีหลายข้อความ การจัดแพ็กเก็ตเป็นการแลกเปลี่ยนระหว่างเวลารอกับประสิทธิภาพการส่ง ไม่ได้เข้าใจโปรโตคอลชั้นสูงทุกชนิดโดยอัตโนมัติ เอกสารเซิร์ฟเวอร์อนุกรมที่เผยแพร่สู่สาธารณะของ FCTEL ระบุโหมดการทำงานแบบเซิร์ฟเวอร์ TCP และไคลเอนต์ TCP ส่วนรุ่นนั้นมีวิธีจัดเฟรมแบบใดหรือไม่ รวมถึงชื่อและช่วงค่าของการตั้งค่า ต้องตรวจสอบจากคู่มือของรุ่นที่เกี่ยวข้อง
หากแหล่งข้อมูลอนุกรมยังส่งต่อเนื่องขณะที่อัปลิงก์ถูกปิดกั้น ปริมาณข้อมูลในบัฟเฟอร์จะเพิ่มขึ้น กลไกแรงดันย้อนกลับของ TCP สามารถจำกัดการส่งผ่านเครือข่ายได้ แต่ไม่สามารถทำให้แหล่งข้อมูลอนุกรมที่ไม่มีการควบคุมการไหลที่เหมาะสมหยุดส่งได้ ต้องประเมินความจุบัฟเฟอร์ การควบคุมการไหลด้วยฮาร์ดแวร์หรือซอฟต์แวร์ที่รองรับ พฤติกรรมของแหล่งข้อมูล และนโยบายเมื่อการเชื่อมต่อขาดร่วมกัน การขนส่งข้อมูลที่เชื่อถือได้ของ TCP ไม่ได้หมายถึงการทำงานโดยไม่สูญเสียข้อมูลอย่างไม่จำกัดภายใต้ความคับคั่งทุกรูปแบบ
เปิดภาพต้นฉบับเพื่อดูรายละเอียด เลื่อนแผนภาพในแนวนอนเพื่ออ่านข้อความกำกับทั้งหมดในขนาดเต็ม
TCP รักษาลำดับไบต์ ไม่ใช่ขอบเขตของการส่งแต่ละครั้ง
TCP นำเสนอการเชื่อมต่อในรูปของสตรีมไบต์ที่เรียงตามลำดับ หมายเลขลำดับระบุตำแหน่งไบต์ ส่วนการตอบรับ การส่งซ้ำ และการควบคุมการไหลทำหน้าที่จัดการการขนส่งข้อมูล เซกเมนต์ TCP เป็นหน่วยขนส่งข้อมูลของเครือข่าย ขณะที่ข้อความของแอปพลิเคชันเป็นไปตามโปรโตคอลชั้นแอปพลิเคชัน การเรียกส่งหนึ่งครั้งไม่ได้กำหนดให้ตัวรับต้องได้รับข้อมูลจำนวนเดียวกันนั้นจากการอ่านหนึ่งครั้ง
สมมติว่าอุปกรณ์สร้างข้อความ A ขนาดหกไบต์ ตามด้วยข้อความ B ขนาดสี่ไบต์ การถ่ายโอนที่สำเร็จจะส่งมอบไบต์สิบไบต์ชุดเดิมตามลำดับเดิม โปรแกรมอาจอ่านสองไบต์แรกของ A ก่อน แล้วจึงอ่านอีกแปดไบต์ที่เหลือ หรืออ่านทั้งสิบไบต์ในครั้งเดียวก็ได้ สิ่งเหล่านี้มักเรียกว่าการแยกและรวมข้อความ หากไบต์ครบถ้วนและเรียงตามลำดับ พฤติกรรมทั้งสองอย่างนี้เพียงอย่างเดียวไม่ได้บ่งชี้ว่าข้อมูลเสียหาย
ความยาวของข้อมูลที่อ่านได้ขึ้นอยู่กับข้อมูลที่มีอยู่ การบัฟเฟอร์ฝั่งรับ การจัดตารางเธรด และอาร์กิวเมนต์ของอินเทอร์เฟซ การแบ่งเซกเมนต์ในเครือข่ายยังขึ้นอยู่กับเส้นทางและสแตกด้วย แอปพลิเคชันไม่สามารถอนุมานความยาวข้อความของแอปพลิเคชันจากความยาวเซกเมนต์ TCP ที่จับได้ หรือถือว่าข้อมูลที่คืนจากการอ่านแต่ละครั้งเป็นคำตอบจากอุปกรณ์หนึ่งข้อความ เมื่อการเชื่อมต่อปิดลง แอปพลิเคชันยังต้องจัดการข้อมูลที่ได้รับครบถ้วนและระบุข้อความส่วนท้ายที่ยังไม่ครบ
เปิดภาพต้นฉบับเพื่อดูรายละเอียด เลื่อนแผนภาพในแนวนอนเพื่ออ่านข้อความกำกับทั้งหมดในขนาดเต็ม
ตัวแยกวิเคราะห์ที่ทนทานรักษาสถานะข้ามการอ่านแต่ละครั้ง
ใช้บัฟเฟอร์ไบต์ที่คงข้อมูลไว้ระหว่างการอ่าน การอ่านแต่ละครั้งจะเพิ่มข้อมูลต่อท้าย ลูปการแยกวิเคราะห์ตรวจสอบก่อนว่ามีส่วนหัวแล้วหรือไม่ จากนั้นจึงใช้กฎความยาวหรือการสิ้นสุดของโปรโตคอล ควรตรวจสอบและส่งมอบให้ชั้นประมวลผลของแอปพลิเคชันเฉพาะข้อความที่ครบถ้วนเท่านั้น เก็บไบต์ที่ยังไม่ครบไว้สำหรับการอ่านครั้งถัดไป และแยกวิเคราะห์ข้อความที่ครบถ้วนหลายข้อความทีละข้อความโดยไม่ทิ้งข้อมูลที่เหลือ
สำหรับโปรโตคอลที่กำหนดเองซึ่งประกอบด้วยตัวระบุการซิงโครไนซ์ ความยาว เพย์โหลด และเช็กซัม ต้องระบุว่าความยาวรวมส่วนหัวหรือไม่ ลำดับไบต์เป็นอย่างไร ขนาดสูงสุดที่อนุญาตเท่าใด และเช็กซัมครอบคลุมส่วนใด แผนภาพใช้รูปแบบสมมติเพื่ออธิบาย ไม่ใช่โปรโตคอล FCTEL ในการใช้งานจริง ให้ใช้โปรโตคอลของอุปกรณ์จริง จำกัดการเพิ่มขนาดของบัฟเฟอร์ และปฏิเสธค่าความยาวที่เป็นไปไม่ได้ กำหนดวิธีซิงโครไนซ์ใหม่เมื่อการตรวจสอบไม่ผ่าน เพื่อไม่ให้ไบต์ผิดพลาดเพียงไบต์เดียวทำให้ข้อความทั้งหมดที่ตามมาคลาดแนว
โปรโตคอลที่ใช้ตัวคั่นต้องจัดการการเอสเคปหรือค่าตัวคั่นที่อยู่ภายในเพย์โหลดไบนารี โปรโตคอลความยาวคงที่ต้องคำนึงถึงประเภทข้อความที่มีความยาวต่างกัน สำหรับโปรโตคอลอนุกรมที่อาศัยจังหวะเวลา ต้องแยกช่วงเวลาที่สังเกตได้บนสายอนุกรมออกจากเวลาที่ข้อมูลมาถึงซึ่งแอปพลิเคชันเครือข่ายเห็น การบัฟเฟอร์และการจัดตารางการทำงานอาจเปลี่ยนช่วงเวลาเหล่านั้นได้ ช่องว่างระหว่างการอ่าน TCP จึงไม่ใช่ช่องว่างระหว่างเฟรมอนุกรมเดิมโดยอัตโนมัติ
เวลารอในการจัดแพ็กเก็ตเปลี่ยนอะไรบ้าง
การรอนานขึ้นอาจรวมไบต์อนุกรมได้มากขึ้นก่อนส่งต่อและลดโอเวอร์เฮดจากการส่งข้อมูลขนาดเล็ก แต่ก็อาจทำให้ไบต์แรกส่งล่าช้า การรอสั้นลงอาจส่งต่อไบต์ได้เร็วขึ้นและทำให้แอปพลิเคชันพบข้อความที่ยังไม่ครบมากขึ้น ทั้งสองแบบไม่อาจทดแทนการแยกวิเคราะห์ที่ถูกต้องได้ ควรปรับความหน่วงของแอปพลิเคชันและความครบถ้วนถูกต้องของข้อมูลให้เหมาะสม แทนการบังคับให้การอ่านหนึ่งครั้งได้หนึ่งข้อความ
สำหรับการสื่อสารแบบคำขอ–คำตอบ ให้พิจารณาการประมวลผลของอุปกรณ์ การส่งข้อมูลอนุกรม การบัฟเฟอร์ของเซิร์ฟเวอร์ เวลาไปกลับของเครือข่าย และการจัดตารางของแอปพลิเคชันแยกกัน ตั้งเวลาหมดอายุให้ครอบคลุมขั้นตอนเหล่านี้โดยอาศัยการทดสอบแบบควบคุม พฤติกรรมการลองใหม่ต้องสอดคล้องกับความหมายของการดำเนินงาน โดยพิจารณาว่าคำสั่งเขียนหรือคำสั่งให้ทำงานสามารถทำซ้ำได้อย่างปลอดภัยหรือไม่ แทนการส่งซ้ำไปเรื่อย ๆ อย่างไม่มีกำหนดหลังหมดเวลารอ
การทดสอบตรวจรับต้องครอบคลุมเนื้อหา จังหวะเวลา และการกู้คืน
ใช้หมายเลขลำดับและความยาวที่ระบุแยกแยะได้ในการทดสอบแบบควบคุม ให้ครอบคลุมข้อความเดี่ยว ข้อความที่ส่งต่อเนื่องติดกัน อินพุตที่แบ่งเป็นส่วนย่อย เพย์โหลดยาว และช่วงหยุดสั้น ๆ ใช้ตัวแยกวิเคราะห์เดิมโดยจงใจเปลี่ยนขนาดการอ่าน แล้วตรวจสอบจำนวนข้อความสุดท้าย ลำดับ เพย์โหลด และผลการตรวจสอบ วิธีนี้ให้หลักฐานที่หนักแน่นกว่าหน้าต่างเทอร์มินัลที่เพียงดูเหมือนปกติ บันทึกตัวอย่างเป็นอินพุตสำหรับการทดสอบ ไม่ใช่ผลการวัดจากลูกค้า
จากนั้นทดสอบรูปแบบอนุกรมที่ไม่ตรงกัน อัปลิงก์ขาด ความคับคั่ง และการเชื่อมต่อใหม่แยกกัน แยกความผิดพลาดของอักขระอนุกรมออกจากการส่งซ้ำในเครือข่าย แยกบัฟเฟอร์ล้นออกจากการแบ่งข้อความตามปกติ และแยกการหมดเวลารอของแอปพลิเคชันออกจากความผิดพลาดด้านความครบถ้วนถูกต้องของข้อมูล บันทึกจำนวนไบต์ขาเข้า ข้อความที่แยกวิเคราะห์แล้ว ข้อมูลที่เหลือในบัฟเฟอร์ สาเหตุของข้อผิดพลาด และเวลาที่ใช้กู้คืน พร้อมเก็บข้อมูลอ้างอิงเวลาที่ใช้ในการจับแพ็กเก็ตและบันทึกข้อมูลอนุกรมไว้
เมื่อเลือกเซิร์ฟเวอร์อุปกรณ์อนุกรม FCTEL ให้ตรวจสอบอินเทอร์เฟซจริง โหมดการทำงาน การควบคุมการไหล และพฤติกรรมเมื่อการเชื่อมต่อขาด ความแตกต่างสำคัญทางวิศวกรรมคือ เซิร์ฟเวอร์ทำหน้าที่เชื่อมต่อและขนส่งข้อมูล โปรโตคอลชั้นแอปพลิเคชันกำหนดข้อความ และตัวแยกวิเคราะห์ประกอบข้อความกลับคืนจากการอ่านหลายครั้ง การแบ่งหน้าที่อย่างชัดเจนช่วยป้องกันไม่ให้พฤติกรรมปกติของสตรีมถูกเข้าใจผิดว่าเป็นข้อขัดข้องของฮาร์ดแวร์
เอกสารอ้างอิงทางเทคนิค: IETF RFC 9293 บริการสตรีมไบต์ของ TCP. แหล่งข้อมูล FCTEL ที่เกี่ยวข้อง: บทความทางเทคนิค และ เอกสารผลิตภัณฑ์เซิร์ฟเวอร์อุปกรณ์อนุกรม (ภาษาจีน).
