机器人终于开始考功能安全了：NVIDIA把卷子发下来，下一个可能就是编码器

我一直有一个判断：编码器在汽车上，ISO 26262 这张卷子已经考了很多年；到了机器人关节，却一直没人真正出卷子。

大家选机器人编码器，问得最多的还是精度多少、分辨率多少、延时多少、最高转速多少。客户会问 SPI 多快，会不会丢码，温漂怎么样，磁铁偏一点还能不能用。

但是很少有人坐下来问另外一组问题：

这颗编码器如果坏了，系统怎么知道？

多久能知道？

它会不会坏了以后还继续输出一个“看起来很正常”的角度？

如果发生这种故障，机器人还能在规定时间内停下来吗？

这其实才是功能安全真正要问的问题。

最近我看到的一张机器人算力板信息图，让我觉得这件事可能开始变了。

NVIDIA没在卖一块更快的板子，它开始卖“这台机器人怎么证明安全”

今年 3 月，NVIDIA 发布 IGX Thor。

IGX T5000 和 Jetson T5000 一样，集成 GPU 都能做到 2070 FP4 TOPS，128 GB LPDDR5X。区别在于 IGX Thor 明显不是按照普通机器人开发板的思路做的：它加入 Functional Safety Island，支持完整 DRAM ECC，而且 NVIDIA 明确把 ISO 26262、IEC 61508 和功能安全能力放进产品定义里。

真正让我注意的还不是这几个参数。

6 月，NVIDIA 又发布了 Halos for Robotics。

这次话说得更直接：他们把过去在自动驾驶上积累的安全架构，开始往工业机器人、人形机器人和 AMR 上搬。IGX Thor 是底下的硬件，Halos OS 是安全软件栈，上面继续接安全应用和认证体系。

而且这已经不是 PPT 上的一张架构图。

Agility Robotics 正在把 IGX Thor 和 Halos Core 集成到 Digit 人形机器人的安全系统中，并准备围绕 IEC 61508、ISO 13849 等标准继续做第三方认证。NVIDIA 甚至把 Digit 定义成 Halos 在量产机器人上的首批实际落点。

这件事情在我看来，比“又发布了一块 2000 TOPS 的算力板”重要得多。

因为汽车那套卷子，开始被算力平台带进机器人了。

算力板过了，事情反而没有结束

很多人容易产生一个误解：机器人用了一个支持功能安全的 NVIDIA 平台，是不是整机安全问题就解决了？

恰恰相反。

它只是意味着系统终于有条件继续往下面查了。

功能安全不是问“CPU 有没有证书”，而是要证明一条完整的故障链：

传感器发生故障——系统检测出来——控制系统知道发生了什么——在规定时间内采取动作——最终进入可以接受的安全状态。

这条链上少一环都不行。

NVIDIA 自己的 IGX Thor Safety Product Brief 里已经写得非常直接：除了 Safety Manual、FMEDA 等安全资料，它还有一套 Edge Safety Link，用来连接 safety-related sensors and actuators，上面可以继续实现 FSoE、PROFIsafe、CIP Safety 等安全协议。

注意这里两个词：

Sensors。Actuators。

所以当算力这一层开始按照功能安全的方法设计以后，问题不会停在算力板。

它一定会继续往下问。

摄像头怎么办？

力传感器怎么办？

电机驱动怎么办？

最后当然也会问：

关节位置是谁告诉我的？

答案就是编码器。

到这一层，±0.05°可能已经不是客户最先问的问题

我觉得这是很多做编码器的人还没意识到的变化。

平时我们讨论一颗编码器，经常讨论的是误差。

比如 INL 是 ±0.1° 还是 ±0.05°，14 位还是 16 位，延迟 10 μs 还是 1 μs。

到了功能安全，问题完全换了一套。

假设机器人膝关节实际已经到了 37°，编码器内部某个故障让输出固定在 32°。

最麻烦的不是它“不准”。

最麻烦的是：

它输出的 32°非常稳定。

CRC 可以是对的。

SPI 时序可以是对的。

数据每一帧都在更新。

从 MCU 看过去，这颗芯片甚至“工作得非常漂亮”。

但这个角度是错的。

这就是功能安全里比随机噪声麻烦得多的一类故障：plausible but wrong。

一个明显跳到 0xFFFF 的编码器其实不难处理，因为控制器马上知道它坏了。

真正难处理的是一颗仍然认真告诉你“现在是 32.001°、32.002°、32.003°”的坏编码器。

于是问题从“角度精度是多少”变成了：

哪些故障可以被内部诊断发现？

哪些故障必须依赖外部冗余发现？

检测覆盖率是多少？

危险故障率是多少？

从故障发生到报告 Fault 最长多久？

