干过汽车电子的工程师，听到“编码器”这三个字，脑子里蹦出来的往往不是价格和货期，而是ASIL、SPFM、安全状态、失效注入这些词。ISO 26262在汽车圈里就是一张绕不开的考卷，转向系统、制动系统、电驱动系统里的位置传感器和电机转子角度编码器，早就被翻来覆去考了十几二十年，哪家供应商能提供符合功能安全要求的编码器，哪家才有资格进量产项目。可到了机器人关节，事情就变得很有意思：关节模组里同样有编码器，同样承担着位置和速度反馈的重任，却一直没人真正把“卷子”出出来。这篇文章想讨论的正是这件事：汽车那张卷子到底是怎么出的，哪些题可以拿到机器人上直接用，哪些题还得我们根据关节场景自己编，以及如果现在想给机器人关节编码器做一轮功能安全设计，落地时到底该从哪下手。对编码器开发者、机器人控制系统工程师、关节模组选型的人来说，这篇文章应该能提供一些能直接拿来用的思路。

1. 汽车界的“编码器考卷”是怎么出出来的

1.1 ISO 26262在考什么

ISO 26262全称是“道路车辆功能安全”，它用一套完整的V模型把安全生命周期拆开，从概念阶段、系统阶段、硬件和软件阶段，一直管到生产、运行、维修、报废。我们常听到的ASIL（Automotive Safety Integrity Level）就是它的核心评级，从A到D，D最严格。编码器在汽车里一般处于“传感器”这个元件层，被放在某个安全相关子系统里，比如电动助力转向（EPS）的电机转子位置检测、电子稳定系统的方向盘转角信号、线控制动的踏板位移测量。它本身不是整个安全功能，但它提供的信号质量直接决定了上层安全功能能不能正确执行。

所以“考”编码器，考的不是它能不能测出角度，而是：它失效时有没有可能让系统感知不到失效、进而输出一个让人伤害的错误动作。ISO 26262的硬件部分要求对每个安全相关元件估算失效率（FIT率）、诊断覆盖率（DC）、单点故障度量（SPFM）和潜在故障度量（LFM），再结合系统要实现的ASIL等级，判断硬件设计是否达标。举一个简单例子，如果EPS依赖电机位置传感器进行电流控制，当位置信号突然跳变，电流环会瞬间饱和，方向盘会猛地抽动。为了防止这种危险，控制单元必须在几毫秒内检测到异常并切到安全状态，比如关闭助力并发出警告。这个过程落到编码器设计上，就变成：你需要周期性自检、合理性检查、冗余通道互检、通信校验，以及对码盘或磁铁安装状态进行监控。

汽车这张卷子真正严的地方不只是算法，而是每个诊断措施、每个失效模式都要有对应的测试记录和失效率依据。编码器供应商得交出一份安全手册，里面写明内部结构、失效模式、诊断措施、建议的安全接口电路。整机厂再用这份手册做系统级分析。这一套流程走下来，编码器在汽车上就不是一个简单的元器件，而是一道有标准答案的考题，考了这么多年，行业已经踩出了一条相对成熟的路。

1.2 汽车编码器里的“送分题”和“送命题”

做汽车功能安全测试时，我们常把编码器相关测试分成两类：一类是“送分题”，一类是“送命题”。

送分题包括上电自检、范围检查、信号超时检测、双通道互比。上电自检时MCU会把编码器角度读几遍，看重复性，再和另一个传感器（比如旋变或霍尔）粗略比对；运行过程中每隔一个角度周期检查读数是否在物理可达到的范围内，比如一个关节不可能在1ms内跳90度，一旦出现这种值就判定故障。这些措施实现简单，但能挡住80%的粗暴失效。

送命题则是那些难以“自曝身份”的故障：温度漂移导致的零点缓慢偏移、磁铁老化导致的角度非线性、线路接触不良引起的偶发跳变、多圈计数在断电后丢失。最麻烦的是前两种，它们不会让信号直接断掉，位置看起来仍然“平滑”，但实际值和真实值之间已经差了几度甚至几十度。在汽车上，如果方向盘转角传感器存在这样的偏移，稳定控制系统就可能把车辆状态判断错；在机器人上，如果关节角度偏移到一定量级，机器人末端实际位置就和模型位置完全对不上，轻则撞停杆，重则导致安全保护策略失效。

