UDS

RyanWang94發表於2020-10-06

UDS(ISO 14229-1&ISO 15765-2)

U 可以基於任何匯流排

VIN :車輛識別號，是主機廠對一輛車的唯一標識碼，是在下線檢測的時候寫入到ECU當中

診斷的作用：讀取軟硬體版本號，故障檢測，程式升級刷寫，下線檢測，IO控制（比如雨刮器的耐久測試）

UDS 定義了一種C/S架構的診斷響應機制

OBD: 與排放相關的，可支援CAN LIN K ，主要與法規相關

UDS是應用層協議，與底層的通訊介質不相關，所以可以在任何形式的通訊介質上實現

UDS 也是參考ISO 七層網路協議模型：每一層都有對應的標準，比如物理層是ISO11898-1/ISO11898-2；網路層和傳輸層中是不同通訊協議的標準，比如ISO15765-2是基於CAN的傳輸協議，ISO17987-2是基於LIN的協議

14229 一共有6個部分

ISO 14229-3 是基於CAN的UDS

UDS 與OBD的關係：

  • OBD是在15031-5中定義的排放相關的服務，UDS是14229-1中定義的通用服務
  • 兩者都依賴15765-2中定義的網路層和14229-2中定義的會話層
  • 一個ECU中是可以共存OBD與UDS的，兩者各司其職
  • Unified: 可以實現任何通訊方式的診斷
    1. 原因：網路層，傳輸層和會話層之間的T_PDU（虛擬PDU）
    2. T_PDU 是A_PDU與任何通訊方式PDU之間連線的介面
    3. image-20200508202957812
  1. image-20200508203056430

D 診斷通訊協議

  • 本地客戶端和本地伺服器：如果Client和Server 的具有相同的本地網段，就是說CAN id 的開頭一樣
  • 遠端客戶端和遠端伺服器：一般是在有閘道器的網路中會涉及的，通過遠端地址進行標識
  • PDU: 是資訊（PCI）和資料（data）組成，在通訊中一般都會涉及到PDU, UDS中每一層都有對應的PDU
  1. 協議控制資訊PCI
  2. data
  • 對等實體：以軟體，硬體或者軟硬體的任意組合實現的每層活動部分
  • 定址方式：
  1. 物理定址：比如軟體刷寫
  2. 功能定址：同時連線幾個ECU 進行DTC的清楚
  • 地址：地址與報文ID 有關，診斷報文ID =基地址+節點地址，功能定址一般為特定ID:0x7DF
  1. 源地址：
  2. 目標地址：

  • 6種服務原語（瞭解即可，底層ECU開發不需要關心這部分的實現）

    1. 服務請求原語（開始傳送給診斷請求）
    2. 服務請求確認原語（診斷請求傳送完成） 內部有A_Result資料：列舉型別，表示是否正確傳輸
    3. 服務指示原語（ECU請求訊息收到，開始處理診斷請求）
    4. 服務響應原語（ECU處理結束，開始向tester傳送，響應報文）
    5. 服務響應確認原語（ECU傳送響應報文結束）內部有A_Result資料：列舉型別，表示是否正確傳輸
    6. 服務確認原語（tester 接收響應報文成功確認）

  • 原語格式：

    1. A_MType：本地診斷還是遠端診斷
    2. A_TA_type: 物理還是功能
    3. A_AE只是針對於遠端診斷方式的

  • A_SDU與A_PDU的關係

    1. 應用層服務A_SDU是通過服務原語進行傳遞到A_PDU的，原語將診斷應用程式中發出的診斷服務需求，轉換成A_PDU
    2. 對等實體間就是通過對應的PDU進行傳遞的
    3. A_PDU = A_PCI +A_SDU

  • A_PCI （應用層協議控制資訊）根據A_PCI引數的第一個位元組是否為0x7F分

  1. A_PCI (SID) ：請求服務和肯定響應，一個位元組無符號整數
  2. A_PCI （NR_SI, SI）：否定響應

  • SID(服務識別符號)

    1. 0x00-0xFF 之間，但是其中部分保留了，可以讓供應商或者主機廠自定義的位元組
    2. 14229-1的部分，目前定義了26個服務型別
    3. 對於請求服務，第六個bit為0，相對應的返回的肯定響應識別符號第6個bit為1，此為他們的對應關係，即肯定響應SID =請求的SID+0x40
    4. 肯定響應NR_SID =0x7F 固定
    5. NRC :返回錯誤的原因，NRC 可以直接查詢14229-1附錄就是了
    image-20200509070705500

  • 診斷三要素：

  1. 請求
  2. 肯定響應
  3. 否定響應

  • A_PDU

    1. Cvt: convention; M： mandatory, C：conditional（基於某一些標準的），S: selectonal(可選的)，U: User optional(使用者自定義)

    2. 子功能（SF）:帶子功能（S）; 不帶子功能（U）

    3. SF ：一個位元組；子功能引數範圍0x00-0x7F： 0-127

      image-20200509071647778

      第7位決定了是否需要傳送肯定響應訊息

      1. A_PDU處理過程

        [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-NUsTLbXy-1601947004780)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509072247357.png)]

