城市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%面向产品支持运作的支撑系统 ；另一方面，将从知识管理方面，通过搭建专家知识库、提供领域基础算法库，搭建知识持续积累和改进系统，并引入大模型人工智能，应对数据持续迭代带来的潜在挑战。