車載診斷標(biāo)準(zhǔn)ISO 15765

本文格式為Word版，下載可任意編輯——車載診斷標(biāo)準(zhǔn)ISO15765ISO15765-3（2023）

道路車輛——控制局域網(wǎng)絡(luò)診斷——

第3部分：

一元化診斷服務(wù)實施（

CANUDS）的

道路車輛——控制器局域網(wǎng)（CAN）的診斷——第3部分：

一元化診斷服務(wù)實施（CAN的UDS）1范圍

這部分ISO15765協(xié)議依照ISO14229-1，描述了在ISO11898定義的控制器局域網(wǎng)中統(tǒng)一診斷服務(wù)（UDS）的實施。它給所有汽車連接至CAN網(wǎng)絡(luò)服務(wù)器及外部測試設(shè)備提供診斷服務(wù)及服務(wù)器存儲器編程的需求。它對汽車內(nèi)部CAN總線架構(gòu)無任何要求。

2參考的標(biāo)準(zhǔn)

下述的參考文檔對于該文檔的應(yīng)用是必不可少的。

3術(shù)語，定義和縮略詞

為編撰該文檔目的，這些術(shù)語和定義已在ISO14229-1，ISO15765-1及ISO15765-2中給出，以下縮略詞術(shù)語同樣適用。DA目標(biāo)地址ID標(biāo)識符DLC數(shù)據(jù)長度碼GW網(wǎng)關(guān)

LSB最低有效位MSB最高有效位NA網(wǎng)絡(luò)地址SA源地址SM子網(wǎng)掩碼TOS服務(wù)類型

4協(xié)定

該部分ISO15765協(xié)議基于ISO14229-1的協(xié)定，該協(xié)議遵從使用到診斷服務(wù)的OSI服務(wù)協(xié)議。

5統(tǒng)一診斷服務(wù)（UDS）對照OSI模型的應(yīng)用

見圖1

6應(yīng)用層及會話層

6.1應(yīng)用層服務(wù)

該部分ISO15765協(xié)議使用ISO14229-1的客戶機-服務(wù)器式的應(yīng)用層服務(wù)。該系統(tǒng)具有測試、檢測、監(jiān)視，診斷及汽車服務(wù)器在線編程的功能。

6.2應(yīng)用層協(xié)議

該部分ISO15765協(xié)議使用ISO14229-1應(yīng)用層協(xié)議。

6.3應(yīng)用層診斷會話管理定時

重要——任何一個服務(wù)器端產(chǎn)生的不等于N_OK的N_USData.indication的指示服務(wù)，服務(wù)器應(yīng)用層都不應(yīng)當(dāng)有一個應(yīng)答信息。

6.3.1概況

下述的是應(yīng)用層及會話層的定時參數(shù)及它們?nèi)绾卧诳蛻魴C-服務(wù)器模式中如何處理的。

診斷層ISO14229統(tǒng)一診斷服務(wù)（UDS）ISO15765-3統(tǒng)一診斷服務(wù)實施ISO15765-2CAN診斷網(wǎng)絡(luò)層ISO11898-1數(shù)據(jù)鏈路層及物理信號用戶定義例如：11898-1或-2物理插接口

圖1OSI模型中，基于CAN的UDS實施

下述的幾種通信會話方式需區(qū)別開：a)物理的通信在如下期間1）默認(rèn)會話方式

2）非默認(rèn)的會話方式——需進行會話處理b)功能的通信在如下期間1）默認(rèn)的會話方式

2）非默認(rèn)的會話方式——需進行會話處理

所有的狀況下，請求服務(wù)器否定應(yīng)答信息的擴展的定時應(yīng)答，包括應(yīng)答碼78hex應(yīng)當(dāng)予以考慮。

定義在ISO15765-2的網(wǎng)絡(luò)層主要是處理客戶機-服務(wù)器的應(yīng)用層及診斷會話管理的定時。

6.3.2應(yīng)用層定時參數(shù)定義

用于默認(rèn)的診斷會話的應(yīng)用層定時參數(shù)值應(yīng)依照如下表2設(shè)置

表2——默認(rèn)會話的應(yīng)用層定時參數(shù)定義定時參數(shù)描述成功發(fā)送請求信息（通過N_USData.con應(yīng)答指示）到接收答復(fù)信息開始（多幀信息的N_USDataFirstFrame.ind和單幀信息的N_USData.ind）的超時設(shè)置接收到應(yīng)答碼為0x78的否定應(yīng)答（通過N_USData.con指示）到接收答復(fù)信息開始（多幀信息的N_USDataFirstFrame.ind和單幀信息的N_USData.ind）的擴展的超時設(shè)置在接收到請求信息（通過N_USData.ind指示），服務(wù)器開始答復(fù)信息的運行要求在傳遞了0x78（擴展的超時設(shè)置）的否定應(yīng)答碼（通過N_USData.con指示），服務(wù)器開始答復(fù)信息的運行要求客戶機成功發(fā)送不需應(yīng)答的物理地址請求信息（通過N_USData.con指示），到它能發(fā)送下一個物理地址請求信息等待的最小時間（見圖6.3.5.3）類型定時器重載值最小值最大值aN/AP2CAN_ClientP2CAN_Server_max??P2CAN*P2CAN_Client定時器重載值*P2CAN_Server_max_rsp??P2CANbN/AP2CAN*P2CAN_Server運行要求運行要求050ms_Server0c5000msP2CAN_Client_Phys定時器重載值P2CAN_Server_maxN/AdP2CAN_Client_Func客戶機成功發(fā)送功能地址請求信息定時器（通過N_USData.con指示），到它重載值能發(fā)送下一個功能地址請求信息等待的最小時間，有可能不需應(yīng)答也有可能該請求數(shù)據(jù)只被某個子網(wǎng)功能地址服務(wù)器支持（見圖6.3.5.3）P2CAN_Server_maxN/Ada客戶機等待一個應(yīng)答信息發(fā)送的最長時間由客戶機決定，但必需滿足P2CAN_Client必需比指定的P2CANb_Client最小值要大；*值由客戶機決定，但必需滿足該值必需比指定的P2CAN*P2CAN_Client_Client最小值要大；c擴展的應(yīng)答定時，在連續(xù)的應(yīng)答碼為0x78的否定應(yīng)答信息之間最小值為1*為±20％的P2CAN2*P2CAN_Server，最大容差_Server；d客戶機發(fā)送下一個請求的最長等待時間由客戶機決定，但必需滿足非默認(rèn)會話的S3Server定時在服務(wù)器一直保持運行。?P2CAN參數(shù)被認(rèn)為是所有系統(tǒng)網(wǎng)絡(luò)設(shè)計參考延時，該延時通過網(wǎng)關(guān)及總線帶寬加上安全系數(shù)（例如最壞狀況的50％）。最壞狀況（客戶機-服務(wù)器-客戶機信息傳輸一個來回的必需

得傳送時間），基于系統(tǒng)的設(shè)計，并受以下因素的影響：a)包含網(wǎng)關(guān)的數(shù)量

b)CAN幀發(fā)送的時間（波特率）

c)CAN總線的使用狀況

d)CAN設(shè)備驅(qū)動使用方法（輪詢方式還是中斷方式）及網(wǎng)絡(luò)層的處理時間

?P2CAN分為兩個時間，一是客戶機發(fā)送請求至服務(wù)器的時間，一是服務(wù)器發(fā)送應(yīng)答至客戶

機的時間。

?P2CAN??P2CAN_Req??P2CAN_Rsp

圖2展示的是?P2CAN組成的一個例子。

圖2——?P2CAN組成的一個例子——單幀請求和應(yīng)答信息

注意：為了簡單描述定時參數(shù)，在以下所有的圖中，假定客戶機到服務(wù)器在同一個網(wǎng)絡(luò)中。所有的說明及附圖依照時間順序表述。

6.3.3會話層定時參數(shù)定義

當(dāng)診斷會話而不是默認(rèn)的會話啟動的時，需要按如下表3的會話層定時參數(shù)進行會話的操作。

