一、EPS 冗余扭矩传感器的功能安全设计：别把“两路信号”误当成“双通道安全”

图 1 封面图：Bosch Mobility 电动助力转向系统公开页面图片，来源。

电动助力转向（EPS, Electric Power Steering）里，扭矩传感器看起来只是一个输入件：驾驶员往左或往右打方向，传感器告诉 ECU 当前转向柱上的扭矩大小和方向，ECU 再计算电机助力。但从功能安全视角看，它不是普通输入，而是 EPS 控制意图的入口。扭矩信号一旦错误，系统可能不是简单地“少帮一点忙”，而是帮错方向、帮过头、在驾驶员修正时产生反向助力，甚至让方向盘出现来回摆动。对工程师来说，冗余扭矩传感器的设计价值不在于多放一路硬件，而在于让系统在输入不可信时仍然知道自己该怎么降级。

公开召回案例给了很直观的提醒。NHTSA 公开资料中曾描述过 EPS 扭矩传感器信噪比不足导致控制模块无法判断驾驶员输入，系统检测到后撤销助力并回到手动转向；也有召回报告提到副数字扭矩传感器极性标定反了，当主扭矩传感器故障后，备用通道反而可能引发方向盘振荡。这类问题非常适合用来解释：功能安全不是“传感器坏了就报故障”这么简单，而是要在故障发生前定义清楚危险、诊断、故障容忍时间、降级路径和验证证据。

图 2 ：EPS 冗余扭矩传感器功能安全架构

图1 根据公开 EPS 架构资料和工程实践整理，用于说明冗余扭矩输入在系统中的位置。

二、扭矩传感器为什么是 EPS 的安全关键输入

传统液压助力转向的助力来自机械和液压系统，电子控制对驾驶员意图的解释相对有限。EPS 则把“助力多少、何时助力、助力方向是否允许”交给 ECU、电机驱动和软件策略。扭矩传感器通常安装在转向柱或转向机相关位置，用来测量驾驶员施加在转向系统上的扭矩；再结合车速、转角、电机位置、电流等信号，形成闭环助力控制。

图 3 公开产品资料图：Bosch Mobility 柱式助力单元与转向系统布置示意，来源。

这带来一个安全边界：如果扭矩输入偏大，车辆可能出现过度助力；如果扭矩方向错误，助力方向可能与驾驶员意图相反；如果输入突然丢失，车辆可能进入无助力状态，低速泊车或紧急避让时驾驶员操纵负担显著增加。多数 EPS 仍保留机械转向链路，因此许多故障反应会设计为“告警 + 限制/撤销助力 + 保持机械可转向”。但这不代表风险天然可接受，因为故障发生的车速、转角、驾驶员预期和故障瞬态都会影响可控性。

所以，扭矩传感器的安全设计通常要回答四个问题：第一，系统如何发现扭矩信号不可信；第二，发现之后多快进入受控状态；第三，进入受控状态时会不会引入新的危险瞬态；第四，量产后如何证明每台车上的传感器、标定和软件参数仍然满足设计意图。

三、ISO 26262 在这里真正要求什么

ISO 26262:2018 是面向道路车辆 E/E 系统功能安全的系列标准，它提供的是生命周期框架和活动要求，而不是给某个 EPS 传感器规定一个固定电路图。换句话说，标准不会直接写“EPS 扭矩传感器必须两路反相信号”或“差值阈值必须是多少牛米”。这些属于技术方案和项目分配。

标准强制要求的核心，是开发组织要从危害分析和风险评估（HARA, Hazard Analysis and Risk Assessment）出发，识别由于 E/E 系统故障导致的危害，分配汽车安全完整性等级（ASIL, Automotive Safety Integrity Level），再把安全目标逐层细化到功能安全要求（FSR, Functional Safety Requirement）、技术安全要求（TSR, Technical Safety Requirement）以及软硬件实现和验证。对 EPS 扭矩输入来说，典型安全目标可以围绕“防止非预期转向助力”“防止助力方向与驾驶员意图相反”“在扭矩输入不可信时进入可控降级状态”来展开。

行业常见做法则更具体：扭矩传感器采用双通道输出，两个通道可能设计为相同量程、反向斜率、不同供电或不同采样链路；ECU 对两路信号做范围检查、相关性检查、斜率检查、供电诊断、通信 CRC 或序列计数检查；当诊断确认故障后，系统根据场景限制助力、冻结助力、平滑退出助力或切换到降级控制。这里的“常见做法”不是标准逐字规定，而是项目为了实现安全目标、满足硬件指标和系统可控性而选择的设计组合。

