1. 为什么神经网络上车这么难：从ISO 26262的视角看问题

做汽车电子功能安全的同行都有一个共识：ISO 26262这本标准，本质上是一套基于“确定性系统”假设构建的方法论。它要求你能够枚举失效模式、计算失效率、定义安全机制、验证安全目标达成。这套逻辑用在ECU、传感器、执行器上，经过十几年的磨合，大家已经驾轻就熟。

但神经网络这个东西一进来，整个体系就开始晃了。

我最初接触这个课题是在一个ADAS项目上，当时团队想把一个用于前向碰撞预警的视觉检测模块从传统CV方案切换到CNN方案，精度确实上去了，但功能安全团队直接卡住了——他们问了一个非常朴素的问题：“你怎么证明这个网络在没见过的情况下不会输出一个危险的错误结果？”这个问题看似简单，实际上直接击中了神经网络与功能安全之间的根本矛盾。

神经网络的本质是一个高维非线性映射函数，它的行为由训练数据、网络结构、权重参数共同决定。你没法像分析一个PID控制器那样，用传递函数去推导它的输出边界。更麻烦的是，它的失效模式不是“某个电阻短路”这种物理层面的确定性失效，而是“在某个特定输入分布下输出偏离预期”这种统计层面的行为异常。

ISO 26262把危害分为系统性失效和随机硬件失效两类。随机硬件失效可以用FMEDA加诊断覆盖率来量化，系统性失效则靠流程约束和验证充分性来保证。神经网络的问题在于，它既有系统性失效的特征（训练不充分、结构设计缺陷），又有随机失效的表象（对输入扰动的敏感响应），但它两者都不完全属于。

这就导致一个尴尬的局面：你没法直接套用现有的ASIL等级分解逻辑，也没法用传统的安全机制（比如看门狗、双核锁步）来兜底。你需要一套新的论证框架。

我后来花了大量时间研究这个方向，也参考了不少行业内的公开论文和标准草案。目前比较主流的思路是三条腿走路：一是把安全需求形式化后嵌入到网络训练过程中，也就是所谓的“概念嵌入”；二是用形式验证方法对网络的局部行为做穷举或约束求解；三是通过运行时监控加安全兜底逻辑来构建防御纵深。这三条路各有优劣，实际项目中往往是组合使用。

下面我会把这套方法论拆开来讲，从整体设计思路到具体的技术实现，再到实操中踩过的坑，尽量把每个环节讲透。如果你正在做神经网络相关的功能安全论证，或者准备把某个AI模块推向量产，这些内容应该能帮你少走一些弯路。

2. 整体论证框架设计：三条腿走路的逻辑

2.1 为什么不能只靠“更多数据”来证明安全

很多算法团队的第一反应是：“我多喂点数据不就行了？”这个思路在工程上可以理解，但在功能安全论证中站不住脚。

原因很简单：数据驱动的验证只能覆盖你采样到的分布，而安全论证要求你覆盖所有可能导致危害的场景。这两者之间的鸿沟不是靠增加数据量能填平的。我见过一个项目，训练集用了上千万帧图像，但最终在功能安全评审时被问了一个问题：“你能证明这上千万帧覆盖了所有可能的逆光加雨雾加行人突然横穿组合吗？”答案是显然的。

所以，数据驱动的方法只能作为论证的一个支撑证据，不能作为核心论据。你需要更形式化、更可推理的手段。

2.2 概念嵌入：把安全需求写进网络的血脉里

概念嵌入是我认为目前最有前途的方向之一。它的核心思想是：不要等到网络训练完了再去验证它是否安全，而是在训练过程中就把安全约束作为损失函数的一部分或者网络结构的一部分嵌入进去。

举个具体的例子。假设你有一个用于车道保持的CNN，安全需求是“当车辆偏离车道中心超过0.3米时，网络输出的转向修正量必须大于某个阈值”。传统做法是训练完网络后，用测试集去验证这个需求是否满足。但概念嵌入的做法是：在损失函数里加一项，专门惩罚那些在偏离超过0.3米时输出修正量不足的样本。这样网络在训练过程中就会“学会”满足这个安全需求。

更激进的做法是直接修改网络结构。比如在输出层前面加一个安全约束层，这个层的权重不是训练出来的，而是根据安全需求硬编码的。这样即使前面的网络输出异常，最终输出也会被约束在安全边界内。

