汽车智能化带来的安全新挑战及其应对思路


从汽车安全带说起


安全带作为汽车发生碰撞过程中保护驾乘人员的基本防护装置,保护了数以百万计的人的生命。在今天看来,安全带是汽车上再基础不过的必需配置,即使再入门级的车型也会标配安全带,这毫无争议,然而你能想象吗:在六七十年前,很多汽车企业还会在成本与安全的平衡中,将安全带拿掉或者是作为选装。


随着沃尔沃改进了三点式安全带,并在1967年在美国的一次交通安全会议上提交了《28000起交通事故报告》,这份报告引来了广泛的关注。因为,报告表明,安全带不但能挽救生命,还降低了50-60%的受伤几率。


自此之后,美国汽车安全技术法规(FMVSS)才将安全带列为“机动车强制安装配置”,要求从1968年开始,轿车面向前方的座位必须配备安全带。欧洲和日本等发达国家也相继制定了一系列规定将安全带列为强制配置项。中国于1993年,要求小车前排强制使用安全带,2003年10月28日,《中华人民共和国道路交通安全法》颁布,不系安全带违法扣分。


总结


可以看到,安全带标配在汽车上经历了三个标志性阶段,争议→技术天花板(三点式安全带改进)→法规强制。


再说到C-NCAP


NCAP(New Car Assessment Program)新车评价程序,主要用于在正面碰撞中评价汽车保护车内乘员的性能,其对于促进汽车OEM提高车辆被动安全性功不可没。


它起源于美国,在诞生之初曾经被各大汽车OEM"恨之入骨",因为几乎所有的车都很难得到3星以上的评价,更别提5星碰撞安全了。后来,陆续其他国家和地区也开始借鉴,在全球的NCAP机构中,EuroNCAP影响力较大。它在欧洲深受消费者欢迎,并拥有广泛群众基础和非常高的公信力。


我国于2006年正式启动了C-NCAP项目,随着汽车碰撞的星级评价被人们列为购车选车的一项重要的安全性指标参考,汽车OEM开始越来越重视C-NCAP的安全评级,17年后的今天,C-NCAP已建立起成熟的测评体系,如今5星碰撞安全被汽车OEM作为一个重要的安全亮点和卖点来宣传。


这足见其对推动安全意识深入到中国汽车企业骨髓的影响。如今,汽车碰撞安全设计体现在各车型的设计平台之中,体现在车辆安全配置不断增加的趋势之中,体现在逐渐被遏制的汽车交通伤害数字之中,更体现在从厂家到消费者的态度和行动之中。


3月30日,中汽中心在其碰撞实验室完成了第20000次碰撞,从1999年的第一次碰撞,到第20000次碰撞,在一次次乒呤乓啷的巨响中,中国汽车的被动安全水平得以巨大的提升。


总结


C-NCAP 的发展也经历了几个标志性阶段:OEM的抗拒→被动应对→主动追求。


智能汽车安全


 如今,汽车的主被动安全已经取得了极大的进步,无论是安全技术的实践应用、以及安全检测技术的提升,两者相互促进共同推动着汽车主被动安全的趋向于完善,然而汽车在走向智能化/电动化的过程中却面临了更大的安全挑战。


传统的分布式EE架构(以控制器为单位,将功能、软件、硬件相互强绑定在一起),已经无法应对汽车智能化需求:功能和软件快速迭代。然而其在系统安全上却有着天然的优势,如同一个个分兵而治的诸侯(我的底盘我做主),封闭性让功能控制的复杂度相对低,且安全相关的控制器,一般由实力强大的Tier1来主导开发,Tier1在细分的专项领域有深厚的安全Know-how积累(正是依赖着安全的实现难度形成自己的护城河),即便如此,在功能迭代和产品变更上,仍近乎于苛刻,即通过尽量不变的方式来维持长期以来打磨好的”安全“。


 智能汽车的安全挑战


挑战1:域控架构/集成式EE架构的复杂度

