重新思考 功能安全（ISO 26262）

title: “重新思考 功能安全（ISO 26262）”
authors: “[DeepThink.ai]”
affiliations: “[AI Genius Institute]”
keywords: “功能安全；ISO 26262；预期功能安全；运行时保证；保证案例；持续认证；AI 定义汽车；运行设计域”

标题解释假设：本文把“功能安全（ISO 26262）”理解为以 ISO 26262:2018 为核心的道路车辆功能安全体系，包括危害分析与风险评估、汽车安全完整性等级分配、系统/硬件/软件开发、验证确认、变更管理与运行服务要求；把“重新思考”理解为对该体系隐含假设、适用边界与证据模式的批判性审视，而不是对标准条款的修订建议。本文的讨论对象是具备学习型感知、数据驱动决策、空中下载（Over-the-Air，OTA）更新或基础模型组件的智能网联汽车，重点覆盖按 SAE J3016 划分的 L2 至 L4 级驾驶自动化 [17]；必要时以机器人、具身智能体作类比，但不把汽车结论直接外推。

论文类型与数值声明：本文是立场/框架型论文，包含问题形式化、参考架构与可复现评估协议。本文未开展实车或大规模仿真实验，不报告任何实测性能数字。文中出现的标准阈值均来自公开标准文本，具体数值与适用条件以标准原文为准；所有实验表格中的数值均以 或 [TODO] 占位。本文引用以公开标准、专著与经典论文为主；受检索条件限制，未对全部条目进行原文页码核验，投稿前应逐条核对版本、页码与链接。

术语约定：本文区分“功能安全”“预期功能安全”与“信息安全”。功能安全关注电气/电子（Electrical/Electronic，E/E）系统故障导致的危害；预期功能安全（Safety of the Intended Functionality，SOTIF）关注没有故障但功能不足或性能受限导致的危害；信息安全关注对抗性攻击导致的机密性、完整性与可用性破坏。本文以功能安全为主线，把信息安全事件视为能力契约违反的一类触发源，但不展开完整的信息安全工程方法。

Abstract

ISO 26262 为道路车辆电子电气系统建立了成熟的功能安全过程体系，但其有效性依赖设计闭合、故障可枚举、统计可证、人类兜底与变更稀少五个假设。人工智能（AI）定义汽车引入学习型感知与决策、开放运行设计域（Operational Design Domain，ODD）、持续数据更新与基础模型组件，使这些假设同时承压。本文重新审视 ISO 26262 的适用范围与认识论基础，提出 CARE（Capability–Assurance–Runtime–Evidence，能力契约—保证案例—运行时强制—证据演化）框架：以能力契约表达安全意图与行为包络，以可辩护的保证案例组织故障、功能不足、认知不确定性与交互风险证据，以独立运行时监控与回退策略强制契约，以证据演化与变更影响闭包维持全生命周期可追溯性。本文形式化风险分解、契约细化、运行时不变式、证据新鲜度与发布门禁，分析监控器可靠性边界与测试选择的计算复杂性。由于尚未开展实测，本文提供可复现的评估协议、基线与消融设计，不报告未经证实的性能数字。CARE 不替代 ISO 26262，而是把其设计期保证延伸到运行期与变更期。

---

你离拥有一支永不停歇、持续进化的 AI 超级研发团队，只差一次 git clone——DeepThink 是 AI Genius Institute & 光剑AI 打造的开源、免费、可自由使用的私有 AI 操作系统（AI OS）：在安全隔离的沙箱中自主执行代码、管理文件、完成超复杂长程任务，作为自托管、多用户、本地优先的 AI Agent Loop Engineering 系统，支持桌面端+浏览器+移动端，让 DeepThink 成为你的全能数字助手；它不止让你使用 AI，更要让你从工具使用者进化为代码创造者，最终成长为可自我繁衍的超级智能体，让每家企业都拥有自己的 AI 超级研发团队，一起走向 AGI——现在就去 git clone，顺手点亮 Star：你收藏的不是一个仓库，而是通往 AGI 的入场券。🚀

DeepThink，开源企业级自主 Agent 超级智能体自进化平台，是从 Harness Engineering 到 Loop Engineering 范式的先行者，面向企业客户的新一代 AI 基础设施（AI Infra）。DeepThink 平台以多 Agent 协作框架为核心，融合 AI 自主编程（AI Coding）、自主进化（Self-Evolving）、全栈可观测性（Full-Stack Observability）、Bug 自修复闭环（Bug Auto-Fix Loop） 与 程序员-Agent 共生协作（Human-Agent Symbiosis），构建一个能持续学习、自我改进、最终成长为超级智能体的企业级 AI 系统。

DeepThink 项目开源代码（如果你觉得好玩，就一起来玩， Star 一下）：
Gitcode: https://gitcode.com/AIGeniusInstitute/deepthink
Github: https://github.com/AIGeniusInstitute/deepthink

---

1 Introduction

汽车安全工程正在从机械与电子系统的故障管理，转向对学习型、数据驱动、持续更新的智能系统的风险管理。一辆“人工智能（AI）定义汽车”的核心能力越来越多地由感知模型、预测模型、规划策略、数据闭环和基础模型组件共同决定；这些组件的行为不是逐行编写出来的，而是从数据与训练过程中涌现出来的。与此同时，车辆仍然要在物理世界中承担碰撞、伤害和生命损失的责任。功能安全因此不再只是“把 E/E 系统做得足够可靠”，而是要回答一个更难的问题：当系统的行为无法被完全枚举、无法在部署前被完全验证、并且会在运行中持续变化时，我们凭什么相信它是足够安全的。

ISO 26262 是当前道路车辆功能安全的核心参照。它为安全生命周期、物品定义、危害分析与风险评估（Hazard Analysis and Risk Assessment，HARA）、汽车安全完整性等级（Automotive Safety Integrity Level，ASIL）、功能安全概念、技术安全概念、软硬件开发、验证确认、变更管理以及运行服务提供了系统的过程要求 [1][2][3][4][5][6][7][8][9]。它的价值在于把“安全”从工程师的直觉转化为可审查的工件、可追溯的需求和可比较的论证。对于由随机硬件失效和系统性软件缺陷主导的风险，ISO 26262 的故障模型、硬件度量与过程纪律仍然有效。

然而，ISO 26262 的有效性依赖一组很少被显式写出的假设。第一，设计边界在部署前闭合：物品、接口、需求和 ODD 可以被稳定地定义，并在开发周期内保持相对不变。第二，危害主要来自可枚举的故障：随机硬件失效与系统性软件缺陷是主要风险源，过程严谨性与测试覆盖可以控制系统性失效。第三，残余风险可以被有限证据度量：硬件失效率、故障注入、测试覆盖和统计抽样足以支撑安全论证。第四，人类驾驶员可以提供可控性兜底：在危害事件发生前，驾驶员能够在可接受的时间内接管或缓解。第五，变更稀少且可审查：变更被视为例外事件，可以通过阶段门、配置管理和变更影响分析来处理。

AI 定义汽车同时挑战这五个假设。学习型感知与规划的行为由数据分布、模型架构、训练目标和部署环境共同决定，难以像传统软件那样把行为分解为可独立验证的单元。模型失效往往不是某个可定位的缺陷，而是输入空间中一片与数据采集、标注偏差、传感器退化和运行环境相关的区域。开放世界中的长尾事件、非平稳分布和持续 OTA 更新，使“用有限测试证明极低失效率”的统计论证变得困难。L3 及以上的驾驶自动化把人类从持续监控中移出，远程操作员的注意力、接管时间和情境意识成为新的瓶颈。模型更新、数据飞轮和供应链中的基础模型组件，使变更成为常态而不是例外。

现有工作已经在不同方向上作出回应。SOTIF 把“没有故障但功能不足”纳入安全视野，用触发条件、已知/未知场景区域和场景化验证组织论证 [10]。ISO/PAS 8800:2024 把人工智能（Artificial Intelligence，AI）安全纳入道路车辆安全生命周期 [11]。UL 4600 强调面向自动驾驶产品的安全案例、论证与置信度 [16]。运行时保证（Runtime Assurance）用简单、可验证的监控器约束复杂控制器，在异常时切换到安全回退策略 [21]。保证案例（Assurance Case）用目标、策略、证据和上下文构成结构化论证 [30]；AMLAS、SACE 等方法进一步把机器学习（Machine Learning，ML）的数据、模型与验证证据组织为可审查的论证 [28][29]。OTA 与软件更新标准则把变更管理、更新包安全和车辆端执行纳入监管视野 [14][18]。

这些工作分别推进了标准、方法或运行时机制，但仍存在一个结构性缺口：它们没有把“能力承诺”“可辩护论证”“运行时强制”和“变更后的再保证”组织成同一条可追溯、可计算、可发布的安全线程。SOTIF 的证据主要形成于部署前，运行时监控往往独立于安全案例，安全案例通常是静态文档，OTA 治理又缺少与证据失效和再保证范围的工程连接。结果是，组织可以在纸面上拥有一份完整的合规档案，却在一次模型更新、一次 ODD 扩展或一次罕见场景暴露之后，无法迅速回答“哪些安全目标仍然成立、哪些证据已经过期、哪些变更必须回滚”。

本文的核心判断是：功能安全需要从“一次性合规证明”转变为“持续托管”（continuous custody）。所谓托管，不是把责任交给某个模型或某个供应商，而是让组织在系统的整个生命周期中持续持有四类能力：明确承诺什么、论证为什么相信、运行时守住承诺、变更后重新证明。基于这一判断，本文提出 CARE 框架，用四个层组织这四类能力：能力契约（Capability Contract，C）、保证案例（Assurance Case，A）、运行时强制（Runtime Enforcement，R）与证据演化（Evidence Evolution，E）。CARE 不替代 ISO 26262、ISO 21448 或 ISO/PAS 8800，而是把它们的设计期工件放入一个持续运行的保证闭环中。

本文的贡献如下：

• 刻画 ISO 26262 的五个隐含假设及其在 AI 定义汽车中的失效机制，给出“故障—功能不足—认知不确定性—交互风险”的四支路风险分解，并明确各支路与现有标准的继承、扩展与新增关系。
• 提出 CARE 四层框架，把能力契约、保证案例、运行时强制与证据演化组织为一条双向可追溯的安全线程，使安全目标、场景、测试、监控器、现场证据与变更影响彼此连接。
• 形式化能力契约及其细化关系、运行时强制不变式、证据新鲜度与变更影响闭包；分析监控器的条件保证边界、测试选择的 NP-难性以及各模块的计算复杂度。
• 给出可复现的评估协议、基线、指标、消融设计与预注册清单；在未完成实测前，不报告任何性能结论，所有结果位置以待填项标注。

本文余下部分安排如下。第 2 节按技术流派梳理相关工作；第 3 节给出问题形式化、CARE 框架、模块细节、生命周期流程与理论性质；第 4 节给出实验设计、指标、主结果模板、消融与分析计划；第 5 节讨论适用边界、组织责任、伦理影响与局限；第 6 节总结并给出可执行的后续工作。

2 Related Work

2.1 功能安全标准谱系

ISO 26262 由多个部分构成，覆盖词汇、功能安全管理、概念阶段、系统级产品开发、硬件级产品开发、软件级产品开发、生产与运行、支持过程以及面向 ASIL 的分析 [1][2][3][4][5][6][7][8][9]。概念阶段通过 HARA 识别危害事件，并依据严重度、暴露度和可控性确定 ASIL；随后把安全目标分解为功能安全需求与技术安全需求。硬件层面使用随机硬件失效概率度量（Probabilistic Metric for Random Hardware Failures，PMHF）、单点故障度量（Single-Point Fault Metric，SPFM）和潜伏故障度量（Latent Fault Metric，LFM）等指标；软件层面强调需求可追溯、方法选择、单元与集成测试、覆盖度以及工具置信度。标准还通过安全要素脱离上下文（Safety Element out of Context，SEooC）、依赖失效分析（Dependent Failure Analysis，DFA）和变更管理处理复用、共因与演化问题。

