作者 | 糊涂振
出品 | 汽車電子與軟件
在現代汽車電子控制單元（ECU）的診斷系統中，時間控制是確保診斷通信可靠性、故障管理準確性的核心技術，如同交響樂團需要精確的節拍器，診斷系統的各個層級——從底層的幀傳輸到高層的服務處理——都依賴精心設計的時間參數協同工作，這些時間參數被系統地組織在傳輸層、網絡層、會話層和應用層中，形成了一個完整的時序控制體系。本文將深入解析診斷系統中各層時間參數的概念、作用與實際應用，通過具體場景展示這些“數字節拍器”如何指揮診斷通信的每一個過程。
01
診斷系統的四層時間參數架構
汽車診斷系統的時間參數按照功能層次可分為四個層級，形成了一個完整的時間控制體系：
這種分層設計遵循了ISO 14229（UDS）和ISO 15765（診斷通信）標準，每一層專注于特定粒度的時序控制，共同保障診斷通信的端到端可靠性。
02
傳輸層時間參數：
數據幀的精準調度
2.1 AM（地址模式）
AM并非嚴格的時間參數，而是決定通信時序基礎的重要模式，它定義了診斷消息的尋址方式：
--物理尋址（1對1通信）：ECU響應快，時序可預測；
--功能尋址（1對多廣播）：響應時間需考慮多個ECU，時序更復雜。
AM決定了后續所有時間參數的基準，比如在功能尋址下，P2時間參數需設置更長，以容納多個ECU的并行處理。
2.2 BS（塊大小）與STmin（最小分隔時間）
BS（與STmin這對參數是多幀傳輸的“流量調節閥”。BS是接收方告知發送方“每次最多給我發多少幀，然后等我確認”；STmin是接收方要求“每幀之間至少間隔多長時間，我好消化”。
比如BS=0表示發送方可連續發送所有數據（無流量控制），而BS=1-255，則每次最多發送指定幀數，然后等待流控制幀；STmin=0-127ms表示具體的最小間隔要求，而當STmin=0x7F，則表示發送方自行決定間隔。
Source:https://blog.csdn.net/LOVE135149/article/details/122621694
為了更好地理解BS和STmin，我們通過一個ECU軟件刷寫場景來做進一步了解：
假設診斷儀需要發送200幀刷寫數據，然后ECU回復流控制幀：BS=10, STmin=5ms，那么發送流程將是這樣的：
1. 診斷儀連續發送10幀數據，每幀間隔≥5ms；
2. 發送完第10幀后，暫停發送，等待ECU確認；
3. ECU處理完數據后，發送新的流控制幀：BS=10, STmin=5ms；
4. 重復此過程，直至200幀全部發送完成。
這樣的設計防止了快速發送方（診斷儀）淹沒處理能力有限的接收方（ECU）。
03
網絡層時間參數：
多幀傳輸的守護者
網絡層參數是多幀傳輸可靠性的核心保障，它們如同交通信號燈，控制著數據流的啟停與節奏，這里需要關注六個網絡時間參數N_As, N_Bs, N_Cs, N_Ar, N_Br和 N_Cr, 如下所示：
Source: https://zhuanlan.zhihu.com/p/368091567
1）N_As（1000ms）：發送方的“首幀耐心”
N_As是指發送方發送首幀后，等待接收方回復流控制幀的最大時間。即發送首幀后啟動1000ms定時器，如果收到流控制幀，則停止定時器，繼續傳輸；如果1000ms超時，則認為接收方無響應，啟動重傳或報錯。
比如某車型在寒冷啟動時，ECU上電初始化較慢。診斷儀發送首幀請求讀取故障碼，ECU因低溫啟動，核心模塊初始化需800ms。此時N_As設置為1000ms，ECU在900ms時完成初始化并回復流控制幀 ，那么傳輸成功；但若N_As設為500ms ，則 超時重傳，這樣就會增加網絡負載，降低效率。
2）N_Bs（1000ms）：塊傳輸的“等待窗口”
當BS>0時，發送方發送完一個數據塊后，等待下一個流控制幀的最大時間。
比如ECU設置BS=5，表示“每次給我5幀數據”，診斷儀發送完5幀后，啟動N_Bs定時器（1000ms），ECU在600ms內處理完5幀數據，發送新的流控制幀，診斷儀收到后繼續發送，整個流程順暢；如果ECU處理異常，超過1000ms未回復，那么診斷儀N_Bs超時， 可能重傳上一個數據塊 ，以確保數據不丟失。
3）N_Cs：連續幀的“節奏控制”
實際發送連續幀時，幀與幀之間的時間間隔，這個值由發送方根據接收方要求的STmin決定，不是獨立配置的參數。也就是說N_Cs ≥ STmin（必須滿足接收方最低要求），并且這個時間間隔的實際值 = max(STmin, 物理層最小間隔)，這兩點發送方必須嚴格遵守，否則接收方可能緩沖區溢出。
4）接收方三劍客：N_Ar、N_Br、N_Cr
這三個參數構成接收方的超時防護網：
N_Ar是指接收方發送流控制幀后，等待下一個連續幀的最大時間，通常為1000ms。即ECU發送流控制幀后啟動N_Ar=1000ms，收到第一幀連續幀，停止N_Ar。
N_Br是接收方在開始接收一個數據塊（最多BS個連續幀）后，等待該數據塊完成的最大時間。N_Br計算公式：N_Br = BS × (單幀傳輸時間 + STmin) + 安全裕量，比如BS=5，STmin=10ms，CAN幀傳輸時間0.3ms，安全裕量50ms，那么N_Br = 5 × (0.3 + 10) + 50 = 101.5ms ≈ 100ms。
N_Cr是指接收方在發送流控制幀后，等待下一個連續幀的最大時間。N_Cr設置原則為：N_Cr = STmin + 網絡最大抖動 + 處理波動，通常設為STmin的1.5-2倍。
04
會話層時間參數：
診斷會話的生命周期管理
UDS服務定義了診斷儀與ECU之間的請求-響應交互模式，在這一交互過程中，多個時間參數控制著通信的時序，在會話層主要涉及S3相關的時間參數。
4.1 S3Server（5000ms）：ECU的“會話自動回收”
ECU在非默認會話（如擴展會話、編程會話）中，無診斷活動時的最大保持時間。
即ECU進入擴展診斷會話（如刷寫準備），啟動S3Server定時器（5000ms倒計時）；然后每次收到有效診斷請求，重置定時器；如果5000ms內無任何請求 ，則自動退回默認會話。
為什么這么設計？主要考慮點是非默認會話通常消耗更多資源（如內存、CPU），通過S3Server機制確保即使診斷儀異常斷開，ECU也能自動釋放資源，回歸正常狀態。
4.2 S3Tester（通常4000ms）：診斷儀的“心跳保持”
診斷儀為保持非默認會話活躍，定期發送TesterPresent服務的時間間隔。即診斷儀進入編程會話（車輛軟件升級），每4000ms發送一次TesterPresent（抑制響應），這確保在長達30分鐘的刷寫過程中，會話始終保持活躍。如果診斷儀崩潰停止發送，5秒后ECU自動退出編程會話 。
通常這兩個時間參數存在的比例關系為S3Tester ≈ (0.7~0.8) × S3Server，這樣在正常網絡延遲下，確保診斷儀的“心跳”總能及時到達。
05
應用層時間參數：
診斷服務的質量保障
應用層時間參數，特別是P2系列參數，構成了診斷儀與ECU之間請求-響應時序的核心框架，定義了通信各方的行為邊界接下來將深入解析四個關鍵的應用層時間參數：P2CAN_Client、P2*CAN_Client、P2CAN_Server和P2*CAN_Server。
為了理解這些參數的作用時機，讓我們先看一個典型的診斷交互時序：
P2參數正是用來約束這個響應時間范圍的關鍵指標。
1）P2CAN_Server
P2CAN_Server是ECU（服務器）從完整接收一個診斷請求消息，到開始發送響應消息之間的最大允許時間，這個時間一般設置為50ms。
這里對于單幀請求，完整接收是指收到完整的請求幀；而對于多幀請求，是指收到所有連續幀并完成重組后的完整請求數據；開始發送是指ECU開始向CAN總線發送響應消息的第一幀（可能是單幀或多幀的首幀）。
2）P2*CAN_Server
當ECU無法在P2CAN_Server時間內完成請求處理時，它可以先發送一個特殊的否定響應NRC 0x78（請求正確接收，響應尚未就緒），然后繼續處理。P2*CAN_Server是ECU從發送NRC 0x78響應到準備好最終響應的最大允許時間，這個時間一般設置為5000ms。
P2*機制體現了診斷系統設計中的重要原則：當無法快速完成時，先確認接收，再異步處理。這避免了診斷儀因長時間等待而誤判為超時。
3）P2CAN_Client
P2CAN_Client是診斷儀（客戶端）在成功發送請求消息后，等待ECU開始響應的最大時間，這個時間通常為P2CAN_Server_max + ΔP2CAN。
這里"成功發送請求消息"是指診斷儀已將請求消息完整發送到CAN總線上，并得到確認；"開始響應"是指檢測到ECU開始發送響應消息，對于多幀響應是檢測到首幀，對于單幀響應是檢測到響應幀。
4）P2*CAN_Client
當診斷儀收到ECU返回的NRC 0x78否定響應時，它需要等待一段時間才能收到最終響應或重新發送請求。P2*CAN_Client就是診斷儀在收到NRC 0x78響應后，等待ECU開始發送最終響應的最大時間。這里不難理解時間起點是診斷儀完整接收到NRC 0x78響應幀的時刻，開始發送最終響應是指ECU開始發送處理完成后的最終響應。
06
DTC時間參數：
故障管理的時序智慧
除了上述這些時間參數，DTC相關時間參數是診斷系統的重要組成部分，包括故障確認時間，故障恢復時間和老化相關參數等。
1）故障檢測時間參數
故障檢測不是瞬時過程，需要一定時間來確認故障的真實性和穩定性。
故障確認時間（Fault Confirmation Time）：從故障條件首次滿足到ECU確認故障存在所需的時間，這個時間通過去抖動（debounce）算法實現，防止瞬時干擾導致誤報。
故障恢復確認時間（Fault Recovery Confirmation Time）：從故障條件消失到ECU確認故障已恢復所需的時間，這確保了間歇性故障不會立即被清除，避免狀態頻繁切換。
這樣通過這兩個時間的應用，可以提高故障檢測的可靠性和準確性，減少誤報和漏報。不同的故障類型可能具有不同的確認時間，例如：
電氣短路：10-50ms（快速檢測，防止損壞）
信號漂移：1-2s（避免誤報，傳感器需要穩定時間）
通信丟失：200-500ms（區分瞬時干擾與真實丟失）
總之，ECU軟件為每個DTC配置適當的確認時間，通常使用計數器或定時器實現：
故障條件滿足時，啟動確認定時器
如果故障條件持續滿足達到確認時間，則確認故障
故障條件消失時，啟動恢復確認定時器
如果故障條件持續不滿足達到恢復時間，則確認故障恢復
Source: https://blog.csdn.net/WE_BIG/article/details/135860897
比如當進行發動機失火故障檢測，第1次檢測到失火事件，啟動500ms定時器，但不記錄故障；如果500ms內再次檢測到失火，確認為真實故障，設置DTC；如果500ms內未再檢測到，則認為是瞬時干擾，忽略。
2）DTC存儲時間參數
DTC被確認后，ECU需要決定何時將其存儲到非易失性存儲器中。
立即存儲：某些嚴重故障（如安全相關故障）在確認后立即存儲，確保即使ECU斷電，故障信息也不會丟失。
延遲存儲：非嚴重故障可能在點火循環結束時存儲，減少對非易失性存儲器的寫操作，延長其壽命。
存儲重試間隔：如果存儲操作失敗，ECU重試存儲的時間間隔。
這樣通過不同的存儲時間來平衡故障信息的及時保存與存儲器壽命保護的需求。
3）故障老化參數
DTC不會永久存儲在ECU中，而是會在一定條件下自動清除，比如采用老化計數器（Aging Counter）記錄DTC自上次發生以來的時間或事件次數。
常見的老化條件包括：
點火循環次數：故障不再發生后經過一定數量的點火循環
行駛里程：故障不再發生后車輛行駛一定距離
時間：故障不再發生后經過一定時間
老化閾值：老化計數器達到此閾值時，DTC被自動清除。不同嚴重等級的DTC可能有不同的老化閾值。
通過這里參數就可以檢測老化是否激活，依次自動清理歷史故障信息，防止存儲器被舊故障碼占滿，同時確保近期故障信息可供分析。
07
結 語
汽車ECU診斷系統的時間參數，看似是一組冰冷的數字，實則是確保診斷通信可靠、故障管理準確的智慧結晶。從傳輸層的毫秒級幀控制，到應用層的秒級服務管理，再到DTC的日級生命周期，每一層參數都在其崗位上精確值守，共同維護著診斷系統的健康運行。
理解這些時間參數不僅需要技術知識，更需要系統思維。在實際工程中，它們不是孤立配置的選項，而是相互關聯、動態平衡的有機整體。一個優秀的診斷系統設計者，應當像交響樂指揮一樣，深刻理解每個“樂器”（參數）的特性，讓它們在正確的時刻發出和諧的聲音。
隨著汽車電子架構的不斷演進，時間參數的管理將面臨新的挑戰和機遇。但無論如何變化，對時間的精確掌控將始終是汽車診斷技術不可或缺的核心能力。只有深入理解這些時間參數的內涵與關聯，才能在日益復雜的汽車電子世界中，構建出穩定、可靠、高效的診斷系統。
