广告

智能汽车集中式计算的考量

2022-09-07 汽车电子与软件 阅读:
在之前整理的笔记中提到,当下汽车中几十乃至上百为了实现不同功能的ECU将会趋向集中,减少成几个甚至一个集中式的计算单元。那么,在这条集中式计算的路上,有哪些关键的考量呢,个人翻译了《Centralizing Compute: How Far Can It Go?(集中式计算能走多远?)》一文,主要涵盖以下6个因素。
在之前整理的笔记中提到,当下汽车中几十乃至上百为了实现不同功能的ECU将会趋向集中,减少成几个甚至一个集中式的计算单元。那么,在这条集中式计算的路上,有哪些关键的考量呢,个人翻译了《Centralizing Compute: How Far Can It Go?(集中式计算能走多远?)》一文,主要涵盖以下6个因素:
  • 时间线(Timelines)
  • 可伸缩性(Scalability)
  • 重要度(Criticality)
  • 冗余(Redundancy)
  • 空间(Space)
  • 处理能力和发热(Processing power and heat)
在ASPICE的SYS.3系统架构设计和SWE.2软件架构设计中,都提到了根据特定评估准则评估备选的系统架构的要求,CMMI更是专门出了一个DAR过程域(决策与分析)来描述这类活动。一般的方法都是选定参数、确定权重、打分比较的三步走,而这都需要专业领域的知识,在集中式计算的考量这个话题中,如果能形成量化参数进行设计评估,可以生成类似如下的雷达图——
文章如下:
集中式计算能走多远?
随着消费者对汽车智能功能的需求日益增长,为每一项功能创建专用ECU(电子控制单元)的做法显然是不可持续的。它会带来太多的复杂性和成本,消耗太多的能量,增加太多的重量,最重要的是,占用太多的物理空间。
因此,OEM厂商正在尽可能地将软件定义的功能升级到集中计算中——这就引出了一个问题:实际上,升级集成能走多远?如果我们按照这种趋势推断,我们是否会看到一辆所有计算功能都在一个盒子里处理的汽车?
虽然向上整合将继续,但至少有6个关键因素会限制在某个点之后的整合。汽车设计师必须优化他们的架构,以便他们在考虑这些问题的同时最大限度地减少所需的盒子数量。
设计的因素
每个车型的最优上集成量是不同的。主机厂在主动安全性能、舒适性和便利性功能、整体车辆设计和消费者价格目标方面有着不同的目标。因此,每辆汽车的电气/电子架构都面临着与包装、电源管理、成本和其他因素相关的独特挑战。换句话说,“优化”对于每个OEM和每个平台都有不同的含义。
然而,在从基础模型到高级选项的所有功能级别上,当涉及到将功能升级到集中式计算时,设计师必须权衡某些常见标准。
1. 时间线(Timelines)
首先要考虑的是不同功能的更新时间线,它们的时间表可能非常不同。
例如,OEM可能希望定期更新车辆的用户体验软件或高级驾驶辅助系统(ADAS)。开发人员可以创建新的应用程序,为消费者提供不同的体验,或者改进现有的软件,以做出更好的驾驶决策。他们可以根据需要随时通过空中向车辆推送这些更新。
相比之下,有很多软件定义的功能在五年或更长时间内不太可能发生太大变化。最典型的例子是电源和身体控制器,它管理内部和外部灯光、窗户控制和门锁、气候控制、警示灯和整体电力分配。
在Aptiv的智能车辆架构™方法中,那些缓慢变化或不变的功能由中央车辆控制器(CVC)处理。更新更频繁的软件位于开放服务器平台(OSP)中。这种分离也使得每隔几年升级一次OSP硬件本身成为可能,因为更强大的处理器出现了,提供更接近今天智能手机提供的消费者体验。
此外,CVC被设计为非常快速地启动,并使用基本的信号来让基本系统尽快运行——例如,打开门,启动引擎和激活后摄像头——而OSP可能需要更长的时间来完全启动更复杂的代码,并使用汽车以太网与其他系统通信。
2.可伸缩性(Scalability)
第二个需要考虑的问题是,一个OEM在多大程度上希望扩展一个特定的汽车平台。也就是说,如果OEM计划在所有车辆(从入门级到高级)上使用相同的基本平台,那么它可能会选择在增加功能的同时简单地添加ECU,以创建更多高级车型。
类似地,OEM可能需要支持遗留体系结构一段时间,而该设计决策将影响组件升级集成决策的时间。
逻辑和物理分开
开放服务器平台(OSP)和中央车辆控制器(CVC)中的软件都可以通过无线方式进行更新。不同的是,OSP中的高级软件发展得更快,而CVC中的软件处理的功能是随着时间的推移而固化的,不太可能经常改变。
图片来源:https://www.aptiv.com/docs/default-source/white-papers/2022_aptiv_whitepaper_centralizingcomputesoftware.pdf?sfvrsn=b0c21238_3/2022_Aptiv_WhitePaper_CentralizingComputeSoftware
3.重要度(Criticality)
第三个考虑因素是所支持的功能的重要度。不同的系统有不同的功能安全要求,将这些系统组合到相同的硬件上可能会导致效率低下。
例如,电子稳定程序(ESP)控制防抱死刹车、牵引力控制和其他功能,帮助车辆保持在道路上安全行驶。因此,ESP的安全性至关重要,ESP控制器必须通过ASIL-D组件的功能安全性验证。如果ESP要升级到一个盒子上,同时控制车辆的音频系统,那么音频的每次小更新都需要整个盒子按照ASIL-D系统的严格要求重新验证。同样的逻辑也适用于任何非常关键的安全系统,比如安全气囊控制器。
在未来,虚拟化技术可以从逻辑上将一个芯片上的系统(SoC)分离成虚拟机,为不同的功能提供各自的保护空间,以防止它们相互干扰。软件容器允许应用程序或应用程序片段独立更新。
Aptiv正在开发中间件来支持这些技术,并为设计人员的软件驻留提供更大的灵活性。
4.冗余(Redundancy)
第四个考虑因素是冗余的需要。随着自动驾驶功能变得越来越普遍,车辆中有更多的安全关键系统,因为更多的系统直接参与决定车辆行驶的位置和速度。每个组件都应该有一个备份,以便在发生故障时能够接管。
这并不是说一辆车的每个部件都应该有两个。也就是说,车辆不需要在同一个区域有两个区域控制器,或者两个CVC或两个OSP。但是,这确实意味着要安装一些额外的连接。
例如,一个前左区域控制器可以支持至少一个前右区域的传感器,反之亦然。这样的话,如果区域控制器出现故障,车辆在那个角落也不会完全失明。集中计算
以类似的方式,CVC和OSP可以相互备份。例如,如果OSP出现问题,CVC可以关闭非必要功能,如音频和舒适功能,并使用其处理器处理OSP的其他功能,以确保车辆处于安全状态。
新兴技术正在帮助促进这种方法。soc开始包括一个“安全岛”,这是一个主要支持ASIL-B的芯片上支持ASIL-D的部分。这种配置允许设计人员将算法分发到两个ASIL-B soc上,然后在ASIL-D部分使用一个监督算法来交叉检查和监控来自这两个soc的结果。如果其中一个SoC显示出故障迹象,ASIL-D部分可以确保将关键功能安全切换到其他SoC。要在设计中广泛采用这项技术还需要几年的时间,但未来应该有机会仔细地进行升级集成。
5.空间(Space)
第五个考虑因素是空间。虽然将功能整合到更少的盒子中在某些情况下可以节省空间,但在其他情况下可能会造成麻烦。
例如,高级车型的车门可以包含多达30个功能,包括自动门锁、车窗、后视镜、传感器等。如果控制这些设备的计算机是真正集中的,那将意味着为这些设备布线——通信线、电源线和地线——穿过门的护套,进入主机箱到中央计算机。布线的数量根本没有意义;它增加了成本,同时增加了电线断裂的风险。
相反,每扇门都应该有一个门控制器,可以为门上的传感器和执行器供电,同时处理与每个设备的通信。这种方法只需要从主体到门控制器的5根电线——用于电源和接地,以及信号传输和接收,还有一根单独的电线用于安全气囊控制模块。
另一个例子是座椅控制器。许多车辆会有一个或两个座位,有12路或14路位置控制,以及座椅加热、通风和按摩功能。同样,把一束粗电线布线到一个可以移动的座椅上是不切实际的。最好是在座椅内部安装一个座椅控制器,以最少的电线馈送它。
第三个例子是屋顶。A柱内的空间非常有限,特别是如果它已经包含了安全气囊,所以将多根电线连接到屋顶来管理天窗、阅读灯和其他设备可能会很棘手。
6.处理能力和发热(Processing power and heat)
设计的第六个考虑因素是单个处理器的特性。很难将一辆汽车的所有计算能力整合到一个芯片上的一个原因是,今天的处理器根本不够强大,无法以这种方式运行整辆汽车。单是ADAS的OEM需求就在快速增长——速度太快了,硅的发展无法赶上。
此外,最强大的硅会产生大量的热量。车辆必须在包括高环境温度在内的恶劣环境中行驶,这意味着消除这些热量可能是一项重大的工程挑战。液冷是昂贵的,并需要空间的软管。使用风扇进行主动空气冷却会产生噪音,而且随着时间的推移,它们可能会损坏。
如果可能的话,使用多个处理器要容易得多,因为每个处理器产生的热量要比一个功能更强大的处理器少,并为它们开发简单的被动冷却解决方案,比如散热器。
可能的配置
考虑到这些因素,我们可以得到盒子的最佳数量,从12到19:
•2-4门控制器
•2座控制器
•1台屋顶控制器
•1个ESP模块
•1个气囊控制器
•1个动力总成和底盘控制器(PCC)
•1 CVC
•1-2个OSPs或ADAS控制器
•2-6个zone控制器
区域控制器的数量取决于车辆中传感器和执行器的数量。一款基础车型可能只有两个区域控制器——一个在前面,一个在后面——而一辆完全自动驾驶的汽车可能有六个区域控制器,以适当地支持车上所有的雷达、摄像头和激光雷达。此外,电动汽车可能需要额外的、单独的ECU,用于高压组件,如DC-DC转换器、逆变器、车载充电器和电池管理系统。然而,近期的大多数配置将包括三个区域控制器——两个在前面,一个在后面。
有进一步整合的机会。入门级车辆可以通过将CVC功能、用户体验和ADAS集成到一个设备中来降低成本,但这只能支持2级自动驾驶,因为这可能是一个单点故障,需要人类驾驶员作为备份。或者,PCC也可以向上集成到CVC中。
尽管存在一些限制因素,但一辆汽车上只有18个或更少的ECU,与当今一些汽车上的100个或更多ECU相比,是一个很大的差距。将功能升级集成到域控制器中,并采用区域架构,这将为整车厂朝着下一代架构(如Aptiv的智能车辆架构™方法)迈出第一步提供良好的服务。整车厂可以利用Aptiv在车辆大脑和神经系统方面的独特专业知识,确保他们能够根据车辆的独特需求实现最佳设计。
成功的基石
未来的汽车将在可能的情况下集中计算,同时保持其所需的安全性和健壮性,以支持一系列先进的驾驶能力,以及卓越的舒适性和便利性。
高度自动化的车辆可能包括以下控制器:
图片来源:https://www.aptiv.com/docs/default-source/white-papers/2022_aptiv_whitepaper_centralizingcomputesoftware.pdf?sfvrsn=b0c21238_3/2022_Aptiv_WhitePaper_CentralizingComputeSoftware
所谓“天下大势,分久必合,合久必分”,若是未来集中式计算的路程走完,所有的ECU都集中到一个盒子之后,会否走上分布式计算的路子将一切都搬到“云”上呢?拭目以待吧。
责编:Admin
文章来源及版权属于汽车电子与软件,EDN电子技术设计仅作转载分享,对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。如有疑问,请联系Demi.xia@aspencore.com
汽车电子与软件
汽车电子与软件
  • 微信扫一扫
    一键转发
  • 最前沿的电子设计资讯
    请关注“电子技术设计微信公众号”
广告
热门推荐
广告
广告
EE直播间
在线研讨会
广告
广告
面包芯语
广告
向右滑动:上一篇 向左滑动:下一篇 我知道了