物理 AI 安全的下一个十年，问题不是 "出事了怎么停"，而是 "还安全多少、以多快速度变不安全"。
01 先说结论
NVIDIA Halos for Robotics 是当前物理 AI 里少有的、把功能安全、AI 安全、网络安全、认证体系和部署闭环做成 "可交付全栈" 的工程实践。它非常会处理 "出事了"，却不太会处理 "正在慢慢出问题"。
一句话：Halos 有刹车，缺仪表盘。
02 Halos 是什么
2026 年 6 月 22 日，NVIDIA 发布 Halos for Robotics——IGX Thor + Halos OS + Outside-In Safety Blueprint + Inspection Lab。Agility 的合作是把 Halos 整合进下一代（第五代）Digit，不是现有 Digit 已搭载。
认证细节要注意区分：车载语境下，TÜV SÜD 认证的是 DriveOS / Thor-X SoC，部分构件达到 ASIL D；机器人语境下，检查方是 TÜV Rheinland，IGX 的 Safety Island 是 SIL 3 capable—— 这是能力等级，不等于已获认证。Inspection Lab 拿到了 ANAB 的 ISO/IEC 17020 检验机构认可。
03 拆开看：Outside-In Safety Blueprint 做对了什么
表格
| 组件 | 职责 |
|---|---|
| SIPP（Sensor Input Processing Pipeline） | 把外部相机流转成事件 |
| SAIM（Safety AI Monitor） | 在 "感知结果还够不够格进决策" 这一关设卡：OOD、遮挡、断连、退化输入都会被拦 |
| SEI（Safety Event Integrator） | 多视角事件融合，检查事件是否过期 |
| SDM（Safety Decision Maker） | 一台有限状态机，跑在隔离的 Safety Island 上，输出安全动作 |
| SBB（Safety Black Box） | 日志与审计追踪 |
更准确地说，SAIM 是在 "感知结果够不够格进决策" 这一关设卡，不是对传感器做 PHM。
Halos OS 有两种配置：纯 Linux，或 Linux + QNX 经 NV Hypervisor 做虚拟机级隔离；Inspection Lab 评估 IEC 61508、ISO 13849 和 ISO/IEC TR 5469。SBB 事件后记录、Isaac Sim / NuRec 部署前仿真验证、CI 数据再训练按版本迭代 —— 三者时间粒度不同，但都是 "回头看" 的时间。
04 盲区：运行时缺一个 "往前看" 的时间维度
SAIM 的逻辑很清晰：输入变 OOD → 检测并标记 → 触发安全链 → SDM 回退到安全状态，直到条件恢复。这是一套成熟的故障响应式架构。
但问题在于：Halos 的时间维度，没有进入安全决策的一阶回路。 渐变型退化分三类：
第一类：物理退化。 激光雷达反射率随温度缓慢漂移、制动片磨损导致响应延迟逐月增加。背锅方是 PHM—— 航空领域在线损伤辨识早已进入飞控内回路（NASA IRAC）和运行决策（Boeing AHM），但在汽车功能安全语境下，退化趋势尚未成为 ASIL 一阶决策输入。
第二类：分布漂移。 训练分布不等于部署分布，模型在真实场景里悄悄变弱。SOTIF（ISO 21448）识别 unknown unsafe scenarios，要求系统在超出已验证能力范围时切到缓解路径；工程上可借鉴 selective prediction /learning to reject—— 但这是 ML 文献的概念，不是 SOTIF 原文表述。背锅方是 MLOps：drift detection 方法成熟，同样没被整合进安全决策的一阶回路。
第三类：假设老化（Assumption Aging）。 Safety Case 依赖的假设在部署后被真实世界慢慢推翻 —— 比如原本 "人不会出现在货架顶部"。物理退化有人背锅，分布漂移有人背锅，假设老化在 automotive AI safety 工程实践中尚未形成责任闭环，这才是真正的盲区。
它的可怕之处不是 "没人负责"，而是：Safety Case 在交付时是对的，第 90 天开始变旧，第 180 天被某个边缘场景悄悄推翻 —— 而系统还在跑，因为没有任何指标越界。
先例是有的：Jaradat & Punnekkat 2018（运行期观测故障率与设计假设发散后回炉 safety case）、Denney & Pai 2024（dynamic assurance）、加拿大 CNSC 约 10 年 PSR 周期重审 safety case。空白不是 "没人想到"，而是还没形成一个可操作的责任闭环。
05 为什么没人做：不是能力问题，是安全经济学
回头看的时间，能写进报告；往前看的时间，要写进状态机。前者是证据，后者是责任。
渐变监测早就有了：EWMA、贝叶斯变更点检测、健康度指标化，在可靠性工程、PHM、MLOps、SOTIF 里都是成熟应用。但它在汽车功能安全语境下，没被提升为 ASIL 一阶决策输入。
卡住的不是 "概率"——ISO 26262 本身就是概率框架，FTA、PMHF 都是定量目标。真正卡住的是 "在线自改基线" ：认证时的概率假设在运营期被自己改掉，可复现、可归档的证据链就断了。
状态机范式没错，它处理突变很对。问题是安全架构里没有第二层范式与它并行：一个管 "出事了没"，一个管 "还在退化到什么时候出事"。
06 解法：从状态机到轨迹管理
不是推翻状态机，而是在状态机之上增加一层时变余量估计：在 SAIM 和 SDM 之间插入一个 "轨迹估计器"—— 输入是 SAIM 的历史输出，输出是 Time-to-Safety-Boundary（TTB） 。
先区分一个概念：safe RL 里的 time to safety（TTS）指违规后恢复速度；TTB 是 "距离触碰安全边界还有多久"，是预测，不是恢复。
状态机收到的是红灯、绿灯；轨迹层给的是：
# 示意性输出，非某系统实测数据
risk_margin = 0.32 # 当前安全余量
drift_rate = 0.004 # 余量衰减速率（/小时）
TTB = 78 # 距触碰安全边界的时间（小时）
TTB_CI = (51, 140) # 90% 置信区间
recommended_action = "derate_10%" # 建议动作：降 10% 功率
它不取代状态机，而是给状态机喂新输入：状态机负责 "出事时怎么停"；轨迹层负责 "还没出事，但余量正在变小，要不要提前降权"。一个是刹车，一个是仪表盘。现在行业里所有人都在卷刹车距离，没人问仪表盘为什么还显示 100% 电量。
轨迹层不是让机器人 "自己决定人生"，是把 "余量、斜率、时间余量、置信区间" 变成 SDM 的可审计输入 —— 和 SAIM 的 OOD 分数一样，都是证据，不是独裁者。
07 升一层：安全边界是时变合同
传统 Safety Case 是 "系统满足一组静态假设"。物理 AI 的 Safety Case 应该是 "系统在这些假设下的余量随时间演化"。
安全不是 "正常 / 故障" 二值，是一个时变可信度曲面：
- Halos 回答：现在安全吗？
- 下一代架构要回答：现在还安全多少、以多快速度变不安全、哪个假设正在先死。
传统安全工程相信：先正常，再异常，再故障。物理 AI 的真相是：没有 "正常"，只有 "暂时还没碰到边界"。
08 标准界的动向
IEEE 2851-2023 已把 functional safety、reliability、cybersecurity、time determinism 放进可依赖生命周期；P2851.1 管 FuSa 与 Reliability，P2851.2 从 2025 年 3 月起管 FuSa 与 Cybersecurity。
也就是说，标准界知道要做跨属性数据互操作，但运行时 "退化轨迹是否被安全栈消费" 仍是空白。
09 结语
Halos 解决了运行时的故障响应 —— 它给了架构，SAIM 给了 OOD 检测，SDM 给了状态机决策。但它的运行时决策核心，仍是 "当前状态 + 事件 + 状态机"。
下一个十年的安全架构，要解决的不是 "系统坏了没有"，而是 "系统正在以多快速度失去可信度，以及我们敢不敢在它还能刹车的时候先松油门"。
顺着这条线再往下走，还有一个更底层的盲区：Halos 的安全架构是为 "能安全停下来的系统" 设计的。人形机器人处在动态平衡里，未必随时停得下来 —— 有些系统，连 "踩刹车" 这件事本身都是未解的工程问题。
