自动驾驶安全实践挑战及思考

上海盘石是一家专业从事汽车功能安全、预期功能安全、信息安全相关的培训、流程咨询、产品咨询、工程服务的专业公司。

上海盘石信息技术有限公司创始人边军以“自动驾驶安全实践的挑战与思考”为主题，围绕如何设计可靠冗余、如何让Linux满足功能安全、如何覆盖感知系统的各种故障模式、如何正确判断自动驾驶设计的ODD、如何定义自动驾驶的安全验收标准、如何解决自动驾驶仿真环境与现实世界的差异等问题展开。以下是发言摘要:

上海盘石信息技术有限公司创始人边军。

如何设计可靠的冗余

首先，我简单介绍一下自己。我从2009年开始接触功能安全。当时常用的标准是IEC 61508，应用于工业领域。到现在为止，我从事安全相关的开发和审计已经十几年了。首先说一下成立上海盘石信息技术公司的初心。经过十几年的工作，我看到国内的安防领域和国外还是有一定差距的，主要表现在自动驾驶领域，芯片和软件质量，尤其是自动驾驶领域。安全是从L2到L3演进过程中最关键、最基本的一点，这个环节的完成将影响整个自动驾驶产业在中国的落地。

自动驾驶的安全需要聚集国家和社会的财力和知识资源，建立产业连接，才能真正解决其在安全方面的共性问题，最终帮助中国落地自动驾驶。我今天带来的内容主要分为六个方面，主要是我在整个自动驾驶发展过程中遇到的问题和挑战，需要大家共同探讨和完成。

第一，如何设计一个可靠的冗余系统，自动驾驶会从L1进化到L4，安全冗余设置会越来越多。从L3-TJP交通拥堵辅助和L3-HWP高速公路诱导的功能出发，在转向、机动和定位方面会有冗余要求。L3以上，安全冗余会有全方位的要求，涉及感知、域控、电控等基本操作层面。

从2018年到现在，中国已经形成了自己的系统解决方案，但是有些解决方案并不代表这个领域已经真正实现量产，还有很多技术问题没有解决。首先，系统需要有有效及时的故障检测机制。“有效”强调安全冗余机制的性能。国内的安全冗余设计往往是多种安全机制的相互制衡。如果一个安全机制失效了，还要注意另一个安全机制的性能是否能满足要求。例如，郑路匹配和绝对定位一起构成了道路级定位的冗余设计。一旦绝对定位失败，郑路匹配方案是否足够精确支持车辆运行是需要考虑的问题。

“及时”强调冗余机制的切换时间，要求系统在短时间内检测出故障点，并迅速切换到备用机制，保证系统的正常运行。例如，如果将摄像头和激光雷达结合起来作为车道线识别的冗余设计，一旦激光雷达出现故障，实际车道线将逐渐偏离摄像头车道线，这就需要激光雷达本身的安全机制及时检测到故障，然后系统将及时切换到基于摄像头输出的侧向控制。如果不能及时发现故障，实际行驶车道线与摄像头车道线偏差过大，系统无法确认故障点，必须采取紧急制动。

第二个难点是复杂的系统设计增加了冗余设计独立的难度。工作人员需要考虑各种共因故障和级联故障，尤其是传感器融合中使用的一些设计，需要考虑传感器的时间戳、自运动状态等共因。除了电子和电气……ical故障、外部环境因素也会导致冗余设计的失败。例如，降雨可能会导致相机和激光雷达的性能下降。

做冗余设计时，要考虑五个方面。首先要做充分的安全性分析，比如FTA，考虑冗余机制由于性能限制的失效概率。第二，在开发初期做DFA分析，避免潜在的公共失败和级联失败。第三，要有时间规划，要缩短自我诊断和相互验证的时间。第四，加大对系统工程的投入。第五，冗余设计不仅要实现ASIL层次分解，还要考虑失效操作。为了顺利减少故障，传感系统需要至少三个独立的功能/机制，并通过“三取二”的策略快速识别故障。

如何让Linux满足功能安全

