深入解析AUTOSAR诊断函数调用机制：从原理到工程实践

1次阅读

共计 2547 个字符，预计需要花费 7 分钟才能阅读完成。

去年参与某 OEM 项目时，遇到一个典型的诊断函数使用问题：ECU 刷写过程中频繁出现通信超时。经过排查发现，开发团队在实现 0x31 服务（RoutineControl）时未正确处理 NRC 0x78（requestCorrectlyReceived-responsePending）状态，导致诊断仪误判操作失败。更严重的是，由于未设置合理的报文超时时间，在 CAN 总线负载较高时，部分关键配置参数未能成功写入，最终造成产线上 3% 的 ECU 需要返工。

在 AUTOSAR 架构中，诊断通信管理主要由两个模块协作完成：

DCM（Diagnostic Communication Manager）：处理诊断请求 / 响应协议
DEM（Diagnostic Event Manager）：管理诊断事件和故障码

以 0x22（ReadDataByIdentifier）服务为例，其完整调用流程如下：

sequenceDiagram
    DiagnosticTool->>DCM: 发送 0x22 请求
    DCM->>DCM: 验证 SID 和 DID 有效性
    DCM->>DEM: 检查诊断条件（如会话状态）DEM-->>DCM: 返回条件状态
    DCM->>SWC: 调用 RTE 接口获取数据
    SWC-->>DCM: 返回请求数据
    DCM->>DCM: 组装响应报文
    DCM->>DiagnosticTool: 发送 0x62 响应

以下是符合 AUTOSAR 标准的 0x22 服务处理函数示例（MISRA C 2012 合规）：

/**
 * @brief 处理 ReadDataByIdentifier 服务
 * @param[in] pMsgContext - 诊断报文上下文
 * @return Std_ReturnType - E_OK: 成功 E_NOT_OK: 失败
 * @remark 符合 ISO 14229- 1 标准
 */
Std_ReturnType Diag_ReadDataByIdentifier(const PduInfoType* pMsgContext)
{
    /* 参数校验（MISRA Rule 17.2）*/
    if ((NULL == pMsgContext) || 
        (pMsgContext->SduDataPtr == NULL)) {return E_NOT_OK;}

    uint8* requestData = pMsgContext->SduDataPtr;

    /* 检查 SID */
    if (0x22 != requestData[0]) {Dem_SetEventStatus(DEM_EID_INVALID_SID);
        return E_NOT_OK;
    }

    /* 提取 DID（注意字节序）*/
    uint16 did = (uint16)((requestData[1] << 8) | requestData[2]);

    /* DID 白名单检查 */
    if (!IsValidDid(did)) {Dcm_SetNegResponse(NRC_REQUEST_OUT_OF_RANGE);
        return E_NOT_OK;
    }

    /* 状态机管理 */
    switch (Dcm_GetSessionStatus()) {
        case DEFAULT_SESSION:
            /* 基础会话允许的 DID 处理 */
            break;
        case PROGRAMMING_SESSION:
            /* 刷写会话特殊处理 */
            break;
        default:
            Dcm_SetNegResponse(NRC_SERVICE_NOT_SUPPORTED_IN_ACTIVE_SESSION);
            return E_NOT_OK;
    }

    /* 实际数据读取操作 */
    if (E_OK != ReadDidData(did, pMsgContext->SduDataPtr + 3)) {Dcm_SetNegResponse(NRC_CONDITIONS_NOT_CORRECT);
        return E_NOT_OK;
    }

    return E_OK;
}

在 AUTOSAR OS 调度环境下，诊断服务可能面临以下并发问题：

数据竞争 ：当应用任务和诊断任务同时访问同一 DID 数据时
优先级反转 ：低优先级的诊断任务持有资源时被高优先级任务阻塞

推荐解决方案：

对共享数据使用 BSW（Basic Software）模块提供的资源锁：

StatusType res = GetResource(RESOURCE_DID_ACCESS);
/* 临界区操作 */
ReleaseResource(RESOURCE_DID_ACCESS);

在 Davinci Configurator 中配置 DCM 任务的合理优先级：
通常设置为高于应用任务但低于报警处理任务
确保不会因诊断处理导致实时性任务延迟

P2Server 时间 （初始响应时间）：建议 50-100ms
P2*Server 时间 （后续响应间隔）：建议 20-50ms
在 CAN FD 8MHz 带宽下，可适当缩短时间

收到需要长时间处理的服务（如 0x31）时立即返回 0x78
启动后台处理任务
处理完成后通过 0x7F 响应结果
设置超时监控（建议最长不超过 5 秒）

参数项	推荐值	说明
DcmDsdTimerP2Server	60	初始响应超时 (ms)
DcmDsdTimerP2*Server	30	流控制帧间隔 (ms)
DcmDemTriggerOnDTCSetting	TRUE	使能 DEM 事件触发
DcmProtocolRxBufferSize	4095	CAN FD 最大支持长度

在支持 UDS over CAN FD 的场景下，如何利用增大帧长度（最高 64 字节）来优化大批量 DID 读取的效率？
当需要支持 0x22 服务读取动态变化的运行数据（如转速、温度）时，如何平衡数据实时性和诊断响应延迟？
对于功能安全相关 DID（ASIL 等级），除了基本的校验机制外，还需要增加哪些保护措施？

在最近参与的域控制器项目中，我们通过优化诊断状态机转换逻辑，将 0x22 服务的平均响应时间从 85ms 降低到 52ms（测试条件：CAN 500kHz，负载率 40%）。关键改进包括：预加载常用 DID 数据到缓存、采用无锁队列处理并发请求、合理设置 BSW 任务优先级。建议开发团队在项目早期就建立诊断响应时间的基线指标，这对后期性能调优非常重要。

正文完