เมื่อข้อความจากโหนดหนึ่งหายไป คำว่า bus-off มักถูกใช้แทนการไม่สื่อสารทุกกรณี แต่ bus-off เป็นสถานะเฉพาะของตัวควบคุม CAN ที่เกิดจากกลไกจำกัดความผิดพลาด ไม่ใช่คำเรียกรวมของไฟเลี้ยงขาด กล่องหลับ หรือเครื่องมือหลุด การแยกคำเหล่านี้ให้ตรงหลักฐานช่วยเลือกขั้นตรวจที่เหมาะ และช่วยไม่ให้การรีสตาร์ตที่ทำให้กลับมาชั่วคราวถูกเข้าใจว่าแก้ต้นเหตุสำเร็จแล้ว
เหตุใดโปรโตคอลจึงมีสถานะหยุดร่วมสื่อสาร
CAN ใช้ตัวนับและสถานะเพื่อลดผลของโหนดที่พบความผิดพลาดมากต่อเครือข่าย ในกลไกทั่วไป bus-off เกิดเมื่อ TEC เกิน 255 ตัวควบคุมจึงออกจากการเข้าร่วมสื่อสารตามปกติ จุดประสงค์คือจำกัดผลกระทบ ไม่ใช่ฟังก์ชันซ่อมฮาร์ดแวร์ และไม่พิสูจน์โดยตัวมันเองว่าไอซีภายในเสีย สภาพสาย การตั้งเวลา และเงื่อนไขการสื่อสารรอบตัวสามารถทำให้โหนดเผชิญความผิดพลาดได้เช่นกัน
error-passive เป็นสถานะก่อนหน้าที่ต้องแยกจาก bus-off โหนดใน error-passive ยังสามารถสื่อสารภายใต้ข้อกำหนดของสถานะนั้น ส่วน bus-off มีขั้นตอนกลับเข้าร่วมที่ต้องอ้างอิงตัวควบคุมและซอฟต์แวร์ การเห็นบัสยังมีเฟรมจากโหนดอื่นไม่ได้หักล้างว่าโหนดหนึ่งอาจอยู่ bus-off เพราะสถานะเป็นรายตัวควบคุม ไม่ใช่สวิตช์ที่ทำให้สายทั้งเส้นเงียบพร้อมกัน
- ข้อความหาย
การไม่พบข้อความอาจมาจากไฟเลี้ยง การหลับ หรือการบันทึกหยุด
- ตรวจสถานะ
ดูว่ามีรายงาน bus-off ของโหนดนั้นจริงหรือเพียงคาดจากอาการ
- ตรวจเหตุเดิม
หากมีสถานะจริง ให้ย้อนดูข้อผิดพลาดและ TEC ก่อนเหตุ ไม่ถือว่าฮาร์ดแวร์เสียทันที
คำว่า bus-off ต้องมีหลักฐานสถานะตัวควบคุม ไม่ใช่ใช้แทนความเงียบทุกกรณี
ตัวอย่างสมมติของอาการกลับมาแล้วหายอีก
สมมติชุดฝึกบันทึกว่าโหนด ก มีข้อผิดพลาดฝั่งส่งเพิ่ม ต่อมาเครื่องมือที่อ่านสถานะของ ก ได้โดยตรงรายงาน bus-off แล้วข้อความจาก ก หายไป หลังขั้นตอนเริ่มระบบใหม่ตามคู่มือ ก ส่งได้อีกระยะหนึ่ง แต่เมื่อเงื่อนไขเดิมเกิดก็เข้า bus-off ซ้ำ ลำดับนี้ชี้ว่าการเริ่มใหม่คืนสถานะการทำงานได้ชั่วคราว แต่ต้นเหตุที่ทำให้ผิดพลาดยังอาจอยู่ ไม่ควรสรุปว่ากล่องซ่อมสำเร็จจากช่วงที่กลับมาส่งได้
เปรียบเทียบกับอีกสถานการณ์สมมติที่ข้อความ ก หายพร้อมไฟเลี้ยงตก แต่ไม่มีข้อมูลสถานะภายในเลย กรณีหลังควรรายงานว่าขาดการสื่อสารสัมพันธ์กับไฟเลี้ยง ไม่ควรใส่คำว่า bus-off เพื่อให้ดูเฉพาะทาง ทั้งสองอาการอาจทำให้หน้าจอปลายทางแสดงค่าเดิมเหมือนกัน แต่หลักฐานที่จำเป็นและคำอธิบายต่างกัน การแยกชัดตั้งแต่บันทึกแรกช่วยไม่ให้ผู้ตรวจคนต่อไปเริ่มจากสมมติฐานผิด
นำไปใช้เก็บหลักฐานก่อนสถานะเปลี่ยน
- ระบุว่าคำว่า bus-off มาจากสถานะตัวควบคุมจริง จากรายงานเครื่องมือ หรือเป็นเพียงการคาดจากข้อความหาย
- เก็บช่วงก่อนเหตุพร้อมชนิดข้อผิดพลาด TEC และสถานะอื่นเท่าที่อ่านได้อย่างปลอดภัย
- ตรวจว่าตัวบันทึกยังทำงานและรับข้อความจากโหนดอื่นได้ต่อเนื่อง เพื่อแยกโหนดหายจากการบันทึกหยุด
- เปรียบเทียบกับเหตุการณ์ไฟเลี้ยงหรือการเปลี่ยนโหมดที่มีข้อมูลอยู่ โดยไม่สร้างข้อผิดพลาดขึ้นเพื่อทดลอง
- ใช้ขั้นตอนฟื้นตัวที่ผู้ผลิตกำหนดเท่านั้น แล้วตรวจซ้ำในเงื่อนไขที่เคยเกิดเหตุเพื่อประเมินว่าต้นเหตุยังอยู่หรือไม่
การเก็บเฉพาะช่วงหลังข้อความหายมักไม่พอ เพราะกลไกป้องกันทำให้กิจกรรมของโหนดเปลี่ยนไปแล้ว สิ่งที่ควรหาอยู่ก่อนหน้า เช่น การเพิ่มของข้อผิดพลาดชนิดหนึ่งหรือความผิดปกติทางไฟเลี้ยง แต่ความเกิดก่อนในเวลาไม่ได้พิสูจน์สาเหตุทั้งหมด อาจมีเหตุร่วมที่ทำให้ทั้งสองเปลี่ยน การวิเคราะห์ควรเขียนความสัมพันธ์ที่พบและสิ่งที่ยังไม่ได้ตรวจ แทนใช้คำว่าต้นเหตุเมื่อมีเพียงความใกล้กันของเวลา
- ผิดพลาดเพิ่ม
ข้อมูลก่อนเหตุของ ก แสดงปัญหาฝั่งส่งและสถานะเปลี่ยน
- เข้า bus-off
สถานะที่อ่านได้ยืนยันว่า ก ออกจากการร่วมสื่อสารตามปกติ
- เริ่มตามคู่มือ
หลังขั้นตอนเริ่มใหม่ ก ส่งได้อีกช่วงหนึ่ง
- เกิดซ้ำ
เมื่อเงื่อนไขเดิมกลับมา ก เข้า bus-off อีก จึงยังไม่ยืนยันการแก้ต้นเหตุ
สถานการณ์สมมติแสดงเหตุที่การรีสตาร์ตไม่ใช่หลักฐานว่าแก้ต้นเหตุแล้ว
การกลับมาทำงานมีทั้งกฎบัสและนโยบายซอฟต์แวร์
เอกสารตัวควบคุมระบุขั้นตอนสังเกตบัสสำหรับการกลับจาก bus-off โดยมีการนับกลุ่มของบิต recessive ตามข้อกำหนด เช่น 128 ครั้งของช่วง 11 บิตต่อเนื่อง แต่รายละเอียดการเริ่มนับและการอนุญาตกลับทำงานสัมพันธ์กับฮาร์ดแวร์และซอฟต์แวร์ ตัวเลขนี้จึงไม่ใช่สูตรเวลารอของรถทุกคัน หากบัสมีข้อมูลคั่นหรือซอฟต์แวร์ยังไม่อนุญาต เวลาที่เห็นจริงย่อมไม่เท่าการคูณบิตอย่างง่าย
แม้คำนวณ 128 คูณ 11 ได้ 1408 บิต ก็ไม่ควรนำไปหารอัตราบิตแล้วประกาศว่าทุกโหนดต้องกลับมาภายในเวลานั้น มันเป็นปริมาณของเงื่อนไขบิตที่ต้องสังเกต ไม่ใช่กำหนดเวลาครบทุกขั้นตอนของระบบ นอกจากนี้การออกจาก bus-off ไม่รับประกันว่าซอฟต์แวร์ชั้นบนได้สร้างข้อมูลใหม่หรือคืนสถานะการทำงานทั้งหมด ต้องตรวจความสดและความถูกต้องของข้อมูลหลังกลับมาด้วย
ข้อผิดพลาดของการรีเซ็ตซ้ำเพื่อซ่อนอาการ
การล้างสถานะซ้ำโดยไม่เก็บสาเหตุทำให้เส้นเวลาหายและอาจทำให้เกิดปัญหาเดิมวนซ้ำ การที่หน้าจอไม่แสดง bus-off หลังเริ่มใหม่อาจเพียงเพราะตัวนับถูกเริ่มใหม่ ไม่ใช่เพราะสายหรือการตั้งค่าถูกแก้ บทความนี้จึงไม่เสนอการปิดกลไกป้องกันหรือบังคับให้โหนดส่งต่อเมื่อเกิดความผิดพลาด การฟื้นตัวควรอยู่ในขั้นตอนที่ผู้ผลิตออกแบบและใช้เป็นส่วนหนึ่งของการตรวจ ไม่ใช่แทนการหาสาเหตุ
ตรวจสอบผลโดยดูการทำงานหลังกลับเข้าบัส
การยืนยันผลควรครอบคลุมว่าข้อความจากโหนดกลับมา มีข้อมูลใหม่ตามคาบที่คาดจากเอกสาร และไม่พบการเปลี่ยนสถานะซ้ำในช่วงเงื่อนไขเดิม หากกลับมามีเพียงเฟรมบางชนิดแต่ข้อมูลที่ต้องใช้ยังหาย ต้องรายงานว่าการฟื้นตัวยังไม่ครบ การใช้ข้อความสั้นว่าติดต่อได้แล้วอาจซ่อนข้อจำกัดนี้ โดยเฉพาะเมื่อเครื่องมือเข้าถึงเฉพาะบริการวินิจฉัยแต่ไม่เห็นทางเดินข้อมูลปกติ
บันทึกสุดท้ายควรแยกเหตุที่ยืนยัน สิ่งที่แก้ ขั้นตอนคืนสภาพ และช่วงสังเกตผล หากไม่มีข้อมูล TEC หรือสถานะจริงตั้งแต่ต้น ให้คงข้อจำกัดนั้นไว้ ไม่ย้อนเขียนว่าเคย bus-off เพื่อให้เรื่องเล่าสมบูรณ์ การเลือกคำที่แม่นช่วยให้ข้อมูลสาธารณะนำไปใช้เรียนรู้ได้โดยไม่สร้างความเข้าใจว่าความเงียบของบัสทุกครั้งเป็นความผิดของกล่อง
