AUTOSAR_SWS_DiagnosticCommunicationManager-2

目錄

• 7 Functional specification
  • 7.3 Diagnostic Session Layer (DSL)
    • 7.3.1 Introduction
    • 7.3.2 Use cases
    • 7.3.3 Interaction with other modules
    • 7.3.4 Functional description
      • 7.3.4.1 Overview
      • 7.3.4.2 Forward requests from the PduR module to the DSD submodule
        • 7.3.4.2.1 Dcm_StartOfReception
        • 7.3.4.2.2 Dcm_CopyRxData
        • 7.3.4.2.3 Dcm_TpRxIndication
      • 7.3.4.3 Concurrent ”TesterPresent” (”keep alive logic”)
        • 7.3.4.3.1 Dcm_CopyTxData

7 Functional specification

7.3 Diagnostic Session Layer (DSL)

7.3.1 Introduction

DSL模組的功能詳細參考ISO14229-1 [2]和ISO15765-3 [4]。

7.3.2 Use cases

略

7.3.3 Interaction with other modules

與DSL子模組互動的模組有以下幾個：

PduR 模組

PduR為DSL提供診斷請求的資料。

在診斷請求的響應準備好後，將由DSL觸發PduR傳送診斷響應。

DSD 子模組

將PduR提供的診斷請求的資料轉發給DSD。

在診斷請求的響應準備好後，將由DSD通知DSL傳送診斷響應。

SW-Cs / DSP 子模組

DSL提供安全和會話狀態的訪問通道。

ComM 模組

DSL透過ComM管理診斷的通訊狀態等。

7.3.4 Functional description

7.3.4.1 Overview

DSL模組提供的功能有以下幾個：

請求處理：

轉發請求: 從PduR接收診斷請求並轉發至DSD。

併發"TesterPresent": 保持會話活躍（Keep-Alive Logic）。

響應處理

轉發響應:將 DSD生成的診斷響應轉發至PduR。

響應時序保證: 確保響應時序。

週期性傳輸支援: 支援定期資料傳輸機制。

事件觸發響應支援: 實現ResponseOnEvent (ROE) 資料傳輸。

分段響應支援: 分段響應。

應用觸發響應掛起: 支援Application觸發的ResponsePending響應。

安全級別管理：

安全管理: 控制並維護診斷安全等級。

會話狀態管理：

會話狀態控制: 管理會話開啟、關閉等狀態。

非預設會話追蹤: 記錄並管理非預設會話狀態。

時序調整: 允許修改會話相關的定時引數。

診斷協議處理：

協議處理: 支援多種診斷協議的解析與處理。

資源管理: 合理調配診斷過程中所需資源。

通訊模式管理：

模式切換: 控制全通訊/靜默通訊/無通訊模式(Full- / Silent- / No Communication)。

診斷狀態指示: 標記診斷活動或非活動狀態。

傳輸控制: 啟用或禁用所有診斷資料傳輸功能。

7.3.4.2 Forward requests from the PduR module to the DSD submodule

graph TD Start(PDUR接收到診斷請求<br>DcmRxPduId收到請求內容) SecondRequestCheck1{當前有無請求處理?} SecondRequestCheck2{DcmDslDiagRespOnSecondDeclinedRequest==Ture?} ConnectionCheck{新請求使用了不同的DcmDslConnection?<br>且新的請求的優先度與當前處理請求相同或者更低<br>且處於非預設會話狀態} DcmStart(PDUR呼叫Dcm_StartOfReception<br>引數包含需要Dcm接收的Sdu資料長度以及首幀或者單幀資料) Check{Check緩衝區大小和服務可用性?} Reject(拒絕接收請求) Copy(PDUR呼叫Dcm_CopyRxData<br>將資料複製進DCM的緩衝區) Finish(PDUR呼叫Dcm_TpRxIndication<br>通知DCM接收已完成) Store(DCM儲存PDU定址資訊) DSD(轉發至DSD, 同時DcmPduId被鎖定<br>相同的DcmDslConnection的後續請求不會被接受<br>併發的TesterPresent requests-0x78除外) Address(用於後續響應時準確傳送到對應的請求地址<br>同時追蹤同一地址的後續請求) Release(PDUR呼叫Dcm_TpTxConfirmation) BufferOverflow(緩衝區溢位) Start --> DcmStart DcmStart -->SecondRequestCheck1 SecondRequestCheck1 --> |當前沒有其他請求在處理| Check SecondRequestCheck1 --> |當前有其他請求在處理| ConnectionCheck ConnectionCheck --> |使用了不同的通道|SecondRequestCheck2 ConnectionCheck --> |使用了相同的通道| y(Dcm_StartOfReception<br>返回BUFREQ_E_NOT_OK) SecondRequestCheck2 --> |判斷成立<br>Dcm_StartOfReception<br>返回BUFREQ_OK| x(由於當前有請求正在處理<br>這裡DCM會回覆響應: NRC 0x21) SecondRequestCheck2 --> |判斷不成立<br>Dcm_StartOfReception<br>返回BUFREQ_E_NOT_OK| z(拒絕接受請求) Check --> |緩衝區足夠且服務可用<br>Dcm_StartOfReception<br>返回BUFREQ_OK| Copy Check --> |Dcm_StartOfReception<br>返回BUFREQ_E_OVFL| BufferOverflow BufferOverflow --> Reject Check --> |服務不可用| Reject Check --> |緩衝區足夠且服務可用<br>Dcm_StartOfReception<br>返回BUFREQ_OK| Store Store --> Address Copy --> Finish Finish -->|Dcm_TpRxIndication<br>引數Result = E_OK| DSD DSD -->|響應傳送成功| Release Release -->|Dcm_TpTxConfirmation<br>引數Result = E_OK| END(DcmPduId被釋放)

