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

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

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

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

圖 1：音頻示例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖 4：框架組裝流程

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

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

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

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

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

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

4 結(jié)論

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

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

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

審核編輯：郭婷