凤凰网汽车

3月9日，地平线在智东西公开课开设的「地平线AI芯片技术专场」完成了第3讲的直播，地平线系统及人工智能安全总监杨虎以《如何翻越自动驾驶AI系统安全高峰》这一主题进行了直播讲解。

如果说自动驾驶处理器是人工智能产业的珠穆朗玛，那么，攀登人工智能的珠峰，务必要翻越“系统安全”的崇山峻岭。

杨虎老师从自动驾驶所带来的安全挑战、自动驾驶AI系统安全的内涵、 AI 芯片的安全量产实践和AI算法安全的可衡量性四方面进行了全方位解读。

本次专场分为主讲和Q&A两个环节，以下则是主讲回顾：

大家好，很高兴和大家交流如何翻越自动驾驶AI系统安全高峰。我叫杨虎，地平线系统及人工智能安全总监，曾在多家行业主流Tier 1和OEM公司担任系统安全相关职位，负责ADAS系统的功能安全工作，实现了功能安全团队及流程从0到1的搭建。我也是ISO 26262功能安全及ISO 21448预期功能安全国际标准制定小组成员，参与了IEEE P2846、IEEE P2851和IEEE P3130自动驾驶国际安全标准制定工作。

以下是本次课程讲解的主要内容，大概分为4个部分：

1、自动驾驶所带来的安全挑战

2、自动驾驶系统安全的内涵

3、AI芯片的安全量产实践

4、AI算法安全的可衡量性

1

自动驾驶所带来的安全挑战

大家对ISO 26262和FUSA可能比较熟悉，在神经网络算法里，业内做过一些故障注入实验。如上图上半部分所示，如果改变原始图像中的一个像素点，在交通标志灯的分类结果中，绿灯的分类结果可能会变成红灯。在高等级自动驾驶系统中，如果把交通标志灯的分类结果引入到控制环中，由单一像素引起的错误可能会导致交通事故的发生，这显然不是做安全工作的人期望看到的。

同时，地平线内部也做过一些类似的故障注入实验。如上图左下角所示，在神经网络不同层注入单一像素错误，注入错误后目标数少于1个占比达到3.4%，目标数多1个或2个分别占比为3%和0.2%，目标数不变的占比大概是93.4%。同样，如果在不同层注入一个像素错误，可能会导致物体的位置或大小发生变化，变化比例约在20%~25%左右，这对目标检测、距离判断等有非常大的影响，也会带来一些安全方面的问题。

单一像素的错误有可能来自于硬件故障，像RAM的某一个bit错误了，或里面的某个加法器、乘法器逻辑有问题，最终导致的结果都是很可怕的。

2018年，Uber在进行自动驾驶汽车测试时，撞死了一名横穿马路行人。这起事故在世界范围内引起了很大的舆论，也引发了人们对自动驾驶行业发展的安全担忧。还有之前特斯拉撞上一辆横穿马路的白色大货车，车辆以为检测到的是云朵，然后没有来得及识别，发生了致命的事故。

在Uber这起事故发生过程中，美国 NTSB发布了一个调查报告，报告中详细给出了碰撞前的时间线，比如在碰撞前2.7~3.8秒时，系统对该行人的识别结果在“车辆”和“其他”之间摇摆不定；距离碰撞还有2.6秒时，系统将该行人和她的自行车识别为“自行车”；然后在距离碰撞1.5秒时，该行人又被系统识别是“未知”；在碰撞前的1.2秒识别结果又变成了自行车。结果来回翻转、不停切换，最终导致了这起事故的发生。

与上面提到由单一像素错误导致的交通事故不同，在这起事故中可以明显看到，在这个过程中没有错误、硬件失效和软件故障，唯一的问题是整个自动驾驶系统没有充分考虑对场景的应对，这也是ISO 26262 功能安全方法论的局限性，即无法覆盖人为误用、功能不足和性能局限，这就需要从ISO 21448预期功能安全的角度来考虑问题并给出解决方案。

另外，随着高等级自动驾驶系统的不断演进和行业不断发展，传统的基于规则的编程方法，像画状态流程图、写软件需求、设计软件架构、单元设计、测试验证等传统的V模型开发模式，即软件1.0的开发模式，逐渐被软件2.0的开发模式取代。软件2.0的开发模式需要先定义问题，把问题定义清楚之后，做一个网络架构，然后不断的收集数据，再不断的训练和迭代优化整个网络结构，最后达到一定的性能表现时，把产品投放到市场上，这也是特斯拉的开发模式对传统V模型开发模式的迭代更新。既然开发模式变了，那应对新开发模式的Safety和Security问题，所采取的手段与方法也应不同。

