DCM之診斷會話層（DSL）詳解一

簡介

[SWS_Dcm_00030] DSL子模塊的全部功能區域應符合規範ISO14229-1 [15]和ISO15765-3 [18]的與網絡無關的部分。（BSW04003） DSL子模塊。 在配置中，能夠根據網絡設置一些參數。

用例
DSL子模塊提供如下功能：

•   會話處理（根據ISO14229-1 [15]和ISO 15765-3 [18]的要求）
•   應用層定時處理（根據ISO14229-1 [15]和ISO 15765-3 [18]的要求）
•   特定的響應行爲（按照ISO14229-1 [15]和ISO 15765-3 [18]的要求）

與其餘模塊的交互
DSL與其餘模塊具備如下交互：

• PduR模塊：PduR模塊提供傳入診斷請求的數據。DSL子模塊觸發診斷響應的輸出。
• DSD子模塊：DSL子模塊將傳入請求通知DSD子模塊並提供數據。DSD子模塊觸發診斷響應的輸出。
• SW-C / DSP子模塊。 DSL子模塊提供對安全性和會話狀態的訪問。
• ComM模塊：DSL子模塊保證了ComM模塊所需的通訊行爲

功能說明
總覽
DSL子模塊提供如下功能：
請求處理

　　-將請求從PduR模塊轉發到DSD子模塊。

　　-併發「 TesterPresent」（「保持活動邏輯」）。
響應處理
　　-將響應從DSD子模塊轉發到PduR模塊。
　　-確保對測試人員的響應時間。
　　-支持按期傳輸。
　　-支持ResponseOnEvent（ROE）傳輸。
　　-支持分段響應。
　　-支持由應用程序觸發的ResponsePending響應。
安全等級處理
　　-管理安全級別。
會話狀態處理
　　-管理會話狀態。
　　-跟蹤活動的非默認會話。
　　-容許修改時間。
診斷協議處理
　　-處理不一樣的診斷協議。
　　-管理資源。
通信模式處理
　　-處理通信要求（全/無聲/無通信）。
　　-指示活動/非活動診斷。
　　-啓用/禁用各類診斷傳輸。

將請求從PduR模塊轉發到DSD子模塊
每當在分配給DCM模塊的DcmRxPduId上開始接收新的診斷請求內容時，PduR模塊就會指示DCM模塊。這是經過調用Dcm_StartOfReception（）來完成的，Dcm_StartOfReception（）通知DCM模塊要接收的數據大小，並提供第一幀或單幀的數據，若是數據大小超出其緩衝區大小，則容許DCM拒絕接收，或者若是請求的服務不可用。對Dcm_CopyRxData的進一步調用要求DCM模塊將數據從提供的緩衝區複製到DCM緩衝區。若是診斷請求的接收完成（當Dcm_StartOfReception接收時）
若是成功，則PduR模塊將調用Dcm_TpRxIndication（）向DCM模塊給出接收指示.DCM應可以使用通用鏈接，其中地址信息由Dcm_StartOfReception（）經過DcmRxPdu的MetaData提供給DCM。必須存儲此尋址信息，並將其用於響應以及檢測來自同一測試人員的請求。有關更多詳細信息，請參見「通用鏈接處理」章節。

[SWS_Dcm_00111]僅在使用參數Result = E_OK調用Dcm_TpRxIndication（）以後，DSL子模塊纔將接收到的數據轉發到DSD子模塊（請參閱SWS_Dcm_00093）。

[SWS_Dcm_00241]一旦收到請求消息（在調用帶有參數Result = E_OK的Dcm_TpRxIndication（）以後（請參見SWS_Dcm_00093），直到爲關聯的Tx-DcmPduId調用了Dcm_TpTxConfirmation（）（請參見SWS_Dcm_00351），DSL就會被髮送。 子模塊應阻止相應的DcmPduId。 在處理此請求期間，沒法接收到同一DcmDslConnection的其餘請求（例如，加強的會話能夠由OBD會話終止），直到發送了相應的響應消息並再次釋放DcmPduId（併發TesterPresent請求除外）爲止 ）。

