云管端一体化软件开发平台——“云梯”

作者：詹辉辉、杜玄、解伟、刘宁

出品：汽车电子与软件

从福泉北路333号到吐鲁番的火焰山山脚下，“云梯”有很多新的故事可以讲。

在格尔木海拔四千多米的昆仑山口，小小的“云梯”盒子与主机厂的兄弟们一道在高原之上前进。去岁黑河冬日里的严寒，没能冻住的除了春天，还有“云梯”蓬勃造梦的勇气。虽说是造梦，实际上已经摸着石头过了好几条河。如何不停留在讲故事、而是实事求是地让梦想照进现实，生动展现云的力量，“云梯”致力其中。

如果说“过河”是对解决方案的理论实践的一种形容，那么河流的源头就是汽车研发所面临的诸多痛点。

“吐鲁番这边，下午三四点钟是晒车的时间，在戈壁上晒到车子达到标准温度，工程师才好上车去测。” 火焰山山脚下的司机之家里，熟悉夏测的老师傅这样说。这个标准温度是什么呢？在日均四十几度的高温预警里，停在酒店停车场的“云梯”实验车里的工业温度计早已晒到罢工，打开车门坐进去，皮座椅烫人。戈壁上穿不得凉鞋，空气中弥漫着石头灼烧的气味。在这样的环境里，标定测试工程师们一呆就是三个月，顶着烈日与高温工作，做六休一，车多人少，人手不够，难免加班。

吐鲁番的山脚下写着一句话，“ 只有借不到的芭蕉扇，没有翻不过的火焰山“。日日在山脚下的公路上往复奔驰的工程师们堪称当代取经人，坚毅果敢一往无前。只是有时也会如大圣一般，被火焰山的高温绊住了脚翻了车。

高温作业测试车翻车现场

“ 高温测试是三高中最舒服的了。“ 夜里十一点天色擦黑，吐鲁番滴下来零星的雨滴，一位主机厂的工程师感叹道。在吐鲁番中彩票一样小概率发生的雨里，他说：“去格尔木做高原测试，带上高压锅，在海拔三四千米的地方成宿成宿的睡不着，头疼，只能连夜从上面下来，到海拔低一点的地方睡个好觉。” “冬天往北边走，电脑要贴上暖宝宝。”

在库木塔格沙漠边上，“云梯”盒子和工程师们一道在高温下保持持续工作，那之后又去了昆仑山口，在标定测试工作中，致力帮助工程师提升工作效率，降低工作难度。

“云梯”是什么？

“云梯”平台的使命是提供一个协同、开放、专业的汽车软件研发工具一站式平台，成为工程师得心应手的助手。该平台是结合智能汽车软件开发、标定、验证、测试中的实际痛点问题，围绕一线工程师日程工作需求量身打造的一款云管端一体化开放工具平台。

由 “两端一通道，三库七系统” 构成，以支持 “远程、协同、知识管理” 三个核心服务。“云梯”通过web界面方式，提供一个多方协作平台（甚至包括外包司机），在该平台上不仅能够动态管理授权不同的软件开发参与方看到同一个项目空间下的各种数据，并且能够随时、随地组织多方实时分析实车或者设备上的数据，宛若多人到现场分析问题。回传到云的数据基于“云梯”知识管理服务，自动进行数据质量分析、解析、评估，并输出简单、直观的结果，更进一步的基于专家推荐模型，推荐新的标定参数，实现知识在组织内的迭代、存储、流转、复用。

“云梯“平台云管端架构

远程

说回“过河”，“云梯”蹚过的一条河可谓是千舟竞渡——远程，是可以一定程度上提升工程师工作效率节省工作成本的解决方案。“ 你们的方案和向日葵之类的远程app有什么不同？”这是初见时大概率会被问到的问题。对此， “云梯”有如下解答：

把有限的车辆数据回传到云端进行分析的远程工具，是不趁手的。其一，实时性不够。数据在云端落盘后，进行分析，再进行参数或者软件更新，其延时基本会以分钟甚至小时计，而对于需要快速验证看到结果，并迭代进行下一次测试的工程开发来说太慢了。如果考虑到动力域，底盘域，ADAS域一些实时性要求非常高的测试项来说（ms级），特别是这些域的功能还涉及都安全，则该方案完全不适用。其二，带宽不够。汽车研发协作中，需要观察大量汽车内的数据（特别是涉及到ADAS领域时更是这样），还需要能够实时动态变更配置。带宽永远是有限的，无论是现在的5G还是未来的什么移动通讯技术，面对海量的数据采集和数据实时观察，把数据从车端经过云端再送到人的面前是一个巨大的挑战。

