提高性能和降低电力汽车

汽车oem厂商提高其投资在半导体生态系统向电气化和自治作为垫脚石,他们开始遇到一些相同的问题芯片制造商一直在绞尽脑汁高级节点——大规模的计算性能,热和权力问题,延长寿命,可靠性和高度多样化的地理上分布的供应链。

这只是开始。每个组件在汽车设计需要综合,构架,最终的上下文中建模和制造一个复杂和不断变化的系统系统。自主车辆被形容为超级计算机或车轮上的数据中心,但这仅仅是一块需要安全开车,自主驱动,汽车在未来。

“超级计算机,如果你认为我们有这些大房间,一切看起来是一样的,“基督教柏查说,汽车微控制器平台架构的高级主管英飞凌科技在小组讨论在DAC。“我们这里(汽车)是一个非常异构超级计算机。我们有非常不同的功能。我们有不同的时间,根据不同的安全根据不同的可靠性。虽然听起来简单,最后很复杂,这是“分而治之”的结果。如果我们只是谈论电动驱动函数,系统需求相比是完全不同的自主驾驶的方向。所以当我们习惯于听到这些话,我们必须更具体。汽车将会是智能手机。汽车将会是一个车轮上的数据中心。这是一个聚合的不同的技术。”

这种聚合影响车辆系统作为一个整体。工作负载可能非常不同的辅助驾驶和自动驾驶。“每一个车辆连接pb的数据一天八个小时,开车时“说尼玛倒Nejatian,全球解决方案架构和工程主管在英伟达汽车。“想想吧。你必须处理这些海量数据。你能做你的笔记本电脑吗?如果你叫一个笔记本电脑,而不是一台超级计算机,这是不可能的。上面的图形处理内容,以及其他应用信息娱乐和处理演讲。这些许多应用程序需求计算、网络和存储。”

至此,NVIDIA去年推出了其驱动雷神SoC,容量为2次,加上引擎处理ChatGPT-like工作负载的谈话。相比之下,一个典型的高端笔记本电脑的能力以吉拍。

“当你考虑车辆10年或15年前,这是能干些什么相比,我们的车辆能够做什么今天是压倒性的,即使只是平行停车协助,”朱迪·柯伦说,首席技术专家、汽车有限元分析软件。“如果你试图教你的16岁如何并行的公园,这是一个简单的事情现在ADAS三级相比,在那里你可以带一些你的注意力的道路和车辆驱动器。ADAS我们已经走了很长的路,我们已经走了很长的路作为一个行业在整个信息娱乐系统,关于沟通你可以做当你在车里。所有这些需要计算能力和软件功能。”

在汽车HBM吗?
随着计算能力和软件需要高速、低延迟的记忆,特别是人工智能/毫升的车辆。生产线主管布雷特默多克内存接口IP解决方案Synopsys对此说,汽车和HBM真正意味着对彼此,尽管一长串的问题仍然需要得到解决。

“热的挑战是一个立即出现,以及确保插入器的机械挑战在汽车环境中可以处理机械压力,”默多克说。“这些事情都是可以解决的。然后它也取决于你使用的HBM,什么样的宽容你可能有错误,和其他问题可能会上升暖气流的结果。如果你使用它只是为了娱乐,没什么大不了的。如果你的发动机控制器的一部分,现在你有一个不同的安全级别,你需要注意。”

不过,默多克承认,汽车制造商希望HBM。“没有真正的秘密,因为带宽在汽车环境只是爆炸,”他说。“如果我们看看相机的数量,和图像处理需要发生在无人驾驶车辆,试图满足LPDDR5x,今天是实际内存使用在汽车环境中,是一个非常大的挑战。渠道所需的数量是巨大的,所以HBM绝对是汽车制造商想要使用的东西,它只是一个时间问题,直到他们开始实际使用。也许有人需要它,做了风险评估,认为他们可以承担一些后果或可以减轻的一些问题,以换取他们会走出HBM受益。年底我一点都不会感到惊奇,如果这十年我们驾着汽车HBM设备的一些关键安全系统。”

