彈指間，2021年馬上已經過去一半的時光。
得空需要多工作、生活做一個覆盤。
應一同行要求，今天漢子我粗略談論下Service85內容，談論維度從以下三個方面：
1）協議介紹
2）圖形化說明
3）手動測試
一、UDS協議對Service85定義
UDS協議關於Service85開篇有云：
The ControlDTCSetting service shall be used by a client to stop or resume the updating of DTC status bits in the server(s). DTC status bits are reported in the statusOfDTC parameter of the positive response to certain SubFunctions of ReadDTCInformation.
通俗講，Service85是透過外部診斷裝置Tester端傳送該服務控制ECU內部診斷程式碼更新其DTC以及DTC Status狀態位。
請求格式如下：
其中對應的Subfunction在協議中型別詳細定義如下：
從上表中可以獲知如下資訊：
Subfunction 01表示Tester端開啟控制器（ECU）診斷功能；
Subfunction 02表示Tester端關閉控制器（ECU）診斷功能。
協議為保證其最大的靈活性和適配性，同樣預留了相應範圍給OEM和Supplier自定義其需要的Subfunction。
Service 85響應格式如下：
二、用圖形說明Service85
透過Service85控制ECU診斷功能，在日常使用中有著不可替代的作用。
眾所周知，控制器診斷功能是伴隨控制器整個執行宣告週期。控制器一上電，負責故障檢測的程式碼就會執行。在控制器執行環境中，只要檢測出對應故障的出現，控制器就會將該故障對應的DTC以及當前實際的DTC Status位儲存在該控制器掉電非易失的記憶體中。
ECU上電後，晶片上執行的Application程式碼就在執行，實時檢測整個ECU執行環境。基於自己的判定機制判斷（避免車內複雜執行情況而設定的防抖演算法），判定對應DTC產生後，儲存在晶片記憶體中。
而在一些特殊情況下，比如當外部Tester需要對ECU進行Software update時，為保證車載網路資源、晶片處理資源全負荷為ECU刷寫服務，這個時候會進行如下兩部分操作：
A：關閉ECU常規通訊功能（Service28）；
B：關閉ECU診斷功能（Service85）。
如上圖，進行該操作後，ECU便將自屬診斷功能進行遮蔽，使晶片全資源為其他需求服務（比如刷寫功能）。這個階段就是出現了可以啟用DTC的故障訊號，對應DTC也不會產生。
這個時候也稍微提一句，在以前車載診斷對車規晶片要求不是特別嚴苛的時候，會有一個有趣的現象：控制器開機10S內不進行任何診斷檢測，也是這個道理！！！
三、手動測試
基於需求規範編輯好診斷資料庫後，對應Service85服務編輯內容如下：
載入到CANoe中進行手動測試：
對應的Trace資料如下：
這裡分享兩處有意思的點：
1、透過CANoe連線待測ECU後，可以在如下的視窗直接查詢該待測ECU已經發生的故障碼DTC以及對應的狀態位：
使用Service85 02，關閉ECU診斷功能，這裡就不會更新對應的DTC資料內容啦！
2、在驗證Service85功能是否實現，比如關閉診斷功能後，啟用故障訊號，檢視是否會將對應的DTC記錄到內容：
A：若沒有記錄，就是Service 85功能實現；
B：若有記錄，則說明該Service85沒有功能實現。
但是這個有一個前提就是晶片記憶體中本就沒有儲存DTC。因此需要Service14將DTC全部清除後再進行Service19 02讀取。
以上分享內容，希望對諸君有所幫助。
願你我相信時間的力量，
做一個長期主義者！
-----------------------------------
作者簡介 | 穿拖鞋的漢子
汽車電子工程師
公眾號：車載診斷技術
來，每天進步一點點！