所以“云梯”给出的策略，是把研发人员的眼和手延长到车内，车内系统提供必要的研发手段和工具。“云梯”平台在云端和车端部署了一套基于web远程访问车辆及设备的服务。车端的“云梯“盒子提供接入车辆接口，集成INCA等标定测试软件，并接入云端后台，接收云端指令，回传数据。“云梯”后台提供远程访问车辆界面，并提供基础设备管理，数据管理等服务。

基于多径聚合的高速、稳定的分布式IoT管道，实现了移动、联调、电信及卫通四网合一，及全国四大区域的就近接入，解决了即使在三高测试中，极不稳定的网络环境难题, 提升用户使用体验。

2022年疫情期间， 黑河的冬测任务照常进行，远在无锡的工程师通过 “云梯” 的远程功能顺利完成了部分工作， “非常顺滑，和实际坐在车里测试标定的体验完全一样。”

 全国全时空流畅触达车辆和设备

“云梯” 提供的是一整套解决方案，可以对项目权限进行管理，致力保护客户数据安全。远程桌面只是 “云梯” 的一个功能模块，还集成了更多功能。“云梯” 的开发人员如是说。

多方协同

“ 我们习惯用企业办公软件开会，能不能更方便一点？” “有的时候现场出现一个小问题，可能半天就能解决，但是还需要花费两天往返跑到现场去沟通，要是能够线上把问题看明白就好了。”“有的问题不是问一个人能解决的，需要多问几个人。” 标定测试工程师们如是说。

针对这一系列问题，“云梯”做出以下解答：

“云梯”平台的协同是全方位，多角色的智能协同。除了公司内部不同地域，不同团队，以及公司外部的供应商，客户，合作伙伴等智能汽车软件开发的关键关联方外（工程师间协同）。“云梯”平台还会重点考虑当前各方急需的工程师和测试司机协同，以及面向未来AI智能的人机协同。但是共同的目标都是围绕提高软件工程师的开发测试效率。

 全方位多角色协同

工程师间协同，除了“云梯”平台的基础功能，如利用灵活的权限管理，对内对外开放项目空间，实现实时同步项目信息和数据外。利用“云梯”平台强大的远程能力，并集成了多个第三方企业OA系统软件，如钉钉，Teams等等，支持一键导入，发起线上实时问题分析会议，多方可以在线看到同一辆目标车辆上的软件运行情况或者问题，快速形成临时虚拟现场团队，分析关键依赖项或者路径，高效解决软件问题。该功能在智能汽车“软件功能上移”的趋势下，正在越来越多地被用到，在疫情远程办公期间也为众多一线工程师所推荐和青睐，为大家节省了大量的人力、时间及差率成本。

和司机协同，主要是实现对司机执行测试用例质量的监测，提高测试数据质量，便于工程师进行数据及问题分析。云端提供测试用例开发编辑模块，在开发每个测试用例时，会导入对应的司机/车辆行为评估算法，及数据采集截取算法（数据打点）。该测试用例和评估算法会以测试任务的方式打包下发到车端“云梯”盒子。司机通过在手机端APP输入测试任务验证码获取当天测试任务信息（APP与 “云梯” 盒子通讯）。开始测试后， “云梯” 盒子会通过手机APP实时语音播报司机所需要做的测试动作，同时会实时收集车辆数据及外置传感器数据（如多摄像头，GPS等），并在边缘引擎中运行评估算法，反馈执行成功与否的结果，并根据数据采集截取算法智能采取目标数据，实现时间同步后，上传到云端或者缓存在本地。因为该协同需求对实时性要求不高， “云梯” 盒子可以在离线的情况下，只要接收了测试任务，就可以完成所有测试任务，在网络恢复后，回传测试数据及结果到 “云梯” 后台。数据截取打点设置可以支持云端信号配置，及司机手动/语音打点，并自定义时长。该功能在道路测试，如ADAS道路标定测试，动力总成的安全、排放测试，失效场景复现等方面得到了应用。

人机协同，即实现AI加持的工程师高效工作。“云梯”平台希望能够利用人工智能（AI）的崛起，开创全新的人工智能下的创新协作范式。如下图，人还是协作的中心，而人工智能是人的副驾驶员（Co-pilot），副驾驶员协助人类驾驶员完成相应的工作。

 AI加持下的人机协同

知识管理

在前面多方协同的基础上，“云梯”进一步开发了知识管理的功能模块。

