联合汽车电子嵌入式软件二面：项目闭环、方案取舍与功能安全

《面试题目》

1. 把你研究生最核心的项目，按「需求—架构—你负责的模块—验证闭环」讲一遍，中间卡过什么？
2. 如果当时必须在「更高性能方案」和「更易量产标定方案」里二选一，你会怎么论证？
3. 电驱里开环弱磁/开环拖动和电流闭环，分别解决什么问题？什么阶段必须切闭环？
4. ASPICE 里你理解的「需求可追溯」在日常开发中长什么样？和只写代码有什么差别？
5. 举一个转矩相关的功能安全场景：危险是什么，你用哪些机制把风险压下去？

《参考解析》

项目讲述要有「对象与指标」，而不是模块名堆砌。 先用一句话说清控制对象、实时周期、精度与安全约束（控制什么电机/执行器、PWM 频率、电流环周期、稳态误差要求），再按数据流讲架构：传感采样 → 坐标变换/状态机 → 控制算法 → 执行器或总线输出 → 故障检测与降级。然后明确个人边界：哪些驱动、算法、联调、文档是自己闭环的，哪些是协作。卡点要具体且带根因定位过程，比如「电流采样窗口不够导致低占空比时采到开关噪声，用示波器同时看 PWM 与 ADC 触发，改成中点触发并加最小脉宽限制」。验证闭环要对应指标：阶跃响应、稳态误差、故障注入、温升/耐久，而不是「最后跑通了」。收尾给一句可复用的工程结论，体现复盘能力。

性能方案 vs 量产方案的论证。 先列约束：样件数量、标定人力、传感器成本、EMC/温度边界、交付节点、产线节拍。再把两个方案的收益与代价量化：高性能方案能带来多少收敛时间/效率提升，失败模式是什么；量产友好方案的性能损失是否仍满足需求，标定参数从多少个降到多少个，产线需要增加哪道工序。用可测数据对比（阶跃超调、调节时间、故障率、参数敏感度），而不是「更先进」。决策原则是先保安全与可重复性，再在裕量内抠性能；关键参数可以分期导入（先固定保守值，后续 OTA/标定放开）。最后承认取舍代价，比如多一次产线零点标定、或牺牲极端工况下的峰值效率——能说清代价，才说明你真的做过工程判断。

开环与闭环的分工。 开环拖动（I/F 或电压频率给定）靠给定频率/电压建立旋转磁场，实现简单、不依赖位置传感器，但對负载突变和参数偏差敏感，容易失步，适合起动初期（反电势小、位置不可信）或传感器故障后的跛行。电流闭环用反馈把 Id/Iq 拉到指令，抑制扰动，是稳态出力、效率和转矩精度的基础。切换时机：位置锁定、电流可观测、观测器收敛之后尽快切闭环；切换过程要做指令平滑与状态机过渡，硬切会引起电流冲击或转矩台阶。要补一句「闭环也依赖传感器质量」：编码器/旋变异常时要能检测并降级到无位置控制或安全停机，而不是假装仍高精度闭环。面试官想听的是「工况分段 + 切换条件 + 保护」，不是定义背诵。

ASPICE 的需求可追溯。 核心是「需求、设计、实现、测试之间有双向链接，变更可评估影响」。日常形态：客户/系统需求 → 软件需求 → 架构与单元设计 → 测试用例与结果，每一层用唯一 ID 串起来；改一个信号、诊断策略或标定参数时，能顺着链接找到受影响的模块、接口、测试集，而不是靠记忆。和「只写代码」的差别在于：先定义验收准则再编码；缺陷要回到需求/设计层定性（是需求漏了、设计错了，还是实现错了）；变更要走影响分析、评审、基线。AUTOSAR 配置、标定参数、诊断服务也应纳入基线，避免「板子上改过但文档对不上」。校招不必吹自己做过完整 ASPICE 评估，但要能讲清你如何写接口说明、维护用例、闭环问题单。

转矩功能安全场景。 危险示例：角度错误、电流环失控或转矩指令被篡改，导致非预期转矩（车辆意外加速/制动），可能影响纵向安全。控制措施分三层：输入合理性（电流、角度、母线电压的范围与突变检查，传感器冗余/交叉校验）；控制侧（转矩限幅、变化率限制、监控器独立计算转矩并与主路径比对）；执行侧（安全关断路径、主动短路/放电、禁驱）。诊断要有确认时间与防抖，避免毛刺误报；一旦确认，按 ASIL 进入安全状态（限扭、降级、停机）。独立监控是关键：主路径和监控路径用不同的实现/不同的传感器，避免共因失效。还要讲验证：故障注入（拔传感器、注入错误角度、篡改 CAN 报文）、HIL 测试、以及 FMEA 分析。回答时把「危险—措施—验证」串成闭环，比罗列名词更有说服力。