与其他系统相比，Linux有很多优点。一方面是免费开源，软件库丰富，开发成本低。另一方面综合性能强，响应时间和速度更快，能更有效地运行软件任务，支持多核运行，适用于不同硬件。同时，Linux也有一些缺点，例如，整个开发过程无法满足与功能安全相关的标准。下面总结了Linux在功能安全性方面遇到的几个主要挑战:

首先是缺少文档，开发过程无法追溯。有鉴于此，可以使用软件FMEA分析对软件模块进行白盒化，识别故障模式和影响，也可以使用ASIL安全等级分解从不同层次对软件模块进行监控，但如果采用软件监控，则需要另外考虑其独立性。

其次，难以保证硬实时性。鉴于此，常见的策略是添加实时内核，用双内核运行，但这种方案也存在很多问题，比如实时内核无法具备Linux内核的优点，Linux内核无法满足安全性。为了保证硬实时，采用双内核可能会导致代码移植的问题。

第三，代码和单元测试的工作量是巨大的，为了安全，需要对不符合ISO26262编码规范的代码进行裁剪和重新编译。第四，安全改造后，Linux的优势消失。业内有一种假设，未来可能不会出现收缩包装的Linux软件包，可以应用于安全性要求高的应用，但硬件的通用性可能会打折扣。

从行业进展来看，目前国内外的组织都在致力于提高Linux系统的安全性。所以从长远来看，Linux可能是一个更加开放的平台，未来在安全产品中使用还是有相当大的概率的。

如何覆盖感知系统的各种失效模式

目前整个自动驾驶的难点其实是感知。例如，L1和L2自动驾驶的主要目标是防止意想不到的AEB与后车相撞。过渡到L3后，会增加很多额外的安全目标，比如正确识别道路边缘信息；正确识别前方障碍物，防止错前追尾；正确识别代表ODD的信息，防止系统进入未知的危险状态。

目前，感知的安全目标主要是为L1和L2级别定义的。一旦应用于L3级系统，如何考虑这些偏差将成为行业难点。想象一下早高峰由阴转雨的场景。你正在一个十字路口开车，突然摄像头失灵了。然后你会看到以下场景:行地址失败，列地址失败，控制寄存器失败，像素数据流水线失败，内存/寄存器寻址失败，图像数据流水线失败。

图片来源:上海盘石信息科技有限公司。

在L3自动驾驶仪中，既要保证目标的正确识别，又要保证ODD的正确识别，同时还要考虑各种故障对它的影响，这实际上工作量非常大。之前见过一些国外的芯片。他们做这个分析的时候，可能会列出上千个场景，考虑每个场景的影响，以及如何解决。

鉴于上述困难，业界也提出了几种摄像机的安全机制。一种是像素级模拟测试，主要针对像素点。常见的方法如模拟信号范围筛选、ADC测试方案、行/列存储数据路径测试方案，最后是冗余。像素模拟测试可以解决像素颜色、强度、对比度的问题，也可以发现大于某个阈值的噪声，但是没有办法解决像素的时空表达，也没有办法解决图像传输中的问题。

对于图像测试，这也是目前业内普遍采用的方式。典型的做法是给出一个参考图像，然后从参考图像中知道应该输出什么目标。这种方法的优点是可以测试像素的时间和空间表达，但也有一些缺点，其诊断覆盖率难以满足一定的要求，难以遍历数量巨大的故障模式。

三是测试成分，内容涵盖像素的颜色、强度、对比度；像素的时间和空间表达；图像传输；也可以发现大于阈值的噪声，相当于白芯测试，采用关键数据写保护；CRC寄存器；温度和电压检测；时钟检查等等。

图片来源:上海盘石信息科技有限公司。

我觉得这些方法以后肯定会结合起来，但是如何设计出一个诊断覆盖率高，可以适用于不同安全目标的方案，是所有相机厂商和后端芯片厂商的难题。

如何正确判断自动驾驶设计的奇数操作设计域

