今天是2022年7月24日,上海天氣陰轉多云。老規矩,分享一段喜歡的文字,避免自己成為高知識低文化的工科男:“ Return to today's topic!最近在做關于OBD的相關內容工作,這里做一個備注。“ 在車載診斷范疇,可以分為兩個方向:1、偏向OEM定義內容2、偏向Society and Legislative Authority本文關于OBD協議內容,ISO為其分配了ISO-15031系列標準號,共有7個子類。同樣在傳統燃油車強國美國,其國內組織SAE也為OBD分配了相應的標準號。本文分享ISO15031-5,即OBD所用的診斷服務(0x01-09),說明其:1)模式的作用(使用場景)2)模式如何使用OBD協議協議中定義9個診斷服務,每個服務用一個byte來代表,即所謂的Service ID(SID),具體內容如下:Service 01 - Request Current Powertrain Diagnostic Data:通過該服務,Tester端可以獲取車載動力系統當前的診斷數據:-> 具體單個定義傳感器的狀態;-> 發動機轉速;-> 動力域DTC數量;-> 故障指示燈是否亮起等。格式為:SID + PID(Parameter ID),PID也是一個Byte,取值范圍是0x00-0xFF,類似于UDS協議,ISO 15031定義了部分PID內容,也做了相當部分的預留。因為該協議具備法規效應,OBD協議定義了眾多PID,對于ECU支持哪些PID,診斷儀是如何獲知?在實際應用過程中,PID分為兩類:-> 用于表征具體的數據;-> 用于指出該ECU支持哪些PID。在第二種使用場景中,PID分別是0x00 , 0x20 , 0x40…. 讀取其中一個PID后ECU會返回4個字節的結果,從返回的4個字節中的每個bit表示其所對應的PID是否被支持。PID 0x00 用于查詢(0x01~0x20)之間支持的PID參數;PID 0x20 用于查詢(0x21~0x40)之間支持的PID參數;PID 0x40 用于查詢 (0x41~0x60)之間支持的PID參數,以此類推。例如:req:01 00res:41 00 xx xx xx xx左起第一位xx表示0x01~0x08之間的PID支持情況,將xx轉為2進制。如xx=0x65 ->xx=0110 0101 從左往右 那么表示支持PID 0x02 0x03 0x06 0x08左起第二個xx表示0x09~0x10之間的PID支持情況,注意二進制轉換。左起第三個xx表示0x11~0x18之間的PID 支持情況,注意二進制轉換。左起第四個xx表示0x19~0x20之間的PID支持情況,注意二進制轉換。只能說一句,協議定制者是真牛逼!接著使用第二步:就可以讀取相關支持的PID參數的值了,假如支持PID 0x04 0x05 0x0dreq:01 04 05 0cres:41 04 xx xx 05 xx 0d xx其中xx表示支持的PID的值了,比如0d表示當前的車速,0d后面的xx的值是64,及對應的是100KM/h,即請求到的車速為當前100km/h。類比UDS協議,每次請求一個PID,也可以一次請求多個,最多6個。而對于最新版ISO 27145協議,通過Service 22來實現對OBD服務車輛信息讀取,這個時候規定是最少支持6個DID讀取。Service 02 - Request Powertrain Freeze Frame Data對車車輛ECU出現并界定出某個故障,會將這個故障被Confirm時的相關狀態信息“凍結”下來(UDS協議中叫快照信息),也就是行業內所謂的凍結幀,這些狀態信息對車輛故障的確定非常重要,因為它們記錄了車輛發生故障時的很多相關信息,凍結幀的載體同樣是PID。在ISO 15031協議中,Service 02與Service 01命令的使用方法相同。只不過02讀取的是故障發生時的數據,而01讀取的當前數據,數據格式和含義都是相同的。與01命令不同的是,02命令中多了一個frame字節:需要注意的是在OBD協議中,用frame = 0x00來代表讀取凍結幀。如果主機廠想自己再定義些什么其他的幀,或者多定義幾個凍結幀,則可以給frame分配上其他的編號。OBD只規定了ECU需要為一個DTC存儲凍結幀,當ECU中同時存在多個DTC時,就要根據優先級來判定存儲誰的凍結幀了。模式2的作用就是為了快速方便的了解,故障發生時刻的一個狀態,以此來分析、排查以及定位故障,從而能夠有效的提高售后維護的效率。Service 03 - Request Emission-Related Diagnostic Trouble Codes服務03用于讀取存儲在ECU中的與排放相關的“confirmed” DTC。Service 03命令的請求和響應格式:Service 03的作用就是請求當前確認的故障(Comfirmed DTC)的故障碼,以此就可以了解車輛發生故障時,是哪個故障導致的,進而就可以根據該故障的機理來分析故障,維修車輛。Service 04 - Clear/Reset Emission-Related Diagnostic InformationService 04用于清空ECU中存儲的與排放相關的DTC。同時清除包括故障碼、凍結幀、測試數據等等排放相關的內存數據。該服務格式請求是一個字節的04,響應是一個字節的44。只有在發動機沒有運轉的時候才可以執行這個服務,否則ECU應該給出NRC 0x22(條件不滿足)來拒絕該服務。Service 05 - Request Oxygen Sensor Monitoring Test ResultsService 05用于讀氧傳感器的狀態,監控氧傳感器的測試結果,因為氧氣的濃度對燃燒過程有著重要的影響,因此對排放也有著重大的影響,因此有必要進行測試監控。一般支持模式6的話也可以通過模式6來代替模式5的功能(對于OBDonCAN來說不支持該服務).Service 06 - Request On-Board Monitoring Test Results for Specific Monitored Systems車上不僅僅氧傳感器的結果需要監控,還有其他很多的地方需要結構,比如催化劑、蒸發系統等等,那么可以通過Service 06來進行監控。主機廠也可以根據需要去定義監控各個系統模塊ID以及需要進行測試的參數TID。該服務用于請求對特定被監測系統的監測結果。OBD中定義了一個MID(Monitor ID)的表格,來標識被監測系統。一個ECU不一定需要支持所有的MID,獲知具體支持哪些MID的方法與01和02服務所使用的方法相同.06服務的response中,針對某一個MID,可能有多個TID(Test ID),因為針對一個系統可能有多個測試項目。TID表格也在OBD中定義。06服務的response格式固定,每個MID的每個TID有6部分組成,具體如下:MID;TID;Unit And Scaling ID,用于標識這個TID的測試內容是什么,比如電壓、時間、計數器之類的;Test Value,實際測量值;Min. Test Value,這個測量值的最小值;Max. Test Value,這個測量值的最大值。Service 07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving CycleService 07也是獲取DTC,但是它與03服務區別在于,它用于獲取在當前以及上一個駕駛循環中出現的處于“pending”狀態的DTC,而Service 03則是獲取的是confirmed DTC。請求及相應格式如下:該服務的作用:每次維修人員修理完之后,會清理故障,為了了解這個故障是不是真正解決了,就需要重新試一下,然后看這個故障是不是又會出現,如果是通過模式3去了解,則至少需要三個操作循環,而模式7則可當前操作循環就可以知道。Service 08 - Request Control of On-Board System, Test or ComponentSercie 08用于對系統進行控制,進行元件測試操作。它相當于UDS中定義的2F和31服務。它的使用方法是SID + TID,注意這個TID與05和06服務的TID不同,在OBD中有一個專門給08服務使用的TID表格。注:因為這個模式使用的比較少,比如我國的所有OBD是不支持08模式的,以下對其進行簡單的介紹。這個模式就是通過定義測試標識符TID以及測試數據,去操作ECU進行測試。Service 09 - Request Vehicle InformationService 09用于讀取車輛信息,請求格式:SID + InfoType(個數若干)InfoType在OBD標準中有定義。并不是所有的InfoType都需要被支持,具體哪些InfoType被支持,可以采用和01服務相同的方法相似。以上分享是關于診斷協議OBD的內容,在車載診斷范疇與UDS是兩個不同范疇。并且OBD協議是針對傳統燃油車的規范(有法律效應)。但現狀是新能源車慢慢在崛起,特別是電池組逐步解決續航行程和充電效率的問題,對于大方向(節能、環保、碳中和)的布局,我國都是一個極好的彎道超車機遇。在以往傳統汽車強國:-> 日本押寶氫能源,大方向錯誤;-> 德在新能源車的電池和軟件捉襟見肘的現狀。作為一個國家工業皇冠上的一顆明珠,汽車對于國家經濟的反哺能力,有著極其重要的作用。看好這個方向,也慶幸自己在這個行業。 |
|