四、冗余不是复制一遍，而是降低相关失效

很多项目评审时会出现一句危险的话：“我们有两路扭矩，所以安全。”这句话只说对了一半。两路信号如果共享同一个供电、同一组地参考、同一种敏感结构、同一套标定逻辑、同一段线束、同一个软件解析函数，那么它们面对共因失效（Common Cause Failure）或级联失效时可能一起错。功能安全真正关心的不是通道数量，而是故障独立性、诊断覆盖率和故障反应质量。

图 4 真实产品图。

从产品形态看，扭矩/角度传感器并不是一块孤立芯片，而是机械接口、敏感元件、信号处理、电连接器和装配基准共同构成的部件。公众号读者看到真实产品图，会更容易理解为什么功能安全不能只审软件阈值：传感器安装位置、轴套结构、连接器方向、机械间隙和产线装配都会进入安全边界。

以双通道模拟扭矩传感器为例，A 通道输出随正向扭矩上升，B 通道输出可能随正向扭矩下降。ECU 不能只看 A 是否在电压范围内，还要看 A 与 B 的和值、差值和方向关系是否合理。若 A 突然跳变而 B 没有对应变化，可能是 A 通道短路、接触不良或采样链路异常；若 A/B 同时漂移，则要考虑供电、地偏移、温度、机械装配或磁场扰动；若两路关系稳定但方向与转角、电机反扭矩不一致，则可能是标定或极性问题。

对数字传感器，诊断对象还包括通信帧、计数器、CRC、超时、数据冻结、重复值和版本/配置一致性。这里有一个工程教训：数字化并不自动等于安全。数字通道可以更容易做端到端保护，却也可能把错误固化在配置、极性、缩放系数或软件接口合同里。副通道如果在标定阶段就被写错极性，它在主通道健康时可能被相关性诊断拦住，但在某些故障组合下仍会成为危险输入。因此，冗余通道必须同时覆盖“运行时随机硬件故障”和“系统性配置错误”。

图 5 扭矩传感器故障与反应矩阵

五、FTTI 不是一个口号，而是故障反应预算

故障容忍时间间隔（FTTI, Fault Tolerant Time Interval）经常被写在安全分析表里，却没有真正进入控制策略。扭矩输入故障的 FTTI 不能只由软件任务周期决定，还要考虑机械系统惯性、电机助力建立时间、驾驶员修正反应、车辆横摆响应和诊断去抖时间。太短的去抖会造成误报和不必要的助力退出；太长的确认会让错误助力持续过久。

一个更可落地的做法，是把 FTTI 拆成几个预算：传感器采样和接口诊断时间、A/B 合理性确认时间、故障锁存与安全状态切换时间、助力削减斜率时间、驾驶员告警时间。比如，范围类硬故障可以很快确认，而轻微漂移和间歇接触可能需要多周期观察；方向极性错误不能只靠瞬时电压发现，需要结合方向盘转角变化、电机电流、车辆状态和端到端标定证据。

这里最难的是“降级瞬态”。如果 ECU 检出两路差异后立刻把助力从当前值砍到零，车辆在低速大转角场景下可能出现方向盘手力突增；如果为了舒适性慢慢退助力，又可能让错误输入继续影响控制。成熟方案通常会根据故障类型、车速、扭矩变化率和当前助力状态选择不同反应：对明显方向错误或异常大扭矩，优先快速限制；对单通道失效但另一通道可信的情况，可在受控窗口内使用可信通道并限制助力上限；对双通道都不可信的情况，应进入更保守的安全状态。

六、硬件指标和系统行为要连起来看

在 ISO 26262 的硬件层面，项目会关注单点故障指标（SPFM, Single-Point Fault Metric）、潜伏故障指标（LFM, Latent Fault Metric）和随机硬件失效的概率度量（PMHF, Probabilistic Metric for random Hardware Failures）。这些指标本身不是为了让表格好看，而是要反映系统是否能覆盖危险失效。

对扭矩传感器链路来说，硬件安全分析不能只分析传感器芯片。传感器供电、地、连接器、线束、滤波电路、ADC、微控制器输入、多路复用器、软件读取路径、通信接口、电机控制输出都可能参与危险链路。一个传感器通道的失效是否是单点故障，取决于另一通道能否及时发现并把系统带到安全状态；一个副通道的失效是否是潜伏故障，取决于它在主通道健康时是否被周期性诊断出来。