表3——會話層定時參數(shù)定義定時參數(shù)說明斷會話的信息請求之間的時間，而不是多服務(wù)器的默認(rèn)會話時間（功能的通信），或者對某一具體服務(wù)器發(fā)送請求最大時間間隔。（物理的通信）。類型推薦超時ms超時ms4000msS3Client在功能地址（0x3E）由客戶機發(fā)送的用于保持診時間重置值2000msS3Server在沒有接收到任何請求信息時，服務(wù)器保持診斷時間重置值N/A會話的時間，不是默認(rèn)會話活動時間。5000ms而且，服務(wù)器轉(zhuǎn)變到非默認(rèn)會話時，應(yīng)當(dāng)改變它的應(yīng)用層定時參數(shù)P2CAN*P2CAN_Client_Server和

，以完成適用于診斷會話的操作。非默認(rèn)的診斷會話適用的定時參數(shù)在診斷會

話控制應(yīng)答信息中報告，當(dāng)一個應(yīng)答需要傳遞（見圖9.2.1服務(wù)說明）或需要提前通知客戶不傳遞任何應(yīng)答信息時。當(dāng)客戶機啟動功能的非默認(rèn)會話時，它應(yīng)當(dāng)調(diào)整響應(yīng)的服務(wù)器的定時參數(shù)。

表4定義了客戶機和服務(wù)器開啟/重啟的S3Client/S3Server定時條件。對于客戶機，周期性發(fā)送功能地址（0x3E）請求信息，應(yīng)當(dāng)與連續(xù)地發(fā)送物理地址（0x3E）請求信息區(qū)別開，后者僅僅在沒有其它任何診斷請求時發(fā)送。對于服務(wù)器，不需要這兩種（0x3E）的操作方式。表4說明S3Server定時器操作是基于網(wǎng)絡(luò)層服務(wù)的，也就是說，S3Server定時器在接收到不支持的診斷請求信息時，重啟。

6.3.4客戶機和服務(wù)器定時器資源要求

對于客戶機及服務(wù)器在默認(rèn)會話及任何非默認(rèn)會話完成上述時間定時的定時器資源要求應(yīng)依照表5及6所示。在非默認(rèn)會話期間，表6所示附加的定時器資源要求適用于客戶機及服務(wù)器。

表4——客戶機及服務(wù)器的會話層定時啟動/中止條件定時參數(shù)動作物理和功能通信，使用功能地址，周期性發(fā)送請求信息N_USData.con用于指示診斷會話控制（10hex）請求信息的完成。只適用于非默認(rèn)會話的會話類型。N_USData.con指示功能地址（0x3E）請求信息的完成，它是在S3Client定時每次到時時發(fā)送。物理通信，使用功能地址，連續(xù)發(fā)送請求信息若不需應(yīng)答，N_USData.con指示診斷會話控制（10hex）請求信息的完成。若需一個應(yīng)答，N_USData.ind指示診斷會話控制（10hex）請求信息的完成。若不需應(yīng)答，N_USData.con指示診斷會話控制任何請求信息的完成。若需一個應(yīng)答，N_USData.ind指示診斷會話控制任何請求信息的完成。N_USData.ind在接收到多幀應(yīng)答信息時，指示出錯。S3Client初始化開始隨后的開始S3Server初始化開始假使需要一條應(yīng)答信息被傳送的話，N_USData.con指示診斷會話控制應(yīng)答信息的完成，表示從默認(rèn)會話轉(zhuǎn)變?yōu)榉悄J(rèn)會話。假使不需應(yīng)答。成功地完成請求的服務(wù)，該請求為診斷會話控制（10hex）請求信息要求從默認(rèn)會話轉(zhuǎn)變至非默認(rèn)會話，隨后的終止隨后的開始N_USDataFirstFrame.ind指示多幀請求信息開始，N_USData.ind表示任何一個單幀請求信息的接收。假使使用默認(rèn)會話，S3Server被禁用。假使需要一條應(yīng)答信息被傳送的話（包括確定及否定應(yīng)答），N_USData.con指示任何應(yīng)答信息的完成，確定一條服務(wù)的執(zhí)行（最終回復(fù)信息）。否定應(yīng)允許答碼0x78不會重啟S3Server。假使不需要任何應(yīng)答信息（確定或否定），請求動作的完成（服務(wù)終止）N_USData.ind指示接收多幀請求信息時的出錯。當(dāng)請求發(fā)送未被請求的信息，如基于某一事件的周期性數(shù)據(jù)及應(yīng)答，見6.3.5.4服務(wù)器關(guān)于S3Server更多的處理。表5——默認(rèn)會話下定時器資源要求定時參數(shù)客戶機服務(wù)器P2CAN_Client為每一個規(guī)律通信通道（物理和功能通信）N/A設(shè)置一個單獨的定時器是需要的，例如，點對點通信需要一個獨立的通信通道。P2CAN_ServerN/A為擴展的應(yīng)答定時一個可選擇的定時器保證隨后的否定*應(yīng)答的發(fā)送比P2CAN_Server早一些。N/AN/AP2CAN_Physical需為每一個物理通信口提供單獨的定時器P2CAN_Functional需為每一個功能通信口提供單獨的定時器

表6——非默認(rèn)會話下另外的定時資源需求定時參數(shù)客戶機當(dāng)使用周期性發(fā)送，功能地址（0x3E）請求信息保持服務(wù)器在非默認(rèn)狀態(tài)，需提供單獨的定時器，不需為每一個激活的診斷會話提供額外的定時器。當(dāng)在無其它診斷請求時，使用連續(xù)的發(fā)送物理地址（0x3E）請求信息保持單個服務(wù)器在非默認(rèn)狀態(tài)，為每一個點對點通信通道設(shè)置單獨的定時器服務(wù)器N/AS3ClientS3ServerN/A服務(wù)器需一個單獨的定時器，由于只有單診斷會話能在一個服務(wù)器中激活。6.3.5具體的定時參數(shù)描述6.3.5.1物理通信

6.3.5.1.1默認(rèn)會話下物理通信

圖3描述了客戶機和服務(wù)器在默認(rèn)會話下物理地址請求信息定時的操作。

圖3——默認(rèn)會話下物理通信

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req到網(wǎng)絡(luò)層開始發(fā)送請求信息。網(wǎng)絡(luò)層傳遞該請求信息至服

務(wù)器。該請求信息要么以單診的形式或多幀的形式。

b)在多幀信息狀況下，請求開始于網(wǎng)絡(luò)層發(fā)送的N_USDataFF.ind通知服務(wù)器。

c)請求信息的完成通過客戶機N_USData.con指示。當(dāng)接收到N_USData.con時，客戶端使用默認(rèn)重載

值為

P2CAN_Client，啟動

P2CAN_Client定時器，該定時器的值應(yīng)當(dāng)考慮到車載網(wǎng)絡(luò)設(shè)計上（通信網(wǎng)關(guān)，

總線帶寬，等）所有的延時。為了簡單化，該圖假定客戶機和服務(wù)器在一條總線上。

d)服務(wù)器通過N_USData.ind指示請求信息的完成。e)服務(wù)器在接收到N_USData.ind指示時，要求在

幀回復(fù)信息條件下，首幀必需在

P2CAN_Server時間內(nèi)開始回復(fù)信息。也就是說，在多

P2CAN_Server時間內(nèi)發(fā)送，對于單幀回復(fù)信息，該單幀必需在

P2CAN_Server時間內(nèi)回復(fù)。

f)在多幀應(yīng)答信息狀況下，客戶機通過網(wǎng)絡(luò)層N_USDataFF.ind指示首幀的接收。當(dāng)接收到首幀時，客

戶機中止

P2CAN_Client定時器。

g)假使完整的信息接收到，或者在接收過程中出現(xiàn)了錯誤，網(wǎng)絡(luò)層最終都產(chǎn)生一個N_USData.ind。在

單幀響應(yīng)信息，通過單個的N_USData.ind指示單幀的接收。當(dāng)接收該單幀指示時，客戶端中止

P2CAN_Client定時器。

h)服務(wù)器通過N_USData.con指示響應(yīng)信息的完成。