这套体系的力量在于过程纪律与可审查性。它迫使组织显式写出安全目标、假设、接口和证据，迫使供应商与整车厂在同一套语言下交换工件，也为第三方评估提供了相对稳定的锚点。对于随机硬件失效和传统软件缺陷，ISO 26262 的故障模型与度量仍然适用。

其局限在于危害模型的重心。ISO 26262 关注 E/E 系统的故障行为，安全论证主要在开发阶段完成；它不试图证明系统在开放世界中的全部感知与决策性能，也不为学习型组件的分布外行为提供完整的统计保证。SOTIF 和 ISO/PAS 8800 对这些缺口作了扩展，但扩展的方式仍以“在部署前构建论证”为主。与本文的差异在于：本文保留 ISO 26262 的故障分支作为 CARE 的一个证据支路，同时把能力契约、运行时强制和证据演化提升为同等重要的安全工件。

2.2 预期功能安全与场景化验证

ISO 21448 把安全视野从“故障”扩展到“预期功能”。它用已知安全、已知不安全、未知不安全与未知安全四类场景组织论证，关注功能不足在触发条件作用下产生的危险行为，目标是把已知不安全和未知不安全区域尽可能缩小 [10]。场景化验证方法进一步把 ODD、逻辑场景、具体场景、测试用例和覆盖指标连接起来；ISO 34502 给出了面向自动驾驶系统的场景化安全评估框架 [15]。仿真、封闭场地和道路测试因此成为 SOTIF 论证的主要证据来源。

SOTIF 的重要贡献在于承认“没有故障也可能不安全”。但它的证据逻辑仍然以部署前的场景库为中心：场景库的覆盖度、触发条件的完整性和未知区域的估计，决定了论证的强度。开放世界的长尾事件、语义歧义、传感器退化、道路参与者的策略性行为以及 ODD 边界之外的迁移，很难被一个有限的场景库完全枚举。仿真与真实世界之间的差距，也会削弱场景证据的可迁移性。

与本文的差异在于：CARE 把 ODD 作为版本化的能力契约，而不是一次性的场景筛选条件；把现场监控、事件报告和漂移检测作为更新“未知不安全”区域的持续证据来源；并把场景证据与运行时监控器、变更影响图连接起来。CARE 不否认场景化验证的必要性，而是把它放入一个会随运行数据演化的证据账本。

2.3 运行时保证与安全监控

运行时保证的核心思想是用一个简单、可验证的监控器约束复杂控制器。Simplex 架构是这一思想的经典代表：在复杂控制器之外设置一个经过验证的安全控制器，当监控器判断复杂控制器可能进入不安全区域时，系统切换到安全控制器 [21]。围绕这一思想，研究者发展了安全包络、运行时验证、屏蔽（shielding）、安全不变式、分布外（Out-of-Distribution，OOD）检测和回退控制等机制。其共同目标是：不要求复杂控制器在所有情况下都正确，而是要求系统在异常时能够及时进入可接受的安全状态。

运行时保证的工程价值很高，但它通常依赖三个前提：安全不变式可以被清晰定义；回退控制器经过独立验证并且能够在时限内到达最小风险状态（Minimum Risk Condition，MRC）；监控器本身足够可靠。现有工作往往重点讨论前两个前提，对监控器自身的失效模式、监控器与标称栈之间的共因、监控阈值带来的误干预成本，以及运行时证据如何进入安全案例和变更管理，讨论不足。

与本文的差异在于：CARE 显式区分确定性安全监控与学习型辅助监控，要求最终安全路径上的监控与回退具有独立性和可验证性；把监控器的漏检、误报、迟检、共因和规格错误列为安全案例中的反驳项；并把运行时日志、干预记录和事件证据接入证据账本与发布门禁。

2.4 保证案例与 AI 保证

保证案例用目标、策略、证据、上下文、假设、理由和反驳项构成结构化论证。目标结构化记法（Goal Structuring Notation，GSN）是其中最常用的表示方法之一 [30]。UL 4600 面向自动驾驶产品，强调安全案例、论证与置信度，而不是规定具体技术方案 [16]。AMLAS 把机器学习系统的保证拆分为数据、模型、验证和部署等阶段的安全案例模式 [29]；SACE 则面向复杂环境中的自主系统，给出从危害识别到运行监控的保证指南 [28]。ISO/PAS 8800:2024 进一步把 AI 安全纳入道路车辆安全生命周期，关注 AI 特有的数据、模型、性能和不确定性问题 [11]。

Koopman 对自动驾驶安全度量与安全案例的讨论，强调了“多安全”与可接受风险之间的关系 [23]；AI 安全研究则早已指出规格错误、奖励黑客、分布漂移与可扩展监督等问题 [24]。这些工作提高了 AI 系统安全论证的结构化程度，但多数保证案例仍然是静态文档：它们在某个时间点被编写、评审和签署，随后进入配置管理。证据的新鲜度、适用范围、版本依赖和反驳项状态，往往没有被当作可计算的一等对象。一次模型更新、一次数据源替换或一次 ODD 扩展，可能使大量证据同时过期，但安全案例不会自动告诉审查者“哪些结论仍然成立”。此外，基础模型与供应链的不透明性，使证据的独立性和可追溯性更加困难。

与本文的差异在于：CARE 把保证案例做成版本化、可查询的图，把每个证据项与声明、范围、来源、版本、时间戳、置信度和反驳项关联；用证据新鲜度与变更影响闭包决定何时需要重新论证；并用发布门禁把“证据是否充分”转化为可执行的工程决策。

2.5 持续认证、OTA 与治理

软件更新与持续认证是 AI 定义汽车无法回避的治理问题。ISO 24089:2023 面向软件更新工程，覆盖更新包、更新管理、车辆端执行与信息安全接口 [14]；联合国欧洲经济委员会（United Nations Economic Commission for Europe，UNECE）第 156 号法规要求软件更新管理系统（Software Update Management System，SUMS），第 157 号法规则对自动车道保持系统提出要求 [18]。欧盟《人工智能法案》（Regulation (EU) 2024/1689）对高风险 AI 系统提出风险管理、数据治理、技术文档、记录保存、透明度和人类监督等要求 [35]；NIST AI 风险管理框架（AI Risk Management Framework，AI RMF）用治理、映射、测量、管理四类功能组织 AI 风险 [36]；ISO/IEC 23894 提供 AI 风险管理指南 [34]；ISO/IEC TR 5469 讨论 AI 系统的功能安全 [33]。

这些法规与框架把“持续治理”写进了组织责任，但它们主要规定目标、过程和文档，不直接给出“一次变更需要多大范围的再保证”的工程机制。组织仍然需要自己回答：哪些安全目标受影响、哪些证据过期、哪些测试必须重跑、哪些场景需要重新评估、何时可以发布、何时必须回滚。CARE 的证据演化层与变更影响闭包，正是为这个问题提供一个可操作的中间层。

与本文的差异在于：本文不提出新的监管条款，而是给出一套把监管要求落到工件、证据与发布决策上的工程方法；其有效性依赖于组织授权、数据治理和独立评估，不能替代法律合规判断。

2.6 人机共驾与安全—信息安全耦合

人类监督是功能安全论证中的传统兜底。HARA 的可控性参数假设：在危害事件发生前，驾驶员或其他人类能够采取措施避免或减轻伤害。但人因研究早就指出，自动化会改变人的注意、技能和情境意识；长期监控自动化系统的人可能在关键时刻失去接管能力，这就是“自动化的讽刺”（ironies of automation）[31]。人类对自动化的使用、误用、弃用和滥用，也取决于信任校准、告警设计和任务负荷 [32]。L3 级接管、远程操作和车队监控把这些问题的难度进一步放大。

信息安全与功能安全的耦合同样不可忽视。ISO/SAE 21434 为道路车辆建立了网络安全工程框架 [12]；ISO/TR 4804 讨论自动驾驶系统的安全与网络安全设计、验证和确认 [13]。传感器欺骗、OTA 包篡改、模型供应链污染和远程指令攻击，都可能直接造成能力契约违反。把信息安全简单归入“未知触发条件”，会掩盖攻击者的策略性与适应性。

与本文的差异在于：CARE 把人类监督写成可度量的契约，包括权限、注意力、接管时间、透明度和失败回退；把安全事件作为契约违反的一类触发源，并在证据账本中保留安全证据的接口。完整的信息安全—功能安全联合分析不在本文范围内，但 CARE 的契约与证据结构为这种联合分析预留了位置。

2.7 小结

综上，现有研究已经分别回答了“如何做功能安全”“如何做预期功能安全”“如何做运行时保证”“如何写安全案例”和“如何治理软件更新”。尚未充分回答的是：当这些答案分散在不同标准、不同团队和不同时间尺度上时，组织如何持续地知道自己的安全承诺是否仍然成立。CARE 针对这一缺口，把能力契约、保证案例、运行时强制与证据演化组织为一个持续闭环。

3 Method

3.1 Problem Formulation

3.1.1 系统、能力与风险

设车辆状态空间为 $\mathcal{S}$，可执行动作空间为 $\mathcal{A}$，观测空间为 $\mathcal{X}$。学习型标称策略记为 ${\pi }_{\theta }:\mathcal{X}\to \mathcal{A}$，其中 $\theta$ 表示模型参数，$D$ 表示训练数据。系统在一个运行设计域 $\mathcal{O}\subseteq \mathcal{X}$ 内工作；$\mathcal{O}$ 既包含道路、天气、光照等环境条件，也包含交通参与者、基础设施、通信与人类监督等条件。

本文把一个安全相关能力（Safety-Relevant Capability，SRC）定义为五元组

$$\mathcal{C}=⟨{\pi }_{\theta },\mathcal{O},\mathcal{G},\mathcal{B},\mathcal{H}⟩,$$

其中 G = { g 1 , … , g m } \mathcal{G}=\{g_1,\dots,g_m\} G={g1​,…,gm​} 是安全目标集合，$\mathcal{B}$ 是行为包络（例如速度、加速度、加加速度（jerk）、间距、可行驶走廊等约束），$\mathcal{H}$ 是人类监督契约。安全目标来自 HARA、系统理论过程分析（System-Theoretic Process Analysis，STPA）[19][20] 与 SOTIF 分析的联合结果；它应当是可度量、可监控、可追溯到证据的，而不是仅以自然语言表述的愿望。

对能力 $\mathcal{C}$，定义风险

$$R(\mathcal{C})={\int }_{x\in \mathcal{O}}p(x)P(H\mid x,\mathcal{C})S(H)\mathrm{d}x,$$

其中 $H$ 是危害事件，$S(H)$ 是后果严重度，$p(x)$ 是 ODD 内的暴露分布。安全可接受性要求

$$R(\mathcal{C})\le R_{\mathrm{acc}},$$

$R_{\mathrm{acc}}$ 是由法规、伦理、组织政策与行业实践共同确定的可接受风险水平。式中的概率与严重度通常是估计值，而不是可直接测量的真值；因此，风险论证必须同时报告估计方法、数据来源、适用范围和不确定性。

为避免把不同来源的风险混为一谈，本文使用如下分解作为记账工具：

$$R(\mathcal{C})=R_{\mathrm{fault}}+R_{\mathrm{insuff}}+R_{\mathrm{epist}}+R_{\mathrm{interact}}.$$

