这是《正常运行时间方程》的第一部分，该系列文章探讨了商用车辆边缘智能的经济性。
一辆重型卡车因出现间歇性故障代码被送至经销商处。技师更换了最可能出现故障的部件，清除故障代码后，将卡车交还给车主。 三周后，该卡车因出现相同的故障代码再次返厂。随后，该故障又再次发生。在第四次返厂时，技术人员才查明了真正原因：一条距离故障代码所指位置两个模块远处的线束发生了磨损。在多次返厂维修期间，该车队整整一周的大部分时间都无法使用这辆卡车。原厂（OEM）不仅为三件并未损坏的零部件支付了费用，还承担了三轮保修人工费，且与该车队之间的关系也因此受损——而这正是该车队下次更新车队时所需要维系的关系。
没有人做错什么。故障代码的触发完全符合设计要求。A J1939故障代码（SPN/FMI） 会告知技师哪个信号超出了预期范围以及超出的具体情况，但不会说明原因。一个简单的布线或连接器问题就可能同时触发多个模块的故障代码。商用车多年来一直采用基于远程信息处理的维护系统，包括由DTC触发的维修工单、仪表盘和警报，这一闭环机制运行良好。真正受限的是输入该系统的信号分辨率。
上下文缺失的代价
根据 ATRI发布的《2026年卡车运输运营成本分析》，2025年卡车平均运营成本达到每英里2.336美元，创历史新高。维修保养费用上涨8.6%，达到每英里0.215美元，是除过路费外涨幅最大的单项支出。随着维修成本攀升，因故障代码模糊而导致的每次返修所产生的费用也随之增加。诊断缓慢的情况屡见不鲜： 麦肯锡2026年调查 显示，确认根本原因大约需要七周时间，并指出数据质量低下是利用AI 预测质量问题的主要障碍。
对于整车制造商（OEM）而言，这种模糊性体现在保修费用上。正如Sonatus 博客文章中指出的，2024年整个汽车行业的保修成本达到580亿美元，是2012年水平的两倍 AI 正是为解决这一“580亿美元问题”而打造的中所述。每一项不必要的保修更换，以及每一次“未发现故障”的退货，都计入了这一数字。
运行时间是决定商用车型能否赢得下一份车队合同的关键因素之一，而且车队在采购要求中越来越常将运行时间和诊断能力作为必备条件。
上下文缺失也会带来人力成本。当警报频繁出现模糊、延迟或错误的情况时，驾驶员就会停止根据警报采取行动，而技术人员则开始手动检查仪表盘。一个无人信任的警报比没有警报还要糟糕，因为这会让人们养成忽略真正重要警报的习惯。
整个车队以及卡车内部的分散状况
在整个车队中，问题在于不同品牌之间存在不一致。 《前路：通过标准化商用车数据开拓新机遇》，该报告指出，超过90%的车队运营着多品牌混编车队，而专有信号格式和命名规范使得系统集成变得困难。 COVESA 预测，商用车远程信息处理市场规模将从2022年的330亿美元增长至2032年的950亿美元，而这一增长完全建立在数据碎片化的基础上。
就单辆卡车而言，问题在于所有权。重型卡车原始设备制造商（OEM）同时也扮演着系统集成商的角色。发动机、变速箱、后处理系统和制动控制器通常来自不同的供应商，而各供应商报告故障的方式各不相同。 整车制造商拥有车辆所有权及保修责任，但并非每个触发故障代码的电子控制单元（ECU）都归其所有。COVESA VSS 等标准有助于实现跨品牌故障代码的命名统一。然而，这些标准并不能补充供应商ECU故障代码中遗漏的上下文信息。
“车辆上下文”的实际含义是什么
“车辆上下文”并不意味着更多的数据。它指的是在恰当的时刻捕获到的、围绕某个事件的信号、系统状态和历史记录：
- 故障周围的窗口，而不仅仅是代码。 触发前后的信号显示了该状况是如何发展的。
- 该时刻的跨域状态。 这意味着发动机、后处理系统、电气系统以及工作循环在同一时间的状态。
- 由事件本身触发的数据采集。 捕获针对的是正在被提出的问题，而不是记录所有内容或按照固定时间表进行采样。
- 车辆上保存的故障历史记录。 当出现某种规律时，工程师可以追溯数周前的数据，而不必等待故障再次发生。
这就是事件驱动型数据收集（例如 Fastlane™ Collector，它对应于 代理循环的“收集”阶段相对应。它同时也改变了数据的适用场景。一个脱离上下文的故障代码虽然可以生成工单，但作为训练预测模型的素材却很糟糕，因为基于模糊标签训练的模型会继承这种模糊性。正是这些富含上下文的事件数据，使得基于AI/ML的预测成为可能。我们将在本系列的后续篇章中再次探讨这一话题。
为什么由车辆来决定这一点
再好的仪表盘也无法恢复车辆从未捕获过的上下文信息。车辆上下文是在事件发生前后几秒内，由车辆在边缘端根据平台设计用于感知、保存和传输的数据来确定的。因此，这属于整车厂商（OEM）的架构决策。车队运营方深感这一问题，并通过采购要求将问题上报给上游。而能够解决这一问题的，正是整车厂商的平台和电子/电气（E/E）架构团队。
采集这些环境信息需要付出代价：包括传感器、车载计算、存储和带宽。整车制造商（OEM）在管理商用车产品线的物料清单（BOM）成本时，面临着比乘用车更薄的利润率和更低的销量，因此这绝非轻率之举。归根结底有两条路径：整车制造商可以投资更强大的硬件来获取更高精度的数据，或者开发足够高效的软件，利用车辆现有的硬件来获取这些数据。
归根结底： 商用车队早已开始利用车辆数据采取行动。问题在于车辆上下文信息：故障代码仅标记被监测的参数，而非具体故障部件，这种模糊性导致了重复维修、保修成本上升、警报疲劳，以及用于AI 的训练数据过于粗糙。解决这一问题需要原始设备制造商（OEM）在边缘端——即事件发生时在车辆上——做出平台决策，这将迫使我们进行成本权衡，相关内容将在第二部分中探讨。