車載以太網 車載以太網的大規模應用，實際上是隨著汽車的電動化，智能化發展而來的。在分布式的EEA時代，各ECU之間需要相互傳輸的信號量極少，使用CAN總線即可實現互聯。當汽車進入智能化時代，EEA架構向中央計算-區域控制方向演進。由于汽車內使用的傳感器越來越多，傳輸的數據量越來越大，所需帶寬也越來越多，因此需要有新的網絡互聯技術來支撐這一變化。為了滿足中央計算機與區域控制器之間的互聯要求，車載以太網被認為是一個合適的解決方案。

如上圖所示，各個域控制器之間采用ETH車載以太網進行連接，而域控制器內部則還是采用星型架構。為了保證ETH傳輸的可靠，還要求多個域控制器之間的ETH進行互聯，組成以太環網。由于ECU演進的程度不統一，它們所采用的互聯技術，可能有CAN，CAN-FD，LIN，FlexRay等各種總線。而對于Camera,?顯示屏等多媒體設備來說，所傳輸的數據量特別大，還需要采用特殊的串行-解串器進行連接。

上圖所展示的還是集成式域控制器架構。整車電子電氣架構按功能進行劃分，分為車身域，ADAS域，信息娛樂域，底盤域，動力域等，各域控制器之間依賴中央網關進行互聯。而對于中央集成-區域控制架構來說，以上的各域控制器將集中到一個中央計算機內部。各個ECU，仍然使用CAN，LIN，FlexRay等技術。它們按汽車物理區域的劃分，分別掛載到不同位置的Zone區域控制器下。此時Zone起到了一個中繼節點的作用，提供了以太網到其他總線的轉發功能，如下圖所示。

? 高速視頻傳輸(FPD-Link)

為了滿足智能網聯汽車對多傳感器的需求，需要有高速視頻傳輸總線來將這些傳感器連接到中央計算機上。這些傳感器一般為視覺攝像頭或者大型液晶顯示屏等。它們對通信的要求是，高帶寬，低時延。通信連接類型一般是點到點的方式。例如用于高級自動輔助駕駛ADAS系統的攝像頭，一般為5M的?Camera Sensor，它所需要的傳輸帶寬高達?2.5Gbps，而這樣的攝像頭全車需要10多個。目前的車載以太網技術根本承載不了這樣的帶寬需求，因此只能考慮專用點到點的連接方式。

如下圖所示，攝像頭和顯示屏，都通過專用的高速視頻傳輸接口連接到中央計算平臺上。其中智能座艙域控制器需要連接的是座艙內部攝像頭(輸入)和座艙內的顯示屏(輸出)。其中可能會使用到不同類型的傳輸接口以及線纜。

車載高速音視頻傳輸接口還有另外一個特殊的需求，即長距離傳輸和車內電磁兼容性設計EMC(Electro Magnetic Compatibility)。相比起個人消費類電子設備，車載傳感器所使用的連接接口工作環境可謂惡劣。首先是要考慮3-10米的傳輸距離。一個攝像頭或者一個顯示屏，與車載中央計算平臺的物理距離，短則1至3米，長則可達10米，一般的數據接口根本無法滿足這樣長的傳輸距離。另一方面，車內工作環境復雜，溫度高，電磁干擾大，數據傳輸距離增加會帶來信號的衰減。因此，需要有專門的數據傳輸技術來滿足車內高速音視頻傳輸的需求。

攝像頭或者顯示屏上傳輸的視頻信號，一般都是RGB、YUV、或者raw data等圖像格式的數據。按圖像的數據特點來看，每個像素都由多個bit組成。在最初的圖像傳輸接口中，采用高速并行接口來傳輸數據。但這樣帶來的問題是接插件的針數多，尺寸大，傳輸線纜的重量，成本都會很高；線束的安裝成本也很高，長距離傳輸的誤碼率相當高，導致傳輸帶寬受限。

因此，采用串行傳輸是代替這種并行傳輸的有效解決方法。通過把發送端的多條并行數據（包括視頻和控制、語音等數據）轉換成單條的串行數據，在接收端再把串行的數據轉換恢復成并行視頻格式和低速控制信號，就能有效解決上文所提的“高帶寬，低時延，長距離”傳輸的問題。