然而,为了实现这一目标,需要下来,成本和可靠性的需求上升。“不仅过于昂贵,这也是TSV可靠性,”弗兰克说,铁产品营销高级总监Rambus。“有公司踢的想法是否可以使用HBM因为大型人工智能系统的车,你需要大量的带宽。我知道在这个领域所做的工作,但我不认为它很快。现在,GDDR和LPDDR从带宽的角度达到的平衡力量和性能在车里,我没有看到,很快停止。LPDDR产业方面做得很好支持汽车可靠性要求。同样,在SoC方面,流程节点也是做汽车。LPDDR5 5 x,最终LPDDR6,变得越来越快,接近10 gb。”

铁指出GDDR汽车,将添加另一个选择,一旦解决了汽车可靠性要求。“这些都是不错的甜蜜点,”他说。“记忆的主要领域必须能够交易发生的人工智能推理。它是一个人还是一个路牌?然后,你有音频/娱乐系统。信息娱乐,与LPDDR甚至GDDR没问题,但专门为ADAS GDDR速度似乎是必要的。当然,汽车工业想更多的内存,但是他们好了。”

计算、内存和软件都适合的伞下车辆结构,发展也包括自主驾驶的传感器融合。副总裁戴维·弗里茨hybrid-physical和虚拟系统,汽车和mil-aero西门子数字行业软件说有三个主要方法看看传感器融合的挑战。

”一个来自多个传感的方法是把原始数据来源在处理之前,”弗里茨说。”虽然这种方法可以减少功耗,坏数据从一个传感器阵列会污染其他传感器的数据,导致糟糕的结果。此外,大量的原始数据的传播带来了其他挑战与带宽,延迟和系统成本。第二种方法是对象融合,每个传感器过程数据和代表其sensor-specific处理的检测结果作为一个解释。这无缝地集成结果从机载传感器的优势,基础设施传感器和其他车辆。这个方法是一个普遍的挑战表示和标签的对象可以跨不同的车辆和基础设施共享。”

第三种选择,弗里茨发现的最有说服力的权力,带宽和成本的角度来看,是一个混合的两种方法。“在这种方法中,对象是由传感器检测到的自己,而不是分类。在这种情况下,对象的点云被传输到机载中央计算系统(标签)点云分类从不同传感器,内部和外部。这会显著减少带宽和延迟需求,保持和负载传感器成本低,并允许车辆解释或分类的对象以任何方式等,从而消除需要一个通用分类标准”。

直到他们解决在一个方法中,oem厂商将这些系统逐步增长,他说。“他们会继续添加ecu一些,然后说,“我们认为我们仍然可以出售三级五年因为我们想踢,可以。”你可以看到广告在电视上,他们加大说(三级)是一种神奇的东西,和真的是一样的lane-keeping我们五年前,但他们认为这是一个新奇才爆炸的事情所以他们推迟。我没有看到很多人要认真解决。人们问,“当我们要自驾车辆吗?“我告诉他们无论他们听到,它的两倍。你认为这是五年?这是至少10。不要等到它,去买一辆车如果你需要它,因为它不会在一夜之间改变,大大。”

不过,有不断变化的生态系统。“oem厂商,包括创业,EV-based oem看垂直整合和驱动整个系统架构,”维迪雅Rajagopalan还说,负责工程的副总裁在Rivian硬件。“他们不看着它从不同层的一定购买组件,但想想一张干净的纸,他们的建筑看起来,这真的让一切。我们谈论软件定义车辆,但那是不可能的,如果你还没有真正建立建筑地面clean-sheet-of-paper架构。”

另一个变化是,oem厂商参与整个设计过程比过去。

