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

一、10Mbit協(xié)議應(yīng)用實例

CAN XL 或 10BASE-T1S 可用作現(xiàn)有 CAN FD 或其他網(wǎng)絡(luò)協(xié)議的替代品，其中應(yīng)用要求超過提供的帶寬。還有一些新的用例可以專門使用這些協(xié)議。

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

圖 1：音頻示例

以類似的方式，低帶寬要求的傳感器使用現(xiàn)有協(xié)議連接，形成按區(qū)域或域組織的子網(wǎng)絡(luò)。這些子網(wǎng)絡(luò)通常通過網(wǎng)關(guān)連接到剩余的車載網(wǎng)絡(luò) （IVN），該車載網(wǎng)絡(luò)通常使用 100MBit/s 或更高范圍內(nèi)的以太網(wǎng)連接（圖 2）。

如今，需要將 CAN 消息從一個通道傳輸?shù)搅硪粋€通道的網(wǎng)關(guān) ECU 已經(jīng)是一個復(fù)雜的組件。添加提供更多帶寬和更長有效載荷的協(xié)議將進一步增加復(fù)雜性，并且在使用與今天相同的硬件和軟件策略時需要明顯更高的處理性能。

網(wǎng)關(guān) ECU 應(yīng)該只轉(zhuǎn)發(fā)消息或 PDU，但不處理數(shù)據(jù)內(nèi)容。在實踐中，網(wǎng)關(guān) ECU 修改數(shù)據(jù)并具有條件轉(zhuǎn)發(fā)規(guī)則。未來將避免對網(wǎng)關(guān)模塊的這些擴展，以遵循基于消息的通信概念或面向服務(wù)的體系結(jié)構(gòu) （SOA） 的方法。下面我們將基于純消息轉(zhuǎn)發(fā)網(wǎng)關(guān)進行討論。圖像

圖 2：網(wǎng)絡(luò)層次結(jié)構(gòu)

2. 10MBit 協(xié)議的以太網(wǎng)網(wǎng)關(guān)功能

分析網(wǎng)關(guān)模塊的作用是將消息從一種協(xié)議傳輸?shù)搅硪环N協(xié)議，而不改變消息的內(nèi)容。

有兩個因素會影響執(zhí)行網(wǎng)關(guān)操作所需的 CPU 資源。首先，產(chǎn)生需要處理的凈數(shù)據(jù)速率的有效載荷長度。第二，觸發(fā)網(wǎng)關(guān)進程的事件率。僅查看總線利用率（總線負載）是不夠的，因為它是總線上的活動和事件率的組合。假設(shè)網(wǎng)關(guān) ECU 需要將任何給定協(xié)議上游傳輸?shù)揭蕴W(wǎng)接口，則需要三個基本步驟，對這兩個因素具有不同的依賴性：

步驟1：將消息從接收接口傳輸?shù)絻?nèi)存中。CPU 資源利用率取決于在一個時間間隔內(nèi)要傳輸?shù)臄?shù)據(jù)量，與總線上有很多短幀還是少數(shù)長幀無關(guān)。然而，凈數(shù)據(jù)速率決定了這項任務(wù)。

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

步驟 3：使構(gòu)建的以太網(wǎng)消息可用于目標接口并啟動傳輸。假設(shè)以太網(wǎng)接口對內(nèi)存中的指針進行操作，傳輸?shù)氖录蕸Q定了所需的 CPU 負載。

圖 3：網(wǎng)關(guān)運行性能

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

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

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

3. 軟硬件網(wǎng)關(guān)優(yōu)化

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

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

一個典型的、面向?qū)拥膶崿F(xiàn)將提供兩個進程（圖 4 左側(cè)），其中傳入進程從其接收緩沖池中保留一個緩沖區(qū)，并在緩沖區(qū)填滿后通知傳出消息進程有關(guān)待傳輸?shù)奈礇Q消息。由于獨立的結(jié)構(gòu)和處理，接收到的消息需要轉(zhuǎn)移到新分配的緩沖區(qū)中進行進一步處理。為了構(gòu)造傳出消息，必須準備一個新的傳輸頭，并且需要在頭之后將接收緩沖區(qū)中的數(shù)據(jù)復(fù)制到新緩沖區(qū)。在這個復(fù)制操作之后，原始緩沖區(qū)可以被傳入消息進程釋放。傳輸完成后，分配的傳輸緩沖區(qū)將被釋放回用于傳出消息的池中。

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

圖 4：框架組裝流程

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

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

在圖的最左側(cè)，我們看到?jīng)]有任何優(yōu)化的 CPU 處理時間。

在中間部分，DMA傳輸用于將數(shù)據(jù)從通信接口傳輸?shù)较到y(tǒng)內(nèi)存。新消息的創(chuàng)建仍然是通過復(fù)制操作和動態(tài)標頭創(chuàng)建來完成的。

在圖的右側(cè)，我們使用優(yōu)化的軟件流程，使用一個復(fù)雜的驅(qū)動程序，該驅(qū)動程序使用一個公共緩沖池和用于標頭模板和有效負載數(shù)據(jù)的指針操作。

圖 5：優(yōu)化效果

4 結(jié)論

10MBit 通信協(xié)議會給網(wǎng)關(guān) CPU 帶來額外的負載。通過巧妙的軟件方法和硬件特性，所需的 CPU 性能不會隨著帶寬和凈數(shù)據(jù)速率的增加而增加。

Renesas 的以太網(wǎng)通信接口提供自動數(shù)據(jù)傳輸并支持指針操作，以便在系統(tǒng)內(nèi)存中進行復(fù)雜的消息組合。下一代 CAN XL 接口將朝著相同的方向發(fā)展。

10BASE-T1S 和 CAN XL 都將擁有它們主導(dǎo)的應(yīng)用領(lǐng)域。它們由值得信賴的標準化機構(gòu)開發(fā)，并在提供產(chǎn)品和解決方案的行業(yè)中擁有包括瑞薩在內(nèi)的支持者。

審核編輯：郭婷