首先要解釋一下并行傳輸轉換為串行傳輸的原理。要想實現長距離的高速傳輸，LVDS是一種可行的技術，即低壓差分信號(Low-Voltage Differential Signaling)。它是一種低功耗，低誤碼率，低串擾和低輻射的差分信號傳輸技術。它通常需要通過一對信號線，以極低的電壓擺幅高速差動來傳輸數據。

FPD-Link是基于LVDS物理層之上的一種通信標準。它的英文全稱是Flat Panel Display Link，是美國國家半導體公司(后被德州儀器TI公司收購)于1996年提出的。FPD-Link I代芯片組將寬并行的RGB總線串行化為4或5對LVDS信號。如下圖所示：21根并行信號線串行化為4對LVDS信號，其中3對數據線，1對時鐘線。

到了FPD-Link III的時代，TI?停止使用?LVDS?模式，而改為CML模式。它通過一對屏蔽雙絞線(STP)或者一根同軸電纜(Coax)即可傳輸高速串行信號。它可以實現在10米的距離上傳輸6Gbps的數據。通過增加一對串行和解串器，在傳輸線上可以實現高速正向通道和低速反向通道。

正向傳輸通道用于以最小的延遲將串行化視頻、音頻或其他數據發送到端點設備。為了實現這一點，串行器必須重新格式化其傳入的數據并嵌入數據時鐘，以便可以使用更少的導體將其輸出。通過利用專有的回聲消除技術，FPD-Link?串行器/解串器還允許通過一個物理導體進行全雙工通信。

當高速數據沿正向方向從串行器傳輸到解串器時，低速數據也同時傳輸回到串行器，而無需時分復用。?FPD-Link?串行器和解串器設備通過在鏈路的每一端連續抵消其自己的傳輸信號來自動建立該雙向通道。反向通道通常以比正向通道數據低得多的速度運行，以便于在兩側實現適當的分離，并且可以包含有關同步設備的信息、觸摸中斷、控制信號、狀態信息等。

使用同步反向通道通信，還可以在鏈路上沿正向或反向方向啟用?I2C?訪問或?GPIO?傳輸。為了補償通道插入損耗（該損耗可能很大，具體取決于運行速度以及所用電纜的類型或長度）FPD-Link?解串器利用多種均衡技術來恢復高頻信號成分并減輕碼間串擾、反射或外部噪聲產生的影響。

高速視頻信號從串行器傳輸到解串器的過程中經過PCB走線、連接器和線束，這些傳輸介質都會衰減信號幅度，增加信號噪聲，而且頻率越高，被影響的程度越大。如下圖所示，串行器的輸出數據的眼圖為左邊第一幅圖所示，比較清晰、干凈。經過傳輸線以后，眼圖閉合，如中間第二幅圖所示。為了補償傳輸介質對信號的惡化，FPD Link?器件提供了Equalizer均衡器模塊。這個模塊放大補償輸入信號，且對信號高頻部分補償得更多，以此來部分抵消傳輸通道對信號的影響。通過Equalizer之后，輸入信號的眼圖重新張開，如右邊第三幅圖所示。

由于FPD Link需要適應不同類型不同長度的線束，所以均衡器的高頻增益值分多個等級，芯片會自動檢測輸入信號的質量，自適應地設置最佳的均衡值，這個自適應模塊叫AEQ。該模塊在解串器每次上電時做一次自適應補償，所以即便線束存在老化、溫漂、線束個體差異等實際差異時，AEQ?都能夠自動選擇出最佳的補償等級。另外，技術人員也可以讀取上電以后的AEQ?的補償值，如果明顯高于正常值，可以判斷當前傳輸通道可能存在短路、松動、彎曲等異常情況。

AEQ內還集成有CDR（Clock Data Recovery）電路，集成的鎖相環電路鎖定輸入數據Incoming Data并輸出降噪以后的較干凈的同頻率時鐘Recovered Clock；同時這個干凈時鐘做為新的采樣時鐘，在Sampler上對輸入數據重新采樣并輸出，從而達到濾除輸入數據抖動、降低碼間串擾、減少通道間串擾和恢復數據眼圖的功能。 ?

? 流媒體