其中 $R_{\mathrm{fault}}$ 对应随机硬件失效与系统性软件缺陷，主要由 ISO 26262 的故障分支处理；$R_{\mathrm{insuff}}$ 对应没有故障但功能不足的触发条件，主要由 ISO 21448 的 SOTIF 分支处理；$R_{\mathrm{epist}}$ 对应数据、模型、规格与 ODD 的认知不确定性，包括分布漂移、长尾覆盖不足和仿真—现实差距；$R_{\mathrm{interact}}$ 对应人机交互、多智能体交互以及安全事件引发的行为偏差。需要强调，这四个项不是严格互斥的概率分区，而是风险账本中的四个来源；同一事件可能同时计入多个来源，实际使用时必须避免重复计算。

能力契约（Capability Contract）定义为

$$\Gamma =⟨\mathcal{O},\mathcal{G},\mathcal{B},{\mathcal{A}}_{\mathrm{adm}},T_{\mathrm{resp}},\mathcal{H}⟩,$$

其中 ${\mathcal{A}}_{\mathrm{adm}}\subseteq \mathcal{A}$ 是契约允许的动作集合，$T_{\mathrm{resp}}$ 是从检测到异常到进入安全状态的时间预算，$\mathcal{H}$ 是人类监督契约。契约是 CARE 的“承诺书”：它说明系统在什么范围内、承诺什么样的行为、以什么时限响应异常，以及人类监督承担什么责任。

对两个契约 ${\Gamma }_1$ 与 ${\Gamma }_2$，定义细化关系

$${\Gamma }_2⊑{\Gamma }_1⟺{\mathcal{O}}_2\subseteq {\mathcal{O}}_1,{\mathcal{G}}_1\subseteq {\mathcal{G}}_2,{\mathcal{B}}_2\subseteq {\mathcal{B}}_1,{\mathcal{A}}_{\mathrm{adm},2}\subseteq {\mathcal{A}}_{\mathrm{adm},1},T_{\mathrm{resp},2}\le T_{\mathrm{resp},1}.$$

直观地说，${\Gamma }_2$ 在更小的 ODD 内承诺更强的目标、更紧的包络和更快的响应，因此可以视为对 ${\Gamma }_1$ 的细化。反之，ODD 扩展、目标放宽或响应时限延长都不是细化，必须触发新的证据与再保证。这个关系为 OTA 发布提供了一个简单但重要的判断：新版本要么是旧契约的细化，要么必须被当作新契约重新论证。

3.1.2 ISO 26262 的五个隐含假设

表 1 概括了本文关注的五个隐含假设、它们在 ISO 26262 中的体现，以及 AI 定义汽车中的失效方式。

表 1 ISO 26262 的五个隐含假设及其在 AI 定义汽车中的承压点

假设	在 ISO 26262 中的体现	AI 定义汽车中的现实	直接后果
设计闭合	物品定义、需求分解、接口与 ODD 在开发前相对稳定	学习行为由数据、模型、训练目标和部署环境共同决定，难以完全指定	安全目标到模型行为的追溯变弱
故障本体	以随机硬件失效和系统性软件缺陷为主要风险源	失效常表现为分布性错误、语义错误、数据偏差和模型漂移	硬件失效率指标无法覆盖主要风险
统计可证	PMHF、故障注入、测试覆盖与有限样本支撑论证	长尾、非平稳、开放世界使有限证据难以支撑极低失效率	统计论证依赖强假设，外推困难
人类兜底	HARA 的可控性参数假设人类可及时接管或缓解	L3+ 人类可能移出持续监控；远程操作受注意力与通信限制	可控性假设失效，接管成为新瓶颈
变更稀少	变更管理、阶段门与配置管理处理例外变更	OTA、数据飞轮、模型与供应链更新使变更成为常态	静态安全案例迅速过期

第一，设计闭合假设。ISO 26262 的物品定义、需求分解和 V 模型开发，建立在“系统边界、接口和行为可以被稳定描述”的前提上。传统软件的行为可以由需求、设计和代码逐层追溯；测试覆盖可以作为“需求是否被验证”的代理。学习型模型的行为不是逐行编写的，而是由数据分布、网络结构、损失函数和训练过程共同塑造的。即使工程师能写出“在雨天识别行人”这样的需求，也无法据此枚举模型在全部输入上的行为。安全目标到模型行为之间，只能通过数据覆盖、场景测试、形式化性质和行为监控建立间接联系。

第二，故障本体假设。ISO 26262 的硬件度量针对随机硬件失效，软件过程针对系统性缺陷；两者都假设失效可以被定位到某个组件、某条需求或某个开发阶段。学习型系统的失效往往不是某个可定位的缺陷，而是输入空间中的一片区域：罕见的物体组合、异常光照、遮挡、传感器退化、标注偏差或训练数据中未被代表的道路参与者。一个数据采集偏差可能同时影响大量输入，形成跨组件的共因。硬件失效率、单点故障度量和潜伏故障度量无法覆盖这类风险。

第三，统计可证假设。ISO 26262-5 为不同 ASIL 规定 PMHF、SPFM 和 LFM 目标；以 ASIL D 为例，PMHF 目标处于 $10^{-8}{\mathrm{h}}^{-1}$ 量级，ASIL C 与 ASIL B 通常处于 $10^{-7}{\mathrm{h}}^{-1}$ 量级（具体数值与适用条件以标准原文为准）。这类目标可以用硬件失效率数据、故障注入和可靠性模型支撑。对于学习型系统，相关事件更罕见、更非平稳，且“失败”的定义依赖场景与语义。Kalra 与 Paddock 的研究表明，若要用道路测试以统计置信度证明自动驾驶相对人类驾驶的可靠性优势，所需里程可达数亿英里量级 [22]。这不是说统计方法无效，而是说统计结论必须附带分布假设、置信水平和外推边界；没有这些条件的“零事故”或“低脱离率”不能直接转化为安全证明。

第四，人类兜底假设。HARA 用可控性参数描述人类在危害事件前采取行动的可能性。该参数在 L0–L2 的驾驶辅助语境中有其合理性，但在 L3 及以上，人类可能被移出持续监控；即使保留接管请求，驾驶员的注意力、情境意识和反应时间也取决于任务负荷、告警方式和接管预算。Bainbridge 对自动化讽刺的分析、Parasuraman 与 Riley 对自动化使用与误用的分析，都提醒我们：人类监督不是免费的兜底，而是一种需要设计、训练和测量的能力 [31][32]。如果安全论证把“人类会接管”当作无需证据的假设，那么论证的结论就建立在一个未经检验的前提上。

第五，变更稀少假设。ISO 26262 通过配置管理、变更管理和阶段门处理开发过程中的修改。它假设变更可以被识别、评估、批准，并在发布前完成验证。AI 定义汽车的变更可能来自模型重训、数据源替换、提示词或策略调整、传感器固件升级、地图更新、第三方基础模型版本变化，甚至来自车队数据回流导致的重新训练。变更不一定伴随代码 diff，也不一定经过传统软件发布流程。一次看似“只换模型”的更新，可能改变系统在长尾场景中的行为。静态安全案例无法自动判断哪些证据仍然有效。

除五个假设外，还有两个跨切面问题。其一是供应链证据不对称：基础模型、训练数据、标注服务和工具链可能由不同组织提供，整车厂难以获得完整的训练细节与独立评估。SEooC 的假设在基础模型语境下可能不成立。其二是安全—信息安全耦合：攻击者可以主动寻找模型、传感器或 OTA 链路的弱点，使“未知触发条件”不再是自然分布的一部分，而是具有策略性的对抗输入。本文把这两个问题作为 CARE 的外部接口，而不是在框架内部完全解决。

3.1.3 范围与非目标

本文的范围是道路车辆 L2–L4 驾驶自动化的功能安全，重点讨论学习型感知、预测与规划组件，以及它们与运行时监控、安全案例和 OTA 的关系。本文不试图：

• 提出新的 ISO 26262 条款或替代现有标准；
• 给出条款级的合规映射或认证结论；
• 完整解决信息安全工程、隐私保护或 AI 伦理问题；
• 报告实车、仿真或用户实验的实测结果；
• 假设所有组织都拥有对 ODD、模型和发布流程的完全控制权。对于供应链分工复杂的组织，CARE 的治理层需要按合同与责任边界调整。

3.2 Framework Overview

CARE 由四个层组成，图 1 给出整体结构。其中 R 层的回退策略执行最小风险 maneuver（Minimum Risk Maneuver，MRM），目标是把车辆带入 MRC。

┌──────────────────────────────────────────────────────────────────────────────┐
│                          CARE：持续功能安全保证框架                           │
├──────────────────────────────────────────────────────────────────────────────┤
│  C  能力契约层                                                               │
│      ODD 版本 · 安全目标 · 行为包络 · 可接受动作集 · 响应时限 · 人类监督契约     │
├──────────────────────────────────────────────────────────────────────────────┤
│  A  保证案例层                                                               │
│      故障分支 · 功能不足分支 · 认知不确定性分支 · 交互分支 · 反驳项 · 证据账本    │
├──────────────────────────────────────────────────────────────────────────────┤
│  R  运行时强制层                                                             │
│      信号健康 · 感知一致性 · 行为包络 · 系统健康 · 人机就绪 → 监控器 → 回退/MRM │
├──────────────────────────────────────────────────────────────────────────────┤
│  E  证据演化层                                                               │
│      现场监控 · 漂移检测 · 事件学习 · 变更影响闭包 · 发布门禁 · 周期复审          │
└──────────────────────────────────────────────────────────────────────────────┘
              ▲                                                       │
              └──────── 安全线程：危害↔目标↔假设↔场景↔证据↔监控↔变更 ────────┘

图 1 CARE 四层框架与贯穿全生命周期的安全线程（本文绘制，不含外部数据）。

四个层回答四个不同的问题。C 层回答“系统承诺在什么范围内做什么”；A 层回答“为什么相信这些承诺可以被接受”；R 层回答“运行时如何守住承诺”；E 层回答“变更之后如何继续相信”。四层不是瀑布式的先后关系，而是持续循环：C 层的契约约束 A 层的论证义务，A 层的反驳项约束 R 层的监控设计，R 层的运行证据回流到 E 层，E 层的变更影响又触发 C 层与 A 层的更新。

表 2 概括了四层的核心问题、主要工件、证据与典型失败模式。

表 2 CARE 四层框架

层	核心问题	主要工件	典型证据	典型失败模式
C 能力契约	承诺什么？在什么范围内承诺？	契约、ODD、目标、包络、监督契约	需求评审、一致性检查、可测性分析	契约过宽、目标不可测、假设未写明
A 保证案例	为什么相信风险可接受？	GSN 论证、反驳项、证据账本	测试、证明、仿真、现场数据、专家评审	论证跳跃、证据过期、反驳项被忽略
R 运行时强制	运行时如何守住承诺？	监控器、仲裁器、回退策略、MRC	故障注入、形式验证、时序分析	漏检、误报、迟检、共因、回退失败
E 证据演化	变更后如何继续相信？	证据账本、影响图、发布门禁、复审记录	现场监控、漂移检测、事件报告、OTA 审计	证据债务、漂移未察觉、变更影响漏判

CARE 的设计遵循五条原则。

P1 契约先于模型。 任何学习型组件进入安全论证之前，必须先有明确的能力契约。契约不是模型的附属说明，而是模型的设计约束与验收标准。没有契约，模型评估只能得到“在某个数据集上表现如何”，无法回答“是否满足安全目标”。

P2 独立强制。 最终安全路径上的监控与回退应当是确定性的、可独立验证的，并且尽量与标称栈解耦。学习型监控可以作为辅助信号，但不应在缺乏独立验证的情况下单独承担安全关键决策。独立性不是一句口号，而是需要在传感器、计算、供电、软件和开发团队上做出具体安排。

P3 证据是一等公民。 每一条安全声明都应当有对应的证据项；每个证据项都应当有范围、来源、版本、时间戳、置信度、评审者和反驳项。证据不是附录中的一张表，而是可查询、可更新、可失效的工程对象。

