เมื่อข้อมูลบนเครือข่าย CAN มาถึงช้ากว่าที่คาด คำถามแรกไม่ควรมีเพียงว่าสายขาดหรือกล่องเสีย เพราะข้อความอาจเตรียมพร้อมแล้วแต่ยังรอโอกาสใช้บัสอยู่ การตัดสินสิทธิ์ส่งเรียกว่า arbitration เป็นกลไกที่ทำให้หลายโหนดใช้คู่สายร่วมกันได้โดยไม่ต้องมีผู้ควบคุมคอยเรียกทีละตัว บทความนี้อธิบายหลักการในเครือข่ายที่ตั้งค่าอย่างถูกต้อง แล้วใช้สถานการณ์สมมติเพื่อแยกการรอปกติออกจากความผิดพลาด โดยไม่กำหนดรหัสข้อความของรถจริง
ผู้ส่งเปรียบเทียบสิ่งที่ส่งกับสิ่งที่ปรากฏบนบัส
ในช่วงตัดสินสิทธิ์ โหนดที่กำลังส่งจะอ่านระดับบนบัสด้วย ถ้าโหนดหนึ่งปล่อยบิต recessive แต่พบว่าบัสเป็น dominant แสดงว่ามีผู้ส่งอีกตัวมีสิทธิ์เหนือกว่าในตำแหน่งนั้น โหนดแรกจึงเลิกแข่งขันและเปลี่ยนเป็นผู้รับ ส่วนข้อความที่ชนะเดินหน้าต่อได้ กลไกนี้ทำงานทีละบิตตามลำดับที่ส่งออกมา ไม่ใช่การส่งข้อความทั้งหมดให้ชนกันแล้วสุ่มเวลาลองใหม่ หลักการดังกล่าวช่วยอธิบายว่าทำไมผู้แพ้สิทธิ์จึงไม่เท่ากับผู้สร้างเฟรมผิดพลาด
คำว่าลำดับความสำคัญเป็นคุณสมบัติของข้อความที่แข่งขันในครั้งนั้น ไม่ใช่ตำแหน่งถาวรของกล่องหนึ่งบนรถ กล่องเดียวอาจมีหลายข้อความที่มีสิทธิ์ต่างกัน การกล่าวว่ารหัสตัวเลขต่ำชนะใช้ได้เมื่อเปรียบเทียบรูปแบบที่เหมาะสม แต่เมื่อมีเฟรมฐาน เฟรมขยาย หรือชนิดเฟรมต่างกัน ต้องดูบิตในส่วน arbitration ที่ส่งจริงด้วย การอ่านบันทึกจึงควรเก็บชนิดเฟรมประกอบ หลีกเลี่ยงจัดอันดับจากตัวเลขที่หน้าจอแสดงเพียงช่องเดียว
- เริ่มส่งพร้อมกัน
โหนด ก และ ข พบว่าบัสว่างและเริ่มส่วนตัดสินสิทธิ์
- อ่านขณะส่ง
ข ส่ง recessive แต่พบบัสเป็น dominant จึงทราบว่ามีข้อความสิทธิ์สูงกว่า
- เปลี่ยนเป็นผู้รับ
ข หยุดแข่งขัน ส่วน ก ส่งเฟรมต่อ การแพ้สิทธิ์ไม่ใช่เฟรมผิดพลาด
ผู้แพ้การตัดสินสิทธิ์เปลี่ยนเป็นผู้รับ โดยเฟรมของผู้ชนะเดินหน้าต่อ
ตัวอย่างสมมติของการรอที่ไม่ใช่ความเสียหาย
สมมติชุดฝึกแรงดันต่ำมีข้อความ ก และ ข พร้อมเริ่มหลังบัสว่างพร้อมกัน โดยกำหนดให้ ก ชนะตามส่วนตัดสินสิทธิ์ ข จึงรอ สมมติจากบันทึกที่วัดจริงในชุดฝึก ก ใช้เวลา 0.24 มิลลิวินาที และมีช่วงเว้นก่อนเริ่มข้อความถัดไป 0.006 มิลลิวินาที หากไม่มีข้อความอื่นแทรก ข จะเริ่มได้หลังจากนั้นประมาณ 0.246 มิลลิวินาที ตัวเลขนี้เป็นเพียงเงื่อนไขของตัวอย่าง ไม่ใช่ระยะเวลาคงที่ของเฟรม CAN ทุกแบบ
หากโปรแกรมผู้รับต้องเห็น ข ภายใน 0.20 มิลลิวินาที เงื่อนไขสมมตินี้ทำให้ส่งไม่ทันได้แม้ไม่มีข้อผิดพลาดทางไฟฟ้าเลย แต่ถ้าเวลาที่กำหนดคือ 2 มิลลิวินาที การรอรอบเดียวนี้ยังไม่ทำให้พลาดกำหนด ประเด็นจึงอยู่ที่ความสัมพันธ์ระหว่างเวลาที่อนุญาตกับเวลารอจริง ไม่ใช่แค่มองว่า ข ช้ากว่า ก ทั้งนี้ยังต้องรวมเวลาที่ข้อมูลรอในโปรแกรมต้นทางและเวลาประมวลผลปลายทางก่อนตัดสินผลทั้งระบบ
นำไปใช้แยกเวลารอออกจากเวลาส่ง
- เริ่มจากนิยามอาการให้วัดได้ เช่น ช่วงห่างของข้อความยาวขึ้น หรือข้อมูลถึงผู้ใช้ช้า ทั้งสองอย่างไม่ใช่ตัววัดเดียวกัน
- อ่านบันทึกที่มีเวลา ชนิดเฟรม และสถานะข้อผิดพลาด โดยตรวจว่าฮาร์ดแวร์กำหนดเวลา ณ ต้นเฟรมหรือปลายเฟรม
- ทำเครื่องหมายข้อความที่ครองบัสก่อนข้อความที่สนใจ แล้วเปรียบเทียบช่วงปกติกับช่วงที่เกิดอาการ
- หากมีบันทึกจากโปรแกรมต้นทาง ให้เทียบเวลาที่ข้อมูลพร้อมส่งกับเวลาที่ปรากฏบนบัส เพื่อแยกคิวในซอฟต์แวร์ออกจากการรอสิทธิ์
- สรุปเฉพาะสิ่งที่ข้อมูลรองรับ หากมีเพียงบันทึกบนสาย ให้รายงานช่วงที่เห็นข้อความ ไม่สรุปเวลาที่ต้นทางเริ่มสร้างข้อมูล
วิธีนี้มีประโยชน์เมื่อพบอาการเฉพาะช่วงข้อมูลหนาแน่น ตัวอย่างเช่นบันทึกสมมติแสดงว่าข้อความ ข มาช้าทุกครั้งที่มีชุดข้อความอื่นอยู่ก่อนหน้า แต่ไม่มีเฟรมผิดพลาดเพิ่ม ความสัมพันธ์นี้สนับสนุนให้ตรวจตารางการส่งและคิวก่อน อย่างไรก็ตามบันทึกจากจุดเดียวอาจไม่เห็นทุกฝั่งของเกตเวย์ และคำว่าไม่มีข้อผิดพลาดต้องหมายถึงเครื่องมือรองรับการรายงานข้อผิดพลาดชนิดนั้นจริง ไม่ใช่เพียงหน้าจอซ่อนข้อมูลไว้
- ก ใช้บัส
เฟรม ก ครองบัส 0.24 มิลลิวินาทีในตัวอย่าง
- เว้นก่อนส่ง
เพิ่มช่วงเว้น 0.006 มิลลิวินาที เมื่อไม่มีข้อความอื่นแทรก
- ข เริ่มได้
รวมรอ 0.246 มิลลิวินาที จึงเกินกำหนดสมมติ 0.20 มิลลิวินาทีแม้ไม่มีข้อผิดพลาดทางไฟฟ้า
คำนวณจากเวลาเฟรมและช่วงเว้นที่สมมติในบทความ ไม่ใช่ค่าคงที่ของ CAN
ข้อผิดพลาดในการตีความลำดับความสำคัญ
ลำดับความสำคัญสูงไม่ได้ทำให้ข้อความตัดกลางเฟรมที่กำลังส่งอยู่ หากข้อความเร่งด่วนพร้อมหลังอีกเฟรมเริ่มแล้วก็ยังมีเวลารอส่วนที่เหลือ ขณะเดียวกันภาระบัสเฉลี่ยต่ำไม่ได้รับประกันว่าจะไม่มีช่วงรอสั้น ๆ ที่ยาวเกินข้อกำหนด เพราะข้อความอาจมารวมกันเป็นชุด การดูค่าเฉลี่ยหนึ่งวินาทีจึงอาจกลบเหตุการณ์ที่กินเวลาเพียงเศษมิลลิวินาที ต้องเลือกช่วงวิเคราะห์ให้สัมพันธ์กับเวลาที่ระบบต้องตอบสนอง
อีกความเข้าใจผิดคือใช้ชื่อกล่องหรือความสำคัญต่อผู้ขับมาทำนายสิทธิ์ส่งทันที เราไม่ทราบการกำหนดลำดับของผู้ผลิตจากชื่ออุปกรณ์ และไม่ควรแก้รหัสข้อความเพื่อให้ข้อมูลของตนแทรกก่อนในรถจริง การแก้เช่นนั้นกระทบทั้งตัวกรองและความหมายในชั้นแอปพลิเคชัน บทความนี้ใช้สำหรับอ่านหลักฐานและวางคำถามตรวจสอบ ไม่ใช่แนวทางปรับตารางการสื่อสารหรือฉีดข้อความเข้าระบบรถ
ตรวจสอบผลด้วยลำดับเหตุที่ทำซ้ำได้
การยืนยันสมมติฐานควรเปรียบเทียบช่วงการทำงานที่มีเงื่อนไขใกล้กัน ระบุจำนวนเหตุการณ์ที่พบและช่วงเวลารอสูงสุดที่สังเกตได้ หากข้อความช้าเกิดพร้อมการเพิ่มเฟรมผิดพลาด การอธิบายด้วยการรอสิทธิ์อย่างเดียวไม่เพียงพอ ในทางกลับกันถ้าพบว่าข้อมูลเริ่มปรากฏบนบัสช้าตั้งแต่ก่อนช่วงใช้งานหนาแน่น ควรย้อนตรวจเวลาสร้างข้อมูล การบันทึกเก็บทั้งเหตุการณ์ที่สนับสนุนและเหตุการณ์ที่ขัดแย้งจะช่วยไม่ให้ติดอยู่กับข้อสรุปแรก
