我們知道,一輛車上的ECU數(shù)量少則幾十個,多則上百個。假設(shè)這樣一種場景,車輛由于某種原因?qū)е乱徊糠諩CU功能失效,需要重新更新這些ECU的Application程序,如果一個一個進(jìn)行更新,勢必花費一點時間,而作為消費者,總希望自己的車子能快點修好,維修人員又何嘗不是呢?所以,并列刷寫(Parallel Flash)和隊列刷寫(Queued Flash)來了。
再有,在車輛下線時EOL(End of Line),工廠追求效率,一般會1(刷寫上位機(jī))拖N(N個 ECU)刷寫,這是不是一種Parallel Flash呢?
再次提示:Queued Flash針對 單個ECU ,Parallel Flash針對 多個ECU ,且兩種技術(shù)可以同時使用。本文,我們認(rèn)識一下Parallel Flash。
1
整車網(wǎng)絡(luò)拓?fù)?/p>
在了解Parallel Flash之前,我們先認(rèn)識一下整車網(wǎng)絡(luò)拓?fù)?。為便于理解,我們簡單示意整車的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。整車網(wǎng)絡(luò)中,不僅僅只有Can總線,還會有Ethernet、Flexray以及Lin總線。
如上圖,整車中的網(wǎng)關(guān)可以分為三種類型:Vehicle GW(Edge Node)、ECU/Domain Network GW、ECU Sub GW。
Vehicle GW(Edge Node) :與外部設(shè)備(Tester)通過以太網(wǎng)通信,也稱為邊緣節(jié)點。邊緣節(jié)點與域網(wǎng)關(guān)通過主干網(wǎng)相連,主干網(wǎng)會選擇速率相對較高的總線,比如:Ethernet/Flexray。
ECU/Domain Network GW :域網(wǎng)關(guān),整車會分為動力域、影音域等多個域。域網(wǎng)關(guān)與子網(wǎng)關(guān)或者終端ECU連接,之間可以通過速率相對低一些的Can/Lin總線通信。
ECU Sub GW :子網(wǎng)關(guān),子網(wǎng)關(guān)之下會掛接終端ECU,子網(wǎng)關(guān)與終端ECU之間可以通過Can/Lin總線通信。
既然Ethernet的速率快,為啥還整這么多總線呢?誰家也不是地主,成本是每家OEM都很在乎的事,保證既定功能目標(biāo)的前提下,OEM會想方設(shè)法地降成本,不然,如何適應(yīng)叢林法則?Ethernet雖然快,但是成本高,所以,OEM的EE部門在整車的拓?fù)湓O(shè)計中,會考慮好總線的選擇。
2
Parallel Flash刷寫流程
假設(shè)有兩個ECU:ECU01和ECU02需要同時刷寫,且ECU01和ECU02均掛接在子網(wǎng)關(guān)GW-S下,子網(wǎng)關(guān)GW-S在中央網(wǎng)關(guān)GW-C下,上位機(jī)(Tester)通過以太網(wǎng)(DoIP)進(jìn)行刷寫。這里分兩種情況討論:
第一:GW的處理能力不足
第二:GW處理能力足夠
1、刷寫流程解析
假設(shè) :用功能尋址發(fā)送$19 02 08服務(wù),讀取ECU01和ECU02故障信息,回復(fù)信息需要 多幀傳輸 。
提示 :基于第一種情況討論
- Tester通過DoIP發(fā)送一幀功能尋址診斷請求(Request1 = $19 02 08)給GW-C;
- GW-C會立即應(yīng)答上位機(jī)(因為DoIP診斷請求使用Tcp協(xié)議),這相當(dāng)于Can總線的ACK應(yīng)答機(jī)制,同時將Request1通過Flexray總線路由給GW-S;
- GW-S進(jìn)一步將Request1由Flexray總線轉(zhuǎn)成Can總線路由給ECU01和ECU02;
- ECU01和ECU02在各自的P2Server時間內(nèi)給出響應(yīng),即:首幀(FF:Frist Frame)。 受限于GW-S的處理能力 ,GW-S先給ECU01發(fā)送FC.CTS(繼續(xù)連續(xù)幀發(fā)送,注意:這里使用物理尋址發(fā)送給ECU01),讓ECU01先發(fā)送CF(Consecutive Frame )幀,而讓ECU02等待ECU01處理完(給ECU02發(fā)送FC.Wait,物理尋址發(fā)送流控等待),當(dāng)GW-S處理完ECU01以后,再給ECU02發(fā)送FC.CTS( 物理尋址發(fā)送 ),完成ECU02的處理;
- GW-S將Can總線傳來的FF轉(zhuǎn)換成Flexray的STFU(Start Frame Unacknowledged),之后通過Flexray總線路由給GW-C;
- GW-C接收到GW-S轉(zhuǎn)發(fā)的ECU01 LF(Last Frame)幀以后,響應(yīng)Tester(DoIP Response ECU01);
- GW-C接收到GW-S轉(zhuǎn)發(fā)的ECU02 LF(Last Frame)幀以后,響應(yīng)Tester(DoIP Response ECU02)。
2、問題拓展
第一:如上的刷寫流程可以看出,診斷命令Request1經(jīng)過GW-C、GW-S,到診斷命令被處理(P2Server時間),路由消耗的時間不少,從這個角度考慮,能理解OEM為什么會約束嚴(yán)苛的路由時間了吧,就是為了提高刷寫的速率。
第二:功能尋址的診斷請求不僅發(fā)送給終端ECU(比如:上述的ECU01和ECU02),GW節(jié)點也需要處理該診斷指令(比如:上述的GW-C、GW-S)。
第三:我們常常看到這樣的約束條件:“ 功能尋址的$3E 00/80指令與物理尋址的非$3E 00/80指令同時請求某個ECU時,功能尋址的$3E 00/80指令需要優(yōu)先處理 ”。為什么呢?畢竟讓節(jié)點保持在編程會話更重要。
第四:上述我們看到的是DoIP發(fā)送功能尋址給到ECU01和ECU02,這是 同一個指令發(fā)送給不同的ECU 。而Parallel Flash中還有一種情況,DoIP分別給ECU01、ECU02發(fā)送物理尋址的指令(比如:$10 01),為什么可行?一般診斷中,Ethernet總線的速率是100Mbps,而Can總線速率為500kbps,Ethernet總線速率是Can總線通信速率的200倍,其數(shù)據(jù)的處理能力足以支撐以太網(wǎng)使用物理尋址給一定量的ECU分別****發(fā)送 不同的診斷指令 ,并處理各個ECU的響應(yīng)數(shù)據(jù)。
第五:每經(jīng)過一次GW,指令的路由都會有一定的延遲。
第六:GW處理能力足夠與否,首先需要看主芯片的資源是否夠用,雖然開辟更多的RAM去處理診斷指令可以使得刷寫速率更快(上圖中的第二種情況),但是面對的資源開銷也是相當(dāng)可觀。尤其當(dāng)總線轉(zhuǎn)換時,TP層、PduR模塊都需要開銷資源,而且開銷量都不小。
審核編輯:劉清
-
CAN總線
+關(guān)注
關(guān)注
145文章
1987瀏覽量
132884 -
ecu
+關(guān)注
關(guān)注
14文章
934瀏覽量
55835 -
Flash單片機(jī)
+關(guān)注
關(guān)注
0文章
111瀏覽量
9767
發(fā)布評論請先 登錄
認(rèn)識一下這款名叫“CAN總線存儲器”的神器
認(rèn)識一下NI SWITCH模塊的組成和特點

請教一下關(guān)于asmi_parallel ip核的使用方法
認(rèn)識嵌入式Linux
認(rèn)識一下針對單片機(jī)幾個基本概念
認(rèn)識一下Boost拓?fù)浣Y(jié)構(gòu)
先來認(rèn)識一下正激的基本原理
簡單地認(rèn)識一下D/A和A/D
帶你重新認(rèn)識了一下真正的PID
認(rèn)識一下甲醛傳感器
簡單認(rèn)識一下EMC中共模和差模的區(qū)別

認(rèn)識一下只有driver的驗證平臺

認(rèn)識一下幾個常用的門級電路

評論