“陈音：智能网联汽车的安全设计思考与实践”

7月1日-2日，由盖世太保汽车主办的“2021第四届世界自动驾驶论坛”在上海隆重举行。 本次论坛将聚焦自动驾驶感知、智能驾驶域控制器、芯片、计算平台、无人驾驶不同落地场景等自动驾驶关键技术进行讨论，以促进自动驾驶相关技术的更快发展和完整性。 以下是北京汽车股份有限公司智能网联中心专业总师 陈音在这次大会上的发言。

你好。 我是北汽股份有限公司的陈音。 今天感谢盖西邀请我们在我们的ICV开发过程中分享整车安全设计的实践。 演讲分为四个方面: 1、ICV安全概念。 2、安全设计在工程开发中的应用。 3、安全性测试与验证。 4、问题与思考。

一、ICV的安全概念

这是汽车工程学会赋予的概念，涵盖的副本比以前流传下来的汽车要多得多。 不仅是汽车本身，特别是下一阶段汽车道路协同的ICV的情况下，高级自动驾驶安全可能不仅可以扩大到车自身的安全，还可以扩大到道路、交通、云控制系统。 我们的车自己安全了，但不够未来的无人车用。

首先，将安全性分为几个阶段。 基本安全、功能安全、预期功能安全和新闻安全。 其实ai引入后未知的东西也会一起带入，我们的感知系统、决策系统、相关环境都有很多不明确性。 在整体的安全考虑事项中，除了基本的安全性外，新闻安全性、功能安全性、预期的功能安全性等也会影响e/e架构的设计。 但是，e/e架构设计是整车开发的开始，在整个生命周期中架构无法改变，所以e/e架构决定了安全性的框架，也就是我们的天花板。 如果我的车设计了这样的e/e架构，将来ota会变成什么样？ 可以升级到什么程度？ 其实已经受到一定的限制。 在ICV的新概念下，我们将在新闻安全、功能安全、预期功能安全上进行越来越多的设计和考虑。

基本上很安全。 我想把它叫做安全功能本身。 因为在以前流传下来的安全概念中，根据事故发生的时期前后有几个阶段。 这些阶段基于以前流传的车有海因里希的模式。 这里有先行安全、主动安全、主被动融合、被动安全、事故救援等，这些对ICV来说都是基础性的。

从功能上来说，避免因电力电子系统的故障而产生不合理的风险，首要的是通过安全概念中定义的安全机制来应对。 其实功能安全的概念还是比较有趣的，大家都知道安全是相对的，没有绝对的安全。

功能安全，例如同样的功能在今天设计时和3年后设计时，其实那个要求会发生变化。 因为大家对安全的理解，包括接受程度在内都会发生变化。

期望功能的安全性，首要的是避免因期望的性能表现限制和误用而产生不合理的风险，它强调故障以外的原因造成的危害，通过odd、功能裁断、系统细化来处理。 那是很互补的关系，当然其处理方法也不太一样。 其中有两块预计将面临功能安全，一个场景是未知的不安，这应该是比较黑色的部分。 另一件事是我知道不安全。 第一，相对于这两个行业，将其范围更缩小。 这是期待安全的第一个方向。

其处理方案包括提高电子电器的可靠性。 从技术角度提高识别、决策和控制系统的性能。 这些可以通过感知来提高，例如通过ota来提高。 也有提高hmi安全机构的设计以降低误用概率。 基于场景的模拟测试和数据采集的回流测试等，一个是探索未知的不安全部分，其实前期不太容易预测，可以通过后面发现和改进来弥补。 通过了大型超高行驶距离随机场景测试。

新闻安全首先是通过互联网进行的攻击，要防止它，或者说在受到攻击之后如何使它处于安全的状态呢？ 我先去防御。 另一方面，如果有突破，至少在自动驾驶阶段不会发生人身伤害。

二、安全设计在工程开发中的应用

第一，结合功能安全、期望的功能安全、新闻安全的相关标准，形成整车开发的安全设计流程。 整车e/e体系结构决定了ICV的安全性。 根据初步框架进行各项安全分解和安全机制设计、功能优化和框架强化的多任务循环，最终形成实现安全的e/e框架。

在e/e体系结构中，对于功能安全的设计，e/e体系结构是如何体现的？ 例如，基于自动驾驶场景的分解、功能定义时，进行功能安全分解、sotif分解、功能安全目标定义，论证新体系结构的功能安全实施导入方案。 其中包括传感器冗余、主干网冗余、计算冗余、运行冗余、双电源环供电冗余的必要性和相应的电源分配。

