《车云一体技术规范1.0》

AUTOSEMO车云一体工作组是面向智能化汽车构建通用的车云一体化的SOA软件架构，积极推动设计规范以及相关技术标准。组长单位是东软睿驰，副组长单位是广汽研究院和中汽创智，共有23家参与单位。车云一体技术规范发展目标是基于SOA设计思想，构建横向-跨整车各域、纵向-跨车云的软件参考架构、设计规范与服务化标准接口。车云一体技术规范是聚焦行业内较新的技术进行首次梳理，形成研究成果供行业参考。

01. 车云一体行业发展趋势和价值应用

1.1 车云一体技术发展趋势

汽车E/E架构通过整合汽车内各类传感器、处理器、线束连接、电子电气分配系统和软硬件生成的总布置方案，实现整车的功能、计算、运行及能量的分配。传统汽车使用由上百个ECU组成的分布式E/E架构，OEM定义对各ECU的功能需求，由不同供应商负责最终功能实现。这种架构导致大量功能控制逻辑在子节点ECU内部完成，传感器、执行器信号被掩埋在分布网络下，仅通过在局部网络的ECU部署基于服务的通讯，无法实现对整车硬件能力的充分展示。且考虑到基于SOA软件平台，未来SOP后的车型也需具备硬件冗余能力以应对OTA软件升级，上百个ECU的冗余设计将极大增加成本支出，也导致跨域功能OTA的实现将涉及数量众多的ECU。

随着车载芯片算力的提升和高带宽、低时延车载以太网通讯技术的落地，汽车E/E架构已从分布式演进至域集中(Domain Centralized),并向整车集中+区域(Vehicle Computer & Zonal)、整车集中(Vehicle Centralized)不断进化。在高集成度的EE架构下，域控制器将承担整车主要逻辑，而执行器、传感器将成为纯粹的执行机构，执行控制命令或是提供环境感知数据。

图-整车EE架构各阶段定义(Bosch)

同时，新型E/E架构下的通讯方式也从传统CAN信号传输向高速以太网通讯方式进行演进，基于SOA设计思想的服务化通讯协议在汽车领域的应用成为了新的技术趋势，在汽车智能场景化应用的市场需求日益旺盛的时代，基于SOA的汽车软件架构可以更快速地进行支撑。

SOA (Service Oriented Architecture),即面向服务的架构。SOA将车端能力划分为服务，并按照整车的原子能力将对应服务拆分为颗粒度更小的接口。各服务组件的接口进行标准化封装，可通过既定协议互相访问、扩展组合；其核心要素包括松耦合、标准化定义、软件复用等。SOA使应用层功能能够在不同车型上复用，且能够基于标准化接口快速响应用户新的功能需求。

SOA不仅解决了整车能力的跨域融合，也实现了车云之间服务化通信的能力，打破物理的界限，通过云端协同计算和生态能力引入，提升整车智能化的能力，支撑OEM构建车云一体化的软件平台。

1.2 车云一体行业发展情况与生态规划

广汽集团是业内首个提出汽车数字镜像云、车云一体化概念的OEM企业，并率先推出车云一体化的星灵电子电器架构。星灵架构主要由三个核心计算机构成：中央运算机、智驾计算机、信息娱乐计算机，并由区域控制器进行“管理”，再借助汽车数字镜像云、高速以太网和5G等技术，形成车云一体化集中计算能力。广汽研究院作为AUTOSEMO成员单位深度参与相关技术规范和标准，作为车云一体工作组的主要牵头单位积极牵头参与协会工作，并与东软睿驰一同开展智能场景编排相关的技术规范与标准定义。

东软睿驰（上海）汽车技术有限公司作为国内SDV领域的领军企业，在汽车基础软件、自动驾驶、车云一体、大数据等领域为OEM提供先进的产品与技术服务，支撑OEM构建软件服务生态，提升车型和品牌竞争力。

东软睿驰车云一体平台产品是自主研发的面向下一代新型E/E架构的智能化软件产品，基于SOA设计思想构建车云协同的智能汽车数字底座，为OEM提供全栈式SDV产品与服务。

车云一体平台产品主要由车云一体工具平台、车云一体核心计算平台、车云一体服务平台三个核心平台构成。

车云一体工具平台：面向OEM提供基于SOA服务设计和开发的一站式工具平台，包括服务开发、场景服务编排、仿真验证、大数据分析等功能，并支持第三方主流开发工具的集成，方便OEM按照标准的SOA幵发流程进行协同作业，提升开发效率和软件质量，降低开发难度和开发成本。

车云一体核心计算平台：覆盖车端和云端构成的智能协同计算软件平台，通过车云互联、车云协同计算能力实现车端ECU能力与云端服务的无缝衔接支撑汽车智能化场景应用的高速、平稳的运行。