“它不再是他们发送一个询价表,并期望层提出正确的解决方案,”Ramakrishnan Aravind说,合作和创新的西海岸主管Vitesco技术。“这是一个合作方式从第一天,甚至一级oem厂商和芯片供应商携手发展中正确的解决方案,无论是垂直整合或外包产品。我们注意到,从OEM的角度来看。我们也看到oem厂商不只是与层的协作,但也一直到芯片供应商。oem厂商告诉我们,他们希望我们使用这个芯片供应商和一个从供应链的角度来看,在这方面的弹性。也是效率,因为,例如,电力电子与更好的效率,改善范围,改善性能。这些都是非常战略一个电动汽车OEM想到位与另一个。”

此外,oem厂商在技术解决方案要求更多的可伸缩性,转化为额外的机会。“在某些产品,我们提供,我们传统的oem厂商向我们走来说,例如,“我们想让你融入e-drives提供一分之三的解决方案,”“Ramakrishnan说。“其他oem只想购买逆变器和电子驱动并不真的在乎。他们有不同的策略在供应链方面,或者他们将它。我们需要灵活的提供一个单独的逆变器和电源模块。一些厂商说,“我们不希望你给我们一个逆变器。我们可以照顾的集成,但我们真正感兴趣的进入逆变电源模块。所以这种灵活性在业务模型的方法无疑是在过去几年的前沿。”

其他引用类似经历。说:“有两个极端发展模式英飞凌的柏查。“新一,大家谈判和合作。然而,因为我们是在过渡,我们仍有一些地区经典瀑布,我说的一级。一级ECU的知识,然后到半导体,每个人都有当地的生态系统更小的软件/硬件公司。仍然存在,它很难的过渡阶段。你如何管理呢?我们的旧世界,需要服务。但是我们如何适应新的模型?这是超出纯技术挑战。”

一个领域,将有助于模型基于行业标准的发展,它可以帮助转变的一些设计工作的流程,除了使软件定义的车辆。从供应商的角度来看,需要得到尽可能多的重用的设计。

“如果我能得到这个模型前,与oem厂商分享它,然后是系统开发早期的一部分,它提供了我们一个机会,并得到反馈如何使该组件共同跨多个oem,“Ansys的柯伦说。“在虚拟环境是改变的一部分的关键。”

兰迪鱼、导演、产品线管理,硬件在Synopsys对此分析和测试,同意了。“作为我们与数据中心的比较——每个人都喜欢,指的是数据中心,在车内的一件事,我们都忘了是在数据中心,人们或多或少去software-wise Linux和一个共同的平台。所以软件定义的车辆和面向服务的体系结构正在讨论现在,仍然不是一个常见的软件栈,即使真的有很多吸引人的和有趣的委员会或试图成为驱动的标准。但如果oem和层的,或者任何需要巩固,我认为没有人真正有兴趣成为赢家与一个或另一个。和有一个共同的平台整个行业将使软件开发的加速度。”

结论
在一天结束的时候,要真正实现电气化的承诺,软件定义车辆和自治需要接近整个车辆的开发从一个更高层次的抽象来处理复杂性。

部门主管Roland Jancke设计方法弗劳恩霍夫IIS的自适应系统分部工程说,这可能太复杂的处理。“但你需要关注你提出的问题,web系统或一个模型,然后,把你的注意力放在哪里,你需要的详细级别,和其他组件需要在更抽象的层面上,只是为了符合这一特定部分,你想看看。”

模型将会有所帮助,但前提是足够可靠的模型。“我们怎么能相信这些模型吗?”Jancke问道。“这是重要的自主驾驶的下一个级别。他们说需要100万公里的道路上。但是他们不能让他们都在路上,所以,只有10%是在路上,这意味着90%是虚拟。我们怎么信任这些模型和调查的结果如果只有虚拟呢?”

如果行业能够模块化和标准化,然后设计模型可以负担的分布在很多不同的球员。

“这些接口是不同层次的标准化的方式连接在一起,或不同的模型一起,“Jancke补充道。“这是一种形式化的方法和规范,这是一个好主意,以使这些模型转化为不同的水平。如果我有一个行为模型的电机,和我交换一个有限元模型,因为我想研究力学的行为,我可以交换在正确的时间和在相同的接口。标准化是不同供应商之间的交流总是关键。”