6.3.5.1.2默認(rèn)會話期間擴展了應(yīng)答定時的物理通信

圖4描述了默認(rèn)會話期間客戶機和服務(wù)器物理地址請求信息定時操作，及服務(wù)器請求擴展的響應(yīng)定時（否定應(yīng)答碼0x78的處理）。

圖4——默認(rèn)會話期間的物理通信——擴展了應(yīng)答定時

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req到網(wǎng)絡(luò)層開始發(fā)送請求信息。網(wǎng)絡(luò)層傳遞該請求信息至服

務(wù)器。該請求信息要么以單診的形式或多幀的形式。

b)在多幀信息狀況下，請求開始于網(wǎng)絡(luò)層發(fā)送的N_USDataFF.ind通知服務(wù)器。

c)請求信息的完成通過客戶機N_USData.con指示。當(dāng)接收到N_USData.con時，客戶端使用默認(rèn)重載

值為

P2CAN_Client，啟動

P2CAN_Client定時器，該定時器的值應(yīng)當(dāng)考慮到車載網(wǎng)絡(luò)設(shè)計上（通信網(wǎng)關(guān)，

總線帶寬，等）所有的巖石。為了簡單化，該圖假定客戶機和服務(wù)器在一條總線上。

d)服務(wù)器通過N_USData.ind指示請求信息的完成。e)服務(wù)器在接收到N_USData.ind指示時，要求在

幀回復(fù)信息條件下，首幀必需在

P2CAN_Server時間內(nèi)開始回復(fù)信息。也就是說，在多

P2CAN_Server時間內(nèi)發(fā)送，對于單幀回復(fù)信息，該單幀必需在

P2CAN_Server時間內(nèi)回復(fù)。

f)服務(wù)器在給定的

P2CAN_Server時間內(nèi)無法提供請求的信息時，它可以通過發(fā)送應(yīng)答碼為0x78的否定

應(yīng)答信息請求擴展的定時窗。客戶端接收到否定應(yīng)答信息時，客戶端網(wǎng)絡(luò)層產(chǎn)生一個N_USData.ind。接收到應(yīng)答碼為0x78的否定應(yīng)答信息，客戶端重置它的

*載的P2CAN_ClientP2CAN_Client定時器，但使用的是擴展的重

定時值。

g)服務(wù)器在發(fā)送否定應(yīng)答信息N_USData.con之后，要求在給定的擴展的

*時間內(nèi)應(yīng)答信息。假使在給定的擴展的P2CAN_ServerP2CAN_Server*（P2CAN_Server）

時間內(nèi)仍無法提供請求的信息，服務(wù)器則繼續(xù)發(fā)

送應(yīng)答碼為0x78的否定應(yīng)答。

*客戶端使用的是擴展的重載的P2CAN_Client定時值重置它的

P2CAN_Client定時器。為了簡單起見，圖中只顯示了一個應(yīng)答碼為0x78的否定應(yīng)答信息。

h)一旦服務(wù)器可以提供請求的信息（確定的否定的應(yīng)答，而不是應(yīng)答碼0x78的應(yīng)答），它就啟動最終

結(jié)果的應(yīng)答信息。

i)在多幀應(yīng)答信息狀況下，客戶機通過網(wǎng)絡(luò)層N_USDataFF.ind指示首幀的接收。當(dāng)接收到首幀時，客

戶機中止

P2CAN_Client定時器。

j)假使完整的信息接收到，或者在接收過程中出現(xiàn)了錯誤，網(wǎng)絡(luò)層最終都產(chǎn)生一個N_USData.ind。在

單幀響應(yīng)信息，通過單個的N_USData.ind指示單幀的接收。當(dāng)接收該單幀指示時，客戶端中止

P2CAN_Client定時器。

k)服務(wù)器通過N_USData.con指示響應(yīng)信息的完成。

6.3.5.1.3非默認(rèn)會話期間的物理通信6.3.5.1.3.1功能地址（0x3E）信息

圖5——非默認(rèn)會話期間的物理通信——功能地址

圖5描述了客戶機和服務(wù)器非默認(rèn)會話期間物理通信及使用功能地址的定時處理。客戶機周期性發(fā)送(0x3E)請求信息，不需要服務(wù)器的應(yīng)答信息。

P2CAN_Client與P2CAN_Server定時處理與6.3.5.1.1和6.3.5.1.2小節(jié)中描述的處理方法一致。

唯一的區(qū)別是客戶端重置的值及服務(wù)器端發(fā)送結(jié)果應(yīng)答時間會有不同。這是由于轉(zhuǎn)變到另一會話層而不是使用默認(rèn)會話層，因此使用的是不同的P2CAN會話控制（0x10）服務(wù)對定時參數(shù)更詳細(xì)的描述。）

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req至網(wǎng)絡(luò)層，傳遞診斷會話控制（0x10）請求信息。網(wǎng)絡(luò)層

傳遞該請求信息至服務(wù)器。

b)請求信息是單幀信息。它的完成通過客戶端N_USData.con指示。6.3.5.1.1和6.3.5.1.2描述的應(yīng)

答定時適用于此?？蛻舳水a(chǎn)生的N_USData.con促使S3Client定時器開啟（會話定時器）。c)服務(wù)器通過N_USData.ind的發(fā)送器一個應(yīng)答。服務(wù)器應(yīng)當(dāng)發(fā)送診斷會話控制（0x10）的確定應(yīng)答信息。d)服務(wù)器通過N_USData.con指示應(yīng)答信息發(fā)送的完成。然后服務(wù)器開啟S3Server定時器，只要它不超

時，它就一直處于非默認(rèn)狀態(tài)。客戶機負(fù)責(zé)保證S3Server定時器在它超時之前復(fù)位，以保證服務(wù)器處于非默認(rèn)會話狀態(tài)。

e)一旦客戶機開啟了S3Client定時器，這會促使不需應(yīng)答信息的功能地址（0x3E）請求信息的發(fā)送。

每一次發(fā)送的時機都是在S3Client超時時發(fā)送。

f)在網(wǎng)絡(luò)層通過N_USData.con指示（0x3E）請求信息傳遞完成之后，客戶機再次啟動S3Client定時器。

這就是說，功能地址請求信息是在每一次S3Client定時超時之后，周期性發(fā)送的。g)服務(wù)器在處理診斷服務(wù)的任何時間內(nèi)，它都中止S3Server定時器。

h)當(dāng)診斷服務(wù)處理完之后，服務(wù)器重啟S3Server定時器。這就是說，診斷服務(wù)，包括（0x3E），都重置

_Client的值。（見9.2.1節(jié)診斷

S3Server定時器。診斷服務(wù)是在接收到請求信息（N_USDataFF.ind或者N_USData.ind服務(wù)）與完成

最終結(jié)果應(yīng)答這個期間內(nèi)處理的。這里是需要一條應(yīng)答信息的?；蛘哒埱笕缓笤\斷服務(wù)動作的完成

不需要任何應(yīng)答信息。（及時到達一個點會促使一個應(yīng)答信息的發(fā)送）

i)所有（0x3E）請求信息，在服務(wù)器處理另外一條請求信息期間接收的話，都會被服務(wù)器忽略。由于

它已經(jīng)中止了S3Server定時器，并且在服務(wù)處理完之后重啟。

6.53.5.1.3.2物理地址（0x3E）信息

圖6描述了非默認(rèn)會話期間客戶機與服務(wù)器物理通信的定時處理。以及使用物理地址（0x3E）請求信息需要服務(wù)器返回應(yīng)答信息以保持在沒有其它診斷服務(wù)的時候診斷會話的持續(xù)。

圖6——非默認(rèn)會話期間的物理通信——物理地址

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req至網(wǎng)絡(luò)層，傳遞診斷會話控制（0x10）請求信息。網(wǎng)絡(luò)層

傳遞該請求信息至服務(wù)器。

b)請求信息是單幀信息。它的完成通過客戶端N_USData.con指示。6.3.5.1.1和6.3.5.1.2描述的應(yīng)