P4 变更是默认状态。 不要把变更当作例外。系统设计、证据组织和发布流程都应当假设模型、数据、地图、传感器和供应链会持续变化。再保证不是一次性的项目，而是常规运营的一部分。

P5 不做单一指标优化。 安全、可用性、舒适性、成本、证据质量与发布速度是多目标关系。用单一指标（例如碰撞率、脱离率、测试覆盖率）驱动决策，容易产生古德哈特定律式的行为：指标被优化了，但真实风险没有下降，甚至被转移到未被测量的维度。

3.3 C：能力契约

能力契约是 CARE 的起点。它把“安全”从抽象目标转化为一组可检查的承诺。一个完整的契约至少包含以下要素。

（1）能力与边界。 说明系统提供什么能力、不提供什么能力、与哪些外部系统交互。例如，“在城市道路中执行车道保持与自适应巡航”与“在无保护左转中自主通行”是不同能力，不能共用同一套安全论证。能力边界应当与物品定义、接口定义和责任边界一致。

（2）ODD。 ODD 不是一句“城市道路”，而是一个多维条件集合。本文建议至少覆盖以下维度：

• 运行条件：道路等级、车道数、曲率、坡度、路面材料、施工状态；
• 环境条件：天气、光照、能见度、积水、积雪、扬尘；
• 交通条件：交通密度、参与者类型、速度分布、异常行为；
• 基础设施：标线、信号灯、标志、路侧单元、地图新鲜度；
• 数字条件：通信覆盖、时延、远程监督可用性、OTA 通道；
• 人类条件：驾驶员/操作员状态、接管时间预算、培训与权限。

ODD 应当机器可读、可版本化，并与场景库、测试用例和运行时监控器共享同一套本体。否则，契约中的 ODD 只是一段文字，无法驱动测试与监控。

（3）安全目标。 安全目标来自 HARA、STPA 与 SOTIF 的联合分析。HARA 提供危害事件、严重度、暴露度和可控性；STPA 提供控制结构、不安全控制动作和损失场景；SOTIF 提供功能不足、触发条件和已知/未知区域。三者结合，才能既覆盖故障，又覆盖功能不足和交互风险。安全目标应当尽量写成可观测、可判定的形式，例如“在契约 ODD 内，系统不得导致与弱势道路使用者发生超过可接受严重度的碰撞”，并明确“可接受严重度”的判定依据。

（4）行为包络。 行为包络把安全目标转化为对轨迹和控制的约束，包括速度上限、加速度与jerk限制、最小跟车距离、横向偏差、可行驶走廊、舒适度边界等。包络的取值来自车辆动力学、道路几何、法规、组织政策和风险分析，不应由模型自行决定。包络既是设计约束，也是运行时监控器的检查对象。

（5）响应时限。 契约必须规定从异常检测到进入安全状态的时间预算 $T_{\mathrm{resp}}$。该预算应当小于故障容忍时间间隔（Fault-Tolerant Time Interval，FTTI），并覆盖感知、决策、通信、执行器响应和机械延迟。对于不同的异常类别，可以设置不同的时限；但每个时限都必须有对应的监控器和回退策略。

（6）人类监督契约。 如果系统依赖驾驶员、远程操作员或车队监控员，契约必须写明：谁在什么条件下拥有何种权限；接管请求以什么方式发出；操作员需要多少时间恢复情境意识；如果操作员未响应，系统如何自动进入 MRC；如何测量操作员的注意力、负荷和接管成功率。人类监督不是“有人在旁边”即可，而是一项需要设计、训练和验证的能力。

契约需要经过四类检查。一致性检查确认安全目标、行为包络与 ODD 之间没有矛盾；可行性检查确认在包络内至少存在一个可执行策略；可测性检查确认每个条款都有对应的测试或监控方法；范围检查确认契约覆盖了预期的运行场景与责任边界。对于简单的不变式，可以使用形式化工具检查；对于语义性条款，需要领域专家评审与场景化验证。

契约细化关系在 OTA 场景中尤其有用。若新版本只是在更小的 ODD 内运行、采用更紧的包络或更快的响应，那么它可以被视为旧契约的细化，再保证范围可以限定在受影响的分支。若新版本扩展 ODD、放宽包络或改变安全目标，那么它不是细化，必须按新契约重新论证。这个判断看似简单，却能阻止“用一次模型更新悄悄扩大运行范围”的常见风险。

下面给出一个仅用于说明的定性例子。某城市路口能力契约规定：在晴天、干燥路面、有信号灯且地图新鲜度满足要求的条件下，系统可以自主通过路口；安全目标包括避免与行人、骑行者和其他车辆发生超过可接受严重度的碰撞；行为包络限制路口内的最高速度与横向加速度；人类监督契约要求远程操作员在收到接管请求后于规定时限内确认，否则系统自动执行最小风险 maneuver。该例子不包含任何真实产品参数，也不构成安全结论；它只说明契约如何把 ODD、目标、包络和监督组织成可检查的条款。

3.4 A：可辩护的保证案例

保证案例把契约与证据连接起来。CARE 采用 GSN 的基本结构：目标（Goal）说明要论证的命题；策略（Strategy）说明如何分解；子目标（Sub-goal）承接分解后的义务；解（Solution）指向证据；上下文（Context）与假设（Assumption）限定论证范围；理由（Justification）说明策略的合理性；反驳项（Defeater）指出论证可能失效的条件 [30]。

CARE 的顶层目标可以写成：“在能力契约 $\Gamma$ 规定的 ODD 与监督条件下，系统的残余风险不超过 $R_{\mathrm{acc}}$。” 顶层策略按四类风险来源分解为四个分支，如表 3 所示。

表 3 保证案例的四个分支

分支	主要危害来源	主要方法	证据示例	与现有标准的关系
故障分支	随机硬件失效、系统性软件缺陷	HARA、FMEA、DFA、ASIL、故障注入	失效率数据、诊断覆盖、故障注入结果	继承 ISO 26262
功能不足分支	触发条件、性能边界、语义歧义	SOTIF、场景化测试、仿真、封闭场地	场景覆盖、触发条件分析、边界测试	扩展 ISO 21448
认知不确定性分支	数据偏差、分布漂移、模型不确定性、规格不完整	数据治理、OOD 检测、不确定性量化、鲁棒性测试	分布测试、长尾评估、漂移监控	扩展 ISO/PAS 8800 与 AI 保证方法
交互分支	人机共驾、多智能体互动、安全事件	STPA、人因实验、威胁分析、红队测试	接管实验、冲突场景、攻击注入	扩展 ISO 26262、ISO 21448、ISO/SAE 21434

四个分支不是彼此独立的“保险箱”。故障可能放大功能不足，功能不足可能诱发危险的人机交互，安全事件可能同时触发多个分支。安全案例必须显式记录跨分支的交互，而不是把每个分支单独论证后简单相加。

证据是保证案例的支撑。CARE 区分五类证据：

• 形式证据：定理证明、模型检查、静态分析、类型系统、控制器不变式证明；
• 经验证据：场景测试、仿真、封闭场地、道路测试、故障注入；
• 过程证据：评审、审计、工具置信度、配置管理、开发流程符合性；
• 专家证据：人因评审、领域专家判断、独立安全评估；
• 运行证据：现场日志、接管记录、近失事件、事件报告、漂移监控。

每类证据都有不同的强度、适用范围和失效速度。形式证据的适用范围窄，但在其假设内强度高；经验证据依赖场景分布，外推需要谨慎；过程证据说明“组织如何工作”，但不直接证明产品行为；专家证据可以覆盖难以量化的因素，但需要管理主观性；运行证据最贴近真实世界，但受车队规模、运行里程和事件报告质量限制。CARE 不把不同证据简单折算成一个分数，而是要求每个证据项明确其声明、范围和局限。

反驳项是保证案例中最容易被忽略、却最重要的部分。CARE 要求至少记录以下反驳项：

• 监控器规格错误或漏检；
• ODD 漂移或运行条件超出契约；
• 训练数据偏差或标注错误；
• 仿真—现实差距；
• 人类监督失效或接管时间不足；
• 供应链组件版本变化；
• 安全事件或对抗性输入；
• 指标被优化但真实风险未下降；
• 证据本身过期或适用范围不匹配。

每个反驳项都有状态（开放、已缓解、已关闭）、负责人和证据链接。未解决的关键反驳项应当阻止发布，而不是被写在附录里“已知但接受”。

CARE 的保证案例是版本化的。每次契约变更、模型更新、数据源替换或 ODD 扩展，都会生成新的案例快照；快照之间可以比较目标、策略、证据和反驳项的变化。案例不是一份 PDF，而是一个可查询的图：从任一安全目标出发，可以追溯到支撑它的场景、测试、监控器和现场证据；从任一现场事件出发，可以反向追溯到受影响的安全目标、假设和变更。

为了保证论证的独立性，CARE 要求评审者、工具和数据来源尽可能独立于开发团队。用同一个模型验证自己、用同一批数据训练和测试、用同一套工具生成和检查证据，都会削弱论证强度。独立性不是绝对要求，而是需要在案例中显式说明并评估的维度。

3.5 R：运行时强制

运行时强制层把契约变成运行时的硬约束。其基本结构是：学习型标称栈产生候选动作；安全监控器根据独立观测与状态判断当前是否仍处于契约允许的区域；仲裁器根据监控结果选择标称动作或回退动作；执行器执行最终动作。图 2 给出结构示意。

┌──────────────┐    a_nom    ┌──────────────┐    a_safe    ┌──────────────┐
│ 学习型标称栈  │ ──────────▶ │  安全仲裁器   │ ──────────▶ │ 执行器/车辆   │
│ 感知·规划·控制│             │  (确定性)     │             │              │
└──────┬───────┘             └──────▲───────┘             └──────┬───────┘
       │ 观测/状态                  │ 监控结果                    │ 状态反馈
       ▼                            │                             │
┌──────────────┐   ┌────────────────┴──────────────┐   ┌─────────▼────────┐
│ 独立传感器/健康│──▶│ 安全监控器：信号·感知·包络·系统·人机 │◀──│ 车辆状态/执行器反馈 │
└──────────────┘   └───────────────────────────────┘   └──────────────────┘

图 2 运行时强制结构（本文绘制）。最终安全路径上的监控与仲裁应尽量独立于学习型标称栈。

监控器可以分层设计，如表 4 所示。

表 4 运行时监控的层级

层级	监控对象	示例信号	典型触发动作
L0 信号健康	传感器、通信、时钟、电源	丢帧、校验失败、时延超限、饱和、温度异常	切换冗余、降级、告警
L1 感知一致性	检测、跟踪、定位、地图匹配	多帧/多模态不一致、OOD 分数、置信度骤降	限速、融合冗余、请求接管
L2 行为包络	规划轨迹与控制输出	碰撞时间、间距、横向误差、加速度/jerk 越界	重规划、减速、MRM
L3 系统健康	计算、执行器、通信链路	算力不足、执行器反馈偏差、总线错误	安全停车、切换到备用通道
L4 人机就绪	驾驶员、远程操作员、监督链路	注意力、接管时间、通信质量、确认超时	请求接管、自动 MRM

设监控器输出 M ( s t ) ∈ { 0 , 1 } M(s_t)\in\{0,1\} M(st​)∈{0,1}，其中 $M(s_t)=1$ 表示当前状态满足契约允许条件。运行时策略为