车云一体服务平台：根据OEM的品牌特性为终端车主提供海量应用订阅商城服务、为第三方开发者提供专业的API开发者服务平台、为产品生态提供稳定的服务运营平台和数据服务平台。

1.3 车云一体的价值应用

1.3.1 车云一体价值综述

在软件定义汽车的发展趋势下，车云一体软件架构和设计方法不仅限于在技术层面上的软硬件解耦，屏蔽不同硬件架构的差异性，提升了开发效率并降低研发成本，实现了汽车软件平台化的技术价值。同时，也推动了汽车软件产业发展的商业价值，以往OEM主要依靠整车销售及品牌价值的盈利模式，通过车云一体平台构建的“软件加工厂二可支撑海量的软件订阅服务，提高用户体验附加值、同时为了适应不断变化的市场环境和用于需求，持续可进化的价值也是必不可少。

未来围绕智能汽车有望形成以车云一体架构为基础搭建SOA平台，以用户体验为核心，OEM与科技公司、其他行业领先企业合作共创的软件定义汽车新生态。

1.3.2车云一体价值说明

车云一体的价值主要体现在三个方面，业务价值、技术价值和商业价值。

（1）车云一体-业务价值

基于SOA的设计思想，通过服务化方式解决车云能力的自由调度，提升车云高效协同，并通过服务的自由组合提升智能化体验。OEM可以专注用户需求进行应用功能的敏捷开发。以往动辄好几年的新功能开发、集成、验证的周期将缩短为几个月甚至更短，支付给供应商的昂贵开发费用也不复存在，基于车云一体的原子服务能力搭建的开发平台，可以让不同应用人群轻松定义服务、编排服务、仿真测试，快速发布完成开发工作。

基于SOA提供的松耦合性和原子服务能力，车端功能可以动态配置，根据不同需求的用户、出行目的、道路情况等状态，为用户提供能够切实满足用户个性化需求的场景模式，实现千人千面的用车体验。

（2）车云一体-技术价值

通过打通车云之间的通讯链路，可以帮助OEM提升车云高效协同，在复杂的网络环境下可自由切换，并提高数据传输效率，降低数据传输成本，同时在获取脚本后，通过已封装的服务可立即解析和执行，无需繁琐的升级流程，高效的服务解析能力，可提高客户体验和满意度，车云一体通过分布式引擎能力，保障场景引擎在服务自由调度过程中平稳运行，并且有效降低频繁调度的总线带宽负荷，从而提高运行稳定性和安全性。

（3）车云一体-商业价值

回顾智能手机的生态发展，已经诞生了如淘宝、支付宝、微信、字节跳动等一系列科技公司和互联网企业，而基于智能汽车的SOA生态仍处于起步阶段。除传统汽车产业内玩家，其他行业领先企业也能通过SOA平台接入汽车业务。针对车端的硬件能力及用户需求，为智能汽车场景功能的创新注入更多活力，促进万物互联，实现汽车与日常生活的深度融合。提前布局车端与业内领先OEM进行合作,有利于抢占车端应用市场，探索车辆持续运用软件的商业模式。全新的生态和全新的商业模式，往往预示着无限的可能。

02. 车云一体定义和设计规范

车云一体是指车端各ECU与云端生态能力之间，基于SOA服务化的设计思想，构建支撑整车智能化应用场景的平台化软件架构和方法论。

车云一体的核心实现路径：

（1）横向-跨域:针对不同的E/E架构（尤其在域控集中式架构下），通过解决车内横向跨域的问题,构建整车集中的软件平台，是车云一体架构中车端面向云端能力融合的基础。

（2）纵向-跨车云：基于车内功能统一整合和可开放的能力，通过与云端的打通实现车云之间数据和服务的交互，从而充分利用云端的计算能力和生态服务能力提升智能化。

（3）关键技术：基于SOA的设计思想将云端和车端能力以服务化的方式进行封装，进而简化应用的开发效率以及体现服务自由组合能力实现场景灵活可变的用户体验。

2.1 车云一体整体设计原则

车云一体是由面向服务的基础运行环境和面向服务的开发环境的一整套软件框架以及可以快速地将云端原子能力和车端原子能力通过服务化的方式进行组合的工具链构成。基于稳定、高效、安全运行的服务自由调度的运行环境和降低开发难度提升效率的工具链，可以实现从服务定义、编排到智能化场景运行支撑的全链路车云一体解决方案。

图例说明：新场景设计“当乘客打开任意车门进入到车内时，座舱氛围灯自动开启，并在车机中显示欢迎语和语音提示”，在开发环境中进行相关原子服务的定义开发以及基于设计的场景流进行服务编排生成，从而实现智能化场景的功能。