所以汽车工程师对待编码器的态度是很“保守”的：能加冗余就加冗余，能不依赖单一信号就不依赖。因为一旦把编码器当成安全关键元件，你的所有测试都要围绕“它在哪些场景下会撒谎”来做，而不是只关心“它准不准”。

2. 机器人关节处的“无人出卷”到底卡在哪

2.1 机器人安全标准现状：有题纲，没细项

机器人领域并不是没有功能安全标准。工业机器人本体安全看ISO 10218-1，机器人系统集成安全看ISO 10218-2，协作机器人有专门的技术规范ISO/TS 15066，控制系统功能安全也常引用ISO 13849和IEC 62061。这些标准对机器人的停止功能、速度监控、力矩限制提出了明确要求：比如协作机器人要求在人员靠近时限制末端速度，有些模式下要求力或功率不得超过阈值，如果依赖关节速度反馈来做限制，编码器的数据质量就直接关联到人身安全。

但问题在于，这些标准整体上是“功能级”的，它们告诉你必须实现安全相关速度监控，却没像汽车ISO 26262那样，对关节编码器这个具体传感器定义出一套“怎么诊断、怎么测试、需要覆盖哪些失效模式”的细则。换句话讲，机器人安全标准给了你一份题纲，但试卷具体怎么出，至今没有公认版本。更尴尬的是，很多协作机器人厂商内部已经把编码器信号用于安全转矩限制或安全速度限制，可采购编码器时，供应商往往连一张功能安全数据表都提供不出来。原因是需求侧没有强制要求，供给侧就不愿意投入做完整的功能安全认证。

这里还要补充一个行业背景：汽车功能安全有法规和事故责任压力，整车厂如果不满足ISO 26262，可能连上市都困难。机器人目前只有出口欧盟时对CE认证有较强要求，而CE框架下机械指令的评估往往允许厂家“自我声明”，对编码器元件的针对性测试并不像汽车那么“主观题必做”。于是出现了这种局面：机器人关节里的编码器明明承担着和汽车转向传感器类似的职责，却没有一套完整的外部考卷。

2.2 关节编码器和汽车编码器的差别比想象中大

很多人以为把汽车上经过认证的编码器拿来装到机器人关节里，问题就解决了。实际使用后就会发现“水土不服”是必然的。首先是物理结构差异：汽车把传感器装在转向管柱、刹车踏板、电机后端，通常环境相对可控；机器人关节里，编码器往往要套在电机轴上或嵌在谐波减速器后端，周围有强磁场、高频电流、抱闸冲击、润滑油脂蒸汽，还有持续变化的径向力。编码器不仅要测量转子的位置，有时还得感受谐波减速器的柔轮变形反馈，这对机械安装精度要求比大多数汽车场景苛刻得多。

其实是寿命和维修策略差异。汽车零部件按整车寿命设计，一般要求15年或更长，维护周期是明确的；机器人关节模组是个易磨损组合件，谐波减速器寿命、轴承寿命可能只有几千到几万小时，编码器如果内置在关节里，坏了就要全套售后，这对可靠性的要求甚至更高。成本上的压力也更突出，车规编码器一套下来几十上百美元，机器人关节整机可能才几百美元，供应商很难为了提升功能安全等级而大幅增加成本。

最后是信号处理链条的差异。汽车上编码器信号大多经过专用ASIC和安全冗余协议处理，机器人控制里则常见SPI、I2C、RS485这类通用总线，甚至很多学生项目和初创团队默认使用循环读取方式，没有考虑总线时序和失效控制。ISO 26262要求的是元件的失效模式和诊断措施有明确对应关系，而机器人行业很多编码器还是当“普通外设”来用，安全性和可用性混在一起。

2.3 需求不明确，供应商只能“躺平”

