1、AUTOSAR

1、面试官可能问：“你之前做的 VCU，如果要迁移到 AUTOSAR，该怎么划分？”

你可以回答：
我之前开发的 VCU，应用业务包括油门解析、目标扭矩计算、整车状态机、控制权仲裁以及故障降级。
如果采用 AUTOSAR Classic，我会将这些业务划分为应用 SWC，通过 RTE 与其他组件及 BSW 交互。
CAN 的信号打包和解包由 COM 负责，PDU 路由由 PduR 负责，CanIf 进行控制器接口抽象，底层 CanDrv 负责 CAN 硬件操作。网络状态管理交给 CanSM、ComM 等模块，诊断和故障事件可结合 Dem 等模块实现。
这样可以把业务逻辑与硬件驱动解耦，提高软件移植和复用效率。
这里强调的是架构设计思路，不要说自己已经完成了 AUTOSAR 工程迁移。

接收流程反过来：

CAN 硬件接收 → CanDrv → CanIf → PduR → COM → RTE → SWC。

2、COM、PduR、CanIf、CanDrv 分别负责什么？

2、高频问题：什么是 Signal、PDU、Frame？

举个 VCU 的例子。

你要发送电机目标扭矩：

CAN ID = 0x180
DLC = 8

Byte0~1 : 目标扭矩
Byte2   : 电机使能
Byte3   : 控制模式
Byte4   : Alive Counter
Byte5   : Checksum
Byte6~7 : 预留

这里的目标扭矩、使能、控制模式，分别可以定义为 Signal。

多个 Signal 按配置封装成 I-PDU，然后通过下层映射为 CAN 帧发送。

注意：一个 I-PDU 通常可以映射为一个经典 CAN 数据帧的有效载荷，但不能把 I-PDU、PDU 路由和 CAN 物理帧完全等同起来。

面试还可能继续问：

Q：发送周期 10ms 是谁实现的？

A：在 AUTOSAR COM 周期发送方案中，由 COM 的发送模式配置和周期处理实现发送调度；应用 runnable 的执行周期则由 RTE 事件映射及 OS 调度决定。二者不一定相同。

Q：收到的数据怎么知道过期了？

A：COM 可以配置接收截止时间监控（Rx Deadline Monitoring），但对于扭矩这类安全关键数据，还要由应用层结合信号有效性、通信模式和故障策略处理。超时后应禁止使用陈旧的控制数据，并进入设计规定的安全状态。

Q：Alive Counter 和 Checksum 是干什么的？

A：Alive Counter 用于辅助检测重复、丢失或顺序异常的报文；Checksum 或 CRC 用于检测部分数据错误。具体算法和容错规则由协议或 E2E 配置决定，不能代替所有通信故障诊断。

3、AUTOSAR 工具链：必须认识这些名字

工具 主要作用 你需要掌握什么
Vector DaVinci Configurator Classic AUTOSAR BSW 配置及代码生成 配置 CAN、COM、PduR、CanIf 等
DaVinci Developer Classic SWC 设计、接口、RTE 相关开发 软件组件和 RTE
EB tresos Studio AUTOSAR ECU/BSW/MCAL 模块配置 配置和生成基础软件
CANoe 网络仿真、分析、自动化测试 虚拟节点、仿真、测试
CANalyzer CAN/LIN 等通信分析 抓包、报文分析
CAPL Vector 环境的事件驱动脚本语言 报文模拟、故障注入
CANdb++ CAN 数据库编辑 DBC 信号定义

DBC 和 ARXML 有什么区别？
DBC 是 CAN 数据库描述文件，主要定义 CAN 报文和信号。

典型内容包括 CAN ID、DLC、信号起始位、长度、字节序、Factor、Offset、单位等。

ARXML 是 AUTOSAR 的 XML 描述格式，可以描述 SWC、端口、接口、ECU 配置、通信系统和 BSW 参数等广泛内容。

4、如何用 CANoe 定位通信异常？

接入总线，确认接口与波特率	检查 Trace 中的 CAN ID / DLC / 数据

检查帧周期、丢帧、错误帧	根据 DBC 解码信号

比较期望值与实际值	模拟其他 ECU 或注入故障

验证 ECU 超时、降级和恢复

CANalyzer 主要用于分析和测试；CANoe 更强调仿真、测试与自动化能力。
如果面试官问你是否熟悉 CANoe，而你没有实际长期使用过：
我之前主要使用 CAN 调试工具完成报文收发、日志采集、协议分析和底盘通信联调。CANoe 目前更多是了解其网络仿真、Trace、信号分析和自动化测试能力，还没有在量产 AUTOSAR 工程中完整使用过。调试方法是相通的，需要补的是工具操作和配置工作流。