图 6 公开产品图：Infineon XENSIV TLE4802 传感器芯片图片，来源。

芯片级公开产品图适合提醒读者：安全相关传感器链路的风险不只在“测量对象”，也在封装、供电、接口、诊断状态位和配置数据。这里不能把某个具体芯片简单等同于 EPS 扭矩传感器本体，但可以用它说明汽车传感器芯片在安全机制、诊断接口和系统集成中的角色。

这也是为什么 EPS 常使用带安全文档的 MCU、传感器和驱动器。供应商可能提供安全手册、失效率、失效模式分布、FMEDA 或应用说明，帮助系统集成方完成安全分析。但供应商资料不能替代整车项目的安全论证。传感器在数据手册里支持功能安全，不等于你的转向系统已经满足安全目标；MCU 有锁步核、存储器 ECC 和 ADC 诊断，也不等于扭矩输入的极性、标定、降级和驾驶员体验已经被验证。

七、软件诊断要避免两个极端

第一个极端是“阈值万能”。很多软件把 A/B 差值大于某个阈值作为核心诊断，却忽略了温度漂移、机械迟滞、采样相位、滤波延迟和方向盘快速操作。结果可能是在激烈转向时误判故障，或者为了避免误判把阈值放得太宽，真实漂移又被漏掉。更稳的策略通常会采用多维诊断：静态范围、动态斜率、A/B 相关性、与转角变化方向一致性、与电机电流响应一致性、以及故障去抖和恢复条件。

第二个极端是“可恢复太积极”。扭矩传感器故障如果频繁进入、退出，会让助力行为变得不可预测。安全相关故障通常需要锁存、DTC 记录和清晰的恢复条件。是否允许当次驾驶循环内恢复，要看故障类型和安全概念。有些瞬态通信错误可以恢复，有些极性、标定、供电异常则更适合保持降级或要求维修。这里要把故障处理策略写进安全要求，而不是留给软件工程师在代码里临场发挥。

还有一个容易被低估的问题：滤波器本身也可能掩盖故障。对扭矩信号做低通滤波可以改善噪声，但也会引入延迟；对 A/B 差值做滤波可以减少误报，但会推迟诊断。功能安全评审时应要求软件团队给出滤波参数、诊断阈值、去抖计数、任务周期、最坏执行时间和 FTTI 预算之间的对应关系。

八、标定和产线是冗余设计的最后一公里

扭矩传感器不是装上就完事。零点、增益、方向、温度补偿、机械装配偏差都可能通过标定进入系统。对冗余通道来说，标定错误有时比随机硬件失效更棘手，因为它可能在所有车辆状态下都表现得“很稳定”，直到某个通道故障或某个边界场景触发才暴露。

因此，EOL（End of Line）产线测试应覆盖至少三类检查：第一，零扭矩和已知扭矩下 A/B 输出是否在窗口内；第二，正负方向加载时两路方向关系是否符合设计；第三，写入 ECU 的传感器参数、软件版本、配置校验和是否与车辆配置一致。售后诊断也应能读取关键 DTC、冻结帧和传感器状态，避免维修人员只看到一个笼统的“转向系统故障”。

对项目管理者来说，这意味着功能安全不能只盯开发阶段。生产、运行、服务和退役活动同样属于安全生命周期的一部分。一个在样车台架上表现很好的扭矩冗余方案，如果量产标定流程没有防错，仍然可能在现场留下系统性风险。

图 7 公开资料图：FORVIA HELLA 线控转向传感器技术新闻图。

线控转向和 EPS 不是同一个系统边界，但公开资料图能很好地说明一个趋势：转向系统正在把更多“驾驶员意图”和“车辆执行状态”交给电子传感器、控制器和通信链路来表达。越是这样，冗余信号的独立性、配置一致性和故障反应就越不能只停留在框图层面。

图 8 ：从安全目标到量产证据链

九、一个项目落地模板

如果把“EPS 冗余扭矩传感器安全设计”落到项目交付物，可以按以下模板推进。

第一步，定义危害和安全目标。不要只写“扭矩传感器故障”，而要写清故障造成的车辆层行为，例如非预期助力、助力方向错误、助力突然丢失、方向盘振荡或驾驶员操纵负担突增。每个行为都要结合场景评估严重度、暴露率和可控性。

第二步，定义传感器安全概念。明确 A/B 通道是否反相、是否独立供电、采样链路是否独立、通信是否有端到端保护、MCU 对输入链路有哪些诊断、哪些故障由传感器内部发现，哪些故障由 ECU 发现。这里应避免模糊表述，比如“进行合理性检查”不够，必须写出检查对象、阈值来源、确认时间和反应策略。