功能安全开发所有的开发活动中,都要求尽最大可能降低功能和系统的复杂度,复杂度的上升,对于安全实现的难度而言,是指数级上升的。然而域控架构和集中式EE架构的复杂度是天然的。原来一个功能相对简单的ASILD控制器的功能安全实现已经相当困难了,域控架构的安全实现难度可想而知。

挑战2:整车安全功能和系统的"耦合"

相对于原来相互没有任何交集的驱动、制动、转向控制系统,如今因为电动化将制动(涉及到传统制动与能量回收制动分配)与驱动控制耦合成一个更复杂的功能系统;因为自动&辅助驾驶将整车所有的横纵向控制全部耦合成一个最复杂的大系统(自动驾驶可控制转向,制动,驱动等所有安全强相关的功能系统),原来独立、封闭和解耦的安全相关的控制系统完全被打开,这对于功能安全的影响来说是颠覆性的。

挑战3:OEM自研安全Know-how

传统开发模式下,功能安全更多是由Tier1来实践的,OEM更多的是做最上层的安全需求以及最后端的整车集成验证,如今OEM自研模式下,需要独立的挑起“功能安全大梁”,这需要Know-how的积累。

挑战4:“变”是安全的天敌

功能/系统安全的实现需要非常繁复和仔细的论证,一旦论证OK,在稳定的沿用的基础上,做逐步的优化是最好的选择,安全设计有时候不是一蹴而就的,需要逐步在分析、测试验证以及运行中不断的打磨。而来自于“非优化或完善维度”的变更,有时候对已有的安全策略和方案是颠覆,影响分析和论证需要重新进行,然而在如今功能/软件变更频率如此高的背景下,一个完整的安全论证几乎是不可能完成,在安全论证不充分的情况下,将变更引入的同时也引入了风险。

挑战5:自动驾驶功能的复杂

功能安全主要是解决由于系统的失效(系统性失效和硬件随机失效)带来的安全风险,在自动驾驶功能引入之前,汽车上电子系统安全挑战主要是来自于这种失效引起的,自动驾驶功能引入后,除了上面提到了带来了系统复杂度的安全挑战(功能安全)外,又引入了另一个:预期功能安全。


预期动能安全主要是解决由于系统性能局限和人的误用带来的安全风险,简单来说就是系统即使没有失效(完全做到了功能安全),仍然不能规避这类安全风险。比如摄像头在没有任何功能安全失效的情况下,仍然有可能因为误识别而做出危险的决策控制,比如“非预期的刹车”、“非预期的没有刹车”,以及“非预期的转向”等。

挑战6:不仅“内忧”还有“外患”

功能安全和预期功能安全,都是在解决系统内部的安全,可谓“内忧”。除了这些,还有来自于系统外部的安全风险,那就是网络安全(信息安全)


网络安全主要是解决系统由于受到主动、刻意的攻击而面临的安全风险,可谓“外患”。


功能封闭=百毒不侵:分布式EE架构,安全相关的系统完全封闭,不接受任何来自外部的控制,与网络物理隔绝,即完全不给机会入侵,相对安全。


如今,功能需要带来了开放,整车制动、转向、驱动都需要开放其控制对上游的自动驾驶控制,汽车上有了大脑能够对汽车所有的安全系统展开控制,这打通了安全控制的链路,大大增加了安全入侵面,而且整车连入了互联网,将安全控制系统暴漏在入侵的威胁中,除此之外,整车OTA功能的引入,也给“不安全软件”或“非法”软件刷入到车上带来了机会。


总结


对于智能汽车而言,功能安全、预期功能安全、网络安全环环相扣,只有三个维度都做到才能保证安全,缺失任何一个都会使得其他两个维度所做的努力功亏一篑(水桶效应)。然而现实是,别说三个都做到,做到其中任何一个,都面临巨大的挑战,同时做到的难度更是难以想象。


如何应对挑战?


 从安全带和C-NCAP案例中得到的启示,安全水平的提升需要两个维度的努力:


1. 来自于安全技术的突破


