搞臺(tái)架測(cè)試的人應(yīng)該都撞過(guò)這堵墻一條500 kbit/s的CAN總線原本跑得好好的接上測(cè)量模塊開(kāi)始灌數(shù)據(jù)儀表盤(pán)上的Bus Load肉眼可見(jiàn)地往上跳幾分鐘后丟幀、錯(cuò)誤幀、節(jié)點(diǎn)離線陸陸續(xù)續(xù)全來(lái)了。這不是設(shè)備質(zhì)量問(wèn)題而是總線的物理規(guī)律擺在那里。這篇文章我不繞彎子直接聊一個(gè)在整車(chē)測(cè)試和臺(tái)架試驗(yàn)里非常實(shí)用的組合方案用CAN測(cè)量模塊的總線負(fù)載控制配合X-Link以太網(wǎng)擴(kuò)展把大批量測(cè)量數(shù)據(jù)從CAN總線上安全地拆下來(lái)。先說(shuō)清楚思路的核心很多人以為掛一個(gè)CAN轉(zhuǎn)以太網(wǎng)網(wǎng)關(guān)就能降壓其實(shí)如果測(cè)量模塊還在往總線上發(fā)測(cè)量幀網(wǎng)關(guān)只是“換個(gè)地方讀數(shù)據(jù)”總線負(fù)載一點(diǎn)都不會(huì)降。真正有效的做法是從源頭分流——讓測(cè)量數(shù)據(jù)走以太網(wǎng)CAN總線只保留控制和狀態(tài)信息。下面我按負(fù)載計(jì)算、方案設(shè)計(jì)、實(shí)際配置、問(wèn)題排查四個(gè)部分展開(kāi)全部是實(shí)操經(jīng)驗(yàn)可以直接抄作業(yè)。1. 先算一筆賬CAN測(cè)量模塊的總線負(fù)載是怎么爆表的1.1 CAN總線的帶寬不是“共享”那么簡(jiǎn)單要理解總線負(fù)載控制得先回到物理層。經(jīng)典CAN總線是半雙工、多主通信同一時(shí)刻整條總線上只能有一個(gè)節(jié)點(diǎn)在驅(qū)動(dòng)總線收發(fā)數(shù)據(jù)。換句話說(shuō)500 kbit/s的波特率意味著每秒最多傳輸50萬(wàn)個(gè)bit這些bit里不只是有效數(shù)據(jù)還包括幀頭、仲裁字段、CRC、ACK、幀間隔等等。這里有個(gè)經(jīng)常被忽略的點(diǎn)CAN報(bào)文的協(xié)議開(kāi)銷(xiāo)非常大。一個(gè)標(biāo)準(zhǔn)CAN數(shù)據(jù)幀如果數(shù)據(jù)段是8字節(jié)在500 kbit/s下總線占用時(shí)間大約為120 bit數(shù)據(jù)內(nèi)容不同會(huì)略有差異與位填充有關(guān)。算下來(lái)8字節(jié)數(shù)據(jù)有效載荷只有64 bit協(xié)議和填充占了接近一半。所以CAN總線的“有效吞吐率”遠(yuǎn)低于它的物理波特率這也是測(cè)量數(shù)據(jù)一多就爆負(fù)載的根本原因。更麻煩的是CAN采用逐位仲裁機(jī)制所有節(jié)點(diǎn)同時(shí)搶總線ID越小優(yōu)先級(jí)越高。這意味著負(fù)載升高時(shí)低優(yōu)先級(jí)幀的發(fā)送延遲會(huì)急劇加大而且是不可預(yù)測(cè)的。工程上總線負(fù)載超過(guò)70%已經(jīng)要警惕超過(guò)80%基本就離事故不遠(yuǎn)了因?yàn)檠舆t和錯(cuò)誤率會(huì)進(jìn)入正反饋循環(huán)。1.2 一個(gè)典型臺(tái)架測(cè)量場(chǎng)景的負(fù)載演算我用一個(gè)真實(shí)比例的數(shù)據(jù)來(lái)算給大家看。假設(shè)某臺(tái)架測(cè)試系統(tǒng)CAN波特率500 kbit/s原車(chē)或ECU控制部分已經(jīng)占用了一定負(fù)載報(bào)文組報(bào)文數(shù)量平均周期單幀約定位數(shù)產(chǎn)生的負(fù)載控制報(bào)文A40個(gè)20ms118 bit40 × 118 ÷ 0.02 236000 bit/s狀態(tài)報(bào)文B30個(gè)100ms118 bit30 × 118 ÷ 0.1 35400 bit/s兩組相加是271400 bit/s占500 kbit/s的54.3%。也就是說(shuō)還沒(méi)接測(cè)量設(shè)備總線已經(jīng)過(guò)了一半?，F(xiàn)在測(cè)量模塊來(lái)了要采集16路溫度、16路壓力、8路振動(dòng)總共40路模擬量信號(hào)。假設(shè)每路信號(hào)16 bit一個(gè)CAN報(bào)文8字節(jié)能塞4路信號(hào)那么40路信號(hào)至少需要10個(gè)測(cè)量報(bào)文。如果測(cè)量周期要求10ms負(fù)載增加量是10 × 118 ÷ 0.01 118000 bit/s也就是23.6%。加上原有的54.3%總負(fù)載來(lái)到77.9%。這個(gè)數(shù)字在真實(shí)車(chē)上已經(jīng)很危險(xiǎn)了中等優(yōu)先級(jí)報(bào)文開(kāi)始出現(xiàn)偶發(fā)等待錯(cuò)誤幀開(kāi)始零星出現(xiàn)。如果甲方說(shuō)“測(cè)量周期壓到5ms”負(fù)載增加量直接翻倍到47.2%總負(fù)載101.5%總線徹底不可用。這種要求我在實(shí)際項(xiàng)目里遇到過(guò)不止一次——振動(dòng)和瞬態(tài)壓力信號(hào)確實(shí)需要高采樣率不是測(cè)試人員在無(wú)理取鬧。1.3 高負(fù)載帶來(lái)的連鎖反應(yīng)很多人以為總線負(fù)載高頂多是“報(bào)文發(fā)送慢一點(diǎn)”其實(shí)遠(yuǎn)不止如此。我把實(shí)際觀察到的故障鏈列出來(lái)第一環(huán)是仲裁延遲?？偩€忙時(shí)低優(yōu)先級(jí)幀的節(jié)點(diǎn)持續(xù)檢測(cè)到總線被占用發(fā)送請(qǐng)求不斷掛起幀的實(shí)際發(fā)送時(shí)刻與預(yù)期時(shí)刻產(chǎn)生偏移。第二環(huán)是發(fā)送超時(shí)。對(duì)于周期性報(bào)文控制器本地有發(fā)送緩沖和超時(shí)機(jī)制。延遲過(guò)大會(huì)導(dǎo)致驅(qū)動(dòng)層認(rèn)為發(fā)送失敗進(jìn)而報(bào)錯(cuò)或者觸發(fā)重發(fā)。第三環(huán)是錯(cuò)誤幀的雪崩效應(yīng)。節(jié)點(diǎn)在發(fā)送或接收中出錯(cuò)會(huì)主動(dòng)發(fā)出錯(cuò)誤幀錯(cuò)誤幀本身也要占用總線時(shí)間相當(dāng)于額外增加負(fù)載進(jìn)一步惡化總線狀況。第四環(huán)最嚴(yán)重錯(cuò)誤計(jì)數(shù)累積會(huì)讓節(jié)點(diǎn)進(jìn)入Bus Off狀態(tài)徹底脫離總線。此時(shí)測(cè)量模塊不僅丟數(shù)據(jù)連和主控的通信都斷了。我見(jiàn)過(guò)因?yàn)榭偩€負(fù)載過(guò)高多個(gè)ECU輪流下線最后整個(gè)臺(tái)架測(cè)試直接停擺的場(chǎng)面。所以在設(shè)計(jì)測(cè)量系統(tǒng)時(shí)不能只看“當(dāng)前負(fù)載100%滿不滿”而是要從源頭控制負(fù)載預(yù)算給總線留出足夠的裕度。2. 解決思路壓縮只能救急分流才是根治2.1 能壓的先壓信號(hào)打包、周期放寬、觸發(fā)發(fā)送在引入以太網(wǎng)擴(kuò)展之前通常先把CAN側(cè)的“純軟件優(yōu)化”做掉這是成本最低的手段。第一招是信號(hào)打包。CAN報(bào)文8字節(jié)數(shù)據(jù)段雖然不大但16 bit的信號(hào)能塞4個(gè)有的溫度信號(hào)甚至12 bit就夠。如果各信號(hào)各自成幀浪費(fèi)極大全部合并打包后報(bào)文數(shù)量能降到原來(lái)的四分之一甚至更低。第二招是周期放寬。溫度、液位這類(lèi)緩變信號(hào)10ms和100ms周期對(duì)數(shù)據(jù)質(zhì)量影響不大但總線負(fù)載差了一個(gè)數(shù)量級(jí)。我會(huì)按信號(hào)物理特性分級(jí)設(shè)置刷新周期而不是所有信號(hào)統(tǒng)一10ms。第三招是觸發(fā)式發(fā)送。對(duì)某些只在特定工況下變化的信號(hào)設(shè)置閾值或斜率觸發(fā)數(shù)據(jù)變化才發(fā)幀不變就不發(fā)。比如耐久測(cè)試?yán)锏挠蜏匦盘?hào)長(zhǎng)時(shí)間穩(wěn)定時(shí)幾乎不占總線。這些手段在做負(fù)載控制時(shí)應(yīng)當(dāng)優(yōu)先考慮因?yàn)楦膭?dòng)小、見(jiàn)效快。但它們有一個(gè)本質(zhì)上的天花板如果信號(hào)本身就是快速變化的比如振動(dòng)加速度、瞬態(tài)壓力采樣率不能降觸發(fā)式也沒(méi)意義那無(wú)論怎么壓縮數(shù)據(jù)量就在那里。2.2 壓縮的天花板經(jīng)典CAN一個(gè)幀只有8字節(jié)經(jīng)典CAN的8字節(jié)數(shù)據(jù)段是硬約束。我算過(guò)一筆賬如果測(cè)量系統(tǒng)需要100路信號(hào)、每路1 kHz采樣、每路16 bit純有效數(shù)據(jù)量是100 × 1000 × 2 200 KB/s也就是1.6 Mbit/s。而一條500 kbit/s的CAN總線即使全部用來(lái)傳輸100%有效數(shù)據(jù)也不夠用何況還有巨大的協(xié)議開(kāi)銷(xiāo)。CAN FD能解決一部分問(wèn)題數(shù)據(jù)段最大可以到64字節(jié)同樣帶寬下的有效吞吐能提升數(shù)倍。但現(xiàn)實(shí)場(chǎng)景里被測(cè)對(duì)象往往是老車(chē)型、老ECU總線上大多數(shù)節(jié)點(diǎn)不支持CAN FD不可能為了測(cè)量單獨(dú)把總線升級(jí)。就算支持CAN FD的大量數(shù)據(jù)幀同樣會(huì)占用總線時(shí)間影響原有報(bào)文延遲。所以一旦測(cè)量數(shù)據(jù)量超過(guò)總線的物理承載能力唯一的出路是分流而不是繼續(xù)在CAN協(xié)議層面死磕。2.3 X-Link的真正作用讓數(shù)據(jù)流走另一條路X-Link以太網(wǎng)擴(kuò)展的思路其實(shí)很樸素把測(cè)量數(shù)據(jù)和CAN控制數(shù)據(jù)拆到不同的物理通道上。CAN總線繼續(xù)做它擅長(zhǎng)的事——承載小流量、高實(shí)時(shí)性、確定性的控制和狀態(tài)信息而大批量的測(cè)量數(shù)據(jù)走以太網(wǎng)利用以太網(wǎng)百兆甚至千兆的帶寬來(lái)承擔(dān)。這里要強(qiáng)調(diào)一個(gè)容易踩坑的認(rèn)知誤區(qū)。我在項(xiàng)目里不止一次看到有人把“CAN轉(zhuǎn)以太網(wǎng)網(wǎng)關(guān)”串到總線上以為這樣就能降低負(fù)載結(jié)果總線負(fù)載紋絲不動(dòng)。原因是只要測(cè)量模塊還在向CAN總線發(fā)送測(cè)量幀網(wǎng)關(guān)無(wú)論怎么轉(zhuǎn)發(fā)總線上的流量沒(méi)有減少。真正的分流必須發(fā)生在源頭也就是讓測(cè)量模塊本身意識(shí)到“這批數(shù)據(jù)不要發(fā)CAN了直接走以太網(wǎng)”。X-Link在這個(gè)場(chǎng)景里可以是一個(gè)測(cè)量模塊的以太網(wǎng)擴(kuò)展接口也可以是一個(gè)緊耦合在測(cè)量模塊旁邊的橋接單元。關(guān)鍵在于它和測(cè)量模塊之間是數(shù)據(jù)通道級(jí)別的耦合不是簡(jiǎn)單地在CAN總線上掛一個(gè)被動(dòng)設(shè)備。測(cè)量模塊把采集到的批量數(shù)據(jù)封裝成UDP報(bào)文通過(guò)以太網(wǎng)直接發(fā)給上位機(jī)CAN側(cè)只保留命令、事件、少量狀態(tài)信息流量瞬間降下來(lái)。用這張表說(shuō)明分流前后的差異更直觀項(xiàng)目分流前分流后CAN總線上的測(cè)量幀每10ms 10幀0幀CAN總線上的控制/狀態(tài)幀原有原有測(cè)量數(shù)據(jù)通道500 kbit/s CAN百兆/千兆以太網(wǎng)總線負(fù)載壓力77.9%以上回到54.3%可擴(kuò)展性幾乎沒(méi)有余量可繼續(xù)加通道這也是整個(gè)方案的核心控制流與數(shù)據(jù)流分離讓每種通信機(jī)制都工作在它最舒適的區(qū)間。3. X-Link以太網(wǎng)擴(kuò)展的落地實(shí)操3.1 拓?fù)渑c硬件連接方式先說(shuō)硬件形態(tài)。X-Link在實(shí)際項(xiàng)目中通常有兩種用法第一種是集成式擴(kuò)展口測(cè)量模塊本身帶以太網(wǎng)口或者通過(guò)擴(kuò)展底座提供以太網(wǎng)能力。數(shù)據(jù)在模塊內(nèi)部采集后直接走以太網(wǎng)上傳根本不出現(xiàn)在CAN總線上。這種方式最干凈但要求測(cè)量模塊本身支持。第二種是外置式橋接測(cè)量模塊通過(guò)CAN或者專(zhuān)用的高速數(shù)據(jù)接口連到X-Link網(wǎng)關(guān)網(wǎng)關(guān)再走以太網(wǎng)。這種方案適合已采購(gòu)的舊測(cè)量模塊但配置時(shí)一定要確認(rèn)X-Link和測(cè)量模塊之間是“控制關(guān)系”而不是“總線監(jiān)聽(tīng)關(guān)系”否則又會(huì)回到“只轉(zhuǎn)發(fā)不降壓”的老路。物理接線方面我有幾條實(shí)際經(jīng)驗(yàn)以太網(wǎng)優(yōu)先用屏蔽雙絞線距離超過(guò)30米時(shí)用工業(yè)級(jí)交換機(jī)和工業(yè)網(wǎng)線避免長(zhǎng)距離繞線帶來(lái)的信號(hào)衰減。如果系統(tǒng)里要做時(shí)間同步交換機(jī)和網(wǎng)卡必須支持IEEE 1588PTP協(xié)議普通家用交換機(jī)會(huì)破壞時(shí)間戳精度。CAN側(cè)接線盡量短從測(cè)量模塊到總線節(jié)點(diǎn)不要拖很長(zhǎng)的飛線。屏蔽層單端接地防止地環(huán)路引入共模干擾。3.2 網(wǎng)絡(luò)參數(shù)與協(xié)議規(guī)劃以太網(wǎng)側(cè)配置看起來(lái)簡(jiǎn)單但有幾個(gè)參數(shù)會(huì)直接影響測(cè)量數(shù)據(jù)質(zhì)量。第一IP地址分配必須用靜態(tài)IP或者基于MAC地址的保留地址絕不能依賴(lài)DHCP自動(dòng)獲取。測(cè)試臺(tái)架一旦重啟DHCP重新分配地址可能導(dǎo)致上位機(jī)連接斷掉而且不好排查。第二傳輸層協(xié)議建議選UDP不要選TCP。這個(gè)可能與很多人的直覺(jué)相反但測(cè)量數(shù)據(jù)是實(shí)時(shí)流TCP的重傳機(jī)制在丟包時(shí)會(huì)阻塞后續(xù)數(shù)據(jù)造成延遲尖峰和采樣時(shí)間軸扭曲。而UDP丟一幀上位機(jī)記錄一下缺失計(jì)數(shù)下一幀繼續(xù)采樣對(duì)實(shí)時(shí)性影響更小。第三通信模式上單臺(tái)上位機(jī)用單播就行如果多臺(tái)PC要同時(shí)看同一路數(shù)據(jù)用組播更省帶寬。組播需要交換機(jī)支持IGMP Snooping不然后續(xù)會(huì)有意外流量。規(guī)劃的參數(shù)一般包括IP、端口、MTU、發(fā)送緩沖區(qū)深度和數(shù)據(jù)幀打包時(shí)間窗口。下面是一個(gè)典型配置示例供參考XLinkConfig Network ip192.168.1.10 mask255.255.255.0 gateway192.168.1.1/ Route sourceCAN:0x200-0x220 destUDP:192.168.1.50:5001/ Frame maxLength1400 timeWindow5ms/ Timestamp modePTP/ /XLinkConfig這里的核心是把CAN ID段0x200到0x220的報(bào)文路由到UDP端口5001數(shù)據(jù)幀打包長(zhǎng)度1400字節(jié)避免IP分片時(shí)間窗口5ms讓低數(shù)據(jù)率信號(hào)的幀不會(huì)等太久。3.3 CAN側(cè)過(guò)濾與路由規(guī)則設(shè)置X-Link配置里最容易忽略的是CAN側(cè)的過(guò)濾規(guī)則。我建議分三步設(shè)置第一步列出所有測(cè)量相關(guān)報(bào)文的ID范圍只路由這些幀到以太網(wǎng)。不要讓網(wǎng)關(guān)把所有CAN幀都轉(zhuǎn)發(fā)過(guò)去否則以太網(wǎng)側(cè)會(huì)收到大量無(wú)關(guān)控制報(bào)文干擾Wireshark分析和上位機(jī)處理。第二步明確哪些幀仍然要留在CAN總線上。比如診斷請(qǐng)求、節(jié)點(diǎn)心跳、緊急狀態(tài)幀這些應(yīng)該繼續(xù)走CAN甚至可以通過(guò)CAN側(cè)直接透?jìng)鞑唤?jīng)過(guò)以太網(wǎng)。第三步設(shè)置背壓策略。以太網(wǎng)斷線或者上位機(jī)停止接收時(shí)X-Link是緩存還是丟棄我的建議是丟棄并記錄計(jì)數(shù)。因?yàn)闇y(cè)量數(shù)據(jù)具有很強(qiáng)的時(shí)效性緩存一整箱舊數(shù)據(jù)在恢復(fù)網(wǎng)絡(luò)后一股腦發(fā)出去只會(huì)讓上位機(jī)收到一堆過(guò)時(shí)信號(hào)毫無(wú)意義。實(shí)際操作中我還會(huì)給每條路由配置獨(dú)立的UDP端口比如溫度信號(hào)發(fā)往5001端口壓力信號(hào)發(fā)往5002端口振動(dòng)信號(hào)發(fā)往5003端口。這樣上位機(jī)可以并行處理也方便單獨(dú)監(jiān)控每條數(shù)據(jù)流的丟包率。3.4 性能驗(yàn)證與數(shù)據(jù)質(zhì)量檢查配置完不能讓系統(tǒng)直接上線要先做一輪性能驗(yàn)證。我的固定動(dòng)作如下第一步用CANoe或者TSMaster模擬原車(chē)負(fù)載報(bào)文觀察插入測(cè)量模塊后總線負(fù)載的變化。驗(yàn)證結(jié)果應(yīng)該和我之前算的賬一致分流后總線負(fù)載應(yīng)當(dāng)回到原有水平而不是繼續(xù)爬升。第二步在以太網(wǎng)側(cè)抓包。用Wireshark監(jiān)聽(tīng)對(duì)應(yīng)的UDP端口統(tǒng)計(jì)每秒接收的幀數(shù)量、幀間隔抖動(dòng)、是否有亂序和重復(fù)幀。特別關(guān)注延遲抖動(dòng)也就是相鄰幀到達(dá)時(shí)間間隔的標(biāo)準(zhǔn)差這個(gè)指標(biāo)比平均延遲更能反映鏈路是否平穩(wěn)。第三步檢查時(shí)間戳精度。帶PTP同步的X-Link不同模塊間的采樣時(shí)間戳偏差應(yīng)該保持在微秒級(jí)沒(méi)有PTP時(shí)也要通過(guò)軟件校準(zhǔn)把偏差控制在可接受范圍內(nèi)。下面是我習(xí)慣記錄的驗(yàn)證指標(biāo)表格指標(biāo)合格標(biāo)準(zhǔn)備注CAN總線負(fù)載低于60%分流后應(yīng)回落以太網(wǎng)吞吐量低于鏈路帶寬的60%避免交換機(jī)擁塞UDP丟包率低于0.1%峰值也不能超0.5%端到端平均延遲小于10ms含CAN采集與以太網(wǎng)上傳延遲抖動(dòng)小于2ms影響采樣時(shí)間軸多模塊時(shí)間偏差小于100us需PTP支持4. 實(shí)測(cè)中的常見(jiàn)問(wèn)題與排查技巧4.1 總線負(fù)載沒(méi)超但總線上還是大量錯(cuò)誤幀這種情況在真實(shí)項(xiàng)目里很常見(jiàn)計(jì)算結(jié)果負(fù)載只有50%Error Frame卻刷屏。根本原因往往是物理層問(wèn)題而不是流量問(wèn)題。優(yōu)先級(jí)最高的排查項(xiàng)是CAN收發(fā)器的位定時(shí)采樣點(diǎn)設(shè)置。CAN控制器在采樣點(diǎn)讀取總線電平采樣點(diǎn)太靠后或太靠前對(duì)總線傳播延遲和時(shí)鐘偏差的容忍度都會(huì)下降。工程上推薦采樣點(diǎn)設(shè)置在75%到87.5%之間經(jīng)典CAN的標(biāo)準(zhǔn)配置一般是80%。不同節(jié)點(diǎn)的采樣點(diǎn)差異過(guò)大會(huì)直接導(dǎo)致位錯(cuò)誤。第二個(gè)排查點(diǎn)是總線長(zhǎng)度和線纜質(zhì)量。500 kbit/s下總線長(zhǎng)度超過(guò)100米就可能出現(xiàn)信號(hào)反射尤其用質(zhì)量差的雙絞線時(shí)隱性電平回波會(huì)導(dǎo)致CRC錯(cuò)誤。把總線縮短、換屏蔽雙絞線、重新壓接端子往往比改軟件更管用。第三個(gè)是終端電阻?？偩€段落兩端必須各有一個(gè)120歐姆終端電阻不能只在測(cè)量模塊這一端加也不能用“一拖二”的方式在兩個(gè)設(shè)備上各加120歐姆那樣并聯(lián)后阻值不對(duì)。用萬(wàn)用表在總線斷電狀態(tài)下測(cè)量CAN_H和CAN_L之間的直流電阻應(yīng)該約60歐姆。4.2 X-Link丟包和斷流如何排查以太網(wǎng)側(cè)丟包的原因比CAN復(fù)雜但排查路徑是固定的。先看X-Link自身的告警計(jì)數(shù)確認(rèn)丟包發(fā)生在發(fā)送端、網(wǎng)絡(luò)鏈路還是接收端。如果是X-Link發(fā)送端丟包說(shuō)明內(nèi)部緩沖區(qū)溢出需要調(diào)整數(shù)據(jù)打包時(shí)間窗口或者減小單幀負(fù)載。如果發(fā)送端沒(méi)有告警懷疑點(diǎn)要轉(zhuǎn)到交換機(jī)和PC網(wǎng)卡。很多測(cè)試用筆記本是Wi-Fi連接Wi-Fi的延遲抖動(dòng)和丟包率根本滿足不了測(cè)量要求必須先切有線。有些Windows機(jī)器默認(rèn)UDP接收緩沖區(qū)過(guò)小高速數(shù)據(jù)流直接丟在系統(tǒng)內(nèi)核緩沖區(qū)應(yīng)用層毫無(wú)感知這種情況需要手動(dòng)調(diào)大注冊(cè)表里的UDP緩沖區(qū)。還有一類(lèi)容易被忽略的問(wèn)題是網(wǎng)卡節(jié)能模式PC網(wǎng)卡默認(rèn)可能開(kāi)啟EEE節(jié)能以太網(wǎng)或者電源管理導(dǎo)致鏈路偶爾“休眠”幾十毫秒表現(xiàn)為周期性丟包。在網(wǎng)卡高級(jí)設(shè)置里把“節(jié)能以太網(wǎng)”和“Green Ethernet”關(guān)掉往往能解決。4.3 多模塊時(shí)間戳對(duì)不齊如果系統(tǒng)里有多臺(tái)測(cè)量模塊經(jīng)常會(huì)出現(xiàn)同一時(shí)刻采集的數(shù)據(jù)在回看時(shí)差了幾毫秒甚至幾十毫秒。這不是數(shù)據(jù)傳錯(cuò)了而是各模塊的本地時(shí)鐘沒(méi)有對(duì)齊。解決辦法是使用PTP協(xié)議做硬件時(shí)間同步。前提是X-Link、交換機(jī)和PC都支持IEEE 1588并且PTP報(bào)文沒(méi)有被交換機(jī)阻斷。實(shí)際配置時(shí)要把其中一臺(tái)設(shè)備設(shè)為PTP主時(shí)鐘其余從時(shí)鐘自動(dòng)同步。如果網(wǎng)段里還有普通流量建議給PTP報(bào)文打VLAN標(biāo)簽并設(shè)置高優(yōu)先級(jí)避免網(wǎng)絡(luò)擁塞影響同步精度。沒(méi)有PTP能力的老設(shè)備只能通過(guò)軟件方式校準(zhǔn)在上位機(jī)里記錄CAN側(cè)時(shí)間戳和以太網(wǎng)側(cè)時(shí)間戳之間的固定偏移再用這個(gè)偏移修正。這種方案精度一般只適合時(shí)間精度要求不高的場(chǎng)合。4.4 分流后上位機(jī)還在讀舊數(shù)據(jù)源最后說(shuō)一個(gè)我踩過(guò)的大坑。做了分流改造后CAN總線負(fù)載確實(shí)降下來(lái)了但上位機(jī)軟件還在按老配置從CAN卡讀取測(cè)量報(bào)文結(jié)果就是界面上的數(shù)據(jù)一陣一陣地?cái)嗔?、重連。原因很簡(jiǎn)單測(cè)量模塊不再把新數(shù)據(jù)發(fā)到CAN總線上位機(jī)卻還在等CAN報(bào)文。排查時(shí)第一反應(yīng)以為是X-Link壞了查了半天才發(fā)現(xiàn)是上位機(jī)的數(shù)據(jù)源配置沒(méi)改。所以分流改造必須同步進(jìn)行兩端配置測(cè)量模塊側(cè)把測(cè)量幀路由到以太網(wǎng)上位機(jī)側(cè)把測(cè)量數(shù)據(jù)源從“CAN通道”切換到“X-Link以太網(wǎng)通道”同時(shí)保留CAN通道用于讀取心跳、狀態(tài)和控制信息。忘記改任何一端系統(tǒng)都跑不順暢。最后再分享一點(diǎn)個(gè)人體會(huì)總線負(fù)載控制這件事表面上看是配置和計(jì)算問(wèn)題本質(zhì)上是在給通信系統(tǒng)做“預(yù)算管理”。每個(gè)報(bào)文、每個(gè)周期、每條數(shù)據(jù)流都在消耗有限的總線資源測(cè)量模塊接入前先把這筆賬算清楚就不會(huì)等總線爆了再去救火。X-Link這類(lèi)以太網(wǎng)擴(kuò)展方案的價(jià)值不只是帶寬大而是讓CAN總線重新變得確定、可控。測(cè)試系統(tǒng)越做越大的時(shí)候這種“各走各路”的思路會(huì)越來(lái)越重要。