前言

本文思維大綱如下：

在車載以太網(wǎng)開發(fā)過程中，我們最為常見的應用層協(xié)議主要是SOMEIP與DOIP兩大類協(xié)議，其中SOMEIP協(xié)議作為實現(xiàn)SOA架構的一種重要實現(xiàn)手段被廣泛應用，DOIP協(xié)議則針對大文件的刷寫場景，大大提高了刷寫效率。

特別對于SOMEIP協(xié)議作為涉及到整個系統(tǒng)多方交互的重要協(xié)議，隨著域集中式不斷發(fā)展，其通信帶寬瓶頸也是日趨緊張， 這里指的通信帶寬瓶頸更多的指的是SOMEIP應用的最大吞吐量，最大吞吐量的計算可以參考小T之前的文章《車載以太網(wǎng)性能還能這樣測！》有著更為詳解的說明與測試方法。只要最大吞吐量提高了，那么車載以太網(wǎng)帶寬利用率也就上去了，通信帶寬瓶頸問題也就能夠解決。

本文主要聚焦如何進一步提高基于SOMEIP應用的整體車載以太網(wǎng)性能，目前主要從如下幾個方面進行展開優(yōu)化，以便能夠大大提高車載以太網(wǎng)性能：

物理層優(yōu)化；

數(shù)據(jù)鏈路層優(yōu)化；

網(wǎng)絡層優(yōu)化；

傳輸層優(yōu)化；

SOMEIP應用層優(yōu)化；

1. 物理層優(yōu)化方向

1.1 提高物理層通信帶寬能力

我們都知道車載以太網(wǎng)的PHY需要與對應的MAC層速率相匹配，如果MAC最大通信速率僅為100Mbps，那么其與之匹配的物理層芯片PHY最大僅需滿足100Mbps即可。

如果MAC層最大支持1000Mbps，那么此時的PHY則同步需要設置成1000Mbps，才能夠大大提高物理層通信帶寬能力。

當前需要注意的是在整車情況下，如果ECU A設置成1000Mbps，但是對手件僅為100Mbps，在使能自協(xié)商的前提下那么最終協(xié)調的通信速率將僅為100Mbps，則大大降低了整個系統(tǒng)的通信帶寬。

因此，對于整車以太網(wǎng)設計而言，應當針對通信數(shù)據(jù)需求場景，合理的設計好通信帶寬，無需過多，夠用即可。如果一味的追求高帶寬而不考慮應用場景的需求，那么就會無形中增加成本，對產品競爭力造成影響。

如下圖所示為幾種不同通信速率下的MAC與PHY芯片的組合場景：

車載以太網(wǎng)MAC層與PHY層兩者通信速率要確保設置一致，最大通信速率取決于MAC層與PHY層之間共同能夠達到的最大值；

一般對于整車通信而言，為了減少車載以太網(wǎng)通信雙方Linkup時間，一般都會關閉自協(xié)商，統(tǒng)一強制設置好Master與Slave，通信速率以及雙工模式等；

2. 數(shù)據(jù)鏈路層(MAC)優(yōu)化方向

2.1 使能DMA傳輸

以英飛凌TC3XX芯片為例，其芯片內部的Eth MAC層存在DMA機制，該DMA完全處于Eth控制器內部，與外部的DMA無關，通過使能多通道DMA機制，可以大大提高通信速率并確保高優(yōu)先級報文能夠優(yōu)先發(fā)送。

Tx DMA通道及優(yōu)先級配置：

Rx DMA通道及優(yōu)先級配置：

2.2 設置硬件最大傳輸效率

以英飛凌TC3XX芯片為例，看看如何修改并設定MAC層最大通信速率，其他芯片類似，可調整設定成最大傳輸效率1000Mbps，即1Gbps：

3. 網(wǎng)絡層(IP)優(yōu)化方向

3.1 使能硬件CRC計算

對于網(wǎng)絡層我們發(fā)送數(shù)據(jù)是需要需要針對IP層數(shù)據(jù)進行組包同時需要進行CRC計算，我們知道如果包較長的話，那么CRC耗時就會變長，當前英飛凌TC3XX系列芯片MAC層支持IP層硬件CRC計算功能，這樣IP層軟件層的CRC可以不用計算，直接在MAC硬件中直接計算即可。

在AUTOSAR Eth Driver 規(guī)范中就有關于CRC Offloading的這種軟件需求，如下圖所示：

英飛凌TC3XX系列Eth Driver中的CRC Offloading使能配置如下：

在使能底層MAC硬件自身的CRC計算能力之后，軟件層的TCP/IP協(xié)議棧各協(xié)議層的CRC計算也需要關閉掉，否則就無法真正發(fā)揮底層硬件的功能了，如下所示：

注意事項：使能其中一個時，四個均需要同時使能，這個可能是硬件特性導致，也是跟AUTOSAR規(guī)范有些偏差的地方，不過為了提高性能，全部使能也沒啥大問題。

4. 傳輸層(TCP/UDP)優(yōu)化方向

4.1 減少數(shù)據(jù)拷貝

對于TCP或者UDP層可能會存在一些數(shù)據(jù)拷貝的地方，針對這些數(shù)據(jù)拷貝，一般會有如下兩種思路:

是不是必須要數(shù)據(jù)拷貝，有沒有零拷貝方案，因為對于以太網(wǎng)這種上千字節(jié)的拷貝是很花時間的，應該盡可能做到零拷貝，除了必要的組包跟解包以外；

如果無法避免數(shù)據(jù)拷貝，需要考慮源地址與目標地址是否在CPU取值效率最高的地方，比如TC397的DSPR就會比LMU區(qū)域快很多，因盡可能將源地址與目標地址均放入到DSPR中；

如果無法避免數(shù)據(jù)拷貝，看看是否可以采用單指令多操作數(shù)方式(SIMD)方式來實現(xiàn)Memcpy動作，應該也在一定程度上能夠加速數(shù)據(jù)拷貝。

4.2 使能硬件CRC計算

同3.1小節(jié)，一并使能TCP以及UDP報文的硬件CRC計算功能，關閉軟件CRC計算特性，這樣CPU就可以做更多的事情，也不會接收到無效報文的中斷。

5. SOMEIP應用層優(yōu)化方向

5.1 優(yōu)化序列化算法

SOMEIP應用中有一個必須要做的步驟就是序列化，但是我們都知道對于SOMEIP而言，特別是報文長度達到1400左右個字節(jié)的時候，序列化所花費的時間就會非常長，因此需要優(yōu)化序列化算法，一般可以從如下幾個方面入手進行優(yōu)化：

優(yōu)化內存對齊方式，這個需要結合芯片架構特性來決定，比如當前MCU為32bit，那么采用4字節(jié)對齊則更為合適，采用1字節(jié)對齊則會增加系統(tǒng)處理時間，影響序列化效率；

采用更為高效的序列化算法，如Protobuf或者Nanopb等方式來進行序列化，能夠在某種程度上提高序列化水平，同時能夠實現(xiàn)跨平臺的數(shù)據(jù)解析功能；

5.2 采用結構體對齊方式序列化

不進行SOMIP特有的序列化，采用結構體對齊的方式來進行序列化，不過這個對于結構體的良好設計會有些要求，當然也會增加較多填充字符，影響每次傳輸過程中的有效帶寬；