车载智能计算基础平台SOA软件架构白皮书.pdf

车载智能计算基础平台车载智能计算基础平台SOA 软件架构白皮书软件架构白皮书 中国智能网联汽车产业创新联盟中国智能网联汽车产业创新联盟 基础软件工作组基础软件工作组 2022 年年 8 月月 2 日日 I 目目 录录 前 言.1 第一章 研究背景及意义.3（一）汽车电子电气架构发展趋势.4（二）车载智能计算基础平台.5（三）面向服务的架构 SOA.5（四）智能驾驶域 SOA.8 第二章 SOA 架构技术简介.10 第三章 SOA 架构在汽车行业的发展现状.11（一）国外发展现状.11（二）国内发展现状.14 第四章 车载智能计算基础平台参考架构.17（一）系统软件层.17（二）功能软件层.20 第五章 车载智能计算基础平台 SOA 接口.24（一）智能驾驶通用模型及其接口.24（二）功能软件通用框架及其接口.26（三）数据抽象接口.27 第六章 车载智能计算基础平台 SOA 核心架构.29（一）软硬件解耦.30（二）智驾功能的基础服务分解.31（三）网联云控服务.31 II （四）信息安全服务.32（五）系统软件.32（六）OEM自动驾驶应用软件 SOA 开发 SDK.33 第七章 车载智能计算基础平台 SOA 实现的扩展技术.35（一）SOA与内核.35（二）容器.35（三）虚拟化技术.36（四）通信技术.37 1 面向服务的通讯.37 2 实时以太网技术.40 3 DDS 与 TSN 联合调度.42（五）SOA架构中的信息安全技术.42 1 SOA 系统环境安全.42 2 安全的 DDS模型.43（六）OTA 技术.44（七）云原生.45 第八章 车载智能计算基础平台 SOA 应用参考实践.46（一）基于微服务和容器的车道保持.46（二）基于 SOA 服务的云车协同实践.49 缩略语缩略语.52 参考文献参考文献.53 附件附件 A 安全安全 SOA 服务框架服务框架.54 1 前前 言言 智能化和网联化不仅仅是全球汽车产业的发展方向，也是国家发展战略的重要方向。为此，工业和信息化部印发的车联网（智能网联汽车）产业发展行动计划（以下简称行动计划）提出了智能网联汽车发展的阶段目标和任务以及需要突破的关键技术。车载智能计算基础平台是行动计划提出的关键技术之一，基础平台相关的硬件及软件，特别是软件架构设计是自动驾驶和车联网应用的重要基石。由中国软件评测中心、工信部装备工业发展中心牵头发布的车载智能计算基础平台参考架构 1.0中提出了基于异构分布的硬件平台和集成自动驾驶操作系统的车载智能计算基础平台参考架构。SOA 白皮书基于上述参考架构，从软件架构和软件设计的角度分析了智能网联汽车特别是自动驾驶功能的实际应用需求，提出了智能网联汽车基础平台软件设计的 SOA核心架构，详细探讨了 SOA服务接口，可扩展的关键技术，以及包括信息安全/数据安全的基础服务。本白皮书由中国智能网联汽车产业创新联盟基础软件工作组成员共同起草，致力于促进汽车技术基础平台软件架构的开放性，应用软件的通用性，服务组件的模块化，汽车感知数据接入和通讯接口标准化，智能网联汽车服务软件和应用开发，为实现软件定义车辆奠定基础。在此衷心感谢参加研究报告编写的各单位、组织及个人。2 组织指导组织指导：中国智能网联汽车产业创新联盟基础软件工作组 编写编写单位单位：国汽智控（北京）科技有限公司、禾多科技（北京）有限公司、苏州挚途科技有限公司、紫金山实验室、中瓴智行（成都）科技有限公司、北京邮电大学、福特（南京）工程技术研究院、北京经纬恒润科技股份有限公司、北京谦川科技有限公司、中国软件评测中心（工业和信息化部软件与集成电路促进中心）。参研单位参研单位：武汉光庭信息技术股份有限公司、中兴通讯股份有限公司、清华大学、国家工业信息安全发展研究中心、北京地平线机器人技术研发有限公司、上海睿赛德电子科技有限公司、北京国家新能源汽车技术创新中心有限公司、北京智行者科技有限公司、北京超星未来科技有限公司、南京芯驰半导体科技有限公司、普华基础软件股份有限公司、黑芝麻智能科技（成都）有限公司、华为技术有限公司、北京百度智行科技有限公司、广东为辰信息科技有限公司、长沙智能驾驶研究院有限公司、苏州智行众维智能科技有限公司、华砺智行（武汉）科技有限公司。参编人员参编人员：尚进、陈林、丛炜、黄小云、于英俊、何知俊、白钰、陈绪戈、杨修浩、朱海龙、蒋彪、吴超、孟祥雨、金燕江、於大维、于雅琪、郭伟、孟庆洋、王伟、余贞金、李诒雯、陈晓、羊诚、郑四发、张创、余宇舟、程智锋、熊谱翔、李克、杨上东、吴倩、张放、耿庆官、熊祺、朱煜奇、陶圣、刘艳玲、张晓先、罗青松、黄何、申泽庶、贾元辉、陈丽蓉、罗家豪、张启迪、任学锋。3 第一章第一章 研究背景及意义研究背景及意义 在传统汽车逐渐被智能网联汽车颠覆的趋势下，软件在产业价值链和商业模式中越来越重要，软件定义汽车成为发展方向。ADAS 的发展及自动驾驶的需求促使汽车电子电气架构从分布式的功能框架向集中式的智能计算平台演进。自动驾驶软件的复杂性和快速更新迭代要求智能计算平台软件设计不仅要支持基础 OTA 功能而且要实现软硬件解耦、区域分离、软件模块和通讯接口开放、算法和应用模块重用。网联化使汽车成为互联网的一部分，其应用场景涵盖移动通讯、云车协同、车路协同、数字孪生和智慧交通等。这些应用场景促使汽车在信息交互、移动通讯、数据交换和应用共享方面需要实现开放。车载智能计算基础平台作为车联网的基础节点，其软件架构设计需要涵盖上述应用场景，主要包括基于 5G和边缘云的协同计算、基于 V2X 的感知规划、基于融合智慧交通的网联云控等。从软件设计的角度，需要考虑对复杂应用软件的支持，以及在处理分布和计算资源分配方面的灵活性和可扩展性。计算平台的设计（特别是软件架构的设计）应遵循 SOA 设计理念，即分层化、模块化和标准化，使服务和应用能够在不同车型、硬件平台、操作系统上复用，并且可以通过标准化接口对应用功能进行快速迭代升级。从计算平台本身的角度看，架构设计需要涵盖系统软件（虚拟机、系统内核、中间件）、功能软件以及应用软件三个层次。从车联网的角度看，软件架构设计应涵盖计算平台、边 4 缘计算和中心云三个维度的资源协同、数据共享和应用扩展。在成熟的 SOA 架构基础上，丰富的应用生态将具备更大的价值空间，助力实现真正的软件定义汽车。（一）（一）汽车电子电气架构发展趋势汽车电子电气架构发展趋势 随着智能汽车的快速发展，汽车电子化程度越来越高，车内电控单元的数量呈指数增长。智能汽车应用场景需要多类型、多数量的传感器支撑，进而需要集中化、高算力的车辆域控制器进行算力聚合，以满足智能汽车的算力需求。汽车电子电气架构的演进趋势由传统分布式架构到域集中式架构最后到中央集中式架构转变，如图 1 所示。传统汽车电子电气架构无法满足智能汽车的算力和模块高扩展性的需求，分布式 ECU 方案通常采用低功耗、低算力硬件单元，数据处理能力较弱，且各ECU 之间的算力无法进行整合。此外，传统分布式 ECU 方案软硬件强耦合，且每个 ECU 的软件逻辑、处理的传感器数据、实现的功能都相对单一和固定，后续迭代升级的资金和时间成本巨大。图 1 汽车电气架构演进趋势（来源：博世）5 （二二）车载智能计算基础平台车载智能计算基础平台 车载智能计算基础平台是新型集中式电子电气架构发展趋势下出现的新型核心零部件，是集中式电子电气架构的基础支撑。车载智能计算基础平台集成异构分布硬件平台和智能驾驶软件平台，可以提供强大集中的算力，满足智能汽车的需求。车载智能计算基础平台可以实现硬件标准化和软件开发车辆应用功能，实现供应商可替代，加速软件迭代周期。智能汽车将成为移动数据中心，大量边缘计算工作可以集中至计算平台，有力解决传统电子电气架构中各ECU算力不足的问题。作为承接并支撑汽车芯片、基础内核与整车发展的关键产品，车载智能计算基础平台及其搭载的软件平台涵盖产业链上游、中游和下游产业，对各个关键零部件产业的发展有极大的推动作用，将成为半导体、汽车电子等产业增长的驱动力，具有广阔的市场前景。其中，上游产业包括传统芯片、操作系统、基础软件、AI 芯片、人工智能等，中游产业包括智能汽车计算平台等，下游产业包括零部件和整车等。此外安全防护、测试评价等产业为智能汽车计算平台的发展提供支撑，同时，也会带动 5G、云计算、大数据、移动支付、共享出行等服务产业的发展。（三三）面面 向服务的架构向服务的架构 SOA 软件定义汽车是大势所趋。目前，汽车行业已掀起智能化转型浪潮，并在主控芯片的算力方面展开激烈竞争。回顾智能手机发展历程，竞争初期各厂商争相在诸如处理器、屏幕、摄像头等硬件方 6 面提升配置。当硬件竞赛发展到一定程度时，厂商间的差异化竞争力将着重体现在软件层面。同时，软件具备边际开发成本更低、易满足用户个性化需求等优势。构建完善的软件生态可为整车厂打造更为差异化的品牌特征，从而反向推动新车销量。大众汽车认为软件创新在未来汽车创新中的占比将达到 90%左右。集中化的电子电气架构是实现软件定义汽车的硬件基础，而SOA 则是实现软件定义汽车的软件基础。传统分布式电子电气架构下，汽车采用“面向信号”的软件结构（如图 2 所示），ECU 之间的通信方式为通过 LIN/CAN 等总线进行点对点通信。相应的 ECU 信号已在编译软件阶段完成预设，收发关系和路由信息是静态的。如果想要升级或新增某项功能时，需要修改与该信号相关的所有 ECU软件，并修改总线的网关配置和节点数量。因此，在传统的通信及ECU 软件架构设计中，各类信号能否准确、高效地在车内进行收发传导是通讯网络关注的重点。然而，随着汽车智能化升级需求的快速增长，传统通讯网络及软件架构中扩展性差、升级和移植成本高等问题逐渐凸显，当需要新增某项应用软件或服务时，需重新建立一个新的基础软件环境。为解决上述问题，汽车行业基于 IT 行业发展经验，引入 SOA 软件架构设计思想。电子电气架构正朝着以通用计算平台为基础，面向服务架构的方向发展。SOA 是一种软件架构，同时也是一种软件设计方法和理念，如图 3 所示。它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用 7 中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。SOA 具备松耦合、标准接口可访问和易于扩展等特点，使得开发人员能以最小的软件变更应对迭代多变的客户需求。图 2 “面向信号”的架构（Signal-Oriented Architecture）图 3 面向服务的架构（Service-Oriented Architecture）8 （四四）智能驾驶域智能驾驶域 SOA 当前，集中式电子电气架构的典型方案主要有三域EEA和Zonal EEA，如图 4 和图 5 所示。Zonal EEA 即中央&区架构，搭载车载中央计算机和区控制器，Zonal EEA方案具有前瞻性，可能需要更长时间来实现。三域 EEA 利用三个大型域控制器实现车控、智驾、信息娱乐的功能，其中“三域”指车辆控制域、智能驾驶域和智能座舱域。车辆控制域是原动力域、底盘域和车身域等经典车辆域的整合，负责整车控制功能的实现；智能驾驶域负责自动驾驶相关感知、规划、决策相关功能的实现；智能座舱域负责 HMI 交互和智能座舱相关功能的实现。图 4 三域 EEA示意图（来源于网络）9 图 5 Zonal EEA示意图（来源于网络）智能驾驶域和智能座舱域的 SOA 架构设计在底层有一定共通性，但智能驾驶域相比于智能座舱域具有更高的安全性和实时性要求，因此智能驾驶域SOA是整车SOA设计的难点、核心和关键。本白皮书主要针对智能驾驶域SOA开展研究，同时对与智能座舱域SOA和未来 Zonal EEA的智能驾驶域 SOA存在的共性问题提供参考。10 第二章第二章 SOA 架构技术简介架构技术简介 SOA 是一种设计思想和方法论，在 IT 领域已经有数十年的应用经验。在 SOA 中，服务是最核心的抽象手段和系统最基础的描述单元。每个服务组件具备独立的功能，且可被复用。服务组件之间的接口遵循统一标准，可互相访问，可组合扩展。业务过程则是带有状态和服务调度策略的服务组件的组合与扩展。SOA 的优点主要包括：1）高扩展性，各个服务之间低耦合；2）易于部署，软件从单一可部署单元，被拆分成多个服务，每个服务都为可部署单元；3）易于开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级；4）易于测试，可以单独测试每一个服务。另外，SOA的不足主要包括：1）由于强调互相独立和低耦合，服务可能会细致拆分，进而导致系统凌乱和笨重；2）服务之间的通信会使得整个架构变得复杂。SOA 的灵活性和可扩展性符合“软件定义汽车”的发展趋势。业务需求与硬件资源解耦是应用 SOA 的前提，汽车电子电气架构从分布式逐步向集中式发展，为 SOA 应用提供了基础条件。在智能网联汽车中，大量的功能需要控制器间的协调工作来完成，因此，将SOA 引入到当前汽车软件设计中，将应用程序的不同功能单元（服务）进行拆分，通过定义良好的接口和契约将这些服务联系起来。接口是采用中立的方式进行定义，其应该独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种各样系统中的服务可以以一种统一和通用的方式进行交互。11 第三章第三章 SOA 架构在汽车行业的架构在汽车行业的发展现状发展现状 SOA 架构平台的发展是汽车行业一场巨大的改革，在 SOA 架构下所形成的产业分工中，车企和供应商纷纷在寻找自己的定位。（一）（一）国外发展现状国外发展现状 1 宝马 宝马对 ECU 按照需求进行分类，如图 6 所示，将分散凌乱的ECU、传感器和执行器按类别定义 ECU 系统需求和统一开发方法，甚至统一管理供应商，最终实现系统优化。在中央计算平台进行整车功能的划分，将功能进行严格的抽取和封装，相互之间独立性强，复杂度大大降低，有利于功能单元的移植和复用。图 6 宝马自动驾驶平台架构 2 大众 大众率先采用了面向服务的MEB架构，如图7所示。MEB架构是一种用于构造服务的架构模式，主要来源于软件技术，独立域操 12 作系统、编程语言和软件框架。MEB 架构初衷是将软件划分为单独的软件组件，通过最小化组件之间的功能依赖性来提高软件的可扩展性和复用性。图 7 大众三域电子电气架构 从MEB架构的实现来看，SOA架构思想主要是通过不同服务的相互作用实现一个复杂的功能。每个服务都是一个独立可执行的软件组件，被准确描述了功能范围，通过准确定义的服务接口将功能提供给其他软件组件，服务以组合的形式来调动其他基础服务，然后将功能组合起来。大众也是将相关功能逻辑上移至域控制器，在域控制器下接嵌入式 ECUs、传感器和执行器。大众还公开了软件架构，使用 CP 和AP 服务中间件来实现 SOA 通信，其中 CP 连接传感器、执行器和嵌入式 ECU，收集信号，通过服务或者信号发送给 AP，AP 作为封装服务，和云端后台或者其他 AP节点进行服务交互。3 丰田 丰田电子电气架构经历了简单的 LAN 网络到分层 LAN 网络架构的转变，目前采用中央网关和域控制器架构，用于应对复杂的系 13 统需求和与日俱增的开发量。但随着车型的改进不断产生新的变型，系统和软件也变得越来越大，而且 Tier1 开发过程必须统一管理，基于这些目标，他们提出了 Central&Zone 架构，EE 架构需要引入中控 ECU，所有功能都分配到 ZoneECU。4 现代 如图 8 所示，在现代的通信架构设计中，CAN 网络会和以太网共存相当长一段时间，但 SOA 并不能直接和这些网络通信，而是采用了 SOA Adaptor模块来转换其他网络的功能和信息。在和云端交互的时候，SOA 需要使用外部设备来进行服务级别的交互，这样在增强整车数据的开放性的同时增加了信息安全。另外，现代还在车内系统设计了 SOA Gateway 节点，用于升级安全等级。由于服务交互的频繁性，现代采用 SD Proxy 来高效地处理服务相关信息和进行服务更新，即安全或者强相关的服务通过 Service Router来访问。图 8 现代 SOA架构 5 AUTOSAR 14 AUTOSAR 组织为应对自动驾驶技术的发展推出了 AP架构，如图9所示。AP平台采用了SOA架构，由一系列的服务组成，应用和其他软件模块可以根据需求调用其中的一个或者多个服务，而服务可以由平台提供，也可以由远程其他部件提供，OEM 可以按照功能设计需求定义所需的服务组合。AP 的主要特点是可根据应用需求动态加载，可通过配置文件动态加载配置，并可进行单独更新，相对于 CP，可以满足更强大的算力需求，更安全，兼容性好，可进行敏捷开发。图 9 Adaptive AUTOSAR 架构（二）（二）国内发展现状国内发展现状 与国外 OEM 不同，国内 OEM 尚未实现能完全自主定义的 HPC平台，仍需要各供应商配合，尤其是传统 OEM，变革涉及太多车型，以及庞大的供应商体系，使得固有的电子电气架构模式极难突破。因此采用更稳妥的循序渐进策略，将 SOA 理念的实施重点放在娱乐系统，以娱乐系统的验证来考量是否有实施整车 SOA 架构的条件。15 上汽零束提出了 SOA 软件平台，将汽车的各个功能打通，使得他们相互联系起来。另外，上汽零束还打造了一个 SOA 软件平台的开发者平台，开发者平台将提供在线调试工具及仿真环境，在确保代码质量的同时，帮助开发者快速实现车端应用功能开发。此外，通过平台后台管理系统，开发者能对账号权限、应用风控及内容进行管理，实现软件在应用市场的审核、上架等。华为推出的 MDC 定位为智能驾驶的计算平台。平台基于 CPU与 AI处理器芯片，搭载智能驾驶 OS，兼容 AUTOSAR。其中 OS的功能软件采用 SOA 架构，定义了智能驾驶基本算法组件（如感知算法组件、融合算法组件、定位算法组件、决策算法组件、规划算法组件、控制算法组件等）的调用框架与组件之间的软件接口；上层场景应用可以灵活选择不同的算法组件组合，实现具体的场景应用功能。另外，还有一部分主机厂，率先在 ADAS 域内先实现 SOA 通信，将 SOA 融入到自动驾驶中。但在自动驾驶域，目前没有完整的落地解决方案。很多整车厂及方案供应商尝试围绕着服务的定义和部署，通过毫米波雷达、激光雷达和摄像头等多传感器的前融合架构方案，为上层系统开发大量的抽象服务。并通过服务间的组合来定义功能服务，通过敏捷开发以及针对接口的严格的封装和层次化结构，导入标准化的服务接口API，同时软件组件通过”服务总线”的中间件建立通讯（SOME/IP，DDS 等），用这种思想去尝试进行智能驾驶域的 SOA设计，真正意义的实现软件和硬件分离。16 另外，由中国汽车协会牵头的中国汽车基础软件生态委员会（简称 AUTOSEMO）于 2021年先后发布了车载 SOA软件架构技术规范 1.0、车载 SOA 软件架构技术规范 1.1与中国汽车基础软件发展白皮书2.0。白皮书首次提出 ASF框架，ASF框架是对通用基础软件的扩充，同时也对 AUTOSAR 的服务管理框架进行扩展，向应用层提供更多基于服务开发需要的功能，其中包括服务转换、服务调试、服务同步，服务权限管理和基于 android 的 SOA 协议栈。17 第四章第四章 车载智能计算基础平台参考架构车载智能计算基础平台参考架构 车载计算基础平台侧重于系统可靠、运行实时、分布弹性、高算力等特点，实现感知、规划、控制、网联、云控等功能，最终完成安全、实时、可扩展的多等级自动驾驶核心功能。如图 10 所示，车载计算平台的总体架构主要包含车控操作系统和异构分布硬件架构两部分。其中，运行于车载智能计算基础平台硬件及汽车电子控制单元硬件之上，支撑智能网联汽车驾驶自动化功能实现和安全可靠运行的软件集合，架构上包括系统软件和功能软件。图 10 车载智能计算基础平台架构框图（一）（一）系统软件层系统软件层 系统软件是针对汽车场景定制的复杂大规模嵌入式系统运行环境，如图 11 所示。系统软件一般包含操作系统内核、虚拟化管理（Hypervisor）、POSIX、系统中间件及服务等。18 图 11 系统软件架构 1 操作系统内核 车控操作系统内核支持异构芯片，需考虑功能安全、实时性能要求。当前异构分布硬件架构各单元所加载的内核系统功能安全等级有所不同，AI 单元内核系统 QMASILB，计算单元内核系统QMASILD，控制单元内核系统 ASILD，因而出现不同安全等级的多内核设计或单内核支持不同安全等级应用的设计。保证差异化功能安全要求的同时满足性能要求，是车控操作系统系统软件设计的关键。另外，车载智能计算基础平台的复杂性也要求内核对功能软件及应用软件的库支持和高度可编程性。2 虚拟化管理（Hypervisor）Hypervisor技术是实现跨平台应用、提高硬件利用率的重要途径。Hypervisor 是一种硬件虚拟化技术，管理并虚拟化硬件资源（如CPU、内存和外围设备等）并提供给运行在 Hypervisor 之上的多个内核系统。车控操作系统通过 Hypervisor 实现有效的资源整合和隔离。19 3 可移植操作系统接口（POSIX）POSIX 是被主流操作系统广泛采用和遵守的标准。基于 POSIX的应用可以方便在不同操作系统间移植。POSIX 也能够很好地适应自动驾驶所需要的高性能计算和高带宽通编程。Adaptive AUTOSAR同样采用基于 POSIX 标准的内核系统，可使用 PSE51 子集的标准POSIX API，旨在满足未来高级自动驾驶的需求。车控操作系统系统软件基于实时嵌入式软件单元架构，可借鉴 Adaptive AUTOSAR平台思路，在不同内核系统采用 POSIX API 与应用软件、功能软件交互。4 系统中间件及服务 系统中间件位于系统软件中，主要是管理计算资源和网络通讯，并为上层应用提供基础的系统服务。其中最主要的中间件是指分布式通信服务，它主要是以发布/订阅方式为 SOA应用之间提供数据和信息交换服务。车控操作系统可建立跨多内核、多 CPU、多板的通用、高速、高效的通讯和数据共享机制。采用发布/订阅架构的分布式中间间，强调以数据为中心，提供丰富的 QoS 策略，能保障数据进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需求。其中有代表性的分布式通信中间件技术规范为 DDS、SOME/IP等。5 安全域操作系统及功能服务 安全域操作系统是系统软件层上运行在 MCU上的实时安全车控操作系统。安全域操作系统主要包含硬件抽象层、基础软件、实时 20 操作系统内核和运行时环境等模块。安全域操作系统最基本的要求是高实时性。系统具备硬实时特性，需要在规定时间内完成资源分配、任务并发、同步等指定动作，可参考 CP软件架构。（二）（二）功能软件层功能软件层 功能软件是车控操作系统根据面向服务的架构设计理念，通过提取智能驾驶核心共性需求，形成智能驾驶各共性服务功能模块，高效实现驾驶自动化功能开发的软件模块。如图 12 所示，功能软件由应用软件接口、智能驾驶通用模型、功能软件通用框架，以及数据抽象组成。图 12 功能软件架构 1 应用软件接口 车辆应用建立在功能软件基础上，功能软件通过统一应用软件接口为应用软件提供调用和服务。应用软件的开发和运行可以不依赖具体传感器和车型。不同的市场参与方（包括政府主管机构、主机厂、供应商、高速路或停车场等交通设施管理者和个人）都可以开发应用。应用可以被打包、部署、启动、调度和升级。应用程序 21 的功能可通过用户、路端以及云端来定义，并通过应用场景触发。借助功能软件层的支撑，应用程序的开发将向轻量化方向发展，越来越聚焦在业务逻辑本身所决定的规则制定上。应用程序构建在更为抽象的环境模型、车辆模型、任务模型和资源模型之上，相比功能软件有更好的可移植性，能够跨车型、跨计算平台部署。和功能软件相比，应用程序更侧重于业务而不是功能，更偏向用户侧而不是系统侧，更关注目标而非方法。应用程序可以构建在功能软件所提供的服务上，也可以直接构建在环境和车辆模型上。应用程序接口不仅涉及到应用程序的运行，还应涉及应用的开发和管理类接口。系统软件供应商应该为应用软件开发提供统一的开发环境和工具，可以体现给用户不同形式的 SDK，例如环境模型、功能配置、各种算法 SDK 以及包括应用开发所必要的工具链、软件包、开发接口、开发文档、示范应用和配置等。2 智能驾驶通用模型 智能驾驶通用模型是对智能驾驶中智能认知、智能决策和智能控制等过程的模型化抽象。智能驾驶通用模型由环境模型、规划模型、以及控制模型组成。环境模型作为智能认知框架，为智能决策和智能控制提供模型化的广义环境信息描述。环境模型调度各类感知、融合和定位算法，对传感器探测信息，车-路、车-车协同信息，以及高精地图先验信 22 息进行处理加工，提供探测、特性、对象、态势、场景等各级语义的道路交通环境和自车状态信息。规划模型根据环境模型、自车定位、个性化设置和自车状态反馈等信息，为自车提供未来一段时间内的行驶轨迹，主要分为行为预测、行为决策和运动规划三大部分。行为预测是根据感知和地图数据对其他交通参与者未来的行驶轨迹进行预测，为行为决策提供更全面、可靠的参考信息；行为决策为自车提供行为策略，同时为运动规划提供相应的规划约束条件，保证规划结果不仅满足交通法规等硬性要求，同时更加符合人的驾驶策略；运动规划根据以上信息，为自车规划未来一段时间内的安全、舒适、正确的轨迹。控制模型主要由常规工况和降级工况组成，其中常规工况主要针对 ODD 以内的动态驾驶任务，降级工况主要针对发生系统性失效或者超出 ODD 以外的动态驾驶任务，均需要进行输入处理、状态决策、控制计算及执行输出等。针对上游及底盘信息的输入，以及控制输出均需要适配层去匹配不同的功能算法框架平台及车辆平台；针对横纵向及紧急控制等算法模块需要进行故障诊断、配置及标定接口模块统一管理。3 功能软件通用框架 功能软件通用框架是承载智能驾驶通用模型的基础，分为数据流框架和基础服务两部分。数据流框架向下封装不同的智能驾驶系统软件和中间件服务，向智能驾驶通用模型中的算法提供与底层系统软件解耦的算法框架。23 数据流框架的主要作用是对智能驾驶通用模型中的算法进行抽象、部署、驱动，解决跨域、跨平台部署和计算的问题。基础服务是功能软件层共用的基本服务，其主要服务于智能驾驶通用模型或功能应用，但其本身不局限于智能驾驶。基础服务平台包含可靠冗余组件、信息安全服务、网联云控服务，其中可靠冗余组件将系统中其它所有软件和硬件模块都抽象为被管理实体，通过与所有被管理实体的交互，完成对整个系统的监测和故障处理；信息安全基础服务中的数据安全服务为车端数据定义了数据类型和安全等级，为车端功能和应用所需不同类型数据在不同车辆运行场景下制定安全策略和数据处理规则。数据流框架上的算法部署和数据流编排模块，按规则定义控制算法部署和数据交换。网联云控服务可提供操作系统的安全冗余信息、超视距信息和通用模型的信息，通过 LTE-V2X、4G/5G 的通讯方式，实现与车车通讯、车云通讯、车人通讯和车与路侧基础设施通讯。4 数据抽象 数据抽象通过对传感器、执行器、自车状态、地图以及来自云端的接口等数据进行标准化处理，为上层的智能驾驶通用模型提供各种不同的数据源，进而建立异构硬件数据抽象，达到功能和应用开发与底层硬件的解耦。24 第五第五章章 车载智能计算基础平台车载智能计算基础平台 SOA 接口接口 整车EEA架构升级和整车SOA的需求有效推动了自动驾驶领域底层功能的服务化。在接口标准化、相互独立、松耦合的标准要求下，操作系统通过对服务进行设计和有效组合，可以将传统编程从业务逻辑分离，允许开发人员集中精力编写上层的应用算法，而不必将大量的时间花费在更为底层的技术实现上。针对不同的模块，如环境模型、规划模型、算法模型等，操作系统应提供不同类型和颗粒度的应用软件接口。应用软件接口应具有灵活性，如可以接受不同类型的参数，运行模糊逻辑等。应用软件接口应具有可扩展性，用户可基于现有的接口进行增强和优化。（一）（一）智能驾驶通用模型及其接口智能驾驶通用模型及其接口 智能驾驶通用模型应提供智能驾驶所需的感知、融合、定位、规划和控制等算法以及这些算法所需外部环境和车辆自身数据的抽象化模型。1 环境模型接口 环境模型应提供北向接口给应用软件开发和东西向接口给规划控制算法和处理逻辑，且环境模型的对外接口需要标准化并具有灵活性和可扩展性。主要包括：1）目标检测和融合接口；2）车道检测和车道融合接口；3）交通信号灯及交通标识检测接口；4）道路信息和标记检测接口；25 5）融合定位接口；6）可行驶空间信息检测接口；7）自车状态服务接口；8）泊车信息检测接口。2 规划模型接口 规划模型应能根据环境模型信息、功能配置输入、车辆状态反馈信息预测未来一段时间内的交通参与者的运动状态，并且及时做出正确的行为决策，为运动规划提供行为策略和约束条件，最终输出符合车辆运动学和动力学约束的轨迹，同时满足实时性、安全性、舒适性的要求。主要包括：1）行为预测接口；2）轨迹预测接口；3）交通规则识别接口；4）导航服务接口；5）行为决策接口；6）轨迹规划接口。3 控制模型接口 控制模型应满足异构算法在不同场景下的部署要求。控制模型应提供开放的输入输出接口，能够适配不同类型的上下游输入信息，满足跨车型部署及搭载的要求。控制模型应提供在不同环境下的部署接口，满足跨平台搭载的要求。控制模型应能够提供故障诊断、配置及标定接口，满足车规级的开发要求。控制模型接口主要包括：26 1）控制算法接口；2）车身反馈接口；3）底盘反馈接口；4）车身控制接口；5）底盘控制接口；6）ADAS功能状态上行接口。（二）（二）功能软件通用框架及其接口功能软件通用框架及其接口 功能软件通用框架应满足高性能计算、高可靠性和稳定性要求。1 数据流框架接口 数据流框架应能对智能驾驶算法进行逻辑编排和运行驱动，同时对所需数据进行实时处理和管理。数据流框架应支持高性能计算和统一的东西向模块之间的接口，使在其框架上运行的算法可以根据不同的驾驶场景进行参数和算法优化或可插扩。数据流框架接口应包含：1）数据流编排服务接口；2）算法调度服务接口。2 基础服务类接口 基础服务类接口应满足可配置、可调试、可升级的基本要求，同时，基础服务应做到高效、轻量级，对智能驾驶的实时算法逻辑运行和实时数据处理做到最小影响或干扰。基础服务类接口应包含：1）信息安全服务接口；2）网联云控服务接口；27 3）可靠冗余服务接口。3 应用开发接口 应用开发接口一般是为满足 OEM自主开发自动驾驶应用、算法的需求而设计的接口。这些接口和相关工具链通常以 SDK 方式呈现给用户。应用开发接口应包含：1）基于场景的规控框架；2）插扩算法框架；3）功能配置；4）模式管理器；5）平台和系统配置。（三）（三）数据抽象接口数据抽象接口 数据抽象应满足对来自不同类型的数据源数据的统一抽象描述、标准化的数据结构定义。数据抽象应能提供上层功能和应用开发的统一数据接口。数据抽象接口应包含：1 传感器数据接口 1）摄像头原始数据/压缩接口；2）毫米波目标检测接口；3）毫米波目标跟踪接口；4）激光雷达接口；5）超声波接口；6）GNSS接口；7）IMU 接口。28 2 V2X 数据接口 1）路侧感知数据接口；2）云控数据接口；3）交通信息接口；4）车周围信号接口。3 地图数据接口 4 HMI服务及数据接口 29 第六章第六章 车载智能计算基础平台车载智能计算基础平台 SOA 核心核心架构架构 SOA 的设计思想是将应用程序分解为特定的功能组件或服务，并且独立于硬件、操作系统，通过标准化协议和应用程序接口（API）进行访问。这些服务设计应该可以被共享而不是受限于特定的硬件和车型。与云相关的某些组件或服务在设计时应考虑可以运行在本地计算机（计算平台）或分布式联网计算机群（边缘云或中心云服务器）上，在应用和服务组件的设计中可远程访问并独立更新。而计算平台底层系统和基础软件设计需要为上层服务和应用提供友好而且稳定的 SOA基础架构。主要包括以下方面：1）解耦：操作系统解耦硬件平台，底层软件独立于车型、操作系统以及编程语言。内核/POSIX/中间件独立于业务逻辑，数据源解耦传感器硬件设计。2）分层：整个系统应该进行分层架构设计，对系统不同层次和各个基础服务组件间界定清晰的界面，尽量采工业界认同的接口和标准，兼容车辆传统的控制器和操作系统和协议。3）模块化：将基础服务软件功能分解成不同类型的一个或多个独立功能，功能间相互独立，方便构建上层应用，如数据收集、数据回传、OTA、信息安全、网联云控。智驾功能的基础服务也可以进行分解，如状态机、模式管理器、算法模块、环境模型。4）抽象：对不同的感知硬件实现共性数据抽象，既隔离上次算法模块又可以实现快捷硬件匹配。30 5）标准化：接口和数据标准化。（一）（一）软硬件解耦软硬件解耦 软硬件解耦是在软件系统和应用设计上独立于硬件设计，通过构建一个通用的软件架构对硬设备接口进行抽象化处理，来兼容不同的硬件设备。提供传感器抽象机制，支持主流类型主流型号的传感器，对新型传感器具有扩展能力。提供丰富的硬件适配服务软件，硬件适配包括快速适配硬件平台和快速适配车辆平台两个部分，其中快速适配硬件平台又包括内核、中间件、AI、安全域几个方面，快速适配车辆平台包括传感器抽象、执行器抽象、HMI 数据接口。主要包括：1）平台解耦和适配；2）AI模块移植和部署；3）传感器抽象；4）执行器抽象;5）地图数据；6）中间件适配；7）HMI数据；8）核心车辆信号；9）V2X 数据。31 （二）（二）智驾功能的基础服务分解智驾功能的基础服务分解 在 SOA 架构设计中，对复杂应用和服务提取共性功能，分解成不同基础服务功能，目的是最大限度的从用现有模块和服务，提高开发效率。功能分解应该遵循：1）基础服务内高内聚，服务之间低耦合；2）低耦合服务间尽可能使用标准化的服务化界面；3）如果某个功能模块复杂度还是很高，通过共性提取，需要继续拆分。通过对复杂的自动驾驶功能、算法分解，形成基础模块，状态机/模式管理器、算法、环境模型，提供通用的 L0L4 级自驾功能应用开发的组件化解决方案，支持基于组件的快速开发和验证。主机厂基于自身策略，在设计和开发功能软件时可以选择不同的功能模块和算法组件，实现拼插式功能组合，灵活构建智能驾驶系统级解决方案。（三）（三）网联云控服务网联云控服务 网联云控服务既提供标准的、抽象的信息服务，如红绿灯信息、交通提醒信息、安全预警信息、路侧感知信息、周边车辆行驶信息，也提供可插扩算法的能力，可以新增、转换、适配不同的云控算法和应用。网联云控模块是车内外信息通信的桥梁，车辆平台可把自车状态、行驶意图广播到周围环境中或上传到云平台，同时也可从周围环境或边缘云获得感知信息(如障碍物信息)，决策规划建议，甚至运行轨迹信息。32 在设计相关服务设计中，可以遵循 SOA 设计思想，使服务不依赖于平台。运行在平台上的感知算法可以融合来自云端的 V2X 道路信息，实现车路协同。车辆通过订阅云端感知和规划数据，充分利用云端的算力和多维度场景信息，实现运控应用场景。比如拥有感知设备的停车场全自动泊车。网联云控模块可以通过对基于 SOA 架构设计思想的应用设计，无缝对接现有 V2X 场景，支持云控应用和云车协同应用。通过 5G低延时、高速率的通讯技术支持数字孪生，实现车内计算、应用向云边浮动和扩展。（四）（四）信息安全服务信息安全服务 基于信息安全技术（详见第 7 章第五节），可以建立多种遵循SOA 架构设计的信息安全服务，如网络入侵检测，信息安全监控和预警，数据安全、主机安全监测。在设计信息安全服务时，应该考虑用 SOA 的方法。比如信息安全监控可能运行在平台上，也可能运行在云端。基于 SOA 设计信息安全服务不依赖平台和操作系统，可以和云端的安全应用共享或无缝对接，也可以快速引入第三方信