在之前整理的笔记中提到，当下汽车中几十乃至上百为了实现不同功能的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_CentralizingComputeSoftware3.重要度(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都集中到一个盒子之后，会否走上分布式计算的路子将一切都搬到“云”上呢？拭目以待吧。
最前沿的电子设计资讯