注意：概念嵌入不是万能的。它只能处理那些可以形式化为数学表达的安全需求。对于“不要撞到行人”这种语义级别的需求，你没法直接写进损失函数里。你需要先把它分解为可量化的子需求。

2.3 形式验证：给神经网络做“数学体检”

形式验证在传统软件安全中已经很成熟了，但用在神经网络上是一个相对新的领域。它的基本思路是：把神经网络看作一个数学函数，然后用形式化方法去证明这个函数在给定输入范围内满足某些性质。

目前比较实用的方法有两种。一种是基于SMT求解器的，比如用Reluplex算法处理ReLU激活函数的网络。它的优势是精度高，能给出严格的证明或反例。缺点是计算复杂度随网络规模指数增长，目前只能处理几千个神经元的小网络。

另一种是基于抽象解释的，比如用区间算术或者多面体抽象来近似网络的行为。它的优势是可扩展性好，能处理大网络。缺点是精度损失，可能给出“不确定”的结果。

在实际项目中，我通常建议对安全关键模块用SMT方法做精确验证，对非关键模块用抽象解释做快速筛查。两者结合，既能保证关键路径的严格性，又能控制整体验证成本。

2.4 运行时监控：最后一道防线

不管前面的验证做得多充分，你总得承认一个现实：你不可能证明一个神经网络在所有可能的输入下都安全。所以你需要运行时监控作为兜底。

运行时监控的核心思路是：在网络输出之后，加一个独立的、可解释的安全检查模块。这个模块不依赖神经网络，而是基于确定性规则或者传统控制理论。如果网络输出通过了检查，就放行；如果没通过，就切换到安全降级模式。

比如在自动紧急制动系统中，网络输出一个减速度请求。运行时监控模块会检查这个请求是否在物理可行范围内（比如不超过最大减速度），是否与当前车速和障碍物距离一致（比如不会导致后车追尾）。如果检查不通过，就切换到一个保守的制动策略。

这个模块本身需要按照最高ASIL等级来开发，因为它承担了最终的安全责任。它的存在也反过来降低了对神经网络本身的ASIL要求，因为你不再需要证明网络永远正确，只需要证明监控模块能及时捕获网络的错误输出。

3. 核心细节解析：从安全需求到网络约束的转化

3.1 安全需求的形式化分解

这一步是整个论证链条的起点，也是最容易被低估的环节。很多团队拿到一个“避免非预期制动”这样的安全需求后，直接就开始训练网络了。这是典型的跳步。

正确的做法是先把安全需求分解为可量化、可验证的子需求。以AEB为例，“避免非预期制动”可以分解为：

• 在无碰撞风险时，制动请求必须为0
• 在碰撞时间大于2秒时，制动请求不得超过舒适减速度阈值
• 在碰撞时间小于0.6秒时，制动请求必须达到最大减速度
• 制动请求的变化率不得超过物理执行器的响应极限

这些子需求每一个都可以转化为对网络输出的约束条件。比如第一条可以转化为：当输入图像中不存在障碍物时，网络输出的制动概率必须低于某个阈值。

这个分解过程需要功能安全工程师和算法工程师紧密配合。功能安全工程师负责定义“什么是不安全”，算法工程师负责判断“这个定义能否转化为网络可理解的约束”。

3.2 损失函数中的安全惩罚项设计

一旦你有了形式化的子需求，下一步就是把它嵌入到损失函数中。这里有几个实操要点。

首先是惩罚项的形式。对于“输出必须小于阈值”这类需求，可以用ReLU形式的惩罚：max(0, output - threshold)。对于“输出必须在某个范围内”的需求，可以用双边惩罚。对于“输出变化率受限”的需求，需要在时间维度上做差分后再惩罚。

其次是权重的调节。安全惩罚项的权重不能太大，否则网络会为了满足安全约束而牺牲所有性能，导致模型不可用。也不能太小，否则安全约束形同虚设。我的经验是先用一个较大的权重训练几轮，观察安全约束的满足情况，然后逐步降低权重，在安全和性能之间找平衡点。

还有一个容易被忽略的点：惩罚项应该只在违反约束的样本上激活。如果对所有样本都施加惩罚，网络会倾向于输出一个“安全但无用”的保守值。比如在AEB中，如果对所有样本都惩罚制动请求，网络最终会学会永远输出零制动，这显然不是我们想要的。

