今天，很多主机厂都会提到他们在数据规模上的突破，汽车每天产生大量数据。但问题在于，这些数据如何真正赋能业务？如何用于创新？实际上，行业仍面临不少挑战。

我们发现，很多主机厂已经积累了大量车联网数据，尤其是在推行新能源车的这几年，数据存量更是大幅增长。然而，我们看到的情况是：很多数据“大而无用”。它们可能被用于一些宏观分析，但在研发、售后等具体业务场景中的价值挖掘仍然不足。例如，如何利用数据进行质量监控？如何更高效地支撑业务？这些都是当前需要解决的问题。

从业务需求来看，行业对数据的需求非常旺盛。核心原因在于，汽车本身发生了巨大变化——从过去的“控制系统”演变为“控制系统+计算系统”。过去，研发、生产制造的工具和方法，都是围绕控制系统设计的，而今天的汽车在计算系统上运行着大量新功能和软件，导致传统工具和方法已难以适应新的挑战。

因此，我们看到，今天的研发面临诸多挑战，售后服务同样如此。从研发到生产，再到售后，整个业务系统其实都有重构一遍的机会。我们对此感到很兴奋。

那么，具体而言，智协慧同团队能做什么？如何帮助主机厂更好地使用汽车数据？

我们将数据能力拆分为四个层级：

过去，数据采集往往难以支撑复杂的业务需求。第一层能力，就是要实现高精度、高质量的数据获取，以低成本的方式，将各业务部门所需的数据采集并回传。

业务部门在使用数据时，往往面临较高的技术门槛和成本。因此，第二层能力的核心是简化数据的访问和使用。通常，企业初步使用数据的方式是进行分析和生成报告，但如果这个过程过于复杂或成本过高，数据的价值就难以充分发挥。

3.  高效的数据闭环能力

第三层不仅仅是数据分析，而是将数据应用于核心业务算法的优化。例如电池管理、整车控制等智能算法，需要依赖大规模数据进行训练，在云端训练，在车端部署，并持续反馈优化，形成闭环迭代。

4. 开放数据生态的能力

在前三层，数据的使用还主要局限于企业内部，而第四层则是数据对外部生态的赋能。近期，我们看到多个OEM厂商发布了“智驾险”产品，本质上，这类保险是为自动驾驶提供兜底保障。而要实现这种保险，保险公司需要基于OEM的数据运行自己的判责算法，以评估事故责任。在这个过程中，OEM的数据不再仅仅服务于自身业务，而是开始支撑更多外部合作伙伴的创新。

在这四个层级上，智协慧同拥有完整的技术方案。从一开始，我们的产品和技术布局就围绕这四个层级展开，目标是全面满足各层级的数据应用需求。

车端数据库：突破传统车云数据模式

过去，行业普遍认为车只是一个数据源，所有数据必须上传云端，才能进入数据库进行存储和计算。而我们率先提出并实现了在车端直接写入数据库的技术，打破了传统数据处理模式。

那么，车端数据库与云端数据库的区别是什么？

首先，存储寿命是车端数据库面临的首要挑战。在云端，存储寿命并不是关键问题，而在车端，存储设备需要承载大量数据写入，同时寿命受限，不能因频繁写入而损坏存储介质。

其次，CPU 资源的受限。在云端，CPU 资源相对充裕，计算负载上升时，可以通过增加计算节点来扩展性能，因此很少有人关注数据库对 CPU 的消耗。但在车端，CPU 资源几乎是一条红线，计算资源必须被严格控制，以确保系统的稳定运行。

车云计算框架：构建高效计算体系

我们构建的车云一体化计算框架，核心理念借鉴了计算机行业的 Serverless 架构。

在云端，数据计算可以使用 Python、Spark 等工具，但车端环境完全不同，软件运行受限，传统的云端计算框架无法直接适用。因此，我们开发了两个轻量化的计算引擎，让车端也能高效执行计算任务。