功能安全里有一个很关键的概念:功能安全是降低安全风险而非“0”化风险,使之达到”风险可接受”。


这里很多人都会觉得功能安全有点“玄学”,什么是风险可接受?如何度量?


要理解这里的“风险可接受”,需要理解另一个词“State of the art", 简单来说就是”标杆技术“。安全的技术水平不是一条静态的线,而是在行业的不断努力下,随着时间的推移持续向上移动的准绳,如同安全带,在六七十年前不作为标配就是”风险可接受“,而现在则是“完全不能接受”。


这里想表达的是,行业内的企业主动的、自发的在安全技术的探索和提升,是应对安全挑战的最佳选择。


这些技术上的探索,会在逐步成熟的过程中,形成“标杆技术”、“技术天花板”,一旦“标杆技术”被认可为行业共识和安全的最佳实践,就会逐步通过法规约束和检测技术列为强制要求项。


智能汽车的安全经验,并不像其他的安全技术,可以很容易显性化的复制。


就像当前很多功能安全巨头供应商,其功能安全经验并不会被公之于众,而是作为自己的技术护城河,将来的OEM安全的探索和技术积累同样,安全技术的Know-how越多越深入,就越会在激烈的竞争中脱颖而出。


说白了,安全技术,是可以为降本提供依据和思路的,不做功能/系统安全分析,既无法清楚的看到自己安全的短板,做补足而降低安全风险,也无法看到在某些局部做了过安全设计却没有提升整体的安全水平(无用设计)


2. 检测技术规范和法规约束


智能汽车安全,对于法规约束和检测技术规范,也带来了巨大的挑战。


不同于传统的安全检测,很多的安全可以相对显性化的测试和检测,而智能汽车安全,无论是功能安全、预期功能安全、网络安全都极其困难。


于是,行业内在检测方法、安全监管上也需要采用更加创新的方式,当前我们也已经看到了一些方向的探索和实践:


①欧洲的实施经验参考

功能安全在全世界范围内,以欧洲实施和落地的最为深入和成熟。虽未法规强制,但几乎欧洲的所有汽车上下游企业都作为实际强制来实践的。


这是因为欧洲采用了“宽进窄出”的要求,即企业需要对安全负责,产品一旦出现安全问题,会回溯到开发中是否遵循了功能安全的开发。


②国内:检测+安全evidence审查并举

如上描述,单纯的依赖检测来保证智能汽车安全几乎是无法做到的,功能安全、预期功能安全、网络安全的水平只有每个企业自身了解,因此需要辅以企业的安全声明和对自身安全的信心。


GB17675针对功能安全的符合性采用”抽查+审查“的机制,审查企业的“功能安全总结文档”,这就意味着企业需要对功能安全承诺(这要求企业有信心声明达到了功能安全),同时保留了对企业详细安全文档的审查要求,即出了安全问题,仍然会回溯到企业的功能安全开发是否完整来定责。这有些参考了欧洲的思路。


③汽车安全沙盒监管:

所谓的汽车安全沙盒监管,是在后市场阶段针对车辆应用的前沿技术进行深度安全测试的机制,主要目的是引导企业查找问题、改进设计、降低风险。作为传统监管方式的有益补充,汽车安全沙盒监管变被动监管为主动监管,有利于更早地将前沿技术引发的质量安全问题纳入监管范围,提高应急处置能力,防范和化解重大风险,保护消费者合法权益,同时有利于鼓励企业技术创新,倡导最佳安全设计实践。


沙盒监管作为传统监管方式的有益补充,是一种针对技术创新的柔性监管制度,实际上是为企业提供一个测试平台和测试周期,在不违反原则性准入标准和监管底线的基础上,鼓励企业在不完全掌握产品风险时,自愿开展进一步测试,最大限度地防范产品应用风险。同时,改善监管应对风险的实时性、灵活性,防止监管过严对科技创新的抑制,较好地平衡技术创新和安全风险,积极倡导最佳安全实践,为推动我国汽车产业繁荣健康、安全有序发展提供了新的监管思路。该制度起源于英国,目前美国、德国、日本等20多个国家和地区正在金融、汽车、能源等领域积极推进实施。