5、SWC、Runnable、RTE、OS 是怎么运行的？

1. SWC 是什么？

SWC（Software Component），软件组件。

可以把你之前 VCU 的程序划分为几个 SWC：

VCU 软件

├── PedalSWC
│   └── 油门踏板信号处理
│
├── VehicleStateSWC
│   └── 整车状态机
│
├── TorqueControlSWC
│   └── 目标扭矩计算
│
├── FaultManagerSWC
│   └── 故障处理与降级
│
└── MotorControlSWC
    └── 电机控制请求

SWC 之间不应该通过随意访问其他模块的全局变量来交换数据，而是尽可能通过标准化接口通信。

典型接口分为：

接口	作用
Sender-Receiver	传递信号和数据
Client-Server	请求执行操作并获取结果
Mode-Switch	通知或管理模式切换

例如：

/* 通过 RTE 读取油门信号 */
Rte_Read_PedalValue(&pedal);

/* 通过 RTE 输出目标扭矩 */
Rte_Write_TargetTorque(torque);

这里的函数是概念示例。真实的 RTE API 名称由 SWC 端口、数据元素及工具生成规则决定。

2. Runnable 是什么？

Runnable 可以理解为 SWC 内部能够被 RTE 调度执行的一个逻辑执行单元，通常对应一个 C 函数。

例如你的 VCU 控制算法：

void TorqueControl_10ms(void)
{
    uint16_t pedal;
    float torque;

    Rte_Read_PedalValue(&pedal);

    torque = CalculateTorque(pedal);

    Rte_Write_TargetTorque(torque);
}

这是一个典型的周期 Runnable。

但是注意：

Runnable 不等于 FreeRTOS Task。

Runnable 由 RTE 事件触发，其执行映射到 AUTOSAR OS 的 Task 中。

一个 OS Task 可以执行多个 Runnable。

3. Runnable 由谁决定每 10ms 执行一次？

这道题非常重要。

这里需要区分三个东西：

Timing Event： 描述 Runnable 的周期触发需求。

RTE： 根据配置生成 Runnable 调用和数据交换的相关代码。

AUTOSAR OS： 负责实际任务调度。

实际项目还需要配置 OS Counter、Alarm 或 ScheduleTable 等时序机制。

6、面试官问：FreeRTOS 的 Task 和 AUTOSAR Runnable 有什么区别？

你可以回答：

FreeRTOS Task 是操作系统调度的执行实体，开发者可以直接创建任务，并在任务函数中编写循环。

AUTOSAR Runnable 是应用软件组件内部的执行单元，通过 RTE 事件触发，再映射到 AUTOSAR OS Task 中执行。

两者不是同一层次的概念。AUTOSAR 可以将多个 Runnable 映射到一个 OS Task，便于统一管理执行周期、优先级和任务调度。

7、、AUTOSAR COM 怎么控制发送周期？

这是 CAN 总线开发岗位非常可能追问的内容。

1. COM 的三种常见发送模式

AUTOSAR COM 的发送模式配置中，主要需要了解：

模式	作用	举例
PERIODIC	周期发送	电机状态每 10ms 发送
DIRECT	按配置的发送触发条件发送	故障状态变化触发发送
MIXED	结合周期发送和直接触发	周期心跳，同时允许事件触发

除此之外，还有 NONE 等配置模式。实际 DIRECT 发送是否立即触发、发送多少次，还受到信号 Transfer Property、重复发送配置和调度执行方式影响。

2. 假设要求电机目标扭矩每 10ms 发送

可以这样理解配置过程：

Signal：TargetTorque
       |
配置长度：16bit
       |
配置 Factor、Offset、字节序
       |
映射到 I-PDU
       |
配置 I-PDU 发送模式 PERIODIC
       |
配置周期：10ms
       |
COM 周期处理
       |
PduR
       |
CanIf
       |
CanDrv
       |
CAN 总线

其中最值得记住的配置参数有：

• ComTxModeMode：发送模式。
• ComTxModeTimePeriod：周期发送时间。
• ComTxModeRepetitionPeriod：重复发送间隔。
• ComTxModeNumberOfRepetitions：重复发送次数。
• ComTxModeTimeOffset：周期发送偏移时间。

注意这些是典型 AUTOSAR COM 配置参数名称，具体可用项与工具、AUTOSAR 版本及配置容器有关。

面试官问：调用 Com_SendSignal() 后，CAN 会立刻发送吗？

