1. 更高、更快、更遠、更慢

在我們的日常生活、運動、技術發展中，一切都是為了讓事情變得更好、更快或更進一步。很難記住發明比以前慢的東西被稱為創新，但這正是汽車以太網所發生的事情。

圖 1：以太網和 CAN 規范路線圖

第一個 100MBit/s 和 1000MBit/s 版本已成功開發并推向市場，其物理層允許自動協商以簡化系統集成。在過去十年末，開發了僅支持 10MBit/s 的汽車以太網版本，其物理層與 100MBit/s 和 1GBit/s 版本不兼容；業績明顯下降。

OEM 要求退回到較舊的拓撲樣式和較低的速度，以縮小較低速度等級應用在每個以太網端口成本方面的性能差距。CAN FD 當時支持 2MBit/s，并隨著時間的推移提高到 5MBit/s。CAN 周圍的社區也看到了對更高帶寬和更長有效載荷的需求，并開始開發一種改進的 CAN 標準，稱為 CAN XL。

在第一部分中，我們將簡要概述 CAN XL 和 10MBit/s 以太網，它們之間有什么區別。在第二部分中，我們描述了潛在的用例以及對硬件和軟件的影響。

2. 10MBit汽車協議

甚至 CAN XL 和 10BASE-T1S 也是在不同的標準化機構中開發的，在業界的廣泛支持下，過程幾乎相同。

圖2：標準開發方案

CAN XL 技術工作的基礎是在 CAN in Automation （CiA） 中完成的。在穩定文件后，它被移交給 ISO 以創建一個國際標準。這一過程仍在進行中，預計將于 2023 年完成，并獲得批準的國際標準。CiA 將作為技術委員會和用戶聯盟繼續推動 CAN 標準。

以太網規范由 IEEE 擁有和維護。所有標準化工作都是在一個工作組內完成的，該工作組創建了 2019 年草案，以納入 IEEE 802.3 主要標準。由于 IEEE 是一個獨立于行業的組織，OPEN 聯盟負責擴展汽車要求的規范。對于 OPEN Alliance 規范的長期維護，還涉及 ISO。

2.1 CAN XL – 更高的速度、更多的有效載荷和附加功能

盡管 CAN XL 為 CAN FD 提供了完全的向后兼容性，但幀格式已得到廣泛更新。在這篇文章中，我將介紹主要差異并概述新領域的意圖。在以后的文章中，我們將介紹更多細節，包括更新的位時序更改、位填充和錯誤信號通知規則。

CAN XL 遵循 CAN FD 的概念，具有低速仲裁階段（最高 1MBit/s）和高速數據階段。CAN XL 數據階段位時間被指定為高達 10MBit/s。CAN XL 的另一個關鍵特性是有效載荷長度可達 2048 字節。此外，CAN XL 完全向后兼容 CAN FD。

圖 3：CAN XL 幀格式

圖 3 顯示了 CAN XL 幀格式，命名了不同的字段區域，并指出了標稱位時間的使用位置以及高速位時間的開始位置。簡要說明了關鍵更改之后 - 如您所見，幾乎所有內容都已更新。

優先級 ID——這個 11 位長的字段是以前稱為“基本標識符”的字段。CAN XL 在第一個仲裁字段中僅支持 11 位。

IDE——僅僅因為不支持標識符擴展，該位總是作為顯性位傳輸。

XLF ， resXL – 這兩位（XLF 為隱性，resXL 為顯性）編碼后一幀為 CAN XL 數據幀。

廣告– “仲裁到數據序列”是從標稱數據位時間切換到 XL 數據位時間發生的點。與在單個位中完成更改的 CAN-FD 相比，CAN XL 中的轉換需要更長的時間以增加此敏感過程的穩健性，從而允許收發器更改為快速模式，其中 TX 節點可以在推/拉模式下運行。

SDT—— “服務數據單元類型”是描述有效載荷類型的上層信息。該字段相當于以太網協議中的 EtherType。SDT 由 CiA 611-1 定義。

SEC——該位指示幀是否在有效負載中包含簡單或擴展內容，并且是從上層提供的。

DLC– 數據長度代碼字段與之前版本的含義相同。使用這個 11 位長的字段，指示從 1 字節到 2048 字節的數據字段。

SBC – 填充比特計數字段提供有關仲裁字段中動態填充比特數量的信息。在后面的文章中，我們將詳細介紹 stuff bit 規則。該值將由協議控制器計算。

PCRC – 前言 CRC 字段是根據迄今為止解釋的仲裁字段和控制字段中的大多數位計算得出的 CRC。目的是獲得對標頭信息的額外保護。

VCID—— “虛擬 CAN 網絡 ID”應該支持 CAN 總線上的虛擬化，就像以太網網絡中的 VLAN 概念一樣。

自動對焦– 接受字段，也由上層提供，是用于幀分類的附加 32 位，可以看作是對降低的優先級標識符字段的補償。

數據字段——在該字段中，實際有效載荷由上層提供，其中字節編號從 0 到 DLC。

FCRC – 幀 CRC 是根據目前看到的所有動態比特計算的

FCP – 格式檢查模式允許接收器確認他仍然與發送器在比特流上同步，并宣布 CAN XL 數據階段結束。這是對該領域的一個非常簡單的解釋。

