ระบบสื่อสารยานยนต์

ตรวจความเข้ากันได้ก่อนใช้เครื่องมือกับ CAN FD

แยกความสามารถซอฟต์แวร์ ตัวควบคุม ภาครับส่ง และชุดสาย พร้อมตัวอย่างอ่านเฟรมสั้นได้แต่ยังไม่ยืนยันการรองรับ FD ครบ

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

ความเข้ากันได้มีหลายชั้น

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

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

ภาพอธิบาย 1ตรวจความสามารถตลอดชุดเครื่องมือ
  1. ตัวควบคุม

    ต้องเข้าใจรูปแบบ FD ไม่ใช่เปลี่ยนเฉพาะภาครับส่งแล้วจะรองรับ

  2. ภาครับส่งและสาย

    ต้องเหมาะกับเวลาและแรงดันที่เครือข่ายใช้ตามข้อกำหนด

  3. ซอฟต์แวร์และไฟล์

    เปิดช่องถูกโหมดและรักษาธงกับข้อมูลเกินแปดไบต์ได้ครบ

การมีเมนู CAN FD ในโปรแกรมยังไม่ยืนยันฮาร์ดแวร์และไฟล์ปลายทาง

ตัวอย่างสมมติที่การอ่านแปดไบต์ยังพิสูจน์ไม่ครบ

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

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

นำไปใช้ตรวจชุดเครื่องมือก่อนเชื่อม

  1. ระบุจากเอกสารเครือข่ายว่าต้องรองรับ Classical หรือ FD รูปแบบใด และมีการสลับอัตราบิตหรือไม่
  2. ตรวจตัวควบคุม ภาครับส่ง รุ่นฮาร์ดแวร์ และไดรเวอร์ที่ผู้ผลิตระบุ ไม่สรุปจากหัวต่อที่เสียบกันได้
  3. ตรวจอัตราบิต nominal และ data รวมถึงรูปแบบ ISO หรือ non-ISO ที่เกี่ยวข้อง
  4. ตรวจความสามารถฟังโดยไม่ส่ง ตัวจบสาย และสายต่อที่เพิ่มให้ตรงกับสภาพเครือข่าย
  5. ใช้ไฟล์หรือชุดฝึกที่มีข้อมูลหลายขนาดตรวจการแสดงและส่งออก ก่อนเชื่อมเพื่อวิเคราะห์รถตามวิธีอนุญาต

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

ภาพอธิบาย 2รับได้แต่ส่งออกขาดในชุดฝึก
  1. รับ 32 ไบต์

    ฮาร์ดแวร์ชุดฝึกรับเฟรม FD สามสิบสองไบต์ได้

  2. เก็บเพียง 8

    ตัวส่งออกเก่าจำกัดข้อมูลไว้แปดไบต์แม้ยังแสดงธง FD

  3. ขาด 24 ไบต์

    32 − 8 = 24 ไบต์ ปัญหาอยู่ทางส่งออก ต้องเก็บข้อมูลเดิมครบ ไม่เติมศูนย์แทน

ตัวอย่างแยกปัญหาหลังรับออกจากความผิดพลาดบนคู่สาย

ข้อผิดพลาดของการดูเพียงความเร็วสูงสุด

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

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

ตรวจสอบผลตลอดทางจากเฟรมถึงไฟล์

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

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

แหล่งอ้างอิงและอ่านเพิ่มเติม

เรียบเรียงคำอธิบายและตัวอย่างขึ้นใหม่จากหลักการในแหล่งข้อมูลต่อไปนี้

  1. CAN FD Protocol Tutorial · Kvaser
  2. Supporting CAN FD and the non-ISO version · Kvaser
  3. Kvaser SDK migration from CAN CLASSIC to CAN FD · Kvaser

เล่มที่ลงลึกเรื่องนี้

อ่านต่อเรื่องใกล้กัน

ถามเรื่องหนังสือ ตะกร้า