DLC ของ CAN FD เหตุใดจึงไม่เท่าจำนวนไบต์เสมอไป

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

DLC เป็นรหัสความยาว ไม่ใช่ตัวนับทั่วไป

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

• DLC 9 แทนฟิลด์ข้อมูล 12 ไบต์ และ DLC 10 แทน 16 ไบต์
• DLC 11 แทน 20 ไบต์ และ DLC 12 แทน 24 ไบต์
• DLC 13 แทน 32 ไบต์ และ DLC 14 แทน 48 ไบต์
• DLC 15 แทน 64 ไบต์ โดยค่าศูนย์ถึงแปดยังคงตรงกับจำนวนไบต์

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

1. 1
   รหัส DLC

   รหัสมากกว่าแปดต้องแปลงตามตาราง เช่นรหัส 9 แทน 12 ไบต์

2. 2
   ฟิลด์บนสาย

   เก็บข้อมูลครบตามความยาวที่ถอดจาก DLC ไม่ตัดตามค่ารหัสดิบ

3. 3
   ข้อมูลใช้งาน

   เอกสารแอปพลิเคชันระบุว่าไบต์ใดมีความหมายและไบต์ใดเป็นส่วนเติม

อย่าสับสนรหัสดิบ จำนวนไบต์บนสาย และส่วนข้อมูลที่แอปพลิเคชันใช้

ตัวอย่างสมมติเมื่อข้อมูลมีความหมายเพียงสิบไบต์

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

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

นำไปใช้ตรวจความครบของไฟล์บันทึก

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

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

1. 1
   ต้องใช้ 10 ไบต์

   แอปพลิเคชันสมมติต้องการข้อมูลสิบไบต์ในเฟรมเดียว

2. 2
   เลือก DLC 9

   ขนาดที่รองรับถัดไปคือสิบสองไบต์ จึงเหลือสองไบต์ตามข้อตกลงส่วนเติม

3. 3
   ใช้พื้นที่ 83.33%

   10 หาร 12 คูณ 100 ประมาณ 83.33 เปอร์เซ็นต์ เฉพาะฟิลด์ข้อมูล

4. 4
   อย่าอ่านแค่ 9

   หากใช้รหัส DLC เป็นจำนวนไบต์จะตัดฟิลด์จริงทิ้งสามไบต์

ตัวอย่างสมมติแสดงทั้งความผิดพลาดเมื่อตัดข้อมูลและสัดส่วนที่คำนวณได้

คำนวณประสิทธิภาพโดยระบุสิ่งที่นับ

สำหรับตัวอย่างสิบไบต์ในฟิลด์สิบสองไบต์ สัดส่วนข้อมูลที่มีความหมายต่อฟิลด์ข้อมูลเท่ากับ 10 หาร 12 คูณ 100 ประมาณ 83.33 เปอร์เซ็นต์ ค่านี้ไม่ใช่ประสิทธิภาพการใช้บัส เพราะยังไม่ได้รวมส่วนหัว CRC และเวลารอ หากอีกแอปพลิเคชันต้องใช้ 33 ไบต์ในเฟรมเดียว ขนาดที่เลือกได้ถัดไปคือ 48 ไบต์ ส่วนเกินจึงมี 15 ไบต์ และสัดส่วนเฉพาะฟิลด์ข้อมูลคือ 33 หาร 48 เท่ากับ 68.75 เปอร์เซ็นต์

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

ข้อจำกัดของส่วนเติมและพื้นที่เก็บในตัวควบคุม

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

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

ตรวจสอบผลด้วยการย้อนจากไฟล์กลับไปยังเฟรม

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