Safety和Security也面临着一些新问题，像利用激光笔做幻影攻击。如上图左上角所示，掉头的标志牌用一支激光笔照射时，可能会分类成交通灯，置信度为0.45；人行道的标志牌经过激光笔照射，可能会被分类成电影院；同样，双层巴士可能会被检测成蟾蜍；停车场的标志也会被错误的分类成皂液瓶。如果人为的用激光笔恶意照射，可以认为是Security要应对的问题。但如果是在城区场景下，这种光影变换很常见，可能又回到了Safety应对的场景里，所以这个问题会有点混合，从源头上来看，很难界定它是 Security还是Safety问题，但产品设计中一定要把这个问题解决掉才能安全应用。

同样，上图左下角的标志牌也类似，上面一些白色标签、黑色标签或人为贴的补丁也会导致识别结果错误。还有随着时间的延长，标志牌可能出现掉漆、老化的问题，导致交通标志检测和分类出现错误，这种情况很难将它归类为Security还是Safety问题，但产品中一定要把这些问题解决掉。

综上所述，如果只遵守ISO 26262应对自动驾驶所带来的安全问题足够吗？显然是不够的，例如上图左半部分人穿着鸡的服装，他的分类结果是no person，probability达到了0.99，实际上人藏在鸡的服装里，但神经网络并不能很准确的检测出里面有人。同样中间部分的图像中，在马路上画一个小姑娘，如果神经网络设计足够smart，有可能检测出是一个行人。还有在逆光环境中，功能或器件并没有失效，但在这种场景下，对于目标识别跟检测也会有一些影响。同样，一些穿奇装异服的人，如果只考虑ISO 26262应对这些场景，很显然是无法应对这个复杂而真实的世界。

那面对自动驾驶场景下带来的诸多安全挑战，该如何应对？首先要分析和界定自动驾驶系统安全的内涵。

2

自动驾驶系统安全的内涵

对于自动驾驶系统安全的内涵，首先要做安全风险的梳理。如果从产生原因划分，安全风险可以来自于产品内部，也可以来自于产品外部。产品内部又可分为功能失效与功能不足，功能失效包括硬件随机失效和系统性故障，可以采用ISO 26262和功能安全的方法论去处理；如果是功能不足，比如一开始设计时没有考虑到陌生场景，需要用SOTIF方法论处理。

产品外部原因可以分为性能局限和误用，性能局限包括逆光或者大雪场景，也是用SOTIF方法论来解决问题；误用分为无意误用与有意误用，无意误用也需要SOTIF方法论来处理问题，有意误用，比如网络攻击，就需要ISO 21434方法论来处理。

把安全风险做系统化梳理后，发现系统安全由网络安全、预期功能安全和功能安全三个部分组成，它们所应对的问题各不相同，但又互为补充。

在研究自动驾驶政策以及法规监管的一些动态时，会发现无论是中国、美国还是欧盟，有关高等级自动驾驶的产业政策或行业法规，都会不约而同的涉及到功能安全、预期功能安全以及网络安全。上图右上角是去年7月，工信部出台的有关智能网联车辆准入管理意见，里面明确提到了功能安全、预期功能安全以及网络安全这三个topic。欧盟在 Regulation No.157里也提到了System safety and Fail-safe Response和Cybersecurity and Software-Updates。美国也是如此，美国交通部与NHTSA、白宫的交流非常密切，每1~2年就会发布一个产业政策，像AV1.0、AV2.0、AV3.0、AV4.0，目前最高版本是AV4.0，这些产业政策对安全都很关注。

上图右半边是美国发布的一个自动驾驶车辆行动计划，它把自动驾驶车辆的关键技术点大概分为了20条，其中第一条、第二条、第十一条是有关于ISO 21434、ISO 26262以及ISO/PAS 21448。从这些工业强国的产业政策包含的内容可以看出，对安全的监管将变得越来越强。

那么系统安全如何实现落地呢？

3

AI芯片的安全量产实践

首先看下地平线系统安全的总览。地平线安全团队可以划分为三个不同部分，第一部分负责芯片安全，包括了 SoC的Safety架构跟Security架构；第二部分是系统及人工智能安全，这个部门负责整个公司的流程搭建、体系维护升级、整个公司的产品开发项目安全管理，也包括了 AI的安全研究；最后一部分是上层应用的安全，它也涵盖了两个方面：一个是Safety架构，另一个是Security架构。