同时，我们构建了一套统一的开发环境，类似于低代码平台拖-拉-拽式开发模式。支持主机厂的业务部门只需编写业务逻辑，无需关心计算任务如何在云端或车端运行。我们提供的计算逻辑框架支持跨车端与云端部署，一旦在云端搭载了这套车云一体计算框架，计算任务便可跨车云运行。

这就是我们核心产品的设计理念和技术优势。

数据工具链的进化：赋能业务

服务产品研发的最终目标还是要真正赋能业务。

在传统车联网方案中，数据上传频率通常在六七百个信号，或者更高一点能达到两三千个信号。而我们目前的客户，单车可支持26,000多个高精度信号的采集和存储，并通过车端数据库进行灵活管理和按需上传，而非简单的全量数据同步。

在数据库设计过程中，我们有一个很重大的创新，是在文件格式上。对标对象是全球领先的汽车开发工具链，例如Vector、ETAS等国际品牌。

过去，汽车研发工程师通常使用价值数十万元的Vector数据采集设备，连接车辆进行数据采集，并将数据导出到Vector CANoe等软件进行回放和分析，同时借助MATLAB等工具进行进一步的计算。这些传统工作流主要依赖离线、单机操作，并未考虑到多车协同管理或车云数据链路的不稳定性。

我们在文件格式方面进行了深度优化，不仅对标了Vector的BLF格式，还针对车云协同的需求进行了定制化改进。例如，我们在数据包头（header）部分增加了校验机制，以确保数据在车云传输过程中即便遇到网络波动，也能保证数据的完整性和可用性。

此外，传统车联网在云端合并小文件时，通常需要解包、排序，并基于VIN码和时间戳重组数据，但这一过程面临很多挑战，比如数据回传延迟。

我们创新地采用了一种智能ID索引机制，使得数据在云端合并时无需解包，即可直接按照时间序列和车辆标识（VIN）进行拼接，大幅提升了数据处理效率。

在2023年进一步优化了文件存储结构。对比来看，传统的车联网数据存储通常是零散的小文件，而我们通过大文件封装技术，减少了冗余数据，压缩比更高，节省了大量存储成本。同时，传统方法在几百兆（MB）级别的数据块上进行检索，耗时较长。而我们的大文件格式支持在几百KB级别的数据块上进行索引检索，大幅提升查询效率。

经过几年的技术打磨，客户反馈，采用我们的文件格式后，数据存储成本显著降低，同时数据检索的性能也得到了大幅提升。

伴随服务客户数据上云的过程中，我们逐步建立了一套全新的工具链和开发方法。

我们做了哪些优化？

1.在线数据记录仪（ODR）

过去，在车上安装数据记录设备的成本极高，每台设备动辄几万元，通常只用于实验车辆。而现在，我们的方案将这套能力下沉到所有量产车，使每辆车都能以百元级成本配备在线数据记录仪，实现实时数据采集。

2. 车端计算能力提升

传统计算方法需要先采集数据，再回传至云端进行计算。而如今，我们在每台车上部署了计算引擎，相当于为每辆车配备了一个嵌入式 MATLAB，可直接在车端执行计算。这大幅提升了本地计算效率，减少了数据回传成本。

3. 工具链在线化

过去，很多单机离线的工具和方法必须先导出数据，再分析处理。而现在，我们已经实现了全流程在线化，数据回传后即可直接在云端回放和分析，极大提升了故障排查和优化效率。

这一整套新的开发方法，意味着传统的单机离线工具链，正逐步向云端、在线化、智能化的方向演进。工程师不再受限于实验车、不再需要等待数据回传、不再依赖单机软件，而是能直接在云端和车端协同计算，加速开发效率。

中国智能汽车产业的崛起，催生本土工具链的突破

去年，我参加一个活动时，很多客户都对我们很熟悉。他们说：“我知道你们，以前工程师调试车辆都得在车上拿着笔记本去调试，现在都不下楼了，直接远程就能把工作完成了。” 这个反馈让我们很欣慰，因为这正是我们努力的方向——用更高效的工具链，让工程师从繁琐的手动调试中解放出来。

