法雷奥胡波平:汽车电子功能安全设计

  • 车云菌
  • 发表于: 2018/11/19 15:03:00 来源:车云网

正是因为自动驾驶在车载领域丰富了很多原来没有的功能,催生了功能安全的需求。

编者按:11月14-16日,由工业和信息化部、应急管理部、科学技术部、广东省人民政府指导举办的“2018中国安全产业大会”在广东佛山举行。车云主办“安全出行主题论坛暨第二届交通安全产业峰会”,峰会以"安全出行"为主题,"专业论坛+创新展"联动,打通汽车、交通、电子、通信等多个行业,探讨最具前瞻性和可行性的安全出行模式与生态,强势推动跨界融合与协同发展,全面提升大会关注度及影响力。

论坛期间,法雷奥主动安全产品线研发经理胡波平发表了以《汽车电子功能安全设计》为主题的演讲,胡总从事雷达系统产品开发和研究,参与多项国家重大专项技术攻关,2014年9月进入法雷奥集团,任全球电子电气开发中心技术主管,次年任主动安全产品线研发部经理,车载传感器,自动驾驶系统,功能安全,MBD等领域全球专家。

15433023274791.jpg


以下是胡总的演讲全文:

非常感谢有这个机会在这里交流,主动安全和功能安全的议题。

法雷奥是一个传统的一级供应商,跟刚才诸位讲的纯信息安全有所不同,我们的信息安全方向主要是基于ADAS和自动驾驶,我们的信息来源于传感器,给车企提供传感、探测、控制相关的各式各样的ECU。

我们今天主要是涉及几个方面。

  • 为什么我们在这个时间点提功能安全。

  • 现在都有哪些人参与功能安全。

  • 法雷奥在这方面的地位是什么样。

  • 谈一下基于ECU的设计,怎么样达成功能安全的各种要求。

其实我们可以看到,有两个行业自己在不断的演进,一个是汽车,汽车工业本身一代一代往前走,还有一个行业就是计算机,可谓是蓬勃发展,两个行业发展到现在出现了一个交点,这个交点可以看到就是“自动驾驶”。

正是因为自动驾驶在车载领域丰富了很多原来没有的功能,催生了功能安全的需求。

我们看到国内外主流的车企大多数都有自己的在自动驾驶或者ADAS方面的规划,甚至有一些车企付诸实践,特斯拉、奔驰、宝马都取得了一些建树。

法雷奥作为一家供应商主要给这些车企提供ECU,包括各式各样的传感器,对于自动驾驶来讲,信息来源就是这些传感器。它们是否正常工作直接决定了自动驾驶车辆是否可以得到可靠的道路信息。

这是我们的雷达,在国内现在暂时没有大规模的商用,这是下一代马上在国内推出的,前置摄像头,还有激光雷达是全球第一款在车上量产的激光雷达。如果是L3以上的自动驾驶,激光雷达不可缺少的,我们的Scala在奥迪A8奥迪A6标配,现在奥迪能够做到L3。

我们可以看到这是激光雷达对于路面情况探测的一个展示,可以非常好的探测到路面非常细微的目标,得到这样级别的探测才有可能谈到L3以上。

同时还有提供算力,可用作域控的融合ECU。正是通过各种传感器对我们的真实世界进行一个探测和感知我们才有L3甚至更高等级的自动驾驶,目前的整个业态主要的生态还是集中L2。L3各大车厂在试探,L4运营的比较少,但是我们有参与。

整个的自动驾驶涉及了很多的方面,像AI,像环境的一个感知和建模,各式各样的技术都非常的关键,但是中间我们认为最关键的还是功能安全。这里写的功能安全是简写,关于这方面是整个不管是整车还是ECU,能否正确的工作,取决于功能安全的能力。

其实我们在谈安全,事实上我们提车辆的安全,是由三个方面进行保障的,排第一的当然是功能的安全,功能安全更多的是解决你的传感器或者ECU是否正常工作,如果是你的ECU不正常工作,就谈不上功能,这是基础。

第二,其实我们叫“预期功能安全”这方面的标准在制定当中,预期功能安全是非常重要的,更加注重在ECU或者功能在正常工作时,由于系统限制导致没有办法完全的保证安全,这种情况怎么办,这是预期功能的范畴,刚才讲很多的如果车机被劫持有可能有涉及到预期功能安全。

第三,才是我们刚才讲的信息安全。他们之间的关系是,一般来讲信息安全产生的问题基本上都会涉及到功能安全或者是预期功能安全,如果你的车机或者你相应的控制器被劫持,原本的功能不再存在或者你的功能不再完整了,这个时候就不符合功能安全的要求了,还有一些是我的车机还可以正常的工作,提供的内容不是原来的内容,属于预期功能安全范畴。