答定時適用于此。客戶端產(chǎn)生的N_USData.con不會促使S3Client定時器開啟（會話定時器）。這與使用功能地址不同，使用功能地址會周期性發(fā)送(0x3E)信息保持診斷會話一直處于激活狀態(tài)（見6.3.5.3.1）。

c)服務(wù)器通過N_USData.ind指示請求信息的完成。6.3.5.1.1和6.3.5.1.2描述的應(yīng)答定時適用于此。d)圖上給出，假定客戶機需要服務(wù)器一個應(yīng)答。服務(wù)器應(yīng)當(dāng)發(fā)送診斷會話控制（0x10）的確定應(yīng)答信

息。e)服務(wù)器通過N_USData.con指示應(yīng)答信息發(fā)送的完成。然后服務(wù)器開啟S3Server定時器，只要它不超

時，它就一直處于非默認(rèn)狀態(tài)?？蛻魴C通過N_USData.ind指示診斷會話控制（0x10）的接收。這將促使S3Client的開啟?？蛻魴C負(fù)責(zé)保證S3Server定時器在它超時之前復(fù)位，以保證服務(wù)器處于非默認(rèn)會話狀態(tài)。

f)客戶機任何時候發(fā)送一條請求信息至服務(wù)器（包括（0x3E）信息），它都會中止S3Client。g)接收到請求信息的單幀或首幀，服務(wù)器都中止S3Server定時器。服務(wù)器通過N_USData.ind標(biāo)識請求

信息的完成。6.3.5.1.1和6.3.5.1.2描述的應(yīng)答定時適用于此。

h)客戶機通過N_USData.ind指示應(yīng)答信息的完成，這促使客戶機開啟S3Client，服務(wù)器通過

N_USData.con指示應(yīng)答信息的完成，這促使服務(wù)器開啟S3Server。還有一種客戶機不需要應(yīng)答的狀況，客戶機接收到網(wǎng)絡(luò)層N_USData.con確認(rèn)標(biāo)識請求信息發(fā)送完時，開啟S3Client，服務(wù)器完成請求的動作時，開啟

S3Server，為簡單起見，圖中顯示的是需要應(yīng)答的狀況。

i)假使客戶機在S3Client超時之前，沒有發(fā)送任何診斷請求信息，這促使客戶機在S3Client超時時，發(fā)送一條物理地址（0x3E）請求信息。j)服務(wù)器通過N_USData.ind指示（0x3E）請求信息的接收。這促使服務(wù)器中止S3Server定時器。

6.3.5.1.1和6.3.5.1.2描述的應(yīng)答定時適用于此。

k)客戶機通過N_USData.ind指示（0x3E）應(yīng)答信息的完成，這促使客戶機開啟S3Client，服務(wù)器通過

N_USData.con指示（0x3E）應(yīng)答信息的完成，這促使服務(wù)器開啟S3Server。還有一種客戶機不需要應(yīng)答的狀況，客戶機接收到網(wǎng)絡(luò)層N_USData.con（0x3E）標(biāo)識請求信息發(fā)送完時，開啟S3Client，服務(wù)器完成請求的動作時，開啟

S3Server，為簡單起見，圖中顯示的是需要應(yīng)答的狀況。

6.3.5.2功能通信

6.3.5.2.1默認(rèn)會話期間的功能通信

圖7描述了默認(rèn)會話期間，一個客戶機與2個服務(wù)器功能地址請求信息的定時處理。從服務(wù)器角度看，這與物理地址請求信息的定時處理沒什么區(qū)別。但是客戶機對定時的處理就與物理通信不同。

圖7——默認(rèn)會話期間的功能通信

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req至網(wǎng)絡(luò)層開始發(fā)送功能地址請求信息。網(wǎng)絡(luò)層傳遞該請求

信息至服務(wù)器。功能地址請求信息只能是單幀信息。b)客戶機通過N_USData.con指示請求信息的完成。當(dāng)接到N_USData.con時，客戶機啟動

定時器，使用默認(rèn)的重置值

P2CAN_ClientP2CAN_Client。該定時器的值應(yīng)當(dāng)考慮到車載網(wǎng)絡(luò)設(shè)計上（通信網(wǎng)關(guān)，總

線帶寬，等）所有的延時。為了簡單化，該圖假定客戶機和服務(wù)器在一條總線上。c)服務(wù)器通過N_USData.ind指示請求信息的完成。d)功能地址服務(wù)器在接收到N_USData.ind后，要求在

在多幀回復(fù)信息條件下，首幀必需在

P2CAN_Server時間內(nèi)發(fā)送應(yīng)答信息。也就是說，

P2CAN_Server時間內(nèi)發(fā)送，對于單幀回復(fù)信息，該單幀必需在

P2CAN_Server時間內(nèi)回復(fù)。

e)在多幀應(yīng)答信息狀況下，客戶機通過網(wǎng)絡(luò)層N_USDataFF.ind指示首幀的接收。當(dāng)接收到首幀時，客

戶機中止

P2CAN_Client定時器。

f)當(dāng)接收到首幀/單幀指示接下來的應(yīng)答信息，客戶端要么知道服務(wù)器即將應(yīng)答或已經(jīng)應(yīng)答過了，則停

止P2CAN_Client，要么不是所有服務(wù)器應(yīng)答或它不知道服務(wù)器即將應(yīng)答（客戶機等待進一步的應(yīng)答信

。假使完整信息接收到或者在接收過程中產(chǎn)生了一個錯誤，網(wǎng)絡(luò)層產(chǎn)生最

息）時，重啟P2CAN_Client后結(jié)果N_USData.ind。對多幀信息的最終一個N_USData.ind不對P2CANg)服務(wù)器通過N_USData.con指示應(yīng)答信息發(fā)送的完成。、

_Client定時器產(chǎn)生影響。

6.5.3.2.2默認(rèn)會話期間擴展應(yīng)答定時的功能通信

圖8描述了默認(rèn)會話期間客戶機與2個服務(wù)器功能地址請求信息的定時操作。這里一個服務(wù)器通過應(yīng)答碼為0x78的否定應(yīng)答請求一個擴展的應(yīng)答定時。從服務(wù)器角度看，這與物理地址請求信息的定時處理沒什么區(qū)別。但是客戶機對定時的處理就與物理通信不同。

圖8——默認(rèn)會話期間功能通信——擴展的應(yīng)答定時

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req至網(wǎng)絡(luò)層開始發(fā)送功能地址請求信息。網(wǎng)絡(luò)層傳遞該請求

信息至服務(wù)器。功能地址請求信息只能是單幀信息。b)客戶機通過N_USData.con指示請求信息的完成。當(dāng)接到N_USData.con時，客戶機啟動P2CAN定時器，使用默認(rèn)的重置值P2CAN_Client_Client。該定時器的值應(yīng)當(dāng)考慮到車載網(wǎng)絡(luò)設(shè)計上（通信網(wǎng)關(guān)，總

線帶寬，等）所有的延時。為了簡單化，該圖假定客戶機和服務(wù)器在一條總線上。c)服務(wù)器通過N_USData.ind指示請求信息的完成。d)功能地址服務(wù)器在接收到N_USData.ind后，要求在P2CAN在多幀回復(fù)信息條件下，首幀必需在P2CAN_Server_Server時間內(nèi)發(fā)送應(yīng)答信息。也就是說，

時間內(nèi)發(fā)送，對于單幀回復(fù)信息，該單幀必需在

時間內(nèi)無法提供請求的信息時，它可以通過

P2CAN_Server時間內(nèi)回復(fù)。服務(wù)器在給定的P2CAN_Server發(fā)送應(yīng)答碼為0x78的否定應(yīng)答信息請求擴展的定時窗。

e)客戶端接收到否定應(yīng)答信息時，客戶端網(wǎng)絡(luò)層產(chǎn)生一個N_USData.ind。接收到應(yīng)答碼為0x78的否

定應(yīng)答信息，客戶端重置它的P2CAN_Client*定時器，但使用的是擴展的重載的P2CAN_Client定時值。

