图解AUTOSAR_SWS_CANInterface

AUTOSAR CAN接口详解文档

基于AUTOSAR标准的CAN通信接口模块架构与工作原理

目录

• 1. AUTOSAR CAN接口概述
• 2. CAN接口架构
  • 2.1 模块定位与组成
  • 2.2 内部组件结构
  • 2.3 接口关系
• 3. CAN消息传输流程
  • 3.1 消息发送流程
  • 3.2 消息接收流程
• 4. CAN控制器模式管理
  • 4.1 状态定义
  • 4.2 状态转换
  • 4.3 错误状态管理
• 5. 总结与应用场景

---

1. AUTOSAR CAN接口概述

AUTOSAR(Automotive Open System ARchitecture)中的CAN接口模块是连接上层通信服务与底层CAN硬件驱动的关键组件。作为通信栈的中间层，CAN接口模块提供了硬件无关的统一接口，屏蔽了底层CAN控制器的硬件差异，使上层应用能够通过标准化接口进行CAN通信。

CAN接口模块的主要职责包括：

• 为上层通信服务提供统一的CAN通信接口
• 管理CAN控制器和收发器的操作模式
• 处理PDU（协议数据单元）的路由和分发
• 实现软件过滤和数据缓冲机制
• 提供网络唤醒和错误管理功能

本文将详细介绍AUTOSAR CAN接口模块的架构、消息传输流程和控制器模式管理机制。

---

2. CAN接口架构

2.1 模块定位与组成

CAN接口在AUTOSAR通信栈中位于通信服务层，是连接上层协议模块和底层驱动模块的枢纽。

根据上图所示，CAN接口架构具有以下特点：

分层结构：

• 应用层：包括PDU Router、CAN Transport Layer、CAN Network Management、COM服务和DCM等上层通信服务
• 通信服务层：包括CAN Interface和CAN State Manager
• 设备驱动层：包括CAN Driver和CAN Transceiver Driver
• 硬件层：包括CAN Controller和CAN Transceiver

这种分层结构遵循AUTOSAR的标准架构设计，实现了不同功能模块的清晰分离。

2.2 内部组件结构

CAN接口模块内部由多个功能组件组成：

• 控制流API：提供CAN控制器模式管理和初始化功能
• 数据流API：处理CAN消息的发送和接收
• PDU通道模式控制：管理通信通道的工作模式
• 软件接收过滤器：实现对接收消息的软件过滤
• 发送缓冲机制：在硬件资源不足时提供消息缓存功能

这些组件协同工作，确保CAN通信的可靠性和灵活性。

2.3 接口关系

CAN接口与其他模块间的接口关系如下：

上行接口：

• 接收来自PDU Router、CAN Transport Layer和CAN Network Management的CanIf_Transmit调用
• 为上层模块提供消息接收和发送确认通知

下行接口：

• 通过Can_Write和Can_SetControllerMode调用CAN Driver
• 通过CanTrcv_SetOpMode调用CAN Transceiver Driver

控制接口：

• 接收来自CAN State Manager的CanIf_SetControllerMode调用
• 接收来自ECU State Manager的CanIf_Init调用

这些接口组成了完整的通信链路，实现了数据和控制信息的双向流转。

---

3. CAN消息传输流程

3.1 消息发送流程

CAN消息发送是CAN接口的核心功能之一，涉及从上层应用到CAN硬件的完整流程。

消息发送流程包含以下关键步骤：

1. 发送请求阶段

   • 上层模块（COM/CanTp/CanNm）通过PDU Router调用CanIf_Transmit
   • CAN接口检查PDU通道模式并查找L-PDU配置（CAN-ID、DLC等）
   • CAN接口将TxPduId映射到硬件发送句柄（HTH）

2. 消息发送处理

   • 硬件对象空闲情况：

     • CAN接口调用Can_Write将消息发送到CAN控制器
     • CAN驱动构建CAN PDU并写入发送缓冲区
     • 返回E_OK并完成发送请求

   • 硬件对象忙情况：

     • CAN驱动返回CAN_BUSY状态
     • 若配置了发送缓冲区，CAN接口将消息存储在缓冲区中
     • 否则返回E_NOT_OK给上层

3. 发送确认阶段（异步）

   • CAN控制器发送完成后触发中断
   • CAN驱动调用CanIf_TxConfirmation通知CAN接口
   • 若存在缓冲消息，CAN接口会取出下一条消息发送
   • CAN接口调用PduR_CanIfTxConfirmation通知上层发送完成