3.3 网络结构层面的安全约束

除了损失函数，你还可以在网络结构上做文章。最常见的方法是在输出层加一个“安全壳”。

这个安全壳可以是一个简单的饱和函数，把网络输出限制在物理可行范围内。比如转向角输出限制在正负180度以内，减速度输出限制在正负10米每二次方秒以内。这个操作看起来很简单，但它能防止网络在极端输入下输出一个物理上不可能的值。

更复杂一点的安全壳可以实现条件约束。比如根据当前车速动态调整减速度上限：低速时允许更大的减速度，高速时限制减速度以避免后车追尾。这个逻辑可以用一个小的确定性模块实现，它的输出作为网络输出的上限。

还有一种做法是在网络中间层插入“安全瓶颈层”。这个层的维度很低，专门用来编码安全相关的状态变量，比如障碍物距离、相对速度、碰撞时间等。这样网络的高层特征必须经过这个瓶颈层才能影响最终输出，相当于给安全相关决策加了一个可解释的中间表示。

3.4 形式验证的输入空间定义

形式验证的一个关键前提是定义清楚“输入空间”。你不能说“验证这个网络对所有输入都安全”，因为输入空间是无穷大的。你需要定义一个合理的输入范围。

这个范围的定义需要结合ODD（运行设计域）。比如一个用于高速公路的AEB系统，它的输入图像中车辆、车道线、天空、路面的像素值范围是有限的。你可以根据实际采集的数据统计出每个像素通道的均值和方差，然后定义一个置信区间作为验证范围。

但这里有一个陷阱：ODD定义得太窄，验证会很容易通过，但实际运行中一旦超出ODD，网络行为就不可预测。ODD定义得太宽，验证复杂度会爆炸。我的建议是先用一个较宽的ODD做初步验证，如果发现大量反例，再逐步收窄ODD，直到验证通过。同时要在运行时监控中明确检测ODD边界，一旦超出就触发降级。

4. 实操过程：一个完整的论证案例

4.1 案例背景与安全目标定义

假设我们有一个用于高速公路辅助驾驶的视觉感知模块，输入是前视摄像头的图像，输出是前方最近车辆的距离估计。这个距离估计会被下游的ACC控制器使用。

安全目标是：距离估计误差不得超过实际距离的15%，或者在绝对误差上不超过5米（取较大值）。这个安全目标对应ASIL B等级。

为什么是ASIL B而不是D？因为距离估计错误不会直接导致危害，它需要经过ACC控制器的处理，而且驾驶员始终在环。但考虑到高速公路场景下追尾事故的严重性，也不能定得太低。

4.2 数据采集与ODD定义

我们采集了大约50万帧高速公路场景的图像，覆盖了晴天、阴天、小雨、黄昏等光照条件，以及不同交通密度和车辆类型。每帧图像都标注了前方最近车辆的真实距离，标注精度在0.5米以内。

ODD定义为：高速公路，车速大于60公里每小时，光照条件为白天或黄昏，天气为无雨或小雨，前方车辆距离在5到150米之间。

这个ODD的定义直接影响了后续所有验证工作的范围。比如在形式验证中，我们只需要考虑这个范围内的输入图像；在运行时监控中，我们需要检测当前场景是否超出ODD。

4.3 网络训练与安全约束嵌入

我们选择了一个轻量级的CNN结构，大约8层卷积加3层全连接，参数量在200万左右。这个规模是为了后续形式验证的可行性考虑——太大的网络验证工具跑不动。

损失函数由三部分组成：距离回归的均方误差、安全约束惩罚项、正则化项。安全约束惩罚项的定义如下：

def safety_penalty(pred_dist, true_dist): # 相对误差超过15%或绝对误差超过5米时施加惩罚 rel_error = torch.abs(pred_dist - true_dist) / true_dist abs_error = torch.abs(pred_dist - true_dist) violation = torch.max(rel_error - 0.15, abs_error / 5.0 - 1.0) return torch.mean(torch.relu(violation) ** 2)

这个惩罚项的设计逻辑是：只有当误差超过安全边界时才施加惩罚，边界内不惩罚。这样网络在满足安全约束的前提下，仍然可以优化平均精度。