并且，客戶端應(yīng)當(dāng)在掛起應(yīng)答信息列表存儲一個服務(wù)器標(biāo)識。一旦在存儲在客戶端掛起的服務(wù)器開始它最終結(jié)果應(yīng)答信息（確定或否定應(yīng)答信息包括應(yīng)答碼為0x78的應(yīng)答），它將從掛起應(yīng)答信息列表中刪除。當(dāng)無任何應(yīng)答信息掛起時，客戶端重新為P2CAN_Client使用默認(rèn)的重載值。為簡單化，圖

中，顯示了從服務(wù)器#1的僅一個應(yīng)答碼為0x78的否定應(yīng)答。

f)只要至少有一個服務(wù)器在客戶機端掛起時，從任一服務(wù)器端任何進一步的應(yīng)答信息，都會促使

P2CAN_Client*定時器使用擴展的值P2CAN_Client重啟（見圖9，該圖顯示了當(dāng)客戶機接收到其次個服

務(wù)器應(yīng)答信息開始的狀況）。

g)至于物理的通信，服務(wù)器請求擴展的應(yīng)答定時要求在擴展的時間P2CAN_Client*（P2CAN_Client）內(nèi)，

應(yīng)答信息。一旦服務(wù)器能提供請求的信息，它就通過發(fā)送N_USData.req至網(wǎng)絡(luò)層開啟最終結(jié)果應(yīng)答

*信息。假使服務(wù)器依舊不能在擴展的P2CAN_Client時間內(nèi)

提供請求的信息，它將繼續(xù)發(fā)送應(yīng)答碼為

定時器，使用擴展的重載值

0x78的否定應(yīng)答信息。這會促使客戶機再次重啟P2CAN_Client*P2CAN_Client。已經(jīng)存儲在客戶端掛起應(yīng)答信息列表中，服務(wù)器端包含應(yīng)答碼為0x78的否定應(yīng)答信

息不影響客戶端該信息列表。

h)如6.3.5.2.1，在多幀應(yīng)答信息狀況下，從任一服務(wù)器端接收的首幀，客戶機都是通過網(wǎng)絡(luò)層

N_USDataFF.ind指示的。單幀應(yīng)答信息通過N_USData.ind指示。當(dāng)接收到首幀/單幀指示接下來的

應(yīng)答信息，客戶端要么知道服務(wù)器即將應(yīng)答或已經(jīng)應(yīng)答過了，則中止P2CAN_Client，要么不是所有服

。

務(wù)器應(yīng)答或它不知道服務(wù)器即將應(yīng)答（客戶機等待進一步的應(yīng)答信息）時，重啟P2CAN_Clienti)假使完整信息接收到或者在接收過程中產(chǎn)生了一個錯誤，網(wǎng)絡(luò)層產(chǎn)生最終結(jié)果N_USData.ind。這對

P2CAN_Client定時器不影響。而且適用掛起應(yīng)答信息列表的處理。

j)服務(wù)器通過N_USData.con指示完成發(fā)送。

6.3.5.2.3非默認(rèn)會話期間的功能通信

圖9非默認(rèn)會話期間的功能通信

圖9描述了非默認(rèn)會話期間客戶機與2個服務(wù)器功能地址請求信息的定時操作。這里一個服務(wù)器通過應(yīng)答碼為0x78的否定應(yīng)答請求一個擴展的應(yīng)答定時。從服務(wù)器角度看，

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req至網(wǎng)絡(luò)層開始功能地址診斷會話控制（0x10）的發(fā)送。網(wǎng)

絡(luò)層傳遞該請求信息至服務(wù)器。請求信息是單幀。b)客戶端通過N_USData.con指示請求信息的完成。6.3.5.1.1和6.3.5.1.2描述的應(yīng)答定時適用于此。

除此之外，客戶端產(chǎn)生的N_USData.con促使S3Client定時器開啟（會話定時器）。

c)服務(wù)器通過N_USData.ind指示請求信息的完成。6.3.5.1.1和6.3.5.1.2描述的應(yīng)答定時適用于此。d)圖上給出，假定客戶機需要服務(wù)器一個應(yīng)答。服務(wù)器應(yīng)當(dāng)發(fā)送診斷會話控制（0x10）的確定應(yīng)答信

息。e)服務(wù)器通過N_USData.con指示確定應(yīng)答信息發(fā)送的完成。然后服務(wù)器開啟S3Server定時器，只要它

不超時，它就一直處于非默認(rèn)狀態(tài)。客戶機負(fù)責(zé)保證S3Server定時器在它超時之前復(fù)位，以保證服務(wù)器處于非默認(rèn)會話狀態(tài)。

f)一旦客戶機開啟了S3Client定時器，這會促使不需應(yīng)答信息的功能地址（0x3E）請求信息的發(fā)送。

每一次發(fā)送的時機都是在S3Client超時時發(fā)送。

g)在網(wǎng)絡(luò)層通過N_USData.con指示（0x3E）請求信息傳遞完成之后，客戶機再次啟動S3Client定時器。

這就是說，功能地址請求信息是在每一次S3Client定時超時之后，周期性發(fā)送的。h)服務(wù)器在處理診斷服務(wù)的任何時間內(nèi)，它都中止S3Server定時器。

i)當(dāng)診斷服務(wù)處理完之后，服務(wù)器重啟S3Server定時器。這就是說，診斷服務(wù)，包括（0x3E），都重置

S3Server定時器。診斷服務(wù)是在接收到請求信息（N_USDataFF.ind或者N_USData.ind服務(wù)）與完成

最終結(jié)果應(yīng)答這個期間內(nèi)處理的。這里是需要一條應(yīng)答信息的?；蛘哒埱笕缓笤\斷服務(wù)動作的完成

不需要任何應(yīng)答信息。（及時到達一個點會促使一個應(yīng)答信息的發(fā)送）

j)所有（0x3E）請求信息，在服務(wù)器處理另外一條請求信息期間接收的話，都會被服務(wù)器忽略。由于

它已經(jīng)中止了S3Server定時器，并且在服務(wù)處理完之后重啟。

P2CAN_Client與P2CAN_Server定時處理與6.3.5.1.1和6.3.5.1.2小節(jié)中描述的處理方法

一致。唯一的區(qū)別是客戶端重置的值及服務(wù)器端發(fā)送結(jié)果應(yīng)答時間會有不同。這是由于轉(zhuǎn)變到另一會話層而不是使用默認(rèn)會話層，因此使用的是不同的P2CAN節(jié)診斷會話控制（0x10）服務(wù)對定時參數(shù)更詳細(xì)的描述。）

_Client的值。（見9.2.1

6.3.5.3客戶機請求信息最小時間

為服務(wù)器輪詢的服務(wù)數(shù)據(jù)的解讀，這對客戶機請求信息發(fā)送的最小間隔時間有要求的。例如，基于標(biāo)準(zhǔn)的功能，服務(wù)器可能處理診斷請求信息以預(yù)定的速率（例如10ms）。診斷

圖18——應(yīng)答信息類型#1的處理

a)

客戶機診斷應(yīng)用通過

發(fā)送N_USData.req到網(wǎng)絡(luò)層開始發(fā)送ReadDataByPeriodIdentifier(0x2A)請求信息。網(wǎng)絡(luò)層發(fā)送該信息之服務(wù)器。請求信息要么做為單幀信息要么是多幀信息（依靠于請求信息中periodicDataIdentifier包含的數(shù)量）。該例中，假定請求信息是單幀信息。b)c)

止S3Server定時器。d)

且周期信息的發(fā)送將要隨后開啟。e)

時器，這用于保持處于非默認(rèn)會話狀態(tài)，而不超時。f)

服務(wù)器開始發(fā)送周期

應(yīng)答信息（單幀信息）。每個周期信息使用網(wǎng)絡(luò)層協(xié)議并且使用用于其它應(yīng)答信息的CAN應(yīng)答標(biāo)識。因此，服務(wù)器每次發(fā)送N_USData.req到網(wǎng)絡(luò)層時，一個周期信息都被發(fā)送，并且當(dāng)前沒有其它服務(wù)在被服務(wù)器處理。例子中，假定服務(wù)器在下一個請求信息到來之前，能發(fā)送客戶機發(fā)起的3周期信息。周期應(yīng)答信息的發(fā)送對定時器S3Server無任何影響（見6.3.5.4）。g)

