【圖解UDS】UDS診斷開發流程及Vector解決方案工具鏈介紹
目錄
爲了便於學習ISO 14229 UDS診斷協議，提供三個資源鏈接：
2.3 診斷解決方案 – CANdelaStudio/ODXStudio建議
爲了便於學習ISO 14229 UDS診斷協議，提供三個資源鏈接：
a) 【圖解UDS】UDS汽車診斷標準協議（ISO 14229）帶你入門到精通
b) ISO 14229 -Part1，2，3，4，5，6，7 UDS最新標準文件獲取路徑
c) ISO 14229 Road vehicles — Unified diagnostic services (UDS)標準各Part部分修訂和發佈狀態彙總
0 前言
下面給大家介紹的是Vector診斷全流程解決方案。講解主要分爲以下幾個部分：診斷的使用案例；Vector解決方案以及小結。
汽車診斷目的是爲了在有限的時間和成本下，快速獲取ECU和車輛的故障信息，便於維修維護。Vector在整個診斷流程中，提供診斷方法和診斷工具以及有關的診斷服務。
1 診斷用例
診斷功能的實現以及測試，在車輛開發中越來越重要，原因呢，是因爲現在的汽車網絡越來越複雜，ECU越來越多，控制策略越來越複雜，每個國家也對汽車排放有相關的法規要求，爲了避免故障無法排查等問題，就需要在開發階段對車輛的診斷功能的實現和驗證進行嚴格的處理，避免後端無法很好的使用診斷功能。
在診斷流程中，ECU供應商根據整車廠的診斷需求以及ECU自身功能需求開發的診斷功能，生產售後會使用ECU或者說整個車輛的一個診斷功能。
診斷通信是Tester和車輛的一個直接通信，所以診斷功能的實現，實際上就是兩種通信的一個規則實現，而通信規則就是由我們常說的診斷協議來定義的，它定義了診斷請求響應的格式，ECU對診斷請求處理的邏輯等等，現在行業內常用的診斷協議，ISO 14229 UDS協議；ISO 15765 CAN總線診斷的傳輸層協議；ISO15031排放相關的OBD協議；ISO 14230 部分整車廠還會使用到的kwp2000的協議，這個協議在UDS之前常用的一種診斷協議。
診斷功能實現後，當然也需要進行測試驗證，診斷測試通常有幾個部分的測試：診斷協議的測試，例如報文格式的測試；傳輸層的測試，例如傳輸層相關時間參數的測試；第3個就是診斷應用的測試，例如會話安全集轉換的一個測試；DID具體數值的測試等等。
診斷流程遵循“V-L型”的一個開發和使用流程，“V”是指開發階段，從需求定義到代碼實現，到集成測試；L是指生產售後階段是使用診斷功能的一個階段。
傳統的診斷開發流程中，診斷數據的交互都是使用機器不可讀的格式文件，比如Excel，PDF等，那麼在整個的開發流程當中會涉及到整車廠，系統供應商，不同的公司，不同的部門，每個工程師根據自己的經驗，對於同一份診斷需求文件的解讀，有可能會出現偏差，例如開發工程師和測試工程師對同一句話的理解不同，則會導致測試不通過，然後又需要重新回到需求定義的部分去完善或者解釋這條需求，從而導致需求定義時間過長，致使整個開發週期延長。
就好比驛站傳書這個遊戲一句話或者一幅圖，每個人用自己的語言描述給下一個人，往往最後一個人描述的東西和第一個人會有很大的一個偏差。
2 Vector診斷解決方案
基於這樣的問題，Vector提出一種以機器可讀的診斷數據庫爲核心的診斷開發全流程解決方案。
因爲機器對於數據的解讀，不會像人工解讀有那麼多經驗理解在裏面，可以很好的把數據傳遞到每一個階段，從而保證整個開發階段的數據的一致性，有效的縮短開發週期，機器可讀的診斷數據庫其實就是將傳統的Excel調查表等信息編輯成CDD或ODX文件。CDD是Vector私有的一種診斷數據庫格式；ODX是國際標準的診斷數據交互格式。CANdelaStudio編輯CDD文件，以及也可以導出ODX文件，ODX Studio用於編輯ODX文件，診斷數據庫的編輯其實就是診斷需求的定義。在需求定義完後，代碼實現可以通過診斷數據庫生成診斷相關的代碼以及應用層接口函數。Vector的診斷部分代碼包括：Non_Autosar標準的CANdesk；以及Autosar標準的MICROSAR DIAG。
功能實現後我們有CANOE.Diva，通過獲取診斷數據庫中的數據定義，自動生成測試用例，然後CANOE執行測試用例並生成測試報告，CANOE，CANalyzer ，CANape可以導入診斷數據庫後手動收發診斷服務或者編寫診斷腳本，Indigo是Vector的一個參數化的診斷儀，另外與診斷相關的功能的刷寫功能，Vector也提供刷寫上位機工具vFlash，下面我們就具體來看一下相關的工具。
2.1 診斷解決方案 - CANdelaStudio
CANdelaStudio用於編輯機器可讀的診斷數據庫CDD文件的工具，在編輯CDD文件的時候我們需要有一個Template，也就是CDDt來保證我們CDD文件的一個有效性。
CDDt所對應的其實是主機廠提供的一個整車級別的診斷需求規範，而每一個CDD文件對應的是每一個ECU的一個診斷需求規範，所以CDDt通常會有兩種可能，第1種，有一些主機廠向Vector定製了他們相對應的這個CDDt文件，或者他們自己有自己編輯好的這個相對應的CDDt文件，他可以直接釋放給系統供應商去編輯CDD文件，另外也會有一些主機廠，它不提供CDDt文件。
所以Vector CANdelaStudio工具裏面會自帶這個Vector標準的一個CDDt文件，那麼，在用戶在編輯的時候，可以基於Vector標準的CDDt文件去編輯自己需要的CDDt，然後再建立自己需要的一個CDD文件。
診斷數據庫裏面有3大部分的內容：ECU Information通信參數的部分；Diagnostic class診斷服務的部分；States定義的就是我們會話安全集的部分。
我們下面具體來看這幾個窗口，首先，ECU Information當中的Interfaces接口，它定義的是不同接口下的通信參數，比如說CAN接口相關的通信參數；以太網接口相關的通信參數，那都定義在我們相對應的這個接口信息裏面，那所有的接口都需要在CDDt裏面定義好，也就是編輯CDD文件的時候，不需要新建這個相關的接口，只需要激活你相對應的總線的接口，然後編輯你相對應的通信參數。
服務的部分，每一條服務都有一個窗口來進行一個編輯，那每一個服務下面相對應的這個參數呢，也都有相對應的標籤頁來進行編輯，比如說當前這個窗口裏面就是我們DTC的一個編輯的界面。
第3個部分我們會話和安全集狀態的一個設置，會話和安全集是兩個獨立的狀態，這兩個狀態呢，在CDD文件裏面會有兩個獨立的表格，在這個表格裏面可以針對你每一條服務精確到每個Subfunction，精確到每一個DID，來建立你在某一個會話，某一個安全集下，是否可以執行，或者涉及到相應的狀態跳轉，在狀態跳轉機制設置好後，我們可以有圖形化的顯示，來顯示你相對應的狀態之間，通過什麼樣的服務來進行跳轉，那我們可以直觀的去檢查，我們的狀態跳轉是否正確。
除了我們上面說的3個部分呢，是我們描述一個診斷需求規範必要的三個部分，另外呢CANdelaStudio也可以用來描述需求，也就是我們可以做一個需求的匹配，比如說我們從我們另外一個provision裏面可以導出我們的診斷需求文件CSV，在這個需求文件裏面定義了我有10條DID的一個需求，那我就可以映射到我現在定義的在CDD文件裏面定義的相關的DID，然後我實際需求文檔裏面的DID，然後做一個匹配，然後來看一下我現在的CDD文件是否已經滿足我所有的一個需求。
CANdelaStudio除了可以去建立CDD文件以外，也可以支持多種文件的一個導入和導出，在這裏呢，大家可能比較關心的一個是CDD可以導出ODX文件，另外呢就是CDD可以導出ARXML文件，那CDD可以導出的是國際標準的ODX 2.0.1，2.1.0和2.2.0。
那當然，這裏導出的呢，只是符合相關的ISO標準的，如果說某一個企業它有自己的一個定製化的ODX標準，那麼這個時候我們是需要做一個定製化的開發，來保證相關的CDD文件可以導出符合這個企業級的ODX實現指南的。
另外呢CDD導出的arxml文件，這裏的arxml文件包含的是Autosar標準裏面所說的dext，也就是dextract僅僅只診斷的這個相關的部分。
2.2 診斷解決方案 - ODXStudio
ODX全稱Open Diagnostic Data Exchange (開放式的診斷數據交互格式)，一開始是由ASAM組織提出的，那也就是我們通常所說的什麼ODX 2.0.1，ODX 2.2.0，其實指的是ASAM當時定義的ODX的一個標準編號。
現在我們所讀到的ISO 22901這個ODX標準是基於ASAM的ODX 2.2.0來進行定義的，ODX標準裏面，它定義4個部分的內容，第一個是UML建模，通過這種建模語言，來描述不同的層級不同的參數之間的一個關聯關係，那在實際使用的時候呢，是將UML建模轉換成XML結構，也就是ODX文件，實質上是一種XML語言結構的一個文件。
第3個部分當然會有一些文本的描述在標準裏面，第4個部分呢就是我們的校驗規則，ODX作爲一種國際標準的數據庫交互格式，不同的層級存放什麼樣的內容，怎麼樣怎麼樣去定義，我相應的這些數據都是有相應的一些規則的，那麼都是需要進行校驗的。
ODX文件它包含幾大類的數據，首先第一個ODX-D描述了診斷數據和診斷服務；ODX-C描述了通信參數；ODX-V描述了整車的拓撲結構，這三個部分呢是描述的診斷數據庫的部分，除此以外還可以描述其他和診斷相關的一些文件，比如說ODX-F描述的是刷寫數據文件，在加載傳統Hex,S19，bin文件以後呢，可以添加一些Check sum，或者security等等相關的一些信息，把他封裝成一個標準的ODX-F文件；ODX-E更多的呢用在主機廠生產車間裏面，在車輛出廠前，對車輛進行相應的一些配置，那ODX-E描述的就是這些配置的相關數據；ODX-FD功能導向的一個ODX文件，在4S店裏面通常售後階段，我們需要不是某一個ECU相關的數據，而是車輛某一個功能的集合的這樣一個數據，所以ODX-FD通常會使用在售後階段，尤其是像4S店裏面；ODX-M多ECU的Jobs，這個部分現在行業內已經沒有人使用了，所以我們現在最多會用到的ODX文件會包含以下的6個部分。
在描述一個ODX文件的時候，我們需要注意的是，ODX標準本身它定義的很寬泛，你可以把它想象成它是描述了一個100%的內容，而每一個工具，不同家的工具在實現ODX的時候，它可能都會滿足其中的可能70~80%這樣一個需求，就會造成工具A和工具B之間能夠相互兼容其實只有每個中間的一部分並不能夠相互兼容彼此的100%，那這個時候當然我們主機廠在使用ODX這個文件的時候，肯定是希望我所有的工具供應商都能滿足我釋放的同一份ODX文件，所以這個時候需要定義企業級的ODX規範，也就是ODX Guide line，也就是ODX實現指南，來定義好我這家企業所需要的ODX文件是什麼樣的，然後來讓我不同的工具供應商來基於這份企業級規範滿足不同一個ODX需求。
ODX Studio是我們用於編輯ODX文件的一個工具，它可以同時編輯ODX 2.0.1和ODX 2.2.0 兩個格式，這兩個版本之間是相互不兼容的。
ODXStudio的一個編輯界面，每個層級都是一個獨立的標籤頁，ODX-D，-C，-V，-F，-E，-FD。
那每一個層級：-D定義出來我可以把它保存成一個ODX-D的文件；-F可以保存成ODX-F的文件等等，當然我們通常在使用一個ODX文件的時候，可能同時需要ODX-D和ODX-C包含在一起，所以這個時候在標準裏面還有一種格式，就是PDX，Pack的ODX，打包的ODX文件，這個格式文件可以一個或多個的ODX文件，後綴名就是.pdx。
剛剛我們介紹的CDD，ODX 是兩種診斷數據庫文件，那我們在什麼樣的情況下，去使用哪一種數據庫文件呢，Vector有如下的一種建議。
2.3 診斷解決方案 – CANdelaStudio/ODXStudio建議
我們建議在開發階段使用CDD文件，而在生產後售後階段使用ODX文件，爲什麼會有這樣的建議呢，我們在開發階段數據會一直變動，或者說我們的數據庫文件會一直需要不斷的進行修改，那相較於ODX文件，CDD文件是面向工程性的，所以它的可編輯性更強，而且行業內大部分人對CDD文件還是比較熟悉的，所以它編輯起來會更簡單更容易一些，而到了我們生產售後階段，我們可能會有不同的Tester的一個應用，那麼這個時候我們需要一種國際標準的格式能夠被不同的Tester去進行使用，去進行調用，那麼這個時候我們就可以選擇從前期開發階段的CDD文件導出相對應的ODX文件，來應用到我們生產和售後階段，然後適應我們不同Tester的需求。
這樣一個建議會涉及到我們整個數據交互的流程，這個數據交互流程的核心是CDD文件，而CDD來源於實際的診斷規範。
對於ECU供應商而言，我們主要是做ECU開發，那麼我們可以用CDD文件來導入到我們GENy相關的這個代碼配置工具裏面去做相應的代碼生成，也可以把它放到我們的CANOE.Diva或者CANOE Indigo像這些工具裏面去做相應的測試。
而對於主機廠這邊，首先主機廠可能也會開發一部分的ECU，所以我們也可以同樣的流程通過CDD文件導入到我們的代碼配置工具裏面去做相應的代碼生成以及我們相應的CANOE等工具裏面去做這個測試的部分，另外到生產售後階段，我們每一個主機廠都會有自己的不同的Tester，甚至說每個階段都會有不同的Tester，那麼我們可以通過CDD格式文件通過CANdela Studio導出符合相對應的Tester需求的一些數據庫文件，比如說ODX比如說主機廠自定義診斷數據庫格式來應用我們不同的Tester裏面。
這樣的一個“”是經歷過相應的一些實際案例的一個檢驗的，首先我們來看福特，福特有自己的一個格式MDX，這個診斷數據庫文件它不是通過福特的某一個工具直接生成的，而是通過CANdela Studio定義的CDD文件導出福特自己的MDX文件，那福特在前期ECU開發的時候或者說他建議他的ECU供應商去進行ECU開發的時候會使用CDD，然後使用我們的CANdesk這個這樣一個代碼包，然後來做相應的診斷功能的開發。
到了他的生產售後階段，它們會有自己的MDX相應的一些驗證工具，會有他們自己相應的一些售後工具，EOL工具等等，那他們就通過CDD導出的MDX文件來應用到它們不同的一些部門裏面，應用到不同的工具裏面，那這個呢也符合我們剛剛說的前期開發階段使用CDD文件。而生產售後階段呢，就使用它們自定義的格式文件。
另外一個使用案例呢，是歐洲的兩個主機廠之間有一個合作的項目，那麼這個時候呢，在合作以前，OEM1它使用的CDD文件，而OEM2它使用的ODX文件，那麼這個時候，它們兩之間相互交互的時候呢？OEM1就選擇用CDD導出相應的ODX文件，來跟OEM2之間來進行交互，以及相應的一些工作，那ODX本身這個文件也可以用在不同公司不同的部門之間相互的一個交互，而我們原本的CDD文件，也可以用在我們一開始的開發流程當中，不用改變它自身已有的相關的一些流程。
剛剛說到的是主機廠，那麼對於系統供應商呢？採埃孚之前也有定製過相應的它們自己的一個CDD文件，這個CDD文件用於他們前期的開發和測試的工作，而到了交付給主機廠或者他們後端自己需要的一些工具的時候，就會把CDD導出相對應的ODX文件，或者主機廠需要的一些CDD文件交付給主機廠，然後或者是採埃孚可以通過他們自己的CDD，導出相對應的一些工具需要的ODX文件，XML，Excel相對應的一些Template。
這個是我們對於兩種數據庫文件的一個建議，在我們需求定義好以後，下面一步就是做代碼的實現，那麼在代碼實現的部分，Vector提供有嵌入式代碼。
2.4 診斷解決方案 – 嵌入式診斷
嵌入式代碼首先第一種Nun Autosar標準的Command代碼，Command裏面診斷的部分叫做CANdesc，它的一個實現方式就是將CDD文件導入到我們的GENy工具裏面，然後去生成診斷相關的一些底層代碼，以及應用層接口。
另外一種就是我們Autosar解決方案MICROSAR，其中的MICROSAR DIAG診斷的部分包含我們的DCM，DEM和FIM相關的這些模塊，那它的一個實現方式也是將我們的CDD或者ODX文件導入到我們的配置工具“達芬奇”裏面，自動生成和診斷相關的一些底層代碼，以及應用層接口。
在診斷功能實現以後，我們就要對它來進行測試，那有兩種測試方法，第1種是自動化測試，第2種是手動測試，我們首先來看自動化測試。
2.5 診斷解決方案 –自動生成的測試
自動化測試是實現，我們可以用CANOE.Diva這個工具，他可以在導入診斷數據庫ODX或者CDD文件的基礎上去，去自動生成診斷相關的測試用例，可以覆蓋UDS，KWP，GMW3110或者OBD等相關的一些測試用例。
我們可以看到這張圖裏面就是歐洲一個主機廠，他一個車型平臺上面通過手動測試和自動測試分別所耗費的時間的一個對比圖，灰色就是他手動測試所花費的時間；紅色就是它自動測試所花費的時間，我們可以看到自動測試所消耗的時間，只有他手動測試的1/3，甚至更少。
CANOE.Diva的一個流程，把CDD和ODX文件導入到Diva工程當中，然後去通過一些相應的配置，點一個按鈕自動生成診斷相關的一些測試用例，那這部分測試用例實際是CANOE的一個測試模塊，所以需要把Diva的工程導入到CANOE當中去連接ECU，去執行這些測試用例，最終自動生成相應的測試報告。
Diva生成的測試用例，分兩個部分，首先一個部分呢是標準工具自帶的相應的測試點與我們的需求進行一個匹配，相交叉的這個點就會生成相對應的測試用例，那當然我不能保證這裏生成的測試用例可以滿足你100%的需求，比如說像NRC的優先級，就是我們標準的CANOE.Diva工具測不了的。
那麼這個時候，我們可以由用戶自己來提供相應的測試需求或者說測試規範，我們以項目服務的方式來開發CANOE.Diva Plugin，來擴展Diva自動化測試的測試用例，那目前呢，我們在全球已經有超過給15家這個OEM定製過相應的Diva擴展的測試用例。
標準的Diva可以測到點，包括:物理尋址和功能尋址的測試；P2，P2*，S3時間參數的測試；請求格式，響應格式，22服務裏面同時讀取多個DID等等相應的測試；具體數據內容的測試；ECU應用相關的測試；以及會話安全集相關轉換的等等相關的測試。
Diva當中的配置主要包括，像工程配置，工程配置包括像我們是否這個工程是CAN的網絡，然後我們的27服務使用到的Dil文件的加載，以及CANOE環境文件加載等等。
另外一個是測試配置，主要是配置我們測試當中的用到的一些時間參數，還有我們這些診斷服務是否要測以及我們的測試深度等等
那關於DTC這部分的配置，我們主要是通過加載DBC文件來實現網絡相關的故障注入，也可以通過像VT系統，來注入一些短路，斷路，或者電壓等等相關的一些IO故障注入。
那對於刷寫的測試呢，我們是從CANOE.Diva 4.0版本開始支持的，它需要調用我們的vFlash工具所做的一個vFlash一個工程，完整的一個刷鞋的工程來進行測試，它可以對有效的刷寫流程進行測試，也可以在刷寫流程當中去製造一些故障，然後來看我們的刷寫是否會被停止，以及我們的ECU是否可以重新被刷寫等等。
CANOE.Diva是自動生成診斷和刷寫相關的測試用例的工具；而我們另外一個工具vTESTstudio是用來去編輯測試用例這樣一個工具，並且他們的執行環境都是CANOE，現在我們可以把CANOE.Diva的工程，直接導到vTESTstudio裏面，把他們合併到同一個測試工程，並且在此基礎上添加一些Diva可能暫時還不支持的一些測試用例。
這個界面顯示的呢，就是我們生成的一個測試報告的一個界面，那我們具體的每一條測試用例是否通過，具體的測試條目，具體的一些測試步驟以及相對應的trace窗口，都會在我們報告當中去顯示。
下面來看手動測試的部分，
2.6 診斷解決方案 – 手動測試支持
CANOE，CANape，這些工具不是主要用來做診斷的，但是呢，他們都可以在加載數據庫的基礎上手動收發一些診斷服務，或者去編寫一些診斷相關的腳本，那我們現在具體介紹Indigo工具，Indigo是我們參數化的診斷儀，但是它是一個基於PC機的診斷儀。
Indigo這個工具是以我們的USKS作爲一個導向，也就是說我們平常的診斷儀，手持式的診斷儀，可能是針對我們每一個車型來定製相對應的診斷儀的功能，但是Indigo這個工具，它是更換不同的車型，我只需要跟換我車型相對應的這個CDD或者ODX文件就可以。以此來生成相對應的數據導向的功能。
同時呢，它也可以加載C#腳本所編輯的一個Vector Diagnostic Scripting來管理相應的診斷序列。
這個是Indigo的一個GUI界面，可以看到在這個界面裏面，DTC Auditor顯示是每個ECU分別由多少個DTC，當然這邊還有一個可以由另外一個窗口具體顯示我每一個ECU裏面具體一些DTC的信息，這個窗口描述的是，我們DID相對應的一些數據，當然這個是我們Trace的原始報文，而這邊顯示的呢，是我們已經解析好的相對應的一些數據，那我們可以看到Indigo爲了更好的方便我們中國用戶的使用，所以我們Indigo從4.6版本開始，是支持中文的一個界面。
Indigo除了是現場的一個診斷儀以外，它也可以支持一個遠程的介入，通常我們的整車試驗場或者說我們車輛可能在外地，然後我們的診斷專家他可能在另外一個城市，那這個時候如果診斷專家需要去獲取到車輛的一些信息的時候，我診斷專家通常都是出差到本地去做一些診斷的工作，但是這個時候我診斷專家比較忙，現場也比較緊急，這樣一些情況的話，這個時候通過遠程的方式來連接，那現場端 Indigo Access Point這個現場端然後連接我們的這個接口卡，然後去連接我們的車輛，然後通過WiFi連上後臺的服務器，遠程專家這端也是任然應用的Indigo這個工具，只是帶有Indigo Remote license，然後去用WIFI連上我們後臺的服務器，兩個之間相互對接上。
我們的 Indigo Access Point這端會有一個賬戶和密碼，我的遠程端去輸入這個賬戶跟密碼，就可以知道我是跟哪一個 Indigo Access Point端去進行連接，那這個時候我們還會有一個問題，就是現場這個車輛上面放一臺電腦放一個接口卡其實是不太方便的，所以這個時候我們有另外一個自帶操作系統的接口卡VN8810，它可以直接替代我的現場端和接口卡的兩個部分，直接連上車輛的OBD口，並且OBD直接給它供電，同時通過WIFI連上後臺的服務器，那還是一樣的，我的remote遠程專家發送相應的指令，獲取相應的一些診斷信息。
這個就是VN8810自帶操作系統的智能設備，以及它相關的性能參數，那麼這個VN8810應用用場景主要就是遠程診斷以及刷寫。
那麼這個是我們傳統的兩端都基於PC機的Indigo Remote系統的一個界面。
我們現在從需求定義到代碼實現，以及到測試的部分，整個的診斷開發全流程已經覆蓋到了。接下來一個，就是跟我們的診斷功能息息相關的，也就是我們ECU另外一個刷寫的功能。
2.7 診斷解決方案 – 刷寫工具
刷寫功能的實現，首先是我們ECU本身也需要有Bootloader的代碼，來支撐這個刷寫的功能，當然Vector也提供相應的flash Bootloader的代碼包，另外我們的vFlash是一種通用型的上位機工具，爲什麼說它是通用型的呢？因爲我們可以支持不同的總線，包括CAN，DoIP，FlexRay等等，我們支持不同的刷寫格式，比如傳統的Intel-Hex，Motorola-s，Binary等等，以及ODX-F相關的這個格式，也可以支持不同的OEM刷寫規範刷寫序列。
爲什麼呢？因爲我們在使用vFlash的時候需要一個基於刷寫規範定製的vFlash Template，這個vFlash Template是基於這個刷寫規範定製化開發的，所以它的獲取方式通常會有幾種。首先一個是購買了Vector Flash BootLoader我們會隨包帶相對應的vFlash Template；另外只是購買vFlash這個工具的話，我們可以以項目的形式定製化開發相對應的vFlash Template；其次我們在全球已經有給很多的主機廠定製了相對應的vFlash Template，那主機廠也可以把這個vFlash Template釋放給你相對應的系統供應商。建立vFlash這個工程的時候，我們只需要選擇對應的vFlash Template，然後加載我們的刷寫數據，然後去配置一些ECU相關的配置，比如說我們CANID的定義等等（CANID，波特率等等填寫），來建立一個完整的刷寫工程。
那我們可以將我們的這個刷寫工程保存成一個Pack&Go的一個格式，也就是vFlash Pack，這個vFlash 相當於是一個打包好的一個工程，然後這個工程裏面會包含你的，比如說Seed&Key文件，你的刷寫文件，你的vFlash Template等等，全部包含在裏面，那這個vFlash Pack可以直接被vFlash打開，然後去進行刷寫執行，也可以被其他的工具比如說Diva進行直接的調用。
這個是vFlash一個刷寫過程的一個界面，它會顯示我當前已經刷到了已經執行到了哪一個階段，然後已經刷到了我的data的部分，然後當前還剩多長時間，我的一個刷新速率等等。
vFlash是針對單個ECU進行刷寫，尤其是像在產線上1對1的刷寫的話效率是不太高的，所以我們有另外一個license，就是vFlash station。vFlash station可以調用vFlash Pack實現對多個的同時刷寫，最多的是8個ECU，也就是8個獨立的物理通道。vFlash station它提供的不是一個標準的含GUI的工具，而是一個函數庫，這個函數庫包含C和C#的API，那麼你在產線上通常會有一箇中控機制，那你可以把這個vFlash station功能嵌入到你相對應的這個中控機制裏面，那採用這個C或者是C#上的一個API去調用相對應的功能。
除了vFlash station以外，它還有另一個擴展的License，就是vFlash Remote，它和我們剛剛講到的Indigo Remote類似，是一個遠程刷寫的方案。那麼我們需要一個vFlash 的現場端，現場端提供這個ID和密碼，讓我遠程端去輸入我的IP和密碼，同時連上服務器，那麼我就知道我們兩端可以連接上，然後我的vFlash Remote這一端，加載我的這個vFlash Pack工程，然後傳輸到我的現場端，然後去執行相應刷寫的動作。
同樣的我們的現場端也可以用VN8810直接去連接我們的車輛。
3 結尾
歡迎大家給我留言，如果覺得好，動動你的手指，“點贊”+“收藏”
獲取更多汽車行業資訊，以及工具鏈的使用，可以關注微信公衆號“汽車電子助手”
或者掃描下方二維碼進行關注
END