智驾「完整数据闭环」受困，谁能蹚出一条最佳路线？

城市NOA，标志着自动驾驶商业化的一座里程碑，也意味着智能汽车下半场的开端。

自2023年上海车展以来，有关城市NOA的路线之争逐渐明晰，“重感知＋轻地图”、借助纯感知和融合感知路线、以及BEV+Transformer模型的智能驾驶解决方案，成为业界共识。

如今，迈向商业化落地竞争，如何利用高效的算力支撑、完善的算法模型、大量有效的数据形成闭环，是城市NOA大规模量产的关键。

在博世看来，能够支撑智能驾驶全栈解决方案的完整数据闭环，由“软件开发数据闭环”和“基于AI数据闭环”两个部分组成。

一方面，基于AI驱动实现AI数据闭环，自动驾驶科技公司大秀肌肉。例如，毫末智行、百度等智能驾驶解决方案供应商，打造出了各自的数据闭环解决方案，在数据采集、数据筛选、算法模型迭代等环节发力，致力于实现低成本、大规模、高质量、高效率的数据闭环。

不过，如何利用自动化手段高效完成包括trigger、标注在内的数据采集工作，并且确保数据是可用于模型优化的“正确”数据，是AI数据闭环的难点之一。

另一方面，验证驱动（测试驱动）的软件开发数据闭环，以易特驰等传统供应商擅长，其挑战来自于对海量数据的获取、分级存储及管理。

事实上，在验证驱动模式下，实现软件算法及模式开发、软件生产及释放、完整车辆状态数据采集等，既契合“软件定义汽车”趋势下汽车功能的更新，也有助于实现整车数据闭环。

毕竟，软件定义汽车，汽车开发贯穿整个汽车生命周期。相比传统汽车研发在“量产”后走向终点，如何在硬件“量产”后持续汽车软件的研发和交付，是新汽车亟需解决的一大难题。

面向软件定义汽车和数据闭环的诸多痛点，全球领先的嵌入式软件开发与汽车信息安全解决方案和服务提供商易特驰，推出了软件定义汽车研发支撑平台“云梯平台”。

“从代码的编译开始，云梯平台可实时触达到车内采集信号、采集数据放到云端存储，并作为数据原料上传到云端进行分析、修改代码，以此打通车端所有节点的数据，目前第一阶段的云梯平台已经实现直接触达车端。”易特驰高级系统架构师杜玄介绍称。

软件定义汽车，卡在哪了？

诚然，软件定义汽车，即在模块化和通用化硬件平台的支撑下，软件深度参与汽车的定义、开发和验证流程，通过不断优化客户体验，持续创造价值。

从用户角度来看，标准化的传统汽车，无法满足千人千面的个性化需求。而软件定义汽车带来了深刻的变化，越来越多的汽车功能通过软件更新迭代实现，常开常新的智能汽车，具备丰富的自选应用、OTA更新软件、无需升级硬件、愈加舒适的驾乘环境等优势。

于OEM而言，立足用户的驾乘体验，在汽车软件层面建立起品牌的差异化竞争优势，是打破内卷赢取更多市场份额的策略之一；此外，软件定义汽车趋势下，更短的汽车开发周期、SOP后快速的迭代更新、减少的ECU软件升级周期等，也意味着成本的下降。

不过，随着智能网联汽车的发展和电子电气架构的演变，整车电子电气架构由分布式架构往往集中式架构转变，对汽车软件开发提出了更多挑战。

首先，域集中化或跨域架构下，汽车功能上移，如何做功能迭代是关键。目前，业界的普遍做法是通过软硬、软软解耦，即为硬件黑盒子构建通用的软件框架，对接口设备做抽象化处理，兼容不同接口，或通过软件架构内部模块的解耦，对软件模块接口进行标准化处理。

据悉，易特驰的云梯平台解决方案，通过中间件，打通经典分布式ECU体系或和现代域集中体系，建立异构分布的支撑机制，灵活完成对汽车信号观察、状态控制，进而实现汽车功能的快速迭代。

其次，汽车软件开发复杂度更高，多方参与面临协作难题，如何实现对汽车实体的感知和触达是汽车研发协作必须解决的问题。

过去，在人工标定时代，主要依靠工程师们用笔记本电脑记录数据、调参，不仅费时费力，还难以调整至最优参数。

再过渡至传统汽车研发工具链时代，不少工具还停留在绑定window平台，用C#开发人机交互界面，并且只支撑单机或传统的C/S结构的原始状态，与数字化时代的步伐严重脱节。

“理想的软件定义汽车研发平台，一定是围绕车辆对象为中心的；无论是在实验室里车辆测试台架，还是试验场地的验证车辆，还是三高测试路上的标定车辆，或者是最终用户手里的量产车辆，无论何种类、什么时间、在什么地点，汽车研发支撑平台都有能力触达车辆。”杜玄表示。

而汽车研发协作过程，需要观察大量汽车内的数据，常常要面对海量数据、高实时性以及多方协作的问题。尽管可依托云端作为信息存储和中转，但仍需要高速和稳定的网络，支撑协作人群到云端再到车端的通讯信道。尤其是在汽车验证状态或车队场景，对数据处理能力和实时性要求更高。