※Note：

新請求的優先度更高時，是否會直接直接搶佔？

以下是診斷通訊用到的幾種PDU (DcmDslConnection配置相關?)：

OBD DcmRxPduId

OBD DcmTxPduId

UDS phys DcmRxPduId

UDS func DcmRxPduId

UDS DcmTxPduId

透過配置DcmDslProtocolRx容器中的DcmDslProtocolRxAddrType為DCM_FUNCTIONAL_TYPE或者DCM_PHYSICAL_TYPE，
並且每個通道分配適當的DcmDslProtocolRxPduId，就可以實現物理定址和功能定址的設定。

7.3.4.2.1 Dcm_StartOfReception

參照流程圖

※Note1：

當有請求在處理中時，如果收到了來自外部的TesterPresent診斷請求，無論與正在處理的請求是否源自同一通道，都會被接受(Dcm_StartOfReception返回BUFREQ_OK)，但是都不會進行處理(即：不進行S3Server timer的重製)。

※Note2：

Dcm_StartOfReception()可以在中斷中呼叫。

※Note3：

Dcm_StartOfReception()的引數 TpSduLength等於0，函式也會返回BUFREQ_E_NOT_OK，不會再進行下一步的處理。

7.3.4.2.2 Dcm_CopyRxData

※Note1：

當Dcm_CopyRxData被呼叫且引數SduLength為0時，函式也會返回BUFREQ_OK，並且透過bufferSizePtr返回當前Dcm的接收緩衝區的剩餘大小==

根據前面的Dcm_StartOfReception的說明，當該函式的引數TpSduLength等於0時，會返回BUFREQ_E_NOT_OK，並且不會進行進一步的處理，這是否意味著當TpSduLength等於0這種情況發生時，根本不存在進行下一步的Dcm_CopyRxData呼叫？

猜測：Dcm_CopyRxData可能不僅在接受請求資料時呼叫，或者是為了保證Dcm_CopyRxData函式的相容性。

※Note2：

在Dcm_StartOfReception取得Dcm接收緩衝區指標到Dcm_TpRxIndication 被呼叫的時間內，是資料複製階段，這段時間內，Dcm模組不能訪問Dcm緩衝區。

※Note3：

Dcm_CopyRxData可以在中斷中呼叫。

7.3.4.2.3 Dcm_TpRxIndication

※Note1：

當Dcm_TpRxIndication被呼叫且引數Std_ReturnType result不是E_OK時，Dcm模組將不對接收該PduIdType id資料的緩衝區域進行進一步的評估(如計算剩餘size等)，因為接收的資料無法確認是有效還是無效的，防止引發其他錯誤。

※Note2：

在Dcm_StartOfReception取得Dcm接收緩衝區指標到Dcm_TpRxIndication 被呼叫的時間內，是資料複製階段，這段時間內，Dcm模組不能訪問Dcm緩衝區。

※Note3：

Dcm_TpRxIndication可以在中斷中呼叫

7.3.4.3 Concurrent ”TesterPresent” (”keep alive logic”)

graph TD A[PduR呼叫Dcm_TpRxIndication<br>引數Result=E_OK] --> B{是否為TesterPresent請求?} B -- 不是 --> C[轉發到DSD做進一步處理] B -- 是 --> D{suppressPosRspMsgIndicationBit==TRUE?} D -- 不是 --> C[轉發到DSD做進一步處理] D -- 是 --> E[重置S3Server會話計時器] E --> F[不轉發到DSD模]

※Note1：

不同於前面的正常的診斷請求的接收流程，對於服務SID 0x3E的keep-alive logic請求使用獨立的DcmRxPduId，並且緩衝區也由Dcm模組內部直接給定，不需要顯式的配置。

※Note2：

該服務的DcmRxPduId(UDS func DcmRxPduId)也屬於物理定址的DcmDslConnection，也正因為有獨立的處理過程，所以對於積極響應抑制位為TRUE的情況，不影響其他的物理定址請求。

7.3.4.3.1 Dcm_CopyTxData

※Note1：
:如果 PduR_DcmTransmit()中請求傳送的資料長度大於已經被Dcm_CopyTxData複製到傳送緩衝區的資料長度，那麼說明傳送緩衝區的長度不足以容納請求的資料，在當前傳送緩衝區的資料傳送成功後，PDUR會繼續呼叫Dcm_CopyTxData複製後續資料。