LIN มักใช้กับงานที่ไม่จำเป็นต้องสื่อสารตลอดเวลา จึงมีการจัดการพักและปลุกเครือข่าย แต่การไม่เห็นคำตอบในไฟล์ยังไม่ยืนยันว่าโหนดพักอย่างถูกต้อง บางครั้งไม่มี header ให้ตอบ บางครั้งภาครับส่งพักแต่โปรแกรมยังไม่กลับมา หรือไฟเลี้ยงอาจมีปัญหา บทความนี้แยกสถานะที่ต้องใช้หลักฐานคนละชนิดและไม่กำหนดเวลาหลับเฉพาะรถโดยไม่มีเอกสาร
บัส ภาครับส่ง และแอปพลิเคชันเป็นสามระดับ
สถานะบัสบอกกิจกรรมที่สังเกตบนสาย ส่วนสถานะภาครับส่งเป็นโหมดของชิปที่เชื่อมสายกับตรรกะ และสถานะแอปพลิเคชันบอกว่าโปรแกรมพร้อมสร้างหรือใช้ข้อมูลหรือไม่ ทั้งสามสัมพันธ์กันแต่ไม่เท่ากัน ภาครับส่งที่รองรับ sleep อาจยังเฝ้าตรวจเหตุปลุกบางชนิดได้ ขณะที่โปรแกรมยังพักอยู่ รายละเอียดต้องอ่านคู่มือของอุปกรณ์ที่ใช้จริง
การจัดการเครือข่าย LIN มีแนวคิดสั่งพักและร้องขอปลุก แต่การรองรับและเงื่อนไขของวงจรจริงมีรายละเอียดเฉพาะ การเห็นแรงดันสายอยู่ระดับพักจึงไม่รับรองว่าทุกโหนดกินกระแสต่ำ และการที่ตัวหนึ่งไม่ตอบก็ไม่แปลว่าต้องปลุกด้วยข้อความทดลองทันที ต้องดูตารางและสถานะงานที่ควรเกิดก่อน โดยใช้ขั้นตอนที่ผู้ผลิตกำหนดเท่านั้น
- กิจกรรมบนบัส
ไม่มีคำตอบอาจเพราะไม่มีส่วนหัวเรียก ยังบอกสถานะผู้ตอบไม่ได้
- โหมดภาครับส่ง
ชิปอาจพักแต่ยังเฝ้าเหตุปลุกที่รองรับ ต้องมีหลักฐานโหมดของชิป
- ข้อมูลพร้อมใช้
พัลส์แรกไม่ได้ยืนยันว่าโปรแกรมสร้างคำตอบครบและใหม่แล้ว
ความเงียบไม่พิสูจน์ว่าภาครับส่งและโปรแกรมเปลี่ยนสถานะในเวลาเดียวกัน
ตัวอย่างสมมติของการกลับมาสองขั้น
สมมติชุดฝึกพักหลังจบงาน และมีเหตุใช้งานที่ได้รับอนุญาตเมื่อเวลา 10 วินาที ภาครับส่งรายงานตื่นเมื่อ 10.02 วินาที แต่เฟรมข้อมูลที่แอปพลิเคชันตอบได้ครบปรากฏเมื่อ 10.08 วินาที ช่วงจากเหตุถึงสัญญาณตื่นคือ 20 มิลลิวินาที และจากนั้นถึงข้อมูลครบอีก 60 มิลลิวินาที รวม 80 มิลลิวินาที ตัวเลขนี้เป็นลำดับสมมติ ไม่ใช่ข้อกำหนดเวลา LIN ทุกระบบ
ถ้าผู้วิเคราะห์ดูเพียงสัญญาณตื่นที่ 10.02 แล้วกล่าวว่าข้อมูลพร้อมใช้ทันที จะข้ามขั้นที่โปรแกรมและตารางต้องกลับมาทำงาน ในทางกลับกันถ้าดูเฉพาะข้อมูลที่ 10.08 จะยังไม่รู้ว่าความล่าช้าเกิดในภาครับส่งหรือหลังจากนั้น การแบ่งสองช่วงช่วยตั้งคำถามได้ตรง แต่ต้องมีหลักฐานสถานะและนาฬิกาที่สัมพันธ์กันจริงจึงคำนวณได้
นำไปใช้ตรวจเหตุเงียบก่อนสรุปว่าหลับ
- ตรวจว่าขณะนั้นตารางควรส่ง header สำหรับข้อมูลที่สนใจหรือไม่ หากไม่มีการเรียก การไม่มี response ยังบอกสถานะผู้ตอบไม่ได้
- ตรวจเงื่อนไขพักและเหตุใช้งานที่ควรกลับมาจากเอกสารตรงระบบ ไม่ใช้เวลาจากชุดฝึกนี้เป็นเกณฑ์
- บันทึกสถานะภาครับส่งเท่าที่อ่านได้โดยวิธีที่อนุญาต พร้อมเวลาของ header และ response
- ตรวจว่าตัวบันทึกยังเฝ้าดูอยู่ตลอดช่วงเงียบ และไม่มีตัวกรองซ่อนข้อมูลที่กลับมา
- ยืนยันข้อมูลหลังตื่นครบและแปลได้ตามข้อตกลง ไม่ใช้การเห็นพัลส์แรกเป็นผลสำเร็จทุกขั้น
การสแกนหรือโปรแกรมที่ส่ง header เองอาจเปลี่ยนพฤติกรรมเครือข่าย จึงต้องรู้บทบาทของเครื่องมือที่เชื่อมอยู่ ไม่ถือว่าเปิดหน้าจอดูข้อมูลแล้วเป็นการสังเกตแบบไม่รบกวนเสมอ การตรวจสถานะพักที่ดีควรจดว่าเครื่องมือทำอะไรระหว่างรอ หากข้อมูลกลับมาเพราะเครื่องมือสร้างกิจกรรม ต้องแยกจากการกลับตามการใช้งานปกติของชุดฝึก
- เหตุเมื่อ 10 วินาที
ใช้เหตุที่อนุญาตและนาฬิกาที่เทียบกับสถานะถัดไปได้
- ตื่นเมื่อ 10.02
10.02 − 10 = 0.02 วินาที หรือ 20 มิลลิวินาที
- ข้อมูลครบเมื่อ 10.08
10.08 − 10.02 = 0.06 วินาที หรืออีก 60 มิลลิวินาที
- รวม 80 มิลลิวินาที
20 + 60 = 80 การดูเวลาสุดท้ายอย่างเดียวยังไม่แยกความล่าช้าแต่ละขั้น
เส้นเวลาสมมตินี้ไม่ใช่เกณฑ์เวลารถจริง
ข้อผิดพลาดของการยืมเกณฑ์ชิปเดียวไปใช้ทั้งรถ
คู่มือภาครับส่งอาจกำหนดเวลาหรือรูปแบบที่ทำให้ชิปเปลี่ยนโหมด แต่เวลาจากการใช้งานจนข้อมูลรถพร้อมใช้ยังรวมตัวควบคุม ซอฟต์แวร์ และตาราง LIN การนำเวลาชิปไปตั้ง timeout ของระบบทั้งหมดจึงไม่ครอบคลุม และพิกัดกระแส sleep ของชิปไม่ใช่กระแสหลับรวมทั้งรถ ข้อมูลระดับชิ้นส่วนต้องใช้ในขอบเขตชิ้นส่วนนั้น
ไฟเลี้ยงที่ยังมีค่าเฉลี่ยตามคาดไม่ได้พิสูจน์ว่าไม่มีการตกสั้น ๆ ระหว่างกลับมา และการไม่มีข้อผิดพลาด checksum ก็อาจเป็นเพราะไม่มี response ให้ตรวจ การประเมินจึงควรดูทั้งจำนวนข้อมูลที่ได้รับและสถานะ ไม่ใช้คำเตือนน้อยลงแทนคำว่าทำงานดีขึ้น หากยังไม่มีเครื่องมือเก็บเหตุสั้น ให้ระบุข้อจำกัด ไม่เดาว่าไฟเลี้ยงนิ่งตลอดจากมิเตอร์ครั้งเดียว
ตรวจสอบผลด้วยการพักและกลับซ้ำตามเงื่อนไข
เมื่อทำตามขั้นตอนที่อนุญาตแล้ว ควรเทียบการพักและการกลับหลายรอบภายใต้เงื่อนไขเดียวกัน บันทึกว่าภาครับส่งพร้อมเมื่อใดและข้อมูลสมบูรณ์เมื่อใด หากมีเพียงไฟล์บัส ให้ยืนยันเฉพาะกิจกรรมและความครบของเฟรม ไม่ระบุเวลาตื่นของชิปที่ไม่ได้วัด ตัวอย่างสองช่วง 20 กับ 60 มิลลิวินาทีใช้ได้เมื่อมีหลักฐานสองเหตุจริงเท่านั้น
ผลสุดท้ายควรบอกว่าช่วงเงียบสอดคล้องกับสถานะที่เอกสารกำหนดหรือยังขาดข้อมูล และหลังกลับมามีข้อมูลที่ต้องใช้ครบหรือไม่ หากโหนดกลับมาเฉพาะบางรอบให้เก็บทั้งรอบผ่านและไม่ผ่านเพื่อเทียบ ไม่เฉลี่ยเวลาจนกลบครั้งที่ไม่ตอบเลย การแยกการไม่ตอบออกจากการตอบช้าช่วยให้คำอธิบายสถานะประหยัดพลังงานไม่ถูกใช้ปิดข้อผิดพลาดที่ยังไม่แก้
