簡介
[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結束：
- 關機后再開機
- 接收clearResponseOnEvent請求
- 接收stopResponseOnEvent請求
- 任何會話更改。
[SWS_Dcm_00907]如果EventWindowTime超時且電源循環未結束，則Dcm應發送對設置請求的最終肯定響應。
對於EventWindowTime無限（0x02），ThisCycle（0x03），ThisAndNextCycle（0x04），Dcm將不會發送最終響應，因為這些EventWindow時間將在電源循環結束時結束。 如果會話更改或使用“ stopResponseOnEvent”子功能停止服務，也將沒有最終響應。