能夠在PduR模塊的接口描述中找到有關API的更多描述（原型，輸入/輸出參數）。對於不一樣的診斷通訊應用程序，可使用不一樣的DcmPduId。 例如：

• OBD DcmRxPduId：用於接收OBD請求，
• OBD DcmTxPduId：用於傳輸OBD響應，
• UDS phys DcmRxPduId：用於接收UDS物理尋址的請求。
• UDS函數DcmRxPduId：用於接收功能已尋址的UDS請求。
• UDS DcmTxPduId：用於傳輸UDS響應。

每一個DcmRxPduId配置了地址類型（物理/功能尋址）（請參閱配置參數DcmDslProtocolRx）。 能夠對每一個DcmRxPduId進行配置，由於對於功能和物理接收而言，始終存在不一樣的DcmRxPduId值，而與傳輸層的尋址格式（擴展尋址，常規尋址）無關。

併發「 TesterPresent」（「保持活動邏輯」）

 測試人員可能會與物理請求/響應並行發送功能「 TesterPresent」命令。 在ISO14229-1 [15]中，這稱爲「保持活動邏輯」。 此功能「 TesterPresent」將在單獨的DcmRxPduId（UDS func DcmRxPduId）上接收，該DcmRxPduId與物理請求屬於同一DcmDslConnection。 在這種狀況下，將使用未明確配置的Dcm內部接收緩衝區。 所以，功能性TesterPresent（而且只有功能性TesterPresent沒有響應）的處理方式以下：

[SWS_Dcm_00112]當PduR模塊使用參數Result = E_OK調用Dcm_TpRxIndication（）時（請參見SWS_Dcm_00093），而且若是請求是「 TesterPresent」命令，且「 suppressPosRspMsgIndicationBit」設置爲TRUE（SID等於0x3E，子功能等於0x3E） DSL子模塊應重置會話超時計時器（S3Server）。
[SWS_Dcm_00113]當PduR模塊使用參數Result = E_OK調用Dcm_TpRxIndication（）時（請參閱SWS_Dcm_00093），而且若是請求是「 TesterPresent」命令且「 suppressPosRspMsgIndicationBit」設置爲TRUE（SID等於0x3E，則子函數等於） DSL子模塊不得將此請求轉發給DSD子模塊以做進一步解釋。

 SWS_Dcm_00113的原理：因爲繞過了DSL子模塊中的功能「 TesterPresent」，所以DCM模塊可以無延遲地接收和處理下一個物理請求。

將響應從DSD子模塊轉發到PduR模塊

[SWS_Dcm_00114] DSD子模塊應請求DSL子模塊傳輸響應。
[SWS_Dcm_00115]當DcmDslMainConnection的診斷響應準備就緒時，DSL子模塊應經過使用相應的調用PduR_DcmTransmit（）來觸發診斷響應向PduR模塊的傳輸。
DcmDslProtocolTxPduRef參數做爲PduId。
[SWS_Dcm_01072]⌈若是是PeriodicTransmission，則Dcm應在對PduR_DcmTransmit（）的調用中提供完整的有效載荷數據，而且指望不對Dcm_CopyTxData進行任何調用。
[SWS_Dcm_01073]在進行週期性傳輸的狀況下，將使用Dcm_TxConfirmation（）調用Dcm進行週期性傳輸以指示傳輸結果使用DcmTxPduId發送響應，該消息在DCM模塊配置中連接到DcmRxPduId，即接收請求的ID（請參閱配置參數DcmDslProtocolTx）在PduR_DcmTransmit（）內，僅將長度信息以及（對於通用鏈接而言）尋址信息提供給PduR模塊。在DCM模塊成功調用PduR_DcmTransmit（）以後，PduR模塊將調用Dcm_CopyTxData（）來請求DCM模塊提供要發送的數據，而且在成功發送完完整的PDU或發生錯誤以後將調用Dcm_TpTxConfirmation（）。有關通用鏈接內地址信息處理的更多詳細信息，請參見第7.2.4.5節「通用鏈接處理」。
[SWS_Dcm_00117]若是在成功發送了完整的DCM PDU後DSL子模塊收到確認，或者經過調用Dcm_TpTxConfirmation（）發生錯誤，則DSL子模塊應將此確認轉發給DSD子模塊。