客戶機診斷應(yīng)用層通

過發(fā)送N_USData.req到網(wǎng)絡(luò)層開始發(fā)送ReadDataByPeriodIdentifier(0x2A)請求信息。網(wǎng)絡(luò)層發(fā)送該信息之服務(wù)器。請求信息要么做為單幀信息要么是多幀信息（依靠于請求信息中periodicDataIdentifier包含的數(shù)量）。該例中，假定請求信息是單幀信息。h)i)

客戶機通過

N_USData.con指示請求信息的完成。隨后應(yīng)答定時參考6.3.5.1.1和6.3.5.1.3。

在周期機制激活期間，

服務(wù)器通過N_USData.ind（或者單幀的N_USData.ind）指示請求信息的開始。服務(wù)器應(yīng)當(dāng)馬上中止周期機制，處理接收到的請求信息。而且，服務(wù)器在處理任何診斷服務(wù)的時候，它都中止S3Server定時器。j)

送機制處于非激活狀態(tài)。k)

例中，假定應(yīng)答時多幀信息。l)m)

動作。由于S3Server定時器還沒有重新激活。

圖中，假定客戶機需要

服務(wù)器的一個應(yīng)答。服務(wù)器應(yīng)當(dāng)通過發(fā)送N_USData.req至網(wǎng)絡(luò)層發(fā)送一個確定（或否定）應(yīng)答。該

服務(wù)器通過

N_USData.ind指示多幀請求信息的完成，隨后應(yīng)答定時參考6.3.5.1.1和6.3.5.1.2。周期信息發(fā)

服務(wù)器通過

N_USData.con指示ReadDataPeriodicIdentifier應(yīng)答信息發(fā)送的完成。隨后服務(wù)器重啟S3Server定

圖中，假定客戶機需要

服務(wù)器的一個應(yīng)答。服務(wù)器應(yīng)發(fā)送ReadDataPeriodicIdentifier確定應(yīng)答信息指示請求已被處理并

客戶機通過

N_USData.con指示請求信息的完成。隨后應(yīng)答定時參考6.3.5.1.1和6.3.5.1.3。

服務(wù)器通過

N_USData.ind指示請求信息的完成。隨后應(yīng)答定時參考6.3.5.1.1和6.3.5.1.2，而且，服務(wù)器停

S3Client定時器超時，

客戶機發(fā)送功能地址TesterPresent(0x3E)請求信息重啟服務(wù)器中的S3Server定時器。

服務(wù)器在處理從前請

求，發(fā)送多幀信息應(yīng)答的過程中。因此，服務(wù)器在接收到TesterPresent(0x3E)請求信息時，不應(yīng)

n)當(dāng)診斷服務(wù)完全處理

完了，服務(wù)器重啟S3Server定時器。這是說，所有診斷服務(wù)包括TesterPresent(0x3E)都能重啟

S3Server定時器。診斷服務(wù)在接收到請求信息（N_USDataFF.ind和N_USData.ind）到完成最終結(jié)果

應(yīng)答的時間內(nèi)都會執(zhí)行。當(dāng)需要應(yīng)答信息時，或者當(dāng)有請求導(dǎo)致的動作的完成但不需應(yīng)答信息時（指定時間的到達導(dǎo)致的應(yīng)答信息）。這包括否定應(yīng)答信息（包括應(yīng)答碼0x78）。服務(wù)器在完成處理之后（最終結(jié)果信息完全發(fā)送）重啟周期機制。o)

服務(wù)器重啟周期應(yīng)答

信息的發(fā)送（單幀信息）。每一周期信息使用網(wǎng)絡(luò)層協(xié)議，及用于其它應(yīng)答信息的CAN應(yīng)答標(biāo)識。因此，服務(wù)器每周期發(fā)送一個N_USData.req至網(wǎng)絡(luò)層并被傳輸，并且服務(wù)器沒有其它服務(wù)在當(dāng)前處理。周期應(yīng)答信息的發(fā)送對S3Server不影響。（見6.3.5.4）p)

時時。q)

網(wǎng)絡(luò)層通過

N_USData.con指示TesterPresent(0x3E)請求信息發(fā)送完之時，客戶機再次重啟S3Client定時器。也就是說，功能地址TesterPresent（0x3E）請求信息在S3Client定時器每次超時的周期都發(fā)送。

一旦S3Client開啟（非

默認(rèn)會話激活），導(dǎo)致功能地址TesterPresent(0x3E)的發(fā)送，不需要應(yīng)答信息。每次在S3Client超

圖19——應(yīng)答信息類型#2處理

a)客戶機診斷應(yīng)用通過

發(fā)送N_USData.req到網(wǎng)絡(luò)層開始發(fā)送ReadDataByPeriodIdentifier(0x2A)請求信息。網(wǎng)絡(luò)層發(fā)送該信息之服務(wù)器。請求信息要么做為單幀信息要么是多幀信息（依靠于請求信息中periodicDataIdentifier包含的數(shù)量）。該例中，假定請求信息是單幀信息。

b)c)

止S3Server定時器。d)

且周期信息的發(fā)送將要隨后開啟。e)

時器，這用于保持處于非默認(rèn)會話狀態(tài)，而不超時。f)

客戶機通過

N_USData.con指示請求信息的完成。隨后應(yīng)答定時參考6.3.5.1.1和6.3.5.1.3。

服務(wù)器通過

N_USData.ind指示請求信息的完成。隨后應(yīng)答定時參考6.3.5.1.1和6.3.5.1.2，而且，服務(wù)器停

圖中，假定客戶機需要

服務(wù)器的一個應(yīng)答。服務(wù)器應(yīng)發(fā)送ReadDataPeriodicIdentifier確定應(yīng)答信息指示請求已被處理并

服務(wù)器通過

N_USData.con指示ReadDataPeriodicIdentifier應(yīng)答信息發(fā)送的完成。隨后服務(wù)器重啟S3Server定

服務(wù)器開始發(fā)送周期

應(yīng)答信息（單幀信息）。每個周期信息使用網(wǎng)絡(luò)層協(xié)議并且使用用于其它應(yīng)答信息的CAN應(yīng)答標(biāo)識。因此，服務(wù)器每次發(fā)送N_USData.req到網(wǎng)絡(luò)層時，一個周期信息都被發(fā)送，并且當(dāng)前沒有其它服務(wù)在被服務(wù)器處理。例子中，假定服務(wù)器在下一個請求信息到來之前，能發(fā)送客戶機發(fā)起的3周期信息。周期應(yīng)答信息的發(fā)送對定時器S3Server無任何影響（見6.3.5.4）。

g)客戶機診斷應(yīng)用層通

過發(fā)送N_USData.req到網(wǎng)絡(luò)層開始發(fā)送ReadDataByPeriodIdentifier(0x2A)請求信息。網(wǎng)絡(luò)層發(fā)送該信息之服務(wù)器。請求信息要么做為單幀信息要么是多幀信息（依靠于請求信息中periodicDataIdentifier包含的數(shù)量）。該例中，假定請求信息是單幀信息。

h)i)

客戶機通過

N_USData.con指示請求信息的完成。隨后應(yīng)答定時參考6.3.5.1.1和6.3.5.1.3。

在周期機制激活期間，

服務(wù)器通過N_USData.ind（或者單幀的N_USData.ind）指示請求信息的開始。服務(wù)器應(yīng)當(dāng)馬上中止周期機制，處理接收到的請求信息。而且，服務(wù)器在處理任何診斷服務(wù)的時候，它都中止S3Server定時器。

j)

送機制處于非激活狀態(tài)。k)

服務(wù)器通過

N_USData.ind指示多幀請求信息的完成，隨后應(yīng)答定時參考6.3.5.1.1和6.3.5.1.2。周期信息發(fā)

圖中，假定客戶機需要