S 服務

常用的6類服務

UDS中定義的服務一共6類26個，下面定義一些常用的服務

1. 診斷和通訊管理功能單元

0x10 DiagnosticSessionControl

  • 三種診斷會話

    1. 預設診斷會話：ECU一般剛上電，冷啟動，軟體復位進入的狀態，是比較安全的狀態，通過0x10 01 讓ECU進入此會話，安全鎖定狀態
    2. 非預設診斷會話
      • 程式設計會話：用於重新程式設計即軟體刷寫的狀態，主程式設計環節 0x10 02
      • 擴充套件診斷會話：ECU刷寫的預程式設計環節, 0x10 03

    注意：不同的診斷會話具有不同的功能和定時引數；一般來說非預設會話基本能夠支援比較多的服務，預設會話能夠支援的服務比較有限

    注意：不能由預設會話直接跳轉到程式設計會話的，只能有擴充套件會話跳轉到程式設計會話，如果在預設會話中傳送跳轉到程式設計會話的請求是，ECU會回覆NRC7E

  • 會話超時-定時器S3

    1. 在非預設會話中保持的時間是可以設定，一般預設P2=50ms, P2* = 5000ms

    2. 問：P2和P2*是什麼意思？

      • P2–從ECU收到請求訊息到傳送響應訊息之間的時間

      • P2*–從ECU傳送了NRC為0x78的否定響應訊息到開始傳送下一個響應訊息

      • [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-x54XtmD6-1601947004782)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200528102453424.png)]

        S3server 的時間是確認從PDUR中接收到資料之後開始計時的

    3. 通過0x3E服務可以請求不要斷開非預設會話

    4. 一般用於軟體刷寫中

  • 0x10 服務

    1. SF 0x00-0xFF
    2. NRC

  • 診斷描述檔案（cdd）

    1. 在dependency中可以看到會話切換的轉換圖

  • 有時候在功能定址過程中為了減少匯流排負載，如果不想所有的ECU都傳送肯定響應，則需要應用SF中的一直肯定響應訊息位 如 0x10 83

0x27 SecurityAccess

  • 四個步驟

    image-20200509080128185

  1. 請求，2n-1表示安全等級，如果請求時已經解鎖，則直接返回位為全0的肯定響應，表明已經處於解鎖狀態

  2. ECU返回種子，隨機數，種子的位元組長度由OEM自定義

  3. Tester通過種子,再根據種子安全等級與範圍，計算一個金鑰key1

  4. ECU 通過key1 計算Key2, 如果Key1 =Key2 則解鎖

  5. ECU返回解鎖訊息

    • 0x27 可以實現不同安全等級切換，但是在任意時刻只能有一個安全等級
    • 編寫cdd檔案時，種子位元組、安全等級、金鑰資料型別都可以自定義，建立好的安全等級可以在state groups中檢視
    • 常見8個NRC

  6. 不同安全等級之間的關係

    [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-AaoBNnrz-1601947004785)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200529164400912.png)]

    • 不同安全等級之家可以是相互獨立的也可以是有依賴關係的，比如說要先解鎖了安全等級1之後才能進入到安全等級3

    • 從解鎖狀態跳轉到鎖定狀態的幾種方式：

      1. 接收了$11服務，ECU重新復位了

  7. ECU重新上電了

    1. 接收了$10會話切換功能

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-BRd6QeKH-1601947004787)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200806163112407.png)]