DAS——在數據到仲裁序列中，比特率從 XL 數據比特時間切換到標稱比特時間。

ACK/EOF – 幀以已知的確認時隙和 EOF 序列結束，其格式沒有改變。

在媒體訪問方案上，與以前的 CAN 版本相比沒有變化，CAN XL 仍然遵循 CSMA/CR 原則。

2.2 10BASE-T1

在對 CAN XL 說了很多話之后，讓我們看看 10MBit 汽車以太網，準確地說，是 IEEE 802.3cg 中定義的 10 MBit/s 單對以太網 （SPE）。10MBit SPE 的 MAC 層協議與其他以太網協議沒有區別，無需進一步解釋。

圖 4：IEEE 802.3cg ［4］ 的范圍

相反，IEEE 定義了一個物理層，以滿足汽車行業在穩健性、實施成本和布線方面的需求。結果是具有不同應用目標的兩個不同物理層。

10BASE-T1L – 這是 10MBit/s SPE 的“長距離”變體，允許長達 1000 米的電纜長度。這種點對點變體超出了汽車應用的范圍，但可用于卡車、火車和其他車輛技術。

10BASE-T1S – 這是“短距離”變體，電纜長度可達 25 米，并允許使用 10 厘米短截線的總線拓撲結構。為了避免共享總線拓撲上的沖突，該標準定義了一個可選的協調子層，稱為 PLCA（物理層沖突避免）。

PLCA ——PLCA 的目標是在吞吐量、延遲和公平性方面改進多點（總線）拓撲上以太網 （CSMA/CD） 中現有的沖突檢測機制。重要的是要知道這種“仲裁”純粹發生在 PHY 級別，MAC 在以下描述的過程中不發揮任何作用。

圖 5：PLCA 循環示例 ［2］

在 PLCA 系統中，每個 PHY 都分配有一個唯一的 PHY ID，范圍從 0 到 255。ID 為 0 的 PHY 是 PLCA 協調器。總線上的每個 PHY 都知道 PHY 的數量。PLCA 使用循環方案，其中每一輪都由 PLCA 協調器發送一個信標來觸發。PLCA 方案中的每個參與者，包括協調器，在 BEACON 之后按照 PHY ID 的順序都有一個傳輸機會。

傳輸機會只是一個機會。如果一個節點沒有要傳輸的東西，系統中的下一個 PHY 會在超時時間之后獲得他的機會。如果一個節點有一個傳輸掛起，它被允許在他的傳輸機會內開始傳輸一個幀。如果系統配置允許，一個節點還可以傳輸多個幀，即所謂的突發。它們每條消息的有效負載長度可以不同。

這種調度方案避免了總線沖突和重新傳輸，從而降低了可用帶寬并保證了系統內傳輸機會的公平性。在此 PLCA 機制之上，可以在 MAC 層啟用其他整形功能，例如 Credit Base 整形或 Time Aware Shaping。

3. CAN XL 和 10BASE-T1S 之間的比較——獲勝者是……

贏家是用戶。兩種協議都提供允許應用程序傳輸更長有效載荷并在總線上實現接近 10Mbit/s 的傳輸速度的數據速率。甚至媒體訪問方案都不一樣，我們分兩種方式來比較。

3.1 數據報效率

兩種協議在數據報中都有報頭和報尾形式的開銷（例如尋址、協議字段、CRC）。在 CAN XL 中，效率進一步受到仲裁階段和數據階段填充位和不同總線速度的影響。

圖 6：數據報效率比較

圖 6通過將開銷上的花費與有效載荷位上花費的時間相比較，繪制了數據報在有效載荷上的效率。

CAN XL 受到較慢的仲裁階段和更大的報頭和更多開銷位的影響。以 1MBit/s 而不是 500kBit/s 運行仲裁階段可以顯著提高較短幀的數據報效率。有人可能會完美地爭辯說，在 CAN XL 中，協議類型和接受字段是用戶日期而不是開銷。這將使 CAN XL 更接近 10BASE-T1S 的曲線。

3.2 總線循環效率

如果我們觀察 PLCA 循環而不是單個數據報，情況正在發生變化。

圖 7：PLCA 循環示例

讓我們假設系統配置如圖 7 所示，并假設只有 PHY 9 有未決傳輸。在這種情況下，總線保持未使用狀態的時間是超時時間的 9 倍，在這種情況下我們假設為 24 位。此外，BEACON 所需的額外時間，效率變化如圖 8 所示。

圖 8：總線循環效率示例

在 CAN XL 中，等待任何傳輸機會不會降低總線效率，但仍需要考慮空閑時間和 EOF 序列。然而，在 512 字節有效載荷的典型操作條件下，兩種協議顯示出相同的效率。

四、結論與展望

這兩種協議都是為了處理新 E/E 架構的要求而開發的，并在 10MBit/s 區域提供預期的性能。除了這里簡要解釋的協議字段之外，在更高級別協議的可用性方面還有其他一些增強，例如，安全性或功率傳輸的考慮。

協議的效率取決于用例、系統配置和擴展功能的使用。更喜歡哪種變體更像是一個哲學或戰略問題。從我們的角度來看，這兩種協議都有可能在不同應用中的相同車載網絡 （IVN） 中使用。

審核編輯：郭婷