关于车云服务化通信的实现，由于车内通讯和车云通讯协议的不同，需要考虑通过SOA的设计思想进行不同协议的服务化转换，实现车云间服务自由发现的能力。

2.2 车云一体开发环境

车云一体开发环境主要面向于普通开发者、专业开发者、第三方开发者，提供包括服务定义、服务开发、服务编排、仿真测试、审批发布、数据运行的一整套工具链。

如下图所示，设计“当下雨时，且车速大于20km/h,自动开启雨刷器功能”的服务的流程

以服务定义、编排到场景运行的车云一体SOA服务开发的全部流程为例，首先服务定义时比如定义车端服务（雨刷、车速）以及云端服务（天气）,通过工具生成相应的原子服务，在服务编排时选择已经定义好的原子服务按照场景逻辑进行编辑，发送指令在运行环境运行。

2.3 车云一体运行环境

车云一体运行环境主要分布在车端软件平台和云端软件平台。针对不同的E/E架构，布置在定位为整车级管理的域控制器中，作为车内跨域融合与车云的交互中央交互单元，进行集中式管理。

车端部分主要包括动态服务引擎，以及为动态服务引擎提供车辆硬件能力的静态服务（原子/组合服务）和管理服务自由调度分配的服务调度管理平台。同时基于车内基础软件和中间件的系统和整车管理能力，与云端服务能力进行融合。

云端部分主要包括云端核心服务模块，提供动态可配置的全ECU的数据采集、OTA、诊断等远程管理能力的车辆远程服务平台，以及提供云端生态能力的云服务（提供CP/SP服务、V2X、IOT服务等），具体如下图所示：

03. 车云一体服务化架构设计规范

3.1 车云一体整体架构设计

整体车云一体架构设计如下图，车云一体整体架构应支持智能模型上车，提供车云生态一体化体验服务可通过智能模型调度，赋能千人千面个性化体验。

车云一体架构有机地进行了能力抽象、分层、权限控制、分模态组合、分应用的提供车云一体服务,有力支撑了云管端一体的SOA平台架构。

图车云一体架构圏

ASF软件架构将整车的硬件能力以服务形式提供,通过标准化的接口实现车辆功能的软硬件解耦。

ASF软件架构以服务的形式进行接入，为应用层开发者提供更丰富的选择。开发者平台提供IDE环境并通过标准化API进行应用开发，使开发者能够结合自身业务与车端功能，孵化出跨域融合、跨行业融合的全新软件产品。

车云一体架构的优势主要表现在以下几个方面：

（1）位置透明：车云服务的使用者不需要关心服务在车端还是云端，由平台自动完成服务的消费和响应；车端服务可以在云端访问，云端服务也可以在车端访问，形成车云一体化服务；

（2）可重用：车云一体化软件组件抽象实现，就可以方便地提供能力服务，可以被不同的上层抽象和使用，不同的车辆可以使用云端同一个软件组件提供的能力服务，车辆内部也可以很容易地实现跨域访问，而不需要重复地构建；

（3）易扩展：车云一体架构实现了组件的接口与实现分离，可以方便地进行实现的重构而不影响服务的消费者；也可以方便地进行云端、车端能力的扩展，通过服务发现的机制自动加入到SOA平台而不需要平台重构就可以向消费者提供服务；当然，还可以通过服务编排的机制根据不同的场景进行服务的调度和协调;方便进行扩展和使用；

（4）易使用：服务消费者只关心抽象服务的使用，而不用关心具体使用哪些车辆服务,这些服务是来自车端还是云端、也不用关心车辆服^务的组合和协调调度，更不用关心服务的实现机制和原理；

（5）安全可控：通过访问权限暴露相关服务接口的机制，有效地控制了非法的访问，并且系统的安全机制和分层管控方法，更加方便地进行安全策略的控制和调整，保证了整个SOA平台的安全可靠；

车云一体化软件组件的优势远不止于此，它解放了开发者的思维，提升了开发者对车辆的认识，可以让不同的角色聚焦到自己熟悉的领域，而屏蔽不必要的实现和部署细节，降低了上层应用对底层能力的依靠，解耦了不同功能组件的相互的依赖等等。

3.2 车端分层设计原则

从最小功能原则、高开放性原则、可继承原则、接口最小化原则、低依赖原则等五个原则进行车辆抽象。

（1）最小功能原则：根据业务场景抽象服务功能，遵从单一性原则，一个服务完成一个场景功能。再从场景功能继续下探，依据服务功能挖掘需要的能力，确定能力是来自车端还是云端，将车端或者云端能力抽象，然后再逐层抽象；