训练过程中我们监控了两个指标：平均绝对误差和安全违规率。安全违规率定义为测试集中误差超过安全边界的样本比例。目标是把这个比例降到0.1%以下。

4.4 形式验证的具体操作

训练完成后，我们用Reluplex算法对网络进行了形式验证。验证的性质是：对于ODD范围内的所有输入图像，网络输出的距离估计误差不超过安全边界。

实际操作中，我们没法对整个图像空间做验证，因为维度太高。所以我们先用一个特征提取器把图像降维到128维的特征向量，然后对这个特征向量空间做验证。特征提取器本身是确定性的，不包含可学习参数。

验证过程跑了大约72小时，最终给出了“无法找到反例”的结论。注意这里说的是“无法找到反例”，而不是“证明安全”。因为Reluplex在超时后会返回未知结果，我们设定了一个48小时的超时阈值，超过就认为验证不充分。

为了提高验证的置信度，我们还做了敏感性分析：对输入特征向量的每个维度分别施加扰动，观察输出误差的变化。如果某个维度的扰动会导致输出误差急剧增大，说明网络对这个维度过于敏感，需要增加训练数据或调整网络结构。

4.5 运行时监控模块的实现

运行时监控模块是一个独立的C语言程序，运行在安全核上。它的输入是网络输出的距离估计、当前车速、以及一个基于传统雷达的距离测量值。

监控逻辑如下：

• 如果网络输出与雷达测量值的差异小于3米，直接采用网络输出
• 如果差异在3到8米之间，采用雷达测量值，并记录一次“网络异常”事件
• 如果差异大于8米，触发安全降级，ACC功能退出，提示驾驶员接管

这个逻辑的核心思想是：雷达测量虽然精度不如网络，但它的失效模式是已知的、可预测的。用雷达作为交叉验证，可以在不显著增加成本的前提下，大幅提升系统的安全置信度。

监控模块本身按照ASIL B开发，经过了单元测试、集成测试和故障注入测试。它的代码规模控制在500行以内，确保可审查性。

5. 常见问题与排查技巧实录

5.1 安全约束嵌入后模型性能下降太多怎么办

这是最常见的问题。你加了安全惩罚项，模型在测试集上的平均精度可能下降5%到10%。这个代价是否可接受，取决于你的安全目标有多严格。

如果下降太多，可以尝试以下几个方向。一是调整惩罚项的权重，从大往小调，找到一个性能和安全都可接受的平衡点。二是改进惩罚项的形式，比如用Huber损失代替平方损失，减少对极端违规样本的过度惩罚。三是增加训练数据中安全关键场景的比例，让网络有更多机会学习这些场景下的正确行为。

还有一个技巧是分阶段训练：先不加安全约束训练一个基础模型，然后在这个模型的基础上加安全约束做微调。这样网络不会因为安全约束而完全偏离原来的学习方向。

5.2 形式验证跑不完怎么办

形式验证的计算复杂度是网络规模的指数函数。如果你的网络有几十万神经元，目前的工具基本跑不动。这时候你有几个选择。

一是缩小验证范围。不要验证整个ODD，只验证最关键的子区域。比如只验证距离在5到30米之间的场景，因为这是碰撞风险最高的区间。30米以外的场景可以用统计测试来覆盖。

二是简化网络结构。把大网络蒸馏成小网络，然后对小网络做验证。蒸馏过程中要保证安全关键行为被保留，这本身也是一个研究课题。

三是用抽象解释代替精确求解。抽象解释虽然可能给出“不确定”的结果，但它能处理大网络。你可以用抽象解释做快速筛查，找出可疑区域，然后对这些区域用精确方法做局部验证。

5.3 运行时监控的阈值怎么定

阈值定得太松，监控形同虚设；定得太紧，频繁触发降级，用户体验极差。我的经验是用实际路测数据来标定。

具体做法是：采集一段长时间的正常行驶数据，统计网络输出与雷达测量值的差异分布。然后取这个分布的99.9百分位作为阈值。这样在正常行驶中，误触发率低于0.1%。同时要确保这个阈值对应的实际距离误差仍然在安全边界内。

如果发现99.9百分位对应的误差已经超过安全边界，说明网络本身的精度不够，需要回到训练阶段改进模型，而不是靠调阈值来解决问题。

5.4 如何向评审方解释“验证不充分”