事实上，在自动驾驶早期，大家更倾向于使用静态奇数约束和地理围栏。到目前为止，纯静态的运行设计域约束已经不再适用，系统需要有一个有效及时的反映环境条件的动态检测机制，以保证系统始终在可接受的风险下运行。

这里有两个例子。左图是单个因素影响的评估:比如阳光直射导致摄像头反光，系统如何判断什么程度的反光会影响驾驶员，什么时候应该退出，这是目前行业的难点。右图是多个影响因素的耦合:雾夜，迎面远光灯，此时系统如何评估是退出还是继续跑？

图片来源:上海盘石信息科技有限公司。

以下是基于传感器原理方法的环境触发条件识别案例:车辆行驶在金属护栏道路边缘，雷达反射导致虚拟场景，系统误以为前方有车，导致误制动。

图片来源:上海盘石信息科技有限公司。

如何定义自动驾驶的安全验收标准

针对如何定义自动驾驶的安全可接受性标准，首先解决两个问题:一个已知的不安全场景如何被认为是可接受的？未知的不安全场景有什么解决方法？

针对已知的不安全场景，一方面需要量化系统安全性能要求，建立测试评估体系，同时需要解决模拟和测量中的技术难点，再现不安全场景，通过模拟测试结果判断是否满足安全要求。针对未知的不安全场景，也有两个问题需要考虑:一是如何定义自动驾驶放行的安全准则，什么样的碰撞概率是可以接受的；二是如何建立场景库，解决算法的安全问题，而不是总是测试实车，缩短测试周期。

具体来说，对于已知的不安全场景，期望安全标准列出了传感器、执行器、算法和集成系统的不同测试方法，但目前还没有量化KPI的方法。对于行业实践，很多指标需要量化定义。除了感知，实际上还有控制和决策的指标。如何分配和定义各个指标，是目前整个行业面临的难题。

为了解决这个问题，我们可以量化感知系统的安全KPI:第一层通过RSS或者TTC来评估安全距离是否合适。第二层是通过碰撞检查评估肇事者是否可控。缓解策略的效果如何？总体来说，通过这两条路线来评价决策系统是否足够安全。

图片来源:上海盘石信息科技有限公司。

如何解决未知场景安全问题，我们需要定义车辆安全准则:汽车行驶了多久，碰撞概率有多大。这是一个相对安全的概念。这是安全性和可用性之间的平衡，因此我们必须考虑定义可接受的风险。什么是可接受的风险？目前有几种想法。

首先，通过交通道路数据看不同场景下的风险标准。其次是参照功能安全ASIL A-D的等级标准来定义，定义了风险准则之后，还有一个问题，就是如何衡量。据估计，需要140亿公里才能证明自动驾驶算法的安全性。这直接反映了自动驾驶系统测得的工作负荷。所以我觉得模拟一定是未来的主流方向。虽然现在仿真存在各种缺点，但是随着数字软硬件技术的发展，这些问题会逐步得到解决。

如何解决自动驾驶模拟环境与现实世界的差异

整个仿真和现实世界还是有很大差别的，首先是因为传感器仿真模型的局限性。上海盘石是一家专业从事汽车功能安全、预期功能安全、信息安全相关的培训、流程咨询、产品咨询、工程服务的专业公司。

上海盘石信息技术有限公司创始人边军以“自动驾驶安全实践的挑战与思考”为主题，围绕如何设计可靠冗余、如何让Linux满足功能安全、如何覆盖感知系统的各种故障模式、如何正确判断自动驾驶设计的ODD、如何定义自动驾驶的安全验收标准、如何解决自动驾驶仿真环境与现实世界的差异等问题展开。以下是发言摘要:

上海盘石信息技术有限公司创始人边军。

如何设计可靠的冗余

首先，我简单介绍一下自己。我从2009年开始接触功能安全。当时常用的标准是IEC 61508，应用于工业领域。到现在为止，我从事安全相关的开发和审计已经十几年了。首先说一下成立上海盘石信息技术公司的初心。经过十几年的工作，我看到国内的安防领域和国外还是有一定差距的，主要表现在自动驾驶领域，芯片和软件质量，尤其是自动驾驶领域。安全是从L2到L3演进过程中最关键、最基本的一点，这个环节的完成将影响整个自动驾驶产业在中国的落地。