没有哪家传感器厂愿意主动花钱做功能安全认证，除非客户在下单时把功能安全要求写进规格书里。而机器人厂商对“我的编码器需要达到什么ASIL等级”普遍没有概念，大家更容易问的是分辨率、精度、温漂、通信协议。其实这些参数能决定机器人的控制精度，却无法回答“位置跳变后你希望系统在多少毫秒内安全停机”这个问题。

我在和做关节模组的同行交流时经常提到一个例子：某机械臂项目，客户手册里写着支持安全停止、支持力矩限制，但关节编码器的采购规格书里只字未提“诊断覆盖率”和“安全反应时间”。结果项目测试时，用故障注入器强行拉断编码器SPI通信线，控制器的速度环直接发散，关节迅速冲过机械限位。这类事故在汽车开发阶段是不该发生的，因为早在设计阶段就会有人要求编码器失效后必须进入安全状态。只能说，机器人行业想真正出好这张卷子，第一步是机器人厂商自己把需求说清楚。需求说不清，供应商自然不愿意做；供应商不做，标准化就更遥遥无期。

于是很多团队开始自研“内部考卷”：参考ISO 26262的理念，结合机器人关节实际场景，定义自己的安全需求和测试用例。这其实是可以落地的，而且效果很好。

3. 实战：给机器人关节编码器先出一张“内部卷”

3.1 安全需求分解：把整车场景翻译成关节场景

做内部卷的第一步不是选芯片和算法，而是先做危险分析。ISO 26262里的标准动作是HARA（Hazard Analysis and Risk Assessment），虽然机器人没有完全对应的标准，但思路完全可以平移。

假设我们做一个协作机械臂，工作场景是人机共享空间，允许人员在机械臂运动范围内做事。安全目标是：当人员接近时，机械臂末端速度不得超过某个阈值，比如ISO/TS 15066里常用的每秒250毫米；或者当机械臂与人员接触时，碰撞力不得超过对应身体部位的参考值。要满足这个目标，系统需要实时知道每个关节的速度和位置。如果编码器发生故障，比如某个关节的速度反馈突然变成错误值，控制层可能输出错误指令，末端速度可能瞬间超过安全限值。这时安全机制必须在规定时间内触发安全停止。这个“规定时间”是总预算，比如从编码器读数错误到安全控制器确认故障，再到抱闸和电机停机，每一环都要分配时间。编码器侧的预算通常要控制在几毫秒到几十毫秒级别，否则整个安全回路就来不及。

把这句话翻译成技术需求，就是：编码器系统需要具备故障检测能力，检测到失效后需要在X毫秒内报告；报告后控制器需要在Y毫秒内进入安全状态；安全状态本身要能确保关节不会继续发力。这个X和Y必须来自于整机安全分析，不能拍脑袋。我的习惯是先按最严格的场景算一遍，再按可用性要求放松。如果机器人本身自带刹车并且可以断电抱闸，安全状态非常简单；如果是外骨骼、柔性关节这类无法立刻抱死的设备，编码器诊断的响应时间就得更激进。

3.2 编码器硬件层：选型、冗余、多圈与通信

明确了安全需求之后，编码器硬件的选型逻辑就清晰多了。机器上经常讨论磁编码器和光编码器谁更好，但从功能安全角度看，更关键的是“故障模式是否可控”。

磁编码器在机器人关节里用得最多，因为体积小、抗污染、成本低，AS5600、AS5047P、MT6816这些芯片都快成了入门标配。但磁编码器最要命的失效模式是环境磁场干扰和磁铁老化。磁铁在使用中退磁会导致输出角度与实际角度之间出现非线性误差，这种误差在初期非常小，很难被发现，随着时间推移才逐渐变大。如果需要应对这个失效，就要考虑周期性的在线校验，比如利用电机自身的反电动势或计算电流相位来间接判断角度是否合理。光编码器一般不会有退磁问题，但码盘怕脏、怕震、怕碎裂，如果关节工作在粉尘多或润滑油脂甩溅的环境里，码盘污染会让读数出现随机毛刺。高可靠机械臂常采用磁+光双编码器套装，两个通道独立工作，控制器实时比较两个角度。这种方法在汽车上属于常规操作，在机器人上却被很多团队当成“浪费成本”而放弃。但实际上，双编码器带来的不仅是冗余，还可能让你在诊断覆盖率的证明上省很多力。