[SWS_Dcm_00118]傳輸失敗時（失敗PduR_DcmTransmit（）請求）或錯誤確認（Dcm_TpTxConfirmation（）帶有錯誤），DSD子模塊不得重複診斷響應發送。
注意：僅當PduR_DcmTransmit成功時才指望Dcm_TpTxConfirmation。有關API的更多描述（原型，輸入/輸出參數），請參見PduR模塊的接口描述。

 通用鏈接處理

DCM將可以處理由DcmPdus標識且MetaDataLength> = 1的通用鏈接。這些鏈接在運行時攜帶實際的測試儀地址。 根據ISO15765-2 [17]，使用常規的固定或混合29位尋址格式的CAN診斷支持通用鏈接。 根據CAN ID的實際佈局，通用鏈接也能夠用於擴展或常規和混合的11位尋址格式。 DCM沒法識別CanTp使用的實際尋址格式。
通用鏈接不須要配置參數DcmDslProtocolRxTesterSourceAddr。多個鏈接可能引用相同的DcmPdus。

[SWS_Dcm_00845]配置工具應經過檢查DcmDslConnection（DcmDslProtocolRxPduRef，DcmDslProtocolTxPduRef，DcmDslPeriodicTxPduRef，DcmDslPeriodicTxPduRef，DcmDslRoeTxPduRef）的全部引用PDU的MetaDataLength來驗證通用鏈接是否一致。 僅當DcmDslProtocolRxPduRef也爲通用時，TxPdu引用纔可能爲通用。
[SWS_Dcm_00848]必須存儲經過通用鏈接接收到的診斷請求的源地址。 它在經過Dcm_StartOfReception（）提供的元數據的第一個字節中提供。
[SWS_Dcm_00849]存儲的源地址應用做經過通用鏈接發送的響應的目標地址。 它應在提供給PduR_DcmTransmit（）的元數據的第二個字節中提供。

經過發送繁忙的響應來保證測試人員的時間安排

[SWS_Dcm_00024]若是應用程序（或DSP子模塊）可以執行請求的診斷任務，但須要額外的時間來完成任務並準備響應，則DSL子模塊應發送NRC 0x78（響應未決）的否認響應。達到響應時間時（DcmDspSessionP2ServerMax -DcmTimStrP2ServerAdjust分別 SWS_Dcm_00024的DcmDspSessionP2StarServerMax -DcmTimStrP2StarServerAdjust）⌋（BSW04016）比率：DSL子模塊保證了對測試器的響應時序。
[SWS_Dcm_00119] DSL子模塊應從單獨的緩衝區發送SWS_Dcm_00024中要求的否認響應。SWS_Dcm_00119的原理：這是必要的，以免覆蓋正在進行的請求處理，例如應用程序已經在診斷緩衝區中準備了響應內容。一個診斷請求的NRC 0x78（響應未決）的否認響應數受配置參數DcmDslDiagRespMaxNumRespPend限制。這樣能夠避免應用程序中的死鎖。
[SWS_Dcm_00120]若是對請求的診斷任務的否認響應數（請參見SWS_Dcm_00024）達到配置參數DcmDslDiagRespMaxNumRespPend中定義的值，則DCM模塊應中止處理活動的診斷請求，並通知應用程序或BSW（若是此診斷任務暗示）經過將活動端口接口的OpStatus參數設置爲DCM_CANCEL來調用SW-C接口或BSW接口），並應發送NRC 0x10的否認響應（常規拒絕）

 支持按期傳輸