我本人做了近10年的汽车工具链，过去9年一直在业务端，对行业的痛点感受很深。以前，我和人讨论过：为什么中国没有机会做自己的工具链，只能沿用欧美的方案？

当时的结论是：工具链本质上承载的是产业的最佳实践，而这些实践的沉淀，必须伴随产业的成熟。过去，汽车工业的主导权一直在欧美，中国没有机会沉淀自己的工具链。但现在情况变了——智能汽车产业的加速发展，全球领先的机会首次出现在中国。

这一趋势带来的结果是，我们的工具链已经在灵活采集、远程调试等领域走在前面，让工程师的工作方式发生了质变。我们身处中国，伴随着中国客户成长，接触到的需求比欧美同行更早、更多。因为中国智能汽车产业的发展，站在了行业发展更前沿的位置，推动我们比国外的厂商更快地完成技术演进。

数据协同新模式：让业务与数据团队高效协作

今天在座的更多是云端的客户，所以也想分享一下在云端看到的一些合作机会。我们观察到，几乎所有客户都会遇到一个共性问题：拥有数据的部门和业务部门之间的困境。

通常，数据部门（比如企业的数字化团队）会对业务部门说：“你们把需求告诉我，或者说你们要什么数据，先统计一下吧。”但问题是，业务部门往往并不知道自己真正需要哪些数据，或者未来可能会用到什么数据。同时，很多业务团队也不愿意把自己脑子里的想法和具体的计算逻辑直接告诉数据部门。这样，就形成了一个天然的信息断层。

我们很早就意识到这个问题，并在解决方案中找到了一种更高效的方式：数据部门不需要让业务团队先梳理清楚需求。相反，应该在数据之上搭建一套统一的工具，让这套工具变得足够简单、直观，让业务部门可以直接使用。

我们观察到的一个典型问题是：业务部门过于“强势”地独立管理数据。不用统一的平台，而是自己搭建数据平台，各自维护一套系统。结果就是：

我们的解决方案是什么？

我们帮助客户搭建统一的数据工具，这个工具本身并不复杂。为什么？因为过去大家习惯于用 MySQL，而我们提供的工具可以看作是分布式版本的 MySQL，这样业务部门更容易接受。

当业务部门通过这个工具自主构建业务模型，并消耗数据进行分析时，数据依然集中管理，不会被分散到各个“孤立的台子”里。

随着时间推移，数据的使用模式逐渐显现，我们发现，不同业务部门在数据特征提取上存在共性，比如车辆数据的预处理、特征提取等。通过抽取共性的部分，可以逐步形成真正的数据资产，让数据部门能够进行沉淀和优化。

这种方式并不要求客户一开始就具备完善的数据资产管理体系，而是在实际运营过程中，让数据资产自然生长和积累，最终形成可复用、可共享的智能化数据体系。

数据赋能汽车售后业务创新

在过去两年，我们观察到云端数据分析在售后领域的价值正逐步显现，特别是在深入业务场景方面带来了重要突破。

当前，售后团队面临的最大挑战是什么？

传统的售后体系主要依赖故障码和诊断仪，但现在越来越多的故障并不会触发故障码，比如黑屏、闪屏、无故障码等影响用户体验的问题。

这些情况给售后团队带来了巨大的挑战，尤其是在人车比这一行业关键指标上，传统模式下，售后团队规模与车辆规模的比值可能相差十倍之多，导致售后人力成本居高不下，且难以支撑智能汽车的快速发展。

如何优化这一现状？

我们在与客户合作的过程中，提出了一些新的关键KPI，帮助车企构建更加高效的售后体系：

这些新的指标体系突破了传统售后对故障码的依赖，让车企可以基于真实的车辆使用数据，构建智能化、数据驱动的售后服务能力，从而提高效率、降低成本，并提升用户体验。