不一定。

你可以回答：

Com_SendSignal() 主要负责更新 COM 中对应信号的数据。

是否触发发送取决于该信号的 Transfer Property、I-PDU 发送模式及发送相关配置。

对于 PERIODIC 模式，实际发送主要由 COM 周期发送机制控制；对于配置了触发条件的 DIRECT 或 MIXED 模式，则可能触发直接发送请求。

即使 COM 发起发送请求，也还要经过 PduR、CanIf、CanDrv，因此不代表报文已经从 CAN 总线上发送完成。

3. COM 怎么检测接收超时？

例如 VCU 要求每 10ms 收到一次电机速度。

假设配置：

电机速度报文周期：10ms
接收超时阈值：100ms

AUTOSAR COM 中可以配置：

• ComTimeout
• ComFirstTimeout
• ComRxDataTimeoutAction
• ComTimeoutNotification

典型流程：

收到电机速度信号
       |
COM 更新接收数据
       |
重置相应接收超时监控
       |
规定时间内未收到有效更新
       |
COM 检测超时
       |
执行配置的超时动作
       |
调用超时通知或更新信号
       |
应用层执行故障处理

ComRxDataTimeoutAction 的典型行为包括替换为初始值或保持当前值等，具体取决于配置。

面试加分点：

COM 检测到超时，并不意味着它一定会自动停止电机。

COM 负责信号层处理和通知，最终控制器如何降级，需要由应用层和安全策略完成。

8、CanSM、ComM、CanNm、BswM 究竟有什么区别？

这几个模块是典型的面试追问点。

你现在的笔记只写了它们的定义，还需要理解它们怎么协同工作。

1. 四个模块分别负责什么？

模块	全称	核心职责
CanSM	CAN State Manager	CAN 网络通信状态及 Bus-Off 恢复
ComM	Communication Manager	管理通信用户的通信模式请求
CanNm	CAN Network Management	CAN 网络管理报文、休眠与唤醒协调
BswM	BSW Mode Manager	根据模式条件执行配置的模式仲裁与动作

ComM 的典型通信模式有：

• COMM_NO_COMMUNICATION：不允许正常通信。
• COMM_SILENT_COMMUNICATION：限制发送，允许接收的通信模式。
• COMM_FULL_COMMUNICATION：完整通信。

CanSM 的典型通信状态则包括 NO_COMMUNICATION、SILENT_COMMUNICATION、FULL_COMMUNICATION，另外还有内部的状态切换和恢复子状态。

两者的区别是：

ComM 负责协调通信需求，CanSM 负责落实 CAN 通信控制的状态切换。

2. 汽车上电后，CAN 是怎么启动的？

以一个典型 VCU 为例：

ECU 上电
    |
    v
EcuM 管理 ECU 初始化流程
    |
    v
OS / BSW 模块初始化
    |
    v
应用请求完整通信
    |
    v
ComM 处理通信请求
    |
    v
CanSM 协调 CAN 控制器和收发器
    |
    v
CAN 进入 Full Communication
    |
    v
COM I-PDU Group 等通信资源按配置启用
    |
    v
开始正常收发 CAN 报文

这是一条简化的逻辑流程，并不是所有 AUTOSAR 项目都严格按图中的线性顺序执行。实际还需要 BswM、EcuM、ComM、CanNm 之间的配置与协作。

9、AUTOSAR 下 Bus-Off 由谁负责？

你之前学习的 STM32 Bus-Off 处理是自研架构。

在 AUTOSAR Classic 中，典型流程是：

CAN 控制器检测 Bus-Off
           |
           v
        CanDrv
           |
  CanIf_ControllerBusOff()
           |
           v
         CanIf
           |
           v
        CanSM
           |
           v
    Bus-Off 恢复状态机
           |
           v
  控制器恢复、恢复等待与状态检查
           |
           v
    恢复符合条件后继续通信

你可以这样回答：

CAN 底层控制器负责检测 Bus-Off，CanDrv 通过 CanIf 将 Bus-Off 事件通知 CanSM。

CanSM 根据配置的恢复策略协调控制器状态、恢复等待和通信模式转换。

应用层还需要根据通信中断情况进行故障降级。CAN 总线恢复正常之后，也不一定可以直接恢复原有扭矩控制，需要重新确认设备状态和控制安全条件。

注意：AUTOSAR 标准 CAN 接口中，CanIf 会接收底层驱动的 Bus-Off 通知，再协调上层状态管理。不要把 COM 当作 Bus-Off 恢复模块。

10、面试官问：ECU 上电以后，为什么 CAN 没有发送报文？