流媒體（streaming media）是指將一連串的媒體數據壓縮后，經過網上分段發送數據，在網上即時傳輸影音以供觀賞的一種技術與過程。隨著汽車智能化和網聯化的發展，流媒體在汽車上的應用也越來越多。例如流媒體后視鏡就是通過后向攝像頭獲取數據處理后再播放給駕駛員看。智能駕駛功能也越來越多地把感知和規控信息渲染處理后傳輸給車載大屏播放。

基本術語

分辨率

指視頻在一定區域內包含的像素點的數量。單位“P”（Progressive）表示縱向有多少行像素，“k”則表示橫向有多少千像素。例如720P表示縱向有720行像素，而4k就是視頻橫向大約有4000列像素。 ? 按通常的橫縱比例定義， 720P的分辨率為1280x720像素

1080P的分辨率為1920*1080像素

2k的分辨率為2560*1440像素

4k的分辨率為3840*2160像素

幀率 ? 指1秒內連續播放多少個畫面。一般達到每秒播放24個畫面就有動畫效果。幀率的單位是“fps”，常見的有24fps、30fps、60fps。幀率越高視頻播放起來會越流暢，但幀率越高，對設備要求也越高。? ? ? 編碼解碼

我們平時看到的視頻、圖片和音頻等大部分都是通過壓縮處理的。Codec編碼解碼器主要作用是對視頻信號進行壓縮和解壓縮。對信息進行壓縮處理，例如只記錄一幀完整畫面及其后幀與幀之間的差異部分，而不是每幀記錄全畫幅。

常見的H264、H265就是編解碼格式。H265比H264更加新，壓縮效率也更高，但需要專用的硬件解碼器，因而可能不能在舊的設備上播放。IPhone相機拍攝格式選擇的“高效”其實就是H265，“兼容性最佳”其實就是H264。當然類似地，音頻也有編碼解碼，例如常見的MP3就是一種編碼（壓縮）格式。?

總體架構

下圖是兩個控制器之間視頻流傳輸的架構示意圖，例如其中一個可以是智能駕駛域控制器，另一個是智能座艙域控制器。 ?

智駕域控渲染后的視頻通過特定編碼器后生成原始視頻流，然后封裝打包成PES流，然后再裝載到MPEG-TS的容器中，打包成TS流。TS流再通過RTP協議傳輸。在網絡傳輸上，RTP向下通過UDP、IP多層協議，完成以太網的傳輸。智能座艙域控制器收到以太網幀后，會逆向地對其進行分級組包拆包，解析出RTP報文，繼而是TS流和PES流。然后再把視頻流送進解碼器進行解壓縮和播放。

而與視頻流平行傳輸的還有一路控制流通過RTCP協議傳輸。RTCP?提供數據分發質量反饋信息報告，接收端可以根據RTCP中的傳輸質量信息，反饋給上層應用端，以調整傳輸質量，例如網絡質量差的時候就不傳4k視頻，而改成傳720p。

通過上述架構和總體流程的介紹可以看出，流媒體與本地存儲多媒體的一個本質區別是流媒體需要進行網絡傳輸后播放。例如在汽車上，激光雷達和攝像頭等傳感器會提供原始數據給智能駕駛域控制器，域控制器完成傳感器同步融合等處理后再渲染出表示周圍環境的視頻，甚至制作音頻，然后再將音視頻同時傳輸給車機在中控屏幕上播放。傳輸過程中，音視頻需要在控制器之間傳輸。傳輸下層協議的UDP、IP等都是通用的以太網傳輸協議和標準，而RTP/RTCP則是在以太網傳輸基礎上針對流媒體傳輸的關鍵協議。?

PES和TS流

編碼器里出來的原始音視頻裸流就是ES（Elementary Stream）流，ES流只包含一種音頻或者視頻。 ? ES的第一次封裝：PES。 ? PES?（Packetized Elementary Stream）流是ES流經過PES打包器處理后形成的數據流，在這個過程中完成了將ES流分組、打包、加入Header信息等操作。PES流的基本單位是PES包。PES包由Header和Payload組成。Payload部分組合起來就是原始的ES流，并不會修改ES的內容。一個PES包的最大長度是65535個字節。第一層封裝的主要目的是豐富傳輸流的信息。

ES的第二次封裝：MPEG-TS。