0x28 CommunicationControl
  • 可以開啟或者關閉某些訊息的傳送/接收
    1. 0x28 01
0x3E TesterPresent
  • 測試工具保持連線服務
  • 用於保持診斷儀與ECU的連線，同時將之前的服務和狀態保持，,不會因為超過P2*的時間限制重新切換到Default Session
  • 0x3E 80使ECU保持在擴充套件診斷會話模式
0x85 ControlDTCSetting

  • 用於停止或者恢復單個伺服器或者一組伺服器中DTC狀態記錄

    1. 0x85 01 正常記錄

    2. 0x85 02 停止DTC更新

以下診斷服務用得相對於上面的少一些

0x11 ECUReset
  • 請求ECU執行復位
  • 如果需要回複復位的肯定響應，那麼肯定響應一定要在復位執行之前返回
  • 復位之後直接進入預設會話
0x83 AccessTimingParameter
  • 讀取和修改通訊鏈路的實時引數
  • 暫時不支援
0x84 SecuredDataTransmission
  • 保護資料傳輸免遭第三方攻擊
0x86 ResponseOnEvent
  • 啟動/停止伺服器中某個特定事件觸發的響應
0x87 LinkControlu
  • 控制客戶端和伺服器之間的通訊，以便獲取診斷目的的匯流排頻寬

問題：怎麼編寫CDD檔案

2. 資料傳輸功能單元

讀取ECU內的數值，如軟體版本號，VIN, 車型配置等

讀寫資料的個數規定上限為4095

0x22 ReadDataByIdentifier

  • 根據DID讀取資料

    1. 模擬量輸入輸出
    2. 內部資料
    3. 系統狀態資訊

  • DID規範見14229附錄，一次請求可以傳送多個DID，每一個DID都是雙位元組無符號數

    1. 比如讀取VIN的DID就是0xF190，VIN號一共是17個位元組
    2. 比如DID=0x010A 返回發動機冷卻液溫度、節氣門位置、發動機轉速、歧管進氣壓力、怠速控制等等
    3. 比如DID=0x0110 包含電池正電壓
    4. ISO對於DID的取值範圍做了劃分，具體DID代表了什麼/多少資料、格式就需要OEM/Supplier制定
    5. 不同的DID需要不同的服務支援
  • image-20200509094523018
0x2E WriteDataByIdentifier
  • 和讀取訊息類似，只是過程相反image-20200509095444880
  • 寫入的一般都是
    • 非易失儲存器中的資料
    • 可標定的引數
    • 車輛的配置資訊
  • 否定NRC
  • 示例
    1. 通過F190寫入VIN號，同上相反

3. 傳輸儲存的資料功能單元

0x19 ReadDTCInformation

  • 一共28種子功能，常用的有4種

    image-20200509101220348

    1. 0x02 最常用 SM（StatusMask）表示掩碼; SAM（StatusAvailabilityMask）表示返回的可用掩碼

      注意:SAM是通過SM與ECU內部的現有的DTC的狀態進行&計算，篩選出非0的所有的DTC

      所以一般狀態掩碼與DTC的狀態碼的定義類似

      image-20200509101446767

    2. 0x04 快照資料，也就是故障發生時候的環境資料

      • ECU每發生一次故障，記錄一次DTC，都會記錄一次snapshotData，主要作用是幫助分析發生故障的主要原因

      • 分為

        1. 全域性快照（必須）

          一般包括：

          ​ 供電電壓

          ​ 里程數

          ​ 電源模式

          ​ 日期

          ​ 時間

          ​ 冷卻液溫度

        2. 區域性快照（可選）：全域性快照資訊的補充

      • 比如：

        [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-ugkblX6K-1601947004789)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509103311366.png)]

    3. 0x06 擴充套件資料—服務執行時的環境資料

      • 擴充套件資料資訊是一組提供診斷故障程式碼相關擴充套件狀態資訊的資料組，一般包括
        1. 包括故障出現計數器-記錄的次數
        2. 故障待定計數器-記錄的次數
        3. 已老去計數器-記錄的此時
      1. 老化計數器-記錄的次數
        [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-5bOTVFus-1601947004789)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509103655505.png)]

    4. 0x0A 讀取所有的DTC，返回ECU內目前記錄的所有DTC

      image-20200509101555180