你可以按下面顺序排查：

1. CAN Controller 和 Transceiver 是否正确初始化。
2. CanSM 是否处于允许正常发送的通信状态。
3. ComM 是否有 Full Communication 请求。
4. BswM 是否根据模式切换执行相应动作。
5. 对应的 COM I-PDU Group 是否已经启动。
6. COM 是否配置了正确的发送模式和周期。
7. CanIf、PduR、CanDrv 的映射是否正确。

这比只回答“看看 CAN 驱动有没有初始化”更加符合 AUTOSAR 开发岗位。

11、MCAL、CanDrv、CanIf、CanTrcv、CDD 怎么区分？

这是车载 MCU 底层岗位可能问的重点。

1. MCAL 是什么？

MCAL（Microcontroller Abstraction Layer），微控制器抽象层。

可以把它理解为 MCU 外设的标准化驱动层。

典型驱动模块：

MCAL 模块	对应硬件
Mcu	MCU 时钟、复位等功能
Port	引脚配置
Dio	数字输入输出
Adc	ADC
Spi	SPI 控制器
Can	CAN 控制器
Lin	LIN 控制器
Gpt	通用定时器
Wdg	看门狗
Pwm	PWM

面试官问：STM32 HAL 和 AUTOSAR MCAL 有什么区别？

STM32 HAL 是厂商提供的硬件抽象接口，用于操作 MCU 外设。

AUTOSAR MCAL 是符合 AUTOSAR 标准接口和配置要求的底层驱动模块。

两者都涉及 MCU 硬件操作，但 AUTOSAR MCAL 还需要遵循对应模块的标准 API、配置模型、初始化方式以及上层模块集成要求。

因此不能直接认为 HAL_CAN_Send 和 AUTOSAR Can_Write 只是函数名称不同。

12. CanDrv 和 CanTrcv 有什么区别？

这是很容易被问到的一题。

CanDrv： 管理 CAN 控制器，包括波特率、发送邮箱、接收硬件对象、中断和控制器模式。

CanTrcv： 管理 CAN 收发器的工作模式，例如 Normal、Standby 等，具体支持哪些模式取决于器件。

CanTrcv 一般归属于 ECU Abstraction 相关模块，而不是 MCAL 内的 CAN 控制器驱动。

什么是 CDD？

CDD（Complex Device Driver），复杂设备驱动。

当标准 BSW 模块不适合某些特殊硬件、严格时序或专用设备功能时，可以通过 CDD 实现特定驱动和接口。

但不能因为自己不熟悉 AUTOSAR，就把所有业务功能都放进 CDD。CDD 的使用应由架构需求决定。

13、E2E、DEM、DCM、CanTp 必须知道

1. E2E 是什么？

E2E（End-to-End Communication Protection），端到端通信保护。

它不是简单地检测 CAN 总线物理错误，而是用于保护应用数据在通信链路中的完整性和时序等属性。

典型 E2E 保护可以利用：

• CRC：检测数据损坏。
• Counter：检测重复、丢失和顺序异常。
• Data ID：将数据与预期的数据标识关联。
• 接收监控机制：辅助识别更新异常。

E2E 有不同保护 Profile，实际字段和检查行为取决于 Profile 及配置。

面试官问：CAN 本身已经有 CRC，为什么还要 E2E？

CAN 帧 CRC 主要保护总线传输过程中的帧数据。

但是应用信号从发送端的软件组件到接收端的软件组件，中间还经过数据缓存、通信栈和其他处理环节。

E2E 通过计数器、CRC、Data ID 等机制，进一步检测数据损坏、重复、丢失及顺序异常等通信失效情况。

因此 CAN 帧 CRC 和 E2E 保护的范围不同，不能相互替代。

14、面试官问：UDS 0x19 是什么？

0x19 是 ReadDTCInformation，读取诊断故障码信息。

你还应该认识：

服务 ID	作用
0x10	诊断会话控制
0x11	ECU Reset
0x14	清除诊断信息
0x19	读取DTC信息
0x22	根据辨识符读数据
0x27	安全访问
0x2E	按标识符写入数据
0x31	常规控制
0x34	请求下载
0x36	传输数据
0x37	Request Transfer Exit

这些都是 UDS 常见服务，具体支持哪些由 ECU 和项目配置决定。

你之前做过 Bootloader、升级、故障诊断，这部分可以与实际项目结合。

2. DEM 和 DCM 的区别

模块	主要作用
Dem	Diagnostic Event Manager，诊断事件管理
Dcm	Diagnostic Communication Manager，诊断通信管理
CanTp	CAN Transport Layer，处理 ISO-TP 分段与流控
NvM	NVRAM Manager，非易失性数据管理