MPEG-TS，也稱MTS或TS（transport stream），是一種標準容器格式，是對PES包的進一步封裝。它主要用來傳輸和（傳輸過程中）存儲音頻、視頻和節目系統信息等。TS包的長度是188字節，4字節頭，184字節payload。所以一個PES包可能會被封裝成多個TS包。一個PES包必須由整數個TS包傳輸，如果承載一個PES包的最后一個TS包沒有被裝滿，則用填充字節進行填充。第二層封裝的目的是規范化傳輸的最小單元，保證傳輸的可靠性，以適應不太可靠的傳輸。

TS包都是分為包頭?TS Header和TS Payload有效載荷部分，其中有效負載可以填入音頻、視頻、和節目映射表等其它形式數據。TS流可以理解為一個大的管道，里面傳輸的TS包可能會屬于不同的PES流，而TS Header中的PID則是用來識別PES流的關鍵字段。在TS流中找出相同PID的TS包，按順序排列，一般是如下圖所示的結構。第一個TS包的Payload里包含了PESHeader，最后一個TS包的Payload里包含了空位填充，以保證TS包188字節的固定長度。

RTP傳輸協議

RTP全稱是Real-time Transport Protocol，實時傳輸協議，是一個網絡傳輸協議。它詳細說明了在以太網上傳遞音頻和視頻的標準數據包格式。RTP協議和RTP控制協議（RTCP）往往一起使用，而且它是創建在UDP協議上的。廣義的RTP標準其實包含了RTP和RTCP兩個子協議。所以當我們平時討論RTP的時候也要注意背景和語境，確認討論的是廣義的RTP還是狹義的RTP。下文用“RTP子協議”指示狹義，其余均是廣義。

RTP為數據提供了具有實時特征的端對端傳送服務，如在組播或單播網絡服務下的交互式視頻音頻或模擬數據。應用程序通常在?UDP?上運行?RTP?以便使用其多路節點和校驗服務。分層協議的好處是能各司其職，高效應對復雜的傳輸問題。RTP?本身并沒有提供按時發送機制或其它服務質量（QoS）保證，它依賴于底層協議去實現這一過程。

RTP?并不保證傳送或防止無序傳送，也不確定底層網絡的可靠性。下圖是基于以太網幀、RTP包和TS包的示意圖。與其他以太網通訊協議一樣，其報文頭包含了關鍵的媒體傳輸信息，也是該層協議的特征所在。

下表對應的是RTP子協議Header。前12字節（即頭3行）是必填字段。

其中各個字段的含義是，

V：RTP協議的版本號，占2位，當前協議版本號為2。

P：填充標志，占1位，如果P=1，則在該報文的尾部填充一個或多個額外的八位組，它們不是有效載荷的一部分。

X：擴展標志，占1位，如果X=1，則在RTP子協議報頭后跟有一個擴展報頭。

CC：CSRC計數器，占4位，指示CSRC?標識符的個數。CSRC可以理解為音視頻的來源，例如一個RTP子協議包中包含了來自于兩個視頻來源的數據，則CC是2。下面的CSRC identifier也有2個。

M:標記，占1位，不同的有效載荷有不同的含義，對于視頻，標記一幀的結束；對于音頻，標記會話的開始。

Payload Type：有效載荷類型，占7位，用于說明RTP子協議報文中有效載荷的類型，例如H263的視頻是34。而由于H264出現的比RTP的定義晚，一般H264的Payload Type都定義為RTP子協議保留號段中的96。

Sequencenumber：序列號，占16位，用于標識發送者所發送的RTP子協議報文的序列號，每發送一個報文，序列號增1。接收者通過序列號來檢測報文丟失情況，重新排序報文，恢復數據。

Timestamp：時間戳，占32位，時戳反映了該RTP子協議報文的第一個八位組的采樣時刻。接收者使用時戳來計算延遲和延遲抖動，并進行同步控制。

SSRC identifier：同一個RTP會話中同步信源標識符，占32位，用于標識同步過的信源。

CSRC identifier：特約信源標識符，每個CSRC標識符占32位，可以有0～15個。每個CSRC標識了包含在該RTP子協議報文有效載荷中的所有特約信源。CC中定義了RTP子協議包中有幾個信源，這個部分則定義了每個信源的ID。 ? 審核編輯：黃飛

?