简介面向电动汽车及新能源汽车领域功能安全工程师、电控系统开发者的一份专业技术文献聚焦PCU动力控制单元系统从概念到验证的功能安全正向开发流程。内容以某款插电式混合动力车型搭载的PCU系统为案例系统阐述相关项定义、边界与接口、危害分析和风险评估、安全目标、功能安全要求与技术安全要求并针对V模型开发右侧环节详细展示故障注入测试的设计与实施示例为整车及零部件层级的功能安全开发提供方法论参考。包内为单个PDF文件大小1.45MB属于文献类学习材料可作为功能安全开发、测试验证及ISO 26262标准理解的配套阅读资料。目前已有174人学习下载适合需要系统建立PCU功能安全完整开发框架的工程师快速获取核心要点。1. PCU功能安全真正难的不是标准是让每个故障都有落点做电驱动功能安全的人都有个共识ISO 26262 的流程文档好写难的是把 ASIL 等级拆到每一帧 CAN 报文、每一个 PWM 通道、每一颗芯片引脚上。PCUPower Control Unit作为整车扭矩输出的最后执行层集成了逆变器、BOOST/OBC、电机控制器和发电机控制器任何一个环节出现系统性失效或随机硬件失效都可能让电机输出非预期扭矩后果直接对应到整车的加速、制动和转向安全。这篇博文基于一篇实际的 PCU 功能安全开发论文完整拆解 V 模型左侧的安全目标推导——从相关项定义、HARA 分析到 FSR/TSR 落地以及右侧故障注入测试的工程实现路径。适合正在做电控系统功能安全正向开发的工程师也适合想搞懂 ASIL 等级到底怎么分配、E2E 保护机制怎么验证的测试人员。2. 相关项定义与 HARA把非预期扭矩拆成可分配的安全目标2.1 相关项边界PCU 里每一块电路板的职责概念阶段的起点是相关项定义Item Definition。论文分析的是一台紧凑型插电式混合动力汽车的电驱动系统PCU 作为相关项的核心控制器边界范围覆盖了 BOOST/OBC 高压变换器、逆变器、驱动电机E-Motor和发电机G-Motor。硬件架构上采用双芯片方案TI TMS570LS1115 作为安全监控芯片负责通信监控、E2E 校验和安全状态仲裁TMS320F28379D 作为控制芯片实现电动机、发电机、BOOST/OBC 的具体控制算法。这项定义工作看似只是画框图实际上决定了后续所有安全要求的分配粒度。我一般会要求硬件工程师在相关项定义阶段就给出芯片级接口清单特别是安全监控芯片与控制芯片之间的交互通道。论文里 TMS570 与 F28379D 的分工很典型监控芯片不参与扭矩控制环路只做监督仲裁——这符合 ISO 26262 中关于独立性Freedom from Interference的要求。如果监控芯片和控制芯片共用同一片电源或同一个晶振就要在后续分析中额外考虑共因失效。PCU 的典型功能列表需要覆盖所有运行模式。论文中给出了六类功能其中有三类容易被忽略功能名称目的关键运行模式电力驱动响应扭矩请求输出驱动力矩电动模式发电机械能转电能通过 BMS 为电池充电发电模式跛行故障状态下降额运行支持车辆跛行降额模式放电响应主动/被动放电请求高压侧能量释放到安全状态放电模式坡道辅助驻车和起步时防止反向溜车溜车距离10cm驻车模式交流充电220V 交流电转为高压直流电充电模式注意跛行和放电这两个功能往往在概念阶段被当成次要功能但实际上它们本身就是安全机制的一部分需要在 HARA 中单独评估——降额策略如果设计不当可能从安全降额变成新的危害。2.2 HAZOP 与 HARA 的组合从功能异常到 ASIL 等级危害分析和风险评估的核心方法是 HAZOPHazard and Operability Analysis对输出驱动扭矩这项功能用引导词Guide Word体系识别功能异常表现引导词功能异常表现功能丧失有需求时不能输出驱动扭矩提供错误的功能实际输出扭矩大于/小于期望值非预期功能无需求时输出驱动扭矩输出卡滞扭矩输出量无法更新方向错误扭矩输出方向与期望值反向这六类异常每一条都要映射到整车层面的危害事件。论文给出的例子非常典型非预期输出驱动扭矩运行场景为新车起步或拥堵路况变道时高车速过弯道最终危害事件是与侧方车辆碰撞严重度 S3、暴露概率 E4、可控性 C2组合结果为 ASIL C。这里有一个工程上容易出错的地方S、E、C 三个参数的确定不能完全靠主观判断ISO 26262-3 提供了量化参考表但实际企业做 HARA 时通常依赖内部的事故统计数据加上对标数据库。论文中暴露概率取 E4 的依据是该场景在总运行时间中的占比小于 10%这个数据需要从整车实际运行工况中采集而不是从实验室工况里取。我见过不少项目在 HARA 阶段把暴露概率估低导致 ASIL 等级降级后期在功能安全审计时被 challenge 甚至返工。2.3 安全目标的确定注意 SG3 和 SG4 的差异每个危害事件需要对应一个安全目标Safety Goal安全目标必须描述到可以用安全状态故障容错时间间隔FTTI来验证的粒度。论文中列举了四个安全目标序号安全目标安全状态ASILFTTISG1防止电机非预期输出驱动扭矩输出扭矩不应超过需求扭矩 20N发出警示终止扭矩输出可进入主动短路模式ASC或滑行模式FreewheelingC400msSG2防止电机非预期输出反向扭矩发出警示终止扭矩输出可进入 ASC 或 FreewheelingC400msSG3系统放电时应避免非预期的高压直流电压超过 60V超过 60V 时发出警告信号避免人员靠近高压系统A3sSG4系统应避免非预期的高温保持电机温度 160℃ 以下IGBT 和 PCBA 温度 100℃ 以下B-注意 SG3 的 FTTI 是 3 秒而 SG1/SG2 只有 400ms——这个差异直接决定了安全机制实现方案。高压放电保护可以通过硬件比较器独立触发因为 60V 的阈值判定不需要复杂的算法而扭矩监控必须在一个控制周期内完成通常需要 TMS570 在 10ms~20ms 的任务周期内连续检测多帧扭矩报文才能在 400ms 内完成仲裁并触发 ASC。SG4 的 ASIL B 等级则意味着温度监控可以通过软件诊断方式实现不需要独立的硬件安全路径这为后续 TSR 的制定留了余地。3. 从安全目标到 FSR/TSRV 模型左侧的层层细化3.1 FSR 的粒度CAN 通信相关功能安全要求的写法在安全目标确定之后需要为每个 SG 导出功能安全要求Functional Safety Requirement, FSR。FSR 的粒度是关键——写得太粗后续 TSR 无法落地写得太细又在系统层绑死了实现方案违背了FSR 应独立于实现的原则。论文中给出的 FSR 示例以 CAN 通信为主线FSR_01驱动控制系统应通过 CAN 总线建立通信接口QM——SG1、SG2FSR_02电驱动控制系统应通过 CAN 总线接收 VCU 发送的电动机和发电机的扭矩需求值ASIL C——SG1、SG2FSR_03电驱动控制系统应通过 CAN 总线向 VCU 持续发送电动机和发电机的实际扭矩值ASIL C——SG1、SG2FSR_04电驱动和发电功能运行时应避免输出扭矩非预期地超出需求扭矩超出阈值且持续超过时间阈值时系统应进入安全状态ASIL C——SG1FSR_05应对逆变器的 PWM 扭矩控制信号进行诊断根据故障相位数关断功率管ASIL C——SG1、SG2这个写法有一个值得学习的点FSR 中明确写了QM与ASIL C的混合分配。FSR_01 的通信接口建立本身是 QM但承载扭矩需求的通信内容必须达到 ASIL C。这意味着在系统设计时通信接口的底层驱动不需要按照 ASIL C 开发但报文内容的 E2E 保护必须按照 ASIL C 的度量要求来设计。这种 QM/ASIL 混合的做法在业内是允许的但前提是 QM 部分不能干扰 ASIL 部分的安全机制——比如 CAN 驱动发生故障时不能导致 E2E 校验失效。司是在做 FSR 评审时重点核对的就是这类降级是否合理。3.2 TSR 的落地TMS570 芯片层面的 E2E 校验设计从 FSR 到技术安全要求Technical Safety Requirement, TSR需要把系统应做什么翻译成芯片应做什么。论文中对应 FSR_02 的 TSR 示例有九条工程参考价值最高的是 E2E 保护部分TSR_02_01: 电驱动系统必须持续读取 CAN 信息中的扭矩需求 TSR_02_02: 电驱动系统必须验证 CAN 信息中的扭矩需求 TSR_02_03: TMS570 芯片必须对 CAN 接收报文进行 E2E 校验例如 CRC TSR_02_04: E2E 校验连续故障次数超过 10 次时TMS570 通过 CAN 上报 VCU控制电机进入安全状态 TSR_02_05: TMS570 芯片应检测 VCU 请求扭矩的范围 TSR_02_06: VCU 请求扭矩超过合理范围时TMS570 通过 CAN 上报 VCU控制电机进入安全状态 TSR_02_07: CAN 通信 E2E 校验故障恢复后电驱动系统应能恢复工作 TSR_02_08: 持续性 CAN 通信丢失达到故障允许阈值时间电驱动系统进入安全状态 TSR_02_09: 持续性 CAN 通信丢失小于故障允许阈值时间电驱动系统应能保持工作这组 TSR 有几处容易被低估的细节第一TSR_02_03 明确规定 E2E 校验由 TMS570 完成而不是由 F28379D 完成。这是独立性原则的体现——控制芯片负责扭矩计算监控芯片负责验证扭矩指令的完整性两者互不信任。如果 E2E 校验跑在控制芯片上一旦控制芯片软件逻辑出错校验也会跟着失效。第二TSR_02_04 引入了连续故障次数的概念这比单帧故障直接进安全状态更合理。CAN 通信受到电磁干扰时出现单帧 CRC 错误是正常现象如果因为一帧错误就切断扭矩整车的驾驶体验会非常差甚至引发新的危害——比如在高速超车时突然失去动力。连续 10 次故障作为一个阈值实际上是在容忍瞬态干扰和及时进入安全状态之间做平衡。这个 10 的取值不是拍脑袋定的需要结合 FTTI 反推假设每条 CAN 报文周期是 10ms10 次连续故障对应 100ms加上检测和仲裁时间仍然小于 SG1 的 400ms FTTI。第三TSR_02_07 和 TSR_02_09 要求系统在故障恢复后能自动恢复工作这是功能安全里容易被忽略的恢复路径。很多项目只关注进安全状态不关注从安全状态出来。如果故障恢复逻辑设计不当会出现两种问题要么系统永远卡在安全状态整车需要下电重启——这在实际行驶中是不可接受的要么恢复条件设置太宽松故障尚未完全消除就恢复输出导致反复震荡。3.3 需求分配要解决的两个问题完成了 FSR 和 TSR 之后还需要在系统架构层面做安全要求分配这里有两个核心问题需要解决第一个问题是安全机制的覆盖率。每个 FSR/TSR 都要有明确的实现载体硬件单元或软件模块并且这个载体要能证明自己具备处理该故障的能力。论文中以 CAN 通信故障为例FSR_02 对应的安全机制分布在 TMS570 的 CAN 外设、E2E 校验软件模块、ASC 触发逻辑三个位置三个位置的故障相互独立才能保证整车控制器和电机控制器之间的 CAN 传输发生故障时系统依然能通过 TMS570 内部的校验逻辑感知到通信异常。第二个问题是安全机制自身的失效模式。安全机制也是系统的一部分它自己也会出故障。TSR 中已经隐含了这个考量——TMS570 如果自身失效怎么办通常的方案是再增加一个硬件看门狗External Watchdog或者锁步核Lockstep Core来监控 TMS570 本身。但论文的方案里没有展开这部分实际做系统设计时这一块不能省可以在 FSR 层补充一条安全监控功能自身应具备失效检测能力然后再向下细化 TSR。4. 故障注入测试信号级 HIL 与功率级 PHIL 怎么选4.1 信号级 HIL 与功率级 PHIL 的边界V 模型右侧的验证和确认工作故障注入测试是最直接的手段。论文搭建了信号级 HIL 和功率级 PHIL 两套平台信号级 HIL 通过 USPACE 模拟逆变器、电机和机械执行部件整个模拟过程仅需上位机编程修改电机参数或被模拟部件的参数非常方便功率级 PHIL 则通过电机模拟器与 MCU 直接相连能够真实模拟电机绕组的电气特性。两套平台的选用逻辑是信号级 HIL 适合做功能安全需求的逻辑验证因为它的仿真模型参数可调可以快速覆盖大量的故障注入用例功率级 PHIL 适合做控制器的真实电气特性验证因为信号级 HIL 无法模拟功率器件在短路、过流等故障下的真实响应。论文中特别提到用功率级 HIL 做故障注入测试的最大优势是修改电机参数无需额外增加台架对比传统台架测试——换一个电机参数可能要重新定制台架夹具和传感器耗时数周而 PHIL 平台只需要修改上位机模型参数。工程中普遍的做法是先做信号级 HIL 的自动化回归测试把安全机制的逻辑功能验证透再针对高风险场景做功率级 PHIL 抽测。如果预算有限功率级 PHIL 至少要吃透三类场景IGBT 短路故障、电机定子绕组相间短路、以及旋变信号受到强电磁干扰时的解码行为——这三类故障在信号级 HIL 里很难真实模拟。4.2 故障注入列表设计与优先级故障注入不是随机乱打需要从底层故障模式和危害场景出发系统性地枚举。论文中给出了 MCU 和 OBC 两部分的常见故障类型按照故障注入测试类型进一步细化为七大类故障源类型故障注入示例验证目的解析器错误正/余弦信号注入噪音和电磁干扰旋变解码安全机制电机温度传感器信号中断温度采样断线诊断定子绕组模拟绕组电感错误电机参数辨识异常处理转子转子惯性误差过大转子位置估算精度轴承异常波动的扭矩注入机械故障导致扭矩波动控制器失效过压、欠压故障控制器电源异常保护在做故障注入测试用例设计时我一般会按照三个维度排列优先级一是该故障与安全目标的关联度比如涉及 SG1/SG2 的优先二是故障发生的概率参考市场售后数据和 FMEA 中的发生频度评级三是故障注入的难度简单易复现的先做复杂场景后做。论文中特别强调故障注入要根据底层故障模式和种类结合 HIL 台架完成故障注入评价安全机制和安全措施是否有效执行以及执行结果是否实现了功能安全要求。4.3 测试序列脚本示例故障注入测试的自动化程度直接影响测试效率。以下是一个典型的 CAN 总线故障注入测试脚本逻辑使用 Python 编写通过 HIL 台架的上位机接口控制 CAN 节点开关import can import time # 定义安全状态判定阈值 ASC_ACTIVE 0x01 # 主动短路模式标志位 FREEWHEEL_ACTIVE 0x02 # 滑行模式标志位 def can_fault_injection_test(bus_channel, fault_duration_ms, mode): CAN总线故障注入测试 mode: 0-短路, 1-断路, 2-CAN阻抗异常 # 打开CAN通信 bus can.interface.Bus(channelbus_channel, bustypepcan, bitrate500000) # 记录注入前的扭矩指令与实际扭矩 torque_cmd_before read_torque_command(bus) torque_actual_before read_actual_torque(bus) # 执行故障注入 if mode 0: inject_short_circuit(bus_channel) # 注入短路故障 elif mode 1: inject_open_circuit(bus_channel) # 注入断路故障 else: inject_impedance_anomaly(bus_channel) # 注入R/C阻抗异常 # 故障持续期间监控安全机制响应 fault_start time.time() safety_state 0 while (time.time() - fault_start) (fault_duration_ms / 1000.0): # 读取TMS570上报的安全状态标志 safety_state read_safety_state(bus) if safety_state ASC_ACTIVE or safety_state FREEWHEEL_ACTIVE: break time.sleep(0.005) # 5ms轮询周期 # 恢复CAN通信 remove_fault_injection(bus_channel) # 判断测试结果是否在FTTI400ms内进入安全状态 response_time (time.time() - fault_start) * 1000 if safety_state ! 0 and response_time 400: print(fPASS: 安全机制在{response_time:.0f}ms内触发进入ASC/Freewheeling模式) else: print(fFAIL: 安全机制未在400ms内触发响应时间{response_time:.0f}ms) # 验证故障恢复后系统能恢复零扭矩控制 time.sleep(1.0) torque_actual_after read_actual_torque(bus) if abs(torque_actual_after) 5: # 扭矩小于5Nm视为恢复零扭矩 print(PASS: 故障恢复后系统回到零扭矩控制模式) bus.shutdown()这段脚本的核心逻辑是注入故障之后以 5ms 周期轮询 TMS570 上报的安全状态标志位记录从故障注入到安全机制触发的时间间隔并对比 FTTI 要求400ms判断测试是否通过。脚本最后对故障恢复后的扭矩输出做了验证确保系统回到零扭矩控制而不是停留在 ASC 模式。这里有一个参数要注意轮询周期 5ms 不能太长否则会漏掉安全机制在 FTTI 内的高频状态变化也不能太短否则总线负载过高干扰被测试系统的正常运行。5ms 对 500kbps 的 CAN 总线是合理取值如果总线负载本身较高可以适当调整到 10ms。4.4 通信故障注入的台架实践论文中对 CAN 总线故障注入做了具体展开电机控制器通常放置在动力 CAN 网络中驾驶员的控制命令输出给整车控制器VCUVCU 经过策略执行后输出扭矩控制指令给电机控制器。如果 VCU 与电机控制器之间的 CAN 传输发生故障——例如 VCU CAN 总线受干扰、CAN 总线节点故障、或 CAN 总线的 R/C 阻抗变化过大——都可能影响信号传输的完整性导致电机控制器收不到扭矩指令进而可能造成整车危害。台架测试时故障注入的触发方式分为两种一种是通过特殊的硬件设备在线完成比如 CAN 总线故障注入仪可以在线切换短路、断路、C 型阻抗网络另一种是通过特殊软件程序在上位机侧完成比如通过 USPACE 上位机修改 CAN 控制器参数模拟总线关闭Bus-Off状态。论文中采用的方案是硬件故障注入为主——因为 CAN 短路和断路故障无法通过软件真实模拟只有硬件级别的故障注入才能验证控制器在物理层故障下的真实响应。5. E2E 连续故障判定与安全状态恢复验证5.1 连续 10 次的逻辑陷阱TSR_02_04 要求 E2E 校验连续故障次数超过 10 次才触发安全状态但连续的判定逻辑在嵌入式软件实现中有一些细节需要注意/* TMS570 E2E校验连续故障计数器实现 */ #define E2E_FAILURE_THRESHOLD 10 #define E2E_FAULT_RECOVERY_TIMEOUT 100 /* 故障恢复判定时间窗单位ms */ static uint8_t e2e_fail_cnt 0; static uint8_t e2e_pass_cnt 0; void E2E_MonitorTask_10ms(void) { uint8_t crc_ok CheckE2E_CRC(); /* 校验CRC字段 */ uint8_t timeout_ok CheckTimeout(); /* 校验报文超时 */ if (crc_ok timeout_ok) { /* 一帧通过恢复计数清零 */ if (e2e_fail_cnt 0) { e2e_fail_cnt--; } else { e2e_pass_cnt; } if (e2e_pass_cnt 5) { /* 连续5帧通过判定故障恢复 */ e2e_fail_cnt 0; e2e_pass_cnt 0; SetFaultStatus(E2E_FAULT_RECOVERED); } } else { /* 一帧失败连续故障计数递增 */ e2e_fail_cnt; e2e_pass_cnt 0; if (e2e_fail_cnt E2E_FAILURE_THRESHOLD) { SetFaultStatus(E2E_FAULT_ACTIVE); TriggerSafetyState(ASC_MODE); /* 进入主动短路模式 */ } } }这里的逻辑说明E2E 校验任务以 10ms 为周期执行每次执行时检查 CAN 报文的 CRC 字段和超时标志。当连续 10 帧100ms都校验失败时触发安全状态当连续 5 帧通过时判定故障恢复并清空故障计数。注意故障恢复的判定阈值5 帧与故障触发的阈值10 帧是不对称的——这种不对称是刻意设计的目的是防止系统在故障边缘状态下反复震荡。如果恢复阈值设得比触发阈值还低只要故障间歇性出现系统就会在进安全状态和出安全状态之间反复切换这在整车上是不可接受的。另一个工程细节是故障计数器的递减逻辑很多初学者把连续实现成只要有一帧成功就清零这也会出问题。真正的连续应该是一帧成功抵消一次计数而不是把之前积累的失败次数全部抹掉。论文中 TSR_02_04 的连续故障次数超过 10 次配合 TSR_02_09 的通信丢失小于故障允许阈值时间时系统应能保持工作实际上要求实现方必须明确什么算一次故障什么算一次恢复。5.2 故障恢复后的行为验证故障恢复验证是整个功能安全测试中最容易被跳过、也最容易出问题的环节。论文中的测试结果是在高速零扭矩控制状态下通信故障前一帧通信发生后触发安全机制控制进入 ASC 模式通信恢复后一帧通信后控制回到零扭矩控制模式。这个验证至少回答三个问题第一恢复时间是多久从通信恢复到系统退出 ASC 模式会经过E2E 连续 5 帧通过的判定加上安全状态仲裁逻辑的处理时间最终的恢复时间通常在 100ms 量级。这个时间不能太长否则驾驶员在故障恢复后会感到明显的动力中断也不能太短否则没有充分确认通信链路的稳定性。第二恢复过程中扭矩输出是否有跳变系统从 ASC 模式切回零扭矩控制模式时如果扭矩指令和实际电机转速之间有明显偏差会产生扭矩冲击。所以在台架测试中需要额外加一个观测点记录恢复模式切换时刻的电机力矩实测值确认没有超过预设的突变阈值。第三故障恢复后累计的相关故障计数是否需要通过诊断仪清除论文中没有展开但实际项目里ISO 26262 要求故障事件要记录在非易失性存储器中便于售后诊断和召回分析。这个故障记忆功能本身也需要测试——验证下电重启后故障码依然存在只有通过诊断仪手动清除才能复位。以上是从 V 模型左侧的需求开发到右侧的故障注入验证的完整闭环。整个过程中最值得留意的两个参数一个是安全目标的 FTTI 值400ms 或 3s另一个是 E2E 连续故障计数阈值10 次二者共同决定了整个安全机制在时间维度上是否满足要求——这个时间轴上的自洽性是功能安全开发中最容易在样件阶段暴露问题的环节。本文还有配套的精品资源点击获取 PCU功能安全正向开发：ASIL分解、E2E校验与故障注入测试实践
简介面向电动汽车及新能源汽车领域功能安全工程师、电控系统开发者的一份专业技术文献聚焦PCU动力控制单元系统从概念到验证的功能安全正向开发流程。内容以某款插电式混合动力车型搭载的PCU系统为案例系统阐述相关项定义、边界与接口、危害分析和风险评估、安全目标、功能安全要求与技术安全要求并针对V模型开发右侧环节详细展示故障注入测试的设计与实施示例为整车及零部件层级的功能安全开发提供方法论参考。包内为单个PDF文件大小1.45MB属于文献类学习材料可作为功能安全开发、测试验证及ISO 26262标准理解的配套阅读资料。目前已有174人学习下载适合需要系统建立PCU功能安全完整开发框架的工程师快速获取核心要点。1. PCU功能安全真正难的不是标准是让每个故障都有落点做电驱动功能安全的人都有个共识ISO 26262 的流程文档好写难的是把 ASIL 等级拆到每一帧 CAN 报文、每一个 PWM 通道、每一颗芯片引脚上。PCUPower Control Unit作为整车扭矩输出的最后执行层集成了逆变器、BOOST/OBC、电机控制器和发电机控制器任何一个环节出现系统性失效或随机硬件失效都可能让电机输出非预期扭矩后果直接对应到整车的加速、制动和转向安全。这篇博文基于一篇实际的 PCU 功能安全开发论文完整拆解 V 模型左侧的安全目标推导——从相关项定义、HARA 分析到 FSR/TSR 落地以及右侧故障注入测试的工程实现路径。适合正在做电控系统功能安全正向开发的工程师也适合想搞懂 ASIL 等级到底怎么分配、E2E 保护机制怎么验证的测试人员。2. 相关项定义与 HARA把非预期扭矩拆成可分配的安全目标2.1 相关项边界PCU 里每一块电路板的职责概念阶段的起点是相关项定义Item Definition。论文分析的是一台紧凑型插电式混合动力汽车的电驱动系统PCU 作为相关项的核心控制器边界范围覆盖了 BOOST/OBC 高压变换器、逆变器、驱动电机E-Motor和发电机G-Motor。硬件架构上采用双芯片方案TI TMS570LS1115 作为安全监控芯片负责通信监控、E2E 校验和安全状态仲裁TMS320F28379D 作为控制芯片实现电动机、发电机、BOOST/OBC 的具体控制算法。这项定义工作看似只是画框图实际上决定了后续所有安全要求的分配粒度。我一般会要求硬件工程师在相关项定义阶段就给出芯片级接口清单特别是安全监控芯片与控制芯片之间的交互通道。论文里 TMS570 与 F28379D 的分工很典型监控芯片不参与扭矩控制环路只做监督仲裁——这符合 ISO 26262 中关于独立性Freedom from Interference的要求。如果监控芯片和控制芯片共用同一片电源或同一个晶振就要在后续分析中额外考虑共因失效。PCU 的典型功能列表需要覆盖所有运行模式。论文中给出了六类功能其中有三类容易被忽略功能名称目的关键运行模式电力驱动响应扭矩请求输出驱动力矩电动模式发电机械能转电能通过 BMS 为电池充电发电模式跛行故障状态下降额运行支持车辆跛行降额模式放电响应主动/被动放电请求高压侧能量释放到安全状态放电模式坡道辅助驻车和起步时防止反向溜车溜车距离10cm驻车模式交流充电220V 交流电转为高压直流电充电模式注意跛行和放电这两个功能往往在概念阶段被当成次要功能但实际上它们本身就是安全机制的一部分需要在 HARA 中单独评估——降额策略如果设计不当可能从安全降额变成新的危害。2.2 HAZOP 与 HARA 的组合从功能异常到 ASIL 等级危害分析和风险评估的核心方法是 HAZOPHazard and Operability Analysis对输出驱动扭矩这项功能用引导词Guide Word体系识别功能异常表现引导词功能异常表现功能丧失有需求时不能输出驱动扭矩提供错误的功能实际输出扭矩大于/小于期望值非预期功能无需求时输出驱动扭矩输出卡滞扭矩输出量无法更新方向错误扭矩输出方向与期望值反向这六类异常每一条都要映射到整车层面的危害事件。论文给出的例子非常典型非预期输出驱动扭矩运行场景为新车起步或拥堵路况变道时高车速过弯道最终危害事件是与侧方车辆碰撞严重度 S3、暴露概率 E4、可控性 C2组合结果为 ASIL C。这里有一个工程上容易出错的地方S、E、C 三个参数的确定不能完全靠主观判断ISO 26262-3 提供了量化参考表但实际企业做 HARA 时通常依赖内部的事故统计数据加上对标数据库。论文中暴露概率取 E4 的依据是该场景在总运行时间中的占比小于 10%这个数据需要从整车实际运行工况中采集而不是从实验室工况里取。我见过不少项目在 HARA 阶段把暴露概率估低导致 ASIL 等级降级后期在功能安全审计时被 challenge 甚至返工。2.3 安全目标的确定注意 SG3 和 SG4 的差异每个危害事件需要对应一个安全目标Safety Goal安全目标必须描述到可以用安全状态故障容错时间间隔FTTI来验证的粒度。论文中列举了四个安全目标序号安全目标安全状态ASILFTTISG1防止电机非预期输出驱动扭矩输出扭矩不应超过需求扭矩 20N发出警示终止扭矩输出可进入主动短路模式ASC或滑行模式FreewheelingC400msSG2防止电机非预期输出反向扭矩发出警示终止扭矩输出可进入 ASC 或 FreewheelingC400msSG3系统放电时应避免非预期的高压直流电压超过 60V超过 60V 时发出警告信号避免人员靠近高压系统A3sSG4系统应避免非预期的高温保持电机温度 160℃ 以下IGBT 和 PCBA 温度 100℃ 以下B-注意 SG3 的 FTTI 是 3 秒而 SG1/SG2 只有 400ms——这个差异直接决定了安全机制实现方案。高压放电保护可以通过硬件比较器独立触发因为 60V 的阈值判定不需要复杂的算法而扭矩监控必须在一个控制周期内完成通常需要 TMS570 在 10ms~20ms 的任务周期内连续检测多帧扭矩报文才能在 400ms 内完成仲裁并触发 ASC。SG4 的 ASIL B 等级则意味着温度监控可以通过软件诊断方式实现不需要独立的硬件安全路径这为后续 TSR 的制定留了余地。3. 从安全目标到 FSR/TSRV 模型左侧的层层细化3.1 FSR 的粒度CAN 通信相关功能安全要求的写法在安全目标确定之后需要为每个 SG 导出功能安全要求Functional Safety Requirement, FSR。FSR 的粒度是关键——写得太粗后续 TSR 无法落地写得太细又在系统层绑死了实现方案违背了FSR 应独立于实现的原则。论文中给出的 FSR 示例以 CAN 通信为主线FSR_01驱动控制系统应通过 CAN 总线建立通信接口QM——SG1、SG2FSR_02电驱动控制系统应通过 CAN 总线接收 VCU 发送的电动机和发电机的扭矩需求值ASIL C——SG1、SG2FSR_03电驱动控制系统应通过 CAN 总线向 VCU 持续发送电动机和发电机的实际扭矩值ASIL C——SG1、SG2FSR_04电驱动和发电功能运行时应避免输出扭矩非预期地超出需求扭矩超出阈值且持续超过时间阈值时系统应进入安全状态ASIL C——SG1FSR_05应对逆变器的 PWM 扭矩控制信号进行诊断根据故障相位数关断功率管ASIL C——SG1、SG2这个写法有一个值得学习的点FSR 中明确写了QM与ASIL C的混合分配。FSR_01 的通信接口建立本身是 QM但承载扭矩需求的通信内容必须达到 ASIL C。这意味着在系统设计时通信接口的底层驱动不需要按照 ASIL C 开发但报文内容的 E2E 保护必须按照 ASIL C 的度量要求来设计。这种 QM/ASIL 混合的做法在业内是允许的但前提是 QM 部分不能干扰 ASIL 部分的安全机制——比如 CAN 驱动发生故障时不能导致 E2E 校验失效。司是在做 FSR 评审时重点核对的就是这类降级是否合理。3.2 TSR 的落地TMS570 芯片层面的 E2E 校验设计从 FSR 到技术安全要求Technical Safety Requirement, TSR需要把系统应做什么翻译成芯片应做什么。论文中对应 FSR_02 的 TSR 示例有九条工程参考价值最高的是 E2E 保护部分TSR_02_01: 电驱动系统必须持续读取 CAN 信息中的扭矩需求 TSR_02_02: 电驱动系统必须验证 CAN 信息中的扭矩需求 TSR_02_03: TMS570 芯片必须对 CAN 接收报文进行 E2E 校验例如 CRC TSR_02_04: E2E 校验连续故障次数超过 10 次时TMS570 通过 CAN 上报 VCU控制电机进入安全状态 TSR_02_05: TMS570 芯片应检测 VCU 请求扭矩的范围 TSR_02_06: VCU 请求扭矩超过合理范围时TMS570 通过 CAN 上报 VCU控制电机进入安全状态 TSR_02_07: CAN 通信 E2E 校验故障恢复后电驱动系统应能恢复工作 TSR_02_08: 持续性 CAN 通信丢失达到故障允许阈值时间电驱动系统进入安全状态 TSR_02_09: 持续性 CAN 通信丢失小于故障允许阈值时间电驱动系统应能保持工作这组 TSR 有几处容易被低估的细节第一TSR_02_03 明确规定 E2E 校验由 TMS570 完成而不是由 F28379D 完成。这是独立性原则的体现——控制芯片负责扭矩计算监控芯片负责验证扭矩指令的完整性两者互不信任。如果 E2E 校验跑在控制芯片上一旦控制芯片软件逻辑出错校验也会跟着失效。第二TSR_02_04 引入了连续故障次数的概念这比单帧故障直接进安全状态更合理。CAN 通信受到电磁干扰时出现单帧 CRC 错误是正常现象如果因为一帧错误就切断扭矩整车的驾驶体验会非常差甚至引发新的危害——比如在高速超车时突然失去动力。连续 10 次故障作为一个阈值实际上是在容忍瞬态干扰和及时进入安全状态之间做平衡。这个 10 的取值不是拍脑袋定的需要结合 FTTI 反推假设每条 CAN 报文周期是 10ms10 次连续故障对应 100ms加上检测和仲裁时间仍然小于 SG1 的 400ms FTTI。第三TSR_02_07 和 TSR_02_09 要求系统在故障恢复后能自动恢复工作这是功能安全里容易被忽略的恢复路径。很多项目只关注进安全状态不关注从安全状态出来。如果故障恢复逻辑设计不当会出现两种问题要么系统永远卡在安全状态整车需要下电重启——这在实际行驶中是不可接受的要么恢复条件设置太宽松故障尚未完全消除就恢复输出导致反复震荡。3.3 需求分配要解决的两个问题完成了 FSR 和 TSR 之后还需要在系统架构层面做安全要求分配这里有两个核心问题需要解决第一个问题是安全机制的覆盖率。每个 FSR/TSR 都要有明确的实现载体硬件单元或软件模块并且这个载体要能证明自己具备处理该故障的能力。论文中以 CAN 通信故障为例FSR_02 对应的安全机制分布在 TMS570 的 CAN 外设、E2E 校验软件模块、ASC 触发逻辑三个位置三个位置的故障相互独立才能保证整车控制器和电机控制器之间的 CAN 传输发生故障时系统依然能通过 TMS570 内部的校验逻辑感知到通信异常。第二个问题是安全机制自身的失效模式。安全机制也是系统的一部分它自己也会出故障。TSR 中已经隐含了这个考量——TMS570 如果自身失效怎么办通常的方案是再增加一个硬件看门狗External Watchdog或者锁步核Lockstep Core来监控 TMS570 本身。但论文的方案里没有展开这部分实际做系统设计时这一块不能省可以在 FSR 层补充一条安全监控功能自身应具备失效检测能力然后再向下细化 TSR。4. 故障注入测试信号级 HIL 与功率级 PHIL 怎么选4.1 信号级 HIL 与功率级 PHIL 的边界V 模型右侧的验证和确认工作故障注入测试是最直接的手段。论文搭建了信号级 HIL 和功率级 PHIL 两套平台信号级 HIL 通过 USPACE 模拟逆变器、电机和机械执行部件整个模拟过程仅需上位机编程修改电机参数或被模拟部件的参数非常方便功率级 PHIL 则通过电机模拟器与 MCU 直接相连能够真实模拟电机绕组的电气特性。两套平台的选用逻辑是信号级 HIL 适合做功能安全需求的逻辑验证因为它的仿真模型参数可调可以快速覆盖大量的故障注入用例功率级 PHIL 适合做控制器的真实电气特性验证因为信号级 HIL 无法模拟功率器件在短路、过流等故障下的真实响应。论文中特别提到用功率级 HIL 做故障注入测试的最大优势是修改电机参数无需额外增加台架对比传统台架测试——换一个电机参数可能要重新定制台架夹具和传感器耗时数周而 PHIL 平台只需要修改上位机模型参数。工程中普遍的做法是先做信号级 HIL 的自动化回归测试把安全机制的逻辑功能验证透再针对高风险场景做功率级 PHIL 抽测。如果预算有限功率级 PHIL 至少要吃透三类场景IGBT 短路故障、电机定子绕组相间短路、以及旋变信号受到强电磁干扰时的解码行为——这三类故障在信号级 HIL 里很难真实模拟。4.2 故障注入列表设计与优先级故障注入不是随机乱打需要从底层故障模式和危害场景出发系统性地枚举。论文中给出了 MCU 和 OBC 两部分的常见故障类型按照故障注入测试类型进一步细化为七大类故障源类型故障注入示例验证目的解析器错误正/余弦信号注入噪音和电磁干扰旋变解码安全机制电机温度传感器信号中断温度采样断线诊断定子绕组模拟绕组电感错误电机参数辨识异常处理转子转子惯性误差过大转子位置估算精度轴承异常波动的扭矩注入机械故障导致扭矩波动控制器失效过压、欠压故障控制器电源异常保护在做故障注入测试用例设计时我一般会按照三个维度排列优先级一是该故障与安全目标的关联度比如涉及 SG1/SG2 的优先二是故障发生的概率参考市场售后数据和 FMEA 中的发生频度评级三是故障注入的难度简单易复现的先做复杂场景后做。论文中特别强调故障注入要根据底层故障模式和种类结合 HIL 台架完成故障注入评价安全机制和安全措施是否有效执行以及执行结果是否实现了功能安全要求。4.3 测试序列脚本示例故障注入测试的自动化程度直接影响测试效率。以下是一个典型的 CAN 总线故障注入测试脚本逻辑使用 Python 编写通过 HIL 台架的上位机接口控制 CAN 节点开关import can import time # 定义安全状态判定阈值 ASC_ACTIVE 0x01 # 主动短路模式标志位 FREEWHEEL_ACTIVE 0x02 # 滑行模式标志位 def can_fault_injection_test(bus_channel, fault_duration_ms, mode): CAN总线故障注入测试 mode: 0-短路, 1-断路, 2-CAN阻抗异常 # 打开CAN通信 bus can.interface.Bus(channelbus_channel, bustypepcan, bitrate500000) # 记录注入前的扭矩指令与实际扭矩 torque_cmd_before read_torque_command(bus) torque_actual_before read_actual_torque(bus) # 执行故障注入 if mode 0: inject_short_circuit(bus_channel) # 注入短路故障 elif mode 1: inject_open_circuit(bus_channel) # 注入断路故障 else: inject_impedance_anomaly(bus_channel) # 注入R/C阻抗异常 # 故障持续期间监控安全机制响应 fault_start time.time() safety_state 0 while (time.time() - fault_start) (fault_duration_ms / 1000.0): # 读取TMS570上报的安全状态标志 safety_state read_safety_state(bus) if safety_state ASC_ACTIVE or safety_state FREEWHEEL_ACTIVE: break time.sleep(0.005) # 5ms轮询周期 # 恢复CAN通信 remove_fault_injection(bus_channel) # 判断测试结果是否在FTTI400ms内进入安全状态 response_time (time.time() - fault_start) * 1000 if safety_state ! 0 and response_time 400: print(fPASS: 安全机制在{response_time:.0f}ms内触发进入ASC/Freewheeling模式) else: print(fFAIL: 安全机制未在400ms内触发响应时间{response_time:.0f}ms) # 验证故障恢复后系统能恢复零扭矩控制 time.sleep(1.0) torque_actual_after read_actual_torque(bus) if abs(torque_actual_after) 5: # 扭矩小于5Nm视为恢复零扭矩 print(PASS: 故障恢复后系统回到零扭矩控制模式) bus.shutdown()这段脚本的核心逻辑是注入故障之后以 5ms 周期轮询 TMS570 上报的安全状态标志位记录从故障注入到安全机制触发的时间间隔并对比 FTTI 要求400ms判断测试是否通过。脚本最后对故障恢复后的扭矩输出做了验证确保系统回到零扭矩控制而不是停留在 ASC 模式。这里有一个参数要注意轮询周期 5ms 不能太长否则会漏掉安全机制在 FTTI 内的高频状态变化也不能太短否则总线负载过高干扰被测试系统的正常运行。5ms 对 500kbps 的 CAN 总线是合理取值如果总线负载本身较高可以适当调整到 10ms。4.4 通信故障注入的台架实践论文中对 CAN 总线故障注入做了具体展开电机控制器通常放置在动力 CAN 网络中驾驶员的控制命令输出给整车控制器VCUVCU 经过策略执行后输出扭矩控制指令给电机控制器。如果 VCU 与电机控制器之间的 CAN 传输发生故障——例如 VCU CAN 总线受干扰、CAN 总线节点故障、或 CAN 总线的 R/C 阻抗变化过大——都可能影响信号传输的完整性导致电机控制器收不到扭矩指令进而可能造成整车危害。台架测试时故障注入的触发方式分为两种一种是通过特殊的硬件设备在线完成比如 CAN 总线故障注入仪可以在线切换短路、断路、C 型阻抗网络另一种是通过特殊软件程序在上位机侧完成比如通过 USPACE 上位机修改 CAN 控制器参数模拟总线关闭Bus-Off状态。论文中采用的方案是硬件故障注入为主——因为 CAN 短路和断路故障无法通过软件真实模拟只有硬件级别的故障注入才能验证控制器在物理层故障下的真实响应。5. E2E 连续故障判定与安全状态恢复验证5.1 连续 10 次的逻辑陷阱TSR_02_04 要求 E2E 校验连续故障次数超过 10 次才触发安全状态但连续的判定逻辑在嵌入式软件实现中有一些细节需要注意/* TMS570 E2E校验连续故障计数器实现 */ #define E2E_FAILURE_THRESHOLD 10 #define E2E_FAULT_RECOVERY_TIMEOUT 100 /* 故障恢复判定时间窗单位ms */ static uint8_t e2e_fail_cnt 0; static uint8_t e2e_pass_cnt 0; void E2E_MonitorTask_10ms(void) { uint8_t crc_ok CheckE2E_CRC(); /* 校验CRC字段 */ uint8_t timeout_ok CheckTimeout(); /* 校验报文超时 */ if (crc_ok timeout_ok) { /* 一帧通过恢复计数清零 */ if (e2e_fail_cnt 0) { e2e_fail_cnt--; } else { e2e_pass_cnt; } if (e2e_pass_cnt 5) { /* 连续5帧通过判定故障恢复 */ e2e_fail_cnt 0; e2e_pass_cnt 0; SetFaultStatus(E2E_FAULT_RECOVERED); } } else { /* 一帧失败连续故障计数递增 */ e2e_fail_cnt; e2e_pass_cnt 0; if (e2e_fail_cnt E2E_FAILURE_THRESHOLD) { SetFaultStatus(E2E_FAULT_ACTIVE); TriggerSafetyState(ASC_MODE); /* 进入主动短路模式 */ } } }这里的逻辑说明E2E 校验任务以 10ms 为周期执行每次执行时检查 CAN 报文的 CRC 字段和超时标志。当连续 10 帧100ms都校验失败时触发安全状态当连续 5 帧通过时判定故障恢复并清空故障计数。注意故障恢复的判定阈值5 帧与故障触发的阈值10 帧是不对称的——这种不对称是刻意设计的目的是防止系统在故障边缘状态下反复震荡。如果恢复阈值设得比触发阈值还低只要故障间歇性出现系统就会在进安全状态和出安全状态之间反复切换这在整车上是不可接受的。另一个工程细节是故障计数器的递减逻辑很多初学者把连续实现成只要有一帧成功就清零这也会出问题。真正的连续应该是一帧成功抵消一次计数而不是把之前积累的失败次数全部抹掉。论文中 TSR_02_04 的连续故障次数超过 10 次配合 TSR_02_09 的通信丢失小于故障允许阈值时间时系统应能保持工作实际上要求实现方必须明确什么算一次故障什么算一次恢复。5.2 故障恢复后的行为验证故障恢复验证是整个功能安全测试中最容易被跳过、也最容易出问题的环节。论文中的测试结果是在高速零扭矩控制状态下通信故障前一帧通信发生后触发安全机制控制进入 ASC 模式通信恢复后一帧通信后控制回到零扭矩控制模式。这个验证至少回答三个问题第一恢复时间是多久从通信恢复到系统退出 ASC 模式会经过E2E 连续 5 帧通过的判定加上安全状态仲裁逻辑的处理时间最终的恢复时间通常在 100ms 量级。这个时间不能太长否则驾驶员在故障恢复后会感到明显的动力中断也不能太短否则没有充分确认通信链路的稳定性。第二恢复过程中扭矩输出是否有跳变系统从 ASC 模式切回零扭矩控制模式时如果扭矩指令和实际电机转速之间有明显偏差会产生扭矩冲击。所以在台架测试中需要额外加一个观测点记录恢复模式切换时刻的电机力矩实测值确认没有超过预设的突变阈值。第三故障恢复后累计的相关故障计数是否需要通过诊断仪清除论文中没有展开但实际项目里ISO 26262 要求故障事件要记录在非易失性存储器中便于售后诊断和召回分析。这个故障记忆功能本身也需要测试——验证下电重启后故障码依然存在只有通过诊断仪手动清除才能复位。以上是从 V 模型左侧的需求开发到右侧的故障注入验证的完整闭环。整个过程中最值得留意的两个参数一个是安全目标的 FTTI 值400ms 或 3s另一个是 E2E 连续故障计数阈值10 次二者共同决定了整个安全机制在时间维度上是否满足要求——这个时间轴上的自洽性是功能安全开发中最容易在样件阶段暴露问题的环节。本文还有配套的精品资源点击获取