ResponseOnEvent的預配置
[SWS_Dcm_00908] DDcm僅支持在配置中預先配置的Roe請求。
注意：預先配置使Dcm可以自由地優化未配置的請求。
[SWS_Dcm_00909] DDcm支持配置容器DcmDspRoe來配置所有受支持的ResponseOnEvent設置請求。
[SWS_Dcm_00954]如果DcmDspRoeInitialEventStatus設置為
DCM_ROE_STOPPED Dcm的行為應類似於以下RoeEvent：將StorageState設置為“ StoreEvent”，將EvetenWindowTime設置為infinity。
根據SWS_Dcm_00954和SWS_Dcm_00897，RoeEvent的預配置應具有與在先前駕駛周期中收到的設置和啟動請求相同的行為。如果在start / stop / clearedResponseOnEventRequest中設置了storageState，則預配置將被新接收的請求替換。
事件觸發的處理
ROE事件觸發onDTCStatusChange（0x01）
如果RoeEvent處於“ ROE啟動”狀態，並且配置為onDTCStatusChange（請參見容器DcmDspRoeEvent），則Dcm在Dem報告適合於請求的DTCStatusMask的DTCStatusChange時立即觸發ServiceToResponseTo。根據SWS_Dcm_00909，Dcm僅支持預配置的ROE請求。因此容器如果應使用onDTCStatusChange，則需要配置DcmDspRoeOnDTCStatusChange。
[SWS_Dcm_00912]⌈如果一個RoeEvent的狀態配置為
Dcm應將onDTCStatusChange更改為“ ROE已啟動”
Dem_DcmControlDTCStatusChangedNotification（TRUE）觸發DTC狀態更改報告到Dcm.
[SWS_Dcm_00913]⌈如果RoeEvent的狀態，配置為
在OnDTCStatusChange上，Dcm將調用“ ROE啟動”
Dem_DcmControlDTCStatusChangedNotification（FALSE）停止觸發向Dcm的DTC狀態更改報告。
[SWS_Dcm_00914]⌈如果子函數OnDTCStatusChange的RoeEvent的狀態為“ ROE啟動”，則在調用Dcm_DemTriggerOnDTCStatus（）且DTCStatusNew適合於相應的DTCStatusMask的情況下，OnDTCStatusChange將觸發serviceToRespondTo。
[SWS_Dcm_00915]⌈如果DTCStatusNew適合相應的DTCStatusMask，則如果事件觸發了onDTCStatusChange，則Dcm將執行serviceToResponseTo 0x19 0x0E。
ROE事件觸發onChangeOfDataIdentifier（0x03）
如果RoeEvent處於“ ROE啟動”狀態，並且已配置為
onChangeOfDataIdentifier（請參見容器DcmDspRoeEvent），DSW在SWC或CDD報告DcmDspRoeDidRef引用的DID更改后立即觸發ServiceToResponseTo（SWC或CCD通過調用Dcm_TriggerOnEvent報告DID更改）。根據SWS_Dcm_00909，Dcm僅支持
預配置的ROE請求。因此，在onChangeOfDataIdentifier配置中，具有onChangeOfDataIdentifier的ROE設置請求中的Did必須鏈接為DcmDspRoeDidRef。
[SWS_Dcm_00918]⌈如果請求ResponseOnEvent為
onChangeOfDataIdentifier和所請求的Did未被稱為
對於任何DcmDspRoeEvent的DcmDspRoeDidRef，Dcm均應使用NRC 0x31 RequestOutOfRange。否定響應拒絕請求。
注意：Dcm不會直接通知SW-C有關激活
ResponseOnEvent。 SW-C必須監視相應的ModeDeclarationGroup DcmResponseOnEvent_ <RoeEventID>的更改並開始報告
如果模式為“ ROE已啟動”，則數據標識符將更改為Dcm
[SWS_Dcm_00920]⌈如果調用Dcm_TriggerOnEvent（）並且傳遞的RoeEvent處於活動狀態，則Dcm將為此RoeEvent觸發一個事件。
[SWS_Dcm_00921]⌈如果為onChangeOfDataIdentifier觸發了事件，則Dcm必須使用為此引用的Did執行serviceToResponseTo 0x22。RoeEvent（DcmDspRoeDidRef）
觸發ServiceToRespondTo
[SWS_Dcm_00922]如果由RoeEvent觸發了ServiceToRespondTo，則Dcm應將ServiceToRespondTo作為正常的診斷服務執行。
[SWS_Dcm_00558]如果在Dcm已經在其他診斷協議上執行請求時觸發了ServiceToRespondTo，則Dcm應將ServiceToRespondTo推遲到服務執行完成為止。
[SWS_Dcm_00923] DDcm僅處理最后一個ServiceToRespondTo。如果已經由於另一個服務執行而將ServiceToRespondTo推遲，則新的響應將覆蓋先前的觸發器。
[SWS_Dcm_00924]如果在接收到有關其他診斷協議的請求的同時執行ServiceToRespondTo，則ServiceToRespondTo將被取消。
[SWS_Dcm_00925]如果在RoeEvent更改為“ ROE已清除”狀態或“ ROE已停止”狀態時ServiceToRespondTo處於掛起狀態，則將刪除掛起的RoeEvent。
[SWS_Dcm_00127]如果通過子服務StartResponseOnEvent接收到UDS服務ResponseOnEvent（0x86），則DSP子模塊將為所有RoeEvent存儲接收到的RxPduId的各自已配置的sourceAddress，該事件將被啟動，直到eventWindowTime超時為止。
[SWS_Dcm_00128] DSPDSP子模塊必須將此存儲的sourceAddress作為參數轉發給slInternal_ResponseOnOneEvent（）函數中的參數，該函數用於觸發serviceToRespondTo
注意：如果將serviceToResponseTo發送到相同或不同的TxPduId，則Dcm會存儲接收ROE請求的協議的sourceAddress。 sourceAddress鏈接始終始終是正確的TxPduId，因為ServiceToRespondTo只有一個TxPduId鏈接到一個協議（請參見ConfigurationParameter DcmDslROEConnectionRef）。如果RoeEvents在重啟后處於活動狀態，則sourceAddress需要在重啟后進行存儲。
發送ServiceToRespondTo
Dcm支持在相同的TxPduId上從ServiceToResponseTo進行傳輸，就像發送ROE響應（TYPE 1）或在不同的TxPduId（TYPE2）。
[SWS_Dcm_00131]⌈配置的協議緩沖區應用於ROE消息的傳輸（由於接收應使用單獨的協議，因此需要使用單獨的緩沖區進行接收）。
[SWS_Dcm_00926]⌈如果在協議上收到ROE請求DcmDslMainConnection，Dcm應在稱為DcmDslROEConnectionRef的協議上發送ServiceToRespondTo。
注意：如果EventWindowTime的激活時間超過了此電源循環的時間，則Dcm必須在事件開始的地方存儲協議。[SWS_Dcm_00927]⌈如果為TYPE1配置了所引用的ResponseOnEvent協議（DcmDslROEConnectionRef），則Dcm必須發送ServiceToRespondTo發送到ROE響應的TxPduID相同。
[SWS_Dcm_00928]⌈如果引用的協議用於ResponseOnEvent（DcmDslROEConnectionRef）已配置為TYPE2，Dcm應將ServiceToRespondTo發送到已配置的TxPduID（請參閱配置參數DcmDslRoeTxPduRef）。
[SWS_Dcm_00132] p必須將pMsgContext指針（ROE消息）的內容復制到緩沖區中。
[SWS_Dcm_00133]⌈ROE通信只能在完全通信模式下執行。 Dcm應檢查DcmDslMainConnection中的DcmDslProtocolComMChannelRef的通信模式。
[SWS_Dcm_00134]⌈ROE事件應在除完全通信模式之外的任何其他通信模式中禁用。
[SWS_Dcm_00135] in在不同於完全通信模式的通信模式下發生的ROE事件應被丟棄，並且不排隊等待以后的傳輸。
[SWS_Dcm_00136] the應用程序請求的ROE事件不應激活完全通信模式。
[constr_6025]引用DcmDslResponseOnEvent連接⌈只有一個DcmDslROEConnectionRef可以引用DcmDslResponseOnEvent連接。
ROE傳輸周期
[SWS_Dcm_00601]⌈DCM模塊應遵守兩（2）次連續Roe傳輸之間的最短時間（請參見配置參數DcmDspRoeInterMessageTime）
在多個客戶端環境中的ResponseOnEvent
[SWS_Dcm_00929]⌈如果至少一個RoeEvent處於“ ROE啟動”狀態，則Dcm應始終使用子功能clearResponseOnEvent處理ROE請求，而與接收請求的DcmDslProtocol無關。
[SWS_Dcm_00930]⌈如果至少一個RoeEvent處於“ ROE啟動”狀態，則Dcm應始終使用子功能stopResponseOnEvent處理ROE請求，而與接收請求的DcmDslProtocol無關。
[SWS_Dcm_00940]⌈如果至少一個RoeEvent處於“ ROE已啟動”狀態，則Dcm將拒絕在與使用NRC 0x22（條件未正確）啟動RoeEvent的協議不同的DcmDslProtocol上收到的所有ROE請求，除了SWS_Dcm_00929和SWS_Dcm_00930。
[SWS_Dcm_01045]⌈僅TYPE2消息將支持並行執行診斷響應。
支持分段響應（分頁緩沖區）
[SWS_Dcm_00028]如果啟用（DcmPagedBufferEnabled = TRUE），則DCM模塊應提供一種機制，以發送大於已配置和分配的診斷緩沖區的響應。⌋（BSW04017）
[SWS_Dcm_01058]如果DcmPagedBufferEnabled == TRUE並且為請求生成的響應長於DcmDslProtocolMaximumResponseSize，則Dcm應以NRC 0x14（DCM_E_RESPONSETOOLONG）進行響應。
[SWS_Dcm_01059]如果DcmPagedBufferEnabled == FALSE並且為請求生成的響應長於Dcm_MsgContextType結構元素resMaxDataLen，則Dcm應以NRC 0x14（DCM_E_RESPONSETOOLONG）進行響應。使用分頁緩沖區處理時，ECU不會被迫提供與最大響應長度一樣大的緩沖區。
請注意：
- 分頁緩沖區處理僅用於發送-不支持接收。
- 分頁緩沖區處理不適用於該應用程序（僅DCM內部使用）。
支持ResponsePending觸發的響應
應用在某些情況下，例如在例行執行的情況下，應用程序需要立即請求NRC 0x78（等待響應），該請求應立即發送，而不是在到達響應時間之前發送（P2ServerMax或P2 * ServerMax）。
DCM模塊調用操作並獲得錯誤狀態時DCM_E_FORCE_RCRRP，DSL子模塊將使用NRC 0x78（響應待處理）觸發否定響應的傳輸。此響應需要從單獨的緩沖區發送，以避免覆蓋正在進行的請求處理。
管理安全級別
[SWS_Dcm_00020]⌈DSL子模塊應保存當前活動安全級別的級別。⌋（BSW04005）
為了訪問此級別，DSL子模塊提供以下接口：
-獲取當前的活動安全級別：Dcm_GetSecurityLevel（）
-設置新的安全級別：DslInternal_SetSecurityLevel（）
[SWS_Dcm_00033]⌈在DCM初始化期間，安全級別被設置為值0x00（DCM_SEC_LEV_LOCKED）。（BSW101）通過SWS_Dcm_00033，ECU被鎖定。
[SWS_Dcm_00139]在以下情況之一下，DSL必須將安全級別重置為值0x00（即，啟用了安全性）：
-如果執行從defaultSession以外的任何診斷會話到defaultSession以外的其他會話（包括當前活動的診斷會話）的轉換，或
-如果執行從defaultSession以外的任何診斷會話到defaultSession（DslInternal_SetSecurityLevel（））的轉換（由UDS服務DiagnosticSessionControl（0x10）或S3Server超時啟動）。⌋（）一次只能激活一個安全級別。
管理會話狀態
[SWS_Dcm_00022] DSL子模塊應保存當前活動會話的狀態。⌋（BSW04006）
為了訪問此變量，DSL子模塊提供以下接口：
- 獲取當前活動會話：Dcm_GetSesCtrlType（）
- 設置一個新會話：DslInternal_SetSesCtrlType（）
[SWS_Dcm_00034]在DCM初始化期間，會話狀態設置為值0x01（“ DefaultSession”）。⌋（BSW101）
[SWS_Dcm_01062]對Dcm_ResetToDefaultSession（）的調用允許應用程序將當前會話重置為默認會話，並通過調用來調用ModeDeclarationGroupPrototype DcmDiagnosticSessionControl的模式開關。
SchM_Switch_ <bsnp> _DcmDiagnosticSessionControl（RTE_MODE_DcmDiagnostic SessionControl_DEFAULT_SESSION）.
示例：超過速度限制時自動終止擴展診斷會話。
跟蹤活動的非默認會話
[SWS_Dcm_00140]每當非默認會話處於活動狀態並且達到會話超時（S3Server）而沒有收到任何診斷請求時，DSL子模塊均應重置為默認會話狀態（“ DefaultSession”，0x01）並調用模式切換的ModeDeclarationGroupPrototype
通過調用SchM_Switch_ <bsnp> _DcmDiagnosticSessionControl（RTE_MODE_DcmDiagnostic SessionControl_DEFAULT_SESSION）進行DcmDiagnosticSessionControl。
注意：<bsnp>是BSW Scheduler名稱前綴
根據下表，處理S3Server超時計時器的啟動/停止：
[SWS_Dcm_00141]⌈
| 子請求開始 | 完成任何最終響應消息或錯誤指示（Dcm_TpTxConfirmation（）：確認完整的PDU或錯誤指示） |
| 子請求開始 | 如果沒有響應消息，則完成請求的操作（正面和負面）是必需的/允許的。 |
| 子請求開始 | 指示在接收多幀請求消息期間發生錯誤。（Dcm_TpRxIndication（）：錯誤指示） |
| 子請求停止 | 多幀請求消息的開始（Dcm_StartOfReception（）：指示PDU接收開始） |
| 子請求停止 | 接收單幀請求消息。（Dcm_StartOfReception（）：指示PDU接收開始） |
“S3Server的啟動”是指重置計時器並從頭開始計數
允許修改計時
[SWS_Dcm_00027]⌈DCM模塊應按照[18]處理以下協議定時參數：P2ServerMin，P2ServerMax，P2 * ServerMin，P2 * ServerMax，S3Server⌋（BSW04015）[SWS_Dcm_00143]⌈P2min / P2 * min和S3Server設置為以下定義的值：P2min = 0ms，P2 * min = 0ms，S3Server = 5s。（BSW04015）這些協議定時參數對會話層定時有影響（對傳輸層定時無影響）。在協議處於活動狀態時，可以使用以下方法修改其中一些時序參數：
- UDS服務DiagnosticSessionControl（0x10）
- UDS服務AccessTimingParameter（0x83）
DSL子模塊提供以下功能來修改定時參數：
- 提供有效的計時參數，
- 設置新的計時參數。僅在發送響應后才允許激活新的計時值。
處理不同的診斷協議
有必要區分不同的診斷方案（例如OBD，增強型診斷...）。
不同的服務表
對於不同的協議，一組不同的允許的診斷服務有效（例如，用於增強診斷的UDS命令，用於OBD協議的OBD模式服務）。可以創建不同的服務表並將它們鏈接到診斷協議。
[SWS_Dcm_00035]⌈每次協議初始化時，DSL子模塊都會設置到相應服務表的鏈接（請參閱配置參數DcmDslProtocolSIDTable）（BSW101）
DSD子模塊使用此鏈接來進一步處理診斷請求。
協議優先級
通過配置參數DcmDslProtocolPriority，可以為每個協議賦予其自己的相對優先級。
可能的用例：有些ECU與車輛內部診斷測試儀（通過增強診斷運行）和車輛外部OBD測試儀通信。
OBD通信必須具有比增強診斷更高的優先級。
[SWS_Dcm_00015] allowed允許具有更高優先級的協議優先於已運行的協議（BSW04021）
由於不同的DcmRxPduId值（根據協議配置，請參閱配置參數），可以區分診斷協議
協議配置中引用的DcmDslProtocolRxPduRef）。
協議搶占
[SWS_Dcm_00459]⌈如果正在運行的診斷請求被（其他協議的）更高優先級的請求搶占，則DSL子模塊應調用所有已配置的Xxx_StopProtocol（）函數（請參閱配置參數DcmDslCallbackDCMRequestService）。
[SWS_Dcm_01144]⌈無法使用更高優先級協議的並發TesterPresent激活協議搶占（另請參見[SWS_Dcm_01146]）。
[SWS_Dcm_00079]⌈為了取消與較低優先級請求相關的較低層中的掛起傳輸，DCM模塊應使用以下參數調用PduR_DcmCancelTransmit（）：
PduId：要取消的Pdu的ID⌋（）
[SWS_Dcm_00460] P當PduR_DcmCancelTransmit（）返回E_NOT_OK時，DCM模塊應假定正在進行的傳輸無法取消，並且不得重試取消傳輸請求。當前協議應停止並開始新協議。
[SWS_Dcm_01046]⌈如果正在運行的診斷請求被（其他協議的）更高優先級的請求所搶占，則DCM必須取消Dcm_OpStatus設置為DCM_CANCEL⌋（）的所有外部掛起操作。
[SWS_Dcm_01047]⌈如果對Dem的操作未決並且新請求也需要與Dem進行交互，則Dcm應接受新請求並使用新請求中的參數調用相應的Dem API。
[SWS_Dcm_00575]⌈為了取消與較低優先級請求相關的較低層中的掛起接收，DCM模塊應使用以下參數調用PduR_DcmCancelReceive（）：
PduId：要取消的Pdu的ID⌋（）[SWS_Dcm_00576] P當PduR_DcmCancelReceive（）返回E_NOT_OK時，DCM模塊應假定正在進行的接收無法被取消，並且不應重試取消接收者的請求。應停止當前協議，並啟動新協議。
[SWS_Dcm_00625] request如果此優先級較高的協議處於默認會話中且未處於活動狀態，則低優先級或相同優先級的請求可以搶占該優先級較高的協議。
請求處於執行階段。在這種情況下，DSL子模塊應調用所有已配置的Xxx_StopProtocol（）函數（請參閱配置參數DcmDslCallbackDCMRequestService）。
[SWS_Dcm_00728] shall具有相同優先級的協議應該可以處理。
[SWS_Dcm_00727]⌈如果診斷請求已在運行，並且無法處理第二個請求（ClientB）（例如，由於優先級評估），則響應行為取決於配置選項參數DcmDslDiagRespOnSecondDeclinedRequest（請參見SWS_Dcm_00914_Conf）。如果此配置參數為TRUE，則響應為NRC 0x21（BusyRepeatRequest）將針對第二個請求發出（請參見[SWS_Dcm_00788和[SWS_Dcm_00789）。如果配置參數為FALSE，則不會發出任何響應，請參見[SWS_Dcm_00790]。
[SWS_Dcm_00729]⌈如果多個具有不同PduID的客戶端正在請求同一協議，則由於同一協議的所有連接都具有相同的優先級，因此不會處理第二個請求（具有不同的RxPduId）。如果配置參數DcmDslDiagRespOnSecondDeclinedRequest為TRUE，則將為第二個請求發出NRC 0x21（BusyRepeatRequest）的否定響應。如果配置參數為FALSE，則不會發出任何響應。
[SWS_Dcm_01050]⌈如果診斷並行請求的優先級與活動請求相同/較低，則不得調用ComM API（ComM_DCM_ActiveDiagnostic，ComM_DCM_InactiveDiagnostic）。
協議啟動檢測
[SWS_Dcm_00036]⌈在診斷協議的第一個請求下，DSL子模塊應調用所有已配置的Xxx_StartProtocol（）函數（請參閱配置參數DcmDslCallbackDCMRequestService）。（BSW101）在此函數中，應用程序可以檢查環境條件並進一步啟用/禁用協議的處理。
[SWS_Dcm_00144] all在所有Xxx_StartProtocol（）函數都返回E_OK（意味着所有組件都已允許啟動協議）之后，將從默認會話配置中加載默認計時參數（請參閱配置參數DcmDspSessionRow）。 ⌋（BSW04015）
[SWS_Dcm_00145] all在所有Xxx_StartProtocol（）函數都返回E_OK（意味着所有組件都允許啟動協議）之后，將設置服務表（請參閱配置參數DcmDslProtocolSIDTable）。[SWS_Dcm_00146] all在所有Xxx_StartProtocol（）之后函數已返回E_OK（表示所有組件均已允許啟動協議），安全性狀態被重置。
[SWS_Dcm_00147]⌈所有Xxx_StartProtocol（）函數都返回E_OK（意味着所有組件都已允許啟動協議）之后，會話狀態將重置為默認會話。 此外，DCM模塊應調用ModeDeclarationGroupPrototype DcmDiagnosticSessionControl的模式開關
通過調用SchM_Switch_ <bsnp> _DcmDiagnosticSessionControl（RTE_MODE_DcmDiagnostic SessionControl_DEFAULT_SESSION）.
注意：<bsnp>是BSW Scheduler名稱前綴
協議停止
僅在協議搶占的情況下才會出現協議停止（請參見“協議搶占”）[SWS_Dcm_00624]⌈連接了Dcm_TpTxConfirmation（）的接收
對於DSL子模塊給出的響應，DCM不應停止當前協議（不調用xxx_StopProtocol）。
注意：協議（例如OBD）將一直處於活動狀態，直到重置或其他協議被搶占為止。
管理資源
由於資源有限，以下幾點應被視為有關
設計：
- 只能在DCM模塊中使用和分配一個診斷緩沖區。 然后，該緩沖區用於處理診斷請求和響應。
- NRC 0x78（待處理的響應）響應的輸出是單獨進行的緩沖。
- 分頁緩沖區處理（請參閱SWS_Dcm_00028）
通訊模式處理
通信模式處理是Dcm和ComM之間的接口。 ComM通知Dcm有關通道的當前免疫狀態。 Dcm正在調用有關活動診斷的ComM，這將阻止Ecu關機/睡眠。
狀態ActiveDiagnostic顯示診斷請求是否應使ECU保持喚醒狀態（ActiveDiagnostic ==“ DCM_COMM_ACTIVE”），或者診斷請求是否應阻止Ecu關機/睡眠（ActiveDiagnostic ==“ DCM_COMM_NOT_ACTIVE”）。
應用程序可以根據系統狀況更改狀態ActiveDiagnostic。
[constr_6027]⌈應用程序將通過調用來通知Dcm有關ActiveDiagnostic狀態的Xxx_SetActiveDiagnostic（）。
[SWS_Dcm_01069]⌈Dcm_Init（）之后，Dcm應將ActiveDiagnostic設置為“ DCM_COMM_ACTIVE”。
[SWS_Dcm_01070]⌈如果使用“ false”調用Xxx_SetActiveDiagnostic（），則Dcm將ActiveDiagnostic設置為“ DCM_COMM_NOT_ACTIVE”。
[SWS_Dcm_01071]⌈如果使用“ true”調用Xxx_SetActiveDiagnostic（），則Dcm將ActiveDiagnostic設置為“ DCM_COMM_ACTIVE”。
無通訊no Communication
ComM模塊將通過調用Dcm_ComM_NoComModeEntered（）向DCM模塊指示“無通信模式”。作為響應，DCM將立即禁用所有傳輸（有關詳細信息，請參見Dcm_ComM_NoComModeEntered（）的定義）。
靜默溝通Silent Communication
ComM模塊將通過調用Dcm_ComM_SilentComModeEntered（）向DCM模塊指示靜默通信模式。作為響應，DCM將立即禁用所有傳輸（有關詳細信息，請參見Dcm_ComM_SilentComModeEntered（）的定義）。
全面溝通Full Communication
ComM模塊將向DCM模塊指示完全通信模式，通過調用Dcm_ComM_FullComModeEntered（）。 作為響應，DCM將啟用所有傳輸（有關詳細信息，請參見cm_ComM_FullComModeEntered（）的定義）
默認會話Default Session
[SWS_Dcm_00163]⌈如果ActiveDiagnostic為'DCM_COMM_ACTIVE'並且Dcm處於診斷協議的默認會話中，則DCM應通過每個請求調用ComM_DCM_ActiveDiagnostic（NetworkId），並將networkId與接收到的Pdu關聯（請參閱DcmDslProtocolComMChannelRef），以通知關於需要保持在完全通信模式下的ComM模塊。⌋（）[SWS_Dcm_00164]⌈接收到Dcm_TpTxConfirmation（）並連接到DSL子模塊給出的響應后，DCM將調用ComM_DCM_InactiveDiagnostic（NetworkId），並將networkId與傳輸的Pdu（請參閱DcmDslProtocolComMChannelRef），以通知ComM
不再需要完全通訊的模塊.
[SWS_Dcm_01142]⌈Dcm必須等待來自ComM的完全通信模式指示（調用Dcm_ComM_FullComModeEntered（）），然后再啟動診斷答案的傳輸。等待時間應不大於從收到請求的那一刻起計算的P2ServerMax。
[SWS_Dcm_01143]⌈如果Dcm需要確認待傳輸的響應（DCM_E_FORCE_RCRRP），則Dcm應觸發DET錯誤DCM_E_FORCE_RCRRP_IN_SILENT_COMM.⌋
注意：在接收端，如果進行分段傳輸，則靜默通信模式可能會導致請求丟失。
[SWS_Dcm_00165]⌈DCM不應調用NRC 0x78的ComM_DCM_InactiveDiagnostic（NetworkId）（響應待審核）。 DCM僅應調用ComM_DCM_InactiveDiagnostic（NetworkId），最后一個響應（肯定或否定）已連接到請求。
[SWS_Dcm_00697]⌈如果在功能尋址的情況下抑制了否定響應（請參見SWS_Dcm_00001），則DCM應調用
ComM_DCM_InactiveDiagnostic（NetworkId）.
會話過渡Session Transitions
[SWS_Dcm_00167]⌈如果ActiveDiagnostic為“ DCM_COMM_ACTIVE”，並且實際診斷會話更改為與默認會話不同的會話（由UDS服務DiagnosticSessionControl發起），則Dcm應調用
ComM_DCM_ActiveDiagnostic（NetworkId），以及與接收到的Pdu關聯的NetworkId，以通知ComM模塊需要保持在完全通信模式下的信息。
注意：ComM_DCM_InactiveDiagnostic（NetworkId）的調用是
[SWS_Dcm_00168]⌈如果實際診斷會話已從會話更改，則獨立於ActiveDiagnostic。
與默認會話（由UDS服務DiagnosticSessionControl或S3Server超時或協議搶占發起）不同，則DCM應使用以下命令調用ComM_DCM_InactiveDiagnostic（NetworkId）：
與接收到的Pdu關聯的networkId，以通知ComM模塊不再需要完全通信.
非默認會話Non Default Session:
[SWS_Dcm_00169]⌈只要服務器處於默認會話以外的會話中，則當從客戶端接收到請求時，DCM不應使用與接收到的Pdu相關的networkId來調用ComM_DCM_ActiveDiagnostic（NetworkId）。
[SWS_Dcm_00170] as只要服務器處於默認會話以外的會話中，則DCM均不得在接收時將調用與接收到的Pdu相關聯的networkId的ComM_DCM_InactiveDiagnostic（NetworkId）。 Dcm_TpTxConfirmation（）連接到DSL子模塊給定的響應。