有了这样强大的组织之后，地平线在产业界的参与度也比较多，像参与了 ISO的一些标准制定，以及IEEE 2846、IEEE 2851等，还有参与CAICA SOTIF工作以及ELISA组织等。

2020年9月时，地平线的产品开发流程通过了 ISO 26262 ASIL D级别认证，这证明了地平线具有开发最高级别功能安全产品的能力。地平线根据ISO 26262功能安全流程的要求进行产品研发，在随后的2021年7月，征程5 获得了ASIL B功能安全产品认证。这标志着地平线征程5芯片的功能安全架构、设计实现均达到了全球公认的汽车功能安全标准 ISO 26262 ASIL-B级别，满足世界一流OEM和Tier1的功能安全开发要求。征程5也是中国首颗基于ISO 26262功能安全流程开发的车规级AI芯片。

同样地平线每年还会组织公司级的功能安全外部培训，如果今年的培训计划实施完，地平线会有近100位工程师拿到第三方的功能安全资质认证。这些工程师并不专门从事系统安全的工作，他们分散在软件开发、测试和项目管理等等不同的职能和业务部门里，将系统安全落地在自动驾驶技术研发的全流程中。

下面介绍下地平线的功能安全管理框架。功能安全管理目标分为三个层次：一个是总体功能安全管理，即建立和维护总体的功能安全管理流程与文化，并持续改进；第二个是产品开发项目的功能安全管理，即确保整个产品开发项目里的一些确认措施符合ASIL等级要求，包括评审，流程审核和产品评估；第三个是量产功能安全管理，当产品投放到市场之后，产品的功能安全怎样做现场监控，怎样通过质量途径做售后的反馈及更新。上图右半部分解释了地平线总体的安全管理架构，包括上面提到的三个维度。

有了安全管理的基础之后，技术实现层面也需要考虑系统安全。考虑一个ADAS控制器的抽象的安全架构，由于地平线是做视觉感知起家的公司，所以在视觉方面的投入会多一些，抽象架构也是以Camera Sensor为主，其他像激光雷达、毫米波雷达、超声波雷达等划归为Other Sensor。

ADAS控制器主要处理器是征程系列的SoC，它里面又分为两大部分：一部分是图像处理，另一部分包括感知、Fusion、 Planning模块。在图像处理部分包括图像接口，像MIPI、ISP、IPU、GDC以及光流等模块。从征程5的实施经验来看，这些模块可以达到ASIL B等级。图像预处理的信号出来后，经过AI感知做一些卷积处理，处理完在CPU里做Fusion或Planning，目前在征程5上也做到了ASIL B等级，未来产品可能达到ASIL D等级。同样，外部MCU可能做一些控制车辆的功能，它的等级会高些，可以达到ASIL D。随着集成度越来越高，外部MCU会逐渐集成到SoC内部，整个SoC的ASIL等级就会不断提升，外部可能只需要一些简单的器件，比如DDR、EMMC等，再加上一些 fall back机制，这就是抽象的ADAS控制器的整个安全架构。

征程5 SoC是业界最为复杂的一颗AI芯片，在征程5内部集成了很多的功能安全特性，比如用于系统监控、诊断和恢复的隔离安全岛；锁步CPU/FCHM/DMA/WDT；外围E2E保护；具有比较逻辑自检的关键路径上的延迟双锁步逻辑；受ECC/奇偶校验保护的SRAM；DDR 受Inline ECC 保护；寄存器有奇偶校验、回读机制去做检查；关键控制模块：Triple-voted flip-flop；电压、时钟、温度监控也会有独立的监控在里面；上电时存储器和逻辑 BIST；同时也支持运行时测试模式/软件测试库等等。征程5除了拥有特别多的safety feature之外，security方面的设计也很多。对征程5 SoC Security需求的整体来源做系统性梳理后，发现它包括了系统&应用层级的知识、市场趋势&客户需要、系统化的Security工程开发方法，像TARA，TCC等，以及行业标准&法规等，从而确保方案不会出现一些关键需求的遗漏。同样，征程5上所支持的Security特性包括了安全启动、安全刷新、安全通信、安全存储、密钥管理、安全配置等。征程5还有一个独特的特性是AI模型保护，即内部提供了一种通过内存防火墙保护DDR中存储的AI模型的方法。同样，在安全调试上，当使用不同的系统资源访问时，提供不同的调试模式。