基于结对开发理念的专家模型，及大数据分析的数字化知识管理体系。可以支持云端可灵活设置，车端可边缘执行的可存储、迭代、流转、复用的知识对象，从而形成组织记忆。这样的好处是专家经验被数字化后，能够在组织内部流动，让更多的 “新手” 迅速成长为专家，规模化、自动化复用，大大提高效率。同时更能够解决行业普遍存在的，不同团队人员之间的数据孤岛，甚至部分人员离职后，该部分经验知识完全流失，没人可以接的窘境，形成良性的可持续发展。

所谓的结对知识对象开发，即让标定专家和软件工程师结对，测试工程师和大数据专家结对等等。因为不同的团队成员有不同的能力，“云梯”平台充分发挥不同角色的优势，比如让软件工程师把标定专家针对某一项标定量的评估过程以算法的形式开发出来，并对该算法进行三层抽象 – 原子服务层，业务层，应用层（前两层由开发者提供，应用层由客户基于前两层自主开发）。测试工程师能够基于业务层算法，能够快速开发出适用于新测试项目的评估算法，并在后续项目中进行迭代复用。该算法在云端开发后，能够和测试任务一起打包下发到蓝天盒子的边缘计算引擎中，在边缘侧进行执行（可以支持Simlink开发的既有算法）。计算的结果和测量数据会共同打包上传到“云梯”后台。测试标定完成后，可以一键生成直观的测试报告，通过红黄绿不同颜色告知工程师需要关注的参数，并进行进一步分析。

数据上传到云端后，“云梯”平台会提供一套基础数据管理服务，除了常用的如数据权限、上传、下载、不同数据之间关联，追溯外，还根据不同的域提供一些数据质量批量检查，转换服务。如垃圾数据清理，CAN的raw data到物理值，动力域的DCM / MF4到CSV，视频流到图片的转换，ROS Rosbag转换为MF4或者博世AOS的bytesoup格式等等。基于这些数据及数据标签（来自知识对象），进行数据分析，提供标定参数推荐，对比，统计服务。在标定参数推荐中，“云梯”平台会继续采用结对的方法引入专家评审系统，通过专家经验改进推荐模型。在云端数据及专家语料库积累到一定的量的阶段，“云梯”平台会尝试进一步采用通用AI大模型进行针对性训练，以更加多维的方式和工程师进行沟通协作，支持工程师更加高效地完成工作。

“以往培训一个新人上手的时间，现在只需要一半。”该功能在博世底盘产品开发上已经全面铺开使用，并取得了非常好的反馈效果。

软件定义汽车浪潮下的软件开发

随着下一代整车EEA的持续演进，公众普遍认可SDV软件定义汽车这一趋势。这一趋势带来最大的变化就是软硬分离，软件复杂度的几何级数上升，及软件在硬件量产后的持续迭代更新。各主机厂和零部件供应商纷纷做出了技术栈，人才库及组织架构上的调整以迎接这一巨变。但是依然会常常看到业内投入巨大，但是软件乃至整车发布延期甚至失败的案例。其中最主要的一个原因是软件复杂度的骤升，叠加汽车软件本身的多维复杂度属性，业内在短期内还没有找到或者掌握一个能够很好驾驭其过程的方法和工具。

从技术角度看，智能汽车与其说是“装了四个轮子的手机”，其实更像一个移动的小型“ICT机架”，上面部署有多个算力强大的域控或者SOC，及高速的数据交换网络。其软件的复杂度，开发方式，生态（特别是座舱域）也越来越向ICT行业看齐。业内近年做了一些很多有益的尝试，比如引进ICT领域大规模软件开发的方法论，如DevOps，CICD，Everything as code，极限敏捷等，与传统的ASPICE，V-Model，功能安全等经典流程产生碰撞，引起了广泛的讨论。ICT行业积累20余年成熟的大规模软件开发的方法论，能够给智能汽车软件开发提供一些非常好的经验和参考。但是另外一方面，汽车软件和ICT领域软件还是有些本质不同，除了大家常常提到的安全属性外，在软件开发特征上，还会体现在如下三个方面：

首先，智能汽车的软件开发，是围绕汽车这一个高速移动的设备进行的，需要适应变化多样的工作场景。除了众所周知的传统动力域我们需要根据不同的工况，如高海拔，高寒，高温，进行标定外。在自动驾驶域即使累计训练了数以万计的里程数，但是仍然非常苦恼于常常见于媒体的“corner case”失效报道。在座舱领域更是有多样性层出不穷，个性化的应用场景。这个在ICT领域的软件开发是较少甚至没有的。这个特性需要智能软件的开发测试，能够随时，随地、便捷、高效地感知和触达车辆或者设备实体，快速地把我们的最新软件或者标定参数部署到目标车辆或者设备上，以验证新功能。而开发阶段的车辆或者设备是极其有限和宝贵的，常常需要排队使用或者异地运输。资源的紧缺，开发测试环境的不符合要求，会严重导致项目的延期交互。