在新闻安全方面，根据新型结构拓扑和功能分配，进行敏感源和危害分解，定义整车级、重要功能、场景的新闻安全诉求，论证其安全方案，分解整车和诉求定义，在系统设计层面展开威胁分解，进行风险判断，从设计角度提出诉求，中央计算 具体来看，第一是在五层结构的基础上推进。

目前大家熟知的功能安全和期望的功能安全，具体到这个过程中，第一个结合点就是功能安全解体的时候，首先从功能安全的引入引出第一个功能定义，然后有可能站在期望的功能安全的立场上对其能力和功能提出诉求。 比如，感知那些方面吗？ 性能要求是什么？ 他会出现什么样的缺陷？ 进行这些解体后，根据上述主要功能形成裁断或修订的方案。 我们可能在更换感知系统，或者提高性能。 可能会稍微缩小odd，以优化整个系统。 最后，回到功能安全拆解的链接，从功能安全目标的角度进行下一个ee架构设计诉求的输入。

例如，关于lca这一功能，分为转向转矩的要求、转向转矩的撤回、和向驾驶员的交接这三个主要功能。 右边被提示期待功能安全解体的立场。 例如，车道探测、障碍物探测的诉求、道路边界的探测、驾驶员的交接能力、车道变更的诉求、转向输入的探测、轨迹计算的明确化(从决定的立场)，之后是转矩的执行。 通过期待功能的安全拆解，m部将提高功能的安全性，形成最终的三个主要功能的定义，并根据主要功能进行一点补充和改进。

三、安全性测试和验证

其实关于智能辅助驾驶，除了部分技术要求和技术标准外，对于准入至今仍是空小白。 l2可能比以前近一点，但人在车内也是主体，责任也在人，所以相对会弱一点。 但是，自动驾驶有很多指导性和政策法规。 像联合国一样，与自动驾驶进行比较，提出了多支柱法。 三大支柱是道路测试、场地测试、仿真测试，测试认证后可以批量生产。 在这里分为典型的顾客场景、危险场景、极限场景、认证场景，

工业和信息化部几个月前发布了《ICV生产公司及产品准入管理指南(试行)》。 这里对模拟、封闭道路、实际道路、软件升级、ota、数据存储测试提出了一点要求。 我们现在实践还不多，但现在对自动驾驶来说，能封闭道路的事件并不多。 第一是两者。 另一方面，面向adas，首先以前流传的c-ncap评价和安全指数测试实际上基本上是安全的性能测试，不能说是安全性的测试。 自动驾驶或无人驾驶封闭道路的测试，首先是拿着车牌在上路的车封闭的地方进行测试。 现在大家都在做，但是还没有确定的指导方针。 只是，对地方有几个要求。 关于如何评价，每个地方都有每个地方的评价方法，目前体系还不成立。

封闭场试验除了基本的性能试验外，还有典型的危险场面试验，对于预想的功能安全性，可以在一些已知的不安全的情况下在场内进行模拟。 功能安全措施可以通过实车进行验证。 特点是可以量化，可以重复，容易评价。 因为那个场景无论是否插入随机场景，都在一定范围内。 它可以为准入许可的发放提供依据，但问题是场景少、多、复杂度低，在报考方法上实际上是可以通过的。 将来，特别是在自动化日益发展的情况下，比较网站测试的有效性也可能是点到点，并不是非常重要的依据。

众所周知，道路适应性测试在无人驾驶时测量到的公里数很多，但实际上在adas测试中这一部分也非常重要，aeb功能也是一辆车量产前几千小时的测试。

目前，adas分为高行驶距离和低行驶距离，模拟普通客户的测试，高行驶距离将在未来汽车驾驶的范围内进行。 低行驶距离是针对已知的典型环境反复进行高强度的测量。 例如，这个环境有很多井盖，高度有限。 这些对aeb的威胁比较大。 它可以选择这个链接和几个点不断测量，也可以在与周边典型场景上午下午不同的时间进行测试。 虽然这个里程数不高，但其问题，例如已知的不安全是非常有效的。 要验证那个是否会发生吗？ 对策比较有效吗？ 通常，要模拟客户的测试，最重要的是预测预期的功能安全中未知的不安全部分。

验证目标包括hui涵盖道路状况、交通状况和各种情况，这个复盖率是我们测试的重要考虑因素之一。 也包括了驾驶员的习性、误用的可能性。