这是功能安全工程师最头疼的问题。你没法证明网络绝对安全，只能证明“在当前验证条件下未发现反例”。评审方可能会追问：“那没验证到的部分呢？”

我的应对策略是构建一个“安全论证链”：形式验证覆盖了核心ODD区域，统计测试覆盖了边缘区域，运行时监控覆盖了所有区域。三者叠加，形成一个完整的防御体系。每一层都有明确的覆盖范围和置信度，评审方可以看到你清楚地知道自己的边界在哪里，并且对边界外的情况有兜底措施。

提示：不要试图掩盖验证的局限性。评审方最怕的不是“你验证得不充分”，而是“你不知道自己验证得不充分”。坦诚地说明边界和兜底措施，反而更容易获得认可。

5.5 常见问题速查表

6. 工具链与工程实践建议

6.1 训练框架的选择

在功能安全项目中，训练框架的选择不仅要考虑性能，还要考虑可追溯性和可复现性。我推荐使用PyTorch，因为它的动态图机制方便调试，而且社区生态丰富，遇到问题容易找到解决方案。

但要注意一点：训练过程中的所有超参数、数据版本、代码提交哈希都必须记录在案。这是功能安全审计的基本要求。我通常会用MLflow或者Weights & Biases来做实验管理，确保每次训练都可以完整复现。

6.2 形式验证工具的实际表现

目前市面上可用的神经网络形式验证工具不多，比较成熟的有Reluplex、Marabou、ERAN等。我在项目中主要用Marabou，因为它的Python接口比较友好，而且支持多种网络格式。

实际使用中，Marabou对ReLU网络的支持最好，对Sigmoid和Tanh网络的支持有限。所以如果你的网络用了这些激活函数，可能需要先做近似处理，或者换用其他工具。

还有一个坑是：形式验证工具通常对输入维度很敏感。如果你的输入是原始图像，维度是几万甚至几十万，工具基本跑不动。必须先做降维，把输入压缩到几百维以内。

6.3 运行时监控的部署考量

运行时监控模块通常部署在安全核上，资源受限。所以代码要尽可能精简，避免动态内存分配，避免浮点运算（如果安全核没有FPU）。

我通常会用定点数来实现监控逻辑，把浮点运算转化为整数运算。这需要仔细设计数值范围和小数位数，确保精度损失在可接受范围内。

另外，监控模块的输入需要做时间同步。网络输出和雷达测量可能来自不同的传感器，时间戳不一致会导致误判。我通常会用硬件触发信号来做同步，确保两个数据来自同一时刻。

6.4 文档与证据链的整理

功能安全论证最终要落到文档上。你需要准备的材料包括：安全计划、危害分析与风险评估、安全需求规格、网络架构设计文档、训练过程记录、验证报告、运行时监控设计文档、测试报告等。

这些文档不是写完就完了，它们之间需要有一致性和可追溯性。比如安全需求规格中的每一条需求，都要能在验证报告中找到对应的验证结果。我通常会用需求管理工具（如DOORS）来建立这种追溯关系。

注意：文档工作最好从项目第一天就开始做，不要等到评审前才补。补出来的文档往往漏洞百出，而且会消耗大量精力。

7. 一些个人体会

这个方向我做了两年多，最大的感受是：神经网络的功能安全论证不是一个纯技术问题，它是一个技术加沟通加流程的综合问题。你不仅要把技术做扎实，还要能把你的论证逻辑清晰地传达给评审方。

技术层面，我认为未来几年会有几个突破方向。一是形式验证工具的可扩展性会大幅提升，能处理更大规模的网络。二是安全约束嵌入的方法会更加成熟，可能出现标准化的安全层设计模式。三是运行时监控会走向标准化，可能出现通用的安全监控IP核。

但不管工具怎么进步，有一个原则不会变：你不能把安全责任完全交给神经网络。神经网络是一个强大的工具，但它不是一个可信任的安全载体。你需要用确定性的手段去约束它、监控它、兜底它。这个思路在功能安全领域是通用的，只不过在神经网络上表现得更加突出。

最后分享一个小技巧：如果你刚开始做这个方向，不要一上来就搞一个大而全的框架。先从一个小的、具体的模块入手，把安全需求分解、约束嵌入、形式验证、运行时监控这条链路完整走一遍。走通之后，再逐步扩展到更大的系统。这样你踩的坑会少很多，而且每一步都有实实在在的产出。