自动驾驶的安全需要聚集国家和社会的财力和知识资源，建立产业连接，才能真正解决其在安全方面的共性问题，最终帮助中国落地自动驾驶。我今天带来的内容主要分为六个方面，主要是我在整个自动驾驶发展过程中遇到的问题和挑战，需要大家共同探讨和完成。

首先，如何设计一个可靠的冗余系统……em，自动驾驶会从L1进化到L4，安全冗余设置会越来越多。从L3-TJP交通拥堵辅助和L3-HWP高速公路诱导的功能出发，在转向、机动和定位方面会有冗余要求。L3以上，安全冗余会有全方位的要求，涉及感知、域控、电控等基本操作层面。

从2018年到现在，中国已经形成了自己的系统解决方案，但是有些解决方案并不代表这个领域已经真正实现量产，还有很多技术问题没有解决。首先，系统需要有有效及时的故障检测机制。“有效”强调安全冗余机制的性能。国内的安全冗余设计往往是多种安全机制的相互制衡。如果一个安全机制失效了，还要注意另一个安全机制的性能是否能满足要求。例如，郑路匹配和绝对定位一起构成了道路级定位的冗余设计。一旦绝对定位失败，郑路匹配方案是否足够精确支持车辆运行是需要考虑的问题。

“及时”强调冗余机制的切换时间，要求系统在短时间内检测出故障点，并迅速切换到备用机制，保证系统的正常运行。例如，如果将摄像头和激光雷达结合起来作为车道线识别的冗余设计，一旦激光雷达出现故障，实际车道线将逐渐偏离摄像头车道线，这就需要激光雷达本身的安全机制及时检测到故障，然后系统将及时切换到基于摄像头输出的侧向控制。如果不能及时发现故障，实际行驶车道线与摄像头车道线偏差过大，系统无法确认故障点，必须采取紧急制动。

第二个难点是复杂的系统设计增加了冗余设计独立的难度。工作人员需要考虑各种共因故障和级联故障，尤其是传感器融合中使用的一些设计，需要考虑传感器的时间戳、自运动状态等共因。除了电子和电气故障，外部环境因素也会导致冗余设计的失败。例如，降雨可能会导致相机和激光雷达的性能下降。

做冗余设计时，要考虑五个方面。首先要做充分的安全性分析，比如FTA，考虑冗余机制由于性能限制的失效概率。第二，在开发初期做DFA分析，避免潜在的公共失败和级联失败。第三，要有时间规划，要缩短自我诊断和相互验证的时间。第四，加大对系统工程的投入。第五，冗余设计不仅要实现ASIL层次分解，还要考虑失效操作。为了顺利减少故障，传感系统需要至少三个独立的功能/机制，并通过“三取二”的策略快速识别故障。

如何让Linux满足功能安全

与其他系统相比，Linux有很多优点。一方面是免费开源，软件库丰富，开发成本低。另一方面综合性能强，响应时间和速度更快，能更有效地运行软件任务，支持多核运行，适用于不同硬件。同时，Linux也有一些缺点，例如，整个开发过程无法满足与功能安全相关的标准。下面总结了Linux在功能安全性方面遇到的几个主要挑战:

首先是缺少文档，开发过程无法追溯。有鉴于此，可以使用软件FMEA分析对软件模块进行白盒化，识别故障模式和影响，也可以使用ASIL安全等级分解从不同层次对软件模块进行监控，但如果采用软件监控，则需要另外考虑其独立性。

其次，难以保证硬实时性。鉴于此，常见的策略是添加实时内核，用双内核运行，但这种方案也存在很多问题，比如实时内核无法具备Linux内核的优点，Linux内核无法满足安全性。在……为了保证硬实时性，采用双核可能会导致代码移植的问题。