的泗公路场景随机性高，重现性低，价格相对较高。 意外行为的发现效率，一开始会出现很多问题，我觉得很有效，但是越往后，发现效率越低。 那么，应该什么时候结束？ 因为这也很难评价，只能说是那种程度，但是要引路，或者从复盖率的角度加一点系数。 例如，公司本身通过拆解来定义在被测道路上往返行驶4次、7次，有时根据整个开发周期来进行一些限制。 如果跑不完，车上市后也会继续跑，有时跑得比顾客还快。 这样也可以弥补一点。

另一个问题是边缘场景实际上不容易验证，这部分稍后通过模拟进行。 另一个问题是高速公路上测试的合法性。 从adas开始，我们一直在路上跑。 大家都有责任。 工程师很辛苦。 必须进行安全相关的测试。

右边是一条路线驶下来，高速、城际、城市中的例子。 另外，一个链接高速，到l2+和l3其实是高速场景，包括将来odd高速跑在内，那么在高速这个区间应该跑多少，也是根据我们的覆盖度要求设计的。 我跑多远的路段，什么时候跑？

通过实际车辆对道路关闭的验证，实际上验证数量有限。 由于包括限价、安全性限制，未来无论是adas还是高级自动驾驶，特别是高级自动驾驶模拟比例越来越高，95%以上在模拟上进行。 仿真一定要从诉求定义开始。 例如，如果分解功能安全和期待的功能安全等，则范围包括控制要求和其他要求。 在此基础上，选一点场景吧。 因为功能不同，场景也不同。 数据收集，数据融合，提取，标记，分解，最后构建这个场景。 基于该场景进行了很多模拟，

在仿真中，分为功能场景、逻辑场景、具体场景，分别适用于系统概念阶段、系统开发阶段和系统测试阶段，抽象度依次减少，场景数依次增加。 参考iso3450x、sae自动驾驶水平的定义，以及pegasus额度和asam组织对场景的定义，通过实际交通数据的解决，定义相应逻辑场景的参数空之间，参数重组后，有场景比较之嫌

在v模型前阶段的设计过程中，通过模型进行验证。 模型在环上，软件在环上。 我很久以前就在做hil了。 以前就有传说车上的hil比较有效，但ICV以后，实际上就集中在一个单元测试上了。 整车的hil测试变得困难。 因为我必须在台架上模拟感知，模拟动态系统，还有交通和旁边的影响，所以hil vil还不成熟，还在讨论中，但是它可用的场景不多，验证效率不高，所以个人认为未来 那就勾结整车，组件测试。

四、问题与思考

从安全的角度设计和验证都是我们考虑的问题。 因为安全永远达不到100%，如何让它更安全，更安全地被接受呢？

1、安全设计从e/e架构开始，受架构约束。 由于目前经常进行功能升级，因此在功能升级过程中，此时需要重新评估安全性。 因为你的体系结构本来就设计好了，所以如果设计当初不考虑ota功能，就有可能出现安全问题。 因此，在ota升级过程中，这也是未来ICV面临的问题，首先e/e体系结构有前途，需要在此过程中重新审视。 升级时必须慎重。

2、怎么做才足够安全？ 不仅是超低速无人驾驶，如果有交接的话现在也不安全。 需要保安人员。 如果没有交接会产生什么危害？ 一个没关系。 一个可能是大事故。 如果不明确分解的话，这个不能每3万公里按一次。 5万公里可以不接管人而拆除。 我觉得这个理论不太正确。

3、无人驾驶系统的结构不同。 真正的无人驾驶和以人为本是完全不同的。 驾驶辅助可以参考以前流传下来的做法，期待功能安全、功能安全实际上可以作为参考。 但是，一旦变成无人驾驶，就无法控制了。 那么，这个基准制定之初，对象不同，需要对其进行改善、调整、扩展，才能采用新的基准。 目前的标准体系远远不能支持更高级的自动驾驶车辆准入，它们还没有形成一种支持。

4、安全性开发范围的延长。 既然是ICV，车就是其中的一个节点。 例如，简单的信号现在没有安全要求。 我们的车有功能安全要求，就像信号灯也在我的系统链路中，在功能链路中一样，所以对于v2x道路的设施，也必须提出其控制器安全要求。 他必须达到符合我要求的水平，才能说我们的系统是安全的。 目前空不足。 没有提到这个。 后面的无人驾驶系统的安全可能无法保证。

这是我想和大家今后讨论的部分。 谢谢你。