|
汽车行业正面临其历史上最重大的转变之一。新的商业模式承诺在整个车辆生命周期中带来额外的收入。消费者越来越期望他们的汽车能够融入他们的数字、私人和职业生活中。对于制造商来说，有许多新的机会可以在竞争中脱颖而出，然而，尤其对于已经建立起来的企业来说，利用这些机会是一个挑战。 摘要 当前的电子电气架构(E/E architectures)在可更新性(Updateability)、可定制性(Customizability)和互联性(Connectivity)方面并不具备扩展性。随着速度变得至关重要，它们的设计、基础开发方法和工具都存在重大限制。这阻碍了软件为中心的技术平台的引入。为了成功实现软件定义汽车(SDV Software Defined Vehicle)的转型，需要基于对不同技术领域进行共同分析的多级策略。 在文本中，我们从电子/电气架构的角度分析SDV，描述了SDV对各个功能领域内部和之间的影响，并利用此来推导技术需求和参考架构。 SDV的实施与新的以车辆为中心(Vehicle Centric)和区域性架构(Zonal Architecture)密切相关，因为这些提供了使用高性能中央计算机(High Performance Central Computer)和区域控制器(Zone Controller)以简化开发功能作为技术基础。为确保设计仍然具有成本效益，其中至关重要的是以务实的方式推动技术转型，特别是考虑到现有架构。没有一种大小适合所有的解决方案，因此我们在文本中包括可能的融合、迁移和融合情景，这些情景也可以分步实施。 作为全球最大的一级汽车零部件供应商-博世，我们拥有多年在所有汽车领域的经验，我们提供了对新车架构这一颠覆性主题的全面观点。通过这样做，我们希望帮助我们的客户向下一代整车电子电气架构形态转型。 1 背景简介 过去几年里，对新的汽车电子架构的需求大幅增长，第一批汽车制造商已经开始转向集中式(Centralized)和区域式(Zonal)架构。然而，对于这些新设计还存在一些批评。在汽车电子架构领域，有人认为它们过于昂贵、难以扩展，并且缺乏从传统系统逐步迁移的风险缓解路径的潜力。但与此同时，新的架构也带来了新的机会。它们通过简化提供了相关的竞争优势，实现了全面更新，并将软件配置和可扩展性作为中心关注点。尽管目前存在一些停滞，但是推动汽车架构根本变革的竞争已经开始。
传统基于功能的电子电气架构设计 新的汽车架构可以更好地满足消费者对驾驶体验的不断变化的期望。在当今市场上，引擎性能、外观和安全性已经不再是消费者选择汽车时唯一考虑的标准。特别是年轻人购买汽车是因为它能为他们提供娱乐、便利和融入在线世界(Online World)的机会。他们寻求能够无缝连接交通、家庭和工作的产品。当前，汽车正在演变为一个技术阶段，个性化用户体验(User eXperience)和可持续演进迭代是关键因素。 对于成熟的汽车制造商来说，这是一个进入新领域并开拓新收入来源的机会。然而，新的汽车电子架构必须在确保车辆初期生产的成本效益和在整个车辆寿命周期内支持可重构性和可扩展性之间找到平衡。一次性的“配置套餐”越来越多地被后续可以添加车辆功能的“订阅服务”所取代。功能可以在车辆系列开始生产后继续进行开发。 汽车行业对这些挑战的应对方案是软件定义汽车(SDV Software Defined Vehicle)，它代表了技术解决方案空间从硬件到软件的转变。这种新的关注点带来了所期望的灵活性，但也需要改变整体汽车架构。除了需要用几个强大的汽车计算机替换许多小型、功能导向的控制单元之外，汽车内部和外部的连接以及旨在减少硬件和软件开发差异的“整车级操作系统(Vehicle OS)”是下一代电子电气架构的核心问题。在这些新的架构中，静态功能和附加功能由动态和分布式服务补充，例如使用云数据优化驾驶策略的服务。因此，新型架构与传统领域之间的界限变得更加模糊。在技术方面，我们经常发现这并不明显，但功能相互依赖性显著增加。很明显，传统架构、市场和车辆细分需要多种解决方案。 然而，通过较少干扰性的变化已经可以实现SDV的许多功能和目标。这使得今天的架构优化能够在持续演进中保持。 在文本中，我们从电气/电子架构的角度评估SDV。我们确定了SDV范式对不同功能领域的影响，并确定在改变现有解决方案时必须考虑的相关驱动因素。借助我们作为综合解决方案提供商的经验，我们探讨了如何现代化或替换现有架构组件，如控制单元、传感器、执行器和线束，以及需要添加新解决方案的位置。
汽车制造商正在加紧推进新的车辆集中架构，并逐步替代之前的架构模式 2 软件定义汽车正在改变汽车领域，但并不会消除它们。 人们对软件定义汽车(SDV)寄予了很高的期望。但是人们可能会想：既然订阅和基于服务的功能(例如，车联网流量数据的包月套餐)已经在今天的汽车中普遍使用，为什么软件定义汽车的技术基础需要进行适应呢？ 新奇之处在于其动态性。在软件定义汽车中，功能会随着时间的推移跨越所有功能领域不断增长，而不再只是在一次定义。一辆车成为一个活跃的平台，生产日期只是其能力的次要指标。要实现这一点需要几个前提步骤。 首先，需要具备能力强大的集中式硬件，该硬件设计有相应的性能储备或可以在车辆使用寿命内更换。这是最明显的变化。在传统分布式架构中无法实施软件定义汽车。 第二个基本要求是与云平台保持稳定连接，通过该平台管理功能，并与车辆进行持续互动(如遥测、数据和服务)。云平台和车辆成为一个紧密相连的技术生态系统。最后，更新路径成为最关键的元素。更新将用于不同目标。包括： 新鲜度：更新或扩展现有功能以改善用户体验。 错误修复：在开发后及时修复错误，以免影响个别客户。 增值服务：引入新功能以持续为车辆增加短期和长期价值。 在整个汽车使用寿命内，对技术实现新功能的需求需要新的系统布局和“软件化”。但是，并非每个部分的解决方案都相同。尽管所有领域最终都将采用更多的软件驱动开发方法，但形式各异。必须考虑到各个领域的个别约束和优化点。为了了解软件定义汽车的技术需求，我们收集了每个领域的新驱动因素和期望，这让我们能够审视每种新的电子电气的架构决策和变化点。 接下来，我们将从多媒体信息娱乐域和车身舒适域开始，然后底盘转向与车辆运动相关的功能域，并以对驾驶辅助和自动驾驶功能域的分析作为结尾。 新的软件定义汽车通过连接汽车的不同功能域获得其汽车特定的特性。这种跨领域功能已经存在于今天。然而，在软件定义汽车中，领域之间的连接点将不再是特定功能，而是更广泛和通用地设计，以支持未来各种可能的应用程序的重复使用。我们预计信息娱乐域和车领域最初会受到这种转变的最大影响，因为它们共同提供了乘客与整车之间常被设想的数字和物理交互。通常情况下，信息娱乐领域也是云上链接的功能终点，将交互扩展到智能手机和远程服务。 为了快速实现可以立即被消费者体验的新的有价值的服务，新的整车平台提供了对必要的传感器信息、执行器和整车信息的便捷访问。然而，安全和保护目标在这种新的设置中不能被危及。这尤其适用于控制灯光、车门和座椅的整车功能，其中实施或执行错误可能会产生安全隐患。此外，可识别个人的信息必须且始终得到保护。 出于这些原因，我们预计车辆的物理功能及其底层控制仍然会在很大程度上与信息娱乐领域分离，并且仅通过逻辑接口(称为整车API或硬件抽象层HAL)由信息娱乐应用程序访问。出于实际原因，将车身控制功能至少部分放在专用控制单元上(可能作为区域控制器Zonal Controller的附加功能)或将其集中在另一个中央控制器(Central Controller)的受保护执行环境(Protected Execution Environment)中甚至是有意义的。这提供了从功能安全(Functional Safety)和网络安全(Cyber Security)角度来看所必需的分离。 然而，我们观察到，在实践中，汽车制造商(OEM)对传感器和执行器的控制逻辑进行不同的分配规划。逻辑是集中的，本地实施在现有的控制单元上，甚至分布在区域控制器Zonal Controller之间。分配通常是针对每个功能单独决定的，并且很少遵循通用策略。然而，由于系统自诊断、启动时间和回退方面的更严格要求，传感器/执行器等特定的硬件单元永远不会完全消失在更深层次的系统中。 如上所述，通用应用接口(Generic API)是简化和实现跨域功能(Cross Domain Functions)的基石。为了进一步优化，SDV平台通过通用、高级、基于软件的保护机制来实现功能安全目标(Functional Safety Goals)，以便在行驶过程中锁定关键执行器等。这显著减轻了SDV应用程序的处理负担，并可以与执行器中简单的本地保护机制相结合。 整车API是一种软件构造，通过相应的抽象，允许技术端点在E/E架构中几乎完全自由地迁移。然而，底层通信总线需要能够支持日益增长的动态需求。 因此，这些API与支持动态建立连接和支持可靠服务质量的传输协议相结合。例子包括SOME/IP和DDS，两者都在以太网类型总线上使用，通常与时间敏感网络(TSN Time Sensitive Networking)结合使用。在这些架构的系统工程中，我们看到了对变体(Variants)和版本(Version)管理的另一种改变。版本管理将扩展到不仅包括软件组件版本管理，还包括API版本管理。后者有助于更容易地管理依赖关系。然而，除了管理技术兼容性之外，还需要考虑其他任何额外的规定，例如释放整体功能链。 尽管辅助和自动驾驶功能越来越普遍，但对于许多汽车制造商来说，手动驾驶体验仍然是设计的重要部分，因为它仍然是品牌的本质。因此，我们预计驾驶软件，特别是负责常规驾驶情况的部分，将不会沿着同样的连续演进道路发展，而是在车辆生产开始时已经达到非常成熟的状态。随后的软件更新主要预计会发生在“引擎盖下”。一些扩展将以维护和性能改进的形式出现在SDV中，这些改进利用云数据或在外部运行非关键的额外功能。 虽然最终客户可能无法立即体验到该领域中的新SDV架构，但这些架构仍然可以为制造商带来显著的好处。他们可以利用引入集中控制系统来提高车辆在动态纵向和横向运动协调方面的安全性、舒适性和效率。通过进一步将转向、制动、加速和悬挂功能转移到该系统，运动功能可以在一个更统一的开发环境中实现。 然而，尽管存在这种向集中化的趋势，但我们仍然没有看到任何一项重大举措来消除高频控制/调节任务与该领域的传感器和执行器之间的密切联系。系统成本方面的相对较低效益、非常严格的安全要求以及针对性能和成本进行高度优化的个别组件阻碍了这一趋势。 对于以上提到的子系统，SDV汽车还具有一个优势，即除了简化联合开发外，还可以在不需要将车辆送到修理厂的情况下进行更新。通过这种方式，还可以引入用于关键行驶情况下的驾驶支持功能的改进，例如牵引控制和整车动力学。然而，出于安全考虑和更严格的汽车认证法规，预计汽车电子领域不会像其他领域那样具有相对较高的功能更新频率和版本多样性。 一个与汽车后台相连接的在线渠道，很可能是在与直接驾驶协调功能分开的执行环境中实现的，为通过基于云的功能扩展提供了使驾驶体验更加安全的机会，例如大雪天气提前预警。然而，由于车辆必须保持可用性，即使没有远程连接，这些功能主要是核心功能之外的非必要附加功能。 用于优化操作策略的功能也是如此，这些功能（取决于开发阶段）在针对动态负载进行优化的本地或云环境中实现。然而，根据这些功能与车辆认证的相关性，分配和更新的自由度可能会受到限制。 对于汽车制造商来说，这提供了新的间接盈利模式的机会。通过标准接口收集的数据可以用于价值创造性的服务，例如预测性维护(Predictive Maintenance)和创建电池证书。功能也可以在更晚的时间激活。
整车集中架构是对C.A.S.E.范式的期望作出的回应。它要求将技术解决方案转移到软件中，并且需要一个支持快速迭代的技术平台 辅助和自动驾驶功能的发展是SDV持续互联的重要受益者。通过不断涌入的场景和遥测数据，自动/辅助驾驶系统(ADAS)可以持续改进。通过迭代更新，这些改进将推出给所有客户。因此，预计更新频率可能会更高。
电子电气架构从分布式向集中式演变 SDV技术的上述元素通常是可持续提高产品质量所必需的，但它们目前已经在现有的以域中心(Domain Centralized)的架构中实现。因此，在用户体验方面，乍看之下似乎不需要采取行动。这是否意味着ADAS是一个“非SDV”领域？并非如此。 ADAS的最终客户业务模式发生了变化，影响了底层的电子/电气架构。以往的架构是为了通过允许用户购买选择不同的车辆功能配置来优化成本。虽然具有成本效益，但这排除了任何后期功能升级的可能性。 在ADAS领域，架构为了具备通用的SDV能力，通常采用了一种完全不同的方式。由于传感器和计算性能过度配置，车辆生产成本可能会增加，但通过订阅模式和按使用收费的选项可以抵消这些成本增加，从而带来收入。此外，尽管在个别情况下可能不需要所有这些功能，减少车型配置数量仍然可以降低成本，所以很多OEM还是会这样做。 SDV的互联功能通常用于功能发布管理和结算。很明显，这只有在覆盖车辆生产成本、寿命周期内的额外收入以及可能减少的车型配置数量的商业案例呈现出正面的情况时，才代表这是一个有利可图的商业模式。 根据目前的观察，汽车制造商特别是专注于中高端和豪华车型的制造商迄今为止一直采用这种方法。从辅助（<=L2 ）驾驶到自动化（>=L3）驾驶功能的过渡显著增加了对传感器、性能和冗余系统结构的需求。为了使额外功能购买模式在非豪华车型中起作用，区分允许或不允许后期集成>=L3驾驶功能的汽车，成为生产中创建车型配置变种的有效标准。在新的整车架构中，可以通过纯增量扩展设计来实现这一点，例如使用额外的集中控制器(Centralized Controller)、冗余电源以及额外的传感器，而不会干扰原始的<=L2 的架构。 通过与云端更紧密的集成，可以将其他数据源包含到SDV中，从而进一步提高辅助功能的功能性能(例如，通过使用在线地图与检测到的道路条件进行预测性规划)。在更强大的无线通信技术可用之前，这些更易受波动的SDV功能不会取代ADAS功能平台的稳定、普遍可用的核心，而是作为补充。 从整体架构的角度来看，在设计SDV汽车时，ADAS功能的集中化仍然是一个重点。这主要是为了在同一硬件平台上实现更广泛的基于软件的扩展。根据目前的技术水平，我们预计需要大量带宽的ADAS专用传感器系统（如摄像头、激光雷达系统和原始数据雷达系统）最初将通过与技术领域相关的宽带接口（例如摄像头使用LVDS，多千兆以太网）保持星型拓扑结构连接。在当前设想的架构中，在ADAS领域内向区域化架构(Zonal Architecture)的转变似乎对带宽较低有的接口更有优势。对于超声波传感器而言，区域集中化也可能在车辆结构布置方面具有优势。 3 软件架构中的主要挑战是管理复杂性 在前一章中，我们概述了整车各个功能域的不同需求以及它们如何从SDV电子电气架构中获益。集中和融合是其中的关键因素。在接下来的内容中，我们将进行一次小型的软件领域探索，以了解技术分离需求，因为这是一个对电气电子架构中的整合程度有重大影响的主导因素。 在SDV中，软件成为汽车技术发展的关键。为了管理日益增长的软件体量，必须减少且控制复杂度。这意味着SDV的软件平台和工具必须是合适的，同时还需要评估硬件设计是否能够作为“软件载体”。在这里，基于硬件的良好分离机制支持至关重要。以往通过将功能放入不同的控制单元来减少复杂性，现在控制器平台的内部成为了分离的主要贡献者。 随着SDV的发展，虚拟化(Hypervisor)管理程序和容器(Container)等技术分离机制起着关键作用。对于微处理器平台，其他行业的技术解决方案，如数据中心的技术解决方案，已经被转移到汽车领域并得到增强。这允许来自不同域的功能即使合并到单个系统芯片(SoC)上。汽车领域可用的操作系统提供了许多功能，允许根据需要进行独立开发，因此小型团队可以尽可能自主地管理、验证和确认它们，而不用回归。这也适用于与功能安全相关的免于干扰要求。然而，汽车微处理器平台的演进尚未完成，并且仍在由SOAFEE等联盟推动。尽管如此，已经达到了较高的成熟水平，使得多个整车域的功能能够整合到单个微处理器平台上。 另一方面，微控制器平台在支持模块化功能部署方面仍处于早期阶段。这部分源于硬件本身的限制，但也适用于针对单点集成和整体部署的许多微控制器软件框架。因此，它们的粒度最多只能达到基于虚拟化分区的分离级别，但在独立性和硬件不可知性方面存在缺陷。这对于精细的部署能力构成了阻碍，目前导致人们普遍认为SDV功能只能在微处理器平台上进行开发。 特别是对于常规驾驶和辅助/自动驾驶领域，由于其高度的安全性和紧密功能耦合要求，尽管进行了解耦开发，但作为功能实现的软件仍必须作为一个整体进行管理。 这是必要的，例如满足联合国欧洲经济委员会R156关于软件更新发布的要求。在这种背景下，与能够单独安装或更新软件组件的能力相比，解耦与认证相关的功能更加重要。这导致了电子电气架构中设计必要的分区，严格将认证相关功能与其他功能分开。 4 区域式电子电气架构的实现 正如现在显而易见的那样，在SDV汽车的电子电气架构中，集中化是必不可少的，但可能受到所使用的计算硬件或软件框架的技术能力的限制。为了完善我们对这些架构的理解，我们现在将转向电子电气架构的底层层次，特别是在SDV汽车中使用区域控制器(Zone Controller)来解耦功能。
区域性电子电气架构 Zonal Architecture 经常提到的整车分区化的主要驱动因素之一是使用区域控制器(Zone Controller)进行整车区域性分割，通过分段或多路复用等方式简化线束。从通信网络的角度来看，这些区域控制器将低速通信通道捆绑在一起，并将它们连接到更大的中央骨干网络上。在区域电子电气架构中，电源网络通过使用例如电子保险丝来确保精细的安全和控制架构。这简化了整体电力分配，优势在于与负责主要分配的中央电力管理相结合实现。区域化可以在生产成本和自动化线束生产及安装方面带来好处，但其优势因整车上的设备数量而异。尤其是在成本要求极高的经济型车型，以及具有较少功能的车型，为了简化线束而增加额外的ECU可能并不划算。 如果区域ECU能够同时减少整体ECU的数量，那么它们将获得进一步的成本优势。这在与车身控制相关的整车应用中尤为明显，因为可以合并许多小型ECU。 然而，正如本节标题已经指出的那样，区域的任务是根据实际情况决定的，即从“中央控制单元的延伸”，到基本独立的以整车电气布置为导向的扩展型车身域控制器。面向服务的架构(SOA Service Oriented Architecture)允许在分配和使用方面具有更大的自由度，并将区域控制器作为实现抽象车辆API的基础设施元素。
特斯拉Model 3的区域性电子电气架构 区域ECU的扩展受到引脚数和散热限制的限制(特别是对于功率电子器件)，这意味着对于高性能SoC或大容量存储器等散热敏感组件的使用受到了严格限制。相比于采用更全面而昂贵的冷却解决方案可以实现更高性能的区域电控单元，采用主动冷却的集中化中央汽车计算机更具优势。 进一步将功能转移到区域ECU（电子控制单元），特别是用于ADAS领域的传感器预处理，并没有明显的优势。无论是增加集中化以简化传感器，还是在传感器内部进行预处理，在域独立性和技术特异性方面都更合理。例如，雷达系统的处理算法非常依赖传感器。将其移至区域ECU需要共同的组件开发，并对区域ECU的设计造成额外负担。从功能上来说，分区预处理的优势是有限的，这一点在具有需要合并重叠图像区域的360度全景影像案例中就变得明显。需要注意的是，这并不意味着摄像头永远不会被分区，因为技术标准和芯片可用性在不断提高。然而，在这种情况下，区域只会充当多路复用器(Multiplexer)。 最后，专门用于通信分发的区域ECU具有执行车载诊断网关功能的潜力。然而，就SDV汽车系统而言，这必须与一个具备远程数据收发和更新功能的主机需求相协调，当然这可以在中央计算单元中有效地实现。 5 集中化的下一个阶段会有不同的变体 从功能域(Domain)的角度来考虑SDV架构，正如前面介绍的那样，可以明显看出向集中化发展的趋势。高级驾驶辅助系统（ADAS）、信息娱乐系统、驾驶和车身功能都会集成到一个统一的电控单元（ECU）上。在'新'功能域(Domain)和区域ECU之间，更加标准化的接口将允许跨功能域实现各种功能。
整车常见的几大功能域 下一步的集成将在已完成整合的功能域上进行，从而产生不同的技术变体。因此，单一功能域控制器(Domain Controller)将逐渐消失于电子电气架构中。然而，在ECU内部，它们仍然存在，原因包括对批准和管理流程的不同要求，以及不同的技术限制。
整车集中架构将引入集中式整车计算机和区域电控单元（ECU）。正如这个例子所示，不同域的跨域集成程度和向纯粹的区域通信/电力网络的转变程度将有所不同 某些汽车制造商今天已经实施的一个集成步骤是“模块化外壳”，其中独立的计算单元被安装在一个共同的机械框架中。特别是ADAS和信息娱乐领域，两者都依赖于高性能SoC和对热敏感的存储组件，可以从共同的冷却系统和可能的额外共用基础设施中获益。模块化外壳概念可以设计为固定的多PCB解决方案，或者考虑更灵活性的适配模块概念。这样可以降低维护成本，并允许在车辆的使用寿命内可能被更好的硬件替换。 单个PCB上的多SoC解决方案代表了更严密的集成水平，同时也增加了协同效应和成本优势。它们还可以与模块化设计概念相结合，用于伸缩扩展变体。尤其对于成本敏感的领域，基于融合SoC的解决方案代表了一种有效的集成解决方案。在这种情况下，分离是通过软件层面实现的，例如使用虚拟化(Hypervisor)程序和容器(Container)框架，始终与强大的硬件支持的分离和服务质量机制进行配对。从功能免于干扰(freedom from interference)的角度来看，这种集成程度也是最复杂的。 关于哪种集成选项最合适的问题不能仅从技术角度回答。然而，特别是使用现有架构中的元素，逐步从模块化外壳概念过渡到融合SoC的方法似乎是一种最小化风险的优势方法。 除了主要以微处理器(MPU Micro-processor)为中心的ADAS和娱乐系统集成平台外，还可以考虑一个类似的以微控制器(MCU Micro-controller)为中心的整车运动控制、网关和车身控制等功能的集成方式。这些平台主要由更强大的分离机制主导，这些机制主要是以硬件形式设计的。这样才能处理更高的确定性要求和相关的认证功能解耦等问题。这与更静态的软件框架相关，然而，这些框架基于已建立的标准，如AUTOSAR Classic。这些平台具有较低的待机电流消耗、快速启动和更容易实现最高安全水平的功能。
AUTOSAR Classic的软件架构 6 结语 下一代车辆架构将用户体验和软件置于首要位置。在消费者偏好的变化推动下，使得汽车制造商利用新的商业模式，这些模式建立在以数据为中心的车辆与基于云的服务互连的基础上，打破以用户为中心的领域与汽车自身功能域之间的隔阂。在硬件和车辆层面上的抽象，以及在软件开发方面的更大自由度和解耦是应对车辆系统日益复杂性的必要条件。通过调整电子电气架构，可以显著简化车辆功能开发。在空间和车辆广义集中化方面，控制单元的集中化是大势所趋。尽管最近有所放缓，但新型整车架构的趋势仍然持续不减，主要表现为高性能计算机和区域ECU。 为了在这一转型中实现成本效益、时间周期缩短和质量目标，需要采用一种全面而有针对性的方法，使受影响的车辆领域的特定技术、商业和功能考虑保持一致，而不是采用过去那种过于教条式的以整车为中心的架构。使汽车电子架构能够从传统架构逐步发展，并覆盖入门级市场等细分领域，这一点尤为重要。 然而，新的以软件为中心的方法在现有生态系统中无法实现足够的扩展性。SOAFEE、COVESA和Eclipse.SDV等新举措以前所未有的规模提供了对软件资源和开发人员的便捷访问。然而，要满足汽车行业的质量要求，还需要进行更多的合作努力，包括硬件标准方面的合作。需要建立新的合作伙伴关系以产生共同的协同效应。在这样做的过程中，必须考虑到高度监管和注重安全的汽车行业的特定情况，该行业在高成本压力下运营。缺乏用于协同项目和产品开发的共同流程、方法和工具是需要克服的一个重要挑战。 如果软件更新、集成云服务、变种和配置管理等需求能清晰地映射到首选技术解决方案和功能视图上，那么软件定义汽车的未来必将成功。作为一个汽车跨功能域的系统供应商，Bosch在经典汽车领域和SDV领域拥有专业知识，我们正在努力解决这些问题。作为一家全球性企业，我们将我们丰富的专业知识带入项目和研究中，带动以内容为中心的可行架构进步，就像文本中所概述的那样。 原文：Bosch Whitepaper - The next step in E/E architectures |
|
|
