แยกส่วนเรียกกับส่วนตอบในเฟรม LIN

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

ผู้ส่ง header ไม่จำเป็นต้องเป็นผู้รับข้อมูลเพียงคนเดียว

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

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

1. 1
   ก เริ่มส่วนหัว

   ฝ่ายควบคุมสร้าง break, sync และรหัสที่มี parity ตามตาราง

2. 2
   ข เผยแพร่คำตอบ

   ผู้เผยแพร่ที่กำหนดส่งข้อมูลและ checksum

3. 3
   ก และ ค ติดตาม

   หากคำตอบครบแต่ ค ไม่อัปเดต ต้องตรวจการแปลและโปรแกรมของ ค ต่อ

สามบทบาทสมมติแยกการส่งบนสายจากการใช้ข้อมูล

ตัวอย่างสมมติของสามบทบาทในเฟรมเดียว

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

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

นำไปใช้แบ่งอาการตามส่วนที่มีหลักฐาน

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

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

1. 1
   รวม 5 ไบต์

   ข้อมูล 4 ไบต์ + checksum 1 ไบต์

2. 2
   รวม 50 บิต

   start 1 + data 8 + stop 1 = 10 ช่วงบิตต่อไบต์

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

   50 / 10000 = 0.005 วินาที เฉพาะไบต์คำตอบ

4. 4
   เผื่อส่วนหัวด้วย

   ช่องทั้งเฟรมยาวเพียง 5 มิลลิวินาทีไม่พอ เพราะยังไม่รวมส่วนหัวและช่องว่าง

ตัวอย่างสี่ไบต์ข้อมูลกับหนึ่งไบต์ผลรวมยังไม่รวมส่วนหัว

ตัวอย่างเวลาเฉพาะข้อมูลและ checksum

สมมติ response มีข้อมูลสี่ไบต์กับ checksum หนึ่งไบต์ และใช้รูปแบบไบต์ที่มี start หนึ่ง data แปด stop หนึ่ง รวมสิบช่วงบิตต่อไบต์ ส่วนนี้มี 5 คูณ 10 เท่ากับ 50 ช่วงบิต หากอัตราสมมติเป็น 10000 บิตต่อวินาที คาบบิตเท่ากับ 100 ไมโครวินาที จึงใช้เวลาส่งขั้นต่ำของไบต์เหล่านี้ 5 มิลลิวินาที โดยยังไม่รวมช่องว่างที่อนุญาตและเวลา header

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

ข้อผิดพลาดจากการมองว่าทุกไบต์มาจากโหนดเดียว

ลักษณะขอบหรือระดับสัญญาณอาจต่างเล็กน้อยระหว่างส่วนหัวและส่วนตอบเพราะผู้ส่งเปลี่ยน แต่ไม่ใช่ทุกความต่างจะปกติ ต้องเทียบกับข้อกำหนดและสภาพการวัด การใช้ภาพเพียงเฟรมเดียวระบุชื่อผู้ส่งแต่ละส่วนโดยไม่มีเอกสารยังเกินหลักฐาน อีกทั้ง checksum ที่ไม่ตรงอาจเป็นการเลือกแบบ classic หรือ enhanced ผิดในเครื่องมือ ไม่ใช่หลักฐานว่าภาคส่งของผู้ตอบเสียทันที

ตรวจสอบผลด้วยทั้งส่วนหัว คำตอบ และผู้ใช้ข้อมูล

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

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