車載以太網(wǎng) 車載以太網(wǎng)的大規(guī)模應(yīng)用，實(shí)際上是隨著汽車的電動化，智能化發(fā)展而來的。在分布式的EEA時代，各ECU之間需要相互傳輸?shù)?a target="_blank">信號量極少，使用CAN總線即可實(shí)現(xiàn)互聯(lián)。當(dāng)汽車進(jìn)入智能化時代，EEA架構(gòu)向中央計算-區(qū)域控制方向演進(jìn)。由于汽車內(nèi)使用的傳感器越來越多，傳輸?shù)臄?shù)據(jù)量越來越大，所需帶寬也越來越多，因此需要有新的網(wǎng)絡(luò)互聯(lián)技術(shù)來支撐這一變化。為了滿足中央計算機(jī)與區(qū)域控制器之間的互聯(lián)要求，車載以太網(wǎng)被認(rèn)為是一個合適的解決方案。

如上圖所示，各個域控制器之間采用ETH車載以太網(wǎng)進(jìn)行連接，而域控制器內(nèi)部則還是采用星型架構(gòu)。為了保證ETH傳輸?shù)目煽?，還要求多個域控制器之間的ETH進(jìn)行互聯(lián)，組成以太環(huán)網(wǎng)。由于ECU演進(jìn)的程度不統(tǒng)一，它們所采用的互聯(lián)技術(shù)，可能有CAN，CAN-FD，LIN，F(xiàn)lexRay等各種總線。而對于Camera,?顯示屏等多媒體設(shè)備來說，所傳輸?shù)臄?shù)據(jù)量特別大，還需要采用特殊的串行-解串器進(jìn)行連接。

上圖所展示的還是集成式域控制器架構(gòu)。整車電子電氣架構(gòu)按功能進(jìn)行劃分，分為車身域，ADAS域，信息娛樂域，底盤域，動力域等，各域控制器之間依賴中央網(wǎng)關(guān)進(jìn)行互聯(lián)。而對于中央集成-區(qū)域控制架構(gòu)來說，以上的各域控制器將集中到一個中央計算機(jī)內(nèi)部。各個ECU，仍然使用CAN，LIN，F(xiàn)lexRay等技術(shù)。它們按汽車物理區(qū)域的劃分，分別掛載到不同位置的Zone區(qū)域控制器下。此時Zone起到了一個中繼節(jié)點(diǎn)的作用，提供了以太網(wǎng)到其他總線的轉(zhuǎn)發(fā)功能，如下圖所示。

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

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

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

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

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

因此，采用串行傳輸是代替這種并行傳輸?shù)挠行Ы鉀Q方法。通過把發(fā)送端的多條并行數(shù)據(jù)（包括視頻和控制、語音等數(shù)據(jù)）轉(zhuǎn)換成單條的串行數(shù)據(jù)，在接收端再把串行的數(shù)據(jù)轉(zhuǎn)換恢復(fù)成并行視頻格式和低速控制信號，就能有效解決上文所提的“高帶寬，低時延，長距離”傳輸?shù)膯栴}。

首先要解釋一下并行傳輸轉(zhuǎn)換為串行傳輸?shù)脑?。要想?shí)現(xiàn)長距離的高速傳輸，LVDS是一種可行的技術(shù)，即低壓差分信號(Low-Voltage Differential Signaling)。它是一種低功耗，低誤碼率，低串?dāng)_和低輻射的差分信號傳輸技術(shù)。它通常需要通過一對信號線，以極低的電壓擺幅高速差動來傳輸數(shù)據(jù)。

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

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

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

當(dāng)高速數(shù)據(jù)沿正向方向從串行器傳輸?shù)浇獯鲿r，低速數(shù)據(jù)也同時傳輸回到串行器，而無需時分復(fù)用。?FPD-Link?串行器和解串器設(shè)備通過在鏈路的每一端連續(xù)抵消其自己的傳輸信號來自動建立該雙向通道。反向通道通常以比正向通道數(shù)據(jù)低得多的速度運(yùn)行，以便于在兩側(cè)實(shí)現(xiàn)適當(dāng)?shù)姆蛛x，并且可以包含有關(guān)同步設(shè)備的信息、觸摸中斷、控制信號、狀態(tài)信息等。

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

