在上一篇文章中，我們對 10MBit/s 汽車協議 CAN XL 和 10BASE-T1S 做了一些解釋。現在我們將關注潛在的用例以及對硬件和軟件的影響。

一、10Mbit協議應用實例

CAN XL 或 10BASE-T1S 可用作現有 CAN FD 或其他網絡協議的替代品，其中應用要求超過提供的帶寬。還有一些新的用例可以專門使用這些協議。

一個示例是連接麥克風和揚聲器以實現主動降噪、道路降噪或 e-Call 應用。對于這些應用，機艙內放置了多個麥克風和揚聲器。網絡流量處于 CAN FD 無法提供的范圍內。隨著遠離專門為單一應用開發的通信協議的趨勢，OEM 首選更通用的協議，例如 CAN XL 和汽車以太網。圖像

圖 1：音頻示例

以類似的方式，低帶寬要求的傳感器使用現有協議連接，形成按區域或域組織的子網絡。這些子網絡通常通過網關連接到剩余的車載網絡 （IVN），該車載網絡通常使用 100MBit/s 或更高范圍內的以太網連接（圖 2）。

如今，需要將 CAN 消息從一個通道傳輸到另一個通道的網關 ECU 已經是一個復雜的組件。添加提供更多帶寬和更長有效載荷的協議將進一步增加復雜性，并且在使用與今天相同的硬件和軟件策略時需要明顯更高的處理性能。

網關 ECU 應該只轉發消息或 PDU，但不處理數據內容。在實踐中，網關 ECU 修改數據并具有條件轉發規則。未來將避免對網關模塊的這些擴展，以遵循基于消息的通信概念或面向服務的體系結構 （SOA） 的方法。下面我們將基于純消息轉發網關進行討論。圖像

圖 2：網絡層次結構

2. 10MBit 協議的以太網網關功能

分析網關模塊的作用是將消息從一種協議傳輸到另一種協議，而不改變消息的內容。

有兩個因素會影響執行網關操作所需的 CPU 資源。首先，產生需要處理的凈數據速率的有效載荷長度。第二，觸發網關進程的事件率。僅查看總線利用率（總線負載）是不夠的，因為它是總線上的活動和事件率的組合。假設網關 ECU 需要將任何給定協議上游傳輸到以太網接口，則需要三個基本步驟，對這兩個因素具有不同的依賴性：

步驟1：將消息從接收接口傳輸到內存中。CPU 資源利用率取決于在一個時間間隔內要傳輸的數據量，與總線上有很多短幀還是少數長幀無關。然而，凈數據速率決定了這項任務。

步驟 2：構造目標以太網消息。如果源協議已經是以太網消息（例如，10BASE-T1S），簡單的交換功能就足夠了。如果源協議不是以太網，則依賴于協議的入口報頭必須由以太網報頭替換。如果例如使用具有較低有效載荷長度的協議并且在將傳輸協議提供給上游接口之前應將其刪除，則此任務可能非常復雜。CPU 負載取決于處理的有效負載大小以及事件率。

步驟 3：使構建的以太網消息可用于目標接口并啟動傳輸。假設以太網接口對內存中的指針進行操作，傳輸的事件率決定了所需的 CPU 負載。

圖 3：網關運行性能

圖 3 顯示了一個簡單的 CAN FD、CAN XL 和 10BASE-T1S 到以太網網關的超過 1 秒的累積 CPU 處理時間，用于 50% 的總線負載和 256 字節的有效負載。

從所需的處理時間來看，10BASE-T1S 似乎需要比 CAN XL 更多的 CPU 時間來處理總線上的流量。事實上，每個有效負載需要相同數量的處理時間。從網絡數據速率我們可以看出，10BASE-T1S 比 CAN XL 高 30% 左右。10BASE-T1S 的處理時間在同一地區與 CAN XL 不同。在查看處理時間相對較短但凈數據速率非常低的 CAN FD 時，必須考慮同樣的因素。

從今天的網關應用和 ECU 設計可以明顯看出，在當前的事件和數據速率下，延遲要求很難滿足。隨著協議提供更多帶寬，實現目標將更加困難。假設連接了多個 CAN 和以太網通道，在相同總線負載的情況下，處理時間比現在高 3 到 4 倍。需要開發解決方案來克服這種情況。