功能安全和预期功能安全尤其功能安全的问题,不见得会对信息安全造成影响,如果整个ECU不工作,不存在信息的问题,整个的功能没有了,就是去了基础,这是他们三者之间的一个关系。

我们在这里着重的看一下功能安全。现在国际上比较通用的规范是ISO26262,她是一个建议的标准不是强制,里面很多的像一些指导性的一些图表或者是指导性的一些流程强烈推荐,不会说必须要这样做,而落实到真正的开发活动当中,强烈推荐是要求必须要做的。

其实,怎样得到功能安全,包括可能有一些后装做车机的厂商,不是一级供应商他们不明白,ECU装到车上必须要符合一定的功能安全等级,车企也越来越多的强调这方面的要求。怎么符合功能安全,怎么得到功能安全。这张图有一个大体的概念,整个有10个部分组成,真正跟我们运营相关的是中间,第三、第四、第五、第六,第七部分,跟研发和设计相关的主要集中在第四、第五、第六。

第四部分主要讲的系统设计。

第五部分讲的是硬件设计。

第六是软件设计。

四五六组合起来,非常像汽车行业讲的“ASPICE”理念的非常相近,只是这里多出了第五关于硬件的设计。总体来讲,不管是软件还是硬件设计都是在系统设计的下游。怎样得到功能安全?

第一,车厂会根据零部件的功能给我们设定一个系统安全目标。比如我的AEB就是不能撞到人,基于这个目标根据ISO26262,可以得到功能评级,有了这个目标,有了这个等级,会产生一个TSR的等级,这边有三种TSR(Technique Safety Request),有了系统的TSR结合前面的表“4.6”系统TSR,可以进入到4.7系统设计,系统设计会分发给软件和硬件,根据4.7的要求,会进入5.6硬件TSR或者6.6,6.6是软件的TSR的产生过程,软件硬件的TSR必须完全的覆盖上游系统设计。

在ISO26262有5点几,六点几,有哪些活动是强烈推荐要做,有哪些是推荐的,文档中都有详细的说明。如果没有做到就不能符合功能安全要求,如果所有的步骤都按照他的规定来做了,并且产生了报告,同时跟上下游之间有追溯关系,这样可以说在这一章节符合了ISO26262的要求,当你全流程做了以后,基于你的报告和上下游的一个分析,我们会说,我符合了ASIL B或者C的要求,车厂或者是业界根据这套方法做的一个评估。

当然根据ISO26262的要求,不管硬件还是软件有以下的要求。

第一,一定要模块化、结构化。

第二,尽可能多的复用。

第三,对软件来讲一定要做到高内聚、低耦合。

第四,所有的开发工作都可以追溯。

还有很重要的一点就是建立上下游之间的互相覆盖关系。

我们看到现在的车辆越来越成为大家生活当中密不可分的一个大手机或者一个大玩具,集成的很多,对ECU的设计提出了越来越高的要求。现在到了一亿行代码级的软件开发量。这么庞大的软件开发怎么测试是一个很大的问题,如果按照原来的静态测试算MCDC,这是一个难以完成的事,维护起来更加困难。

我们现在传感器还有各式各样的ECU的种类越来越多,我们的硬件接口越来越的多,变得越来越难复用,带来了很大的挑战。

假设我们同样是车机或者是一些云,或者是同样是雷达,换了一家供应商性能可能就不一样了,对上层软件可能之前写好的算法可能要进行改变了。

针对我们的结构化、模块化提出了更高的要求。这都是问题,我们可以看一下怎么解,这是我们一些推荐的方法。

首先,可以采用AutoSar框架,AutoSar是通用的软件开发框架,可以更多的复用我们之前开发好的模块。推荐采用基于模型的开发方法,代码全部都是用模型生成的,也许一个模型生成很多行的代码。最后只需要改模型的逻辑,这样代码量再大对模型来讲,变化可能不是很大。还有一个是采用自顶向下的开发组织方式,能有效的控制我们的开发量。最后可以采用敏捷开发,多迭代几次,不要把所有的事放到一起,这样可以大幅降低开发的复杂度,从而保证功能安全。以上是我们给大家的一些建议。

这是今天的内容,谢谢大家。

相关标签:
2018中国安全产业大会
  • 车云星
  • 空间站
  • 福特星球
  • 虫洞

加料 /

人评论 | 人参与 登录
查看更多评论