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

中国智能网联汽车产业创新联盟I 1 (一)汽车电子电气架构发展趋势4........(二)车载智能计算基础平台 5(三)面向服务的架构SOA 5(四)智能驾驶域SOA 8 (一)国外发展现状 11(二)国内发展现状 14 (一)系统软件层 17(二)功能软件层 20 (一)智能驾驶通用模型及其接口 24(二)功能软件通用框架及其接口 26(三)数据抽象接口 27 (一)软硬件解耦 30(二)智驾功能的基础服务分解 31(三)网联云控服务 31(四)信息安全服务(四)信息安全服务 32(五)系统软件 32 (二)容器 35(三)虚拟化技术 36(四)通信技术 37 (五)SOA架构中的信息安全技术 42 (六)OTA技术 44(七)云原生 45 (一)基于微服务和容器的车道保持 46(二)基于SOA服务的云车协同实践 49 1前言车载智能计算基础平台是《行动计划》提出的关键技术之一，基础平台相关的硬件及软件，特别是软件架构设计是自动驾驶和车联网应用的重要基石。由中国软件评测中心、工信部装备工业发展于异构分布的硬件平台和集成自动驾驶操作系统的车载智能计算基SOA车载智能计算基础平台是《行动计划》提出的关键技术之一，基础平台相关的硬件及软件，特别是软件架构设计是自动驾驶和车联网应用的重要基石。由中国软件评测中心、工信部装备工业发展于异构分布的硬件平台和集成自动驾驶操作系统的车载智能计算基SOA白皮书基于上述参考架构，从软件架构和软件设计的角度分析了智能网联汽车特别是自动驾驶功能的实际应用需求，提出了服务接口，可扩展的关键技术，以及包括信息安全/数据安全的基础本白皮书由中国智能网联汽车产业创新联盟基础软件工作组成员共同起草，致力于促进汽车技术基础平台软件架构的开放性，应用软件的通用性，服务组件的模块化，汽车感知数据接入和通讯接口标准化，智能网联汽车服务软件和应用开发，为实现软件定义车及个人。2参研单位：武汉光庭信息技术股份有限公司、中兴通讯股份有限公司、清华大学、国家工业信息安全发展研究中心、北京地平线机器人技术研发有限公司、上海睿赛德电子科技有限公司、北京国家新能源汽车技术创新中心有限公司、北京智行者科技有限公司、北京超星未来科技有限公司、南京芯驰半导体科技有限公司、普华基础软件股份有限公司、黑芝麻智能科技(成都)有限公司、华为技术有限公司、北京百度智行科技有限公司、广东为辰信息科技有限公司、长沙智能驾驶研究院有限公司、苏州智行众维智能科技有限公司、华砺智行(武汉)科技有限公司。编写单位：国汽智控(北京)科技有限公司、禾多科技参研单位：武汉光庭信息技术股份有限公司、中兴通讯股份有限公司、清华大学、国家工业信息安全发展研究中心、北京地平线机器人技术研发有限公司、上海睿赛德电子科技有限公司、北京国家新能源汽车技术创新中心有限公司、北京智行者科技有限公司、北京超星未来科技有限公司、南京芯驰半导体科技有限公司、普华基础软件股份有限公司、黑芝麻智能科技(成都)有限公司、华为技术有限公司、北京百度智行科技有限公司、广东为辰信息科技有限公司、长沙智能驾驶研究院有限公司、苏州智行众维智能科技有限公司、华砺智行(武汉)科技有限公司。参编人员：尚进、陈林、丛炜、黄小云、于英俊、何知俊、白钰、陈绪戈、杨修浩、朱海龙、蒋彪、吴超、孟祥雨、金燕江、於大维、于雅琪、郭伟、孟庆洋、王伟、余贞金、李诒雯、陈晓、羊诚、郑四发、张创、余宇舟、程智锋、熊谱翔、李克、杨上东、吴倩、张放、耿庆官、熊祺、朱煜奇、陶圣、刘艳玲、张晓先、罗青3章研究背景及意义网联化使汽车成为互联网的一部分，其应用场景涵盖移动通讯、云车协同、车路协同、数字孪生和智慧交通等。这些应用场景促使汽车在信息交互、移动通讯、数据交换和应用共享方面需要实现开放。车载智能计算基础平台作为车联网的基础节点，其软件架构设计的角度，需要考虑对复杂应用软件的支持，以及在处理分布和计在传统汽车逐渐被智能网联汽车颠覆的趋势下，软件在产业网联化使汽车成为互联网的一部分，其应用场景涵盖移动通讯、云车协同、车路协同、数字孪生和智慧交通等。这些应用场景促使汽车在信息交互、移动通讯、数据交换和应用共享方面需要实现开放。车载智能计算基础平台作为车联网的基础节点，其软件架构设计的角度，需要考虑对复杂应用软件的支持，以及在处理分布和计计算平台的设计(特别是软件架构的设计)应遵循SOA设计理念，即分层化、模块化和标准化，使服务和应用能够在不同车型、硬件平台、操作系统上复用，并且可以通过标准化接口对应用功能进行快速迭代升级。从计算平台本身的角度看，架构设计需要涵盖系统软件(虚拟机、系统内核、中间件)、功能软件以及应用软件三个层次。从车联网的角度看，软件架构设计应涵盖计算平台、边4缘计算和中心云三个维度的资源协同、数据共享和应用扩展。在成随着智能汽车的快速发展，汽车电子化程度越来越高，车内电控单元的数量呈指数增长。智能汽车应用场景需要多类型、多数量的传随着智能汽车的快速发展，汽车电子化程度越来越高，车内电控单元的数量呈指数增长。智能汽车应用场景需要多类型、多数量的传感器支撑，进而需要集中化、高算力的车辆域控制器进行算力汽车电子电气架构的演进趋势由传统分布式架构到域集中式架案通常采用低功耗、低算力硬件单元，数据处理能力较弱，且各ECU之间的算力无法进行整合。此外，传统分布式ECU方案软硬件图1汽车电气架构演进趋势(来源：博世)5(二)车载智能计算基础平台作为承接并支撑汽车芯片、基础内核与整车发展的关键产品，车载智能计算基础平台及其搭载的软件平台涵盖产业链上游、中游和下游产业，对各个关键零部件产业的发展有极大的推动作用，将成为半导体、汽车电子等产业增长的驱动力，具有广阔的市场前景。工智能等，中游产业包括智能汽车计算平台等，下游产业包括零部件和整车等。此外安全防护、测试评价等产业为智能汽车计算平台的发展提供支撑，同时，也会带动5G作为承接并支撑汽车芯片、基础内核与整车发展的关键产品，车载智能计算基础平台及其搭载的软件平台涵盖产业链上游、中游和下游产业，对各个关键零部件产业的发展有极大的推动作用，将成为半导体、汽车电子等产业增长的驱动力，具有广阔的市场前景。工智能等，中游产业包括智能汽车计算平台等，下游产业包括零部件和整车等。此外安全防护、测试评价等产业为智能汽车计算平台的发展提供支撑，同时，也会带动5G、云计算、大数据、移动支付、(三)面向服务的架构SOA软件定义汽车是大势所趋。目前，汽车行业已掀起智能化转型浪潮，并在主控芯片的算力方面展开激烈竞争。回顾智能手机发展历程，竞争初期各厂商争相在诸如处理器、屏幕、摄像头等硬件方6面提升面提升配置。当硬件竞赛发展到一定程度时，厂商间的差异化竞争力将着重体现在软件层面。同时，软件具备边际开发成本更低、易满足用户个性化需求等优势。构建完善的软件生态可为整车厂打造更为差异化的品牌特征，从而反向推动新车销量。大众汽车认为软集集中化的电子电气架构是实现软件定义汽车的硬件基础，而SOA则是实现软件定义汽车的软件基础。传统分布式电子电气架构下，汽车采用“面向信号”的软件结构(如图2所示)，ECU之间的通信方式为通过LIN/CAN等总线进行点对点通信。相应的ECU信号已在编译软件阶段完成预设，收发关系和路由信息是静态的。如软件，并修改总线的网关配置和节点数量。因此，在传统的通信及ECU软件架构设计中，各类信号能否准确、高效地在车内进行收发传导是通讯网络关注的重点。然而，随着汽车智能化升级需求的快速增长，传统通讯网络及软件架构中扩展性差、升级和移植成本高等问题逐渐凸显，当需要新增某项应用软件或服务时，需重新建立IT图3所示。它将应用程序的不同功能单元(称为服务)进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用7中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一和易于扩展等特点，使得开发人员能以最小的软件变更应对迭代多re图3面向服务的架构(Service-OrientedArchitecture)8气架构的典型方案主要有三域EEA和ZonalAEEA域控制器实现车控、智驾、信息娱乐的功能，其中“三域”指车辆控制域、智能驾驶域和智能座舱域。车辆控制域是原动力域、底盘域和车身域等经典车辆域的整合，负责整车控制功能的实现；智能驾驶域负责自动驾驶相关感知、规划、9图5ZonalEEA示意图(来源于网络)但智能驾驶域相比于智能座舱域具有更高的安全性和实时性要求，A元。每个服务组件具备独立的功能，且可被复用。服务组件之间的接口遵循统一标准，可互相访问，可组合扩展。业务过程则是带有括：1)高扩展性，各个服务之间低耦合；2)易于部署，软件从单易于开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级；4)易于测试，可以单独测试每一个服务。另SOA的灵活性和可扩展性符合“软件定义汽车”的发展趋势。业汽车中，大量的功能需要控制器间的协调工作来完成，因此，将SOA引入到当前汽车软件设计中，将应用程序的不同功能单元(服务)进行拆分，通过定义良好的接口和契约将这些服务联系起来。接口是采用中立的方式进行定义，其应该独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种各样系统中的服务可以SOA架构在汽车行业的发展现状位。(一)(一)国外发展现状宝马对ECU按照需求进行分类，如图6所示，将分散凌乱的CUECU在中央计算平台进行整车功能的划分，将功能进行严格的抽取和封装，相互之间独立性强，复杂度大大降低，有利于功能单元的2大众是一种用于构造服务的架构模式，主要来源于软件技术，独立域操MEB件划分为单独的软件组件，通过最小化组件之间的功能依赖性来提高软件的可扩相互作用实现一个复杂的功能。每个服务都是一个独立可执行的软件组件，被准确描述了功能范围，通过准确定义的服务接口将功能提供给其他软件组件，服务以组合的形式来调动其他基础服务，然大众也是将相关功能逻辑上移至域控制器，在域控制器下接嵌构的转变，目前采用中央网关和域控制器架构，用于应对复杂的系统需求和统需求和与日俱增的开发量。但随着车型的改进不断产生新的变型，于这些目标，他们提出了Central&Zone架构，EE架构需要引入中44现代的交互，这样在增强整车数据的开放性的同时增加了信息安全。另相关信息和进行服务更新，即安全或者强相关的服务通过ServiceRAUTOSARAUTOSAR组织为应对自动驾驶技术的发展推出了AP架构，如其他软件模块可以根据需求调用其中的一个或者多个服务，而服务态加载，可通过配置文件动态加载配置，并可进行单独更新，相对以及庞大的供应商体系，使得固有的电子电气架构模式极难突破。(二)国内发展现状开发者平台，开发者平台将提供在线调试工具及仿真环境，在确保代码质量的同时，帮助开发者快速实现车端应用功能开发。此外，通过平台后台管理系统，开发者能对账号权限、应用风控及内容进解决方案。很多整车厂及方案供应商尝试围绕着服务的定义和部署，通过毫米波雷达、激光雷达和摄像头等多传感器的前融合架构方案，为上层系统开发大量的抽象服务。并通过服务间的组合来定义功能服务，通过敏捷开发以及针对接口的严格的封装和层次化结构，导立通讯(SOME/IP，DDS等)，用这种思想去尝试进行智能驾驶域华为推出的华为推出的MDC定位为智能驾驶的计算平台。平台基于CPU功能软件采用SOA架构，定义了智能驾驶基本算法组件(如感知算法组件、融合算法组件、定位算法组件、决策算法组件、规划算法组件、控制算法组件等)的调用框架与组件之间的软件接口；上层场景应用可以灵活选择不同的算法组件组合，实现具体的场景应用另外，由中国汽车协会牵头的中国汽车基础软件生态委员会(简称AUTOSEMO)于2021年先后发布了《车载SOA软件架构技展，向应用层提供更多基于服务开发需要的功能，其中包括服务转第四章车载智能计算基础平台参考架构车载计算基础平台侧重于系统可靠、运行实时、分布弹性、高算力等特点，实现感知、规划、控制、网联、云控等功能，最终完车载计算平台的总体架构主要包含车控操作系统和异构分布硬件架构两部分。其中，运行于车载智能计算基础平台硬件及汽车电子控制单元硬件之上，支撑智能网联汽车驾驶自动化功能实现和安全可(一)系统软件层系统软件是针对汽车场景定制的复杂大规模嵌入式系统运行环境，如图11所示。系统软件一般包含操作系统内核、虚拟化管理(Hypervisor)、POSIX、系统中间件及服务等。Hypervisor是一种硬件虚拟化技术，管理并虚拟化硬件资源(如CPU、内存和外围设备等)并提供给运行在Hypervisor之上的多个内核系统。车控操作系统通过Hypervisor实现有效的资源整合和隔车控操作系统内核支持异构芯片，需考虑功能安全、实时性能要求。当前异构分布硬件架构各单元所加载的内核系统功能安全等级有所不同，AI单元内核系统QM~ASILB，计算单元内核系统QM~ASILD，控制单元内核系统ASILD，因而出现不同安全等级的多内核设计或单内核支持不同安全等级应用的设计。保证差异化功能安全要求的同时满足性能要求，是车控操作系统系统软件设计的关键。另外，车载智能计算基础平台的复杂性也要求内核对功能软虚拟化管理(Hypervisor)3可移植操作系统接口(POSIX)POSIX是被主流操作系统广泛采用和遵守的标准。基于POSIX的应用可以方便在不同操作系统间移植。POSIX也能够很好地适应tiveAUTOSAR同样采用基于POSIX标准的内核系统，可使用PSE51子集的标准POSIXAPI，旨在满足未来高级自动驾驶的需求。车控操作系统系统软件基于实时嵌入式软件单元架构，可借鉴AdaptiveAUTOSAR平台思路，在不同内核系统采用POSIXAPI与应用软件、功能软件统中间件及服务并为上层应用提供基础的系统服务。其中最主要的中间件是指分布式通信服务，它主要是以发布/订阅方式为SOA应用之间提供数据和信息交换服务。车控操作系统可建立跨多内核、多CPU、多板的通用、高速、高效的通讯和数据共享机制。采用发布/订阅架构的分布进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需P。能服务操作系统。安全域操作系统主要包含硬件抽象层、基础软件、实时(二)功能软件层车辆应用建立在功能软件基础上，功能软件通过统一应用软件接口为应用软件提供调用和服务。应用软件的开发和运行可以不依赖具体传感器和车型。不同的市场参与方(包括政府主管机构、主机厂、供应商、高速路或停车场等交通设施管理者和个人)(二)功能软件层车辆应用建立在功能软件基础上，功能软件通过统一应用软件接口为应用软件提供调用和服务。应用软件的开发和运行可以不依赖具体传感器和车型。不同的市场参与方(包括政府主管机构、主机厂、供应商、高速路或停车场等交通设施管理者和个人)都可以开发应用。应用可以被打包、部署、启动、调度和升级。应用程序功能软件是车控操作系统根据面向服务的架构设计理念，通功能软件是车控操作系统根据面向服务的架构设计理念，通过提取智能驾驶核心共性需求，形成智能驾驶各共性服务功能模块，驶通用模型、功能软件通用框架，以及数环境模型作为智能认知框架，为智能决策和智能控制提供模型化的广义环境信息描述。环境模型调度各类感知、融合和定位算法，对传感器探测信息，车-路、车-车协同信息，环境模型作为智能认知框架，为智能决策和智能控制提供模型化的广义环境信息描述。环境模型调度各类感知、融合和定位算法，对传感器探测信息，车-路、车-车协同信息，以及高精地图先验信应用程序构建在更为抽象的环境模型、车辆模型、任务模型和应用程序构建在更为抽象的环境模型、车辆模型、任务模型和资源模型之上，相比功能软件有更好的可移植性，能够跨车型、跨计算平台部署。和功能软件相比，应用程序更侧重于业务而不是功能，更偏向用户侧而不是系统侧，更关注目标而非方法。应用程序可以构建在功能软件所提供的服务上，也可以直接构建在环境和车应用程序接口不仅涉及到应用程序的运行，还应涉及应用的开发和管理类接口。系统软件供应商应该为应用软件开发提供统一的驾驶通用模型智能驾驶通用模型是对智能驾驶中智能认知、智能决策和智能控制等过程的模型化抽象。智能驾驶通用模型由环境模型、规划模息进行处理加工，提供探测、特性、对象、态势、场景等各级语义控制模型主要由常规工况和降级工况组成，其中常规工况主要D策、控制计算及执行输出等。针对上游及底盘信息的输入，以及控制输出均需要适配层去匹配不同的功能算法框架平台及车辆平台；针对横纵向及紧急控制等算法模块需要进行故障诊断、配置及标定规划模型根据环境模型、自车定位、个性化设置和自车状态反控制模型主要由常规工况和降级工况组成，其中常规工况主要D策、控制计算及执行输出等。针对上游及底盘信息的输入，以及控制输出均需要适配层去匹配不同的功能算法框架平台及车辆平台；针对横纵向及紧急控制等算法模块需要进行故障诊断、配置及标定功能软件通用框架是承载智能驾驶通用模型的基础，分为数据数据流框架向下封装不同的智能驾驶系统软件和中间件服务，向智能驾驶通用模型中的算法提供与底层系统软件解耦的算法框架。数据流框架的主要作用是对智能驾驶通用模型中的算法进行抽象、数据抽象数据抽象通过对传感器、执行器、自车状态、地图以及来自云端的接口等数据进行标准化处理，为上层的智能驾驶通用模型提供各种不同的数据源，进而建立异构硬件数据抽象，达到功能和应用基础服务是功能软件层共用的基本服务，其主要服务于智能驾驶通用模型或功能应用，但其本身不局限于智能驾驶。基础服务平台包含可靠冗余组件、信息安全服务、网联云控服务，其中可靠冗余组件将系统中其它所有软件和硬件模块都抽象为被管理实体，通过与所有被管理实体的交互，完成对整个系统的监测和故障处理；信息安全基础服务中的数据安全服务为车端数据定义了数据类型和安全等级，为车端功能和应用所需不同类型数据在不同车辆运行场景下制定安全策略和数据处理规则。数据流框架上的算法部署和数据流编排模块，按规则定义控制算法部署和数据交换。网联云控服务可提供操作系统的安全冗余信息、超视距信息和通用模型的信息，数据抽象数据抽象通过对传感器、执行器、自车状态、地图以及来自云端的接口等数据进行标准化处理，为上层的智能驾驶通用模型提供各种不同的数据源，进而建立异构硬件数据抽象，达到功能和应用针对不同的模块，如环境模型、规划模型、算法模型等，操作系统应提供不同类型和颗粒度的应用软件接口。应用软件接口应具有灵活性，如可以接受不同类型的参数，运行模糊逻辑等。应用软接口进行增强和优化。(一)智能驾驶通用模型及其接口智能驾驶通用模型应提供智能驾驶所需的感知、融合、定位、规划和控制等算法以及这些算法所需外部环境和车辆自身数据的抽针对不同的模块，如环境模型、规划模型、算法模型等，操作系统应提供不同类型和颗粒度的应用软件接口。应用软件接口应具有灵活性，如可以接受不同类型的参数，运行模糊逻辑等。应用软接口进行增强和优化。(一)智能驾驶通用模型及其接口智能驾驶通用模型应提供智能驾驶所需的感知、融合、定位、规划和控制等算法以及这些算法所需外部环境和车辆自身数据的抽环境模型应提供北向接口给应用软件开发和东西向接口给规划控制算法和处理逻辑，且环境模型的对外接口需要标准化并具有灵车道检测和车道融合接口；灯及交通标识检测接口；4)道路信息和标记检测接口；口；控制模型应满足异构算法在不同场景下的部署要求。控制模型应提供开放的输入输出接口，能够适配不同类型的上下游输入信息，满足跨车型部署及搭载的要求。控制模型应提供在不同环境下的部署接口，满足跨平台搭载的要求。控制模型应能够提供故障诊断、配置及标定接口，满足车规级的开发要求。控制模型接口主要包括：规划模型接口规划模型应能根据环境模型信息、功能配置输入、车辆状态反馈信息预测未来一段时间内的交通参与者的运动状态，并且及时做出正确的行为决策，为运动规划提供行为策略和约束条件，最终输出符合车辆运动学和动力学约束的轨迹，同时满足实时性、安全性、迹预测接口；口；导航服务接口；基础服务类接口应满足可配置、可调试、可升级的基本要求，同时，基础服务应做到高效、轻量级，对智能驾驶的实时算法逻辑(二)功能软件通用框架及其接口功能软件通用框架应满足高性能计算、高可靠性和稳定性要求。数据流框架应能对智能驾驶算法进行逻辑编排和运行驱动，同时对所需数据进行实时处理和管理。数据流框架应支持高性能计算和统一的东西向模块之间的接口，使在其框架上运行的算法可以根据不同的驾驶场景进行参数和算法优化或可插扩。数据流框架接口调度服务接口。基础服务类接口运行和实时数据处理做到最小影响或干扰。基础服务类接口应包含：云控服务接口；。插扩算法框架；式管理器插扩算法框架；式管理器；(三)数据抽象接口数据抽象应满足对来自不同类型的数据源数据的统一抽象描述、标准化的数据结构定义。数据抽象应能提供上层功能和应用开发的；毫米波目标检测接口；接口；激光雷达接口；控数据接口；；车周围信号接口。与云相关的某些组件或服务在设计时应考虑可以运行在本地计算机(计算平台)或分布式联网计算机群(边缘云或中心云服务器)立更新。而计算平台底层系统和基础软件设计需要为上层服务和应用提与云相关的某些组件或服务在设计时应考虑可以运行在本地计算机(计算平台)或分布式联网计算机群(边缘云或中心云服务器)立更新。而计算平台底层系统和基础软件设计需要为上层服务和应用提各个基础服务组件间界定清晰的界面，尽量采工业界认同的接口和3)模块化：将基础服务软件功能分解成不同类型的一个或多个独立功能，功能间相互独立，方便构建上层应用，如数据收集、数据回传、OTA、信息安全、网联云控。智驾功能的基础服务也可以(一)软硬件解耦提供传感器抽象机制，支持主流类型主流型号的传感器，对新型传感器具有扩展能力。提供丰富的硬件适配服务软件，硬件适配包括快速适配硬件平台和快速适配车辆平台两个部分，其中快速适配硬件平台又包括内核、中间件、提供传感器抽象机制，支持主流类型主流型号的传感器，对新型传感器具有扩展能力。提供丰富的硬件适配服务软件，硬件适配包括快速适配硬件平台和快速适配车辆平台两个部分，其中快速适配硬件平台又包括内核、中间件、AI、安全域几个方面，快速适配执行器抽象;(二)智驾功能的基础服务分解服务间尽可能使用标准化的服务化界面；服务间尽可能使用标准化的服务化界面；通过对复杂的自动驾驶功能、算法分解，形成基础模块，状态主机厂基于自身策略，在设计和开发功能软件时可以选择不同的功能模块和算法组件，实现拼插式功能组合，灵活构建智能驾驶(三)网联云控服务网联云控服务既提供标准的、抽象的信息服务，如红绿灯信息、交通提醒信息、安全预警信息、路侧感知信息、周边车辆行驶信息，也提供可插扩算法的能力，可以新增、转换、适配不同的云控算法和应用。网联云控模块是车内外信息通信的桥梁，车辆平台可把自车状态、行驶意图广播到周围环境中或上传到云平台，同时也可从周围环境或边缘云获得感知信息(如障碍物信息)，决策规划建议，V2X道路信息，实V2X道路信息，实现车路协同。车辆通过订阅云端感知和规划数据，充分利用云端的算力和多维度场景信息，实现运控应用场景。比如拥有感无缝对接现有V2X场景，支持云控应用和云车协同应用。通过5G低延时、高速率的通讯技术支持数字孪生，实现车内计算、应用向(四)信息安全服务基于信息安全技术(详见第7章第五节)，可以建立多种遵循SOA架构设计的信息安全服务，如网络入侵检测，信息安全监控和安全服务不依赖平台和操作系统，可以和云端的安全应用共享或无(五)系统软件系统内核、中间件等组件，可为上层功能软件提供一个稳定、高效、采用可保障各类应用系统具备一定隔离性的Hypervisor技术，将成为实现高性能智能驾驶操作系统的关键。比如，针对车辆计算和实采用可保障各类应用系统具备一定隔离性的Hypervisor技术，将成为实现高性能智能驾驶操作系统的关键。比如，针对车辆计算和实3)中间件：是隔离系统软件和应用服务的关键部分。特别是通EMSOASDKLL对不同应用分类提供共性的算法集和模型(包括环境模型、规划模型、控制模型)，通过应用软件接口(SDK/API)支撑应用开发者实LL的传感器和其他硬件类型以及所提供的数据抽象、接口服务和开发工具，实现完整的、定制化的自动驾驶应用功能开发(例如ACC、LKS、HWA等)。A(一)SOA与内核(二)容器IT行业流行的Docker是一个开源应用容器(container)，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后Linux以实现虚拟化。容器是完全使(二)容器IT行业流行的Docker是一个开源应用容器(container)，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后Linux以实现虚拟化。容器是完全使用沙箱机制，相互之间独立。容器上的服务软件可以独立开发，安r库容器、储存容器、队列容器等标准容器。每个容器承载一个独立运行的微服务。应用软件可以拆分成若干个标准化容器，像搭积木一样组合起来，通过约定好的协议彼此通信，从而形成复杂功能的在车云协同和网联云控的场景中，车云一体化中的一个应用可以拆分成几个运行在车载平台和云端平台上的服务。例如感知服务和执行服务运行在车端，而路径规划服务运行在云端(边缘云)。发引用到车辆应用设计中，从而彻底解耦应用程序对平台和底层系(三)虚拟化技术多以及这些服务的规模不断增大，实现和支持这些服务的基础设施虚拟化技术日益重要，因此虚拟化和(三)虚拟化技术多以及这些服务的规模不断增大，实现和支持这些服务的基础设施虚拟化技术日益重要，因此虚拟化和SOA之间相辅相成、相互影响。传统应用平台限制，以快照形式捕捉各种服务的能力并使其可用于1)硬件虚拟化：通过软件方式或者硬件方式将服务器的硬件分成2个或者多个单独的区，每个区都可以安装相同或者不同的操作器和操作系统之间的中间软件层，可允许多个操作系统和应用共享2)终端虚拟化：通过分流、虚拟化以及界面代理技术，即时设3)服务虚拟化：为建立和管理复杂的服务生态环境提供一个通用的基础设施，开发人员只需把重点放在新功能的建设，无需担心性，从而在分布式基础设施上对其生命周期进行管理也很难，性，从而在分布式基础设施上对其生命周期进行管理也很难，因此个平台信息是一个非常重要但很难实现的要求。我们可以对信息访殊的优点，可在机器或集群层通过分布式资源提供任务负载虚拟化。(四)通信技术准化，动态建立通信关系，连接信息孤岛，达到屏蔽系统异构性，实现互操作的目的。当前主流的面向服务的通讯采用DDS与IP(1)DDSDDS用于分布式应用程序通信和集成的以数据为中心的发布-订阅(DCPS)模型。DDS是将分布式系统的组件集成在一起的中间件以保障数据进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需求。在该架构下分布式节点在网络上以发布或订阅的方式传输数据，节点可以是发布者或者订阅者，或两者都是。网络中的数据对象用主题做标识，分布式节点在全局数据空间中发布或订阅感兴趣的主题信息。各个节点在逻辑上无主从关系，点与点之间都是对等关系，通信方式可以是点对点、点对多、多对多，在QoSDDSDDS促进了松散耦合、模块化和开放式架构系统的开发，从而降低了复杂性、上市时间和系统成本。AUTOSARAdaptive定义了(2)SOME/IPSOME/IP沿用了服务器和客户机(Server-Client)的模型。Server向外提供高精地图数据(OfferService)，ADAS控制单元想要订阅其车道线相关信息(SubscribeEventGroup)，高精地图Server同意其订阅请求(SubscribeEventGroupAck)，而后Server02实时以太网技术时间敏感网络(TSN)技术作为新一代以太网技术，因其符合标准的以太网架构，兼具精准的流量调度能力，可以保证多种业务流量的共网高质量传输，被公认为是新型车载实时以太网技术。1级(共计8个优先级)，并进行流量整形(shaper)，在网络出口(Egress)进行队列调度(scheduler)，为每个队列内的任意流量分时延需求。23DDS与TSN联合调度TSN网络之上。此规范将主要(五)SOA架构中的信息安全技术TSN网络之上。此规范将主要(五)SOA架构中的信息安全技术重要组成部分，采用经典的信息安全技术建立可信操作系统运行环境，包括安全启动、安全加载、硬件信息去敏、用户认证、操作系统权限控制、数据安全、数据隐私保护等。附件B是来自谦川科技3DDS的安全模型定义了安全主体(系统的用户)、对象被保护，以及对被限制对象的操作。DDS应用程序共享有关DDS域的信息(Topic)，并对这些DDS的安全模型定义了安全主体(系统的用户)、对象被保护，以及对被限制对象的操作。DDS应用程序共享有关DDS域的信息(Topic)，并对这些Topic相关的数据实例进行读写操作来访问。本和包含它们的消息的完整性；DDS者的身份验证；DDS作者和读者的授权；；性。为了提供对DDS域数据空间的安全访问，使用DDS的应用程序必须首先经过身份验证。获得身份验证后，下一步是实施访问控制，DDS可ManagementGroup)提出的DDS安全模型。41)身份验证服务插件：提供验证应用程序身份的方法和/或调2)访问控制服务插件：提供强制执行有关DDS安全策略，例题等；3)加密服务插件：实现所有密码操作包括加密、解密、散列(HASH)、数字签名等。这包括从共享秘密导出密钥的方法；5)数据标记服务插件：提供一种向数据样本添加标签的方法，(六)OTA技术OTA技术是实现SOA应用更新的重要基础也是软件定义车辆的基础功能。OTA是指通过云端来升级或更新车辆平台中的功能组件、5MIOTAOTA理平台；OTA车端与云端安全的网络连接。(七)云原生云原生(cloudnative)是一种构建和运行软件应用程序的现代方法，它利用云计算的灵活性、可扩展性和弹性。云原生包含当今软件开发人员用于为云计算构建应用程序的各种工具和技术，而不仅适用于本地数据中心的传统架构。云原生的基本要求之一是能够解耦软件从硬件。应该可以确保可以轻松部署工作负载到不同的硬件，而无需根本上重新构建底层软件。云原生被引入汽车应用开发和部署，带来云原生开发的好处解决汽车领域特定挑战和限制的环境。例如功能安全(FuSa)和快速精确的实时控制。云原生本质是面向服务的解决方案，鼓励使用技术例如基于最先进技术的容器、ARM公司成立了基于云原生的SOAFEE项目，项目汇集了汽车制造商、半导体和云技术领导者为软件定义的新的开放标准定义架6(一)基于微服务和容器的车道保持众所周知车道跟随系统的核心任务是检测和跟踪正常道路上的车道街道边界，用两条线标记当前车道。系统根据检测到的车道中心的点计算形成虚拟轨迹，并且下达转向和加速指令给CANBus，化技术部署，微服务之间访问全部通过以太网，众所周知车道跟随系统的核心任务是检测和跟踪正常道路上的车道街道边界，用两条线标记当前车道。系统根据检测到的车道中心的点计算形成虚拟轨迹，并且下达转向和加速指令给CANBus，化技术部署，微服务之间访问全部通过以太网，CAN首先将摄像头和车身控制封装成两个原子化的微服务用来屏蔽硬件层和算法层，这里需要注意的是微服务的颗粒度问题，一般来说车身控制可以具体细分为转向加速等一系列更小颗粒度的原子操作，所以这里到底是用一个大的车身控制服务将业务事先组装好，7还是拆分为若干个细小的原子化服务让上层调用方自己组织业务，道路检测服务推理出的结果会被道路保持服务消费，道路保持服务会根据各个车型的逻辑，比如车道纠正的驾驶感受是否激烈，是否容许一定阀值的道路偏移等综合输出车身控制指令，然后通过OA道路检测服务推理出的结果会被道路保持服务消费，道路保持服务会根据各个车型的逻辑，比如车道纠正的驾驶感受是否激烈，是否容许一定阀值的道路偏移等综合输出车身控制指令，然后通过OA(1)OpenDLV8OpenDLV是一个基于微服务实现车辆自动驾驶的开源框架。OpenDLV框架集成了硬件通信层，传感器融合层，并提供安全以及(2)DockerDoc