在征程5芯片上，考虑完FUSA、Security特性之后，要想真正把一颗芯片做到量产，还得考虑上层算法。上层算法在做高等级自动驾驶的安全风险分析时，发现还需要有SOTIF方法来解决，否则如果只是把Safety和Security问题解决掉，上层算法在应对未知或已知的不安全场景时，没有方法论可以迭代收敛上层算法，使得芯片只是一个硬件，无法真正做到量产上车。

意识到这点之后，我仿照ISO 21448方法论做了一个SOTIF工作流，它与 ISO 21448标准里的需求一一映射。如上图所示，首先要做功能的定义与描述，接着做SOTIF Risk识别与可接受准则的确立，之后做SOTIF trigger condition的分析与梳理，这里涉及到STPA、FEMA、FTA等方法，这些SOTIF triggering会形成SOTIF的safety concept。

SOTIF safety concept可以帮助改进算法和软件产品。产品改进完之后，根据SOTIF HARA识别出的可接受准则，制定V&V Strategy。通过V&V Strategy评估已知的不安全场景是否达到了可接受准则要求的度量，同时通过大里程的累积路试，评估产品应对未知不安全场景的能力，如果这些都符合产品释放准则，就会把产品释放到市场。释放到市场之后，还要做好现场监控。由于现在的生活环境与10年前的生活环境有了很大变化，同样一辆车的生命周期如果是10年，它周围的环境，包括道路的基础设施及人的交通设备都与10年前不同，这10年的生命周期跨度里自动驾驶车辆所要应对的场景变化非常巨大，这时必然需要监控整个自动驾驶车辆所要面对的环境，看它与最初设计的自动驾驶功能、数据集是否一致，如果不一致，就要做迭代、更新。

SOTIF HARA 与 FUSA HARA 类似，以危害事件的 S/E/C 值评定，但 FUSA 以 S+E+C>=7 来认定为危害事件，SOTIF 只要S>0 或 C>0 时就会被认为是危害事件。上图的例子分析了非预期减速度的值，如果两辆车要避免碰撞，它俩之间的间隔距离要大于等于0，由此建立一个物理模型，求解出非预期的减速度要小于等于0.2g，然后再通过可控性的分布以及场景贝叶斯条件概率等，可以算出总确认里程大概是1560000公里。但如果用条件概率做可接受准则的确认，可能会把总确认里程1560000公里会往下降一些，到156000公里。如果没有大于0.2g的非预期减速度，就认为满足了SOTIF的可接受准则。

156000公里是怎样算出的呢？可以分为5步，第一是选择接受准则，比如在ISO 21448里有三大原则：ALARP、GAMAB、MEM，地平线现在用的是GAMAB，即由新功能引起的危害事件概率不超过由人类驾驶员引起的等效危害事件概率；大的原则确立好之后，下一步是计算基础的确认目标，用总里程数除以国家交通部门统计出来的致死交通事故数，可以算出致死两起交通事故之间的安全行驶里程是什么量级，这个量级算出来之后，还要做一些余量修正；第三步是选择对应的统计模型，考虑到交通事故数量有限，选用泊松分布来计算；之后在实际验证中，选择好置信度、安全裕度等，算出一个值；最后这个值再根据贝叶斯条件概率导出确认里程数156000公里。

做完SOTIF HARA以及确立可接受准则之后，还要做SOTIF触发条件分析，当性能局限和触发条件同时发生时，可以认为是相关项的故障行为，同时驾驶员误用也应当把它视为触发条件。在触发条件分析中，采用一些结构化的推导方法去做分析，如上图右半部分所示。比如分析 Camera感知、雷达感知和定位等的触发条件，可以一层一层的往下细分。以Camera感知为例，又分为Sensor特性参数包括了FOV等；环境这块包括了低照度、雨、雪天气等等；算法里面包括了异形车、延迟等都要做一些量化分析。

分析完后，根据一些需求驱动算法的更新，更新完后根据前面设定的可接受准则做一些验证策略。在SOTIF验证策略中主要有两大块：一个是仿真，在51SIM中构建触发条件，然后在专门的客户端自动评估51SIM中的真值与感知结果的差异；另一个是封闭道路验证，我们会配备装有真值设备的车辆，通过地平线的AIDI评估平台做数据闭环的处理。

