首页 > 汽车技术 > 正文

自动驾驶汽车中E/E架构开发的要求

2021-04-01 23:04:44·  来源:汽车ECU开发  
 
对于开发下一代自动驾驶汽车的工程师来说,确认全新E/E架构的需求是一项艰巨的挑战。当今车辆的日益复杂化已是一种被广泛认同的趋势,车辆互联、自动驾驶等功能
对于开发下一代自动驾驶汽车的工程师来说,确认全新E/E架构的需求是一项艰巨的挑战。

当今车辆的日益复杂化已是一种被广泛认同的趋势,车辆互联、自动驾驶等功能也逐渐在落地,且强大、更复杂功能也正在路上。

在整车上,所有这些功能要发挥作用,都需要依赖线束和电子组件。对于OEM和系统集成商来说,成本和时间压力都会显著的增加,因为这些公司需要现代化的解决方案来应对日益增加的车辆复杂性和产品开发时间压缩的压力。

这个过程中一个关键的挑战是顶层车辆模型的E/E需求分解。顶层的多域建模涵盖很多领域,包括机械、E/E、软件、热学和其他领域,对于电子电气架构工程师而言,其需要从此模型中提取E/E方面信息,用来驱动E/E架构的构建以及下游的进一步细化分解。在整个过程中,与现代E/E架构的定义、设计和交付有关的各个工程师必须平衡许多相互依赖的需求。下面从网络拓扑、功能安全、网络安全、处理器,网络和网关负载、组件和软件重用几方面来聊一聊相互依赖的要求和设计技术。

网络拓扑

在这个过程中,大多数工程师的任务通常集中在对功能分配和拓扑优化上,例如:在以域为中心的网络中,确认ECU所需包含的功能,ECU在所处的位置,以及对外的总线连接。
在最近的几年中,从中央网络或多总线体系架构到功能域控制器体系架构的过渡相对容易,该体系架构下将功能进行整合到少量的ECU中,如图1所示。下一个阶段将需要将ECU进行重新组织为更为通用的计算单元,其中将集中更多更复杂的功能。区域ECU根据车辆的物理布局将其余功能组合在一起。实施这些区域性ECU通常需要对软件和供应商的交互进行较大的更改。
自动驾驶汽车中E E架构开发的要求
图1 E/E架构类型

功能安全

在E/E体系结构定义过程中,功能安全需求产生了多种考虑因素。具体考虑因素因功能而异,但行业目前已采用ISO 26262作为功能安全标准。ISO 26262将功能分QM或ASIL,从A级至D级。ASIL功能在发生完全失效的情况下,具有一定的破坏汽车功能安全性的可能性。ASIL A功能风险最小,ASIL D最显著。

整个系统的功能安全性可以通过几种方式实现。承载车辆功能的硬件和软件平台指定开发到特定的ASIL等级,以满足功能安全。另一种方法是向系统添加冗余部件。与其增强一个传感器系统以支持ASIL D功能,不如使用两个ASIL B传感器将传感器数据传递给ASIL D功能,这可能是更可取的选择,另外也越来越需要考虑故障功能行为,特别是在更高级别的ADAS功能(Level 3+)中,这种行为需要更广泛的系统级别的考虑,例如围绕电源网络,通信,处理,传感器的更多层面冗余,这些额外的冗余层可能包括技术冗余,例如图2所示的实现高级ADAS功能的各种传感器的重叠式冗余。

自动驾驶汽车中E E架构开发的要求1
图2 ADAS的重叠式冗余传感器

网络安全

虽然功能安全已经涉及到系统的可靠性,但网络安全必须考虑到针对车辆系统的恶意攻击。现代车辆有多个潜在的弱点,这些弱点被称为攻击面,集成Wi-Fi、蜂窝网络、蓝牙、车载诊断(OBD)、USB和其他连接点都提供了进入车辆通信系统的潜在路径。甚至网络总线电路也被作为入口点访问。在设计防盗系统时需要考虑攻击面,以及不法分子在物理上访问某些系统,而其他系统则可以使用额外的软件身份验证检查来防止未经授权的访问。

网络安全是通过分层的方法实现的,在架构的关键点重复使用各种机制。承载特定功能的ECU可能需要集成硬件安全模块(HSM)。虽然可以在软件中模拟HSM,但是这需要额外的芯片资源,当前基于硬件的安全措施越来越普遍。与网络安全相关的数据也可以被设计为特殊保护,为整个网络安全系统增加更多的层次。

处理器,网络和网关负载

另一个重要的体系结构考虑因素是每个ECU处理器,网络或网络分支以及网络之间的网关上的相对负载。在将功能分配给特定的ECU时,它们的关联信号给连接到ECU的网络增加了额外的负担。如果信号的各个源和目的地之间不存在直接连接,则需要网关进行连接。这样会导致网关的发送信号的负载和频率增加,以传递给定的时序数据。在面向功能的域体系结构中,状态和模式信息信号的路由可能需要穿越网络主干。网络之间的交叉链接是不受欢迎的,因为网络安全功能使防御变得困难。

一个能够研究多种分配以预测每个分配结果的设计工具可以节省大量时间。对于ECU的功能分配,考虑每个ECU的特定处理类型是至关重要的(图3)。每个域的主要处理ECU有不同的特征。当在更新期间将功能添加到架构中时,它们必须被分割并适当地分配给对应的ECU。

自动驾驶汽车中E E架构开发的要求2
图3 每个功能域的典型ECU处理类型

对于实时性要求非常高的数据交互,必须在一个小的时间窗口内执行,这个过程通常被安排在一个高频的触发事件中,例如发送机曲柄角度等。

典型的车身功能,如降低窗口,可以在几十毫秒内响应,这样都可以给用户一个满意的用户体验。然而,某些功能可能会引入ASIL和硬实时性要求。具有防夹功能(如果检测到儿童的手臂则自动关闭窗户),窗户的功能操作包括与安全相关的功能。必须考虑在具有足够ASIL等级和定时自动窗口功能。通常,车身功能高度分布,使用围绕机舱放置的传感器和执行器来建立复杂的舒适性和便利性。

软件和组件重用

车辆特性、功能和系统的可重用性现在是至关重要的。电气和电子架构优化和有效的系统设计对于最大化可重用性、减少车辆变种数量以及提高按时交付正确车辆的能力至关重要。
当开发新的或更新的车辆时,围绕车辆内容的重用存在约束。有些约束是坚定的,而其他约束则需要相对于相关成本进行评估。传统上,除非供应商已签约开发此类功能,否则一级供应商的ECU具有有限的功能添加范围。OEM需要在开发ECU策略甚至完整软件方面承担了更多责任。如今,这已扩展到用于战略模块和设计芯片的硬件。
一旦架构师确定了可以分配功能的位置,就需要考虑ECU类型、安装的软件及其来源。理想情况下,当OEM决定哪些ECU在体系架构的生命周期内的功能分配时,就需要考虑这些因素。

结论

OEM开发E / E系统面临的挑战众多,种类繁多且复杂性不断增加。E / E系统架构师在开发,更新和优化车辆架构时会考虑无数的注意事项。因此,有必要使用高级工具,以根据工程师定义的一组规则和准则来计划和检查体系结构。借助可扩展的规则,系统架构师可以根据定义的规则自动执行分配,以便在详细设计工作开始之前尽早优化E / E体系结构。 
分享到:
 
反对 0 举报 0 收藏 0 评论 0
沪ICP备11026917号-25