其次，汽车是一个高度多方高效协同的产物。传统汽车的ECU数量在150个左右，智能汽车的中央集成化架构目标之一就是尽可能地合并减少这些ECU。这些ECU虽然没有了，但是绝大部分功能还是得留下。传统汽车不同的ECU通过事前定义好的通讯矩阵协同工作，各家供应商基于这套工作方式工作了几十年，分开开发、测试、发布，职责清晰，相互独立，问题追溯容易。智能汽车改变了这一切！越来越多的供应商需要基于同一个硬件开发，比如我们看到越来越多的车身控制功能，动力底盘功能上移到区域控制器或者车载中央大脑上。大家之前自己独立基于自家硬件进行软件适配标定的工作方式，变成了需要在第三方硬件，依赖第三方底层软件的成熟度，按照一定的步骤和时间节点来集成和标定。大家彼此分工的边界更加模糊，相互依赖更强，软件模块的运行环境也更加复杂。据统计，在软硬分离的趋势下，在座舱或者智驾域控上，需要20家以上的软件及工具链供应商参与软件开发及集成的情况非常常见。一旦出现问题，分析链更长，牵涉的关联方更多，需要收集的数据更多，导致推诿扯皮的情况屡见不鲜，效率极其低下，浪费多方时间，导致所有的参与方怨声载道（即使同一家OEM/软件公司内部，因为不同的团队，分布在不同的地点，也会常常出现这情况）。相对来说，在ICT领域因为主要头部玩家的软件掌控力巨大，硬件设备非常标准，出现软件发布延期或者失败的情况少的多。这个特性要求智能汽车的软件开发需要一个共享的工作平台，该平台不仅能够实时访问设备或者车辆，它还能够让所有的软件开发参与方，包括内部，外部供应商、客户、合作伙伴能够都看到设备或者车辆上的实际情况，根据其个人所需截取车身数据或者失效数据，快速便捷地共享给他人，高效地分析，流转问题，提高开发效率。

再次，除了上述的多域控或者SOC加车内高速交换网络外，智能汽车还是一是装了众多传感器及执行器的设备，其能够采集的信息并提供终端用户直观体验和反馈的途径和方法比手机会多至少一个数量级以上，比ICT机架更是多得多（本质上终端消费者不会直接接触到ICT机架）。用户的绝大多数重要用户体验来自于这些传感器和执行器。智能汽车的开发本质是让这些传感器和执行器根据不同的车型，不同的工况，不同的用户达到最高效，符合用户预期的输出。为了达成这一目的，软件开发测试过程中，需要执行大量测试用例，收集大量测试数据，评估数据，修正算法/参数，再次执行测试，直到符合要求为止。期间会涉及大量的人力，而在软件人才奇缺，特别是跨行业的资深专家更是凤毛麟角的汽车行业来说，一直都是各家面临最为棘手的问题之一。专业人才及知识储备的不足，导致项目技术债务不断飙升，延期甚至失败。这个特性要求智能汽车的开发，需要结合当前的客观实际情况，高效地利用现有人才，并进一步的让人才的专业经验和知识可以在组织内部高效地存储，迭代，流转，复用。快速提供项目执行质量和效率。

基于上述三个特性，在引入吸收ICT行业的大规模软件开发方法论的同时，需要因地制宜，结合具体实际场景予以改造落地。在落地过程中，更需要结合智能汽车的本身属性，使用甚至开发一些新工具，切实地帮助一线工程师快速迭代开发智能汽车软件。

“云梯”开发团队与博世内部多个事业部合作，进行了四年智能汽车软件开发最佳实践经验。并以此实践为基础形成的软件定义汽车研发支撑平台—— “云梯” 。

 “云梯” 平台是一个开放平台，面向未来，我们希望能够后续不仅仅集成现有工具链，如EATB，MDA、vECU Builder、ASCOM、AOS等数据分析、虚拟仿真软件，以及接入RALO、INCA，vGETK、MDH等车端产品，我们期望能够集成更多第三方开发工具链及硬件设备，并融入到CICD工具链，实现工程师在“云梯”平台上随时、随地一站式完成所有软件开发工作。

文章转载自公众号：汽车电子与软件