7月1日—2日，由盖世汽车主办的“2021第四届全球自动驾驶论坛” 于上海隆重召开。本次论坛主要聚焦自动驾驶关键技术，如自动驾驶感知、智能驾驶域控制器、芯片、计算平台、无人驾驶不同的落地场景等话题展开讨论，以促进自动驾驶相关技术进一步发展、完善。下面是北京汽车股份有限公司智能网联中心专业总师 陈音在本次大会上的发言。
大家好，我是来自北汽股份有限公司的陈音，今天很感谢盖世邀请我来这边跟大家分享我们在智能网联汽车开发过程当中整车安全设计的实践。演讲分四个方面：1、智能网联汽车安全概念。2、安全设计在工程化开发中的应用。3、安全性测试和验证。4、问题与思考。
一、智能网联汽车安全概念
这是汽车工程学会给的概念，涵盖的内容跟传统汽车比起来多了很多，不光是汽车本身，尤其是下一阶段在车路协同的智能网联汽车情况下，高级自动驾驶安全不仅仅要考虑车本身的安全，可能还要把范围扩大到道路、交通、云控系统。我们的车自己做安全了，但对将来无人车来说还是远远不够。
我们首先把安全分几个阶段：基本安全、功能安全、预期功能安全、信息安全。其实在AI导入以后不确定的东西也一起带进来，我们的感知系统，决策系统，相关的环境都是有很多不确定性。在整体安全考量当中，除了基本安全，像信息安全、功能安全、预期功能安全都会影响到E/E架构的设计。然而E/E架构设计是整车开发的开始，整个生命周期里面架构是不能变的，所以E/E架构决定了安全性的框架，也就是我们的天花板。我的车如果设计的E/E架构是这个样子，将来OTA能成什么样？功能能够升级到什么程度？其实已经受到了一定的限制。在智能网联汽车新的概念下，我们会在信息安全，功能安全，预期功能安全上面做更多的设计和考量。
基本安全，我更愿意把它叫做安全功能的本身。因为传统安全概念里面，根据事故发生时间的先后分为几个阶段，这几个阶段是基于传统车有海因里希的模型，这里有先期安全、主动安全、主被动融合、被动安全、事故救援等等，这些对智能网联汽车来说是很基础的。
作为功能安全，避免因电气电子系统故障而导致的不合理风险，主要通过安全概念中定义的安全机制解决。其实功能安全概念还是比较有意思，大家知道安全是相对的，没有绝对安全。
功能安全，比如说同样的功能今天做设计的时候和三年以后做设计的时候，其实它的要求会有变化。因为大家对安全的理解，包括接受程度都会有变化。
预期功能安全，主要是避免因为预期性能表现局限或者误用而导致不合理的风险，它强调的是非故障原因造成的危害，通过ODD、功能裁剪和系统修改解决。它是很互补的关系，当然它的解决方法也不太一样。这里面有两块是预期功能安全要面对的，一个场景就是未知的不安全的，这个应该是比较黑的部分。还有一个是已知不安全的，主要是对这两个领域，让它的范围变得更小，这是做预期安全主要的方向。
它的解决方案包括电子电器可靠性提升。从技术角度提升识别、决策、控制系统的性能。这些可以通过感知提升，比如说通过OTA是可以提升的。还有提升HMI安全机制设计降低误用概率。基于场景的仿真测试和数据采集回灌测试等，一个是探索未知不安全的部分，其实前期是很难预测的，可以通过后面去发现再去改善弥补。还有通过大规模超高里程随机的场景测试。
信息安全主要是通过网络手段的攻击，要防止它，或者受到攻击以后如何达到安全的状态？首先我要去防御，另一方面一旦有攻破，至少在自动驾驶阶段不产生人身伤害。
二、安全设计在工程化开发中的应用
这个主要是结合功能安全、预期功能安全、信息安全的相关标准，形成整车开发的安全设计流程。整车E/E架构决定了智能网联汽车的安全性。基于初步架构进行各项安全分析和安全机制设计、功能优化和架构修改的多任务循环，最终形成实现安全的E/E架构。
在E/E架构里面对功能安全的设计，E/E架构怎么体现？比如说基于自动驾驶场景分析、功能定义情况下，会进行功能安全分析和SOTIF分析，功能安全目标定义，论证新型架构功能安全实施部署方案。这里包括传感器冗余，骨干环网冗余，计算冗余，执行冗余，双电源环形供电冗余的必要性及相应的电源分配。
在信息安全方面，基于新型架构拓扑和功能分配，进行敏感源和危害分析，定义整车级、关键功能、场景的信息安全需求，论证它的安全方案，分析出整车和需求定义，在系统设计层级开展威胁分析，风险评估，从设计角度提出需求，在中央计算平台和环形新型EE架构部署上面寻求安全解决方案。具体来看主要是按照五层结构进行推进。
现在大家比较熟悉的功能安全和预期功能安全，具体的在这个过程当中，主要结合点是在功能安全分析的时候，首先从功能安全导入引出主要的功能定义，同时在预期功能安全角度可能对它的能力和功能需求，比如说感知哪些方面？它的性能要求是什么样的？他会出现什么样的缺陷？这些进行分析以后，从上面主要功能基础上去形成裁剪或者修改的方案。有可能我们是把感知系统换掉或者性能提升，有可能ODD缩小一些，整个系统进行优化。最后还是会返回到功能安全分析的链路上面去，从功能安全目标的角度去做下一步EE架构设计需求的输入。
比如，对于LCA这个功能，我们分出三个主功能，一个是转向扭矩的请求，一个是撤回转向扭矩，一个是请求驾驶员接管。右边是预期功能安全分析角度会提出来，比如说车道线探测，障碍物探测的需求，道路边界的探测，驾驶员接管能力，换道需求，转向输入的探测，轨迹计算确定（从决策角度），后面是扭矩的执行，通过对预期功能安全分析以后，M部分就是对功能安全的修改，形成最终的三大主要功能的定义，根据主要的功能会做一些补充和改善。
三、安全性测试和验证
其实对于智能辅助驾驶除了有些技术要求和技术标准以外，对准入现在还是挺空白的。L2可能跟传统更加接近一些，因为人在车内还是主体，责任也在人，所以相对来说会稍微弱化一点。但是在自动驾驶这块有很多指导性和政策法规。像联合国针对自动驾驶提出了多支柱法。三支柱就是道路测试，场地测试，仿真测试，测试认证以后可以进行量产。这里分为典型用户场景、危险场景、极限场景、认证场景，
工信部前几个月发布了《智能网联汽车生产企业及产品准入管理指南（试行）》，这里面对仿真，封闭道路，实际道路，软件升级，OTA，数据存储测试都提出了一些要求。我们现在实践还不是很多，现在对于自动驾驶来说封闭道路可以做得事情并不是很多。主要是两方面，一方面面向ADAS主要是传统的C-NCAP测评和安全指数测试，其实还是处于基本安全的性能测试，还不能算是安全性的测试。对于自动驾驶或者无人驾驶封闭道路测试主要是对要上路拿牌照的车在封闭场地做测试。目前大家都在做，但还没有一个明确的指南，只是对场地有些要求。对于怎么评价，各个地方有各个地方的评价方法，现在体系都没有成立起来。
封闭场地测试除了基本性能测试，还有典型危险场景测试，对预期功能安全来说，有些已知不安全的场景可以在场地里进行模拟测试。功能安全措施可以经过实车进行验证。它的优势是可以量化，可以重复，容易做评价，因为它的场景不管有没有随机场景插入，仍然是在一定的范围内，它可以为准入牌照发放提供依据，但问题是场景少，复杂度低，用应试的方式其实都是可以通过的。未来尤其在自动化程度越来越高的情况下，场地测试有效性也可能是点到为止，不能作为很重要的依据。
道路适应性测试，大家知道比较多的是无人驾驶的时候有很高的公里数一直在测，其实ADAS测试当中这部分也很重要，AEB功能在每辆车量产之前也是数千小时的测试。
现在ADAS会分为高里程和低里程，模拟一般用户的测试，高里程会在将来车要开的范围进行。低里程是对已知典型环境重复高强度测，比如说这个环境有很多井盖，有限高，这些对AEB来说是威胁比较大的，那可以在这个路段或者选几个点不停地去测，或者在周边典型较场景上午下午不同的时间去做测试，这个里程数不会很高，但是找它的问题，比如说已知不安全是非常有效的，去验证它会不会发生？措施是不是有效？模拟一般用户测试，主要还是应对在预期功能安全里面预测未知不安全的部分。
在验证目标里面hui覆盖道路状况，交通情况，各种各样的情况都会包含进去，这个覆盖率是我们测试比较重要的一个考量的因素。同时还包括驾驶员习惯，可能的误用。
问题shi开放道路的场景随机性强，可重复性低，成本相对很高。非预期行为的发现效率，一开始会出现很多问题，觉得很有效，但是越往后面开，发现效率越来越低，那么什么时候应该结束？这也是挺难判断的，只能说到那个程度就划一条道，或者从覆盖率角度加一些系数，比如对被测道路跑4个回，7个来回，企业自己根据分析来定义，，有时候也是根据整个开发周期有些限制，有些跑不完会在车上市以后继续跑，比用户跑的更快，这样也可以去做一些弥补。
还有一个问题是边缘场景其实是很难验证的，这部分后面还要用仿真来做。再一个问题，就是高速公路上的测试合法性，从ADAS开始，我们一直是上路跑，大家都是担着责任，工程师很不容易，要去做安全相关的测试。
右边是一些例子，比如一条路线跑下来，有高速的，有城际的，有城市里面的。又比如说一个路段都是高速，到L2+或者L3其实都是高速场景，包括将来ODD在高速上，那在高速这一段应该跑多少，这也是根据我们覆盖度要求去设计，我要跑多少路段，什么时候跑。
实车封闭道路验证，其实我们验证的数量是很有限的，因为成本限制，包括安全性的限制，将来不管是ADAS，还是高级自动驾驶，尤其高级自动驾驶仿真比率越来越高，在95%以上都会在仿真上做。仿真肯定要从需求定义去入手。比如说功能安全和预期功能安全等等分析来说有一个范围，包括控制的要求，其他要求的基础上，我们来选择一些场景。因为不同功能，场景是不一样的。包括数据采集，数据融合，提取，标注，分析，最后构筑这个场景。在这个场景基础上做很多仿真分析，
在仿真里面，分为功能场景，逻辑场景，具体场景分别应用于系统概念阶段及系统开发阶段和系统测试阶段，其抽象程度依次递减，场景数量依次递增。参考ISO3450X、SAE关于自动驾驶等级定义，以及Pegasus额及ASAM组织对场景的定义苟延功能场景，并通过对真实交通数据的处理，定义相应的逻辑场景的参数空间，在参数重组后，经过场景有效性评价得出具体场景。
在V模型前期设计过程当中，通过模型去做验证，包括模型在环，软件在环，我很早以前就做HIL，在传统车上面HIL有效性还是很强的，但是在智能网联汽车以后，其实会集中在一个单体测试上面，因为对整车HIL测试变得难，因为我在台架上又要模拟感知，又要模拟动态系统，还有交通和旁边的影响，所以HIL做起来会非常庞大，它的构建会非常难，所以HIL现在主要用在系统和组件测试上面。VIL现在还不太成熟，大家还在讨论，它可用场景不会很多，验证效率不会很高，所以我个人认为主要精力将来还是要放在MIL测试上面，它会贯穿到整车，组件测试当中。
四、问题与思考
从安全的角度去设计也好，验证也好，这是我们思考的问题，因为安全永远达不到100%，那么我们怎么样让它更加安全或者让大家觉得更加安全可以接受。
1、安全设计从E/E架构开始、受架构约束。因为现在功能升级频繁，在功能升级过程当中，这个时候必须重新评价安全性，因为你的架构是原来设计好的，设计之初如果OTA功能没有被考虑的话，有可能会产生安全的问题，所以我们在OTA升级的时候，这也是我们将来智能网联汽车面临的问题，首先E/E架构要有前瞻性，另外在这个过程当中一定要重新审视它，升级的时候一定要谨慎。
2、怎样才算足够安全？除了超低速无人驾驶，只要有接管现在还是不够安全，安全员还是必要的，如果不接管会产生怎样的危害？一种是没事儿，一种可能是很大的事故，如果没有分析清楚，这个是不能按3万公里，5万公里没有接管人就可以撤下来，我觉得这个理论不太对。
3、无人驾驶系统架构不同。真正的无人驾驶和以人作为主体是完全不一样的。驾驶辅助是可以借鉴传统的方法，功能安全，预期功能安全其实都是可以借鉴的。但是真正到了无人驾驶，是不可控，那么这个标准制定当初面向的对象就不一样，需要一个新的标准改善它做调整扩展才能使用。在现在标准体系下还不能远远支撑更高级别自动驾驶的车辆准入，这些还没有形成一个支撑。
4、安全性开发范围的延伸。既然是智能网联汽车，车是其中一个节点，比如一个简单的红绿灯现在是没有安全要求的，既然我们车有一个功能安全的要求，像信号灯也在我系统链路里面，功能链路里面，那么对于V2X路边的设施，它的控制器安全要求也要提出来，他要实现跟我要求相匹配的等级，才能说我们这个系统是安全的。这块目前还是比较空缺，这块不提出来，后面无人驾驶系统安全可能是不能保证的。
这是我希望跟大家以后探讨的部分，谢谢。