第三，代码和单元测试的工作量是巨大的，为了安全，需要对不符合ISO26262编码规范的代码进行裁剪和重新编译。第四，安全改造后，Linux的优势消失。业内有一种假设，未来可能不会出现收缩包装的Linux软件包，可以应用于安全性要求高的应用，但硬件的通用性可能会打折扣。

从行业进展来看，目前国内外的组织都在致力于提高Linux系统的安全性。所以从长远来看，Linux可能是一个更加开放的平台，未来在安全产品中使用还是有相当大的概率的。

如何覆盖感知系统的各种失效模式

目前整个自动驾驶的难点其实是感知。例如，L1和L2自动驾驶的主要目标是防止意想不到的AEB与后车相撞。过渡到L3后，会增加很多额外的安全目标，比如正确识别道路边缘信息；正确识别前方障碍物，防止错前追尾；正确识别代表ODD的信息，防止系统进入未知的危险状态。

目前，感知的安全目标主要是为L1和L2级别定义的。一旦应用于L3级系统，如何考虑这些偏差将成为行业难点。想象一下早高峰由阴转雨的场景。你正在一个十字路口开车，突然摄像头失灵了。然后你会看到以下场景:行地址失败，列地址失败，控制寄存器失败，像素数据流水线失败，内存/寄存器寻址失败，图像数据流水线失败。

图片来源:上海盘石信息科技有限公司。

在L3自动驾驶仪中，既要保证目标的正确识别，又要保证ODD的正确识别，同时还要考虑各种故障对它的影响，这实际上工作量非常大。之前见过一些国外的芯片。他们做这个分析的时候，可能会列出上千个场景，考虑每个场景的影响，以及如何解决。

鉴于上述困难，业界也提出了几种摄像机的安全机制。一种是像素级模拟测试，主要针对像素点。常见的方法如模拟信号范围筛选、ADC测试方案、行/列存储数据路径测试方案，最后是冗余。像素模拟测试可以解决像素颜色、强度、对比度的问题，也可以发现大于某个阈值的噪声，但是没有办法解决像素的时空表达，也没有办法解决图像传输中的问题。

对于图像测试，这也是目前业内普遍采用的方式。典型的做法是给出一个参考图像，然后从参考图像中知道应该输出什么目标。这种方法的优点是可以测试像素的时间和空间表达，但也有一些缺点，其诊断覆盖率难以满足一定的要求，难以遍历数量巨大的故障模式。

三是测试成分，内容涵盖像素的颜色、强度、对比度；像素的时间和空间表达；图像传输；也可以发现大于阈值的噪声，相当于白芯测试，采用关键数据写保护；CRC寄存器；温度和电压检测；时钟检查等等。

图片来源:上海盘石信息科技有限公司。

我觉得这些方法以后肯定会结合起来，但是如何设计出一个诊断覆盖率高，可以适用于不同安全目标的方案，是所有相机厂商和后端芯片厂商的难题。

如何正确判断自动驾驶设计的奇数操作设计域

事实上，在自动驾驶早期，大家更倾向于使用静态奇数约束和地理围栏。到目前为止，纯静态的运行设计域约束已经不再适用，系统需要有一个有效及时的反映环境条件的动态检测机制，以保证系统始终在可接受的风险下运行。

这里有两个例子。左图是单个因素影响的评估:比如阳光直射导致摄像头反光，系统如何判断什么程度的反光会影响驾驶员，什么时候应该退出，这是目前行业的难点。右图是多个影响因素的耦合:雾夜，迎面远光灯，此时系统如何评估是退出还是继续跑？

图片来源:上海盘石信息科技有限公司。

以下是基于传感器原理方法的环境触发条件识别案例:车辆行驶在金属护栏道路边缘，雷达反射导致虚拟场景，系统误以为前方有车，导致误制动。

图片来源:上海盘石信息科技有限公司。

如何定义自动驾驶的安全验收标准

针对如何定义自动驾驶的安全可接受性标准，首先解决两个问题:一个已知的不安全场景如何被认为是可接受的？未知的不安全场景有什么解决方法？