举例：

电机通信超时，VCU 需要记录故障，并允许诊断仪通过 UDS 读取。

电机通信超时
       |
       v
通信监控或应用层检测
       |
       v
Dem_SetEventStatus()
       |
       v
Dem 管理诊断事件、故障状态
       |
       v
诊断仪通过 CAN 发送 UDS 请求
       |
       v
CanTp → PduR → Dcm
       |
       v
Dcm 与 Dem 交互
       |
       v
读取 DTC 信息并生成响应

图中省略了底层 CanIf/CanDrv 和部分诊断路由配置。

2、CAN 底层协议与驱动

1、CAN 仲裁机制

节点 A：ID = 0x100
节点 B：ID = 0x200

在相同帧格式且同时竞争总线时，ID 0x100 优先级更高

面试官问：“为什么 CAN ID 越小优先级越高？”

你回答：“因为 CAN 在仲裁字段逐位比较，0 为显性位，会覆盖隐性位 1。因此在其他条件相同的情况下，数值更小的 ID 会赢得仲裁。”

补充：11 位标准帧与 29 位扩展帧竞争时，还需要考虑帧格式和仲裁字段，而不能只比较数值大小。

参数 经典 CAN CAN FD
标准 ID 11 位 11 位
扩展 ID 29 位 29 位
数据长度 最多 8 字节 最多 64 字节
波特率 通常最高 1Mbps 可在数据阶段切换更高波特率
CRC 经典 CAN CRC 机制 更长的 CRC 机制
典型用途 ECU 控制信号 较大数据量、密集通信

CAN FD 的两个重要概念：

FDF： 用于区分 CAN FD 帧与经典 CAN 帧。

BRS： Bit Rate Switch，表示是否在数据阶段切换到更高的通信速率。

CAN 报文错误与 Bus-Off

1、为什么 CAN 会出现 Bus-Off？

CAN 总线有错误检测和错误隔离机制。

CAN 控制器内部维护两个错误计数器：

• TEC（Transmit Error Counter）：发送错误计数器。
• REC（Receive Error Counter）：接收错误计数器。

CAN 的三个错误状态

• Error Active（主动错误状态）TEC、REC 均小于 128，仍可正常发送和接收 CAN 报文。
• Error Passive（被动错误状态）TEC 或 REC 达到 128，节点仍能参与通信，但错误标志行为和发送限制有所变化。
• Bus-Off（总线关闭）TEC 超过 255，控制器退出正常总线通信，无法继续正常发送报文，直到完成规定的恢复过程。

Bus-Off 的目的，是让持续出现发送错误的节点退出通信，避免它持续干扰其他正常节点。

CAN 发送失败
    |
TEC 按协议规则累积
    |
错误增加
    |
进入 Error Passive
    |
TEC 继续增加
    |
TEC > 255
    |
进入 Bus-Off

2、Bus-Off 发生后如何恢复？

CAN 协议的 Bus-Off 恢复涉及控制器观察到规定的总线隐性位序列，经典条件是 128 次连续 11 个隐性位 的序列。这个条件和控制器是否自动重新进入正常模式，是两个相关但不同的问题。

以 STM32 bxCAN 为例，可以通过 ABOM 配置选择自动 Bus-Off 管理行为。是否由硬件自动恢复、何时由软件重新初始化或启动，需要依据具体 MCU、HAL 配置和系统状态机设计。

检测到 Bus-Off
       |
       v
记录故障 + 设置 CAN 不可用
       |
       v
通知 VCU 控制任务
       |
       v
执行本地安全降级
       |
       v
CAN 恢复状态机
       |
       v
检查控制器与总线是否恢复
       |
   +---+---+
   |       |
  成功     失败
   |       |
重新允许   限制重试
正常通信   持续故障
   |
重新确认设备状态
   |
按安全策略恢复控制

面试官追问：CAN Bus-Off 是不是直接重新初始化就行？

不行。CAN 协议规定 Bus-Off 节点恢复需要满足相关总线空闲条件，经典规则涉及检测 128 次连续 11 个隐性位的序列。具体由控制器硬件和驱动实现配合完成，AUTOSAR 还要遵守 CanSM 的恢复策略。

如果线路短路或波特率错误，反复初始化根本无法解决问题。

AUTOSAR 下 Bus-Off 由谁负责？

你之前学习的 STM32 Bus-Off 处理是自研架构。

在 AUTOSAR Classic 中，典型流程是：