高速視頻信號從串行器傳輸?shù)浇獯鞯倪^程中經(jīng)過PCB走線、連接器和線束，這些傳輸介質(zhì)都會衰減信號幅度，增加信號噪聲，而且頻率越高，被影響的程度越大。如下圖所示，串行器的輸出數(shù)據(jù)的眼圖為左邊第一幅圖所示，比較清晰、干凈。經(jīng)過傳輸線以后，眼圖閉合，如中間第二幅圖所示。為了補(bǔ)償傳輸介質(zhì)對信號的惡化，F(xiàn)PD Link?器件提供了Equalizer均衡器模塊。這個模塊放大補(bǔ)償輸入信號，且對信號高頻部分補(bǔ)償?shù)酶?，以此來部分抵消傳輸通道對信號的影響。通過Equalizer之后，輸入信號的眼圖重新張開，如右邊第三幅圖所示。

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

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

? 流媒體

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

基本術(shù)語

分辨率

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

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

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

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

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

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

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

總體架構(gòu)

下圖是兩個控制器之間視頻流傳輸?shù)募軜?gòu)示意圖，例如其中一個可以是智能駕駛域控制器，另一個是智能座艙域控制器。 ?

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

而與視頻流平行傳輸?shù)倪€有一路控制流通過RTCP協(xié)議傳輸。RTCP?提供數(shù)據(jù)分發(fā)質(zhì)量反饋信息報告，接收端可以根據(jù)RTCP中的傳輸質(zhì)量信息，反饋給上層應(yīng)用端，以調(diào)整傳輸質(zhì)量，例如網(wǎng)絡(luò)質(zhì)量差的時候就不傳4k視頻，而改成傳720p。

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

PES和TS流

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

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

MPEG-TS，也稱MTS或TS（transport stream），是一種標(biāo)準(zhǔn)容器格式，是對PES包的進(jìn)一步封裝。它主要用來傳輸和（傳輸過程中）存儲音頻、視頻和節(jié)目系統(tǒng)信息等。TS包的長度是188字節(jié)，4字節(jié)頭，184字節(jié)payload。所以一個PES包可能會被封裝成多個TS包。一個PES包必須由整數(shù)個TS包傳輸，如果承載一個PES包的最后一個TS包沒有被裝滿，則用填充字節(jié)進(jìn)行填充。第二層封裝的目的是規(guī)范化傳輸?shù)淖钚卧ＷC傳輸?shù)目煽啃?，以適應(yīng)不太可靠的傳輸。

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

RTP傳輸協(xié)議

RTP全稱是Real-time Transport Protocol，實(shí)時傳輸協(xié)議，是一個網(wǎng)絡(luò)傳輸協(xié)議。它詳細(xì)說明了在以太網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式。RTP協(xié)議和RTP控制協(xié)議（RTCP）往往一起使用，而且它是創(chuàng)建在UDP協(xié)議上的。廣義的RTP標(biāo)準(zhǔn)其實(shí)包含了RTP和RTCP兩個子協(xié)議。所以當(dāng)我們平時討論RTP的時候也要注意背景和語境，確認(rèn)討論的是廣義的RTP還是狹義的RTP。下文用“RTP子協(xié)議”指示狹義，其余均是廣義。

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

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

下表對應(yīng)的是RTP子協(xié)議Header。前12字節(jié)（即頭3行）是必填字段。

其中各個字段的含義是，

V：RTP協(xié)議的版本號，占2位，當(dāng)前協(xié)議版本號為2。

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

X：擴(kuò)展標(biāo)志，占1位，如果X=1，則在RTP子協(xié)議報頭后跟有一個擴(kuò)展報頭。

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

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

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

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

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

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

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

?