ตัวนับความผิดพลาด CAN บอกแนวโน้มอย่างไร

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

TEC และ REC เป็นสถานะสำหรับจำกัดผลของความผิดพลาด

ตัวควบคุมมีตัวนับฝั่งส่งเรียกว่า TEC และฝั่งรับเรียกว่า REC ค่าจะเพิ่มหรือลดตามเหตุการณ์และกฎของโปรโตคอล จึงไม่ใช่ตัวนับที่เพิ่มหนึ่งทุกครั้งโดยตลอด ระบบใช้ค่าเหล่านี้ประกอบการเปลี่ยนสถานะ เช่น error-active และ error-passive เพื่อจำกัดผลกระทบของโหนดที่พบความผิดพลาด การอ่านค่าต้องดูด้วยว่าตัวควบคุมอยู่ในสถานะใดและกำลังทำหน้าที่ส่งหรือรับในเหตุการณ์ที่สนใจ

ในหลักการทั่วไปเมื่อ TEC หรือ REC ถึงระดับ 128 จะสัมพันธ์กับสถานะ error-passive ส่วน bus-off เกี่ยวกับ TEC ที่เกิน 255 ไม่ใช่การนำตัวนับสองตัวมาบวกกันแล้วเทียบขีดเดียวกัน แต่กฎการเพิ่มลดมีรายละเอียดและข้อยกเว้น จึงไม่ควรย้อนคำนวณจำนวนเหตุผิดพลาดจากผลต่างของตัวนับด้วยการหารค่าคงที่ หากจำเป็นต้องทราบเหตุการณ์จริงควรมีบันทึกชนิดข้อผิดพลาดร่วมด้วย

1. 1
   TEC ฝั่งส่ง

   สะท้อนเหตุการณ์ที่เกี่ยวกับการส่งตามกฎของโปรโตคอล

2. 2
   REC ฝั่งรับ

   สะท้อนเหตุการณ์ที่เกี่ยวกับการรับ จึงมีมุมมองต่างจากฝั่งส่ง

3. 3
   สถานะ ณ เวลาวัด

   อ่านตัวนับพร้อม error-active หรือ error-passive และเวลาที่บันทึก

4. 4
   ระบุเจ้าของ

   ตัวนับในอินเทอร์เฟซเป็นของอินเทอร์เฟซนั้น ไม่ใช่ค่าทุกกล่องบนบัส

ตัวนับเพิ่มลดตามกฎ ไม่ใช่จำนวนเฟรมเสียสะสม และห้ามนำ TEC กับ REC มาบวกเทียบเกณฑ์

ตัวอย่างสมมติของแนวโน้มที่ชวนตรวจฝั่งส่ง

สมมติชุดฝึกอ่านค่าได้จริงจากตัวควบคุม ก ที่เวลาศูนย์มี TEC เท่ากับ 0 และ REC เท่ากับ 0 ผ่านไปหนึ่งช่วงบันทึกพบ TEC 24 และ REC 1 ต่อมามี TEC 16 และ REC 0 รูปนี้บอกว่ามีการเปลี่ยนสภาพทั้งเพิ่มและลดของตัวนับ แต่ยังไม่บอกว่ามีความผิดพลาดสามครั้งหรือได้รับสำเร็จกี่เฟรม เพราะระหว่างจุดอ่านอาจมีหลายเหตุการณ์ที่ชดเชยกันอยู่

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

นำไปใช้สร้างบันทึกที่ไม่ซ่อนเหตุการณ์

1. ตรวจคู่มือว่าเครื่องมืออ่านตัวนับจริงจากตัวควบคุมหรือรายงานค่าประมาณ และตัวนับเป็นของอุปกรณ์ใด
2. บันทึกเวลา TEC REC และสถานะตัวควบคุมร่วมกัน ไม่บันทึกเฉพาะค่าสูงสุด
3. เก็บเหตุการณ์เปลี่ยนสถานะ การเริ่มบันทึกใหม่ และการขาดการเชื่อมต่อของเครื่องมือ เพื่ออธิบายจุดที่ค่ากลับศูนย์
4. เทียบกับจำนวนเฟรมและช่วงการส่งรับ เพราะปริมาณงานต่างกันทำให้การเปรียบเทียบจำนวนดิบมีข้อจำกัด
5. ใช้เหตุการณ์ที่มีเวลาร่วมกันตั้งสมมติฐาน แล้วตรวจหลักฐานที่อาจหักล้างสมมติฐานนั้นด้วย

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

1. 1
   ส่ง 0 รับ 0

   ชุดฝึกอ่าน TEC 0 และ REC 0 ณ จุดเริ่มบันทึก

2. 2
   ส่ง 24 รับ 1

   TEC เพิ่มเด่นกว่าฝั่งรับ แต่ยังไม่ทราบจำนวนเหตุการณ์ระหว่างจุดอ่าน

3. 3
   ส่ง 16 รับ 0

   ค่าลดลงได้ตามกฎ จึงไม่ใช่จำนวนเสียสะสมที่เพิ่มทางเดียว

4. 4
   เทียบช่วงส่ง

   หากเพิ่มเฉพาะตอน ก ส่ง ให้ตรวจเงื่อนไขส่งและ ACK โดยยังไม่ฟันธงภาคส่งเสีย

ห้ามย้อนคำนวณจำนวนเหตุผิดพลาดจากผลต่างตัวนับเพียงอย่างเดียว

ข้อผิดพลาดจากการเทียบตัวนับคนละเครื่อง

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

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

ตรวจสอบผลโดยเทียบการเปลี่ยนแปลงในเงื่อนไขเดียวกัน

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

การเขียนผลอาจระบุว่าในช่วงสังเกตห้านาทีที่มีเงื่อนไขกำหนดไม่พบการเพิ่มตัวนับและไม่พบการเปลี่ยนเป็น error-passive แทนกล่าวว่าปัญหาหมดถาวร หากมีการรีเซ็ตตัวควบคุมระหว่างทดสอบต้องแยกช่วงก่อนหลัง เพราะค่าศูนย์ใหม่ไม่ได้ลบเหตุการณ์เก่าในเชิงหลักฐาน การเก็บเส้นเวลาที่ต่อเนื่องช่วยให้ทีมตรวจรวมมองเห็นเหตุและผลโดยไม่หลงกับตัวเลขสุดท้าย