系统留给机器人进入安全状态的时间还剩多少？

这时候客户找编码器供应商要的东西，也不会只是 Datasheet。

它会开始要 Safety Manual、FMEDA、FIT 数据、Diagnostic Coverage、故障响应时间。

FMEDA不是一张高级版规格书

这个地方尤其容易被误解。

FMEDA 不是把 Datasheet 后面再加二十页。

它真正做的是把芯片内部可能坏掉的东西拆开。

霍尔前端可能坏。

ADC 可能坏。

数字滤波器可能坏。

CORDIC 可能坏。

寄存器可能翻转。

时钟可能异常。

电源监控可能失效。

SPI 输出逻辑可能卡死。

然后再问每一种故障：

发生概率有多大？

危险不危险？

内部诊断能不能发现？

发现不了的话，系统靠什么兜底？

因此所谓诊断覆盖率，本质上讨论的是危险故障里面有多少能够被检测出来：

这个数字跟“16 bit”不是一个维度的东西。

一颗角度性能非常漂亮的编码器，如果内部没有合理的故障监测架构，也没有经过 FMEDA 分析，在安全工程师眼里可能很难用。

反过来，一颗精度参数没有那么夸张，但 Watchdog、存储器检测、时钟监测、电源监测、信号幅值诊断、内部数据路径检测、通信 CRC、故障引脚这些东西从架构一开始就考虑好了，它反而更容易进入一个真正的安全系统。

汽车编码器这些年真正形成的壁垒，很大一部分就在这里。

不是角度算不出来。

而是你敢不敢告诉客户，这颗芯片每一个地方坏掉以后会发生什么。

机器人以前为什么没人认真问？

因为以前整机都没有走到这一步。

机器人还在解决“先站起来”“先走起来”“先把东西抓起来”。

一家客户连整机安全架构都还没定，你去给他讲 SPFM、LFM、FMEDA，他大概率不会因为这些东西多付一分钱。

所以过去机器人编码器市场有一个很奇怪的现象。

汽车里已经非常成熟的一套问题，到了机器人关节，好像突然消失了。

不是机器人不存在这些故障。

是没人出卷子。

现在变化在于，NVIDIA 这样的算力平台公司开始把安全架构直接送到机器人整机厂门口。

Agility 已经接了。

后面的整机厂哪怕不完全照着 NVIDIA 的方案走，也会越来越难绕开同一个问题：

如果机器人要真正进工厂，和工人长期待在同一个空间里，出了故障以后，到底凭什么证明它不会继续把人撞倒？

一旦整机厂开始认真回答这个问题，关节位置反馈迟早会被查。

我现在反而更关心第一个来要FMEDA的机器人客户

所以我会做一个可以被证伪的判断。

到 2028 年 9 月之前，昆泰芯很可能会遇到至少一家机器人客户，在关节编码器选型或者项目导入阶段，正式索取 Safety Manual、FMEDA、FIT/失效率或者诊断覆盖率资料。

我现在给这件事大约 65% 的概率。

不是因为我认为未来所有人形机器人都一定照搬汽车的 ISO 26262。

机器人有自己的 IEC 61508、ISO 13849 等体系，不同产品最后走的认证路线也不会完全一样。

我提高这个概率，是因为今年已经出现了一个很明确的领先指标：

不是“有人讨论机器人需不需要功能安全”，而是 Agility 已经把功能安全算力和安全软件栈往 Digit 里面装了。

这两件事差别很大。

真正值得我们盯的，甚至已经不是 IGX Thor 能卖多少块。

而是以后机器人客户发来的 RFQ、技术协议和 SQE 表格里，什么时候第一次出现这些词：

Safety Manual。

FMEDA。

FIT。

Diagnostic Coverage。

SIL。

PL d / PL e。

如果只是问 ±0.1°、16 bit、SPI 多少 MHz，那还是原来的机器人市场。

如果哪一天，一个机器人客户突然问：

“你们这个器件单点故障以后怎么检测？”

那件事的性质就完全变了。

因为这意味着汽车行业考了十几年的那张卷子，终于沿着算力板、控制器、驱动器，一路传到了机器人关节。

而那时候，编码器厂商再临时开始准备答案，可能已经晚了。

最后还有一个边界必须讲清楚。

一颗编码器芯片拿到功能安全相关认证，并不等于它自己就能成为机器人的安全限位。

控制反馈和独立安全功能仍然是两回事。真正的整机安全依赖系统架构、冗余、诊断和安全状态设计。

客户真正要问的也不是：

“你这颗芯片安全吗？”

而是：

“当我开始证明整台机器人是安全的时候，你这颗芯片能给我的证据链贡献什么？”

我觉得，这才是接下来几年机器人编码器真正可能发生变化的地方。