多圈绝对值编码器也需要特别处理。机器人各关节为了在断电后保持零点记忆，常选用带多圈计数功能的编码器。传统的电池备份多圈方案在功能安全上其实是个隐患：电池失效或电压跌落会导致多圈值丢失，而且这个故障不会立刻反映出来，往往上电时才发现位置不对。更稳妥的方案是采用韦根能量收集或纯机械齿轮多圈结构，但这些方案成本更高、结构更复杂。我的建议是，无论选择哪种多圈方案，都要把“多圈有效性”当成一个独立状态位，通过MSB附加校验位或主机读取多圈状态寄存器来判断，一旦状态无效，上电后强制执行零点标定，而不允许直接进入自动运行。

通信层面，I2C因为速度慢、抗干扰弱、引脚少，很多功能安全设计里都不建议直接用于安全相关链路。SPI、SSI或RS485这类差分串行通信更适合做安全链路。即使采用I2C桥接，也必须加入CRC校验、超时监测、连续重复读取和范围约束检查，否则一次总线毛刺就可能让整个上位机读到假位置。

3.3 软件层：自检、互检、安全状态机

软件层的设计核心是“不信任任何单一信号”。我常用四层诊断模型，从里到外分别是：传感器内部自诊断、通信层诊断、数据合理性诊断、跨信号互检。

传感器内部自诊断一般由编码器芯片完成，比如检测磁场强度是否超限、内部温度是否过高、SPI帧CRC是否有误。AS5047P有DIAAGC寄存器可以看到自动增益控制值，当增益异常增大时往往提示磁铁安装距离或退磁，此时虽然角度值可能还正常，但可靠性已经下降，应视为预警。AS5600的MGL和MGH寄存器则是磁场检测输出，可以用来判断磁铁是否过近或过远。MT6816的SPI读取时序要求比较严格，初始化GPIO顺序不对时会产生错帧，我自己的习惯是把读取函数做成状态机，不带超时的读取一律不用于安全判断。

通信层诊断主要看连续读取的间隔、CRC、错误计数。设计时最好定义：连续三帧CRC错误立即报警；一帧超时立即进入安全停止候选。很多工程师只判断“读不到数”，却忽略了总线数据错位后读到的可能是另一个寄存器的值，那比读不到更危险。

数据合理性诊断比较直观：位置差分除以采样周期得到速度，这个速度如果超过电机物理极限的一定比例，基本可以判定位置信号异常；位置如果毫无变化但电流命令很大，也可能说明传感器卡死或断线。这里要注意，单纯的速度限幅可能会被缓慢漂移骗过，所以还要加上位置连续一致性校验，每隔一段较长窗口用积分方式核对位置增益漂移。

跨信号互检是最有效但最容易被忽略的。如果有双编码器，直接比较两者角度，设置一个阈值，比如0.5度或1度，超差就停机。如果只有单编码器，可以考虑用电机反电动势估算转子位置，或者用电流模型间接验证。对于带抱闸的关节，还可以利用“抱闸关闭时角度不应变化”做静态自检。这些互检算法不复杂，但能极大提升对编码器系统性故障的检出概率。

软件实现的另一个重点是安全状态机。检测到编码器故障后，控制器绝不能只是“打印一条日志”然后继续跑。安全状态要分级：轻微故障降速运行并报警；严重故障直接切断力矩并触发抱闸，同时通过安全总线通知外部急停回路。在状态切换过程中，要防止“故障恢复后立即重新使能”的抖动，一般要设置锁定时间，比如进入安全停止后必须人工确认才能复位。

4. 具体测试用例和排查技巧实录

4.1 失效注入测试：把能想到的坏法都来一遍

给关节编码器出“内部卷”，最重要的环节就是失效注入测试。我们测试的目的是证明：所有已经识别的危险失效模式都能在规定时间内被检测出来并触发安全状态；同时，正常工况下不能动不动就误报，否则机器人的可用性会大打折扣。