（2）高开放性原则：设计软件组件或服务的时候，要求高扩展性，通过接口，继承等多种软件技术，使系统在设计的时候就考虑到运行时的对外扩展开放，对内修改封闭；

（3）可继承原则：对车辆能力、云端能力建立通用的能力模型，提供多种不同应用场景的能力继承和具体实现，确保不因为场景能力的不同影响已存的能力模型，继而影响整个系统；

（4）接口最小化原则：软件组件能力提供也使用单一功能的原则，尽可能让一个接口完成一个指定功能，避免接口的混用，并且尽可能保持接口精简；

（5）低依赖原则：充分考虑不同软件组件之间的依赖性，高层模块不应该依赖低层模块，相反，它们应该依赖抽象类或者接口，降低不同软件组件之间的紧耦合性；

车端的分层如下图所示：

图车端分层架构

车内有主域控制器和区域控制器两种类型，主域控制器往往提供更高的算力和更大的通信帯宽，负责统筹管理车内所有的服务，区域控制器只负责某一块功能。只有主域控制器才需要跟云端交互，区域控制器不直接跟云端交互。

不同域控制器的ASF互相协作，提供了车内的所有服务。运行在每个区域控制器的应用程序，不仅可以调用自身域控制器提供的服务，也可以调用其他域控制器的服务，甚至可以通过主域控制器，调用云端的服务。

部署在主域控制器的车云服务转换模块，实现车云服务的双向转换，将整车级服务提供给云端的同时，也将云端服务注册到ASF,车内所有的域控制器都可以访问注册到主域控制器中的云端服务。

通用基础软件提供了ASF的运行环境，ASF支持运行在AUTOSARAP、AUTOSARCP以及Android等平台。ASF需要在域控制器内做到跨核协同，在不同种类的操作系统及基础软件平台之上，提供系统级和整车级服务。

3.3 车云一体数据闭环

车云一体的数据，车云能力抽象代理以服务方式打通车云链路，实现车云之间的服务共享，隔离车云间的平台差异，对车云服务实施权限配置管理及链路状态监控。服务对生态开放，动态部署；计算对生态开发，动态部署。支持智能模型上车，提供车云生态一体化体验。

图车云一体的数据闭环架构图

全栈边缘计算+大数据架构，车云一致的数据结构+序列化+语法编译器+流算子+算法解析器+执行计划优化器，支持同数据同计算结果。执行器屏蔽跨平台资源调度与信号接入之间的差异；高层语法支撑动态车内加载部署；算法=多算子组合的文本描述，车云算子一致；流算子、动态plugin加载、在整车测试集成过程测试验证；算法更新下发文本描述即可，监测算法文件更新后可自动生成可执行对象线程。

面向生态的算法开发灵活性，开发者工具拖拉拽，云上测试即可，无需整车长时间周期成本，完善可组合的数据处理，信号，特征，机器学习等算子模型，与FOTA集成，灵活更新，按需计算，互联网级别的迭代速度。

图车云一体的数据闭环架构图

3.4 车云一体关键实现技术一览

基于车云一体的架构设计和技术目标，有以下四项关键技术：

（1）车云一体服务化通讯设计技术：对车端和云端的通信进行合理规划，对通信数据从大小、安全性、QoS、时延、响应要求等方面进行分类，按照不同的要求和应用建立不同的通信链路，提供通信能力服务；

（2）车云一体服务化通信安全防护技术：对于车云通信链路进行安全防护。不仅仅需要考虑数据传输安全，还需要考虑车辆接入安全、通信链路安全、访问安全，也需要从进程防护、文件加固、流量监控、GNSS欺骗防护、车内流量监控、侵入检测、恶意攻击防护等方面进行系统、全面的安全防护；

（3）车云一体能力同步技术：在车云基础通信服务之上，进行车端能力和云端能力的同步，将车端能力反馈到云端，将云端适合于某一个车辆的能力下发到车端，进行车云能力状态的管理和同步，在车端形成其使用能力的合集，在云端形成车辆的影子设备；车云一体服务的调度和协调技术：车云能力虽然对使用者来讲没有车云分离概念，但是在事实上是存在云和车的区别，为了使消费者无感，实现了车云能力组件化，通过调度协调，实现双向远程调用。车云能力调度协调就是将车端能力和云端能力进行有机整合，将抽象的车云软件组件调度协调，形成车云一体化软件组件，让用户和开发者无感能力的实际部署。

（4）车云能力服务化技术设计思想：从用户出发，分析不同用户现实需求，挖掘用户潜在需要，结合车辆未来的发展以及行业经验，集成云端的Al,Big Data等云端技术，在抽象形成的车云软件组件基础上进一步抽象，形成车云一体的服务。

下面是《车云一体技术规范1.0》的目录：