CAN 控制器检测 Bus-Off
           |
           v
        CanDrv
           |
  CanIf_ControllerBusOff()
           |
           v
         CanIf
           |
           v
        CanSM
           |
           v
    Bus-Off 恢复状态机
           |
           v
  控制器恢复、恢复等待与状态检查
           |
           v
    恢复符合条件后继续通信

你可以这样回答：

CAN 底层控制器负责检测 Bus-Off，CanDrv 通过 CanIf 将 Bus-Off 事件通知 CanSM。

CanSM 根据配置的恢复策略协调控制器状态、恢复等待和通信模式转换。

应用层还需要根据通信中断情况进行故障降级。CAN 总线恢复正常之后，也不一定可以直接恢复原有扭矩控制，需要重新确认设备状态和控制安全条件。

注意：AUTOSAR 标准 CAN 接口中，CanIf 会接收底层驱动的 Bus-Off 通知，再协调上层状态管理。不要把 COM 当作 Bus-Off 恢复模块。

3、CAN 通信突然断开，如何定位？

可以把原因按层次分类：
层次 可能问题 检查方法
物理层 终端电阻错误、断线、接地异常、干扰 万用表、示波器
控制器 Bus-Off、错误计数器升高、FIFO 溢出 CAN 外设状态寄存器
驱动层 中断处理不及时、发送邮箱满 驱动日志、统计计数
系统层 任务阻塞、调度延迟、优先级问题 RTOS 运行统计
通信栈 PDU 映射、发送模式或网络状态错误 配置及状态检查
应用层 信号超时、协议版本不一致、校验失败 解析日志、超时统计
实车排查细节：

如果整车断电，CAN 网络两端各有一个 120Ω 终端电阻，两个电阻并联后，CAN_H 与 CAN_L 之间通常应测得约 60Ω。

不过这是典型双终端网络的测量值，复杂拓扑或有其他电路时不能机械套用，也不能在带电情况下用电阻挡测量。

4、CAN 发送邮箱满了怎么办？

1、硬件邮箱是什么？（以 STM32F4 上的 bxCAN 为例）

• 3 个发送邮箱（Tx Mailbox）。
• 两个接收 FIFO（FIFO0、FIFO1）。
• 每个接收 FIFO 可缓存 3 帧报文。

2、面试官继续问：“高优先级急停命令如何插队？”

正确回答：
我会将安全相关报文与普通业务报文做优先级隔离。软件层采用高低优先级队列，发送调度先处理高优先级队列，同时为安全命令分配符合通信矩阵要求的 CAN ID。

但已经开始在线路上发送的报文，普通软件无法直接插队。因此还需要限制低优先级报文的积压，保证高优先级报文的最坏等待时间。

对安全关键动作，也不能仅依赖一条 CAN 急停报文，还需要结合本地故障处理和系统安全设计。

但这里有一个非常重要的细节

假设三个硬件邮箱已经装了：

邮箱	报文	CAN ID
Mailbox0	日志数据	0x500
Mailbox1	参数查询	0x400
Mailbox2	电机控制	0x200

此时急停报文 0x080 到达。

即使急停在软件队列中排第一，CAN TX Task 也无法立即将它放入已满的邮箱。

软件优先级不能直接覆盖已经提交给硬件的报文。

因此你要掌握三种优化方式：

方式 A：不让低优先级报文长期占满邮箱。

对于低优先级报文，限制最大待发数量，例如调度器可以配置为只占用最多两个邮箱，预留一个供高优先级通信使用。

这是一种软件资源预留策略，不是 bxCAN 本身提供了固定的高优先级专用邮箱。

方式 B：合理配置硬件邮箱仲裁方式。

STM32 bxCAN 的 TXFP 配置影响三个邮箱之间的发送选择：

• TXFP=0：优先考虑 CAN 报文 ID 的优先级。
• TXFP=1：优先考虑邮箱发送请求的先后顺序。

如果需要借助 CAN ID 表达紧急程度，通常应认真评估 ID 优先级方式，而不是让低优先级报文仅因为先进入邮箱就优先发送。

方式 C：必要时撤销尚未发送的低优先级报文。

bxCAN 支持请求终止待发送邮箱中的报文，HAL 提供类似：

HAL_CAN_AbortTxRequest(&hcan, mailboxMask);

但要注意：

• 只能针对可终止的发送请求操作。
• 已经在总线上发送的完整 CAN 帧不能被软件强行插队。
• 终止请求可能涉及竞态和发送结果不确定性。
• 不是所有报文都允许丢弃或撤销。