这种设计确保了消息发送的可靠性和灵活性，特别是通过发送缓冲机制处理硬件资源暂时不可用的情况。

3.2 消息接收流程

CAN消息接收流程描述了从CAN控制器到上层应用的数据流转过程。

消息接收流程有三种主要模式：

1. 中断模式接收流程

   • CAN控制器接收到消息后触发中断
   • CAN驱动从硬件读取消息并调用CanIf_RxIndication
   • CAN接口按以下步骤处理消息：
     • 检查PDU通道模式（OFFLINE/ONLINE）
     • 执行软件过滤（根据HRH和CAN-ID匹配）
     • 执行数据长度检查（可选）
     • 查找目标上层模块并调用PduR_CanIfRxIndication

2. 轮询模式接收流程

   • BSW调度器周期性调用Can_MainFunction_Read
   • CAN驱动检查控制器接收缓冲区是否有新消息
   • 若有新消息，处理流程与中断模式类似

3. 缓冲接收模式（可选）

   • 第一阶段：CAN接口接收到消息后存储到接收缓冲区
   • 第二阶段：上层模块主动调用以下API读取数据
     • CanIf_ReadRxNotifStatus检查通知状态
     • CanIf_ReadRxPduData从缓冲区读取数据

这种多模式设计提供了灵活的消息接收机制，适应不同的系统需求和硬件能力。

---

4. CAN控制器模式管理

4.1 状态定义

CAN控制器的模式管理是CAN接口的重要功能之一，通过定义明确的状态模型确保CAN控制器的正确运行。

CAN控制器存在以下主要状态：

• 未初始化（UNINIT）：控制器未初始化状态
• 已停止（CAN_CS_STOPPED）：控制器已初始化但未参与总线通信
• 已启动（CAN_CS_STARTED）：控制器正常工作，可发送和接收消息
• 睡眠（CAN_CS_SLEEP）：控制器处于低功耗模式

4.2 状态转换

状态转换由特定的API触发：

• UNINIT → STOPPED：通过CanIf_Init初始化
• STOPPED → STARTED：通过CanIf_SetControllerMode(CAN_CS_STARTED)启动
• STARTED → STOPPED：通过CanIf_SetControllerMode(CAN_CS_STOPPED)停止
• STOPPED → SLEEP：通过CanIf_SetControllerMode(CAN_CS_SLEEP)进入睡眠
• SLEEP → STOPPED：通过CanIf_SetControllerMode(CAN_CS_STOPPED)或唤醒事件退出睡眠

特殊转换包括：

• STARTED → STOPPED：发生总线关闭（BusOff）事件时，通过CanIf_ControllerBusOff通知
• SLEEP → STOPPED：外部唤醒事件通过EcuM_CheckWakeup或CanIf_CheckWakeup处理

4.3 错误状态管理

在STARTED状态内，CAN控制器还存在详细的通信错误状态：

• 正常通信：无错误状态
• 错误警告（CAN_ERRORSTATE_WARNING）：当发送/接收错误计数器（TEC/REC）超过96
• 被动错误（CAN_ERRORSTATE_PASSIVE）：当发送/接收错误计数器超过127

这些错误状态允许系统监控CAN通信质量并采取适当措施，如错误日志记录或故障处理。

---

5. 总结与应用场景

AUTOSAR CAN接口模块作为通信栈的关键组件，提供了以下核心价值：

架构优势：

• 抽象层设计：有效屏蔽底层硬件差异，提供统一接口
• 模块化结构：清晰的组件分工，便于维护和扩展
• 标准化接口：符合AUTOSAR规范，确保互操作性

功能特点：

• 多模式支持：支持中断、轮询和缓冲等多种工作模式
• 灵活配置：PDU通道模式控制和软件过滤可定制化配置
• 错误管理：提供完善的状态监控和错误处理机制

应用场景：

• 汽车动力总成系统：发动机、变速箱等关键控制单元间的实时通信
• 车身电子系统：门窗、座椅、照明等舒适性和便利性功能的网络连接
• 高级驾驶辅助系统：提供传感器数据交换和控制指令传输的通信基础设施
• 诊断与维护系统：支持车辆诊断和远程维护的数据交换

通过深入理解AUTOSAR CAN接口的架构和工作原理，开发人员可以更有效地进行汽车电子系统的设计和开发，确保CAN通信的可靠性、实时性和安全性。