$$a_t=\{\begin{array}{ll}{\pi }_{\theta }(s_t),& M(s_t)=1,\\ {\pi }_{\mathrm{fb}}(s_t),& M(s_t)=0,\end{array}$$

其中 ${\pi }_{\mathrm{fb}}$ 是回退策略。回退策略应当简单、可独立验证，并在有限时间内把车辆带入 MRC 或安全状态。根据异常严重程度，系统可以设置多个运行模式：

• M0 名义模式：所有监控通过，执行标称策略；
• M1 降级模式：收紧速度、间距或可用动作集，但仍由标称栈执行；
• M2 最小风险 maneuver：执行预设的减速、靠边或停车轨迹；
• M3 安全停车/接管：在允许的条件下请求人类接管，超时后自动停车；
• M4 紧急干预：由独立安全通道直接限制执行器输出，避免立即碰撞。

模式之间应当有明确的进入条件、退出条件和最小停留时间，避免在边界附近来回切换。切换本身也需要被监控，因为频繁切换会增加执行器负担、乘员不适和后方交通风险。

监控阈值的选择是一个代价敏感问题。设 $\tau$ 为监控阈值，$P_{\mathrm{miss}}(\tau )$ 为漏检率，$P_{\mathrm{fa}}(\tau )$ 为误报率，$c_h$ 为漏检导致的期望危害成本，$c_f$ 为误报导致的干预成本（包括追尾风险、可用性损失和用户不信任），则一个简化的阈值选择问题为

$${\tau }^{\star }=\arg \underset{\tau \in [0,1]}{\min }\left(c_h{P}_{\mathrm{miss}}(\tau )+c_f{P}_{\mathrm{fa}}(\tau )\right).$$

该式不是要给出一个普适阈值，而是强调：监控器不能只按准确率或 AUROC 评价；在安全关键场景中，漏检与误报的成本高度不对称，且随车速、交通密度、道路类型和乘员状态变化。工程上应使用上下文条件化的阈值、滞回机制和多级升级策略，并通过现场数据持续校准。

命题 1（运行时强制的条件保证）：假设 A1–A4 成立：

• A1（监控灵敏度）：若在响应时限内存在可达的契约违反事件 $V$，则 $P(M=0\mid V)\ge 1-{\delta }_m$；
• A2（回退有效性）：若监控器触发，则回退策略在时限内到达 MRC 的概率至少为 $1-{\delta }_{\mathrm{fb}}$；
• A3（独立性）：监控器与回退策略不会与标称栈发生未加约束的共因失效；
• A4（时序）：从检测到执行回退的总时间小于 FTTI。

则在一次决策周期内，未恢复契约违反的概率满足

$$P(\text{未恢复的 }V)\le {\delta }_m+{\delta }_{\mathrm{fb}}.$$

证明见附录 B.1。这个命题的价值不在于给出一个可直接引用的安全数字，而在于把“运行时强制为什么有效”拆成四个可检查的设计义务。${\delta }_m$ 和 ${\delta }_{\mathrm{fb}}$ 通常是未知的；它们必须通过故障注入、形式验证、独立评估和现场数据估计。若 A1 或 A3 不成立，命题的结论就不成立；这正是许多运行时保证方案在工程中失效的原因。

监控器本身有一组不可忽视的失效模式：漏检、误报、迟检、共因、规格错误、阈值漂移、传感器退化和对抗性操纵。其中“监控器悖论”尤其值得注意：监控器越敏感，越容易误报；误报会导致不必要的急刹、靠边或接管，进而增加追尾、交通流扰动和用户关闭系统的风险。一个过于保守的监控器可能比没有监控器更危险。缓解措施包括：确定性不变式与学习型异常检测分层；多级告警与滞回；对误报进行代价敏感的现场评估；保留独立于监控器的硬件安全通道；以及把监控器的失效模式纳入保证案例的反驳项。

对于学习型监控器，本文的建议是谨慎的：它可以作为辅助信号，用于提前降级、请求接管或触发数据回传；但在最终安全路径上，优先使用可解释、可验证、计算开销可控的确定性检查。若必须使用学习型监控器，它应当经过独立训练数据、分布外测试、对抗测试和形式化边界分析，并且不能与标称栈共享同一个失败模式。

3.6 E：证据演化与变更治理

证据演化层解决“变更之后如何继续相信”的问题。其核心工件是证据账本（Evidence Ledger）。账本中的每个证据项至少包含表 5 所示的字段。

表 5 证据账本字段

字段	含义	示例
evidence_id	证据唯一标识	EV-2026-0001
claim_id	支撑的声明或子目标	G1.2
type	证据类型	形式/经验/过程/专家/运行
scope	适用 ODD、场景或组件范围	城市路口、晴天、L2
method	生成方法	场景测试、故障注入、定理证明
source	数据、工具、模型或评审来源	仿真平台版本、测试报告
version	证据版本	v1.3
timestamp	生成或更新时间	2026-09-01
confidence	置信度或强度评级	高/中/低，附依据
reviewer	评审者与独立性说明	独立安全评审组
defeaters	关联的反驳项	仿真—现实差距
status	状态	有效/过期/待复核/撤销

证据会随时间失效。形式证明在其假设不变时相对稳定；场景测试会因 ODD 扩展、传感器更换或模型更新而失效；现场数据会因交通环境变化、季节变化和车队构成变化而漂移；仿真证据会因仿真器版本、场景库和参数变化而失去可比性。CARE 用一个简单的新鲜度函数表示这种衰减：

$${\varphi }_j(t)=\exp \left(-{\lambda }_j(t-t_j)\right),$$

其中 $t_j$ 是证据 $j$ 的生成或最后复核时间，${\lambda }_j>0$ 是衰减率。形式证明、设计评审等证据的 ${\lambda }_j$ 可以设得较小；现场数据、仿真结果和供应商声明的 ${\lambda }_j$ 应设得较大，尤其是在模型、数据或 ODD 发生变化时。

基于新鲜度，可以定义一个证据充分性指数：

$$\mathrm{ES}(t)=\sum _j{w}_j{\varphi }_j(t)1\left[{\mathrm{scope}}_j\supseteq {\mathrm{scope}}_{\mathrm{req}}\right],$$

其中 $w_j$ 是证据权重，${\mathrm{scope}}_{\mathrm{req}}$ 是当前声明所需的范围。发布门禁要求

$$\mathrm{Release}(t)=1⟺\mathrm{ES}(t)\ge \theta \wedge \nexists d\in {\mathcal{D}}_{\mathrm{open}}:\mathrm{critical}(d),$$

其中 $\theta$ 是充分性阈值，${\mathcal{D}}_{\mathrm{open}}$ 是未关闭的反驳项集合。需要强调，$\mathrm{ES}(t)$ 是一个工程启发式指标，不是“安全概率”。权重和阈值需要领域专家校准，并做敏感性分析；把 $\mathrm{ES}(t)$ 当作概率使用，会制造虚假的精确性。

漂移检测是证据演化的另一个关键机制。系统应当监控输入分布、场景构成、传感器健康、模型置信度、接管率、近失事件和事件报告，识别协变量漂移、标签漂移和概念漂移。统计检验（例如最大均值差异、Kolmogorov–Smirnov 检验）可以作为辅助信号，但不能替代对实际失效机理的分析。漂移本身不是坏事：它可能意味着系统运行范围扩大或交通环境变化；关键是漂移是否使原有证据的适用范围失效。

变更影响分析把变更与证据连接起来。把需求、假设、场景、测试、监控器、证据项、模型版本和数据版本组织为有向图 $G=(V,E)$。一次变更 $\Delta \subseteq V$ 的影响闭包定义为

$$I(\Delta )=N^{+}(\Delta ),$$

即从变更节点出发沿依赖边可达的所有节点。再保证范围至少包括 $I(\Delta )$，以及任何其适用范围与 $I(\Delta )$ 相交的证据项。再保证成本可以粗略表示为

$$\mathrm{Cost}(\Delta )=\sum _{v\in I(\Delta )}{c}_v+\sum _{e:\mathrm{scope}(e)\cap I(\Delta )\ne \varnothing }{c}_e^{\mathrm{reval}},$$

其中 $c_v$ 是节点更新成本，$c_e^{\mathrm{reval}}$ 是证据重新验证成本。该式用于发布规划与资源分配，不应被理解为精确的财务模型。

根据变更对契约的影响，CARE 把 OTA 变更分为若干类别，如表 6 所示。

表 6 变更类别与再保证要求

类别	变更示例	契约影响	再保证范围	发布要求
0 非安全相关	界面、日志、非安全相关配置	无	回归测试	常规发布
1 参数校准	舒适度参数、控制增益	包络内	影响子图	影子模式 + 金丝雀
2 模型更新	感知/预测/规划模型更新	同 ODD、同安全目标	影响子图 + 场景回归	金丝雀 + 现场监控 + 回滚条件
3 ODD 扩展	新城市、新天气、新道路类型	契约变更	全量再保证	分阶段发布 + 监管沟通
4 架构/硬件变更	新传感器、新执行器、新计算平台	安全概念变更	全量再保证 + 独立评估	重新评估 + 重新发布

表 6 的类别不是法规分类，而是工程分类。实际使用时，应与 ISO 24089、UNECE R156、ISO 26262 变更管理以及组织内部的质量体系对齐。关键不是类别的名称，而是“变更影响契约的哪些条款、哪些证据因此失效、发布前必须补什么”。

证据演化层还需要组织机制。建议至少设置以下角色：安全委员会（批准契约与关键变更）、独立评估者（审查保证案例与证据独立性）、发布授权人（执行发布门禁）、数据治理负责人（管理数据来源、隐私、偏差与版本）、供应商证据负责人（维护外部组件证据）、事件响应负责人（处理现场事件与回滚）。这些角色可以由同一组织内的不同人员承担，但职责与独立性应当在安全案例中写明。

3.7 训练、部署与运行流程

CARE 的生命周期由两个环组成：开发环与运行环。开发环继承 ISO 26262 的 V 模型思想，负责危害分析、契约定义、架构设计、模型训练、验证与保证案例构建；运行环负责现场监控、事件学习、漂移检测、变更影响分析与再保证。图 3 给出双环结构。

             ┌────────────────────── 开发环（设计期） ──────────────────────┐
             │  危害分析 → 安全目标 → 契约 → 架构/模型 → 验证 → 保证案例      │
             └───────────────▲──────────────────────────────┬──────────────┘
                             │                              │ 发布
                             │                              ▼
             ┌───────────────┴──────── 运行环（运行期） ─────────────────────┐
             │  现场监控 → 事件/漂移 → 证据账本 → 变更影响 → 再保证 → 发布门禁   │
             └──────────────────────────────────────────────────────────────┘

图 3 开发环与运行环（本文绘制）。两个环共享同一套契约、证据账本与安全线程。

在训练阶段，数据治理是安全工作的起点。需要记录数据来源、采集条件、标注规范、隐私处理、偏差评估、场景覆盖和版本哈希；需要区分训练、验证、测试和现场数据，避免泄漏与自证；需要对长尾场景、弱势道路使用者、异常天气和传感器退化进行定向评估。模型训练应当可复现：记录代码、依赖、硬件、随机种子、超参数和数据版本。对于基础模型组件，还应记录供应商版本、许可、已知限制和评估报告。

在部署前，契约需要经过一致性、可行性、可测性和范围检查；监控器需要经过故障注入、时序分析和独立验证；回退策略需要在仿真、封闭场地和受控道路环境中测试；保证案例需要经过独立评审，未解决的关键反驳项必须阻止发布。可以先进入影子模式，让系统在不控制车辆的情况下运行，比较其输出与人类驾驶员或安全基线；再进入小规模金丝雀发布，设置明确的回滚条件。

在运行阶段，系统持续采集监控数据、接管记录、近失事件、传感器健康、模型置信度和 ODD 边界事件。事件报告应当区分“系统失效”“功能不足”“人类因素”“外部干扰”和“未知原因”，并保留原始日志与版本信息。漂移检测与证据新鲜度评估应当定期运行；当证据过期、关键反驳项出现或变更影响闭包触发时，发布门禁应当自动收紧或阻断。周期复审应当覆盖契约、保证案例、监控器有效性、事件趋势和供应商变更。

在退役阶段，需要处理数据保留、模型归档、证据保存和责任追溯。退役不是安全生命周期的终点；历史证据仍然可能用于事故调查、责任认定和后续车型复用。

3.8 Complexity and Theoretical Properties

运行时监控的复杂度取决于检查项的数量与类型。设监控器包含 $k$ 个确定性检查，每个检查的计算量为 $O(1)$，则单步监控的时间复杂度为 $O(k)$，空间复杂度为 $O(k)$。若包含感知一致性检查、轨迹预测或多帧融合，复杂度会上升；工程上需要给出最坏情况执行时间（Worst-Case Execution Time，WCET）预算，并验证其小于响应时限。学习型监控器的复杂度取决于模型规模与输入分辨率，通常远高于确定性检查，因此更适合放在辅助通道。

证据账本的更新与查询可以使用索引结构，单条证据插入与查询的复杂度为 $O(\log n)$，其中 $n$ 是证据项数量。变更影响闭包的计算复杂度为 $O(|V|+|E|)$，其中 $V$ 与 $E$ 分别是依赖图的节点与边。实际系统中，依赖图可能包含数万个节点；增量更新与子图查询是必要的工程优化。

测试选择问题可以形式化为加权集合覆盖。给定需求集合 $R$、候选测试集合 $T$、每个测试 $t\in T$ 覆盖的需求子集 $R_t\subseteq R$ 与成本 $c_t>0$，选择 $T^{\prime }\subseteq T$，使得

$$\underset{T^{\prime }\subseteq T}{\min }\sum _{t\in T^{\prime }}{c}_t\text{s.t.}\bigcup _{t\in T^{\prime }}{R}_t=R.$$

命题 2（测试选择的计算复杂性）：上述加权集合覆盖问题是 NP-难的；贪心算法可以达到 $H_n$ 的近似比，其中 $H_n={\sum }_{i=1}^{n}1/i$ 是第 $n$ 个调和数。证明见附录 B.2。

这个性质有直接的工程含义：在有限预算下，不可能对每一次变更都做全量、穷举的再验证。CARE 的变更影响闭包不是为了“少做测试”，而是为了把测试选择限制在受影响的子图上，再用风险优先级和覆盖约束做可解释的取舍。对于安全关键节点，仍然需要保留强证据，不能用“影响闭包小”作为降低证据标准的理由。

引理 1（证据新鲜度的单调性）：若证据 $j$ 在时间 $t_j$ 后没有更新，且 ${\lambda }_j>0$，则 ${\varphi }_j(t)$ 在 $t\ge t_j$ 上单调递减；在没有新证据的情况下，$\mathrm{ES}(t)$ 不会增加。证明是直接的指数函数性质，见附录 B.3。该引理的意义在于：证据账本不能“自动变好”；发布门禁必须依赖新的证据或明确的复核，而不是时间流逝。

这些性质只说明 CARE 的内部一致性，不证明系统安全。真正的安全结论仍然依赖契约的合理性、监控器的可靠性、回退策略的有效性、证据的真实性和组织的独立性。CARE 提供的是一套把假设显式化、把证据组织起来、把变更纳入闭环的方法；它不能替代工程判断，也不能替代第三方评估。

4 Experiments

4.1 Research Questions and Hypotheses

本文设计如下研究问题：

• RQ1（安全有效性）：在故障注入、分布外场景与组合压力下，CARE 是否降低未恢复的能力契约违反率与危害严重度，相比仅覆盖故障的基线、仅覆盖 SOTIF 的基线和静态安全案例基线？
• RQ2（证据效率）：证据新鲜度与变更影响闭包是否能在不提高逃逸缺陷率的前提下，降低再保证工作量与发布周期？
• RQ3（可用性代价）：运行时监控与回退是否带来误干预、任务完成率下降或乘坐舒适性损失？代价是否可以通过阈值与模式设计控制？
• RQ4（人机监督）：人类监督契约、注意力监控与接管预算是否改善接管成功率与信任校准，尤其是在高负荷场景下？

对应的可检验假设如下。这里只陈述方向与比较关系，不预设数值。

• H1：在故障与 OOD 组合注入下，CARE 的未恢复契约违反率低于仅故障基线；代价是误干预率高于仅故障基线。
• H2：在相同证据预算下，变更影响闭包降低再保证工作量，且逃逸缺陷率不高于全量再验证基线。
• H3：确定性监控器加简单回退能够降低危害严重度；但阈值过敏感会增加误干预与追尾风险，存在代价敏感的最优区间。
• H4：带注意力监控与明确接管预算的人类监督契约，相比通用告警，能够改善高负荷场景下的接管成功率与情境意识。

这些假设可能被证伪。特别是 H2，如果依赖图不完整或证据权重校准不当，影响闭包可能漏掉关键证据，导致逃逸缺陷率上升。实验设计必须允许报告这种失败，而不是只报告支持框架的结果。

4.2 Experimental Platform and Scenarios

实验计划使用开源仿真器与公开数据集，以便复现。CARLA 提供城市驾驶的闭环仿真环境 [25]；nuScenes 提供多模态感知数据 [26]；Waymo Open Dataset 提供大规模感知与行为数据 [27]。三者可以分别用于闭环控制、感知评估和行为分析。具体版本、传感器配置、地图、车辆动力学参数和计算平台需要在实际实验前冻结，并记录版本哈希。

场景设计覆盖以下族：

• 名义场景：正常天气、正常交通、常见道路结构；
• 故障场景：传感器丢帧、延迟、卡死、标定漂移、执行器饱和、通信中断；
• OOD 场景：雨雾、逆光、遮挡、罕见道路参与者、异常交通行为、施工区域；
• 交互场景：切入、加塞、行人突然横穿、紧急车辆、远程接管；
• 组合场景：故障 + OOD、故障 + 交互、OOD + 接管；
• 更新回归场景：模型更新前后行为差异、回滚、金丝雀发布。

表 7 给出实验平台与场景记录模板。

表 7 实验平台与场景设计

维度	设计
闭环仿真	CARLA [25]，城市与郊区道路，固定随机种子
感知数据	nuScenes [26]、Waymo Open Dataset [27]
场景族	名义、故障、OOD、交互、组合、更新回归
注入方式	传感器故障、时延、遮挡、天气、对抗扰动、模型回滚
运行规模	[TODO: 场景数、里程、随机种子数量待定]
计算平台	[TODO: GPU/CPU、内存、实时约束待补充]
车辆动力学	[TODO: 模型与参数待补充]
软件版本	[TODO: 仿真器、模型、依赖版本待补充]

4.3 Baselines and Metrics

实验比较以下基线：

• B1 故障导向基线：按 ISO 26262 风格设计故障检测与安全状态，重点覆盖随机硬件失效和软件缺陷，不包含显式的 OOD 监控与证据演化；
• B2 SOTIF 导向基线：以场景化测试和保守规划为主，覆盖已知功能不足与触发条件，但缺少运行时证据闭环；
• B3 静态安全案例基线：按 UL 4600 风格构建安全案例，定期复审，但不使用证据新鲜度与变更影响闭包；
• B4 CARE 完整框架：C + A + R + E；
• B5 仅运行时监控：在 B1 基础上加入监控与回退，但不做证据演化，用于隔离 R 层的贡献。

指标分为安全、可用性、感知、证据与变更五类，定义见表 8。

表 8 指标定义

类别	指标	定义	方向
安全	未恢复契约违反率	每万公里仿真里程中，监控未触发或回退失败导致的契约违反次数	越低越好
安全	严重度加权危害代理	按碰撞类型、相对速度、参与者类型加权的危害代理	越低越好
安全	MRM 成功率	触发 MRM 后按规定时限到达 MRC 的比例	越高越好
可用性	误干预率	无实际风险时触发降级、MRM 或接管的频率	越低越好
可用性	任务完成率	在契约 ODD 内完成预定路线的比例	越高越好
感知	OOD 检测 AUROC	分布外检测的受试者工作特征曲线下面积	越高越好
感知	检测延迟	从 OOD/故障发生到监控器触发的时延	越低越好
证据	证据新鲜度	按第 3.6 节证据充分性公式计算的指数	越高越好
证据	再保证工作量	变更后重新验证所需的人时或计算时	越低越好
变更	回滚时间	从发现回归到恢复到上一版本的时间	越低越好

AUROC 指受试者工作特征曲线下面积（Area Under the Receiver Operating Characteristic Curve）。这些指标不是安全的充分条件；它们只是用于比较不同设计选择的代理。实验报告必须同时给出指标定义、样本量、置信区间和失败案例。

4.4 Main Results

表 9 给出主结果记录模板。本文不填写任何数值，因为在完成预注册实验之前，任何数字都缺乏可验证来源。

表 9 主结果记录模板（待填）

方法	未恢复违反率（每万公里）	严重度加权危害	MRM 成功率	误干预率	任务完成率	证据新鲜度
B1 故障导向
B2 SOTIF 导向
B3 静态安全案例
B4 CARE
B5 仅运行时监控

结果报告应当遵循以下规则：每个方法使用相同的场景、随机种子和评价脚本；报告均值、95% 置信区间、效应量与样本量；对多重比较作校正；对失败回合单独建表，说明失败原因；不得删除不利结果。若某一方法在部分场景中不可运行，应报告不可运行比例，而不是把它排除在比较之外。

4.5 Ablation Study

消融实验用于识别各层的贡献与交互。表 10 给出消融配置模板。

表 10 消融配置（待填）

配置	安全	可用性	再保证成本	主要观察
CARE 完整	[TODO]	[TODO]	[TODO]	参考配置
去掉 C（弱契约）	[TODO]	[TODO]	[TODO]	契约缺失是否导致证据无法对齐
去掉 A（无案例）	[TODO]	[TODO]	[TODO]	证据是否变成无结构的指标堆叠
去掉 R（无运行时强制）	[TODO]	[TODO]	[TODO]	运行时风险是否上升
去掉 E（无证据演化）	[TODO]	[TODO]	[TODO]	变更后证据过期是否被漏检
去掉确定性监控	[TODO]	[TODO]	[TODO]	学习型监控是否引入新的失效模式
去掉证据新鲜度	[TODO]	[TODO]	[TODO]	过期证据是否被误用
去掉变更影响闭包	[TODO]	[TODO]	[TODO]	再保证范围是否失控或漏项
阈值过敏感/过宽松	[TODO]	[TODO]	[TODO]	监控器悖论是否出现

消融的重点不是证明“每个模块都有用”，而是识别模块之间的交互。例如，去掉 E 可能不会立即提高碰撞率，但会在模型更新后使证据过期；去掉 R 可能在名义场景中表现良好，却在组合故障下迅速失效。实验应当设计能够暴露这些延迟效应的场景，而不是只看单次发布的平均值。

4.6 Analysis Plan

统计分析采用配对设计：同一场景、同一随机种子下比较不同方法；报告风险差、风险比或优势比，以及 95% 自助法（bootstrap）置信区间；对多重比较使用 Holm–Bonferroni 或其他预注册方法校正；对样本量进行功效分析，具体参数 [TODO: 试点数据待补充]。如果场景之间存在强相关性，应使用分层模型或聚类稳健标准误，而不是把每个决策步当作独立样本。

定性分析包括三类。第一，失败案例叙事：对每个未恢复违反、误干预和接管失败，记录场景、系统状态、监控器输出、回退动作和人类反应。第二，专家评审：邀请独立安全评估者审查保证案例、证据账本和变更影响分析，记录分歧与理由。第三，效率分析：测量监控器的最坏情况执行时间、内存占用、通信开销、发布周期和回滚时间。效率分析不能只看平均值，还要报告尾延迟和资源受限条件下的表现。

失效分类见表 11。该表用于统一失败案例的记录口径，避免把不同原因混为一谈。

表 11 失效分类

失效类别	典型例子	检测手段	处置
监控漏检	OOD 未触发、迟检	注入测试、形式边界分析	调整监控、增加冗余、限制 ODD
监控误报	无风险急刹、频繁降级	现场统计、误报根因分析	阈值校准、滞回、上下文条件化
回退失败	MRM 未在时限内完成	故障注入、时序分析	简化回退、冗余执行、收紧契约
共因失效	监控与标称栈共享传感器缺陷	DFA、独立性评审	多样化、隔离、独立通道
规格错误	契约漏掉关键场景	独立评审、STPA、红队	修订契约、补充证据
人机失效	接管超时、注意力缺失	人因实验、日志分析	改进告警、培训、自动 MRM
证据过期	模型更新后旧测试仍被引用	证据账本、影响闭包	重新验证、撤销证据、阻断发布
变更回归	OTA 后行为退化	金丝雀、影子模式、回滚	回滚、根因分析、再保证

4.7 Experimental Limitations

实验设计存在明显限制。第一，仿真—现实差距：CARLA、nuScenes 和 Waymo 数据不能完全代表真实道路的复杂性；感知模型在仿真中的表现可能优于或劣于实车。第二，场景库偏差：场景族的选择会影响结论；如果场景库过度集中于已知风险，CARE 的优势可能被高估。第三，没有实车与车队数据：证据新鲜度、漂移检测和 OTA 治理的真实效果，需要长期运行数据才能评估。第四，人类监督实验受伦理、样本和安全限制，难以覆盖真实高负荷场景。第五，没有第三方认证：本文的框架没有经过认证机构评审，不能作为合规声明。第六，计算资源与实时约束：监控器和证据账本的开销可能在不同硬件上差异很大。

4.8 Reproducibility

实验应当预注册：在数据采集前冻结研究问题、假设、主要终点、场景族、基线、指标、统计方法和停止规则；记录任何偏离预注册的修改。代码、配置、随机种子、模型版本、数据版本、仿真器版本和评价脚本应当归档；在不违反许可与隐私的前提下公开。负结果与失败案例应当与正结果一并报告。具体的数据与代码可用性声明 [TODO: 待补充]。

5 Discussion

5.1 为什么 CARE 不替代 ISO 26262

CARE 的定位是补充，而不是替代。ISO 26262 提供了成熟的词汇、过程、ASIL 方法、硬件度量、供应商接口和审计传统；这些是任何新框架都无法轻易重建的基础设施。CARE 把 ISO 26262 的故障分支保留为保证案例的一支，并继承其设计期工件、变更管理和运行服务要求。不同之处在于，CARE 不把“完成一次评估”当作终点，而是把评估结果放入一个持续运行的契约、监控与证据闭环。

如果把 ISO 26262 比作建筑规范，CARE 更像是建筑的持续运维与结构健康监测：规范告诉你如何设计、如何验收；运维告诉你如何在老化、改造、极端天气和使用方式变化后继续保证安全。两者缺一不可。没有规范，运维失去基准；没有运维，规范只能证明“交付那一刻”的状态。

5.2 适用边界

CARE 适用于 L2 至 L4 的驾驶自动化，尤其是那些具有学习型感知/决策、OTA 更新、远程监督或基础模型组件的系统。对于 L0–L1 的简单驾驶辅助，CARE 的完整四层可能过重，可以只采用契约与证据账本的轻量版本。对于 L5 或完全无人监督的系统，人类监督契约退化为组织层面的远程监控与应急响应，CARE 的 R 层与 E 层需要更强的自治与自证能力。

CARE 的原则也可以迁移到机器人、医疗设备、航空和工业控制，但证据类型、监管要求和风险接受标准不同。不能把汽车场景的结论直接外推到其他领域。对于资源受限的嵌入式系统，运行时监控必须考虑算力、功耗、内存和实时性；确定性检查优先于大型学习型监控器。对于供应链分工复杂的组织，CARE 的治理层需要先解决合同、数据访问和独立评估权限，否则 R 层与 E 层无法落地。

5.3 组织与供应链

功能安全从来不是纯技术问题。CARE 的有效性取决于组织是否愿意把契约、证据和反驳项公开到可审查的程度。建议设置独立的安全委员会与发布授权人，避免“进度压力”直接压倒证据判断；建议把证据质量纳入供应商合同，要求模型卡、数据说明、评估报告、已知限制、版本变更通知和工具置信度证据；建议对基础模型组件建立版本锁定、回归测试和替代方案评估，避免单点依赖。

供应链证据不对称是最大的结构性难题之一。整车厂可能无法获得基础模型的训练数据、架构细节和完整评估结果；供应商可能以商业机密为由拒绝披露。CARE 不能消除这种不对称，但可以通过契约化的证据要求、独立第三方评估、运行时监控和保险/责任安排来缓解。对于无法获得足够证据的组件，组织应当降低其安全关键度、增加冗余、限制 ODD，或选择可替代的方案。

5.4 人类监督与伦理

人类监督契约把“人类兜底”从假设变成可测量的责任。但这也带来伦理问题：谁有权把风险转移给远程操作员？操作员是否具备足够的情境意识和决策时间？接管请求是否会造成注意力陷阱？如果系统在关键时刻要求人类接管，而人类无法及时响应，责任如何分配？CARE 提供证据与追溯，但不能替代伦理与法律判断。

风险分布同样需要被审视。自动驾驶的 ODD 可能优先覆盖商业价值高的城市区域，而忽略农村、低收入社区、弱势道路使用者或极端天气场景。感知数据中的偏差可能对某些人群、肤色、体型、服装或辅助器具识别不足。CARE 的 ODD 与证据账本应当显式记录覆盖范围与缺口，而不是把“未覆盖”隐藏在平均指标后面。

透明性也有限度。要求一个端到端模型解释每一个动作，可能既不现实也无助于安全；更可行的是行为透明性：系统在什么条件下运行、何时降级、为何请求接管、哪些证据支撑当前发布。CARE 的证据账本与运行时日志可以支持这种透明性，但不能保证公众理解或信任。信任应当来自可验证的行为与独立监督，而不是营销话术。

5.5 Limitations

本文的局限主要有六点。第一，缺乏实测：命题 1 的保证是条件性的，${\delta }_m$ 与 ${\delta }_{\mathrm{fb}}$ 没有被测量；CARE 的工程效果需要仿真、封闭场地和车队数据验证。第二，证据充分性指数是启发式：权重、阈值和衰减率需要校准，不能当作概率。第三，监控器的独立性与可靠性难以保证：共因、规格错误和对抗攻击仍然可能使监控失效。第四，变更影响图可能不完整：依赖关系、隐性耦合和供应链变更难以完全枚举。第五，成本与实时性：CARE 的工件和流程会增加工程负担，监控器可能占用稀缺的计算资源。第六，安全—信息安全只作了接口性讨论，没有给出完整的联合分析方法。

5.6 Research and Standardization Agenda

后续工作可以从五个方向推进。第一，与整车厂、一级供应商（Tier-1）和独立评估机构开展试点，把 CARE 的契约、证据账本和发布门禁落到真实车型与真实 OTA 流程中。第二，对确定性监控器进行形式化验证，研究可组合的安全不变式与 WCET 分析；对学习型监控器，研究独立训练、分布外检测和对抗鲁棒性评估。第三，建立开放的场景库、故障注入基准和证据账本格式，使不同组织的结果可以比较。第四，开展人因实验，测量接管时间、注意力、信任校准与远程监督负荷。第五，推动标准化：把 CARE 的工件作为 ISO 26262、ISO 21448、ISO/PAS 8800、UL 4600、ISO 24089 与 UNECE R156 之间的信息性桥梁，而不是另起一套互不兼容的体系。

6 Conclusion

ISO 26262 为道路车辆功能安全提供了成熟的过程基础，但它的有效性依赖设计闭合、故障本体、统计可证、人类兜底和变更稀少五个隐含假设。AI 定义汽车使这些假设同时承压：学习型行为难以完全指定，失效呈现分布性与语义性，长尾与非平稳使有限证据难以外推，L3+ 削弱了人类兜底，OTA 与数据飞轮使变更成为常态。本文认为，功能安全需要从一次性合规证明转向持续托管，并提出 CARE 框架，以能力契约、保证案例、运行时强制和证据演化四个层组织这一转变。

本文的贡献是概念性的、形式化的与工程性的：它给出了五个假设的批判性分析、四支路风险分解、契约细化关系、运行时强制的条件保证、证据新鲜度与变更影响闭包，以及一套可复现的评估协议。本文没有报告实测结果，也不声称 CARE 已经解决了 AI 安全或功能安全问题。CARE 不替代 ISO 26262；它把 ISO 26262 的设计期保证延伸到运行期与变更期，并把“我们凭什么相信”这个问题，变成一组可以持续回答、持续质疑、持续修正的工程工件。

未来工作应当聚焦于可验证的监控器、可比较的证据格式、真实车队数据、人因实验和标准化试点。只有当契约、证据与运行时行为在真实系统中形成闭环，功能安全才算真正从纸面走向道路。

References

[1] ISO 26262-1:2018, Road Vehicles — Functional Safety — Part 1: Vocabulary. International Organization for Standardization, 2018.

[2] ISO 26262-2:2018, Road Vehicles — Functional Safety — Part 2: Management of Functional Safety. International Organization for Standardization, 2018.

[3] ISO 26262-3:2018, Road Vehicles — Functional Safety — Part 3: Concept Phase. International Organization for Standardization, 2018.

[4] ISO 26262-4:2018, Road Vehicles — Functional Safety — Part 4: Product Development at the System Level. International Organization for Standardization, 2018.

[5] ISO 26262-5:2018, Road Vehicles — Functional Safety — Part 5: Product Development at the Hardware Level. International Organization for Standardization, 2018.

[6] ISO 26262-6:2018, Road Vehicles — Functional Safety — Part 6: Product Development at the Software Level. International Organization for Standardization, 2018.

[7] ISO 26262-7:2018, Road Vehicles — Functional Safety — Part 7: Production, Operation, Service and Decommissioning. International Organization for Standardization, 2018.

[8] ISO 26262-8:2018, Road Vehicles — Functional Safety — Part 8: Supporting Processes. International Organization for Standardization, 2018.

[9] ISO 26262-9:2018, Road Vehicles — Functional Safety — Part 9: Automotive Safety Integrity Level (ASIL)-Oriented and Safety-Oriented Analyses. International Organization for Standardization, 2018.

[10] ISO 21448:2022, Road Vehicles — Safety of the Intended Functionality. International Organization for Standardization, 2022.

[11] ISO/PAS 8800:2024, Road Vehicles — Safety and Artificial Intelligence. International Organization for Standardization, 2024.

[12] ISO/SAE 21434:2021, Road Vehicles — Cybersecurity Engineering. International Organization for Standardization and SAE International, 2021.

[13] ISO/TR 4804:2020, Road Vehicles — Safety and Cybersecurity for Automated Driving Systems — Design, Verification and Validation. International Organization for Standardization, 2020.

[14] ISO 24089:2023, Road Vehicles — Software Update Engineering. International Organization for Standardization, 2023.

[15] ISO 34502:2022, Road Vehicles — Test Scenarios for Automated Driving Systems — Scenario Based Safety Evaluation Framework. International Organization for Standardization, 2022.

[16] UL 4600, Standard for Safety for the Evaluation of Autonomous Products. Underwriters Laboratories.

[17] SAE J3016:2021, Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles. SAE International, 2021.

[18] UNECE Regulation No. 157, Automated Lane Keeping Systems (ALKS); UNECE Regulation No. 156, Software Update and Software Update Management System. United Nations Economic Commission for Europe.

[19] Leveson, N. G. Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press, 2011.

[20] Leveson, N. G., Thomas, J. P. STPA Handbook. 2018.

[21] Sha, L. Using Simplicity to Control Complexity. IEEE Software, 18(4): 20–28, 2001.

[22] Kalra, N., Paddock, S. M. Driving to Safety: How Many Miles of Driving Would It Take to Demonstrate Autonomous Vehicle Reliability? Transportation Research Part A: Policy and Practice, 94: 182–193, 2016.

[23] Koopman, P. How Safe Is Safe Enough? Measuring and Predicting Autonomous Vehicle Safety. 2022.

[24] Amodei, D., Olah, C., Steinhardt, J., Christiano, P., Schulman, J., Mané, D. Concrete Problems in AI Safety. arXiv:1606.06565, 2016.

[25] Dosovitskiy, A., Ros, G., Codevilla, F., Lopez, A., Koltun, V. CARLA: An Open Urban Driving Simulator. arXiv:1711.03938, 2017.

[26] Caesar, H., Bankiti, V., Lang, A. H., Vora, S., Liong, V. E., Xu, Q., Krishnan, A., Pan, Y., Baldan, G., Beijbom, O. nuScenes: A Multimodal Dataset for Autonomous Driving. arXiv:1903.11027, 2019.

[27] Sun, P., Kretzschmar, H., Dotiwalla, X., et al. Scalability in Perception for Autonomous Driving: Waymo Open Dataset. arXiv:1912.04838, 2019.

[28] Hawkins, R., Paterson, C., Picardi, C., Jia, Y., Calinescu, R., Habli, I. Guidance on the Safety Assurance of Autonomous Systems in Complex Environments (SACE). University of York, 2022.

[29] Hawkins, R., Paterson, C., Picardi, C., Jia, Y., Calinescu, R., Habli, I. AMLAS: Assurance of Machine Learning for Use in Autonomous Systems. University of York, 2021.

[30] Kelly, T., Weaver, R. The Goal Structuring Notation — A Safety Argument Notation. In Proceedings of the Dependable Systems and Networks 2004 Workshop on Assurance Cases, 2004.

[31] Bainbridge, L. Ironies of Automation. Automatica, 19(6): 775–779, 1983.

[32] Parasuraman, R., Riley, V. Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 39(2): 230–253, 1997.

[33] ISO/IEC TR 5469:2024, Artificial Intelligence — Functional Safety and AI Systems. International Organization for Standardization and International Electrotechnical Commission, 2024.

[34] ISO/IEC 23894:2023, Information Technology — Artificial Intelligence — Guidance on Risk Management. International Organization for Standardization and International Electrotechnical Commission, 2023.

[35] Regulation (EU) 2024/1689, Artificial Intelligence Act. European Parliament and Council of the European Union, 2024.

[36] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST, 2023.

注：参考文献 [1]–[18]、[33]–[36] 为标准、法规或治理框架，版本与适用范围应以发布机构的最新目录为准；[19]–[32] 为公开出版的专著、期刊论文或预印本。本文未对具体页码、DOI 或条款编号作引用，投稿前应逐条核验。

Appendix

A. 符号表

表 12 符号表

符号	含义	首次出现
$\mathcal{S}$	车辆状态空间	3.1.1
$\mathcal{A}$	动作空间	3.1.1
$\mathcal{X}$	观测空间	3.1.1
${\pi }_{\theta }$	参数为 $\theta$ 的学习型标称策略	3.1.1
$\mathcal{O}$	运行设计域	3.1.1
$\mathcal{G}$	安全目标集合	3.1.1
$\mathcal{B}$	行为包络	3.1.1
$\mathcal{H}$	人类监督契约	3.1.1
$R(\mathcal{C})$	能力 $\mathcal{C}$ 的风险	3.1.1
$R_{\mathrm{acc}}$	可接受风险水平	3.1.1
$\Gamma$	能力契约	3.1.1
${\mathcal{A}}_{\mathrm{adm}}$	契约允许的动作集合	3.1.1
$T_{\mathrm{resp}}$	响应时间预算	3.1.1
$⊑$	契约细化关系	3.1.1
$M(s_t)$	运行时监控器输出	3.5
${\pi }_{\mathrm{fb}}$	回退策略	3.5
$\tau$	监控阈值	3.5
${\delta }_m$	监控漏检概率上界	3.5
${\delta }_{\mathrm{fb}}$	回退失败概率上界	3.5
$t_j$	证据 $j$ 的时间戳	3.6
${\lambda }_j$	证据 $j$ 的衰减率	3.6
${\varphi }_j(t)$	证据 $j$ 的新鲜度	3.6
$\mathrm{ES}(t)$	证据充分性指数	3.6
$G=(V,E)$	依赖图	3.6
$I(\Delta )$	变更 $\Delta$ 的影响闭包	3.6
$H_n$	第 $n$ 个调和数	3.8

B. 证明与推导

B.1 命题 1 的证明

设 $V$ 为一次决策周期内存在可达契约违反的事件，$M=0$ 表示监控器触发，$F$ 表示回退失败。由 A1，

$$P(M=1\mid V)\le {\delta }_m.$$

由 A2，

$$P(F\mid M=0)\le {\delta }_{\mathrm{fb}}.$$

未恢复的违反事件可以写为

{ 未恢复的  V } ⊆ { M = 1 ∣ V } ∪ { F ∣ M = 0 } . \{\text{未恢复的 }V\} \subseteq \{M=1\mid V\}\cup\{F\mid M=0\}. {未恢复的 V}⊆{M=1∣V}∪{F∣M=0}.

由并集上界，

$$P(\text{未恢复的 }V)\le P(M=1\mid V)+P(F\mid M=0)\le {\delta }_m+{\delta }_{\mathrm{fb}}.$$

证毕。该证明不要求 $M$ 与 $F$ 独立；并集上界对任意事件成立。但 A3 仍然是必要的，因为若监控器与回退策略和标称栈共享共因，${\delta }_m$ 与 ${\delta }_{\mathrm{fb}}$ 的估计可能严重偏低，甚至命题的建模前提（把 $V$ 与 $M$ 当作可区分事件）都不成立。

B.2 命题 2 的证明

加权集合覆盖是经典的 NP-难问题。给定一个集合覆盖实例，令需求集合 $R$ 为全集，候选测试 $T$ 为集合族，测试 $t$ 覆盖 $R_t$，成本 $c_t=1$，则最小化测试成本等价于最小化集合覆盖的集合数量。集合覆盖是 NP-难的，因此加权集合覆盖也是 NP-难的。

贪心算法每次选择“单位成本覆盖未覆盖需求最多”的测试，直到覆盖全部需求。标准分析表明，贪心算法的近似比为 $H_n={\sum }_{i=1}^{n}1/i\le \ln n+1$，其中 $n=|R|$。证毕。

B.3 引理 1 的证明

对 $t\ge t_j$，

$$\frac{\mathrm{d}}{\mathrm{d}t}{\varphi }_j(t)=\frac{\mathrm{d}}{\mathrm{d}t}\exp (-{\lambda }_j(t-t_j))=-{\lambda }_j\exp (-{\lambda }_j(t-t_j))<0.$$

因此 ${\varphi }_j(t)$ 单调递减。若没有新证据加入，$\mathrm{ES}(t)$ 是若干非增函数的非负加权和，因此也不会增加。证毕。

C. 标准映射

表 13 给出 CARE 与相关标准的概念映射。该映射是信息性的，不构成条款级合规声明。

表 13 CARE 与相关标准的概念映射

标准/部分	主要关注点	CARE 对应层	关系
ISO 26262-3	HARA、安全目标、功能安全概念	C、A	继承并补充契约与动态证据
ISO 26262-4	系统架构、技术安全需求、FTTI	C、R	继承 FTTI，扩展运行时强制
ISO 26262-5	硬件随机失效、PMHF/SPFM/LFM	A	作为故障分支证据之一
ISO 26262-6	软件单元、集成、覆盖、工具置信度	A、R	继承软件过程，扩展监控器验证
ISO 26262-7	生产、运行、服务、退役	E	扩展为持续运行证据与变更治理
ISO 26262-8	配置管理、变更管理、支持过程	E	扩展为证据账本与影响闭包
ISO 26262-9	ASIL 分解、依赖失效分析	C、A	用于故障分支与独立性论证
ISO 21448	SOTIF、触发条件、已知/未知场景	C、A、E	扩展为动态 ODD 与现场证据
ISO/PAS 8800	AI 安全、数据与模型保证	A、E	作为认知不确定性分支的重要参考
ISO/SAE 21434	网络安全工程	C、A、E	作为交互分支的接口
ISO 24089	软件更新工程	E	变更分类与发布门禁的参考
ISO 34502	场景化安全评估	A、E	场景证据的组织框架
UL 4600	自动驾驶安全案例	A	保证案例结构的参考
UNECE R156	软件更新管理系统	E	治理与发布流程的参考

D. 证据账本与检查清单

表 14 证据账本模板

字段	填写要求
evidence_id	全局唯一，不可复用
claim_id	对应安全目标或子目标
type	形式/经验/过程/专家/运行
scope	ODD、场景、组件、版本范围
method	生成方法与工具版本
source	数据、模型、报告或评审记录
version	证据与依赖版本
timestamp	生成/复核时间
confidence	强度评级与依据
reviewer	评审者与独立性说明
defeaters	关联反驳项及状态
status	有效/过期/待复核/撤销

发布前检查清单：

• 契约是否覆盖能力边界、ODD、安全目标、行为包络、响应时限与人类监督？
• 每个安全目标是否至少有一条独立证据？关键目标是否有多源证据？
• 是否存在未关闭的关键反驳项？若有，是否明确阻止发布？
• 监控器是否经过故障注入、时序分析与独立验证？是否记录了漏检/误报的估计？
• 回退策略是否在仿真、封闭场地和受控道路环境中验证？是否能在时限内到达 MRC？
• 变更影响闭包是否覆盖模型、数据、地图、传感器、供应链与监控器？
• 证据是否在有效期内？过期证据是否已重新验证或撤销？
• 现场监控指标、回滚条件与事件响应流程是否就绪？
• 人类监督契约是否包含权限、注意力、接管时间、透明度和失败回退？
• 安全案例是否经过独立评审？评审意见是否已记录并处理？

监控器评审清单：

• 监控器的安全目标与契约条款是否一一对应？
• 监控器是否使用独立传感器、独立计算或独立供电？共因是否经过 DFA？
• 监控器的规格是否可能遗漏关键场景？是否经过 STPA/红队/形式化边界分析？
• 阈值是否按代价敏感原则选择？是否考虑误报导致的追尾与可用性风险？
• 监控器的 WCET 是否小于响应时限？在资源受限时是否有降级策略？
• 监控器日志是否可用于事后追溯与证据更新？

人类监督检查清单：

• 接管请求的触发条件、呈现方式与时间预算是明确的吗？
• 操作员的注意力、负荷与情境意识如何测量？
• 如果操作员未响应，系统是否自动进入 MRC？
• 是否存在自动化偏见、过度信任或技能退化风险？如何缓解？
• 远程监督的通信时延、可用性与信息安全是否经过评估？
• 接管成功/失败案例是否进入证据账本与再保证流程？

E. 评估预注册清单

• 研究问题、假设、主要终点与次要终点是否冻结？
• 场景族、样本量、随机种子与停止规则是否预先定义？
• 基线是否包括故障导向、SOTIF 导向、静态案例与消融配置？
• 指标定义、单位、聚合方式与置信区间方法是否明确？
• 多重比较校正、缺失数据处理与异常回合处理规则是否预先声明？
• 失败案例、负结果与不可运行比例是否纳入报告？
• 代码、配置、模型、数据与仿真器版本是否归档？
• 数据许可、隐私、伦理审查与人类受试者同意是否完成？
• 独立评审者是否在结果产生前确定？
• 任何偏离预注册的修改是否记录并说明理由？