SOTIF要应对未知的不安全区域，主要包括里程累计测试和HIL仿真。一般情况下，Bad Case应考虑危害度量，比如前面提到的模型，0.25g非预期减速度持续3s，大概率会导致碰撞事件的发生，这才是SOTIF领域需要关注的不安全行为。有了一些定量值之后，通过量化的准则，在AIDI数据集里搜集类似的场景，然后把它识别出来，不断累积这样的case，再通过修改软件，达到 156000公里的目标，则可以认为这种未知不安全区域的风险，已经满足了设定的释放准则。

实车数据的规划和监控也很重要，在一开始定义功能时，就需要考虑目标市场的真实使用环境和场景，开发用到的数据就会根据目标市场去采集。在产品开发过程中，收集到的数据不断增长，数据的分布有可能会偏离预定义好的规划。在AIDI平台上就会有一个数据分布的监控功能，来提升数据质量，只有收集回来的数据能够满足预定义好的场景分布，只有这样才能确保开发出来的产品，能够以终为始，真正应对最初定义好的场景。

讲完系统安全在地平线的落地实现，那面向未来，应该如何衡量AI算法的安全呢？

4

AI算法安全的可衡量性

传统汽车领域的安全关键电子电气系统适用ISO26262等标准，采用V模型的方式从流程上进行保证。开发模式如果进化到软件2.0模式，主要是基于数据驱动的方式，通过不断的学习循环方式提升性能。这时可能要根据产品开发模式的特点，制定对应过程的保障，确保产品开发能够达到安全。

在ISO 5469里有一张非常形象的流程图如上图所示，把软件2.0时代的开发模式描述的很契合，像系统定义、风险分析、需求定义以及产品运行和监控，这与原来的V模型有一一对应的关系。但到了下半部分，比如数据准备、训练、V&V、大的回环迭代，它跟原来的V模型就有所不同，可以看出是一个不断迭代、不断回环的过程。

ISO 5469把AI技术的风险等级也做了两个维度的划分，第一个维度从现有安全方法论是否能够应对AI技术的评审和开发角度来看，把AI技术分为三个等级；另一个从使用场景上来看，如果使用AI技术能够自动生成决策控制，它可能就是A1等级，如果AI技术用在了与安全无关的场景里，它可能被分配到D等级，介于这两者之间的又做了一些细分，大概分为了A1、A2、B1、B2、C、D等6个等级。这6个应用等级与AI技术组合成上图的一张表，红色部分表示不推荐使用AI技术，黄色部分可能需要一些特定的要求，绿色部分也需要一些对应的安全风险减少的概念。ISO 5469处于一个非常前期的阶段，它类似于IEC 61508，先把等级定义好之后，再针对不同的色块提出一些具体的需求，比如针对不同的ASIL等级和不同的系统设计架构，包括软件单元设计、代码测试等这些方面衍生出一些具体的需求。

同样，从 AI开发和部署过程上来看，大体上分为定义、specify、架构设计、设计与评估、部署和监控几部分。在这个过程中，软件2.0时代的安全需保证覆盖采、存、筛、标、训、测、发各个阶段。如果考虑AI的安全，从流程上来讲，需要整体关注这些环节，然后在这些环节里添加重点的监控和保障措施，最终在流程上形成一个 Safety Augmentation/Assurance Case，涵盖 FUSA、SOTIF、Cyber Security三个方面的主题。通过这样的一个完整的证据链，才认为流程上是可以的。

这里也做了一些举例，比如规格不够充分，可能会有危害场景的缺失；规格语义存在差距，使得实际的数据集与规格定义的相似性不一致；与实际要求之间存在差距，导致系统需求未充分传递，训练集、测试集的属性或其分布与运行域不匹配，让系统的泛化和鲁棒性能力不足，或部署前后参数或者硬件平台发生变化导致不能达到性能要求等，这些都是过程上的一些控制措施。

关于行人分类规格的示例，上图是一个参考的示例，例如行人检测，当检测出遮挡小于某一个阈值时，应当分类出特定像素高度和特定像素宽度的行人；同时对每帧的误报率也有量化要求，比如对定位方面，要求垂直方向与真值偏差要小于某一个特定像素，水平方向与真值偏差要小于一个特定的像素；对于数据集，验证数据集应当覆盖真实环境情形中的一些特征，危害场景需要被充分的训练和验证，以保证已知的危害场景得到充分学习和良好的性能；技术也不应有偏见，针对不同年龄、性别、种族也要充分考虑，比如在暗光场景下，对一些肤色比较暗的人识别效果可能不太好，这时可能需要去补充一些数据做训练，避免从技术层面产生伦理安全问题的风险。