UDS服務ReadDataByPeriodicIdentifier（0x2A）容許測試人員從由一個或多個periodicDataIdentifiers標識的ECU請求按期發送數據記錄值。
[SWS_Dcm_00122]DCM模塊應使用單獨的協議和單獨的可配置大小的緩衝區來發送週期性傳輸的響應。DcmDslPeriodicTransmissionConRef配置參數容許將用於接收週期性傳輸請求的協議連接/將週期性傳輸響應傳輸到用於傳輸週期性傳輸消息的協議。 請注意，能夠將多個DcmTxPduIds分配給按期傳輸協議.DCM模塊根據通訊模式遵照一些限制：

[SWS_Dcm_00123]週期性傳輸通訊僅應在徹底通訊模式下進行。若是不處於徹底通訊模式，則可能發生週期性傳輸事件。 所以，存在如下兩要求：
[SWS_Dcm_00125] DCM模塊應丟棄徹底通訊模式旁邊的按期傳輸事件，而且不得將其排隊等待傳輸。
[SWS_Dcm_00126]按期傳輸事件不該激活徹底通訊模式。

支持ROE傳輸

使用UDS服務ResponseOnEvent（0x86），測試人員能夠請求ECU開始或中止傳輸由指定事件啓動的響應。 在註冊要傳輸的事件後，測試人員還會指定要響應的相應服務（例如：UDS服務ReadDataByIdentifier（0x22））。
[SWS_Dcm_00595]僅當容器DcmDslResponseOnEvent存在時才啓用ROE功能。

事件狀態圖上的響應ResponseOnEvent StateChart

[SWS_Dcm_00871] Dcm應支持多個RoeEvent。 每一個RoeEvent均可以具備「 ROE已清除」，「 ROE已中止」和「 ROE已開始」狀態。 在如下部分中描述了從狀態到狀態的轉換。 下圖的標籤表示各部分的編號。

 

 

初始化Dcm（1）
[SWS_Dcm_00872] Dcm在Dcm_Init（）期間將每一個事件的狀態更改成「 ROE已清除」狀態。

從「 ROE已清除」過渡到「 ROE已中止」（2）
[SWS_Dcm_00873]經過接收有效的ROE設置請求，請求中尋址的RoeEvent變爲「 ROE中止」狀態（請參見表2）。
[SWS_Dcm_00874]若是RoeEvent是在StorageState設置爲「 storeEvent」的狀況下設置的，而沒有在StorageState設置爲「 storeEvent」的StartResponseOnEvent的狀況下發生，而且在重啓後已激活的EventWindowTime或clearResponseOnEvent已收到，則Dcm將更改成「 ROE中止」 非易失性信息可用時當即聲明。

注意：若是事件在StorageState設置爲「 StoreEvent」的狀況下初始化一次，它將一直保持初始化狀態，直到被ClearResponseOnEvent請求清除爲止（另請參見SWS_Dcm_00897）。
[SWS_Dcm_00951]若是是RoeEvent的配置參數DcmDspRoeInitialEventStatus設置爲DCM_ROE_STOPPED，Dcm將在初始化時當即切換到「 ROE已中止」狀態。
注意：DcmDspRoeInitialEventStatus集經過配置定義RoeEvent的初始化。

從「 ROE中止」過渡到「 ROE已清除」（3）
[SWS_Dcm_00875]經過使用子功能clearResponseOnEvent（0x06）接收到有效的ROE請求，RoeEvents會變爲「 ROE已清除」狀態。

從「 ROE中止」過渡到「 ROE開始」（4）
[SWS_Dcm_00876]經過使用子功能startResponseOnEvent（0x05）接收到有效的ROE請求，全部已中止的RoeEvent都將變爲「 ROE啓動」狀態。
[SWS_Dcm_00902]離開默認會話時一直處於「 ROE啓動」狀態的全部RoeEvent應在（從新）輸入默認會話時變回「 ROE啓動」狀態。
[SWS_Dcm_00965]若是收到一個有效的StartResponseOnEvent請求，且astorageState設置爲StoreEvent，而且EventWindowTime在上一個電源週期中支持StorageState，則一旦非易失性數據出現，RoeEvent應從「 ROE中止」狀態更改成「 ROE啓動」狀態可用（根據SWS_Dcm_00951，此ROEEvent設置爲「 ROE已中止」）。