针对已知的不安全场景，一方面需要量化系统安全性能要求，建立测试评估体系，同时需要解决模拟和测量中的技术难点，再现不安全场景，通过模拟测试结果判断是否满足安全要求。针对未知的不安全场景，也有两个问题需要考虑:一是如何定义自动驾驶放行的安全准则，什么样的碰撞概率是可以接受的；二是如何建立场景库，解决算法的安全问题，而不是总是测试实车，缩短测试周期。

具体来说，对于已知的不安全场景，期望安全标准列出了传感器、执行器、算法和集成系统的不同测试方法，但目前还没有量化KPI的方法。对于行业实践，很多指标需要量化定义。除了感知，实际上还有控制和决策的指标。如何分配和定义各个指标，是目前整个行业面临的难题。

为了解决这个问题，我们可以量化感知系统的安全KPI:第一层通过RSS或者TTC来评估安全距离是否合适。第二层是通过碰撞检查评估肇事者是否可控。缓解策略的效果如何？总体来说，通过这两条路线来评价决策系统是否足够安全。

图片来源:上海盘石信息科技有限公司。

如何解决未知场景安全问题，我们需要定义车辆安全准则:汽车行驶了多久，碰撞概率有多大。这是一个相对安全的概念。这是安全性和可用性之间的平衡，因此我们必须考虑定义可接受的风险。什么是可接受的风险？目前有几种想法。

首先，通过交通道路数据看不同场景下的风险标准。其次是参照功能安全ASIL A-D的等级标准来定义，定义了风险准则之后，还有一个问题，就是如何衡量。据估计，需要140亿公里才能证明自动驾驶算法的安全性。这直接反映了自动驾驶系统测得的工作负荷。所以我觉得模拟一定是未来的主流方向。虽然现在仿真存在各种缺点，但是随着数字软硬件技术的发展，这些问题会逐步得到解决。

如何解决自动驾驶模拟环境与现实世界的差异

整个仿真和现实世界还是有很大差别的，首先是因为传感器仿真模型的局限性。目前常用的仿真软件可以模拟大部分传感器。但是对于污渍和强光的场景，在仿真中很难做出定量的判断，只能定性的处理，所以很难通过仿真发现算法的边界问题。

更大的困难是建立一个与真实世界相似的场景模型。场景仿真的计算量很大，如何支持其物理仿真工作。目前可以把它拆解成几个与功能安全相关的小场景模块，这是未来一个可能的发展方向。

一般来说，为了解决自动驾驶仿真环境与现实世界的差异，可以采用场景库的模式:对于决策系统，通过模拟与现实世界足够接近的场景库，来识别决策算法的缺陷。也可以采用随机交通流的方法:由具有自主驾驶能力的智能体或智能体集群组成的动态背景车辆与测试对象交互生成场景，在随机交通流中进行决策模拟。

(以上内容来自于2022年8月26日由Gaspar主办的2022中国汽车信息安全与功能安全大会上，上海盘石信息技术有限公司创始人边军发表的《自动驾驶安全的现实挑战与思考》主题演讲。)目前常用的仿真软件可以模拟大部分传感器。但是对于污渍和强光的场景，在仿真中很难做出定量的判断，只能定性的处理，所以很难通过仿真发现算法的边界问题。

更大的困难是建立一个与真实世界相似的场景模型。场景仿真的计算量很大，如何支持其物理仿真工作。目前可以把它拆解成几个与功能安全相关的小场景模块，这是未来一个可能的发展方向。

一般来说，为了解决自动驾驶模拟环境与现实世界之间的差异，我们可以ado……场景库的模式:对于决策系统，我们可以通过模拟足够接近真实世界的场景库来识别决策算法的缺陷。也可以采用随机交通流的方法:由具有自主驾驶能力的智能体或智能体集群组成的动态背景车辆与测试对象交互生成场景，在随机交通流中进行决策模拟。

(以上内容来自于2022年8月26日由Gaspar主办的2022中国汽车信息安全与功能安全大会上，上海盘石信息技术有限公司创始人边军发表的《自动驾驶安全的现实挑战与思考》主题演讲。)

标签：优越发现

汽车资讯热门资讯