0x14 ClearDiagnosticInformation
  • image-20200509103924718

  • 3個位元組的DTC組是用於選擇DTC組的掩碼，group對應著車身、動力總成、車身、地盤等

    image-20200529170436690

  • 清除完成之後，返回肯定響應，即使沒有DTC，同樣傳送肯定響應

    image-20200509104301628

  • 清除所有DTC

    image-20200529170347077

  • 清除某一個DTC: 後面直接跟DTC的具體數值就行了

4. 輸入/輸出控制功能單元（I/O控制）

0x2F InputOutputControlByIdentifier
  • 替換伺服器輸入訊號的值或者內部功能
  • 控制電子系統的某個輸出（某個執行器）

5. 遠端啟用例程功能單元

遠端控制，讓ECU啟動、停止或者執行一段特定的序列，並返回其結果

又同步和非同步兩種方式

例程：執行特定序列並或者相關的輸出結果，比如，ECU上電的自檢、ECU儲存器擦除、調整電機的零位角度,可以把例程視為一段比較複雜的邏輯程式。

0x31 RoutineControl

  • 三個步驟

    1. 開始例程 0x31 01

    2. 請求例程結果 0x31 03

    3. 停止例程 0x31 02

      [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-a5ezRdCS-1601947004792)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509105520277.png)]

6. 上傳/下載功能單元

上傳用得比較少，多用下載功能（也就是軟體刷寫）

有關軟體刷寫需要注意的幾點

  • 燒錄的時候，為了降低匯流排的負載率，需要控制車上各個ECU的收發資訊開關
  • 燒寫時不能開啟故障儲存
0x34 RequestDownload
  • 請求下載一段程式/資料

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-0DrEsAOH-1601947004792)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509110208006.png)]

  • 肯定響應

    [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-k8quQRAU-1601947004793)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509110335965.png)]

0x35 RequestUpload
  • 用於請求上傳一段程式/資料
0x36 TransferData
  • 用於傳輸需要刷寫的程式/資料
  • 比如需要傳輸6000個位元組，但是由於通訊波特率決定了一次只能傳輸4000個位元組，這個時候就需要0x36 01 請求之後再有 0x36 02 傳輸
0x37 RequestTransferExit

  • 請求停止程式/資料的傳送

  • 對0x36 資料傳輸的資料校驗，常見的校驗和是CRC8 ，CRC16

  • UDS診斷服務的幾種形式

    1. 只有SID 如0x3E
    2. 帶SF ，SID+SF
    3. 帶資料識別符號DID ，SID+DID, 如0x22 和0x21
    4. 其他 SID+SF+RID(歷程識別符號) 如 0x3E

  • CAN匯流排的UDS實現，ISO15765-2

    • 三種定址方式：

      [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-egjrUo4r-1601947004794)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509111945059.png)]

      1. 正常定址
      2. 擴充套件定址
      3. 混合定址

    CAN匯流排一次最多隻能傳送8個位元組

常用的NRC

1. NRC22

1. NRC31

請求超出範圍

比如NRC31在三個會話中都是支援的，但是不是所有的DID在所有的會話中都是支援的，當讀取某一個DID資訊時，如果該DID在當前會話下不支援就會返回NRC31

image-20200529163734244

DCM(Diagnostic Communication Manager)

DCM模組主要是實現UDS和OBD診斷服務的實現，但是DCM跟其他模組的互動比較頻繁，需要了解診斷服務的機制需要其他模組配合，比如BswM、DEM、EcuM以及SWC等。

功能

  1. 接收並響應診斷儀的資料請求，負責診斷資料流以及診斷狀態的管理
  2. 檢查請求的服務是否在當前的會話和安全等級中支援
  3. DCM支援UDS（14229-1）和OBD-II(15765-4)的全部服務

全域性工作流程

img

內部工作流程

https://img-blog.csdnimg.cn/20200211160056932.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI1OTIwMDkx,size_16,color_FFFFFF,t_70