從「 ROE開始」到「 ROE中止」的過渡（5）
[SWS_Dcm_00877]經過接收帶有子功能stopResponseOnEvent（0x00）的有效ROE請求，已中止的RoeEvent會更改成「 ROE已中止」狀態。
[SWS_Dcm_00878]當eventWindowTime超時時，已中止的RoeEvent會更改成「 ROE中止」狀態。

[SWS_Dcm_00879]經過退出當前會話，全部已啓動的RoeEvent應更改成「 ROE已中止」狀態。
注意：噹噹前會話離開時，RoeEvents會中止，若是該會話從非默認會話更改成相同或不一樣的非默認會話，則RoeEvent將獨立運行。經過保留默認會話，當前活動的RoeEvent將中止並存儲（以便在會話變回默認會話後當即從新啓動（請參見SWS_Dcm_00902）[SWS_Dcm_00952]⌈若是經過子功能接收到ROE請求OnDTCStatusChange和RoeEvent爲「 ROE已啓動」，OnDTCStatusChange的RoeEvent變爲「 ROE已中止」狀態，而且ServiceToRespondTo應由新請求設置的DTCStatusMask觸發。

「 ROE啓動」到「 ROE啓動」的過渡（6）
[SWS_Dcm_00880]經過使用子功能StartResponseOnEvent（0x05）接收到有效的ROE請求，Dcm會作出確定回答，並保持「 ROE啓動」狀態。 ）。

從「 ROE開始」到「 ROE已清除」的過渡（7）

[SWS_Dcm_00884]經過接收帶有子功能clearResponseOnEvent（0x06）的有效ROE請求，全部已啓動的RoeEvent都將變爲「 ROE已清除」狀態。

從「 ROE清除」到「 ROE清除」的轉換（8）

[SWS_Dcm_00885]若是全部RoeEvents都處於「 ROE清除」狀態而且收到了有效的stopResponseOnEvent（0x00）請求，則Dcm將拒絕請求，並帶有NRC 0x24的否認響應（requestSequenceError）。
[SWS_Dcm_00886]若是全部RoeEvent均處於「 ROE已清除」狀態，而且收到了有效的StartResponseOnEvent（0x05）請求，則Dcm應使用NRC 0x24的否認響應（requestSequenceError）拒絕該請求。
[SWS_Dcm_00887]若是全部RoeEvent都處於「 ROE已清除」狀態，而且Dcm確定收到了有效的clearResponseOnEvent（0x06）請求，則RoeEvent保持「 ROEcleared」狀態。）。
[SWS_Dcm_00888]若是沒法正確讀取非易失性數據，則全部處於「 ROE已清除」狀態的RoeEvent都將保持「 ROE已清除」狀態。

從「 ROE已清除」到「 ROE已開始」的過渡（9）

[SWS_Dcm_00889]若是EventWindowTime在電源週期內處於活動狀態且未超時，則Dcm必須從新激活在默認會話期間在默認會話中處於活動狀態的全部RoeEvent。非易失性信息可用時，請從新啓動電源。
[SWS_Dcm_00890]若是在存儲狀態設置爲StoreEvent的狀況下收到有效的StartResponseOnEvent請求，而且EventWindowTime在先前的電源循環中支持StorageState，則一旦非易失性數據可用，RoeEvent應更改成「 ROE啓動」狀態。

從「 ROE中止」過渡到「 ROE中止」（10）