服務(wù)器的一個應(yīng)答。服務(wù)器應(yīng)當(dāng)通過發(fā)送N_USData.req至網(wǎng)絡(luò)層發(fā)送一個確定（或否定）應(yīng)答。該例中，假定應(yīng)答是多幀信息。當(dāng)網(wǎng)絡(luò)層發(fā)送完多幀應(yīng)答信息時，周期機制繼續(xù)發(fā)送周期應(yīng)答信息。

l)m)

S3Client定時器超時，

客戶機發(fā)送功能地址TesterPresent(0x3E)請求信息重啟服務(wù)器中的S3Server定時器。

服務(wù)器在處理從前請

求，發(fā)送多幀信息應(yīng)答的過程中。因此，服務(wù)器在接收到TesterPresent(0x3E)請求信息時，不應(yīng)動

服務(wù)數(shù)據(jù)解讀預(yù)定時間應(yīng)當(dāng)比運行要求時間P2CAN_Server短，以滿足6.3.5和6.3.5.1.2對

服務(wù)器要求。

請求信息間隔時間的最小定時參數(shù)分為如下兩個定時參數(shù)。——P3CAN_Functional：該定時參數(shù)適用于所有功能地址請求信息，由于它在不支持應(yīng)答數(shù)據(jù)

的狀況下，服務(wù)器不要求響應(yīng)功能地址請求信息。——P3CAN_Physical：該定時參數(shù)適用于不需服務(wù)器應(yīng)答的物理地址請求信息。

（suppressPosRspMsgIndicationBit=TRUE）。

物理通信在需要服務(wù)器應(yīng)答的狀況下，客戶端可以在接收到最終一條應(yīng)答信息的時候馬上發(fā)送下一個請求，由于服務(wù)器在完成最終結(jié)果應(yīng)答時——意味著該請求已被服務(wù)器完全處理完了。

圖10描述了功能通信期間出現(xiàn)一個問題的例子。當(dāng)客戶機在它確認(rèn)所有期望的服務(wù)器都對從前做了應(yīng)答時，馬上發(fā)送下一個請求信息。

該情景不僅適用于功能地址請求也適用于物理地址請求，這里客戶機不需接受任何應(yīng)答信息（suppressPosRspMsgIndicationBit=TRUE）。

為了處理上述狀況，在一條物理或功能地址請求信息與新的物理或功能地址請求信息之間，最小時間P3CANa)P3CAN_Physical_Physical和P3CAN_Functional需要為客戶機定義。

_Server_max的值與物理地址的服務(wù)器P2CAN的值一致。該定時適用于所有診斷

會話（默認(rèn)的或非默認(rèn)的）的所有物理地址請求信息而且所有狀況下，都不需要服務(wù)器應(yīng)答。

客戶機每次啟動P3CAN_Physical定時，都發(fā)送一條不需應(yīng)答的物理地址請求信息到總線上，

并且，網(wǎng)絡(luò)層通過N_USData.con指示。當(dāng)客戶機在從前請求信息完全處理完之后，想要發(fā)送新的物理地址請求信息時，這只有在P3CAN_Physical定時器不處于活動的狀況下。

_Physical客戶端在發(fā)送一條新的物理地址請求信息的時刻，啟動P3CAN要等到P3CANb)P3CAN_Physical。然后信息的發(fā)送

超時。

_Server_max_Functional的值是所有功能地址服務(wù)器P2CAN，所有診斷會話（默認(rèn)的或非

默認(rèn)的），所有功能地址請求信息的最大值（最壞狀況）?？蛻舳嗣看伍_啟P3CAN_Functional定時器，都發(fā)送不需應(yīng)答的功能地址請求信息到總線上，

并且客戶端網(wǎng)絡(luò)層通過N_USData.con指示。當(dāng)客戶機在從前請求信息完全處理完之后，想要發(fā)送新的物理地址請求信息時，這只有在P3CAN_Functional定時器不處于活動的狀況下?？?/p>

_Functional戶端在發(fā)送一條新的物理地址請求信息的時刻，啟動P3CAN到P3CAN_Functional。然后信息的發(fā)送要等

超時。

注意：“完全處理完〞就是說要么不需應(yīng)答時沒有接收到任何應(yīng)答，要么所有期待的應(yīng)答都

接受到了。應(yīng)答的服務(wù)器知道并且要求應(yīng)答，或者服務(wù)器不知道并且要求應(yīng)答時出現(xiàn)

P2CAN_Client超時。

_Server對服務(wù)器的要求是它應(yīng)當(dāng)在P2CAN信息的解讀時間應(yīng)當(dāng)短于P2CAN_Server（見圖7.3）時間內(nèi)應(yīng)答信息，這就是說，診斷

。

圖10——發(fā)送下一條請求太早的例子

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req功能地址請求信息到網(wǎng)絡(luò)層。網(wǎng)絡(luò)層傳遞信息到服務(wù)器。b)客戶端通過NUSData.con只是請求信息的完成?？蛻魴C使用默認(rèn)的P2CAN定時器。

c)服務(wù)器通過N_USData.ind指示請求信息的完成。服務(wù)器使用默認(rèn)的P2CAN_Server_Client值開啟P2CAN_Client值開啟P2CAN_Server定時器。

d)對于請求的信息，假定只有服務(wù)器#1支持請求信息，也就是說服務(wù)器#2不會應(yīng)答信息。服務(wù)器#1

是快速服務(wù)器，能很快處理完請求的信息并在P2CAN_Server時間內(nèi)發(fā)送應(yīng)答信息。

e)客戶機接收到應(yīng)答信息。這通過N_USData.ind指示?？蛻魴C僅僅期待服務(wù)器#1的應(yīng)答信息，因此

它中止P2CAN_Client定時器。

f)服務(wù)器#2是慢速服務(wù)器，并且在一段時間內(nèi)（診斷服務(wù)數(shù)據(jù)解讀時間）解讀請求信息，最壞的狀況

下，在網(wǎng)絡(luò)層接收到請求信息之前進行了最終一次請求的信息檢查。這就是說，請求會存儲在一個

緩沖區(qū)并且在檢查請求信息的例程時執(zhí)行。當(dāng)服務(wù)器#2處理該條請求時，它確定了它不需要應(yīng)答，由于它不支持該條請求信息。如下圖，這有可能在服務(wù)器#1完成應(yīng)答信息之后或是在客戶機下一條請求信息之后發(fā)生。

g)客戶機在所有期待的應(yīng)答信息完成之后，會馬上發(fā)送下一條請求。

h)服務(wù)器通過N_USData.ind指示請求信息的完成。但僅僅在快速服務(wù)器#1中進行，由于在服務(wù)器#2

不處理最近一條信息。

i)客戶機新的請求的完成通過N_USData.con指示。

圖11描述了客戶機（基于圖10說明的通信狀況）P3CAN_Functional定時處理。除此之外

_Functional圖11顯示了客戶機功能地址（0x3E）的請求。在S3Client超時且P3CAN求將等待P3CAN

_Functional活動時（請

超時）。

圖11——功能地址請求信息間隔時間最小值（P3CAN_Functional）

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req至網(wǎng)絡(luò)層開始發(fā)送功能地址請求信息。網(wǎng)絡(luò)層傳遞請求只

服務(wù)器。b)客戶端通過N_USData.con指示請求信息的完成?？蛻魴C開啟P2CAN_Client定時器并且開啟

P3CAN_Functional定時器。

c)服務(wù)器通過N_USData.ind指示請求信息的完成。

d)對于請求的信息，假定只有服務(wù)器#1支持請求信息，也就是說服務(wù)器#2不會應(yīng)答信息。服務(wù)器#1

是快速服務(wù)器，能很快處理完請求的信息并在P2CAN_Server時間內(nèi)發(fā)送應(yīng)答信息。

e)客戶機接收到應(yīng)答信息。這通過N_USData.ind指示?？蛻魴C僅僅期待服務(wù)器#1的應(yīng)答信息，因此

它中止P2CAN_Client定時器。

f)服務(wù)器#2是慢速服務(wù)器，并且在一段時間內(nèi)（診斷服務(wù)數(shù)據(jù)解讀時間）解讀請求信息，最壞的狀況

