这是《正常运行时间方程式》的第2部分。 第1部分 阐述了为何必须在车辆上采集车辆环境数据。本部分将探讨实现这一目标所需的成本。
一个平台团队开发了一种模型，可以在卡车后处理（排放控制）系统发生故障数周前就预测到故障。 工程层面的问题已经解决。但平台层面的问题尚未解决：该模型该在何处运行？如果它能安装在卡车上现有的网关或远程信息处理控制器中，就可以随当前的生产计划一同交付。如果它需要性能更强的控制器，就必须等待下一代电气/电子（E/E）架构的推出，而它将永远无法应用于已经上路的卡车。
这是一个在每个新的数据应用场景中都会出现的问题，而在商用车领域，其背后的经济考量与乘用车相比存在以下三个方面的差异。
为什么卡车的计算方式不同
销量。2025年，美国8级卡车的零售销量为 208,386辆。美国轻型新车销量为 1620万，约为卡车销量的78倍。若将中型卡车和专用卡车纳入统计，差距虽有所缩小，但仍无法完全弥合。每增加一美元的计算硬件成本，以及每花费一美元用于集成和验证新控制器，所分摊的销量仅占总销量的极小一部分。
使用寿命。 美国重型卡车的平均 12.1年 。车队还延长了卡车的服役时间：ACT Research的数据 据《FleetOwner》报道 报道的ACT Research数据显示，车队中8级卡车的平均服役年限为6.3年，这是自2013年以来的最高纪录。新型计算硬件（例如性能更强的网关、远程信息处理单元或ECU）仅对新制造的车辆有所帮助。现有车队中的车辆往往会沿用出厂时配备的硬件长达十年或更久，而大部分 第一部分所述的 很大一部分就体现在这些已安装车队中。
架构更新周期。 商用车中的电子/电气架构通常遵循数年一轮的更新周期，且许多控制器来自原始设备制造商（OEM）无法完全掌控的供应商。与新型计算硬件相关的使用场景也需遵循这一时间表。
综合来看，这三个因素使得一个问题变得尤为关键：卡车所需智能能力的多少必须依赖于新硬件，又有多少可以通过更好地利用现有硬件来实现？车载AI 的实现有两种途径。一种是购买功能，另一种是提升效率。
途径一：购买能力
硬件的优势是切实存在的。集中式和分区式架构将工作负载整合到数量更少、性能更强的控制器上，并减少了布线。麦肯锡指出，由于这些控制器需要更强的处理能力， 因此会带来额外成本。商用车整车制造商也正朝着这一方向发展。 Coretura——这家由戴姆勒卡车和沃尔沃集团于2025年成立的合资企业，正在构建一个共享的软件定义车辆平台。该公司还将为商用车指定并采购集中式高性能控制器，首批产品计划于本十年末前应用于目标车型。
当工作负载确实需要更强大的计算硬件时——例如高性能的中央控制器或区域控制器，或是专用的AI 加速器——这便是最佳解决方案：无论是摄像头感知、ADAS、自动驾驶，还是任何在车辆整个使用寿命周期内，每辆车的价值明显超过在当前生产规模下所增加成本的情况。此外，在设计新平台时采用这种方案也合乎情理。
但这也有其局限性。根据该平台的时间表，该技术仅适用于新车。而且，更大的控制器并不能消除对高效软件的需求，因为共享计算机上的每个工作负载都在争夺相同的资源。在麦肯锡关于 汽车边缘计算AI 的研究中，46%的受访者将系统级芯片（SoC）资源有限列为障碍。
路径二：提高效率
软件方案能够更好地发挥现有硬件的潜力。目前已有若干技术日趋成熟：
- 模型压缩。 整数量化使模型 体积缩小约4倍，运行速度提升约3倍 ，且精度损失极小。将剪枝与量化相结合，可将模型存储空间 35倍至49倍，且不影响精度。麦肯锡指出，微控制器在边缘端运行轻量级AI 模型的能力正日益增强。
- 按需执行。 模型可安装在车辆上，而无需始终运行。如 《始终在线的AI 模型给商用车资源带来负担》一文所述一文所述，共享的车载运行时环境既能维持连续运行或安全关键型模型的持续运行，又能仅在车辆状态需要时激活其他模型（例如在车库停泊期间进行的电池健康检查）。
- 基于事件触发的数据采集和车载压缩。 车辆仅存储和发送与事件相关的数据，而非将所有数据进行流式传输。
- 虚拟传感器。 软件可以利用车辆网络中已有的信号来估算数值，而无需额外添加物理传感器。在一份 合作伙伴案例研究中中，基于CAN信号构建的纯软件前大灯水平调节传感器，使每辆车的硬件成本降低了多达20美元。在此案例中，软件方案不仅避免了增加物料清单（BOM）成本，更彻底消除了该成本。
在卡车领域，软件化路线的最大优势在于覆盖范围。它可以在不超出车辆计算能力的前提下，通过空中升级（OTA）部署到已投入运营的车辆上，并应用于现有程序中，无需等待下一代架构的推出。这就是 Fastlane™ Edge该方案的运作原理：它利用车辆现有的计算资源（如高性能网关、远程信息处理单元或中央计算机）运行AI 模型、虚拟传感器和预测性诊断，而无需专用AI 加速器。对于尚未配备此类计算能力的卡车， Fastlane™ Copilot 该方案可在原型车和测试车队中，在不改变现有车辆生产架构的前提下，为现有车辆添加高性能网关。
但这也存在局限性。软件无法将网关转变为感知计算机。它受限于计算余量、内存和验证工作量，并且在安全性、网络安全以及生命周期管理方面也存在自身成本。
把它当作一个决定来对待
错误之处在于将硬件和软件视为独立的预算。软件的效率高低决定了你需要多少硬件。平台团队应遵循以下切实可行的步骤：
- 先进行优化，再确定硬件规格。 应先确定压缩和事件触发式设计完成后的工作负载需求，而非在此之前。
- 问问价值在哪里。 如果大部分价值在于现有用户群，那么硬件路线就无法触及它。
- 根据您的生产规模，权衡价值与成本。 请将每辆车在其使用寿命期间的总价值，与新增硬件及集成成本进行权衡，并将这些成本分摊到您的实际产量中。
- 在新的架构即将推出时，预留出扩展空间。 在规划时应假设高效的软件将填补这一空间。
软件也有其自身的成本。卡车上每增加一个模型，都需要计算资源、内存、集成工作以及验证，而且在车辆整个生命周期内都需要对其进行维护。通过仅在需要时运行模型，并让所有模型共享同一个运行时环境，可以避免随着每个新用例的出现，相关成本不断增加。
一旦工作负载能够部署在本地设备上，接下来的问题就是：哪些工作应该部署在本地，哪些应该部署在云端。这将在第3部分中探讨。
归根结底： 采集丰富的车辆上下文信息并在车载系统上运行AI 需要成本，而商用车整车制造商（OEM）的产量远低于乘用车制造商，因此需在更小的生产规模下分摊这些成本。他们可以通过两种方式解决这一问题：一是增加更强大的硬件，并以数据价值作为投资依据；二是优化软件效率，使其能够利用车辆现有的计算资源运行。大多数厂商将同时采用这两种方法。 但小批量生产、12年的使用寿命以及漫长的架构周期意味着，整车厂商应将软件作为默认方案：在卡车现有的计算资源上运行新的工作负载，仅在需要（例如摄像头感知）或正在设计新的电子/电气（E/E）架构时，才增加计算硬件。