img

DSL(Diagnostic Session layer)

DSL用於處理診斷資料請求和響應的資料流；監控和確保診斷請求和響應的時序。

功能
1. 處理診斷請求

當收到診斷請求時，PDUR呼叫Dcm_StartOfReception()和Dcm_CopyRxData()函式將收到的診斷請求資料放置在DCM模組的Buffer中，然後PDUR呼叫Dcm_TpTxConfirmation()函式通知Dcm模組接收到了新的診斷請求。

2. 處理診斷響應

當需要響應診斷請求時，DSL模組通過呼叫PduR_DcmTransimit()和Dcm_CopyTxData()將資料傳遞至PDUR模組，其中PduR_DcmTransimit()函式只是傳遞長度資訊、地址資訊，資料是通過Dcm_CopyTxData()函式傳遞至PDUR模組，當資料傳輸成功後，PDUR模組通過Dcm_TpTxConfirmation()函式告知DCM資料接收成功。

3. 管理安全等級

DSL提供Dcm_GetSecurityLevel()、DslInternal_SetSecurityLevel()兩個函式分別用於獲取當前的安全等級和設定安全等級。

配置

對於配置層面而言，DSL選單主要是：

  1. 配置診斷幀，包括物理定址和功能定址，單次通訊的最大Buffer，以及時間引數，
  2. 包括回覆0x78的時間
  3. 為了防止診斷服務異常，允許0x78的最大次數等。

DSD(Diagnostic Service Dispatcher)

功能

DSD模組負責檢查診斷請求的有效性（診斷會話、安全訪問級別、應用程式許可權的驗證），並跟蹤服務請求執行的進度。

1. 檢查診斷服務

當DSL接收到新的診斷請求，DSL通過內部介面通知DSD，如圖3所示。DSD呼叫Dcm_GetSesCtrlType()、Dcm_GetSecurityLevel()獲取當前的Session和安全等級，DSD模組會在當前Session的“Service Identifier Table”檢查診斷請求SID是否在其中，如果不在table中，DSD會傳送NRC 0x7F，如果診斷服務支援，但當前Session不支援該子服務，DSD會傳送NRC 0x7E；然後檢查當前安全等級是否滿足條件，如果當前安全等級不支援該診斷請求，DSD會傳送NRC 0x33。最後檢查資料的長度。

img

圖3 DSL與DSD的互動

2. 彙總響應資料

當DSP模組完成診斷請求處理後，DSD負責將整理響應資料。併傳送至DSL。

DSD模組將服務識別符號(SID)(如果是負反饋，則為0x7F)和響應的資料流新增至“Dcm_MsgContextType”。然後DSD將其傳送至緩衝區，並在緩衝區的第一個位元組新增SID。

配置

對於配置而言，DSD主要是配置：

  1. 所需要實現的服務
  2. 服務所支援的session
  3. 服務執行的安全等級

DSP(Diagnostic Service Processing)

功能

DSP用於實現不同服務的處理，當接收到DSD請求處理診斷服務，DSP的處理過程如下：

1. 分析接收的請求資訊，呼叫不同的診斷服務實現函式
2. 檢查格式以及是否支援所定址的子功能
3. 獲取資料或者呼叫DEM、SWC或者其他BSW模組的介面

比如0x22和0x2E服務需要呼叫SWC的資料介面進行讀寫；0x28需要呼叫BswM的邏輯實現關閉不同的CAN報文；0x19服務需要呼叫DEM模組獲取快照資料和擴充套件資料。

4. 彙總響應資料
配置

對於配置而言，DSP模組配置項比較雜，比如：

  1. DID的實現，包括DcmDspData用於配置DID的資料型別，資料長度，以及介面型別；DcmDspDidInfo用於配置DID的讀寫功能；DcmDspDids用於彙總DcmDspDidInfo和DcmDspData，並且新增DID value。

  2. 安全等級的實現，包括種子和祕鑰的位數、最大的錯誤訪問次數，以及時間引數。

  3. Session的配置，包括Session的等級，Session是否支援跳轉至Boot，以及時間引數P2 ServeMax和P2* ServeMax。

DEM(Diagnostic Event Manager)

功能

