作者：詹辉辉、杜玄、解伟、刘宁
出品：汽车电子与软件
从福泉北路333号到吐鲁番的火焰山山脚下，“云梯”有很多新的故事可以讲。
在格尔木海拔四千多米的昆仑山口，小小的“云梯”盒子与主机厂的兄弟们一道在高原之上前进。去岁黑河冬日里的严寒，没能冻住的除了春天，还有“云梯”蓬勃造梦的勇气。虽说是造梦，实际上已经摸着石头过了好几条河。如何不停留在讲故事、而是实事求是地让梦想照进现实，生动展现云的力量，“云梯”致力其中。
如果说“过河”是对解决方案的理论实践的一种形容，那么河流的源头就是汽车研发所面临的诸多痛点。
高温作业测试车翻车现场
“ 高温测试是三高中最舒服的了。“ 夜里十一点天色擦黑，吐鲁番滴下来零星的雨滴，一位主机厂的工程师感叹道。在吐鲁番中彩票一样小概率发生的雨里，他说：“去格尔木做高原测试，带上高压锅，在海拔三四千米的地方成宿成宿的睡不着，头疼，只能连夜从上面下来，到海拔低一点的地方睡个好觉。” “冬天往北边走，电脑要贴上暖宝宝。”
由 “两端一通道，三库七系统” 构成，以支持 “远程、协同、知识管理” 三个核心服务。“云梯”通过web界面方式，提供一个多方协作平台（甚至包括外包司机），在该平台上不仅能够动态管理授权不同的软件开发参与方看到同一个项目空间下的各种数据，并且能够随时、随地组织多方实时分析实车或者设备上的数据，宛若多人到现场分析问题。回传到云的数据基于“云梯”知识管理服务，自动进行数据质量分析、解析、评估，并输出简单、直观的结果，更进一步的基于专家推荐模型，推荐新的标定参数，实现知识在组织内的迭代、存储、流转、复用。
把有限的车辆数据回传到云端进行分析的远程工具，是不趁手的。其一，实时性不够。数据在云端落盘后，进行分析，再进行参数或者软件更新，其延时基本会以分钟甚至小时计，而对于需要快速验证看到结果，并迭代进行下一次测试的工程开发来说太慢了。如果考虑到动力域，底盘域，ADAS域一些实时性要求非常高的测试项来说（ms级），特别是这些域的功能还涉及都安全，则该方案完全不适用。其二，带宽不够。汽车研发协作中，需要观察大量汽车内的数据（特别是涉及到ADAS领域时更是这样），还需要能够实时动态变更配置。带宽永远是有限的，无论是现在的5G还是未来的什么移动通讯技术，面对海量的数据采集和数据实时观察，把数据从车端经过云端再送到人的面前是一个巨大的挑战。
所以“云梯”给出的策略，是把研发人员的眼和手延长到车内，车内系统提供必要的研发手段和工具。“云梯”平台在云端和车端部署了一套基于web远程访问车辆及设备的服务。车端的“云梯“盒子提供接入车辆接口，集成INCA等标定测试软件，并接入云端后台，接收云端指令，回传数据。“云梯”后台提供远程访问车辆界面，并提供基础设备管理，数据管理等服务。
基于多径聚合的高速、稳定的分布式IoT管道，实现了移动、联调、电信及卫通四网合一，及全国四大区域的就近接入，解决了即使在三高测试中，极不稳定的网络环境难题, 提升用户使用体验。
全国全时空流畅触达车辆和设备
“云梯”平台的协同是全方位，多角色的智能协同。除了公司内部不同地域，不同团队，以及公司外部的供应商，客户，合作伙伴等智能汽车软件开发的关键关联方外（工程师间协同）。“云梯”平台还会重点考虑当前各方急需的工程师和测试司机协同，以及面向未来AI智能的人机协同。但是共同的目标都是围绕提高软件工程师的开发测试效率。
和司机协同，主要是实现对司机执行测试用例质量的监测，提高测试数据质量，便于工程师进行数据及问题分析。云端提供测试用例开发编辑模块，在开发每个测试用例时，会导入对应的司机/车辆行为评估算法，及数据采集截取算法（数据打点）。该测试用例和评估算法会以测试任务的方式打包下发到车端“云梯”盒子。司机通过在手机端APP输入测试任务验证码获取当天测试任务信息（APP与 “云梯” 盒子通讯）。开始测试后， “云梯” 盒子会通过手机APP实时语音播报司机所需要做的测试动作，同时会实时收集车辆数据及外置传感器数据（如多摄像头，GPS等），并在边缘引擎中运行评估算法，反馈执行成功与否的结果，并根据数据采集截取算法智能采取目标数据，实现时间同步后，上传到云端或者缓存在本地。因为该协同需求对实时性要求不高， “云梯” 盒子可以在离线的情况下，只要接收了测试任务，就可以完成所有测试任务，在网络恢复后，回传测试数据及结果到 “云梯” 后台。数据截取打点设置可以支持云端信号配置，及司机手动/语音打点，并自定义时长。该功能在道路测试，如ADAS道路标定测试，动力总成的安全、排放测试，失效场景复现等方面得到了应用。
所谓的结对知识对象开发，即让标定专家和软件工程师结对，测试工程师和大数据专家结对等等。因为不同的团队成员有不同的能力，“云梯”平台充分发挥不同角色的优势，比如让软件工程师把标定专家针对某一项标定量的评估过程以算法的形式开发出来，并对该算法进行三层抽象 – 原子服务层，业务层，应用层（前两层由开发者提供，应用层由客户基于前两层自主开发）。测试工程师能够基于业务层算法，能够快速开发出适用于新测试项目的评估算法，并在后续项目中进行迭代复用。该算法在云端开发后，能够和测试任务一起打包下发到蓝天盒子的边缘计算引擎中，在边缘侧进行执行（可以支持Simlink开发的既有算法）。计算的结果和测量数据会共同打包上传到“云梯”后台。测试标定完成后，可以一键生成直观的测试报告，通过红黄绿不同颜色告知工程师需要关注的参数，并进行进一步分析。
数据上传到云端后，“云梯”平台会提供一套基础数据管理服务，除了常用的如数据权限、上传、下载、不同数据之间关联，追溯外，还根据不同的域提供一些数据质量批量检查，转换服务。如垃圾数据清理，CAN的raw data到物理值，动力域的DCM / MF4到CSV，视频流到图片的转换，ROS Rosbag转换为MF4或者博世AOS的bytesoup格式等等。基于这些数据及数据标签（来自知识对象），进行数据分析，提供标定参数推荐，对比，统计服务。在标定参数推荐中，“云梯”平台会继续采用结对的方法引入专家评审系统，通过专家经验改进推荐模型。在云端数据及专家语料库积累到一定的量的阶段，“云梯”平台会尝试进一步采用通用AI大模型进行针对性训练，以更加多维的方式和工程师进行沟通协作，支持工程师更加高效地完成工作。
首先，智能汽车的软件开发，是围绕汽车这一个高速移动的设备进行的，需要适应变化多样的工作场景。除了众所周知的传统动力域我们需要根据不同的工况，如高海拔，高寒，高温，进行标定外。在自动驾驶域即使累计训练了数以万计的里程数，但是仍然非常苦恼于常常见于媒体的“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工具链，实现工程师在“云梯”平台上随时、随地一站式完成所有软件开发工作。