事实上，无论是依靠5G还有未来的移动通讯技术，面向智能汽车海量的数据采集和数据实时观察，将数据从车端经过云端再送到工程师面前，场景带宽远远不够，且基于汽车的移动性及移动网络的易干扰性，难以得到持续高速且稳定的通信信道，这也是软件开发贯穿汽车全生命周期的痛点之一。

在杜玄看来，标定知识对象与大语言模型相结合，是标定领域知识处理的较优解决方案。而通过知识的一点一滴积累和进化，构建形成的标定知识库，将助力云梯平台解决汽车研发协作痛点。

数据驱动＋车云一体，云梯平台实现研发闭环

云是汽车产业的新生产力，车云一体的数据驱动模式将成为汽车产业竞争的关键。

随着汽车芯片的进一步发展，具备更大的算力、更丰富的算子或成可能，而利用云原生平台开发知识对象，依托大模型训练汽车软件开发工具，实现车云一体的自进化闭环模式，是易特驰云梯平台的追求目标。

不难发现，易特驰瞄准的正是OEM汽车开发过程对云原生的知识管理和数据驱动的痛点需求。

毕竟，作为全球最早开始在新车上部署车端-云端数据采集、传输、分析及训练以及发现功能故障的公司，特斯拉尝到了影子模式的甜头。

通过对真实场景中的车辆操控与运行进行模拟测试，再对比分析两者的运行结果，并清洗和标注形成数据集，以训练算法模型并更新部署至车辆，特斯拉的影子模式可以完成自动驾驶系统的循环验证与迭代升级。

但并非所有车企都能成为特斯拉。一方面，大部分车企若自建私有云，或缺乏全局考虑，易产生数据孤岛与业务断层，高昂的成本与收获难成正比。因此，不愿交出“灵魂”的OEM，对云服务的需求更倾向于“授之以渔”。

从汽车研发角度出发，易特驰正在打破OEM的僵局。

据了解，传统汽车研发有成熟的理论模型即V模型，这一基于量产为研发终点而建立的过程模型，为传统的汽车制造提供了很好的面向终点的过程约束，但面向新汽车功能需求的变更会带来非常昂贵的研发代价。

而互联网生态流行的DevOps研发模型，强调使用敏捷的方法提供更快的产品交付的速率，面向计算机环境堪称现今“最理想的数字生产环境”。不过，汽车是复杂的软硬件结合的混合体，“硬件”属性导致其验证成本会成指数级的增加，DevOps的循环速率将被严重拖慢。

对于软件定义汽车新研发场景，V模型与DevOps各有优点。抓住软件定义汽车的“测试驱动”核心，易特驰提出“两套系统”理论模型，一套面向最终产品功能的目标系统，一套面向产品支持运作的支撑系统，即可满足软件定义汽车的时空需求。

“汽车研发支撑工具将成为汽车产品的一部分，汽车产品内部将同时运行两个系统，一个是生产系统（执行驾驶功能的部分），另一个是研发支撑系统，两者互相依靠、互相转化。”杜玄向高工智能汽车介绍到。

而易特驰云梯平台专注汽车研发支撑系统，支撑极限汽车研发、支撑知识智能为核心、支撑云原生物联协作，可打通汽车研发的全部垂直领域，实现数据驱动＋车云一体的研发闭环，一定程度上也打消了车企对“失去灵魂”的顾虑。

不过，基于前述软件开发痛点，哪怕是拥有29年软件经验积淀的易特驰，要搭建起这套云梯平台也并不轻松。

杜玄表示，要彻底打通云、管、端，需要完成信息工具、对象工具、知识工具、数据通道、IOT通道、边际服务适配器、边际知识引擎的搭建。

据了解，2023年7月1日，易特驰发布了云梯平台beta版，开始系统试运行，第一阶段功能支持整车30%目标功能、70%开发支撑。

可以说，云梯平台的快速推进，离不开易特驰过往的业务积累。

依托完备的软件定义汽车解决方案，易特驰的业务包括六大板块：软件开发解决方案（DEV）、车用基础软件（VOS）、车辆云端服务（VCS）、网络安全（SEC）、数据采集和处理（DAP）和端到端解决方案（E2E）。

值得一提的是，“端到端解决方案（E2E）”更从整车操作系统的宏观视角整合了易特驰所有智能汽车软件，包括AUTOSAR AP/CP、信息安全组件等，可为客户提供一套融合FOTA和远程诊断、互联路测和远程标定、灵活数据采集的整体工具链和一键式解决方案。

其次，作为博世的全资子公司，借助其智能驾驶等汽车事业部对云梯平台的先行试用和反馈，易特驰可高效打造更好用、易用的工具链，这也是背靠博世的优势之一。

有关云梯平台的未来规划，杜玄表示易特驰将继续完善云梯平台，以实现100%面向最终产品功能的目标系统，100%面向产品支持运作的支撑系统；另一方面，将从知识管理方面，通过搭建专家知识库、提供领域基础算法库，搭建知识持续积累和改进系统，并引入大模型人工智能，应对数据持续迭代带来的潜在挑战。