[SWS_Dcm_00891]若是RoeEvent處於「 ROE中止」狀態且有效Dcm應收到stopResponseOnEvent（0x00）請求，Dcm應對此請求作出積極響應，並保持「 ROE中止」狀態。
[SWS_Dcm_00953]若是經過子功能接收到ROE請求OnDTCStatusChange，而且RoeEvent已經「 ROE已中止」。OnDTCStatusChange的RoeEvent將保持「 ROE已中止」狀態，但事件邏輯將使用新接收到的DTCStatusMask更新。

ROE子功能
[SWS_Dcm_00892] Dcm應支持下表中標記爲支持的全部ROE子功能。

[SWS_Dcm_00893]對於每一個設置子功能，Dcm僅應支持一個固定的ServiceToRespondTo。 表2中列出了受支持的ServiceToRespondTo

EventWindowTime和StorageState
在每一個ROE請求中，EventWindowTime和StorageState是必需參數。 它們在創建請求和相關控制請求之間可能會矛盾。
[SWS_Dcm_00903] Dcm將根據設置請求評估EventWindowTime。
[SWS_Dcm_00894] Dcm一般應支持表3中定義的EventWindowTimes。

 

 

[SWS_Dcm_00895]配置參數DcmDspRoeEventWindowTime應包含此特定Ecu支持的全部EventWindowTime的列表。
[SWS_Dcm_00896]若是Roe請求包含的事件窗口時間與DcmDspRoeEventWindowTime中配置的事件時間不一樣，則Dcm將以NRC 0x31（RequestOutOfRange）否認的響應拒絕該請求。
[SWS_Dcm_01076]若是Roe請求具備等於storeEvent的storageState且包含非無限的EventWindowTime，則Dcm應使用NRC 0x31（RequestOutOfRange）（）來否認該請求。
[SWS_Dcm_00897]若是將RoeEvent設置爲StorageState設置爲「 storeEvent」，則初始化將被非易失性存儲，以在隨後的每一個駕駛循環中恢復，直到將其清除爲止（請參見SWS_Dcm_00874）。

[SWS_Dcm_00898] Ro若是RoeEvent知足如下全部條件，則RoeEvent應在每一個後續電源週期開始時更改成「 ROE啓動」狀態，直到收到將storageStorageState設置爲StoreEvent的stopResponseOnEvent請求爲止：

• RoeEvent在默認會話中啓動
• StartResponseOnEventRequest的storageState設置爲「 StoreEvent」
• 設置請求具備EventWindowTime inifinity，而且storageState設置爲「 StoreEvent」。 ⌋（）

[SWS_Dcm_00905] if若是知足如下全部條件，則EventWindowTime將在當前電源週期結束時結束：

• 在安裝請求期間，EventWindowTime設置爲無窮（0x02）
• RoeEvent在默認會話中啓動
• 在StartResponseOnEvent請求中未設置storageState⌋（）

[SWS_Dcm_00900]⌈若是ResponseEvent在默認會話中以EventWindowTime CurrentAndFollowingCycle開始，則EventWindowTime應在下一個電源週期結束時或以clearResponseOnEvent / stopResponseOnEvent請求結束。
[SWS_Dcm_00901]⌈若是在默認會話中使用EventWindowTime currentCycle啓動ResponseOnEvent，則EventWindowTime將在此電源週期結束時或以clearResponseOnEvent / stopResponseOnEvent結束。 ⌋（）
[SWS_Dcm_00906]⌈若是在非默認會話中啓動ResponseOnEvent，則
若是知足如下條件之一，則EventWindowTime結束：

1. 關機後再開機
2. 接收clearResponseOnEvent請求
3. 接收stopResponseOnEvent請求
4. 任何會話更改。

[SWS_Dcm_00907]若是EventWindowTime超時且電源循環未結束，則Dcm應發送對設置請求的最終確定響應。

對於EventWindowTime無限（0x02），ThisCycle（0x03），ThisAndNextCycle（0x04），Dcm將不會發送最終響應，由於這些EventWindow時間將在電源循環結束時結束。 若是會話更改或使用「 stopResponseOnEvent」子功能中止服務，也將沒有最終響應。