所以量产软件中，应该通过发送调度策略优先保证时限，而不是经常依赖 Abort 抢占。

另外，安全急停不能只依赖 CAN 报文优先级。对于安全关键运动系统，必须根据风险分析设计本地超时停机、驱动器保护或独立安全通道。

3、如果面试官问：怎么避免高优先级报文饿死低优先级报文？

这是典型的优先级饥饿问题。

我会采用：

• 安全类报文始终优先。
• 周期控制类报文根据 Deadline（发送截止时间）调度。
• 非关键低优先级报文使用带宽配额，例如限制每 10ms 最多发送若干帧。
• 当总线长期过载时，优先削减日志、状态查询等非关键流量。
• 对每类报文统计最大排队时间和超时率。

4、CAN 接收 FIFO 溢出怎么办？

CAN 外设通常先将接收到的帧放入硬件 FIFO 或接收缓冲区，CPU 再通过中断或轮询取出。

如果 CPU 取数据速度太慢，可能发生硬件接收溢出。

优化方式包括：

• 硬件过滤不需要的 CAN ID，减少无关中断。
• 中断中尽快读取 CAN 帧，放入预分配的软件缓冲区，不做复杂解析和日志输出。
• 由接收处理任务完成协议解析和状态更新。
• 记录 FIFO Overrun、软件队列溢出及最大积压量。
• 对于已覆盖的数据，按报文性质采用丢弃、覆盖最新状态或故障上报策略。
  一个加分细节：

并不是所有 CAN 数据都适合排队。

例如电机转速这种周期状态，处理 100ms 前的数据可能已经没有意义；而故障事件和配置命令可能需要保证顺序和完整性。

因此，需要根据数据语义设计不同的缓冲策略。

3、LIN 协议

LIN 和 CAN 的核心区别

对比项 CAN LIN
通信方式 多主竞争、仲裁 一个主节点协调通信
典型速率 125K～1Mbps 等 最高约 20Kbps
物理接口 差分双线 单线通信
发送机制 根据优先级仲裁 根据主节点调度
成本 相对较高 相对较低
典型应用 动力、底盘、ECU 通信 车窗、座椅、空调执行器

Lin为什么不需要can的仲裁？

4、常问

从 MCU 接收到 CAN 帧，到应用程序拿到数据，整个过程是什么？

CAN 控制器通过过滤器接收数据，写入 RX FIFO 或接收缓冲区，触发中断或由轮询读取。CanDrv取得数据后，通过 CanIf 向上通知，再经过 PduR、COM 完成 I-PDU 和信号处理，最后由 RTE 提供给 SWC。使用传统自研架构时，对应的是硬件接收、驱动缓存、协议解析、状态更新和控制任务读取。

CAN 接收中断频率太高，CPU 占用率很高怎么办?

首先测量中断频率、报文数量、最坏中断执行时间和FIFO溢出次数。然后优化硬件接收过滤，减少不需要的帧；中断内只读取数据和缓存，不做日志或复杂协议处理；把解析移到任务上下文。还要检查中断优先级、缓冲区深度和总线实际负载，不能简单通过关闭中断解决。

CAN ID、DLC、Signal 分别代表什么?

CAN ID 是报文标识符，同时参与仲裁; DLC 是数据长度编码，CAN FD 中 DLC 与字节长度不是所有值都一一相等；Signal 是业务数据的逻辑定义，可以具有起始位、长度、比例、偏移、字节序和有效性约束。

COM 和 PduR 的区别是什么?

COM 面向应用信号，处理信号映射、I-PDU 组包解包、发送模式以及接收超时等。PduR 面向 PDU 路由，根据配置将数据交给 Canlf、CanTp 或其他通信模块。

如果控制任务要求 10ms 执行一次，但偶尔运行了 15ms，怎么办？

先测量是否为单次任务执行超时，还是任务被延迟调度。分别统计WCET、任务释放抖动、中断占用、锁等待和通信阻塞。优化时拆分阻塞式操作、降低非关键日志影响、调整优先级和任务周期，并制定超期周期处理策略，避免无限积压。

AUTOSAR CanSM、CanNm、ComM 各是什么?

CanSM 管理 CAN 控制器及收发器相关通信状态和 Bus-Off 恢复；CanNm负责 CAN 网络管理协议；ComM 根据通信用户请求及网络管理等信息协调通信模式。三者是不同层次的状态管理，不是同一个模块。

UDS 为什么需要 CanTp?

UDS 诊断消息可能大于一帧 CAN 能承载的数据，ISO-TP/CanTp 负责多帧分段与重组，并通过 First Frame、Consecutive Frame、Flow Control 等机制完成传输。Dcm 负责诊断服务处理，CanTp 负责底层传输。