下，在網(wǎng)絡(luò)層接收到請求信息之前進行了最終一次請求的信息檢查。這就是說，請求會存儲在一個緩沖區(qū)并且在檢查請求信息的例程時執(zhí)行。當(dāng)服務(wù)器#2處理該條請求時，它確定了它不需要應(yīng)答，由于它不支持該條請求信息。g)盡管客戶機接收到了功能地址請求信息所有期待的應(yīng)答信息，它仍要等待P3CAN許發(fā)送下一條請求信息。在P3CAN_Client_Client超時之后才允

超時的時刻，客戶機發(fā)送下一條請求信息。

h)新的請求信息服務(wù)器中通過N_USData.ind指示。并服務(wù)器#1馬上處理，而服務(wù)器#2下一次檢查請

求信息例程中處理該請求。i)客戶機通過N_USData.con指示新的請求的完成，并且開啟P3CAN_Functional定時器。

j)對于請求的信息，假定只有服務(wù)器#1支持請求信息，也就是說服務(wù)器#2不會應(yīng)答信息。服務(wù)器#1

是快速服務(wù)器，能很快處理完請求的信息并在P2CAN_Server時間內(nèi)發(fā)送應(yīng)答信息。

k)客戶機接收到應(yīng)答信息。這通過N_USData.ind指示?？蛻魴C僅僅期待服務(wù)器#1的應(yīng)答信息，因此

它中止P2CAN_Client定時器。

l)服務(wù)器#2是慢速服務(wù)器，并且在一段時間內(nèi)（診斷服務(wù)數(shù)據(jù)解讀時間）解讀請求信息，最壞的狀況

下，在網(wǎng)絡(luò)層接收到請求信息之前進行了最終一次請求的信息檢查。這就是說，請求會存儲在一個緩沖區(qū)并且在檢查請求信息的例程時執(zhí)行。當(dāng)服務(wù)器#2處理該條請求時，它確定了它不需要應(yīng)答，由于它不支持該條請求信息。m)客戶機S3Client定時器超時，促使客戶機發(fā)送不需服務(wù)器應(yīng)答的功能地址（0x3E）請求信

息。在這種狀況下，P3CAN時發(fā)送。n)當(dāng)P3CAN_Functional_Functional此時依舊活動著，（0x3E）的發(fā)送應(yīng)當(dāng)?shù)絇3CAN_Functional超時

定時器超時的時候，客戶機可以通過N_USData.req發(fā)送功能地址（0x3E）請求。

o)服務(wù)器通過N_USData.ind指示（0x3E）請求信息的接收。p)客戶機通過N_USData.con指示（0x3E）請求的完成，并啟動P3CAN_Functional定時器。

圖12描述了客戶機P3CAN_Physical定時器的操作。該圖顯示了不需應(yīng)答的物理地址請求

的發(fā)送操作及S3Client超時時功能地址（0x3E）請求信息。

圖12——物理地址通信間隔最短時間P3CAN_Physical

a)客戶端診斷應(yīng)用層通過發(fā)送N_USData.req至網(wǎng)絡(luò)層開始發(fā)送物理地址請求信息。網(wǎng)絡(luò)層傳遞請求只

服務(wù)器。b)客戶端通過N_USData.con指示請求信息的完成?？蛻魴C開啟P3CAN答信息，因此，客戶機不需要開啟P2CAN_Client_Physical定時器。由于不需要應(yīng)

定時器。

c)服務(wù)器通過N_USData.ind指示請求信息的完成。在任何非默認(rèn)會話期間，S3Server定時器此刻是中止的。

d)服務(wù)器在一定時期內(nèi)（診斷服務(wù)數(shù)據(jù)解讀時間）解讀請求。在下一次檢查請求例程中請求被處理。

在非默認(rèn)會話期間，服務(wù)的完全執(zhí)行會重置S3Server定時器。

e)客戶機S3Client定時器超時，促使客戶機發(fā)送功能地址（0x3E）請求信息，不需服務(wù)器的應(yīng)答。

f)假定P3CAN_Functional定時器此時沒有活動，也就是說請求被馬上發(fā)送。

g)客戶機通過N_USData.con指示（0x3E）請求信息的完成。

h)服務(wù)器通過N_USData.ind指示（0x3E）請求信息得接收。此刻，從前接收到的物理請求依舊在服務(wù)

器端掛起（還沒有處理）并且S3Server定時器中止。因此，接收到的（0x3E）請求信息會被服務(wù)器忽略。i)當(dāng)P3CAN_Physical定時器在客戶機超時，客戶機遇通過發(fā)送N_USData.req發(fā)送下一條物理地址請求

信息至網(wǎng)絡(luò)層。

j)客戶機通過N_USData.con指示物理地址請求信息的完成?？蛻魴C現(xiàn)在重新開啟P3CAN器。由于不需應(yīng)答信息，因此客戶端不啟動P2CAN_Client_Physical定時

定時器。

k)服務(wù)器通過N_USData.ind指示請求信息的完成。在任何非默認(rèn)會話狀況下，S3Server定時器此刻停

止。

6.3.5.4主動提供的應(yīng)答信息

服務(wù)器主動提供的應(yīng)答信息要么是周期性例程（見服務(wù)ReadDataByPeriodicIdentifierin9.3.4）或者配置引發(fā)的，例如DTC狀態(tài)的變化或者一個日期標(biāo)識的改變（見服務(wù)ResponseOnEventin9.2.8）。

所有主動提供的應(yīng)答信息服務(wù)器都不應(yīng)當(dāng)重啟S3Server定時器。這在周期性信息傳輸或者時間觸發(fā)的事件中時間的時間間隔比S3Server短的狀況下，有效避免了診斷會話的鎖死。

S3Server定時器只應(yīng)當(dāng)在處理一條請求信息并發(fā)送最終結(jié)果應(yīng)答信息（例如，初始確定應(yīng)答指示一個請求成功執(zhí)行）的時候被重置。

6.3.6出錯的處理

應(yīng)用層以及客戶機和服務(wù)器在物理通信、功能通信期間的會話管理出錯的處理應(yīng)當(dāng)依照表7、表8。假定客戶機和服務(wù)器都依照該部分15765協(xié)議進行應(yīng)用層及會話層的定時處理。

表7——客戶機錯誤處理

通信階段請求發(fā)送客戶端錯誤類型物理通信客戶機處理功能通信網(wǎng)絡(luò)層的客戶機在P3CAN_Physical時間之客戶機在P3CAN_Physical時間之后，N_USData.con指示否定結(jié)果值后，有出錯指示，應(yīng)當(dāng)重發(fā)最終有出錯指示，應(yīng)當(dāng)重發(fā)最終的請求的請求重啟S3Client（由于S3Client在請求發(fā)送時中止了）超時客戶機重新發(fā)送最近的請求信息。重啟S3Client（由于S3Client在請求發(fā)送時中止了）這里客戶機不知道多少服務(wù)器應(yīng)答，這就是指示客戶機不再有應(yīng)答信息了。不用再重復(fù)請求信息了?？蛻魴C在進一步請求之前，應(yīng)當(dāng)完全接受到所有的應(yīng)答信息。這里客戶機知道有多少服務(wù)器應(yīng)答，這就是指示客戶機不是所有的服務(wù)器都應(yīng)答?？蛻魴C在完全接收到所有應(yīng)答信息之時發(fā)生了超時，應(yīng)當(dāng)重新請求信息。P2CAN*P2CAN_Client_Client應(yīng)答接收N_USData.ind網(wǎng)絡(luò)層否定結(jié)果值客戶機重新發(fā)送最近的請求信息。重啟S3Client（由于S3Client在請求發(fā)送時中止了）客戶機在完全接收到所有應(yīng)答信息之時，出錯，應(yīng)當(dāng)重新請求發(fā)送信息?？蛻魴C出錯處理運行最多2次，也就是說，最壞狀況下，請求服務(wù)的發(fā)送只能是3次。表8——服務(wù)器出錯處理通信階段請求接收服務(wù)器錯誤類型網(wǎng)絡(luò)層N_USData.ind指示否定結(jié)果值超時_Server處理重啟S3Server定時器（由于它在接收到從