第 2 套：VCU / MCU / OBC / DCDC 三电功能测试高频面试题
适用方向：VCU HIL 测试、三电功能测试、电机控制器测试、OBC/DCDC 测试、整车充电测试。
难度定位：中级车辆测试工程师。
使用建议：回答重点放在“谁提出请求、谁执行、谁限制、我怎么用数据排查”，具体时序和阈值以项目需求为准。
1. VCU HIL 测试环境一般由哪些部分组成？
参考回答：
我会把 VCU HIL 理解成“真实 VCU + 虚拟整车环境”。VCU 本身是真实控制器，HIL 实时机去跑整车、电池、电机、驾驶员、道路这些模型；IO 板卡负责模拟和采集硬线信号，比如电压、电流、数字量、PWM、频率、电阻。
另外还需要 CAN、CAN FD、LIN 或以太网这些通信环境，用 CANoe 或仿真节点去模拟 BMS、MCU、仪表、网关等其他控制器。台架上通常也会有负载模拟、信号调理和故障注入，用来做开路、短地、短电源、通信异常等场景。
我实际测试时，会先做 IO 和通信冒烟，确认 VCU 看到的输入是真实有效的，再开始测上下电、Ready、扭矩、充电和故障降级。HIL 的优势是能比较早、比较安全地把边界和故障场景跑起来。
2. 如果让你从零搭建 VCU HIL 测试，你需要哪些文档和输入？
参考回答：
我不会直接开始接线，先把输入资料要全。最核心的是 VCU 功能需求，里面要明确 Ready、上下电、扭矩、制动、充电、降级这些状态机逻辑。
第二类是接口资料：ICD、引脚定义、电气原理图、线束图，这些决定台架怎么接、IO 怎么映射。第三类是通信和诊断资料，比如 DBC、通信矩阵、UDS 和 DTC 规范。还要有标定说明、测试验收标准、模型需求和版本基线，不然即使台架跑起来，也没法判断结果对不对。
我的搭建顺序一般是：先理解需求和接口，再做接线与通道映射；然后配置 DBC、仿真节点和模型；之后做 IO、通信、诊断冒烟；最后才开始按需求开发和执行用例。中间每一步都要做好版本记录，避免软件、DBC、模型版本混乱。
3. VCU、BMS、MCU 在高压上电和 Ready 过程中有哪些关键交互？如果 Ready 失败怎么排查？
参考回答：
典型情况下，VCU 先收驾驶员输入，比如钥匙、制动、挡位和启动请求，然后判断整车是否具备 Ready 条件。满足条件后，VCU 会请求 BMS 高压上电；BMS 检查电池状态、HVIL、绝缘和继电器条件，完成预充后，把高压状态、允许放电功率等反馈给 VCU。
接着 VCU 会确认 MCU 是否使能成功、有没有严重故障，条件都满足后才进入 Ready。OBC 通常更多和充电状态、插枪互锁或充电相关条件有关，不一定是每个驱动 Ready 流程里的固定主节点，具体还是看项目架构。
如果 Ready 失败，我会先看 Ready 条件表，而不是盲目抓全网报文：驾驶员输入对不对、挡位和制动是否满足、BMS 是否高压上电并允许放电、MCU 是否使能且无故障、有没有碰撞、插枪、HVIL、通信超时这些禁止条件。最后用 Trace、DTC 和状态机变量定位到底卡在哪一项，再判断是信号输入、通信、控制逻辑还是 HIL 映射问题。
4. MCU 扭矩控制测试关注哪些指标？
参考回答：
我会先区分两件事：在 HIL 上，主要验证扭矩请求、状态机、限扭逻辑和信号链路；如果要验证真实扭矩精度、动态性能和热能力，通常还要上电机测功机台架。
在功能测试里，我主要看 VCU 请求扭矩后，MCU 有没有正确响应，响应时间是否满足需求，稳态时目标扭矩和实际扭矩偏差多大，有没有明显超调。还要看阶跃、斜坡、驱动和能量回收切换时的跟随性。
另外限扭一定要测，比如高温、低 SOC、低母线电压、故障状态下，MCU 是不是按策略限扭；扭矩方向对不对；传感器、电压或温度异常时有没有进入正确降级。
我会把目标扭矩、实际扭矩、转速、电流、限扭原因、故障状态画在同一条曲线上看，这样比较容易判断是请求有问题，还是 MCU 自己限制了输出。
5. VCU 下发扭矩指令后 MCU 没有响应，你会怎么排查？
参考回答：
我会顺着信号链路查，不会直接说 MCU 有 Bug。
先确认 VCU 有没有真的发出扭矩请求：看报文周期、目标值、有效位、滚动计数和校验。然后看 MCU 有没有收到，DBC 解析对不对，报文有没有超时或总线错误。
如果通信没问题，我再看使能条件：高压有没有上来、Ready 是否有效、挡位和制动是否满足、急停或碰撞有没有触发。接着看 BMS 有没有把放电允许功率限制到 0，MCU 自己有没有过温、过压、旋变等 DTC。
如果请求到了、条件也满足，但实际扭矩还是 0，就看扭矩仲裁和限扭原因。最后再检查 HIL 模型给的转速、电压、使能和 CAN 通道是不是正确。这样能用数据回答：是没发出、没收到、条件不满足，还是被谁限制掉了。
6. 交流充电 CC/CP 握手流程是怎样的？
参考回答：
这个要先说明，我下面讲的是常见交流充电控制导引逻辑，具体电平和细节要按采用的接口标准和项目实现确认。
一般来说，未插枪时 CP 处在未连接状态；插枪后，车辆和桩通过连接检测确认枪线和连接状态。充电桩在 CP 上提供 PWM，PWM 的占空比代表桩侧可提供的最大电流能力。车辆准备好充电后，OBC 再根据 BMS 给出的目标电压、目标电流，以及桩端能力开始工作。
充电过程中，BMS 决定电池当前允许充多少，OBC 负责在自身能力和桩端限制内跟随这个请求。所以我测试时会同时看 CP/PWM、BMS 的充电允许和目标电流电压、OBC 的实际输出、温度和故障状态。
不能只看到桩给了较大电流就认为车一定会按这个电流充，最终还受 BMS、OBC、温度和故障策略影响。
7. 充电后期最高单体已经接近上限，但充电电流仍未按策略下降，你如何定位？
参考回答：
我先确认前提是不是成立：最高单体电压是否真的接近需求或标定上限，采样值有没有问题，温度和压差是不是也在策略关注范围内。不能只看 SOC 到了多少，因为恒流转恒压或者降流通常更依赖最高单体电压、温度和 BMS 充电策略。
接着看 BMS 有没有下调目标充电电流或者改变目标电压。如果 BMS 已经降流，但 OBC 实际输出没有跟下来，我会重点查 OBC 的跟随逻辑、报文有效性、通信超时和 OBC 自身状态。
如果 BMS 根本没有降流，就回到 BMS 侧查：单体采样、温度、SOC 校正、压差、策略状态机和标定版本。与此同时也要看桩端能力和接口侧限制，防止把桩端现象误认为车端问题。
最后我会把最高单体电压、BMS 请求电流、OBC 实际电流、温度、DTC 和时间趋势放在一起，明确结论到底是采样、策略、通信、OBC 跟随还是桩端问题。
8. DCDC 功能测试应该覆盖哪些点？
参考回答：
DCDC 就是把高压电变成低压电，给 12V 或 24V 系统供电，同时给低压蓄电池充电。
我会先测使能逻辑：高压状态和 VCU/BMS 使能满足时，DCDC 能不能正常启动。正常工作时，看输出电压是否落在需求定义的目标范围内，负载变化时有没有明显过冲或掉压，输出电流能力够不够。
然后要测保护和恢复，包括高压输入异常、低压过压欠压、过流、短路、过温、通信超时。还要看状态报文、故障码和恢复逻辑：故障消失后是自动恢复、重新上电恢复，还是要清故障。
如果输出异常，我会先查高压输入和使能，再看低压负载和保护状态，然后看通信和实际测量值。像 13.5V、14V 这类数值只能举例，实际要以低压电气需求和标定为准。
9. OBC 如何根据 BMS 指令调节输出？测试时看哪些信号？
参考回答：
可以简单理解成：BMS 决定电池现在“允许充多少”，OBC 负责把交流电转换成满足这个请求的直流输出。
BMS 会根据最高单体电压、总压、温度、SOC、故障和电池能力，计算允许充电电压、允许充电电流和充电允许状态，通过 CAN 发给 OBC。OBC 同时还要考虑桩端能力、自身温度和故障状态，最后输出实际电压电流。
我测试时会把 BMS 的请求电压/电流、充电允许标志、最高单体电压和温度，和 OBC 的实际输出、状态机、降额原因、故障码放在一起看。重点验证 OBC 有没有正确跟随、降流是否及时、故障时能不能安全停充。
在 HIL 上可以把请求、报文和状态机链路测得比较充分；但输出纹波、效率、长时间满载温升这类真实电气性能，还要结合 OBC 实物性能台架验证。
10. 直流充电功率突然下降，你会怎么分析？
参考回答：
我先分清楚功率为什么下降：是电压掉了、电流掉了，还是两者一起掉。通常功率下降更多是电流被限制，所以我会先看 BMS 的目标充电电流有没有主动降低。
如果 BMS 降流了，就继续找限制原因：最高单体接近上限、温度过高或过低、温差过大、绝缘/HVIL/DTC、冷却能力不足，还是通信超时。如果 BMS 没降流，但桩端或实际输出降了，就查桩端限流、充电协议、通信和兼容性。
我还会看冷却链路，比如水泵、风扇、阀、压缩机的请求和反馈是不是正常，因为热管理问题也可能让 BMS 主动降流。
最后用趋势数据把 BMS 请求、桩端能力、实际电流电压、单体电压、温度、DTC 放到同一时间轴上，这样才能判断功率下降到底是车端主动策略、OBC/通信问题，还是桩端限制。