由于整个自动驾驶系统比较庞大，在系统安全措施方面包括了控制器上用到的AI技术，传统软件领域中的底层驱动软件以及OS和中间件，自动驾驶系统中的多传感器冗余，以及外部的一些其他系统，像ESP。只有这些保护机制都失效时，才可能导致危害事件的发生。从这个角度上来看，自动驾驶解决方案或系统的系统性安全措施可以从以下方面考虑，像运行时的系统性策略和非运行时的系统性策略，及部署运行时持续的Safety Assurance。

那在AI开发过程中应从哪些方面考虑安全措施呢？首先，在算法架构或者内部产品设计上有多重确认策略，例如在原始图像中检测一辆车时，需要先检测出它是一辆车，之后还要做车牌确认，这就是多重确认。还有一种是做ISO 26262里的ASIL 分解，即通过神经网络，做一个基于规则的监控器，把ASIL的要求或属性分给监控器，然后把低等级的 ASIL属性分给神经网络。

另外，在算法架构层级，可以有Redundancy和Ensemble等措施；在算法的功能层级，要考虑前后帧的时空一致性、对输入数据进行预处理和规则约束；在HADS系统层级包括了多样性传感器的冗余和融合、追踪和预测、运行模式间的转移、实际运行范围的约束等；在考虑System of system上，包括了人机共驾、系统间的协作，像fleet或众包等；在社会包括法律法规层面也要考虑一些安全措施。

除此之外，采用高等级自动驾驶系统时，即使车辆的驾驶行为非常中规中矩，比如当有一辆大货车经过它时，人心理上对自动驾驶车辆是不信任的，你会感觉到自动驾驶汽车在向大货车一端偏移。这又引出了人对自动驾驶汽车安全心理上的适应性，这时会涉及到人机交互，当自动驾驶汽车要过大货车时，要提前告知车主，缓解人的恐惧，实际上也是能够防止驾驶员误用等方面的一些措施。

除了前面提到 AI开发流程方面的一些保障措施，以及AI算法系统架构方面的安全措施之外，那怎样才算安全呢？像ISO 26262里，它的硬件部分有一个量化评估的值，比如对不同的ASIL等级，有不同的量化要求。那对于AI部分，是否有一些量化方面的分析与评价呢？从社会角度看，如何让社会大众认可它是一个可以信赖的系统呢？从自动驾驶系统的角度看，结合SOTIF可接受准则，使用AI发生的事故率，应该以什么样的准则才能认为 AI系统是足够安全的呢？从这些动因上考虑，我认为量化评价一个AI系统的安全裕度是非常有必要的，这也能够有效解决整个行业痛点：“究竟多安全才算安全”。

目前有一些初步的想法。类似于前面的可接受准则推导，假设自车轨迹碰撞的可接受风险概率为p，逐渐往下去分解时，比如行为和轨迹的Safety Boundary，它包括了不确定要求、多少米之内应该检测到前方行人位置精度、斜方差应该是多少等。

从现在的自动驾驶控制器总体产品架构上来看，现在的自动驾驶控制器的底层硬件和一些辅助器件，实际上还是传统的硬件，可以用以前的方法去处理。在此之上，涉及到的一些驱动、OS以及中间件等，实际上还是一个传统的软件开发模式，可以用ISO 26262的方法论来约束它。

怎样实现AI算法的量化呢？例如分类出特定像素高度且特定像素宽度的行人，可以给它分配一个风险量化值，像误差应小于多少，斜方差应该小于多少，标准差等。这样整个系统逻辑关系建立之后，就能量化出顶层可接受风险p值，如果p值与大原则相比，在可接受范围之内，基本上能够从形式化上证明产品，或 AI系统符合了当前可接受的安全水准。同时，从产品正向设计的方向去看，也建立了产品释放的安全信心。

最后做下总结，ISO 26262是汽车行业成熟的关于产品安全开发的经验总结，还会在硬件以及软件部分继续发挥一些基础性的作用。ISO 21448以及ISO 21434的作用会越来越重要，在执行过程中需要将这些方法融汇到产品开发中。除此之外，AI安全将面临新的问题，可能需要新的方法和流程来应对。同时，自动驾驶系统安全的难点是需要系统性的工程化考虑三大安全主题，并不仅仅是个“证”的问题，要开放地看待这件事情。