我們知道，一輛車上的ECU數量少則幾十個，多則上百個。假設這樣一種場景，車輛由于某種原因導致一部分ECU功能失效，需要重新更新這些ECU的Application程序，如果一個一個進行更新，勢必花費一點時間，而作為消費者，總希望自己的車子能快點修好，維修人員又何嘗不是呢？所以，并列刷寫(Parallel Flash)和隊列刷寫(Queued Flash)來了。

再有，在車輛下線時EOL(End of Line)，工廠追求效率，一般會1(刷寫上位機)拖N(N個 ECU)刷寫，這是不是一種Parallel Flash呢？

再次提示：Queued Flash針對 單個ECU ，Parallel Flash針對 多個ECU ，且兩種技術可以同時使用。本文，我們認識一下Parallel Flash。

1

整車網絡拓撲

在了解Parallel Flash之前，我們先認識一下整車網絡拓撲。為便于理解，我們簡單示意整車的網絡拓撲結構。整車網絡中，不僅僅只有Can總線，還會有Ethernet、Flexray以及Lin總線。

如上圖，整車中的網關可以分為三種類型：Vehicle GW(Edge Node)、ECU/Domain Network GW、ECU Sub GW。

Vehicle GW(Edge Node) ：與外部設備（Tester）通過以太網通信，也稱為邊緣節點。邊緣節點與域網關通過主干網相連，主干網會選擇速率相對較高的總線，比如：Ethernet/Flexray。

ECU/Domain Network GW ：域網關，整車會分為動力域、影音域等多個域。域網關與子網關或者終端ECU連接，之間可以通過速率相對低一些的Can/Lin總線通信。

ECU Sub GW ：子網關，子網關之下會掛接終端ECU，子網關與終端ECU之間可以通過Can/Lin總線通信。

既然Ethernet的速率快，為啥還整這么多總線呢？誰家也不是地主，成本是每家OEM都很在乎的事，保證既定功能目標的前提下，OEM會想方設法地降成本，不然，如何適應叢林法則？Ethernet雖然快，但是成本高，所以，OEM的EE部門在整車的拓撲設計中，會考慮好總線的選擇。

2

Parallel Flash刷寫流程

假設有兩個ECU：ECU01和ECU02需要同時刷寫，且ECU01和ECU02均掛接在子網關GW-S下，子網關GW-S在中央網關GW-C下，上位機（Tester）通過以太網(DoIP)進行刷寫。這里分兩種情況討論：

第一：GW的處理能力不足

第二：GW處理能力足夠

1、刷寫流程解析

假設 ：用功能尋址發送$19 02 08服務，讀取ECU01和ECU02故障信息，回復信息需要 多幀傳輸 。

提示 ：基于第一種情況討論

1. Tester通過DoIP發送一幀功能尋址診斷請求（Request1 = $19 02 08）給GW-C；
2. GW-C會立即應答上位機（因為DoIP診斷請求使用Tcp協議），這相當于Can總線的ACK應答機制，同時將Request1通過Flexray總線路由給GW-S;
3. GW-S進一步將Request1由Flexray總線轉成Can總線路由給ECU01和ECU02；
4. ECU01和ECU02在各自的P2Server時間內給出響應，即：首幀（FF:Frist Frame）。 受限于GW-S的處理能力 ，GW-S先給ECU01發送FC.CTS（繼續連續幀發送，注意：這里使用物理尋址發送給ECU01），讓ECU01先發送CF（Consecutive Frame ）幀，而讓ECU02等待ECU01處理完（給ECU02發送FC.Wait，物理尋址發送流控等待），當GW-S處理完ECU01以后，再給ECU02發送FC.CTS（ 物理尋址發送 ），完成ECU02的處理；
5. GW-S將Can總線傳來的FF轉換成Flexray的STFU(Start Frame Unacknowledged)，之后通過Flexray總線路由給GW-C;
6. GW-C接收到GW-S轉發的ECU01 LF（Last Frame）幀以后，響應Tester（DoIP Response ECU01）;
7. GW-C接收到GW-S轉發的ECU02 LF（Last Frame）幀以后，響應Tester（DoIP Response ECU02）。

2、問題拓展

第一：如上的刷寫流程可以看出，診斷命令Request1經過GW-C、GW-S，到診斷命令被處理(P2Server時間），路由消耗的時間不少，從這個角度考慮，能理解OEM為什么會約束嚴苛的路由時間了吧，就是為了提高刷寫的速率。

第二：功能尋址的診斷請求不僅發送給終端ECU（比如：上述的ECU01和ECU02），GW節點也需要處理該診斷指令（比如：上述的GW-C、GW-S）。

第三：我們常常看到這樣的約束條件：“ 功能尋址的$3E 00/80指令與物理尋址的非$3E 00/80指令同時請求某個ECU時，功能尋址的$3E 00/80指令需要優先處理 ”。為什么呢？畢竟讓節點保持在編程會話更重要。

第四：上述我們看到的是DoIP發送功能尋址給到ECU01和ECU02，這是 同一個指令發送給不同的ECU 。而Parallel Flash中還有一種情況，DoIP分別給ECU01、ECU02發送物理尋址的指令(比如：$10 01)，為什么可行？一般診斷中，Ethernet總線的速率是100Mbps，而Can總線速率為500kbps，Ethernet總線速率是Can總線通信速率的200倍，其數據的處理能力足以支撐以太網使用物理尋址給一定量的ECU分別****發送 不同的診斷指令 ，并處理各個ECU的響應數據。

第五：每經過一次GW，指令的路由都會有一定的延遲。

第六：GW處理能力足夠與否，首先需要看主芯片的資源是否夠用，雖然開辟更多的RAM去處理診斷指令可以使得刷寫速率更快（上圖中的第二種情況），但是面對的資源開銷也是相當可觀。尤其當總線轉換時，TP層、PduR模塊都需要開銷資源，而且開銷量都不小。

審核編輯：劉清