在主动巡检和故障拦截方面，我们关注的是那些未被用户投诉或反馈的隐性故障。例如，某些车辆可能出现过黑屏，但用户没有报修，并不代表故障不存在。那么，我们有没有能力在用户感知之前提前发现问题，并做好预案？这就是主动服务的概念。

事实上，这类指标在特斯拉的体系中已经广泛应用。今天，无论是我们的VDM产品，还是华为的VHR，大家都在围绕这些指标进行优化。今天，我们已经在某OEM的量产车型上应用了这套方案。客户之所以选择我们，是因为他们原本在使用我们的 AI 数据底座，后来发现可以基于 AI 数据底座快速搭建新的业务系统。

那么，核心能力是什么呢？

第一，数据基础能力。过去的故障诊断依赖故障码，而现在，我们需要依赖整车的全量数据，通过数据分析快速识别故障，因此 AI 数据底座的能力至关重要。

第二，敏捷开发能力。 许多故障的识别并不需要传统的代码开发流程，而是可以通过在线数据编排，在发现问题的当天就构建相应的故障模型，并立即投入使用。这种在线敏捷开发的能力变得越来越重要。

举一个实际案例：有客户遇到小电瓶频繁亏电的问题，尽管动力电池正常，整车电路检查也未发现异常。我们利用整车高精数据和机器学习分析，发现每次亏电时，座舱 USB 接口都有占用信号。进一步排查后，确认车主长期插在 USB 口的充电宝因反向充电，导致车机频繁启动，最终造成小电瓶亏电。

这是座舱软件的 bug，需等待 OTA 升级修复，短期内无法彻底解决。为此，智协慧同提供了临时解决方案，建立预警机制：当驾驶位检测到无人，且 USB 口仍有设备插入时，系统立即通知客服团队，提醒车主尽快拔除设备，防止小电瓶亏电。

第三，用数据帮助业务部门优化算法。

以我们与某客户的合作为例，第一阶段，我们帮助他们优化了电池升温策略。过去，电池升温的逻辑是基于简单的固定规则，而现在，通过引入更丰富的数据，我们可以动态优化这些规则，提高电池管理的精确度和效率。

到了第二阶段，我们进一步帮助客户优化整车管理，就像特斯拉所做的那样。例如，在车辆运营过程中，我们可以整合多种数据，优化微碰撞识别。微碰撞是后市场事故车维修的一个重要入口，但传统主机厂往往无法第一时间获取相关信息。过去，事故车的报警主要依赖气囊弹出检测，而如今，我们通过智能算法，即使在气囊未弹出的情况下，也能识别出轻微碰撞事件，并通过跨车数据训练优化模型。

此外，我们的系统支持从冷启动到热运行的优化过程。冷启动阶段，即便没有足够的数据，我们也能通过静默采集建立初步模型；而当数据积累到一定量级后，系统可以进入热运行模式，进行高效的实时推理分析。这些能力都是基于我们新的数据架构，帮助客户实现更精细化、智能化的车辆管理。

数据驱动未来：携手行业伙伴共同拓展数据应用

从本质上来看，我们所做的核心工作是构建一套跨车端与云端的数据体系。在此基础上，我们不仅自主探索多个业务场景，同时也与众多合作伙伴一起，在不同的业务领域帮助客户实现创新。

目前，我们已经在国内多个客户的业务场景中落地应用，包括座舱系统、智驾管理、高压控制等多个领域，并积累了丰富的部署经验。我们去年也获得了广汽、一汽、长城等多个主机厂的定点项目。

我们的合作方式非常灵活，可以直接从 AI 数据底座层面切入，与客户共建智能化数据架构；也可以从云端数据管理角度进行协作。此外，在建立合作基础后，我们会进一步拓展至具体的业务场景，例如热管理优化、稳定性分析等，帮助客户探索更广泛的数据应用。

当前，整个行业正处于深度变革期，数据驱动的业务重构已经成为不可逆转的趋势。我们希望能够积极拥抱这一变革，提供更先进的工具，与更多行业伙伴携手，共同推动客户的数字化升级，让智能汽车迈向更深层次的数据应用时代。