实测中我常用的注入方式包括：直接剪断编码器信号线、短路到电源、短路到地、将数据线对调、用信号发生器注入毛刺、用强磁铁靠近编码器外壳、降低供电电压、用加热枪加热编码器附近区域、用风扇吹低温、在码盘表面涂抹油脂模拟污染、反复上电掉电，以及在运行中突然切换控制模式。每一项都要记录检测时间、系统反应、是否出现未检测到的异常。测试通过判据可以参照这样的表格：

强磁场干扰那一次实测超出了预期，后来把屏蔽罩换成坡莫合金材质，并在软件里把磁场状态位一并纳入安全判断，才压到合理范围。这个案例说明，测试不能只做“应该能过的项目”，要把最不理想的情况都暴露出来。

4.2 磁编码器的常见跳变问题

磁编码器在机器人关节调试中最常见的问题就是角度跳变。以AS5600和AS5047P为例，跳变的原因往往不是芯片本身，而是磁铁安装精度不够。磁铁中心与芯片中心偏差超过一定值后，输出角度在接近0度和360度交界处会出现明显非线性，甚至轻微翻转。解决方法是先通过I2C或SPI读原始磁场信号，观察强度变化是否均匀；再在装配时借助工装保证同心度，必要时用软件做多点校表。

AS5047P这类芯片会输出12位原始数据和一些状态寄存器。我遇到过的问题是在高速旋转时连续读取偶尔会返回一个“离群值”，后来发现是SPI读取时序太长，导致在两个采样之间芯片发生了更新。解决办法是把读取周期改成固定时间触发，并且在应用层做连续三帧的中值滤波或变化率限制。这里要特别提醒：用于功能安全诊断时，不能只靠滤波把跳变“抹平”，因为这会掩盖故障。正确做法是用原始信号做故障判断，再用滤波后的信号做控制输出，两者分开。

I2C编码器（比如AS5600）另一个常见坑是总线被卡死。在机器人关节环境中，电机驱动产生的共模干扰可能让I2C总线进入异常状态，表现为MCU一直收不到ACK。工程上可以加更宽的上拉电阻、把线缆改用双绞屏蔽线，并且给I2C通信加上超时复位逻辑。我见过不止一个团队因为I2C总线偶发卡死而丢位置，最后只能换SPI或模拟通信。

4.3 增量式编码器测速噪声与Z信号处理

增量式编码器在机器人关节里一般不会单独使用，但在一些低成本移动机器人或外部轴上仍然常见。STM32系列很多型号都有编码器接口模式，可以把定时器的CH1和CH2配置成正交解码输入，省掉外部计数器。但这里有两个非常实际的问题：一是输入滤波参数设得不合适会导致低速时计数抖动，二是Z信号（零脉冲）的捕获时序如果不处理，上电后起始位置无法固定。

关于滤波，STM32输入滤波器可以配置为几百纳秒到几十微秒。如果关节转速比较快，滤波过深会丢掉真实边沿，表现为角度失真；如果滤波太浅，噪声又会让计数器乱跳。我的经验是先根据码盘线数和最大转速算一下脉冲边沿的最短间隔，然后取一个边沿宽度比例，再实测噪声环境微调。速度计算方面，低速时建议使用M/T法：固定采样时间内同时测位置增量和编码器脉冲周期，比单纯测频法平滑得多。有人说用logisim的“工程”菜单下的“分析电路”或真值表反向生成编码器解码逻辑来理解正交信号，这个方法在课程设计里学数字电路非常直观，但对于产品级功能安全设计帮不上太多，因为实际故障不仅有逻辑问题，还有物理链路问题。倒是可以把这个思路用在测试台架上，模拟一个正交信号发生器，给编码器接口灌入特定的A/B/Z序列，验证解码逻辑和Z标定流程，这个用途很实用。

4.4 通信可靠性的实际排查顺序

