玻尔百科随着车辆演变为复杂的电子平台，确保其安全性变得愈加复杂。软件中的一个错误或传感器的一次故障都可能带来灾难性后果，因此迫切需要一种规范化的方法来管理风险。国际标准 ISO 26262 提供了这样一个框架，为汽车系统的功能安全提供了一套严谨的、基于风险的方法论。本文旨在深入探讨这一重要标准的核心，填补“知道标准存在”与“理解其原则如何塑造安全汽车技术”之间的知识鸿沟。第一章“原则与机制”将解构其基本概念，探讨随机失效与系统性失效之间的关键区别，并详细介绍构成该标准基石的危害分析与风险评估 (HARA) 流程。随后的“应用与跨学科联系”一章将阐明这些理论如何付诸实践，从设计冗余系统到应对网络安全和机器学习带来的现代挑战。
要理解 ISO 26262 所代表的这门错综复杂的安全工程之舞，我们必须从失效的本质而非规则本身入手。当我们说一个系统“不安全”时，我们真正的意思是什么？想象一个高级驾驶辅助系统。如果它的摄像头因为宇宙射线翻转了其内存中的一个比特而在晴朗的日子里未能看到行人，这是一种失效。但如果同一个摄像头因为迎着刺眼的低角度阳光行驶而未能看到行人，这则是完全不同类型的问题。在第二种情况下，摄像头并没有“损坏”；它完全按照设计工作，但其预期功能存在性能限制。
ISO 26262 是一项关于功能安全的标准；它的世界是第一个问题的世界——即由故障引起的危害。它是一份旨在构建在出现问题时不会发生危险性失效的系统的指南。第二个问题，即性能限制的挑战，属于一个互补标准 ISO 21448 的范畴，该标准被称为 SOTIF，即“预期功能安全”。要掌握功能安全，我们必须首先认识到它的边界。ISO 26262 的核心是构建能够抵御其自身内部失效的稳健系统。
在故障的世界里，所有现代安全思维的核心都存在一个深刻而优美的区别。这就是随机硬件失效与系统性失效之间的差异。
随机硬件失效是物理世界不可避免的衰退。它们是自然行为，而非设计行为。一个晶体管老化，一个焊点开裂，一个存储单元被辐射击中。我们永远无法准确预测下一次失效将在何时何地发生，但就像精算师预测寿命一样，我们可以从统计学上描述它们。我们可以测量它们的平均发生率，即所谓的失效时间（FIT）率。因为它们是概率性的，我们可以用概率来对抗它们。如果一个组件每小时发生故障的几率为百万分之一，我们可以增加第二个冗余组件。两者同时独立发生故障的几率将变得微乎其微。
系统性失效则完全是另一回事。它们是机器中的幽灵，是编织在系统设计或软件结构中的缺陷。一行有问题的代码、对需求的误解、设计规范中的逻辑错误——这些都是系统性失效。与随机失效不同，它们根本不是随机的。它们是确定性的。如果触发该错误的特定条件发生，失效必然会发生，每一次都会。
想象一个复杂的制动控制器，它有两个相同且冗余的处理通道。两个通道在同一瞬间遭受独立随机硬件失效的几率微乎其微。但现在，假设两个通道运行完全相同的软件，而这个软件包含一个微妙的错误：当它接收到一个非常特定且罕见的传感器输入序列时，它会命令制动器释放。当那个罕见的序列发生时，两个通道将同时且确定性地失效。硬件冗余变得毫无用处。由这个错误引起的系统失效率就是触发条件发生的频率，这个频率可能比所有随机硬件失效的总和高出数千倍。
这种根本性的二分法解释了为什么 ISO 26262 有两种截然不同的确保安全的方法。对于随机硬件失效，它要求采用定量方法：计算概率、设定数值目标，并使用冗余和诊断等架构特性。对于系统性失效，定量方法毫无意义——人们无法为设计中的人为错误分配概率。相反，标准要求采用定性的、基于流程的方法：严谨的规范、细致的设计、详尽的验证和独立的评审，所有这些都旨在从一开始就防止引入故障，并在故障出现时发现它们。
在构建一个安全的系统之前，我们必须首先就我们要防范的目标达成一致。这就是危害分析与风险评估 (HARA) 的目的，它是 ISO 26262 生命周期中的基础活动。这是一个结构化的头脑风暴过程，工程师们在其中设想可能出错的情况以及其严重程度。
该过程始于识别危害——即可能造成伤害的系统状况。一个简单的故障并非危害。“转向角传感器故障”是一个故障。由此导致的“在高速公路上意外持续的转向指令”才是危害，因为它可能导致伤害。
一旦识别出危害，就必须对其相关风险进行分类。ISO 26262 通过三个不同的视角来审视危害以完成此项工作：
严重度 ()：如果危害导致事故，伤害会有多严重？其范围从“无伤害”() 到“致命或危及生命”()。
暴露度 ()：车辆处于可能发生此危害的情境中的频率如何？对于高速公路车道保持系统，“在高速公路上行驶”的暴露度非常频繁 ()。对于泊车辅助系统，“泊车操作”的暴露度则较低。
可控度 ()：如果失效发生，一个普通驾驶员能否采取行动来避免伤害？在低速时方向盘上意外的轻微拉力很容易被纠正 ()。在高速公路上完全失去转向几乎是不可控的 ()。
这里我们遇到了一个非常微妙但至关重要的点。这些评级—— 等——并非标尺上的数字；它们是有序的类别，或称序数尺度。“无伤害”和“轻微伤害”之间的“距离”与“严重伤害”和“致命伤害”之间的“距离”是不同的。它们是定性判断。这意味着我们不能简单地将它们相乘来得到一个“风险分数”。这样做就像试图将“温暖”乘以“多云”一样。相反，ISO 26262 使用一个分类表，这是一个结合 、 和 的评级来确定最终分类的矩阵。
HARA 过程的输出是汽车安全完整性等级 (ASIL)。ASIL 是一个目标，是对系统的要求。它的范围从 ASIL A（最低完整性要求）到 ASIL D（最高）。被认为风险极低的危害可能被归类为 QM，即“质量管理”，意味着标准的行业质量流程就足够了。对于我们在高速公路上意外转向的危害，最高严重度 ()、频繁暴露度 () 和难以控制 () 的组合直接导致了最高分类：ASIL D。
HARA 遵循的最后一条关键规则是：你必须在评估危害风险时，不能考虑你即将设计的安全机制所带来的好处。如果你正在设计一个高级预警系统来提醒驾驶员注意故障，你不能用这个提议中的系统来为你争取一个更好的可控度评级。这将是循环论证。HARA 定义问题；安全机制是解决方案。
ASIL 不仅仅是一个标签；它是一项指令，决定了后续每个开发步骤所应用的严谨程度。一个要求满足 ASIL D 的系统所受到的要求远比 ASIL A 系统严格。这适用于我们失效二分法的两方面。
为了对抗系统性失效，更高的 ASIL 要求更形式化的方法、更详细的文档、更多的验证活动（如仿真和测试）以及更独立的监督。
为了对抗随机硬件失效，ISO 26262 根据 ASIL 设定了明确的定量目标。对于 ASIL D，目标失效率极低——每 1 亿小时的运行中，危险失效少于一次。仅靠单个组件通常无法实现这一点。这导致了架构上的要求，通过两个关键指标来量化：
单点故障度量 (SPFM)：该指标衡量系统对于单个元件故障的鲁棒性，这些故障本身就可能违反安全目标。高 SPFM 意味着该架构几乎没有“单点故障”。这可以通过冗余或添加能够在单点故障造成危害前检测到它并将系统转换到安全状态的诊断功能来实现。
潜伏故障度量 (LFM)：该指标处理更隐蔽的隐藏或“潜伏”故障问题。潜伏故障是安全机制或冗余组件中处于休眠状态且未被检测到的失效。它本身不会导致失效，但会产生一个漏洞。如果当第一个故障处于潜伏状态时发生第二个故障，系统可能会发生危险失效。高 LFM 表明系统具有有效的在线或周期性诊断功能，可以在这些隐藏故障与第二个故障共同导致危险事件之前发现并标记它们。
用一个单一的、庞大的组件来实现 ASIL D 的苛刻目标通常是不切实际的。解决方案是一种优雅的“分而治之”策略，称为ASIL 分解。
其核心思想是，一个严格的安全要求可以由两个或多个在冗余架构中工作的、要求较低的独立组件来满足。例如，一个 ASIL D 的安全目标可以被分解并由两个独立的通道来完成，每个通道都按 ASIL B 的级别开发。这非常强大，因为开发到 ASIL B 的成本和复杂性远低于开发到 ASIL D。
但这里有一个关键的陷阱：这个策略依赖于冗余通道的独立性。如果一个单一事件可以导致两个通道同时失效，那么冗余的好处就荡然无存。这些事件被称为共因失效 (CCF)。它们可能由环境因素（例如，一次电涌同时摧毁两个电源）或我们之前讨论的系统性失效（两个通道上都存在相同的软件错误）引起。
因此，证明分解合理性的一个关键部分是严谨地论证独立性，并分析和缓解潜在的共因失效。这使我们的故事回到了起点。冗余的优雅数学抽象只与其物理和逻辑实现一样强大，而共因的幽灵——无论是随机的电涌还是系统性的软件错误——提醒我们安全工程的统一性。它是一门既必须掌握概率法则，又必须精通严谨、无故障设计艺术的学科。
在探寻了 ISO 26262 的基本原则之后，我们已经了解了它是什么以及它为什么存在。我们以一种略显抽象的方式讨论了危害、风险和完整性等级。但一个强大思想的真正美妙之处不在于其抽象的定义，而在于它如何塑造我们周围的世界。这些规则和概念是如何从标准的书页中走出来，成为保护我们生命的技术的基石呢？
在本章中，我们将探讨“如何”和“在何处”应用。我们将看到这些原则在行动中，一步步构建安全的系统。我们将见证这个关于安全的思维框架如何超越汽车本身，为不同安全关键领域的工程师们创造一种统一的语言。这是一段从抽象到具体的旅程，揭示了功能安全优雅而实用的核心。
想象一下为一辆新车设计电子制动系统的任务。这其中的利害关系再大不过了。你该从何处着手？ISO 26262 提供了一份蓝图，一个结构化的生命周期，引导工程师从一张白纸到一个成品、值得信赖的产品。这不仅仅是一份检查清单；它是一个严谨的创造与验证过程。
这段旅程始于一份全面的软件安全计划，该计划规划了整个开发过程。系统的安全目标，源自危害分析与风险评估 (HARA)，被一丝不苟地转化为具体的软件安全需求。对于我们的制动系统，这可能包括对最大响应时间或传感器失效时行为的需求。其魔力与纪律在于可追溯性。每一项需求都必须与架构设计、实现它的代码以及验证它的测试相链接。这创造了一条不间断的逻辑链，确保没有一个安全目标被遗忘或未被解决。
架构本身就是防御性设计的艺术品。对于具有高完整性要求（ASIL C 或 D）的系统，工程师可能会创建一个冗余架构，其中关键功能由两个或多个独立的通道执行。设计不仅要规定每个组件做什么，还必须证明免于干扰——即非关键组件（如收音机）中的一个错误绝不可能干扰制动控制器。
最后，所有这些都汇集成一个安全实例。不要把它看作一份单纯的报告，而应看作一个引人入胜的故事，一个我们用来 убе服自己和监管机构，证明系统足够安全的结构化论证。这个论证建立在大量的证据之上：硬件失效分析（FMEDA）的结果、形式化验证的证明、数百万英里虚拟测试的日志，以及从真实世界测试中获得的统计置信度。每一份证据都是故事中的一句话，链接到一个具体的主张，所有这些共同构建出最终的结论：残余风险是可接受的低水平。
安全工程师工具箱中最强大的策略之一是冗余。如果一个组件可能会失效，为什么不用两个呢？对于最高的安全目标，如 ASIL D，通常会对需求进行分解。我们不是要求一个单一的、近乎完美的系统，而是可以构建两个独立的、不那么完美的系统——比如说，达到 ASIL B 级别——它们的组合可靠性满足 ASIL D 的目标。
想象一下两个守卫，每个都负责看守一个关键的大门。两者都不是绝对可靠的，但两人因完全相同的原因在完全相同的时刻都睡着的几率微乎其微。这就是双通道架构背后的原理。然而，这个美丽的逻辑有一个致命弱点：共因失效。如果一个单一事件，比如一次突然的电涌或用于创建他们指令手册的编译器中的一个微妙错误，同时让两个守卫都失效了呢？
这就是为什么独立性不仅仅是拥有两套东西；而是拥有两套不同的东西。冗余通道可能会使用来自不同制造商的处理器，由独立的软件团队编写，甚至使用不同的传感器技术（如一个摄像头和一个雷达）。通过量化这些共因失效的概率（使用一个称为贝塔因子 的度量），工程师可以建立一个定量的论证，证明他们的冗余设计确实达到了所期望的安全水平。
为了管理这一切，通常会引入第三个组件：一个监控器或仲裁器。这个仲裁器的工作是不断比较两个冗余通道的输出。如果它们的输出差异超过一个微小的阈值，仲裁器就知道出了问题。然后它可以接管控制，并命令系统进入一个安全状态，比如轻柔地施加制动。这种简单的比较和回退机制，使得系统能够满足严格的硬件架构度量，如单点故障度量 (SPFM) 和潜伏故障度量 (LFM)。它确保了单个随机故障不会导致灾难，并且隐藏的、潜伏的故障在它们能与第二个故障共同造成危害之前被发现。
我们如何能确定我们的安全机制和冗余设计在现实世界中，面对其无限且不可预测的场景时会起作用？我们不可能在物理测试轨道上测试每一种情况。这就是数字孪生的用武之地——一个用于验证和确认的革命性工具。
数字孪生远不止是一个简单的模拟。它是一个高保真的、基于物理的真实车辆镜像，存在于计算机内部。它理解汽车的动力学、传感器的特性和执行器的局限性。有了这个虚拟副本，工程师们获得了一种超能力：他们可以在极短的时间内测试车辆数百万英里，让它经受罕见而危险的边缘情况（如在结冰的弯道上传感器失效），并系统地注入故障，以观察安全机制是否如设计般触发。
这个“水晶球”使我们能够以前所未有的规模为我们的安全实例收集证据。我们可以验证系统是否正确处理了通过 STPA（系统理论过程分析）等分析方法识别出的不安全控制行为，并估算我们的诊断软件在现实世界中的有效性。然而，能力越大，责任越大。如果我们的“水晶球”有缺陷，它可能会向我们展示一幅令人安心但虚假的安全画面。这就是为什么数字孪生本身作为一个软件工具，也必须受到审查。根据 ISO 26262，它必须被分配一个工具置信度 (TCL)，如果它被用来论证高 ASIL 组件的安全性，那么这个工具本身可能需要进行合格性认证，以证明它适合其用途。我们必须确保我们用于验证的工具本身不是错误的来源。
传统的功能安全关注的是保护一个系统免受其自身的影响——即随机硬件失效和系统性软件错误。但是，当威胁不是意外而是恶意攻击时，会发生什么？在现代的互联汽车中，一次安防漏洞就是一次安全灾难。一个能够向汽车网络注入虚假数据的攻击者，原则上可以禁用刹车或指令意外加速。
这一现实迫使安全工程和安防工程两个领域联合起来。仅仅拥有一个安全实例和一个独立的安防评估已经不够了；它们必须被编织成一个协同保障论证。可以把它想象成保卫一座城堡。安全实例担心城墙因年久失修而倒塌（随机失效）。安防实例担心敌人试图攻破城门（恶意攻击）。协同保障实例则是一个统一的防御计划，认识到一旦城门被攻破，城墙的坚固与否就无关紧要了。
这两个世界之间的桥梁通常是通过明确的、量化的假设来构建的。安全实例可能会做出一个正式声明：“我们假设安防控制措施以 的概率防止恶意篡改。”这个假设随后成为安防团队的最高级别需求，他们必须提供证据——来自密码学审计、渗透测试和形式化分析——来证明这一点。然后，安全论证继续进行，在其整体风险预算中考虑了成功攻击的微小残余风险。
这种紧密的集成也正在推动新的硬件和软件架构。像可信执行环境 (TEEs) 这样的技术在主处理器内部创建了一个“数字堡垒”或安全的“保险库”。最关键的安全代码，比如发动机的扭矩控制，可以在这个隔离的环境中运行，免受系统中安全性较低部分（如信息娱乐单元）中发生的任何恶意软件或故障的影响。这为实现 ISO 26262 理念中至关重要的“免于干扰”提供了一种可证明的机制。
如今，功能安全面临的最大挑战或许来自于人工智能和机器学习 (ML) 的兴起。我们如何认证一个其行为不是明确编程而是从数据中学习而来的系统？当一辆自动驾驶汽车的感知系统，经过严格验证后，通过空中下载更新了一个新的、重新训练过的模型，会发生什么？它还安全吗？
答案不是禁止学习，而是将机器学习的不可预测性包裹在一个确定性的、高度规范的过程中。整个机器学习流程——训练数据集、模型架构代码、训练参数和软件环境——必须被视为一个单一的、与安全相关的可配置项。每一个对训练模型创建有贡献的组件都必须进行版本控制，用加密哈希进行“指纹识别”，并进行数字签名，以确保其完整性和来源。
当一个模型被重新训练时，它不是被简单地替换掉。新模型必须接受完整的回归验证，通常在数字孪生中进行，以确保其性能和安全特性是可接受的。需要进行彻底的变更影响分析，用新的证据更新安全实例，并且一个独立的安全委员会必须批准发布。这个严格的面向安全的机器学习运维 (MLOps for safety) 过程确保了，即使模型的内部逻辑是学习得来的，其创建、验证和部署的过程也像任何其他安全关键软件一样透明、可追溯和值得信赖。
虽然 ISO 26262 是为道路而编写的，但其思想根源于一个更通用的标准，IEC 61508，该标准适用于任何安全关键的电子系统。我们讨论过的原则——基于风险的分析、完整性等级、架构上的深度防御和严格的验证——并非汽车所独有。它们构成了一种通用的安全语言。
考虑一下医院重症监护室中的联网医用输液泵。其关键危害不是“意外加速”，而是“药物过量输注”或“输注不足”。工程师们不是对车辆动力学建模，而是对药代动力学建模——即药物如何被患者身体吸收和消除。然而，确保安全的过程却惊人地相似。
工程师们执行 HARA 来分析危害。他们确定患者伤害的严重度、暴露于危险情况的暴露度（例如，网络中断的概率）以及临床医生的可控度。由此，他们得出一个安全完整性等级 (SIL)，这是医疗领域的 ASIL。然后，他们制定安全目标：或许是自动限制最大允许药物剂量，或在检测到网络故障的几秒钟内转换到安全的、恒定的输注速率。物理背景和具体情境变了，但管理风险的理性框架保持不变。
这就是功能安全学科的终极力量与美妙之处。它提供了一个共同的基础，一套共享的原则，让工程师们能够推理风险并构建值得信赖的系统，无论他们是在设计一辆自动驾驶的汽车，一个与人类并肩工作的机器人，还是一个维持生命的医疗设备。这是一门不让安全凭运气的科学。