如果让你从零开发CAN 模块，会如何规划?

首先明确需求、报文矩阵、波特率、周期、超时与安全约束；然后设计驱动接口、接收过滤、发送调度、缓存与并发保护；再设计协议解析、错误隔离、通信健康及 Bus-Off 恢复机制。验证阶段覆盖正常收发、总线高负载、物理断线、对端掉电、错误恢复、长时间稳定性和时序指标，并做好文档与需求追溯。

实际项目开发

AUTOSAR 项目具体怎么开发？

如果面试官说：“假设现在给你一个 CAN 通信矩阵，让你开发 AUTOSAR CAN 通信模块，你怎么做？”

① 明确通信需求

CAN ID、信号定义、发送周期、超时阈值、校验方式、通信模式和性能要求。

② 导入系统或 ECU 配置

根据项目工具流程导入 DBC、ARXML 或 ECU Extract，确认 ECU 收发报文和信号映射。

③ 配置 AUTOSAR 通信模块

COM：Signal、I-PDU、周期、超时。

PduR：PDU 路由关系。

CanIf：Tx/Rx PDU、HTH/HRH 等映射。

CanDrv：波特率、控制器、硬件对象及中断配置。

CanSM/ComM：通信状态与恢复策略。

④ 生成代码并集成

使用对应工具链生成 BSW 配置代码；结合 RTE、应用 SWC、MCAL 和启动初始化流程完成工程构建。

⑤ 台架验证

验证报文收发、发送周期、信号解析、超时处理、Bus-Off 恢复、网络管理、负载与实时性。

⑥ 文档与版本管理

保存配置基线、测试用例、验证结果、问题记录和软件版本，建立需求追溯关系。

结合实际项目，最可能被问的 4 个 AUTOSAR 场景题

场景一：COM 配置了 10ms 周期，但 CANoe 看到 20ms 才发送一次，怎么办？

我建议这样回答：

首先确认 COM 中 I-PDU 的发送模式、周期和偏移参数是否正确。

然后检查 COM 周期处理函数的调用周期，OS 任务是否按预期调度，相关 I-PDU Group 是否启动，以及当前通信模式是否允许发送。

如果 COM 已经正常请求发送，再向下检查 PduR、CanIf、CanDrv 的发送状态，是否存在邮箱等待、总线负载过高或 Bus-Off 等问题。

最后用时间戳分别记录 COM 发送请求、CanIf 发送请求和底层发送完成时刻，定位延迟发生在哪一层。

核心：区分配置周期错误、调度延迟和总线发送延迟。

场景二：CanIf 已经收到了报文，为什么 SWC 读取不到信号？

按这个顺序排查：

1. CanIf 的 RxPdu 配置和 CAN ID 匹配是否正确。
2. PduR 是否正确路由到 COM。
3. COM I-PDU 配置及 I-PDU Group 是否正常启用。
4. Signal 的起始位、长度、字节序是否正确。
5. 是否触发接收校验或信号过滤。
6. RTE 的端口、数据元素映射是否正确。
7. Runnable 是否执行，并实际读取对应信号。

这里最重要的思路：

硬件收到 CAN 帧，不代表 COM 一定成功解包；COM 成功解包，也不代表应用 Runnable 一定读取了数据。

场景三：CAN 总线正常，但系统一直不能进入 Full Communication？

回答：

我会先检查应用是否向 ComM 提出了 Full Communication 请求，以及是否存在通信抑制条件。

然后检查 CanSM 控制器状态、收发器工作模式、ComM 和 CanSM 的模式切换，以及 CanNm 网络管理相关配置。

同时检查 BswM 模式仲裁条件，确认是否执行了需要的通信使能动作。

最后结合各模块状态和配置日志确定是哪一层阻止了通信模式切换。

场景四：同一个 AUTOSAR 应用想从 STM32 移植到 NXP，哪些模块需要修改？

回答：

首先需要更换或适配新的 MCU MCAL 驱动，包括 Mcu、Port、Dio、Can、Spi 等相关模块。

同时需要调整 ECU 硬件相关配置、CAN 控制器资源、收发器接口、OS 相关配置和存储器布局。

如果 BSW 和应用 SWC 遵循标准接口，并且没有直接依赖特定 MCU 硬件，应用业务逻辑理论上可以较大程度复用。

但具体移植还涉及供应商 BSW 版本、工具链、编译器、驱动能力和实际硬件差异，不能认为完全不需要修改应用。5