随着汽车不断从硬件驱动向软件驱动转变，汽车行业的竞争规则正在发生巨大变化。
发动机是20世纪汽车的技术和工程核心。 如今，这一角色越来越多地由软件、更强大的计算能力和先进的传感器来填补。 大多数创新都涉及所有这些。 一切都取决于这些因素，从汽车的效率、互联网接入和自动驾驶的可能性，到电动汽车和新的移动解决方案。
然而，随着电子产品和软件变得越来越重要，它们的复杂程度也随之增加。 以现代汽车中包含的越来越多的代码行 (SLOC) 为例。 2010年，一些车辆拥有大约一千万个SLOC； 到 2016 年，这个数字增加了 15 倍，达到约 150 亿行代码。 雪崩般的复杂性会导致软件质量出现严重问题，对新车的大量评论就证明了这一点。
汽车的自主程度更高。 因此，汽车行业工作人员将软件和电子产品的质量和安全视为确保人员安全的关键要求。 汽车行业需要重新思考软件和电气电子架构的现代方法。
解决紧迫的行业问题
随着汽车行业从硬件驱动设备转向软件驱动设备，车辆上软件和电子设备的平均数量正在迅速增加。 如今，软件占 D 级或大型汽车总内容的 10%（约 1220 美元）。 软件的平均份额预计将增长 11%。 据预测，到 2030 年，软件将占车辆总含量的 30%（约 5200 美元）。 参与汽车开发某个阶段的人们试图从软件和电子产品带来的创新中受益并不奇怪。
软件公司和其他数字参与者不再希望被抛在后面。 他们正试图吸引汽车制造商作为一级供应商。 公司正在通过从功能和应用程序转向操作系统来扩大对汽车技术堆栈的参与。 与此同时，习惯于使用电子系统的公司正在大胆地进入科技巨头的技术和应用领域。 高端汽车制造商正在不断发展并开发自己的操作系统、硬件抽象和信号处理，以使他们的产品本质上独一无二。
上述策略会产生一些后果。 未来将出现基于通用计算平台的车辆面向服务架构（SOA）。 开发者会添加很多新的东西：互联网接入领域的解决方案、应用程序、 、高级分析和操作系统。 差异不在于汽车的传统硬件，而在于用户界面以及它如何与软件和先进电子设备配合使用。
未来的汽车将转向具有新品牌竞争优势的平台。
这些可能包括信息娱乐创新， 基于“故障安全”行为的智能安全功能（例如，即使系统部分发生故障，也能够执行其关键功能）。 软件将继续在数字堆栈中向下移动，以智能传感器的形式成为硬件的一部分。 堆栈将变得水平集成，并将接收新的层，从而将架构迁移到 SOA。
时尚潮流改变了游戏规则。 它们影响软件和电子架构。 这些趋势推动了技术的复杂性和相互依赖性。 例如，新的智能传感器和应用程序将创建 。 如果汽车公司想要保持竞争力，他们需要有效地处理和分析数据。 模块化 SOA 更新和无线 (OTA) 更新将成为支持车队中复杂软件的关键要求。 它们对于实施按需出现功能的新业务模型也非常重要。 信息娱乐系统的使用将越来越多，并且先进的技术（尽管程度较小） 。 原因是越来越多的第三方应用开发商为车辆提供产品。
由于数字安全要求，传统访问控制策略不再有趣。 是时候切换到 ，旨在预测、预防、检测和防范网络攻击。 随着高度自动驾驶（HAD）能力的出现，我们将需要功能的融合、卓越的计算能力和高水平的集成。
探索有关未来电气或电子架构的十种假设
技术和商业模式的发展路径尚未明确。 但根据我们广泛的研究和专家意见，我们针对未来的电动或电子汽车架构及其对行业的影响提出了十种假设。
电子控制单元 (ECU) 的整合将变得越来越普遍
行业将转向统一的车辆 ECU 架构，而不是使用多个特定 ECU 来实现特定功能（如当前的“添加功能、添加窗口”风格）。
在第一阶段，大部分功能将集中在联合域控制器上。 对于核心车辆领域，它们将部分取代分布式 ECU 中当前可用的功能。 开发工作已经在进行中。 我们预计成品将在两到三年内投放市场。 整合最有可能发生在与 ADAS 和 HAD 功能相关的堆栈中，而更基本的车辆功能可能会保留更高程度的分散化。
我们正在迈向自动驾驶。 因此，软件功能的虚拟化和对硬件的抽象将变得至关重要。 这种新方法可以通过不同的方式实施。 可以将硬件组合到满足不同延迟和可靠性要求的堆栈中。 例如，支持 HAD 和 ADAS 功能的高性能堆栈，以及用于核心安全功能的单独的低延迟、时间驱动堆栈。 或者您可以用一台备用“超级计算机”替换 ECU。 另一种可能的情况是，我们完全放弃控制单元的概念，转而采用智能计算网络。
这些变化主要由三个因素驱动：成本、新市场进入者和 HAD 需求。 降低功能开发成本和所需的计算硬件（包括通信设备）将加快整合过程。 对于汽车市场的新进入者来说也是如此，他们可能会通过以软件为中心的车辆架构方法来颠覆该行业。 对 HAD 功能和冗余不断增长的需求也将需要更高程度的 ECU 整合。
一些优质汽车制造商及其供应商已经积极参与 ECU 整合。 他们正在采取第一步更新其电子架构，尽管目前还没有原型。
行业将限制特定设备使用的堆栈数量
合并支持规范了堆栈限制。 它将车辆和ECU硬件的功能分开，其中包括虚拟化的积极使用。 硬件和固件（包括操作系统）将取决于核心功能要求，而不是车辆功能域的一部分。 为了确保分离和面向服务的架构，必须限制堆栈的数量。 以下是可在 5-10 年内构成未来几代汽车基础的堆栈：
- 时间驱动的堆栈。 在此领域中，控制器直接连接到传感器或执行器，而系统必须支持严格的实时要求，同时保持低延迟； 资源调度是基于时间的。 该堆栈包括实现最高水平车辆安全的系统。 典型的汽车开放系统架构 (AUTOSAR) 领域就是一个例子。
- 时间和事件驱动的堆栈。 例如，该混合堆栈将高性能安全应用程序与 ADAS 和 HAD 支持相结合。 应用程序和外设通过操作系统分开，而应用程序是按时间安排的。 在应用程序内，资源调度可以基于时间或优先级。 操作环境确保关键任务应用程序在隔离的容器中运行，从而将这些应用程序与车辆中的其他应用程序明确分开。 自适应 AUTOSAR 就是一个很好的例子。
- 事件驱动堆栈。 该堆栈重点关注信息娱乐系统，该系统对安全性并不重要。 应用程序与外围设备明显分离，并且使用最优或基于事件的调度来调度资源。 该堆栈包含可见且常用的功能：Android、汽车级 Linux、GENIVI 和 QNX。 这些功能允许用户与车辆交互。
- 云栈。 最终堆栈涵盖数据访问并在外部协调数据访问和车辆功能。 该堆栈负责通信以及应用程序安全验证（身份验证）并建立特定的汽车接口，包括远程诊断。
汽车供应商和技术制造商已经开始专注于其中一些堆栈。 一个典型的例子是信息娱乐系统（事件驱动堆栈），公司正在其中开发通信功能 - 3D 和高级导航。 第二个例子是高性能应用的人工智能和传感，供应商正在与主要汽车制造商合作开发计算平台。
在时间驱动领域，AUTOSAR和JASPAR支持这些堆栈的标准化。
中间件将从硬件中抽象出应用程序
随着车辆继续向移动计算平台发展，中间件将允许重新配置车辆并安装和更新其软件。 如今，每个 ECU 中的中间件促进了设备之间的通信。 在下一代车辆中，它将把域控制器链接到访问功能。 使用汽车中的ECU硬件，中间件将提供抽象、虚拟化、SOA和分布式计算。
已有证据表明，汽车行业正在转向更灵活的架构，包括中间件。 例如，AUTOSAR自适应平台是一个动态系统，包括中间件、复杂操作系统支持和现代多核微处理器。 然而，目前可用的开发仅限于一种 ECU。
中期来看，机载传感器的数量将大幅增加
在未来两到三代汽车中，汽车制造商将安装类似功能的传感器，以确保安全相关储备充足。
从长远来看，汽车行业将开发专用传感器解决方案以减少其数量和成本。 我们相信，雷达和摄像头的结合可能是未来五到八年最流行的解决方案。 随着自动驾驶能力的不断增强，激光雷达的引入将是必要的。 它们将在对象分析领域和本地化领域提供冗余。 例如，SAE International L4（高度自动化）自动驾驶配置最初可能需要四到五个激光雷达传感器，包括安装在后部用于城市导航和近 360 度视野的传感器。
从长远来看，很难说车辆中传感器的数量。 它们的数量要么增加、减少，要么保持不变。 这一切都取决于法规、解决方案的技术成熟度以及在不同情况下使用多个传感器的能力。 例如，监管要求可能会增加对驾驶员的监控，从而导致车内安装更多传感器。 我们预计将看到更多消费电子传感器用于汽车内部。 运动传感器、健康监测（心率和睡意）、面部和虹膜识别只是一些可能的用例。 然而，为了增加传感器的数量甚至保持不变，将需要更广泛的材料，不仅在传感器本身，而且在车辆网络中。 因此，减少传感器的数量会更有利可图。 随着高度自动化或全自动车辆的出现，先进的算法和机器学习可以提高传感器的性能和可靠性。 得益于更强大、功能更强大的传感器技术，可能不再需要不必要的传感器。 今天使用的传感器可能会过时 - 将出现更多功能的传感器（例如，可能会出现超声波传感器，而不是基于摄像头的停车助手或激光雷达）。
传感器将变得更加智能
系统架构将需要智能集成传感器来管理高度自动化驾驶所需的大量数据。 传感器融合和XNUMXD定位等高级功能将在集中式计算平台上运行。 预处理、过滤和快速响应循环可能位于边缘或在传感器本身内执行。 据估计，自动驾驶汽车每小时生成的数据量为 XNUMX TB。 因此，AI将从ECU转移到传感器来执行基本的预处理。 它需要低延迟和低计算性能，特别是当您比较传感器中处理数据的成本和车辆中传输大量数据的成本时。 然而，HAD 中的道路决策冗余需要集中计算的融合。 最有可能的是，这些计算将根据预处理的数据进行计算。 智能传感器将监控自己的功能，而传感器冗余将提高传感器网络的可靠性、可用性，从而提高安全性。 为了确保传感器在所有条件下都具有良好的性能，需要使用传感器清洁应用，例如除冰器和除尘器和污垢去除器。
需要全功率和冗余数据网络
需要高可靠性的关键和安全关键应用将使用完全冗余的循环来满足安全操纵所需的一切（数据通信、电源）。 、中央计算机和耗电的分布式计算网络将需要新的冗余电源管理网络。 支持有线控制和其他 HAD 功能的容错系统将需要开发冗余系统。 这将显着改进现代容错监控实现的架构。
“汽车以太网”将崛起成为汽车的支柱
当今的汽车网络不足以满足未来交通的需求。 数据速率的提高、HAD 的冗余要求、互联环境中的安全和保护需求以及跨行业标准化协议的需求可能会导致汽车以太网的出现。 它将成为关键的推动者，特别是对于冗余中央数据总线而言。 以太网解决方案需要在域之间提供可靠的通信并满足实时需求。 这要归功于以太网扩展的添加，例如音频视频桥接（AVB）和时间敏感网络（TSN）。 行业代表和 OPEN 联盟支持采用以太网技术。 许多汽车制造商已经迈出了这一大步。
本地互连网络和控制器网络等传统网络将继续在车辆中使用，但仅限于传感器等封闭的较低层网络。 FlexRay 和 MOST 等技术可能会被汽车以太网及其扩展 AVB 和 TSN 所取代。
未来，我们预计汽车行业还将使用其他以太网技术——HDBP（高延迟带宽产品）和10G技术。
OEM将始终对数据连接进行严格控制，以确保功能安全和HAD，但他们将开放接口以允许第三方访问数据
传输和接收安全关键数据的中央通信网关将始终直接连接到 OEM 后端。 当规则未禁止时，数据访问将向第三方开放。 信息娱乐系统是车辆的“附件”。 在这一领域，新兴的开放接口将允许内容提供商和应用程序部署其产品，而 OEM 则尽可能遵守标准。
今天的车载诊断端口将被互联远程信息处理解决方案所取代。 车辆网络的维护访问将不再需要，但将能够通过 OEM 后端进行。 原始设备制造商将在车辆后部提供数据端口，用于某些用例（被盗车辆跟踪或个人保险）。 然而，售后设备对内部数据网络的访问将越来越少。
大型车队运营商将在用户体验方面发挥更大作用，为终端客户创造价值。 他们将能够在同一订阅内为不同目的提供不同的车辆（例如，用于日常通勤或周末度假）。 他们将需要使用多个 OEM 后端并整合整个车队的数据。 然后，大型数据库将允许车队运营商通过原始设备制造商级别无法提供的整合数据和分析来货币化。
汽车将使用云服务将车载信息与外部数据结合起来
“非敏感”数据（即与身份或安全无关的数据）将越来越多地在云中进行处理以获得附加信息。 该数据在 OEM 之外的可用性将取决于未来的法律和法规。 随着销量的增长 。 需要分析来处理信息和提取重要数据。 我们致力于自动驾驶和其他数字创新。 数据的有效利用将取决于多个市场参与者之间的数据共享。 目前尚不清楚谁将执行此操作以及如何执行此操作。 然而，主要的汽车供应商和技术公司已经在构建可以处理这些新数据的集成汽车平台。
可升级的组件将出现在支持双向通信的汽车中
车载测试系统将允许车辆自动检查更新。 我们将能够管理车辆及其功能的生命周期。 所有 ECU 都会从传感器和执行器发送和接收数据，检索数据。 这些数据将用于开发创新。 一个例子是根据车辆参数构建路线。
OTA更新能力是HAD必须具备的能力。 借助这些技术，我们将拥有新功能、网络安全以及更快的功能和软件部署。 事实上，OTA更新能力是上述许多重要变化背后的驱动力。 此外，此功能还需要在堆栈的各个级别（车辆外部和 ECU 内部）提供全面的安全解决方案。 该解决方案尚未开发。 看看谁会做以及如何做将会很有趣。
汽车更新可以像智能手机一样安装吗？ 该行业需要克服供应商合同、监管要求以及安全和隐私问题方面的限制。 许多汽车制造商已宣布计划推出 OTA 服务产品，包括为其车辆进行无线更新。
OEM 厂商将与该领域的技术提供商密切合作，在 OTA 平台上标准化其车队。 车载连接和 OTA 平台很快就会变得非常重要。 原始设备制造商了解这一点，并希望在该细分市场获得更多所有权。
这些车辆将在其设计寿命内获得软件、功能和安全更新。 监管机构可能会提供软件维护，以确保车辆设计的完整性。 更新和维护软件的需求将催生车辆维护和运营的新商业模式。
评估汽车软件和电子架构的未来影响
影响汽车行业的趋势正在造成与硬件相关的重大不确定性。 然而，软件和电子架构的未来看起来充满希望。 所有的可能性都向行业开放：汽车制造商可以成立行业协会来标准化车辆架构，数字巨头可以实施车载云平台，移动参与者可以制造自己的车辆或使用开源代码和功能软件开发车辆堆栈，汽车制造商可以引入具有互联网连接功能的日益复杂的自动驾驶汽车。
产品很快将不再以硬件为中心。 他们将以软件为导向。 对于习惯于生产传统汽车的汽车企业来说，这种转变将是困难的。 然而，考虑到所描述的趋势和变化，即使是小公司也别无选择。 他们必须做好准备。
我们看到几个主要的战略步骤：
- 独立的车辆开发周期和车辆功能。 OEM 和一级供应商必须决定如何开发、提供和部署功能。 从技术和组织的角度来看，它们必须独立于车辆开发周期。 鉴于当前的车辆开发周期，公司需要找到一种管理软件创新的方法。 此外，他们应该考虑现有机队的升级和升级选项（例如计算单元）。
- 定义软件和电子产品开发的目标附加值。 OEM 必须确定可以设定基准的差异化功能。 此外，明确定义自己的软件和电子产品开发的目标附加值至关重要。 您还应该确定需要产品的领域以及仅应与供应商或合作伙伴讨论的主题。
- 为软件设定明确的价格。 为了将软件与硬件分离，原始设备制造商需要重新考虑直接购买软件的内部流程和机制。 除了传统的定制之外，分析如何将敏捷的软件开发方法与采购流程结合起来也很重要。 这就是供应商（一级、二级和三级）也发挥着关键作用的地方，因为他们需要为其软件和系统产品提供明确的业务价值，以便能够获得更大的收入份额。
- 为新的电子架构（包括后端）开发特定的组织图。 汽车行业需要改变内部流程来交付和销售先进的电子产品和软件。 他们还需要考虑与车辆相关的电子主题的不同组织设置。 基本上，新的“分层”架构需要对当前的“垂直”设置进行潜在的破坏，并引入新的“水平”组织单位。 此外，还需要扩展团队中软件和电子开发人员的能力和技能。
- 为单个汽车零部件作为产品开发商业模式（尤其是供应商）。 分析哪些功能可以为未来架构带来真正的价值并因此可以货币化至关重要。 这将帮助您保持竞争力并在汽车电子行业占据重要的价值份额。 随后，需要找到新的商业模式来销售软件和电子系统，无论是产品、服务还是全新的东西。
随着汽车软件和电子产品新时代的开始，它从根本上改变了商业模式、客户需求和竞争本质的一切。 我们相信，从中可以赚到很多钱。 但为了利用即将发生的变化，行业中的每个人都必须重新考虑他们的汽车制造方法，并明智地设置（或改变）他们的产品。
本文是与全球半导体联盟合作编写的。
来源： habr.com