ตารางส่งของ LIN ทำให้บัสเป็นระเบียบอย่างไร

LIN จัดโอกาสส่งข้อมูลด้วยตารางที่ฝ่ายควบคุมเริ่มส่วนหัวตามลำดับ จึงต่างจากการให้ทุกโหนดแข่งขันเริ่มเฟรมแบบ CAN การเห็นข้อมูลตัวหนึ่งมาห่างกว่าตัวอื่นอาจเป็นผลของตาราง ไม่ใช่เซ็นเซอร์ตอบช้า บทความนี้อธิบายการใช้ช่องเวลาและคาบผ่านระบบฝึกสมมติ เพื่อให้ตรวจอาการโดยเทียบกับสิ่งที่เครือข่ายกำหนดจริง ไม่ใช้เวลาเดาจากรถคันอื่น

ตารางกำหนดโอกาสของข้อความ

ฝ่ายควบคุมหรือ commander ส่ง header ตามตาราง ส่วนผู้มีหน้าที่เผยแพร่ข้อมูลของเฟรมนั้นส่ง response ในช่วงที่จัดไว้ ช่องเวลาเฟรมต้องให้พื้นที่แก่ส่วนหัว คำตอบ และระยะเผื่อที่กำหนด การส่งคำตอบเสร็จเร็วไม่ได้หมายความว่าจะเริ่มช่องถัดไปทันทีเสมอ เพราะกำหนดการยังอิงตาราง การวิเคราะห์จึงต้องแยกเวลาที่สายมีข้อมูลจริงออกจากความยาวช่องที่จองไว้

ข้อมูลเวลาและความหมายเฟรมอาจอยู่ในเอกสารเครือข่ายหรือ LDF ตารางสามารถมีหลายชุดสำหรับสถานะต่างกัน จึงไม่ควรถือว่าลำดับเดียวที่พบในช่วงหนึ่งต้องใช้ตลอดการทำงาน การเปลี่ยนคาบพร้อมเปลี่ยนสถานะงานอาจถูกออกแบบไว้ ต้องตรวจข้อกำหนดก่อนกล่าวว่าโหนดส่งไม่สม่ำเสมอ และเครื่องมือแต่ละแบบอาจรองรับ LDF หรือการแสดงตารางไม่เท่ากัน

1. 1
   กำหนดช่อง

   ช่องรวมส่วนหัว คำตอบ และระยะเผื่อตามเอกสารเครือข่าย

2. 2
   เรียกส่วนหัว

   ฝ่ายควบคุมเริ่มโอกาส ผู้เผยแพร่จึงตอบข้อมูลของช่องนั้น

3. 3
   วนกลับตามรอบ

   คำตอบจบเร็วไม่ได้ทำให้คาบเท่าความยาวคำตอบ ต้องดูตำแหน่งซ้ำในตาราง

ช่องเวลาเฟรมกับคาบกลับมาของข้อความเป็นคนละปริมาณ

ตัวอย่างสมมติของรอบ 20 มิลลิวินาที

สมมติตารางฝึกมีสามช่องต่อเนื่อง ก ยาว 5 มิลลิวินาที ข ยาว 5 และ ค ยาว 10 รวมรอบ 20 มิลลิวินาที หากแต่ละข้อความปรากฏหนึ่งครั้งต่อรอบ คาบเริ่มของแต่ละชนิดจะเป็น 20 มิลลิวินาที แม้ช่อง ก สั้นเพียง 5 ก็ตาม การนำความยาวช่องไปเรียกคาบข้อมูลโดยตรงจึงผิด ต้องดูว่าข้อความนั้นกลับมาอีกครั้งในตารางเมื่อใด

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

นำไปใช้แยกคาบตารางจากคำตอบล่าช้า

1. อ่านตารางและสถานะที่ใช้งานจากเอกสารที่ตรงระบบ หากไม่มีให้แยกสิ่งที่สังเกตจากสิ่งที่ยังไม่ทราบ
2. ทำเครื่องหมายเวลาเริ่ม header ของข้อความแต่ละชนิดแล้วหาคาบซ้ำของชนิดเดียวกัน
3. ตรวจว่า response เกิดและจบในโอกาสที่คาดหรือไม่ แยกจากการรอ header รอบถัดไป
4. เทียบช่วงก่อนหลังการเปลี่ยนสถานะเพื่อดูว่าตารางเปลี่ยนตามข้อกำหนดหรือเกิดการขาดหาย
5. บันทึกนิยามเวลาและการตั้งเครื่องมือ เพื่อไม่เทียบคาบจากต้นเฟรมกับค่าที่วัดจากปลายเฟรมโดยไม่ปรับความหมาย

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

1. 1
   ก ใช้ 5 มิลลิวินาที

   ความยาวช่องแรกไม่ใช่คาบการกลับมาของ ก

2. 2
   ข ใช้ 5 มิลลิวินาที

   สิ้นช่องที่สอง เวลาสะสมเท่ากับ 10 มิลลิวินาที

3. 3
   ค ใช้ 10 มิลลิวินาที

   5 + 5 + 10 = 20 มิลลิวินาทีต่อรอบ

4. 4
   ก กลับทุก 20

   เมื่อ ก ปรากฏหนึ่งครั้งต่อรอบ คาบเริ่มของ ก คือ 20 มิลลิวินาที

ตัวอย่างสมมติมีแต่ละข้อความหนึ่งครั้งต่อรอบ

ข้อผิดพลาดจากการเร่งตารางเพื่อให้ได้ค่าถี่ขึ้น

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

การเพิ่มความถี่เรียกก็ไม่ได้ทำให้ปริมาณที่เซ็นเซอร์วัดมีข้อมูลใหม่เร็วขึ้นเสมอ หากการวัดภายในอัปเดตช้ากว่า การเรียกถี่ขึ้นอาจได้ค่าเดิมหลายครั้งโดยปกติ ต้องแยกอัตราวัด อัตราเผยแพร่บน LIN และอัตราแสดงผล มิฉะนั้นจะใช้จำนวนเฟรมเป็นตัวแทนความสดของข้อมูลทั้งระบบผิดไป

ตรวจสอบผลด้วยรอบครบและข้อมูลที่คาด

ในการตรวจชุดฝึกตัวอย่าง ควรเห็นลำดับช่อง 5 บวก 5 บวก 10 รวม 20 มิลลิวินาทีและการกลับมาของแต่ละชนิดตามรอบ โดยดูหลายรอบ ไม่ใช้เฟรมเดียวคำนวณตารางทั้งหมด ถ้าพบช่องเพิ่มเติมต้องตรวจว่าเป็นอีกตารางหรือเหตุการณ์ที่เอกสารระบุ หากไม่ทราบให้เก็บเป็นความต่างที่ต้องหาคำอธิบาย ไม่ลบช่วงนั้นเพื่อให้สถิติตรงแบบที่คิด

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