DCM模块中服务0x22读取数据时为何返回NRC 0x31？

Question

在DCM模块中，服务0x22（ReadDataByIdentifier）执行时返回NRC 0x31（RequestOutOfRange），通常表明请求的数据标识符（DID）虽存在但当前不满足读取条件。常见原因包括：① DID所关联的数据在当前诊断会话（如默认会话）中被禁止访问，需先进入扩展会话或编程会话；② 相关ECU状态不满足前提条件（如发动机未运行、高压未就绪、安全访问未通过）；③ DID虽定义但未在当前配置/编译条件下使能（如条件编译宏未启用或RTE未映射）；④ DCM配置中该DID的访问权限（AccessLevel/SessionMask）设置错误，导致会话级校验失败。值得注意的是，NRC 0x31 ≠ 0x33（SecurityAccessDenied），它不涉及安全等级，而是明确指向“请求超出当前上下文允许范围”。建议结合DCM日志、会话状态、安全状态及DID配置三者交叉验证，优先检查`Dcm_Dsp_ReadDataByIdentifier()`中`Dcm_Prv_CheckDIDAvailability()`和会话掩码匹配逻辑。

Answer 1

```html

一、现象定位：NRC 0x31 的语义解码与典型触发场景

NRC 0x31（RequestOutOfRange）在UDS协议ISO 14229-1中明确定义为“请求的数据标识符在当前诊断上下文中不可用”，而非不存在或未授权。它不涉及安全等级校验（≠ NRC 0x33），而是严格反映上下文约束失效——即DID已注册、内存可寻址，但因会话、状态、配置等维度限制被主动拒绝。常见触发链路如下：

• 默认会话（Session 0x01）下尝试读取仅允许扩展会话（0x03）访问的DID（如0xF190）
• 高压电池ECU在DCM_Dsp_ReadDataByIdentifier()中调用Dcm_Prv_CheckDIDAvailability()时，检测到BSW_HV_State != HV_READY
• RTE未生成对应Rte_Read_Dcm_DID_XXXX()接口，导致DID处理函数返回DCM_E_PENDING后超时转为0x31

二、分层排查路径：从运行时行为到静态配置

遵循“由外而内、由实入虚”原则，构建四层验证矩阵：

层级	验证目标	关键检查项	工具/方法
① 运行时上下文	当前诊断会话与安全状态	Dcm_DslGetActiveSession()返回值；Dcm_DslGetSecurityLevel()是否≥DID要求等级	Debugger断点+Trace32日志
② DID可用性逻辑	Dcm_Prv_CheckDIDAvailability()执行路径	会话掩码SessionMask按位与校验；Dcm_DspCheckDIDPreconditions()返回值	Source code review + GDB step-in

三、核心代码分析：Dcm_Prv_CheckDIDAvailability() 执行流

该函数是NRC 0x31生成的关键决策点，其逻辑伪代码如下：

Std_ReturnType Dcm_Prv_CheckDIDAvailability(Dcm_DIDType DidIdentifier) {
  const Dcm_DspDidConfigType* didConfig = Dcm_GetDidConfigPtr(DidIdentifier);
  if (NULL_PTR == didConfig) { return E_NOT_OK; } // → NRC 0x12, not 0x31
  
  // Step 1: SessionMask check (bitwise AND)
  if ((didConfig->SessionMask & Dcm_DslGetActiveSession()) == 0U) {
    return E_NOT_OK; // → Triggers NRC 0x31 at upper layer
  }
  
  // Step 2: Precondition callback (e.g., engine running check)
  if (didConfig->PreconditionFunc != NULL_PTR) {
    if (E_OK != didConfig->PreconditionFunc()) {
      return E_NOT_OK; // → Also leads to 0x31
    }
  }
  return E_OK;
}

四、配置级根因：DCM配置参数与编译条件联动

DID使能受双重控制：静态配置与条件编译宏。典型冲突案例：

• DcmDspDid_0xF180.SessionMask = 0x04（仅允许编程会话），但实际使用默认会话
• #if defined(DCM_ENABLE_DID_F190)未定义，导致Dcm_DspDidConfig[]数组中该DID条目被编译器剔除
• AUTOSAR RTE配置中Dcm_DID_0xF1A0未勾选Enable Read Access，RTE生成器跳过接口声明

五、诊断日志驱动的交叉验证法

启用DCM全量日志（DCM_LOG_LEVEL = DCM_LOG_DEBUG）后，关键日志序列示例：

[DCM] Dcm_Dsp_ReadDataByIdentifier: DID=0xF190, Session=0x01
[DCM] Dcm_Prv_CheckDIDAvailability: SessionMask=0x0C, Active=0x01 → (0x0C & 0x01)==0 → FALSE
[DCM] Dcm_Dsp_ReadDataByIdentifier: DID 0xF190 unavailable → NRC 0x31

此日志直接暴露会话掩码不匹配，无需逆向工程即可定位配置错误。

六、Mermaid流程图：NRC 0x31生成决策树

flowchart TD
    A[收到0x22请求] --> B{DID存在？}
    B -->|否| C[NRC 0x12 - SubFunctionNotSupported]
    B -->|是| D[Dcm_Prv_CheckDIDAvailability]
    D --> E{SessionMask匹配？}
    E -->|否| F[NRC 0x31]
    E -->|是| G{Precondition满足？}
    G -->|否| F
    G -->|是| H[调用RTE读取/回调函数]
    H --> I{成功？}
    I -->|否| F
    I -->|是| J[返回DID数据]

```