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