推行沙盒监管的目的,是以更安全的方式去鼓励创新,并达到不断优化监管模式的效果,有效防止“一管就死,一放就乱”的管理困局,在保护与监管之间找到最佳的结合点。


在我国汽车安全领域引入沙盒监管,鼓励企业在一定时间范围内对已经应用在上市车辆上的前沿技术进行深入安全测试,在一定程度上填补标准滞后带来的监管缺失,有利于监管部门更早地将前沿技术引发的质量安全问题纳入监管范围,更好地保障产品安全底线。参与试点的企业,要主动履行质量安全责任,接受监管部门的管理监督、跟踪评估和质量服务。双方共同努力,查找产品安全问题,改进产品设计、制造,降低产品安全风险。


总结:沙盒监管是在被动监管的基础之上,对于产品应用的新技术,随着技术水平的不断提高,监管线动态趋严的过程,这正是功能安全state of the art基于当前技术水平对安全可接受水平进行动态适配的最佳诠释。


文章来源sasetech

整车研发汽车安全汽车智能化

汽车智能化带来的安全新挑战及其应对思路的评论4条

汽车智能化带来的安全新挑战及其应对思路的相关案例教程

随着软件定义汽车的持续走热,各OEM车企开始建立自己的研发创新中心,关注在软件,人工智能,等创新研发。近在眼前的案例是,上汽集团成立上汽创新开发总院。独立研发中心的建立,从组织授权和资金上给予了充分的保障。但是,这样做就万事大吉了吗?我想,答案肯定是“No” 之前的系列文章,我们描述了什么是SDV,澄清了SDV的历史渊源以及对SDV的一些误解,并提出了软件驱动汽车的概念 (如何正确理解SDV,感兴
来源 | 中国汽车论坛 中国汽车工业协会主办的第11届中国汽车论坛举办的主题论坛“共创软件定义汽车新生态”上,举办了以“安全、产业协同、软件能力建设问题”为主题的圆桌对话。以下内容为现场对话实录: 主持人: 清华大学汽车产业与技术战略研究院院长 赵福全 对话嘉宾: 华为智能汽车解决方案BUCTO 蔡建永 长安汽车软件科技公司总经理 张杰 小鹏汽车嵌入式高级总监 余鹏 主持人(赵福全):刚刚几位嘉宾
1. 概述 TIA Portal为程序块提供 KNOW_HOW_PROTECT 保护功能。如果没有使用正确密码打开使用此保护功能的块时,仅块接口参数 Input、Output、 InOut 、Static 和块注释可见,而无法显示接口参数Temp、Constant、程序代码和网段注释。此时被保护的程序块也不能被修改。若使用正确的密码打开程序块时,可以显示所有的接口参数、注释和程序代码。此时被保护的
随着汽车智能化的迅速发展,各大车企也开始尝试重视芯片研发,从而使自动驾驶技术迎来了发展的契机。目前,市面上的大部分电动车也都已经具备了一定水平的自动驾驶功能。但绝大部分汽车的自动驾驶水平虽然还处在L1-L2级,属于辅助驾驶阶段,很难实现真正意义上的L3-L4级高阶驾驶。而自动驾驶出行服务,已经进入商业化试点阶段,距离L3-L4级别自动驾驶大规模商业化的终点越来越近。 高通入局, 自动驾驶芯片有望加
来源 | 无人车情报局 一、电子电气架构的正向开发流程 国外的OEM在多年的Know-how积累下,其在规划新一代电子电气架构平台时,基本完全按照正向的流程来开发,例如VW的MEB E3架构,Volvo的SPA2等,伴随其正向电子电气架构开发的需要,诞生了强大的工具供应商,比如Vector的PREEvision,其囊括了电子电气开发的整个流程,从需求分析、逻辑功能架构、软件架构、硬件架构到电气原理
影响力
粉丝
内容
获赞
收藏
    项目客服
    培训客服
    4 0