第三步，分配 FTTI 和降级策略。范围故障、相关性故障、极性错误、通信超时、双通道不可信、间歇故障，反应不应完全一样。每个故障都要定义助力限制、斜率限制、告警、DTC、恢复条件和驾驶循环策略。

第四步，建立安全分析闭环。把 FMEA、FMEDA、FTA、DFA 和软件安全分析连接起来。不要让硬件表格说“由软件诊断覆盖”，而软件要求里却没有对应诊断；也不要让软件说“进入安全状态”，而系统验证没有覆盖切换瞬态。

第五步，验证到真实边界。台架可以注入开路、短路、卡滞、噪声、漂移、反相、通信错误和供电扰动；HIL 可以覆盖车速、转角、扭矩组合；整车应验证驾驶员可感知行为。对扭矩传感器，尤其要验证“主通道失效后是否真的能安全使用副通道”，以及“副通道错误时系统是否会拒绝它成为可信输入”。

再往下落一层，项目评审可以设置一张“扭矩输入安全清单”。这张清单不追求漂亮，而追求能把问题逼出来。比如：A/B 两路是否存在共享电源导致的同时失效；地偏移是否会让两路一起朝同一方向漂移；连接器半插、端子退针、线束磨损是否有可诊断表现；传感器内部故障标志与 ECU 外部合理性检查是否会互相矛盾；当传感器数据冻结时，控制器是否会误以为驾驶员正在持续施加恒定扭矩；当车速信号也异常时，助力限制策略是否还成立。

这个清单还应该覆盖软件接口。扭矩单位是 N·m、ADC 计数，还是归一化百分比；正方向是左转还是右转；信号滤波前后分别给谁使用；诊断使用原始值还是滤波值；DTC 触发后哪些模块能看见这个状态。这些问题听起来琐碎，却经常决定安全机制能不能真正闭环。功能安全里最怕的不是没人做诊断，而是每个团队都以为另一个团队已经把边界条件处理好了。

最后，安全案例中最好保留“负面证据”。也就是不只证明正常路径通过，还要记录哪些危险方案被排除了：例如不允许在双通道不可信时继续按最大助力工作，不允许副通道未经方向一致性确认就接管，不允许产线跳过极性检查，不允许售后刷写绕过配置校验。这样的记录能让后续变更评审更有抓手，避免几年后一个看似无害的软件优化，把原本靠流程守住的安全边界悄悄拆掉。

十、常见误区

误区一：把双通道当成 ASIL 分解的自动通行证。ASIL 分解要求独立性、充分性和安全机制论证，不是把同一个传感器的两路输出画成两个方框就结束。

误区二：只验证稳态，不验证故障瞬态。很多危险不发生在故障稳定之后，而发生在切换那几百毫秒到几秒之间。助力从正常到降级的斜率、方向盘反力变化、驾驶员是否能接管，都需要实测。

误区三：忽略标定数据。硬件和软件都正确，参数写错也会造成系统性故障。极性、零点、缩放和车型配置应进入配置管理和产线防错。

误区四：把供应商安全手册当成系统安全案例。供应商资料只是输入，系统集成方仍然要证明自己的使用条件、诊断配置、故障反应和验证覆盖满足项目安全目标。

误区五：诊断越敏感越安全。过度敏感会误触发降级，影响可用性和驾驶员信任；过度迟钝又会漏诊危险。真正的安全是诊断覆盖、确认时间、误报控制和降级行为之间的平衡。

十一、工程师总结

EPS 冗余扭矩传感器的功能安全设计，表面上是在讨论传感器 A 和传感器 B，实际上是在讨论“驾驶员意图什么时候可信”。只要这个问题没有回答清楚，硬件再多一路也只是增加复杂度。

一个可靠的方案应当做到：正常时，两路信号共同提升输入可信度；单通道故障时，系统能识别不可信通道并受控降级；双通道或共因风险出现时，系统能进入保守安全状态；标定和量产阶段，系统能防止错误参数进入车辆；验证阶段，团队能拿出从 HARA 到台架、HIL、整车和售后诊断的完整证据链。

对做 EPS 的团队来说，扭矩冗余不是“有没有”的问题，而是“能不能证明它在关键时刻不会帮倒忙”的问题。功能安全最终保护的不是某个传感器通道，而是驾驶员在异常情况下仍然能够理解车辆、接管车辆、把车辆带回可控状态的能力。