当编码器读数异常时，我建议排查顺序从上到下：先看电源纹波和第二路电源，再看通信线缆的接法、屏蔽和接地，然后看芯片配置和读取时序，最后才怀疑芯片本身或磁铁安装。这个顺序能帮你省一半时间。因为编码器在机器人关节里经常和电机驱动器共享一个电源域，母线电压跌落或IGBT开关毛刺会严重影响I2C/SPI通信。碰到“偶发错帧”的问题时，用示波器量一下时钟线和数据线在故障瞬间的波形，比反复改软件盲试更快。

如果采用ROS 2做整机控制，编码器数据一般是作为驱动节点发布到关节状态话题里。为了安全相关功能，我建议在驱动节点里专门保留一份原始诊断数据，不打包进通用话题，直接通过单独的安全接口上报。因为ROS 2的QoS策略可能会导致数据延迟或丢弃，你总不希望安全停机的判断也走一个“尽力而为”的通道。

5. 关于“卷子”的未来与个人建议

5.1 机器人功能安全标准化可能走的几条路

机器人行业到现在还没有一份针对编码器的“ISO 26262专用卷”，但这个空白不会一直白下去。协作机器人、移动机器人、人形机器人的出货量在增加，一旦出现严重的人身伤害事故，监管压力立刻会倒逼标准化。目前ISO 10218正在往更细的方向修订，ISO/TS 15066也在不断细化，以后完全有可能出现专门针对位置反馈系统、关节编码器的安全要求附录。可以参考的方式是汽车界的SEooC（Safety Element out of Context）：编码器供应商可以在不知道最终系统的情况下，按照一个“脱离上下文的安全元件”来开发和认证，定义好通用安全需求、失效模式、诊断措施，只是应用时有前提条件。机器人专用标准如果能接受SEooC认证元件的复用逻辑，整个供应链就有动力去补课。

另一个趋势和法规出口认证有关。欧盟机械法规对功能安全的引用越来越严格，做出口的机器人厂商早晚要向客户出具PL/SIL评估报告。届时编码器作为关节反馈的核心元件，没有安全数据表会直接被拒。这个压力会沿着整机厂传导到编码器供应商。人形机器人兴起也带来了一个变量，很多车规级传感器供应商开始投入机器人赛道，他们会习惯性使用功能安全流程做编码器选型和验证，把汽车那套“卷子”带进机器人行业。到那时候，机器人关节编码器的标准化可能比我们想象中来得更快。

5.2 给做编码器与关节控制工程的三个实操建议

第一个建议是把“安全相关编码器”和“普通控制编码器”分开定义，千万不要在需求文档里混用。不同应用场景里对编码器安全等级的需求差异很大，家用扫地机器人、工业移动平台和医疗手术机器人完全不在一个级别。需求里写得越明确，供应商才能按标准去做。

第二个建议是建立自己的失效模式库和台架测试用例库。每次项目里碰到编码器故障，不管是野外的还是台架上的，都记录下来，包括现象、环境条件、代码版本、故障周期。做上三个项目之后，你就会发现很多故障是可以提前预判的。编码器供应商给的FMEA报告通常只是起步，真正的可靠性数据要靠自己工程现场积累。

第三个建议是尽早引入故障注入测试，不要等到整机认证阶段才补。我见过太多项目在开发初期只用正常工况测试，等到送检时才发现安全响应时间根本不够。把故障注入做成CI流程的一部分，在每次固件更新后自动跑一轮关键场景，虽然前期投入时间，但能极大降低后期返工成本。

我个人从汽车电子转到机器人领域后，最大的感受是：机器人其实比汽车更需要功能安全的设计方法，因为它和人靠得近、动态性强、关节数量多，失效组合也多。可惜行业里真正愿意静下心来“出卷子”的人不多，大家都着急出产品、跑demo，结果编码器这类基础传感器反而成了功能安全链条上最容易被忽视的薄弱环节。如果你正打算进入这个方向，我建议你先把ISO 26262的Part 5、Part 6、Part 9翻一遍，再用ISO 13849和IEC 62061对照机器人控制架构，然后从一台小关节台架开始，把失效注入、诊断覆盖率和安全状态机一个个跑通。考卷不会突然出现，但你可以先给自己批改。