3. 軟硬件網關優化

查看圖表，已經顯示了最明顯的解決方案；消除將數據從 CPU 移動到內存的負擔。這不是典型的 CAN 方法。傳統上，CAN 使用本地 IP 存儲器作為本地發送和接收緩沖區。這對于經典 CAN 來說是可以接受的，對于 CAN FD 來說是可以接受的。隨著有效載荷數量的增加和更高的數據速率，這種方法將會改變。CAN 的幾種實現方式已經允許通過需要編程和配置的系統 DMA 進行數據傳輸。這種方法很少使用，因為 DMA 很難在 Autosar 環境中使用。將來，DMA 功能將成為 IP 的一部分，對軟件完全透明。接收到的數據“出現”在定義的系統內存中的 FIFO 和緩沖區中，并且可以直接訪問；傳輸數據相同。這一概念已經用于瑞薩的以太網接口，并將擴展到 CAN XL 協議控制器。這種簡單增強的效果如圖 5 所示。

路由過程中需要注意的第二個過程是傳入 CAN XL/10BASE-T1S 消息和傳出 100BASE-T1 消息之間的緩沖區處理和信息交換過程。

一個典型的、面向層的實現將提供兩個進程（圖 4 左側），其中傳入進程從其接收緩沖池中保留一個緩沖區，并在緩沖區填滿后通知傳出消息進程有關待傳輸的未決消息。由于獨立的結構和處理，接收到的消息需要轉移到新分配的緩沖區中進行進一步處理。為了構造傳出消息，必須準備一個新的傳輸頭，并且需要在頭之后將接收緩沖區中的數據復制到新緩沖區。在這個復制操作之后，原始緩沖區可以被傳入消息進程釋放。傳輸完成后，分配的傳輸緩沖區將被釋放回用于傳出消息的池中。

這種方法有兩個主要缺點。首先，即使在像這里這樣的情況下，當在繼續之前沒有依賴或等待條件時，也必須盡量減少進程間通信。其次，指針操作應該優先于數據復制操作。

圖 4：框架組裝流程

圖 4 的右側以簡化的過程顯示為復雜的設備驅動程序，其中傳入和傳出通信接口共享一個公共緩沖區池。這消除了雙重分配和釋放緩沖區以及進程間通信的需要。Renesas 的以太網通信接口中的擴展指針操作支持允許靈活地創建以太網消息而無需任何復制操作，并支持使用報頭模板。這種結構還允許聚合來自傳入接口的消息，排列它們，并輕松創建以太網消息，例如遵循 IEEEE 1722 隧道協議。

圖 5 顯示了優化硬件和軟件時對 CPU 利用率的影響。瑞薩電子準備了一個演示集，其中 CAN XL 和 10BASE T1S 被傳輸到 100BASE-T1 以太網骨干網。為了簡化和比較的公平性，CAN XL 的有效負載已經包含一個 IPv4 標頭。因此，CAN XL 的網關功能在添加以太網 L2 報頭時減少。對于 10BASE-T1S，只實現了軟件開關的功能。

在圖的最左側，我們看到沒有任何優化的 CPU 處理時間。

在中間部分，DMA傳輸用于將數據從通信接口傳輸到系統內存。新消息的創建仍然是通過復制操作和動態標頭創建來完成的。

在圖的右側，我們使用優化的軟件流程，使用一個復雜的驅動程序，該驅動程序使用一個公共緩沖池和用于標頭模板和有效負載數據的指針操作。

圖 5：優化效果

4 結論

10MBit 通信協議會給網關 CPU 帶來額外的負載。通過巧妙的軟件方法和硬件特性，所需的 CPU 性能不會隨著帶寬和凈數據速率的增加而增加。

Renesas 的以太網通信接口提供自動數據傳輸并支持指針操作，以便在系統內存中進行復雜的消息組合。下一代 CAN XL 接口將朝著相同的方向發展。

10BASE-T1S 和 CAN XL 都將擁有它們主導的應用領域。它們由值得信賴的標準化機構開發，并在提供產品和解決方案的行業中擁有包括瑞薩在內的支持者。

審核編輯：郭婷