去年我們做遠(yuǎn)程泊車演示車停在負(fù)二樓人在一層展臺(tái)舉著手機(jī)下發(fā)指令結(jié)果等了快十秒車毫無反應(yīng)。排查到最后問題出在通信鏈路上——T-Box在弱信號區(qū)駐留的不是最優(yōu)小區(qū)上下行調(diào)度也被平臺(tái)限速一條簡單指令繞了一大圈才到車端。那次之后我徹底意識到一件事蜂窩移動(dòng)通信在現(xiàn)代智能汽車?yán)镌缇筒皇恰澳苌暇W(wǎng)、能導(dǎo)航”這么簡單它正在成為遠(yuǎn)程控車、OTA升級、V2X車路協(xié)同、高精度定位地基等幾乎所有智能化能力的底層通道。這是“現(xiàn)代智能汽車中的無線技術(shù)”系列第四篇也是蜂窩移動(dòng)通信技術(shù)部分的第三篇。前面兩篇已經(jīng)把LTE/5G-V2X的基礎(chǔ)架構(gòu)、車-路-云協(xié)同框架和標(biāo)準(zhǔn)演進(jìn)脈絡(luò)梳理過了這篇我打算換個(gè)姿勢直接落到工程落地上從車端通信模組選型、天線布局的硬骨頭到5G-V2X真實(shí)場景的時(shí)延預(yù)算再到軟件定義汽車時(shí)代的遠(yuǎn)程能力、多網(wǎng)協(xié)同和測試驗(yàn)證。整篇依然是“技術(shù)拆解實(shí)戰(zhàn)經(jīng)驗(yàn)”的路子適合正在做車載通信、車聯(lián)網(wǎng)平臺(tái)或者對智能汽車無線系統(tǒng)有好奇心的朋友。1. 車載蜂窩通信的技術(shù)底座從通信芯片到天線系統(tǒng)的工程組合很多做上層應(yīng)用的人會(huì)把蜂窩通信簡單理解成“一塊4G/5G模組插個(gè)SIM卡就能聯(lián)網(wǎng)”。但真正把通信系統(tǒng)裝進(jìn)一輛要跑十五年的車上遠(yuǎn)比這復(fù)雜。車載蜂窩通信的底座由車規(guī)級模組、天線系統(tǒng)和整車電氣環(huán)境三部分構(gòu)成任何一環(huán)出了問題上層應(yīng)用體驗(yàn)都會(huì)直接崩掉。1.1 車規(guī)級通信模組的選型邏輯通信模組在整車電子架構(gòu)里通常被集成進(jìn)T-Box遠(yuǎn)程信息處理終端或直接貼裝在域控制器上是整車對外通信的“心臟”。車規(guī)模組和消費(fèi)級模組最大的差異首先體現(xiàn)在環(huán)境適應(yīng)性和壽命上。消費(fèi)級芯片工作溫度普遍是0℃到70℃但車規(guī)級產(chǎn)品必須覆蓋-40℃到85℃甚至105℃還要承受振動(dòng)、鹽霧、電磁干擾以及長達(dá)10到15年的供貨周期。AEC-Q100認(rèn)證只是入場券真正決定可靠性的是材料選型和出廠測試的嚴(yán)格程度。我在選型階段踩過一個(gè)很隱蔽的坑。某款5G模組樣品在常溫下的射頻指標(biāo)全部合格但放進(jìn)高低溫箱做-30℃低溫循環(huán)測試時(shí)發(fā)射功率出現(xiàn)異常跌落直接導(dǎo)致弱場下掉線。后來反復(fù)排查定位到是射頻前端一顆電容在低溫內(nèi)容值漂移最終換了物料才解決。這件事給我的教訓(xùn)是車規(guī)模組選型不能只看規(guī)格書一定要在高低溫、溫度循環(huán)、振動(dòng)疊加環(huán)境下做射頻全項(xiàng)測試尤其是發(fā)射功率、EVM、靈敏度這些關(guān)鍵指標(biāo)。模組本身的集成度這幾年提升非?？?。當(dāng)前主流的5G車規(guī)模組已經(jīng)把基帶處理器、射頻收發(fā)器、電源管理單元、安全芯片、甚至eMMC存儲(chǔ)都封裝在一起對外只留PCIe、USB、RGMII這類高速接口和天線端口。選型時(shí)要重點(diǎn)關(guān)注的參數(shù)包括支持的頻段組合尤其是否支持運(yùn)營商要求的全部5G頻段和LTE頻段、雙卡雙待能力、VoLTE/VoNR語音方案、網(wǎng)絡(luò)制式回退策略以及和整車域控制器之間的接口帶寬。此外通信模組的SDK和驅(qū)動(dòng)質(zhì)量往往被忽略但實(shí)際聯(lián)調(diào)時(shí)這塊才是最耗時(shí)間的——好的SDK能讓你快速調(diào)通診斷接口和數(shù)據(jù)通道差的SDK會(huì)讓人在底層驅(qū)動(dòng)上浪費(fèi)幾周。1.2 天線布局與整車環(huán)境的真實(shí)博弈天線是整車無線通信的“喇叭”但車身恰恰是最不適合放天線的環(huán)境。一臺(tái)車要同時(shí)容納4G/5G蜂窩天線、GNSS天線、V2X天線、藍(lán)牙/Wi-Fi天線而可用的布置位置就那么幾個(gè)鯊魚鰭、車頂、前風(fēng)擋上沿、后保險(xiǎn)杠、外后視鏡。尤其是金屬車身帶來的屏蔽效應(yīng)會(huì)讓天線性能大打折扣。蜂窩天線的主流方案是鯊魚鰭集成把多根天線塞進(jìn)一個(gè)小殼體里包括主天線、分集天線有時(shí)還要加上V2X天線和GNSS天線。但天線之間距離太近隔離度就會(huì)變差導(dǎo)致天線效率下降、接收靈敏度降低。實(shí)測中鯊魚鰭內(nèi)蜂窩天線與V2X天線若間距低于30cm隔離度很可能只有12dB左右遠(yuǎn)低于理想的20dB以上。如果主機(jī)廠在造型上把鯊魚鰭壓扁留給天線的凈空區(qū)更小這個(gè)問題會(huì)更嚴(yán)重。我做過一次天線布置對比測試V2X天線放在前風(fēng)擋上緣時(shí)如果該區(qū)域貼著金屬含量高的隔熱膜信號衰減可以達(dá)到20dB換成帶“透波窗口”的玻璃區(qū)域同樣的模組接收到的參考信號接收功率明顯改善通信距離的差距非?？捎^。所以如果項(xiàng)目涉及V2X務(wù)必和造型部門、玻璃供應(yīng)商在早期對齊“透波窗口”的位置不要等開模了再返工。MIMO天線的引入也讓整車天線設(shè)計(jì)越來越難。5G的下行速率高度依賴MIMO多天線車頂要布置多根天線做分集和空間復(fù)用。但車頂面積和鯊魚鰭尺寸就那么大天線之間的相關(guān)性系數(shù)ECC很容易超標(biāo)。實(shí)測下來鯊魚鰭內(nèi)做2x2 MIMO是相對穩(wěn)妥的方案做4x4 MIMO時(shí)天線間的相關(guān)性很難壓低除非把天線外延到后窗或外后視鏡區(qū)域。這里給個(gè)建議做天線方案評審時(shí)一定要看整車級OTA測試數(shù)據(jù)而不是模組廠商的實(shí)驗(yàn)室數(shù)據(jù)兩者的差異可能超過30%。2. 5G-V2X場景落地蜂窩鏈路解決的實(shí)際駕駛問題蜂窩技術(shù)進(jìn)入汽車后最受關(guān)注的方向就是C-V2X蜂窩車聯(lián)網(wǎng)。很多人都知道C-V2X有Uu和PC5兩條鏈路但這兩條鏈路在實(shí)車場景中到底怎么分工、各自解決什么問題很多文章講得比較概念化。結(jié)合實(shí)車測試我把自己看到的東西拆開說說。2.1 Uu與PC5兩條鏈路的定位差異Uu是車和基站之間的蜂窩接口本質(zhì)上是“車-網(wǎng)絡(luò)”通信數(shù)據(jù)要經(jīng)過基站、核心網(wǎng)、應(yīng)用服務(wù)器繞一圈PC5是車與車、車與路側(cè)設(shè)備之間的直接通信接口不走基站適合近距離實(shí)時(shí)交互。用一句話概括Uu是“過網(wǎng)”通道PC5是“直達(dá)”通道。我整理了這兩條鏈路在幾個(gè)關(guān)鍵維度的差異方便對照看維度Uu接口PC5接口通信路徑車→基站→核心網(wǎng)→應(yīng)用平臺(tái)車→車/路側(cè)設(shè)備直接通信典型時(shí)延端到端20~50ms有MEC時(shí)通信單跳一般10ms左右覆蓋范圍依賴基站覆蓋全國性通信距離幾百米內(nèi)主要應(yīng)用紅綠燈推送、遠(yuǎn)程信息、OTA碰撞預(yù)警、協(xié)作式變道、盲區(qū)感知網(wǎng)絡(luò)依賴強(qiáng)依賴運(yùn)營商網(wǎng)絡(luò)無網(wǎng)也可用弱依賴Uu鏈路的價(jià)值在于“無處不在”只要有基站信號的地方就能提供云端服務(wù)PC5的價(jià)值在于“低延遲且不依賴網(wǎng)絡(luò)”尤其適合安全攸關(guān)的場景。兩者不是替代關(guān)系而是互補(bǔ)關(guān)系。在車路協(xié)同的開放道路上一輛車通常會(huì)同時(shí)工作在Uu和PC5兩條鏈路上PC5負(fù)責(zé)緊急消息的直連交互Uu負(fù)責(zé)與云端平臺(tái)之間的業(yè)務(wù)信息交互。我在實(shí)車測試中看到的一組典型數(shù)據(jù)是單一PC5鏈路的端到端延遲一般在10ms到20ms之間包含應(yīng)用層處理時(shí)間而Uu鏈路在MEC邊緣節(jié)點(diǎn)配合下通常能做到20ms到40ms。注意這里說的都是理想狀態(tài)一旦出現(xiàn)小區(qū)切換或網(wǎng)絡(luò)擁塞Uu鏈路的時(shí)延會(huì)出現(xiàn)抖動(dòng)后面第三節(jié)和第五節(jié)會(huì)詳細(xì)說。2.2 紅綠燈推送和綠波帶車速引導(dǎo)紅綠燈信息推送是C-V2X落地最早、也最容易讓用戶感知到的場景之一。傳統(tǒng)方案靠車載攝像頭識別紅綠燈問題非常明顯雨雪天看不清、前車大車遮擋、逆光時(shí)失效。而基于V2X的紅綠燈推送信號燈狀態(tài)由路側(cè)設(shè)備RSU從信號機(jī)直接采集再通過Uu或PC5鏈路發(fā)給車與天氣和遮擋無關(guān)。這個(gè)場景里最關(guān)鍵的數(shù)據(jù)是SPaT信號相位與配時(shí)消息和MAP地圖消息。SPaT描述的是當(dāng)前路口每個(gè)信號燈相位紅黃綠的狀態(tài)和剩余時(shí)間MAP描述的是路口的車道拓?fù)洹⑼Ｖ咕€位置、信號燈與車道的關(guān)系。車端拿到這兩份消息后才能在導(dǎo)航地圖上準(zhǔn)確匹配“我這個(gè)車道對應(yīng)的燈色和倒計(jì)時(shí)”。綠波帶車速引導(dǎo)是紅綠燈推送的高級應(yīng)用。云端或路側(cè)邊緣計(jì)算根據(jù)前方多個(gè)路口的SPaT信息和當(dāng)前車輛位置、車速逆向推算出“如果以某個(gè)速度行駛可以通過連續(xù)綠燈”的速度區(qū)間。這種計(jì)算需要路側(cè)設(shè)備把信號燈周期數(shù)據(jù)及時(shí)回傳同時(shí)需要車端具備較高精度的定位否則車速建議的誤差會(huì)很大。實(shí)測下來單獨(dú)靠GPS米級定位在路口停車線位置判斷上會(huì)有一兩秒的偏差加入RTK差分定位后情況會(huì)好得多。這里講一個(gè)我們在聯(lián)合調(diào)試中遇到的真實(shí)問題不同廠商的RSU發(fā)送的SPaT消息里相位編號Phase ID定義并不統(tǒng)一。同一個(gè)路口A廠RSU把左轉(zhuǎn)信號燈編為Phase 3B廠RSU編為Phase 5導(dǎo)致車機(jī)端連接不同路側(cè)設(shè)備時(shí)倒計(jì)時(shí)顯示混亂。這個(gè)問題不是通信鏈路的問題而是業(yè)務(wù)標(biāo)準(zhǔn)化的顆粒度問題最后只能通過路側(cè)設(shè)備的版本升級統(tǒng)一Phase ID映射邏輯。如果你正在做車端V2X應(yīng)用一定要兼容不同廠商的MAP消息差異不要把消息格式寫死。2.3 協(xié)作式變道與盲區(qū)預(yù)警的延遲預(yù)算安全攸關(guān)的V2X場景如協(xié)作式變道、盲區(qū)預(yù)警對延遲要求極其苛刻。一個(gè)完整的端到端延遲預(yù)算可以拆成這么幾段傳感器采集和車端感知、通信鏈路傳輸、接收端應(yīng)用處理、人類駕駛員或執(zhí)行器的響應(yīng)。分配給通信鏈路的預(yù)算通常只有幾十毫秒如果蜂窩鏈路在這個(gè)環(huán)節(jié)出現(xiàn)抖動(dòng)或丟包接收端就可能在最需要檢測的瞬間丟失關(guān)鍵消息。具體來說盲區(qū)預(yù)警場景中主車需要周期性地感知相鄰車道后方車輛的狀態(tài)。如果目標(biāo)車輛通過PC5廣播自己的位置、速度、航向BSM消息主車收到后計(jì)算碰撞時(shí)間TTC當(dāng)TTC低于閾值時(shí)發(fā)出警告。這個(gè)過程要求BSM消息的發(fā)送頻率至少10Hz也就是每100ms發(fā)一次。一旦通信鏈路出現(xiàn)超過200ms的抖動(dòng)車輛位置信息就會(huì)明顯滯后碰撞風(fēng)險(xiǎn)判斷就會(huì)失真。我們在一次多車聯(lián)調(diào)中就遇到過車輛行駛到某個(gè)基站覆蓋邊緣時(shí)Uu鏈路的空口時(shí)延從30ms跳到200多毫秒應(yīng)用層識別到“超時(shí)”直接把一批V2X消息判定為無效并丟掉了。結(jié)果是盲區(qū)預(yù)警功能在該路段頻繁“失靈”。后來把消息接收機(jī)制改成了“多鏈路冗余時(shí)間戳緩存容錯(cuò)判定”即使某條鏈路瞬時(shí)抖動(dòng)只要PC5鏈路在仍然能維持連續(xù)的安全預(yù)警輸出。這個(gè)問題的工程啟發(fā)是做安全類V2X應(yīng)用時(shí)通信鏈路的穩(wěn)定性比平均時(shí)延更重要。平均時(shí)延看起來只有30ms但P99時(shí)延可能已經(jīng)飆到300ms。測試時(shí)要重點(diǎn)盯P99和P999時(shí)延曲線而不是只看平均值。3. 蜂窩網(wǎng)絡(luò)如何支撐軟件定義汽車的遠(yuǎn)程能力軟件定義汽車喊了這么多年背后的核心基礎(chǔ)設(shè)施之一就是蜂窩網(wǎng)絡(luò)。無論OTA升級、遠(yuǎn)程控車還是云端診斷和電子圍欄本質(zhì)都依賴一條穩(wěn)定可靠的車云通信鏈路。這一章聊聊這些遠(yuǎn)程能力的鏈路設(shè)計(jì)以及一些不為人知的細(xì)節(jié)。3.1 OTA通道的設(shè)計(jì)與斷點(diǎn)續(xù)傳整車OTA是蜂窩網(wǎng)絡(luò)在車上“吃得最狠”的功能之一。一個(gè)完整的整車升級包動(dòng)輒幾個(gè)GB如果車云通道設(shè)計(jì)得不好很容易出現(xiàn)下載失敗、升級中斷、流量費(fèi)用爆炸等問題。OTA下載通道通常是這樣設(shè)計(jì)的車端先通過蜂窩模組連接OTA平臺(tái)請求升級任務(wù)平臺(tái)返回升級包下載地址通常是CDN的URL車載終端再通過HTTP/HTTPS協(xié)議從CDN拉取數(shù)據(jù)。這里的核心難點(diǎn)有兩個(gè)一是蜂窩網(wǎng)絡(luò)環(huán)境高度不穩(wěn)定二是升級包太大。斷點(diǎn)續(xù)傳是最基本的要求。汽車可能在任何地方下載升級包隧道、地下車庫、偏遠(yuǎn)地區(qū)隨時(shí)可能斷開。HTTP Range請求可以實(shí)現(xiàn)文件分片續(xù)傳車內(nèi)下載管理器負(fù)責(zé)記錄每個(gè)分片的完成狀態(tài)和校驗(yàn)值斷網(wǎng)恢復(fù)后從斷點(diǎn)繼續(xù)拉取。此外升級包通常建議做差分升級只下載變化部分的二進(jìn)制差異而不是整包下載可以大幅減小下載體積。一個(gè)實(shí)際案例是某次大版本OTA升級包超過8GB幾十輛測試車同時(shí)在同一個(gè)運(yùn)營商基站下下載直接被網(wǎng)關(guān)限速大量車輛下載失敗。后來加入了“多CDN節(jié)點(diǎn)調(diào)度分時(shí)段流量調(diào)度”把下載窗口錯(cuò)開問題才解決。蜂窩鏈路的QoS和APN配置對OTA體驗(yàn)影響很大。車聯(lián)網(wǎng)卡通常有專用APN和QoS優(yōu)先級配置比普通消費(fèi)者流量卡的網(wǎng)絡(luò)優(yōu)先級更高。如果車輛使用普通SIM卡做OTA高峰期會(huì)被網(wǎng)絡(luò)側(cè)限速到Kbps級別一個(gè)8GB的包可能要下載好幾天。做OTA平臺(tái)時(shí)務(wù)必向運(yùn)營商申請專用的車聯(lián)網(wǎng)APN并確認(rèn)QoS配置已經(jīng)落實(shí)到接入網(wǎng)。3.2 云端控車與遠(yuǎn)程診斷的數(shù)據(jù)鏈路遠(yuǎn)程解鎖、遠(yuǎn)程開空調(diào)、哨兵模式視頻回傳這些功能的鏈路基本可以歸納為手機(jī)App→云平臺(tái)→車端T-Box→整車域控制器。蜂窩通信在這條鏈路里承擔(dān)的是“最后一公里”和“最初一公里”的角色。車端和云平臺(tái)之間的通信通?；陂L連接實(shí)現(xiàn)。常見方案是MQTT或者自研TCP長連接車端主動(dòng)和云端建立連接后維持心跳保活云端下發(fā)指令時(shí)通過這個(gè)長連接推送。長連接在車輛休眠后會(huì)被斷開如何在車休眠時(shí)還能收到云端指令目前的主流方案是“云端等待網(wǎng)絡(luò)喚醒”車端進(jìn)入休眠后T-Box仍然保持一個(gè)低功耗的待機(jī)模式周期性喚醒和云端同步或者車端在進(jìn)入休眠前告訴云端“我大概多長時(shí)間醒來一次”云端在這個(gè)窗口內(nèi)下發(fā)消息緩存等車端醒來后再主動(dòng)拉取。這里想強(qiáng)調(diào)的是端到端時(shí)延的體驗(yàn)問題。用戶期望點(diǎn)擊App解鎖后1到2秒內(nèi)車輛響應(yīng)但在弱信號區(qū)域這條指令可能要跑5秒以上。這個(gè)鍋不全是通信模塊的可能是云端處理延遲、核心網(wǎng)調(diào)度、基站無線環(huán)境、車內(nèi)CAN網(wǎng)絡(luò)喚醒流程等多個(gè)環(huán)節(jié)累加的結(jié)果。產(chǎn)品設(shè)計(jì)上一定要做好超時(shí)狀態(tài)提示和重試機(jī)制避免用戶反復(fù)點(diǎn)擊造成指令風(fēng)暴。遠(yuǎn)程診斷是蜂窩上行鏈路的重要應(yīng)用。車輛每天會(huì)產(chǎn)生大量運(yùn)行數(shù)據(jù)電池狀態(tài)、電機(jī)參數(shù)、胎壓、充電狀態(tài)、故障碼等。這些數(shù)據(jù)通過蜂窩網(wǎng)絡(luò)周期性回傳云端支撐故障預(yù)警和遠(yuǎn)程診斷。數(shù)據(jù)傳輸?shù)牧考壱话悴淮蟮笫菍?shí)時(shí)性和可靠性。如果車輛駐留在弱網(wǎng)環(huán)境數(shù)據(jù)積壓會(huì)造成上報(bào)延遲需要車端數(shù)據(jù)網(wǎng)關(guān)有緩存和重傳機(jī)制。3.3 電子圍欄與蜂窩定位的配合電子圍欄是共享汽車、物流車隊(duì)、車輛防盜系統(tǒng)里常見的一個(gè)功能車輛出了某個(gè)地理范圍就報(bào)警。實(shí)現(xiàn)電子圍欄需要定位能力而定位來源不只有GNSS衛(wèi)星。GNSS定位在露天環(huán)境下精度很好但一旦車輛進(jìn)入地下車庫、室內(nèi)停車場、城市峽谷衛(wèi)星信號就會(huì)被遮擋或產(chǎn)生多徑反射定位精度驟降到幾十米甚至完全失鎖。這時(shí)候蜂窩定位作為兜底方案就派上了用場?；救嵌ㄎ?、指紋定位都可以提供幾十米到幾百米精度的位置估計(jì)雖然遠(yuǎn)不如GNSS但足以判斷“車輛是否超出了電子圍欄”。A-GNSS輔助全球?qū)Ш叫l(wèi)星系統(tǒng)是我特別想提的一個(gè)功能。車輛在冷啟動(dòng)時(shí)GNSS模塊需要搜索衛(wèi)星信號并下載星歷這個(gè)過程通常要30秒甚至更久。如果通過蜂窩網(wǎng)絡(luò)把星歷和歷書數(shù)據(jù)提前下發(fā)給車端定位模塊的首次定位時(shí)間TTFF可以縮短到幾秒。這個(gè)功能在緊急呼叫eCall場景里非常關(guān)鍵——事故發(fā)生后需要盡快上報(bào)精確位置每一秒都很寶貴。蜂窩網(wǎng)絡(luò)還承擔(dān)著RTK差分?jǐn)?shù)據(jù)的傳輸任務(wù)。RTK實(shí)時(shí)動(dòng)態(tài)差分定位實(shí)現(xiàn)厘米級定位需要在地面基準(zhǔn)站和車端之間實(shí)時(shí)傳輸差分改正數(shù)據(jù)通常通過NTRIP協(xié)議走蜂窩網(wǎng)絡(luò)下發(fā)。所以你會(huì)發(fā)現(xiàn)高精定位這個(gè)看起來完全屬于衛(wèi)星技術(shù)的領(lǐng)域?qū)嶋H上對蜂窩通信的實(shí)時(shí)性和穩(wěn)定性要求極高。蜂窩鏈路一旦斷流差分?jǐn)?shù)據(jù)中斷RTK定位就會(huì)退化為普通單點(diǎn)定位精度瞬間從厘米級跌到米級。我這里實(shí)測過幾類定位方式的精度對比供大家參考定位方式典型精度依賴條件普通GNSS2~5米露天、衛(wèi)星可見蜂窩基站定位50~500米基站密度覆蓋A-GNSS輔助定位秒級定位蜂窩網(wǎng)絡(luò)下發(fā)星歷RTK差分定位2~5厘米蜂窩網(wǎng)絡(luò)實(shí)時(shí)傳輸改正數(shù)據(jù)GNSSIMU組合城市峽谷抗遮擋傳感器融合4. 多網(wǎng)冗余與定位增強(qiáng)蜂窩技術(shù)如何與其他無線鏈路協(xié)同現(xiàn)代智能汽車上不會(huì)只裝蜂窩通信這一種無線技術(shù)GNSS、藍(lán)牙、Wi-Fi、PC5直連、甚至UWB都會(huì)并存。蜂窩移動(dòng)通信在其中扮演的角色已經(jīng)超越了“單打獨(dú)斗”而是作為一張核心協(xié)同網(wǎng)和其他鏈路共同保證整車在復(fù)雜環(huán)境下的通信連續(xù)性和定位可靠性。4.1 多運(yùn)營商eSIM策略與漫游切換蜂窩通信最怕的一件事是“有信號無網(wǎng)絡(luò)”或者“信號滿格但數(shù)據(jù)業(yè)務(wù)建立失敗”。一個(gè)很實(shí)際的問題是不同運(yùn)營商在不同區(qū)域的覆蓋質(zhì)量差異很大。地下車庫、偏遠(yuǎn)高速、隧道里A運(yùn)營商沒信號但B運(yùn)營商可能能連上。所以越來越多的車聯(lián)網(wǎng)項(xiàng)目開始采用多運(yùn)營商eSIM策略。eSIM相比傳統(tǒng)物理SIM卡最大的優(yōu)勢是可以遠(yuǎn)程切換碼號。車端可以預(yù)置多個(gè)運(yùn)營商的碼號配置文件或者通過遠(yuǎn)程碼號管理平臺(tái)下發(fā)新的運(yùn)營商配置。當(dāng)當(dāng)前運(yùn)營商網(wǎng)絡(luò)質(zhì)量差時(shí)車端可以切換到另一個(gè)運(yùn)營商的配置。但注意切換過程不是瞬間的——需要重新搜索網(wǎng)絡(luò)、附著、注冊、建立PDN會(huì)話整個(gè)過程通常要幾秒到十幾秒車輛正在行駛時(shí)切換可能造成短暫斷網(wǎng)。我在實(shí)車測試中看到過一個(gè)典型的失敗案例一臺(tái)車從國內(nèi)某個(gè)區(qū)域漫游到另一個(gè)區(qū)域運(yùn)營商歸屬發(fā)生變化后APN配置沒有自動(dòng)切換導(dǎo)致數(shù)據(jù)業(yè)務(wù)一直無法建立。最后靠遠(yuǎn)程下發(fā)正確APN配置才恢復(fù)連接。這個(gè)問題的根因是eSIM平臺(tái)沒有做“基于網(wǎng)絡(luò)側(cè)信息的APN自動(dòng)適配”。做多運(yùn)營商切換時(shí)一定要把APN、鑒權(quán)參數(shù)、DNS配置一起切換而不是只切碼號。運(yùn)營商對車聯(lián)網(wǎng)業(yè)務(wù)還有一個(gè)特別的限制規(guī)則某些套餐在特定時(shí)段晚高峰會(huì)對長時(shí)間大流量用戶進(jìn)行限速。這種限速不是通信故障但會(huì)導(dǎo)致車端應(yīng)用感知到“網(wǎng)速突然變慢”。我們測到過一次同一臺(tái)車在凌晨下載速率能到300Mbps晚高峰被限制到1Mbps差距兩個(gè)數(shù)量級。所以O(shè)TA任務(wù)調(diào)度一定要避開高峰時(shí)段。4.2 蜂窩與GNSS的融合定位前面第三章已經(jīng)提到了RTK差分定位通過蜂窩網(wǎng)絡(luò)傳輸這里想把“融合定位”整體的邏輯再講透一點(diǎn)。現(xiàn)代車輛定位系統(tǒng)基本是“衛(wèi)星信號蜂窩網(wǎng)絡(luò)慣導(dǎo)傳感器”三者融合單靠任何一個(gè)都無法保證全天候可用。GNSS提供全局絕對位置但在高架橋下、隧道里、林蔭道上很容易失鎖或產(chǎn)生多徑誤差蜂窩網(wǎng)絡(luò)可以提供粗位置作為初始估計(jì)和兜底同時(shí)承擔(dān)差分改正數(shù)據(jù)的傳輸通道IMU慣性測量單元提供短時(shí)高精度的相對位移在GNSS短暫失鎖時(shí)進(jìn)行航位推算。三者通過卡爾曼濾波融合后才能在城市峽谷、隧道、地下車庫等復(fù)雜環(huán)境中維持一個(gè)可靠的定位結(jié)果。一個(gè)實(shí)際場景車輛駛?cè)腴L隧道后GNSS信號立即消失如果沒有IMU定位點(diǎn)會(huì)停在隧道入口導(dǎo)航會(huì)一直提示“您已偏航”有IMU的情況下定位會(huì)按照隧道走向繼續(xù)推進(jìn)誤差在幾百米范圍內(nèi)。當(dāng)隧道內(nèi)正好有蜂窩基站信號時(shí)還可以用蜂窩定位做誤差修正。駛出隧道后GNSS重新鎖定定位恢復(fù)厘米級或米級精度。對自動(dòng)駕駛來說定位不能斷是底線。所以L3級以上的智能駕駛系統(tǒng)普遍會(huì)采用“GNSSIMURTK視覺/雷達(dá)語義匹配”的多源融合定位方案蜂窩網(wǎng)絡(luò)作為差分服務(wù)和地圖更新通道的角色非常關(guān)鍵。4.3 蜂窩與PC5直連的冗余PC5直連鏈路和蜂窩Uu鏈路之間也不只是分工關(guān)系更是一層安全冗余。在一些完全沒有基站覆蓋的偏遠(yuǎn)公路、地下停車場Uu鏈路可能完全不可用但車與車之間的PC5直連依然能工作。這意味著即便“車-云”失聯(lián)車與車之間的安全消息依然可以互傳。C-V2X的PC5鏈路本身也支持兩種模式一種是在網(wǎng)絡(luò)覆蓋內(nèi)的“模式A”由基站分配資源另一種是覆蓋外的“模式B”車輛自主選擇資源。在無覆蓋區(qū)域模式B讓V2V通信成為最后的保障。雙模終端在實(shí)際部署中會(huì)同時(shí)監(jiān)聽Uu和PC5消息。我在測試中發(fā)現(xiàn)一個(gè)值得注意的現(xiàn)象如果應(yīng)用層同時(shí)從兩條鏈路收到同一類型的安全消息需要做去重和融合判斷。不同鏈路的消息延遲不同簡單“誰先到用誰”可能會(huì)導(dǎo)致狀態(tài)跳變必須加上時(shí)間戳和消息序列號的雙重校驗(yàn)。5. 車載蜂窩通信的測試驗(yàn)證與安全防護(hù)最后一個(gè)部分聊一聊工程落地的“質(zhì)檢關(guān)”——測試驗(yàn)證以及車聯(lián)網(wǎng)躲不開的安全問題。這兩塊是車載蜂窩通信從“能跑”到“跑得穩(wěn)、跑得安全”的關(guān)鍵。5.1 從實(shí)驗(yàn)室到實(shí)車我跑過的那些測試車載蜂窩通信的測試可以分為五個(gè)層級模組級測試、天線級測試、整車級OTA測試、路測和可靠性測試。每個(gè)層級都在驗(yàn)證不同的問題。實(shí)驗(yàn)室射頻測試主要驗(yàn)證模組和天線的傳導(dǎo)性能包括發(fā)射功率、接收靈敏度、EVM誤差向量幅度、鄰道泄漏比、帶外雜散等指標(biāo)。這些測試在屏蔽室里完成可以排除外界干擾是快速判斷模組硬件是否存在問題的第一步。天線OTA測試在微波暗室中進(jìn)行測試整車的實(shí)際輻射性能和接收靈敏度。這個(gè)測試對天線布局優(yōu)化最有價(jià)值能直接看出鯊魚鰭、玻璃天線、車頂天線在不同頻段上的增益和方向圖。整車級OTA和單天線OTA的差異很大因?yàn)檐嚿矸瓷?、天線間耦合都會(huì)影響最終性能。路測是不可或缺的一環(huán)。測試路線要覆蓋高速、城市、隧道、地下車庫、山區(qū)、城鄉(xiāng)結(jié)合部等不同場景重點(diǎn)觀察弱場、切換、重選、擁塞、功耗等指標(biāo)。一條有效的路測路線應(yīng)該在30分鐘內(nèi)盡可能多地觸發(fā)小區(qū)切換和重選而不是在信號良好的城市主干道上繞圈?？煽啃詼y試包括高低溫存儲(chǔ)和工作、溫度循環(huán)、振動(dòng)、鹽霧、EMC電磁兼容。這部分測試周期長但最能暴露國產(chǎn)供應(yīng)鏈里“看似合格實(shí)則脆弱”的批次性問題。我的建議是在模組和T-Box的DV設(shè)計(jì)驗(yàn)證階段就要把溫度循環(huán)和EMC測試排在最高優(yōu)先級不要等項(xiàng)目后期再補(bǔ)。5.2 路測中那些被低估的“小問題”路測里真正讓人頭疼的往往不是通信模組的硬指標(biāo)不達(dá)標(biāo)而是一些軟件和網(wǎng)絡(luò)側(cè)的“軟問題”。這里分享幾個(gè)我實(shí)際遇到過的問題希望讀者不要再踩一遍。隧道掉線是路測里最常見的問題。車輛駛?cè)腴L隧道信號必然衰減關(guān)鍵是恢復(fù)速度。測量中發(fā)現(xiàn)有些車型出隧道后需要10秒以上才能重新注冊上網(wǎng)絡(luò)原因可能是小區(qū)重選參數(shù)配置不當(dāng)或者模組內(nèi)部殘留的歷史小區(qū)信息沒有及時(shí)清理。解決思路是聯(lián)合網(wǎng)絡(luò)側(cè)優(yōu)化重選參數(shù)和T-Reselection定時(shí)器同時(shí)在車端關(guān)閉不必要的省電模式。小區(qū)重選過慢造成的斷流也經(jīng)常遇到。車輛行駛在高速公路上從一個(gè)基站覆蓋區(qū)進(jìn)入另一個(gè)基站覆蓋區(qū)如果小區(qū)重選不及時(shí)應(yīng)用層的TCP連接就會(huì)超時(shí)。這個(gè)問題的本質(zhì)是“信號顯示滿格但數(shù)據(jù)傳不動(dòng)”。排查時(shí)不要只盯信號格數(shù)要看模組上報(bào)的RSRP、RSRQ、SINR和當(dāng)前駐留小區(qū)ID。我測到過一臺(tái)車信號顯示滿格但SINR只有-5dB數(shù)據(jù)業(yè)務(wù)基本處于不可用狀態(tài)。車內(nèi)大功率充電器對蜂窩信號的干擾是個(gè)隱藏很深的問題。我們曾經(jīng)在路測中反復(fù)遇到一個(gè)問題車輛充電狀態(tài)下蜂窩下行速率驟降。排查后發(fā)現(xiàn)是充電器內(nèi)部產(chǎn)生了頻段內(nèi)的雜散干擾導(dǎo)致接收靈敏度下降。這個(gè)問題在實(shí)驗(yàn)室里很難復(fù)現(xiàn)只有在實(shí)車充電狀態(tài)下測試才能暴露。建議在做整車電磁兼容設(shè)計(jì)時(shí)把充電器、逆變器這類功率器件和蜂窩天線的隔離度一并考慮進(jìn)去。跨省漫游后的數(shù)據(jù)掛死也值得提一句。某次路測車隊(duì)從A省開到B省部分車輛的數(shù)據(jù)業(yè)務(wù)在漫游切換后無法恢復(fù)頁面一直轉(zhuǎn)圈。排查后確認(rèn)是DNS緩存過期和APN配置在漫游場景下的適配問題。這個(gè)問題的修復(fù)方案不復(fù)雜但排查鏈路很長涉及運(yùn)營商核心網(wǎng)和車端軟件兩側(cè)。車端設(shè)置長連接/數(shù)據(jù)通道時(shí)要做漫游狀態(tài)監(jiān)聽漫游切換完成后強(qiáng)制刷新DNS緩存并重新建立數(shù)據(jù)會(huì)話。5.3 車聯(lián)網(wǎng)通信安全證書體系和鏈路加密蜂窩通信本身是一個(gè)無線廣播信道天然容易被監(jiān)聽和干擾。雖然沒有基站和核心網(wǎng)的密鑰用戶面的內(nèi)容被直接解密的難度很高但偽基站、中間人攻擊、重放攻擊等風(fēng)險(xiǎn)始終存在。車聯(lián)網(wǎng)的通信安全不是單一維度的問題而是“傳輸安全身份安全數(shù)據(jù)安全”三位一體。C-V2X的PC5接口消息采用PKI證書體系。每輛車都持有自己的證書消息需要簽名接收方通過驗(yàn)簽確認(rèn)消息來源合法。這里有一個(gè)細(xì)節(jié)為了隱私保護(hù)車輛會(huì)定期更換假名證書讓外部無法通過長期跟蹤同一條消息簽名來鎖定一臺(tái)車。這套證書管理機(jī)制在實(shí)車部署中非常依賴穩(wěn)定的蜂窩網(wǎng)絡(luò)——證書下載、更新、吊銷檢查都需要通過Uu接口和云端證書管理系統(tǒng)交互。如果車輛長期處于弱網(wǎng)環(huán)境證書更新不及時(shí)可能導(dǎo)致安全應(yīng)用無法正常工作。我見過不止一次因?yàn)槠髽I(yè)根證書過期沒有及時(shí)更新導(dǎo)致一整批測試車的V2X驗(yàn)簽全部失敗的案例。證書生命周期管理一定要和OTA通道綁定確保證書的及時(shí)輪換。蜂窩鏈路本身Uu接口通過LTE/5G空口加密和完整性保護(hù)機(jī)制防竊聽、防篡改。車端與云平臺(tái)之間的業(yè)務(wù)數(shù)據(jù)通道則通常使用TLS/DTLS加密配合雙向證書認(rèn)證。這里的實(shí)際難點(diǎn)是如何平衡安全和性能。TLS握手有延遲短數(shù)據(jù)頻繁連接會(huì)明顯增加時(shí)延但如果只圖快不做加密又可能讓車輛控制指令暴露在風(fēng)險(xiǎn)中。實(shí)踐中的做法是長連接建立一次TLS會(huì)話后續(xù)消息通過會(huì)話密鑰加密避免反復(fù)握手。5.4 最后再分享一點(diǎn)經(jīng)驗(yàn)做了這么多年車載通信我最深的體會(huì)是蜂窩通信在車?yán)镉肋h(yuǎn)不是“能上網(wǎng)”這么簡單。它是一條貫穿整車硬件、天線工程、網(wǎng)絡(luò)優(yōu)化、云平臺(tái)、安全體系的復(fù)雜鏈路。任何一個(gè)環(huán)節(jié)的短板都會(huì)在用戶的真實(shí)使用中被放大——信號滿格卻刷不出車控指令、OTA下載到99%卡住、地下車庫遠(yuǎn)程啟動(dòng)失敗這些都是鏈條上某個(gè)環(huán)節(jié)松了的癥狀。如果你正在做相關(guān)的聯(lián)調(diào)我給你的建議是先學(xué)會(huì)看模組日志和RF參數(shù)不要一上來就查應(yīng)用層代碼。RSRP、SINR、小區(qū)切換記錄、PDN連接狀態(tài)這些物理層信息往往能直接幫你把問題定位到“模組、天線、網(wǎng)絡(luò)、平臺(tái)”的某一個(gè)環(huán)節(jié)。排查鏈路清晰了問題就已經(jīng)解決一半。蜂窩通信技術(shù)本身很成熟但把它裝進(jìn)一臺(tái)持續(xù)移動(dòng)、環(huán)境多變、安全要求極高的汽車?yán)锕こ碳?xì)節(jié)永遠(yuǎn)比想象的多。這套經(jīng)驗(yàn)希望對你也有用。