用於處理診斷事件的資訊和相關的資料，DCM模組通過服務請求可以獲得這些資料。

DEM模組主要是處理的DTC相關的資料。

DCM模組遵循的標準與DCM相同，負責直接處理與DTC相關的服務，如UDS中的0x19服務(響應報文由DCM傳送出去)。當軟體構件中的Monitor Function檢測到故障或BSW模組檢測到故障時，將通知DEM模組處理和儲存“診斷事件”(由Event ID進行標識)。如果故障確診，呼叫NVRAM Manager(非揮發性記憶體管理器)提供的介面將其存取到非揮發性記憶體中，同時通知應用層進行故障指示。DEM的狀態圖如下圖所示：
img

DTC

DTC資訊= DTC（高3bytes）+DTC狀態(低1byte)

三種常見的DTC格式

  1. 5位SAE標準故障碼

  2. UDS

    image-20200509100523334

DTC屬性

  1. 程式碼值
  2. 檢測方式
  3. DTC狀態
  4. 附加資訊

DTC狀態

詳情可看14229-D附錄

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-ij9xuYra-1601947004797)(C:\Users\WZO4SGH\AppData\Roaming\Typora\typora-user-images\image-20200509100644731.png)]

  • BIT0 : testFailed。表示發生了TestFailed

img

  • BIT1:testFailedThisOperationCycle。表示當前Cycle發生了TestFailed

    img

  • BIT2:pendingDTC。表示當前發生了testFailed

    img

  • BIT3: confirmedDTC,表示已經檢測到多次testfailed，並且能確認故障發生，需要去儲存相關的資料。

img

  • BIT4:testNotCompletedSinceLastClear, 表示自執行14服務起，還沒有完成完成測試，也就是沒有testPass或者testFailed。

img

  • BIT5:testFailedSinceLastClear，表示自執行14服務起，發生了testFailed事件。

    img

  • BIT 6:testNotCompletedThisOperationCycle,表示當前OperationCycle還未完成測試

img

  • BIT7: warningIndicationRequested,表示特定的DTC需要置告警，車身故障燈亮起

    img

Debounce

  1. DEM提供介面函式Dem_SetEventStatus設定DTC的Status

    img

  2. Debounce方式也就定義了DTC狀態變化的形式

    連續測試中：

    • 如果一直測試通過，達到Pass界限，BIT4由1置位0，BIT6由1置位0
    • 如果偵測到testFiled，那麼TripCounter就直接從大於0開始計數
    • 當TripCounter連續計數累計超過Failed時，BIT2與BIT3置位

  3. AgingCounter&Agecounter

    • 當一個OpreationCycle沒有檢測到testFailed,AgingCounter就會自加1，同時DTC Status的BIT就會清0
    • 當AgingCounter計數達到一定的閾值後，此故障已經完成了老化，可以自愈。同時DTC Status的BIT3清0
    • 14229-1附錄D提供了關於AgingCounter的演示

  4. SnapShot

    • SnapShot是一群DID資料的集合
    • 每個DTC在Confirm時可以生成快照，將當時的一些關鍵資料儲存在NVM中
    • 通過19服務讀取SnapShot的具體資料

cess=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI1OTIwMDkx,size_16,color_FFFFFF,t_70)

  1. Debounce方式也就定義了DTC狀態變化的形式

    連續測試中：

    • 如果一直測試通過，達到Pass界限，BIT4由1置位0，BIT6由1置位0
    • 如果偵測到testFiled，那麼TripCounter就直接從大於0開始計數
    • 當TripCounter連續計數累計超過Failed時，BIT2與BIT3置位

  2. AgingCounter&Agecounter

    • 當一個OpreationCycle沒有檢測到testFailed,AgingCounter就會自加1，同時DTC Status的BIT就會清0
    • 當AgingCounter計數達到一定的閾值後，此故障已經完成了老化，可以自愈。同時DTC Status的BIT3清0
    • 14229-1附錄D提供了關於AgingCounter的演示

  3. SnapShot

    • SnapShot是一群DID資料的集合
    • 每個DTC在Confirm時可以生成快照，將當時的一些關鍵資料儲存在NVM中
    • 通過19服務讀取SnapShot的具體資料

相關文章