中国汽车工业协会-汽车行业：中国汽车基础软件发展白皮书4.0

中国汽车基础软件(三)研究范围 1.车端平台 3.设备端平台 3.整车仿真 1.领域知识库 3.实现技术 1.开发方法论综述 Ⅱ六国产整车软件开发平台问题与展望 1.国产基础软件装车量待提高 3.生成式人工智能(AIGC)在整车次件开发 一、整车软件开发平台概述近年来，汽车电子电气架构走向集中化，跨域融合作为其核心内涵之一，意在将多域功能开发挂载至集中统一平台，大幅提升整车软件的开发效率与协同性。现加速体系化创新，在此趋势下，2022年发布的白皮书3.0,即聚焦通用基础软件平台架构和技术，在参考2019版汽标委《车用操作系统标准体系》的基础上，从安全车控、智能驾驶和车载信息娱乐三个方面开展了系统阐述，以构建安全、可靠、稳定的基础软件底座，助力打造整车软件开发平台，实现高阶软件定义汽车。本次发布的白皮书4.0,将基础软件开发理论和经验延伸至整车软件元发平台，将服务对象由车端扩展至云端、loT(IntemetofThings,物联网)端，同时吸收ICT(inormatisandCommunicationsTechnology,信息与通信技术)领域先进理念，结合AlGC(AntificiateeneGeneratedContent,生成式人工智能)等先进技术，围绕SOA(ServiceOrientoArc面向服务的架构)、云原生、仿真、知识库等，探讨整车软件开发平台的关键技术、实政案例与发展书势，旨在为整车软件平台产业链参与者提供有益的指导和参考。第一章整车软件开发平台概述：介绍了目皮书的研究营景和国内外整车软件开发平台的发展现状，同时对整车软件开发平台进行定义和概述。第三章整车软件开发平台的应用介绍》开发方法论，以及包含车控、智驾、座舱在内的整车软件开发平台的典型应用。第四章整车软件开发山发展：以平台化、标准化、开放化、知识化等维度为切入点，研究了整车软件开发平台的发展趋势。第五章国产整车软件开发平台生态介绍：以生态图谱的形式描述了国产整车软件开发平台生态的发第六章国产整车软件开发平台问题与展望：一方面对整车软件开发平台当前存在的问题以及未来发展提出建议，另一方面结合AIGC技术对国产整车软件开发平台的未来发展进行展望。1.整车软件开发平台现状构建整车软件开发平台目的在于实现高效地开发、部署和更新软件。目前，各家的整车软件开发平台正处于快速发展阶段，呈现的主要特征为：集成化、平台化、虚拟化及云端化，根据整车软件应用场景，将各域发展现状总结如下：1.1车控域软件相对成熟车控域(包含：动力域、底盘域、车身域等)软件功能可实现网关信号路由转发、面向服务通信以及对动力、底盘、车身等各模块的控制。车控域基础软件是应用软件与硬件交互的桥梁和通道，设计理念充分 借鉴了模块化、平台化思想。此外，由于整车域基础软件覆盖控制器种类多样，驱动复杂，故基础软件编程语言必须采用C语言或汇编语言等实现通讯，常用软件平台包括AUTOSARCP、Scheduler、OSEK/1.2智驾域软件发展迅速辅助驾驶技术和功能已经日趋成熟，新车搭载率超过50%,智驾体验与场景覆盖度成为众多消费者购车考虑的核心要素。L3/L4高级别自动驾驶技术尚处于测试、示范阶段，规模化应用尚需时日。智驾软芯片算力要求较高，软件迭代速度快，通常采用AUTOSAR方法论并基于AUTOSARAP平台开发。1.3座舱域软件生态丰富智能座舱领域是主机厂研发布局的焦点，是整车智能化、差异化竞争力的核心体现，主要包括：HUD(HeadUpDisplay,抬头显示)、仪表盘和车载娱乐信息系统三部分组成。智能座舱领域的发展主要围绕人的体验和需求展开，座舱域软件设计主要涉及到对传统功能的整合，人机交互方式的提升，其它数字化衍生服务等。智能座舱软件通过对舱内和交互数据采集，并上传到去端进行处理和计算，从而对资源进行最有效地适配，以增加座舱内的安全性、娱乐性和实用性。座能对实的性要求相对较低，但在动态部署等方面需要较高自由度，目前大多基于AUTOSARAE中开发。2.整车软件开发平台问题现阶段，我国整车软件研发以及SOA架构的应用均处于起步阶身，整车软件开发存在开发流程落后、2.1开发流程难以匹配技术革新速度由于汽车行业的数字化、网联化和智货化发展的物，车软件也在不断演化，现有AUTOSAR等标准仍然存在许多功能需求无法满足的情反、如特定领域需求、高性能需求、人工智能等新兴技术关联需求一级零部件供应商、二级零部例供应商等不同的并发团队采用不同的流程、方法和标准，导致软件兼容性2.2工具链复杂、兼容性欠整车软件开发所使用的工具链需要涵盖多种功能模块、跨越多个开发层次、适应多类供应商平台，并且还需要兼顾安全性、平台性和规范性要求。从驱动软件、系统软件、功能软件，再到上层应用软件和用户界面，都需要工具链支持。但是不同供应商、不同软硬件平台所对应的工具链差异显著，造成开发通用2.3安全标准规范体系不完善整车软件开发过程中，标准规范多数遵从国外体系，其中信息安全、功能安全标准尤为突出，自主制定的标准体系相对匮乏。整车软件标准体系发展节奏与汽车智能化发展速度失衡。推行自主软件标准化体系建设，减少软件之间兼容性差，提高软件安全性和稳定性，促进汽车自主软件产业链协同发展已成软件定义汽车，已成为行业共识。主机厂正朝着软件公司方向转型，国内外多家主机厂正在着力打造其专属整车软件开发平台。一汽于2021年制定了“十四五”战略规划，面向社会发布“飞刃计划”,打造完全自主可控的全栈向上为应用软件提供丰富且标准的服务，以支撑软件灵活迭代，为用户提供千人千面的用户体验。FAW.通A框架FAW.OS在平台设计方面最大化保障兼容性与动展性。在硬件层面上，通过虚拟化组件层、操作系统接口抽象层、统一的Al框架隔离硬件平台差异建立适记层向下兼容多种软硬件平台，避免“芯片卡脖子”问题，而且还预留了足够算力，以轻公远行更多更好用的APP。在软件层面上，通过统一的SOA服务层服务2。.上汽云管端一体化氧件平台如图1.2-2所示，上汽电团法研发的“零束云管端一体化SOA软件平台”全力打造核心技术基础平台产品，打破了传统汽车软领件强耦合及“孤岛式”开发，实现智能车“车云一体、跨域融合”的硬件数字化和软件服务化开发，探索出硬件“可插、可拔、可扩展”、软件“可买、可卖、可订阅”全新商业模式，同时引入开发者和loT生态，助力智能汽车行业创新发展及应用生态建设。图1.2-2上汽云管端一体化软件平台 这一软件平台已在智己汽车、飞凡汽车的多款量产车型中落地。3.大众vW.oS大众操作系统VW.OS是CARIAD(大众汽车旗下软件子公司)技术栈中所有基于软件的功能的核心。VW.OS通过结合各合作伙伴提供的解决方案，形成一个可扩展和统一的软件平台。VW.OS的架构如图1.2-3所示。图1.2-3VW.0S系统架构VW.OS由SDK(SoftwarebwelopmentKit,软件开发工具包)、参考应用程序、运行时软件组件、嵌入式软件以及云化工具链组成。VW.OS通过与VWAC(大众汽车云)、大循环数据聚合系统(BigLoop)联合工作，形成整车软件开发平台。VW.AC是大众云服务，负责车辆数据向云上迁移。大循环数据聚合系统是一种持续收集数据并驱动软件功能进行改进的方法。VW.OS的特点如下：●一致的开发平台VW.OS为开发人员提供面向车辆所有域的一致的开发环境。●大循环数据聚合系统和增强定期的OTA(Over-the-Air,远程升级)通过大循环数据聚合系统，不断持续收集数据，并驱动软件功能改进，通过OTA,使用户能够在整个车辆使用周期内从新的创新功能中受益。●跨品牌的软件基础通过解耦的分层架构、面向服务的设计方法，实现更简化、高效和可扩展的软件开发。AreneOS是丰田推出的整车软件开发平台，由工具、整车平台和数据中心这三部分组成。作为一种结合了构建工具和车载软件服务的综合平台，AreneAreneOS的构成与功能如图1.2-4所示。OS目的在于实现整车软件的快速开发与部署。软件平台十社会系统与车一投供后高人与车AreneOS的特点如下：●标准化的开发平台AreneOS为丰田和供应商提供共同中合和标准化流程。通过Arene,丰田和供应商能够确保跨流程可见性，并简化集成和测试过程。●自动化、虚拟化测试AreneOS扩展并加这了软件测过。rene部署了全流程的自动化测试。同时通过仿真技术，使物理测试与虚拟测试相结合，加入针对也件功能的离散独立分析，确保研发质量。●数据、OTA和迭代开发工具通过整车数据、车辆数据分析，持续获得需求，并通过迭代的开发方式和OTA,形成数据闭环，持续改善品质与功能，从而延长了车辆的价值。●整车软件开发平台AreneOS整合了车辆的各个域，使汽车制造商能够提供更丰富、更全面的用户体验。车载计算资源可以在系统之间共享，使车辆能够以更少的资源实现更多功能。●应用程序的可移植性和可重复使用性AreneOS旨在最大化软件的价值。通过标准化接口、解耦的软件分层和先进的测试协议，AreneOS开发的程序不仅在不同平台之间具有可移植性，而且在同一系列不同年代的车辆之间也具有可重复使用性，从而获得更大的投资回报率。总体而言，整车软件平台在全球范围内都得到了广泛关注和发展。不同国家和地区的汽车厂商纷纷加强整车软件研发和创新，以应对日益增长的网联化和智能化需求。 (三)研究范围整车软件开发平台的架构如图1.3-1所示。露端中心测过试.工真链(开发·仿真，调测过试.等)标准车端平台云端平台AIOT端平台整体结构可以分为软件平台、数据中心、工具链以及开发相线的材准现危，真中软件平台根据部署的终端不同，可以进一步划分为车端平台、云端平台和设备端平台。在整车软件开发平台的组成中，有两个重要的框架，为别为中国软件评测中心发布的车载智能计算基础平台参考架构2.0和中国基础软件生态标委会机手行业内生流车企和零部件企业提出的整车服务框架ASFAUTOSEMOServiceFramework车penhe图1.3-2车载智能计算基础平台与ASF框架如图1.3-2所示，整车软件开发平台融合了车载智能计算基础平台参考架构2.0和ASF框架。车载智能计算基础平台为应用软件提供感知、决策、规划、控制及Al端到端大模型等模型库，以及网联云控、信息安全、数据安全、车端LLM(LargeLanguageModel,大规模语言模型)等基础服务，支撑安全、实时、可扩展的多等级自动驾驶、驾舱融合、车路云一体化等应用。在面向高实时、高性能要求的自动驾驶域控上，融合车载智能计算基础平台的自动驾驶操作系统，共同打造整车软件开发平台。ASF框架是面向域控制器打造的SOA框架下的中间件，基于标准基础软件向上扩展，解决域控制器异构芯片跨核融合问题，实现域控制器的统一开发视图。ASF框架是开放的分布式服务框架，通过ASF规范统一服务和接口定义，梳理服务开发环境与运行环境，用于打造高效、集成便捷的整车软件开发平台。白皮书4.0着重研究车端平台相关的开发技术，云端平台和设备端平台仅在本章节进行简要介绍。1.车端平台车端平台用于智能车控，智能驾驶，智能座舱等车端软件开发。智能车控：包括动力系统、底盘系统、车身系统、电池管理系统、网联控车系统等，其特点体现为高安全、低算力、强实时(微秒级)、与车辆安全行驶强相关。当前AUTOSARCP的标准化在车控基础软件上取得了巨大成效，从主机厂到一级零部件供应商、工具链厂商都遵循这一标准开发产品。智能驾驶：其特点体现为高安全、高算力、实时性(毫秒级，确定时间范围内)、与车辆行驶安全强相关。当前未形成统一的技术路线(ROS/Linux/AUTOSARAP),不过AUTOSARAP已作为其中较为成熟的一项技术初步显现技术价值，其中关键技术是软件算法与模型。智能座舱：其特点体现为中安全、高算力、中实时(毫秒级)、行驶安全弱相关，但有强人机交互需求。主要包括中控大屏、数字仪表、流媒体后视镜、HUD、标车记仪等。当前未形成统一的技术路线(Android/AGL/AUTOSARAP),可预见的未来仍然会多路并行。2.云端平台云端平台用于云端软件开发。例如，通过平台服务可以精地自定义到某终端，设置采集频率和上报频率，将车辆CAN(ControllerAreaNetyors电行通信办议)数据中的每个参数通过压缩等方式传输到网关服务，由该服务同一入口来动态地匹已解析有AN数据协议的内容。之后，可将数据再转化为业务数据，提供业务能力支撑，如使查询、迹分析、车辆诊断等，以供各业务方使用。3.设备端平台设备端平台主要指广泛的oT设备及相关的生态应用。AloT=Al(人工智能)+loT,是一种新的loT应用形态，是人工智能技术与勿联网在实际应用中的落地融合。AloT的目标是实现主动智能服务，即智能系统根据用户行为偏好、户画像、环境等各类信息随时待命，具有自学习、自适应、自提高能力，可主动提供适用于用户的服务、而无需等待用户提出需求。从技术角度来讲，利用Al/ML技术驱动的智能视觉、智能音频、智能语音以及融合感知应用是人工智能物联网落地的先发业务。其中汽车是AloT的一种重要终端触点，同时AloT智慧交通)结合，与出行和生活场景深度融合，创造更多的应用价值。4.数据中心数据中心主要指整车数据中心，用于数据存储与分析。众所周知，数据中心也经从最早期的单台服务器运行单一应用程序，到服务器虚拟化，将一台高性能服务器虚拟成多个虚拟机来运行不同的应用。目前数据中心正处于第三个时代，即基于可组合的基础架构、微服务和特定域处理器，通过使用分解和编程控制等概念，使用软件定义的技术，以在数据中心内汇集计算、存储和网络结构等资源。基于该设计，不同的处理器可根据最优方案加速不同的工作负载；可以将计算、内存和其它资源分成多个池，并以适当的数量动态地分配给服务器和应用程序。5.工具链整车软件开发所需要的工具链，覆盖设计到验证阶段，是整车软件开发平台的重要组成部分，在车L端平台上，目前主要应用的工具链可以分为如下几类：●设计工具。类似于Simulink的图形化编程工具，可以用于功能建模、仿真和验证。●编译器和集成开发环境。即针对特定嵌入式处理器的编译器和开发环境，如ARMKeil、IAREm-beddedWorkbench等，可以用于开发底层的驱动程序和基础软件。●模拟和仿真工具。通过该工具，使开发人员能够在虚拟环境中测试软件并验证功能和性能，从而减少对实际环境的依赖。●开发流程管理工具。即版本管理系统、协作工具、自动化测试和持续集成工具等，使开发团队能够更好地合作，以保证软件开发的效率和质量。●调试和测试工具。调试工具如LauterbachTrace32等，用于调试嵌入式代码。测试工具如Vec-torCAST、LDRA等，用于代码静态分析和动态测试。工具链在演进上借鉴了ICT领域的经验，将互联网在云端开发的框架引入车端。工具链呈现的特点为，吸收云原生的概念，形成跨域工具链、云化工具链、车规级容器以及打造DevOps开发体系，大幅提高开发效率和生态建设能力。6.标准规范汽车软件开发标准旨在规范汽车软件的开发流程、技术要求个质量管理、测试验证和文档编制等，以提高汽车软件的质量和效率，确保汽车的安全性和可靠性《当前已有的精准举例如下：●AUTOSAR:汽车开放系统架构。它是一套用于汽车响子系统的开放式标准，旨在提供一致的软件体系架构。它定义了软件的架构和接口，促进了不同EC之间的软件复用。●ISO26262:道路车辆功能安全国际标准。内容主要润盖汽车系统、软件、硬件等方面的安全完整性，强调在汽车产品的开发过程中如他避免、预防、探测、降低或消除风险。ISO26262标准提出了ASIL(即汽车安全完整性等级分为B、C、D四个级别，其中D为最高级)的概念，它会影响到产品开发阶段中各种技术手段的推荐程度。●MISRAC:汽车工业软件可靠性协会MISRA,MotorIndustrySoftwareReliabilityAssocia-tion)制定的一套铀对C语言的编码准则，旨在提高C语言代码的质量和安全性，有助于减少代码缺陷并提高代码可靠二、整车软件开发平台的核心技术本章节详细介绍整车软件开发平台中运用的SOA、云原生、仿真以及知通过开发协同方式、运用的核心技术这两个维度的差异，我们将技术形态分为经典技术形态和创新技术形态。本节将对经典和创新这两种技术形态分别进行概述。1.经典技术形态1.1开发方式多为单点开发当前电子电气架构正处于分布式向中央集中、区域控制转化的过程所以高然存在不少单点开发的情况。究其原因，总结为如下两点：●分布式电子电气架构：各个控制器之间数据交互少且每制负责的功能简单，所使用到的技术单一，所以可以采用单点开发模式。●安全和稳定性要求高：汽车是一种复杂的机械皮备，安全和稳定性对于汽车电子系统来说至关重要。通过单点开发模式，汽车制造商可以更好地率心随着电子电气架构演化速度加快，从业考已意到需要更快速、更具创新性的开发方式来满足不断变化的市场需求。因此，多团队协同开发度式正可新成》主流，以便更好地提升开发效率和创新能力，加速产品上市。1.2当前主流开发技术当前主流开发技术见表2.12.1-1当前主流开发技术sign,基于模型设计)·MATLAB/Simulink:建立车身控制系统模型，进行仿真和测试。MATLAB/Simulink模型与AUTOSAR的结合：通过AUTOSAR字典的配置、创建AUTOSAR模型、添加AUTOSAR配置、生成符合AUTOSAR标准的SWC,实现Simulink模型与AUTOSAR标准的结合，为车身控制系统提供符合AUTOSAR标准的软件组件；套完整的开发工具链。静态代码检查工具为Polyspace。多采用实时操作系统，主要有FreeRTOS,IN-TEGRITYRTOS,AU-TOSAROS等·基于ClassicPlatformAUTOSAR标准的MCU端的OS监控和优化工具，如：gliwaT1和VectorTA-toolsuit。中间件●开发工具：Vector的DaVinci、EB的Tresos、ETAS的ISOLAR、达索的AUTOSARBuilder、东软睿驰的NeuSAR、中汽创智CAIC·CP等；片专用的调试工具；·测量标定工具：ETAS的INCA、Vector的Canape等。智驾系统级芯片)操作系统主要是QNX或Linux·Linux:GCC编译，GNU调试等。中间件·AUTOSARAP:Vector的AdaptiveMICROSARETAS的RTA-VRTAFEB的Coebos、TTTech的MotionWisoK工的SARAdaptive,Mentor的CapitalSTA3、普华基础软件的ORIENTAISAdap-tive、东软驰的NeUSARDS、中汽创智的CAIC·-·以数据为中心的OMGDDS:RTI的ConnextDDSePro.ima的FASTDDS、GreenStrone的SWIFTOSAutoCore的AutoCore.OS软件平台等。掘等在内的一体化数据闭环解决方案。从大类角度，可分为：数据可视化平台、数据标注平台(包括自动化标注)、数据管理平台等。·传统仿真测试：HIL、SIL,国产代表昆易等；展进化出的以TESLA为代表的训练数据/场景/多传Constellation等。SoC操作系统主要是QNX或安卓·安卓：使用AndroidStudio作为主要开发工具，它提供了丰富的开发工具和调试功能，包括代码编辑器、调试器、虚拟设备等。中间件多选用AdaptivePlat-GENIVI(GENMI提供一套基于Linux的座舱中间件，用于连接座舱内的各个设备和应用程序)·选用AUTOSARAP的场合，工具链介绍同智驾部分·GENIVI:使用GENIVIDevPlatform(GDP)、GENIVIDevelopmentPlatform(GDP)等。2.创新技术形态2.1开发方式转为协同开发当前智能网联汽车的研发复杂度在不断提高，总结有如下几点：●用户场景导向研发复杂度高。伴随着智能网联汽车在市场占有率的提升，用户需求和体验成为各家主机厂的研发导向，驾乘体验将不再只是传统的交通工具，如何抓住相户的场景体验，提供丰富的具象化人体感受，将使智能汽车应用场景和功能需求大展，用户应用场景在整个研发过程都会经过复杂的数据化和结构化转化。●研发技术栈多维复杂度高。智能网联汽车的研发技术栈只从传统的电子电气嵌入式方向，逐步扩展为云计算、5G通信、人工智能和新能源电池等多维方向。这代表着整个汽车供应链的参与方已不再只是传统的零部件厂商，基础设施厂商、台商和软件研发厂商都成为了供应链中的一环。供应链规模的扩大带来的不仅是研发点术的复东度提升，也加重了管理和集成验证的难度。智能化和网联化发展的智能汽、在提供用应丰富的场景体验的同时，也悄然带来了行车安全、数据泄露、网络攻击等严重的安全问题。汽车作为车联网基本载体是智慧城市发展的重要环节，相关法规和行业监管的复系度也将不断提高，来确保智能网联汽车行业的良性安全发展。基于这些特点，汽车整在软件不发平台无法通过封闭式管理和生态圈来解决这些问题。未来协同开发体系将会成为中国汽车整气较开发平台的演进方向。接下来，我们分别从SOA云原生技术、仿真技术和知识库来介绍变革中的技术形态。2.2变革中的主流技术(1)面向服务架构(SOA)SOA全称为ServiceOrientedArchitecture,即面向服务的架构，是1996年由Gartner提出，他对SOA概念的解释为：“SOA是一种C/S(Client-Server,客户端/服务器)架构的软件设计方法，应用由服务和服务使用者组成，SOA与大多数通用的C/S架构模型不同之处在于它着重强调架构构建的松散耦合，并使用独立的标准接口"。在分析SOA未来演变趋势时，值得关注的是市场用户的消费核心观的变化，这很有可能直接决定了SOA的发展形态。随着智能网联汽车在市场占有率的攀升，消费者对于自动驾驶方面的驾乘的体验与感知将会趋于熟悉，因此对该部分消费欲望会逐渐降低。取而代之的是，场景化智能化的融合消费体验，如车内娱乐、跨平台社交等向车外衍生的电子消费能力。用户消费观的转变将影响市场反应与产品发展导向，因此如何快速响应用户市场需求，从需求侧转向产品侧快速迭代，成为了各家企业的必争之地。用户不懂什么是SOA架构，也不明白SOA的技术优势，他们只关注日益多元增长的驾乘体验功能。这些 速迭代的底座。因此SOA架构的未来演变趋势也将建立在跨域融合为用户展示消费价值较高的功能上。上层应用软件与SOA基础软件平台的关系如图2.1-1所示。安全体系根据博世的定义，当前整车可分为五大能域，即动力总成域、底盘域、车身域、智能座舱域和自动驾驶域。当前主流主机厂的So构规划思路为通过实现部分域的融合，实现中央计算平台+区域控制随着汽车芯片的算力较传统汽车工业模式已有了长足的进步，域控制器或中央计算平台都是基于平台的芯片算力甚至可达千TOPS。芯片的算力在基础物理层面为SOA架构的跨域融合，最终演化成融合整车全域提供了土壤。但是必须正视汽车芯片当前的集成算力现状并不足以完全支撑中央集中式架构，因此各主机厂只能通过电子电气架构来搭建SOA架构。从长久的未来看，整车驱动的全域融合必须要有整车层面的基础软件平台架构来支撑。中央计算平台的演进将最终带动整车SOA跨域融合的能力。②演变趋势二：零部件协议标准化转化虽然主机厂提供的SOA架构基础软件平台具备软硬件解耦能力，但是实际生产集成中各主机厂厂商的零部件往往都是非标准化的，操作系统并没有自带非标零部件的协议。这是由于传统汽车工业所带来的遗留问题，在零部件上存在大量定制化的设计，形成了大量非标零部件。因此需要SOA架构的基础软件平台来补充这些零部件的协议转化，以此才能为上层应用软件层提供可用的API。从技术上来说，这并不是一个严重的问题，因为提供标准化接口正是SOA架构的优势。但从全局上看增加了整车集成验证的时间成本，也无形中增加了上层应用软件的代码复杂度，锁死了代码复用的可能性，降低了端到端软件开发效率。因此，SOA架构的基础软件平台在短期内必须尽可能多地对非标零部件具备协议转化能力。从长期看，整个行业应该从零部件层面推广标准化生产，从而提升行业整体的研发效率，降低产品复杂度与时间成本。③演变趋势三：真正实现繁荣的第三方研发生态圈如今各主机厂的SOA基础软件平台虽然为独立的第三方软件开发商提供了入口，使得智能汽车软件研发领域的进入上层应用软件的入行门槛大大降低。但是对比同为智能终端的手机，各主机厂的第三方研发生态圈依然是相对封闭的，例如车载应用交互界面，我们可以看到主机厂提供了多种上层Androic应用软件，但不同车型的应用界面可能略有不同。这其中有一部分原因是传统汽车工业定制化零部件的弊端在延续，导致了上层应用软件的第三方研发方缺乏后期集成验证的指导，并加重了软件适配非标零部件的研发成本，严重时会发生同一厂商不同型号的产品，交付的应用软件是独立的两套产品。另一部分原因也在于行业整体缺乏应用商城的整体架构规划。主机广虽然公开了部分SOA服务接口，但是缺乏上层应用软件研发指南和对底层硬件支持的详细说明，这客是情况在现阶段对第三方研发者都是不友好的。因此未来SOA服务接口的第三方研发生态需要突高的行业组织来规划推动：主导SOA服务接口标准化、第三方研发接入与集成指导、形成应用服务商店，以此能够消解传统汽车遗留的非标零部件的桎梏。对第三方研发者而言，可以将丰富的互联网资题纳入SDA研发生态中，针对不同用户的应用场景开发多样化的软件，既可为用户和汽车制造商创造价值，也能让第三方研发者获得收益，形成三方共赢的良性循环。(2)云原生云原生是一种构建和运行软件应用程序的现除方法，它利用了云计算的灵活性、可扩展性和弹性。云原生包括当今软件开发人员用来为公共云构建应用程序的各种工具和技术，而不是适合本地数据中心的传统架构。云原生计算基金会对云原生的定义为：专注于应用程序容器化——将应用程序分解为微服务并打包在轻量级容器中，以便在各他服务器上进行部署和编排。此定义直接点出了云原生相关的技术栈：云原生技术的发展具有互联网行业技术栈快速更迭的属性，任何一项里程碑的技术都可能会带来革命性的行业生态变化。展望未来智能汽车行业的云原生技术，既需要挖掘现有云原生技术的价值来提供整个供应链的协同研发效率，也需要关注人工智能大模型技术的影响趋势。(3)仿真技术随着汽车电动化、网联化和智能化的发展，仿真技术也在智能控制、信息通信技术方面发生了对应变化。首先是智能化发展带了更多的传感器单元，在智能控制技术迅速发展下，通过多样化主被动智能传感器来代替人类的感知，如主动型传感器：超声波雷达、毫米波雷达和激光雷达，以及被动型传感器：摄像头和红外热成像等。这些传感器以光信号或电磁波信号，主要应用于智驾控制场景和智舱控制场景。这些传感器本身具备边缘计算能力，能够对数据进行实时采集和计算。相较于传统汽车的传感器，无论在精准度识别、分辨率和探距能力上都呈现了代差级碾压。因此基于复杂场景的智能传感器仿真分析技术，需要考虑传感器信号处理和控制器数据融合的算法效果，并结合模型化方法进行验证，其具体过程如图2.1-2所示： 图2.1-2智驾系统开发测试程由于仿真测试需要贯穿自动驾驶软件、硬件和率师测试的人模型开发测试流程，因此当前主流的仿真技术平台尚不能提供贯穿流程的全栈式伤真过能力，未来智能网联汽车仿真技术的发展需要从如下几点进行突破：①加强场景数据共享：由于上卡游企业文间的场景库缺乏统一的数据格式标准，因此仍然需要大量的人工干预来建立场景库数据的行注和分析提取工作。为了更好地应对测试挑战和提高测试结果精准度，场景库的数据格式标准必参趋于统这需要行业或组织来主导推进统一化标准的建立。同时联合各主机厂、技术供应商、监管部门和研究机构共享场景数据，加强上下游协同合作关系，以此来共建基础通用场景库。②全栈式仿真平台贯穿V模型：仿真测试平台需要为自动驾驶感知、融合与决策、规控等算法的准确度、域控制器的稳定性以及整车运行的响应速度等领域提供测试环境，而大多数仿真平台往往侧重于某一方面，适用于模块化的二次功能开发与测试。当前企业需要使用混合仿真平台，借助各平台不同的仿真模块能力来达到联合仿真测试结果。实际运用过程中，仿真测试工程师需要二次人工开发接口服务来传输场景测试数据，并整合各仿真平台的测试结果，其中的时间和成本都直接影响了仿真测试验证与评价的效率。未来端到端自动驾驶逐步成为发展方向，具备贯穿V模型研发测试全过程的全栈式仿真平台将成为必然的发展趋势，同时平台也需要具备强可拓展性、允许企业仿真测试人员针对特定的测试需求快速构建和定制仿真场景。③边缘计算和分布式仿真：由于智能传感器在感知模型上需要大算力芯片支撑，随着数据处理能力的提高，边缘计算和分布式仿真技术可能会在自动驾驶仿真测试中得到更广泛的应用。这将有助于在现实交通环境中更快速地进行仿真测试和数据分析，提高测试效率。④仿真测试结果融合DevOps流程：仿真技术在本质上是测试验证技术，在整体研发生命周期上应当实现上下游研发测试数据可追溯性，从顶端上游的用户需求至下游仿真测试结果，应当实现链路闭环。仿真技术作为制造业领域的技术，与云原生DevOps技术生态存在一定的行业壁垒，因此企业与相关从业者应考虑跨行业融合的解决方案，通过接口服务将仿真测试结果融合DevOps流程。⑤AI提高场景模拟数据准确性：理论上场景模拟数据越接近真实世界，智能传感器仿真测试的准确性就能越高。为了提高场景模拟数据的真实性，可以通过引入Al分析模型来训练模拟数据基于真实世界的物理简化渲染，从而生成仿真度较高的场景模拟数据。通过返回仿真测试的评价结果至Al分析模型，进一步帮助企业挖掘具有产品商业价值的场景。(4)知识库当前汽车的研发过程是多项目团队参与+跨领域协同的复杂过程。新产品从设计到交付，需要有强管控流程来对多个责任主体进行支撑，以此来保证各个项目团队的研发与协同效率。但由于研发技术栈的多维跨领域性，各团队人员在业务上虽有相互联系，却也在各自领域的技术知识上有相当程度的独立性。为了解决跨领域协同时必然会发生的协同效率问题，除了企业强力的管控流程推进项目，更需要建立高效的企业知识库作为抓手。SOA面向服务的架构，是一种软件设计和开发的思想OA更则上开放标准与软件资源进行交互，因此可以跨越厂商、产品与技术。电子电气架构演进方式如图2.2-1所示，在较件定义当车》配合硬件的标准化程度不断提高的时代发展下，SOA设计将成为整车软件开发平台的基础图2.2-1电子电气架构演进方式SOA架构具有高度的灵活性和可扩展性，能保证车内外所有应用避免大量的软件接口适配，提升电子电器元件的集成度，帮助主机厂和供应商降低成本的同时节约空间，提高集成效率。它为当代汽车工业的赋能体现在如下方面：●服务化响应市场与用户：传统汽车上的每一个功能无法轻易变动，牵一发而动全身。而在智能汽车时代，各个域控会将其对应的功能封装好并提供接口对外开放，可以使得功能与功能的组合、新功能的添加等更为便捷；●灵活的平台架构升级：SOA所带来的软硬解耦特性，能够有效降低架构升级带来的复杂度，使得软件功能的更新限制在很小的范围内，且对硬件架构产生的影响较低。因此在升级时，能够大幅提升用户体验，实现更为便捷的联网功能，实现不同平台间的各种APP共享等功能；●快速安全的通信策略：车载跨系统的通信是通过SOA架构的服务来实现的。在网络基础设施高度发展的背景下，以太网的通讯效率大大优于传统的CAN总线方式。服务可以通过共享数据来实现跨系统通信，包括使用共享数据库、分布式缓存或共享文件系统等方式，通过加密保护可以确保pheSoharempenef计□□口从功能逻辑的角度对整车功能、整车特性及需求进行设计，输出整车逻辑功能网络。将整车功能块映射到实现此功能的软件组件(整车视角),识别软件组件(整车视角)之间的通信接口交互方式，确定是基于服务通信、基于信号通信还是基于信号转服务通信，或是混合通信方式，对软件组件进行分组。此外还要确定各个ECU硬件节点(含硬件资源)以及ECU节点之间的物理通信连接，如CAN总线、以太网总线等。最后将软件组件映射到各个ECU硬件节点上。在进行整车级架构设计时可灵活使用自顶向下或自底向上的设计方法。成果物包括功能架构、整车级软件架构、整车级的硬件架构等。对外交付物为整车级的SOA服务接口描述文档。根据高层级架构设计的输出进行设计和分解。定义系统拓扑，即将系统功能分解到子系统功能、定义络管理。自顶向下或自底向上的设计方法同样适用于此过程。成果物包括系统级的全局时间描述文档、系统级的网络管理描述文档、系统级的信号转服务描述文档、系统拓扑描术文档。时外交付物则为系统级的软件簇设计描述文档、系统级的SOA服务实例描述文1.3机器设计(MachineDesign)此过程依赖系统设计的网络拓扑描述文档，其主要工作为将要部考当整车的机器(Machine)进行配置设计，包括通信结构、机器(Machine)到实ECUSOA自顶向下或自底向上的设计方法同样适用于此过程对外交付形为机器设计相关文档。此过程的主要输入是上游的机器设计(Mhchineesgn),主要内容有：描述ECU硬件实体的有效资源，例如处理器单元数量、内存、传暖、执行醒、引脚等；选择合适的操作系统；为机器(Machine)定义硬件可用资源；操作系统配置人中台服名配置，例如网络管理等；平台基础模块配置，例如Log等。对外交付物为机器清单描述以及相关配置。可根据自顶向下或自屈向的设计方法，定义或重用服务接口及服务接口数据类型。对外交付物为进一步完善的SOA服务接口插述文当及SOA服务接口数据类型描述文档。此过程依赖于上游的功能集群设计描述文档及SOA服务接口描述文档。主要进行软件组件设计、可执行实体设计、进程设计、功能集群间的交互设计、应用间的交互设计。自顶向下或自底向上的设计方法同样适用于此过程。此过程的成果物为软件组件设计文档、可执行实体描述文档、软件交互描述文档。对外交付物为进程设计描述文档、应用设计描述文档。需要注意的是此过程的应用设计并不区分应用层软件及平台层软件。主要工作内容包括定义SOA服务实例的提供方和消费方，将SOA服务实例的提供方和消费方映射到可运行实体。成果物包括服务实例映射、服务部署描述等。此过程根据上游的应用设计描述文档及SOA服务接口描述文档进行软件编码实现。成果物包括SOA服务实现的应用软件源代码、软件编译配置、SOA服务开发框架及实现代码、平台服务代码对象。对外交 功能型服务平台核心服务(系统级服务)功能型服务(云动)功能型服务(车云系统服务)基础型服务硬件抽象车云一体整车服务层整车服务层SOA开发需要的服务；从整车角度，将各节点的服务进行汇总，为应用开发提供更便捷的接口。车云一体：提供车云通讯和服务编排等功能，将常用的车云通讯能力封装，在车端提供数据汇总功能统一传输至后台处理；并提供服务编排能力，将各类服务通过编排脚本在车端重新编排成动态服务。3.SOA软件平台整车服务SOA软件平台整车服务是指从整车的角度提取各ECU域控制器的通用和公共的部分，用于支持整车的各种功能和业务需求，实现整车的统一协调、管理、调度和控制等服务。SOA软件平台整车服务服务层如图2.2-4所示，是基于系统基础服务实现并对应用服务提供整车级通用服务的层级。SOA软件平台整车服务常需要跨越多个功能域，实现多个功能域的组合复用。SOA软件平台整车服务主要包括了电源管理、网络管理、多康管理、时钟服务、升级服务、安全管理、日志和调试工具管理等。主要包含以下几个方面：●整车基础业务协同服务，定义整车基础和公生的酸电源管理，升级管理，日志管理，诊断管理等；●整车通信与网络协同服务，定义整车风备配置，网络调度，网络安全等；●整车功能安全协同服务，定义查手功能安生相关的服务，如：健康监测，功能冗余，安全管理等；·整车跨域协同服务，定义需里在域间北享的服务，如自动驾驶整车服务，智能座舱整车服务，智能控制整车服务等。对于整车级服务的定史阳实现，主要有以下技术要求：●标准化的通讯协议：整本服务层需要使用标准化的通讯协议，以便各个服务之间能够进行可靠的通讯和数据交换。常用沟通讯协议包括SOEMIP、DDS、共享内存等；●可扩展性和灵活性：整车服务层需要具备良好的可扩展性和灵活性，以适应变化的业务需求和功能扩展。这包括支持动态添加和移除服务、动态调整服务的资源分配、动态配置和组合服务等能力；●可靠性和高可用性：整车服务层需要具备高可靠性和高可用性，以确保整车系统的稳定运行。这包括支持故障恢复、容错处理、负载均衡和故障切换等机制；●极致的性能：能够处理高并发和大数据的操作，满足整车系统的实时性和响应性；●可移植性和可维护性：良好的代码质量，统一的编程规范，功能实现基于基础服务和POSIX操作系统接口，在QNX、LINUX等操作系统间提供较好的可移植性；有较好的故障码和错误日志定义；●整车级服务要具有较好的易用性：提供配套的设计与开发工具，提高应用层服务的集成和开发效率；●安全性和权限控制：整车服务层需要具备强大的安全性和权限控制机制，以防止未经授权的访问和恶意攻击。这包括数据加密、身份认证、访问控制和审计日志等功能；●数据管理和分析：整车服务层需要具备强大的数据管理和分析能力，以便收集、存储和分析整车系统的各种数据，并为决策和优化提供支持。这包括数据存储、数据查询、数据挖掘和实时数据分L析等功能；●故障诊断和远程管理：整车服务层需要提供故障诊断和远程管理功能，以便快速检测和解决整车系统中的故障，并通过远程管理接口进行远程配置和维护；●整车级服务的设计需满足SOA软件层级合理划分的要求，对下做到对系统服务的合理封装，对上需满足所有应用层的公共服务需求；●整车级服务的设计需要满足SOA的所有特性，包括高内聚松耦合特性、兼容特性、SOLID原则、无状态原则、归一化原则等；●整车级服务的设计需满足系统无关性原则，整车服务往往需要应用于车内多个系统中，因此整车服务的设计与定义需要考虑到不同域、不同系统的差异性。整车服务层的设计规范有助于确保系统的一致性、可用性和可维护性，同时也方便团队协作和项目的扩展。设计和定义整车级的服务，需要符合以下规范：●接口设计规范：定义清晰的接口规范，包括输入参数、输出结果、状态码和异常处理等。使用标准的命名规范和数据格式，以便不同服务之间能够进行无缝集成和交互；●服务命名规范：给每个服务指定一个唯一的、具有描述性的司名，以便开发人员和系统管理员能够清晰地理解其功能和用途。遵循一致的命名约定，提高线码的可读性和可维护性；●事件与方法定义规范：定义统一的事件和方法ID;●异常处理规范：定义统一的异常处理机制，并规定不同异常卷型的处理方式。例如，定义标准的错误码和错误信息，以便客户端能够正确地处理异堂情况●安全设计规范：在整车服务层中加入合适的安全机制，包括身份认证、权限控制和数据加密等。确保敏感数据的安全性和用户的合法说问；●性能优化规范：考虑到整车服劳屋需要处理大量的数据和请求，设计合理的缓存机制和查询优化策略，以提高系统的性能和响应速度●日志和监控规范：在整气服务层中加入日志记录和监控功能，记录服务的运行状态和重要的操作信息。使用合适的不具和授式，对系统进行实时监控和故障诊断；●文件和文档规范：为整兴服务层编写清晰、易懂的代码注释，并准备好详细的说明文档。描述服务的功能、接口和使用方法，以便其他开发人员和合作伙伴能够快速理解并正确使用服务；●整车级服务层的数据的设计需满足一致性原则。整车服务会存在跨域交互和使用的情况，此时，数据的一致性要求才能保证不同域不同系统的功能符合预期且行为一致；●整车级服务层通信模块的设计需满足不同域不同通信协议的兼容性原则。由于整车服务面向的服务对象为车内不同域中的对象，因此整车服务的通信模块设计之初就必须考虑整车系统内所使用的所有通信协议的兼容性和同步性等问题，并且还需考虑通信协议的可扩展性；●整车级服务层对于服务访问的安全问题需要做特别的管理，由于整车级的服务往往关联了车内关键的功能和领域，因此服务访问的权限管理需在设计时重点考虑；●整车级服务层要使用基础服务层、设备抽象层、POSIX接口函数集等提高可移植性，尽量采用一套代码来适配不同的操作系统，提高服务的可维护性；●整车级服务层要考虑功能安全和信息安全需求：E2E安全机制，配置和数据安全，必要的超时和异常监测处理，安全日志等。4.整车SOA关键技术整车SOA在落地实现中有多个关键技术，详细如下：●跨域通信中间件：跨域通信中间件提供了对消息队列、发布订阅系统、分布式消息通信机制的抽象和封装，给SOA服务提供了统一的接口和框架，使其可以在不同的域中运行并实现相互间的通信；●服务注册和发现：SOA服务需要进行注册才能够被其它服务或应用程序找到并使用它们，调用者需要具备服务的发现能力才能够使用服务的接口和数据。服务注册和发现通过服务发现协议来实现；●服务接口定义和描述：服务与使用者之间需要约定统一的通信合约，这个就是服务的接口定义和描述。接口定义和描述通常描述了具体服务的接口，接口的参数，使用的数据类型，接口之间通●跨域服务调用接口：跨域服务调用接口允许一个域中的服务调用另一个域中的服务，这个域可以是本车的，也可以是云端的。跨域调用接口通常使用的通信协议有SomelP,DDS,MQTT,http/https等，同时需要配合安全模块以确保安全和可控的跨域通信●数据和协议转换：在不同的网络之间转换数据和控制信息，过据和协议的转换以实现它们之信号的转发和交互。数据转服务：在当前SOA架构下，网夫也高以实现部分信号、数据转服务的功能，如S2S(signaltoservice,信号到服务●安全和身份验证：服务发现上，需要能够设定信息安全组隔离机制，使得服务广播消息只发给有需要的服务使用者；服务访问上，需要他够为服务是供方设置信息安全访问控制机制，认证并授权服务使用方发起的服务请求；服务通信提共信息安全传输机制，来满足不同场景的安全要求；设置服务安全监控机制现SC务相关的异常事件及安全响应处理机制；●服务治理：服务治理涉及管理、监控维护和优化服务的全生命周期。这些组件是实现汽车功能安●服务编排：SOA提供了服类的编排管理功能，编排管理对现有的服务进行编排和流程管理，可以将多个服务组合成更加杂的亚务流程或工作流程，同时提升底层服务使用的安全性和便捷性。服务编排使用拖拽等工具来定义和管理。本节主要介绍跨越确定性调度及确定性通信以及DDS通信中间件技术。整车跨域通讯技术见表2.2-1,是整车SOA系统开发的一个重要环节。目前可供选择的SOC(Ser-vice-OrientedCommunication)协议有SOME/IP,DDS,MQTT,HTTP,主要区别如下：表2.2-1整车跨域通讯技术阅发布 1.跨域确定性调度及确定性通信(1)实时系统根据时间上的要求，计算机系统分为实时系统和非实时系统，非实时系统对任务执行时间没有保证要求，又叫做尽力(BestEffort)系统；实时系统对任务执行有时间保征要成，如图2.2-5所示，本文着重介绍实时系统。实时系统的定义：计算机系统行为的正确性不仅取决于计策机线具的确性，还取决于物理时间的正确性，这样的计算机系统称为实时系统。实时系统存在2个关键因素：●计算时间要有正确性保证，即计算时间满足复由多个实时系统构成，通过通信系统进行数据互的系统则称为分布式实时系统。分布式实时系统通过扩展，弥补了单个实时系统在存储个算方面的局限性。其特点有：●提升系统的扩展性：单个计算系统的计算资源有限；●降低复杂性：通过使用小型化简单化的智能单元组合实现复杂处理功能；●提升线缆连接的安全性：通过将单个计算节点靠近传感器/执行器布置，从而减少整个系统的连节点2节点1节点2图2.2-5实时系统与计算速度无关，实时系统/分布式实时系统必须保证任务或者动作得到及时响应或处理。任务处理的最后期限称为截止时间(deadline)。根据任务的影响，截止时间又分为2种：●软截止时间(Softdeadlines):错过截止时间，系统结果仍然可用；EcunEcunFCU端到端时间基础软件运行时环境软件组件c执行、服务执行和通信处理。 (3)基于SOA跨域通信中间件的确定性调度技术确定性调度技术是跨域服务、跨域通信的一项关键技术。在通信层面，可以支持的通信技术包括：CAN,Ethernet/TSN,PCle等。在上层应用层面，支持的应用协议包括基于IPC的共享内存、DDS、SOME/IP等。确定性调度的实现由以下几部分组成：丢开时间同步，无法保障分布式实时系统的时间确定性和计算结果(服务)的确定性。时间同步技术又分为集中式时间同步和分布式时间同步。在汽车领域目前以基于主从结构的集中式时间同步为主。●通信数据的完整：接收端的数据要和发送端的数据一致，通常通过数据的校验算法保证，常用的●通信时间的确定：通信的时延有界，通常通过设计手段和测试手段来保证。设计手段有时间触发，优先级等方式；测试手段有时间戳的方式。●通信顺序的确定：保证接收端的数据顺序与发送端的顺序一致。通信顺序的不确定性的原因主要有：o通信路径不确定，如存在多条长短不同的通信路径；。通信路径上存储机制，如中继上的存储转发优先级，限速设计情，如：交换机；通信机制本身，如存在重传机制的通信协议例如保证通信顺序的方法有：。通过时间触发保证，采用时间敢感架构，以时间为方拍驱动通信消息，从而保证整车分布式实时系统执行计算链的时间特性和通信的顺序。通过标签计数，为每条消息加顺序信息、接收端可重构发送的顺序。·工具链：分布式实时系统软件设计具与要求高、复杂度大的特点，安全可靠的工具链对设计、开发、测试、验证非常有必要核、工具链需要足：o当前汽车架构的发展要求统一)成熟、安全的工具链支持不同车型当前和未来几年间的发展；o软硬件分离：满定在中速面市需求，支持软、硬件分离研发，加快集成验证；o安全性：满足汽车软件功能安全开发与验证需求；o可集成性：需支持对不同硬件、第三方软件以及通信方式的集成；o可扩展性：需满足主机厂对功能的扩展；o可复用性：需支持软、硬件的复用性，降低开发周期。(1)概述SOA在汽车领域的发展和应用，要求在架构层面使用高度可扩展、面向服务的通信中间件以实现各分发服务)作为面向服务的通信中间件，是电子电气架构跨域融合向整车中央集中化转型过程中，实现DDS丰富的QoS(QualityofService,服务质量)功能能保证数据在多种场景下的高质量传输。例如，高级别智能驾驶场景中大体量的感知数据需要高质量的实时传输支持，最典型的场景是通过DDS实现摄像头图像数据和激光雷达点云数据在各个硬件间高可靠、高实时传输的需求；此外，通过部署DDS还能实现智驾域与动力域之间控制信号的实时通讯，以及智驾域与座舱域之间图像信息实时、可靠的传输。目前，DDS在工业、交通、能源、国防等关键领域的实时分布式通DDSAdaptivePlatformAUTOSARClassicPlatformAUTOSAR准当中。目前国内一些成熟的商业化DDS产品已实现在很多平台上的集成与部署。①基本概念在实时分布式系统中，DDS协议位于操作系统和应用程序之间，采用发布-订阅模型，定义了各节点间动态发现以及数据分发的逻辑和行为。该模型构建了一个虚拟的“全局数据空间”的概念，所有对该空间中的数据感兴趣的应用程序都可以接入。想要向这个数据空间提供信息的应用程序称为"DataW-riter",想从数据空间中获取数据的应用程序称为"DataReader",双方通过对于主题(Topic)的发布和订阅进行匹配，DataWriter将数据发送给每一个匹配的DataReader。DDS通信概念模型如图2.2-7所示。说明图22-7DDS通信概念模型 DDS位于OSI模型的应用层，对下可支持UDP/IP、TCP/IP、SharedMemory、ZeroCopy以及核间通信(IPCF、RPMSG)等底层传输协议，传输协议的选择可通过配置文件进行配置和调整。DDS可支持静态类型、动态类型以及复杂类型的IDL文件的解析和代码生成，同时支持对上述类型数据的发布和订阅功能。DDS通信实体关系如图2.2-8所示。DDS核心协议包括DDS-DCPS(经常简称为DDS)和DDSI-RTPS两部分如图2.2-9所示，扩展协DDSSECURITYDDSRPCDDSXTypesDDSWEBDDS其中5个重要的协议包括：scribe,描述以数接为中心的发布订阅通信机制；Protocol,提供了标准的序列化方式以及发现机制；●DDS-Security:定义了安全模型和服务插件接口(SPI)架构；●DDS-RPC:定义了基于DDS实现的远程调用框架(RPC);●DDS-XTypes:全称ExtensibleandDynamicTopictypesforDDS,定义了DDS类型系统，以支持动态和可扩展的发布订阅主题。DDS提供丰富的QoS服务质量策略，可灵活满足各种分布式系统实时通信的场景需求。DDSQoS服务质量策略见表2.2-2,应包含OMG组织在DDS规范(DDSTMVersion1.4)中定义的22个策略： _____级稳定传输；②高灵活、高扩展性：提供多种通信QoS选择，为不同智能驾驶通信场景提供灵活的QoS管理，大幅度提升通信灵活性；③通信安全保障：提供访问控制、应用程序身份认证、数据信数感信思保护等多种安全保障。(三)云原生云原生技术是一种以云计算为基础，采用微服务容化、Dev等理念构建的新型应用开发和部署方式。它能够帮助企业实现快速迭代、弹性伸缩、高可用性和高成本的目标，从而加速数字化转型实践。在汽车行业中，云原生技术可以帮助车企实现车联网、自动驾驶、智能网联等方面的目标，并通过云原生大数据提供有价值的商业洞察和决策支持。为实现“软件定义汽车”,以面向照多的架(SCA)成为新趋势。在域集中化架构和中央计算架构呈现与云服务相似的部署形态同时，为适应香能网联汽车的快速变化，汽车制造商不断推进在智能驾驶、智能座舱、智能车控等场星中的软情迭代夏新，这加大了车云平台在数据传输、运维管理方面的挑战。主要体现在以下几个方面：●大规模的车辆接入和管理：实现千车千面，需要解决大规模车辆接入和管理的问题。●快速迭代和灵活部署：面对软件更新频繁的挑战，需要能够快速迭代和灵活部署车载应用。●车云消息传输和业务协同：车云平台需要确保消息传输可靠，同时实现车云业务的协同作业。为解决这些挑战，结合云原生技术和边缘计算技术，构建了云边(车)高可靠、易扩展的技术架构。通过车云协同平台，在车载计算设备上部署容器应用，实现车端连接、车载应用统一部署迭代、车载边缘计算和消息高可靠传输。车载云原生技术架构涵盖微服务、容器技术和DevOps等方面，结合云原生技术和汽车应用场景的研究，以应对不断变化的汽车软件需求。1.微服务架构微服务本质是一种架构风格，倡导将单个应用程序开发为“一套小型服务”的方法，每个服务“运行在自己的进程中",并通过轻量级机制进行通信。这些服务“围绕业务功能构建”,并通过全自动部署机制“独立部署”。“这些服务只有最低限度的集中管理”,可能是用不同的编程语言编写的，并使用不同的数据存储技术。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露API来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。 一体化架构微服务架构图23-1微服务对比单体应用的微服务对比单体应用架构如图2.3-1所示，微服务架的的共术优费在子通过服务化实现低耦合效果。彼此独立的各个功能可以单独开发与部署。微服务架构是一种将应用程序拆分成多个独立的那匆，每个服务都运行在自己的进程中，并通过轻量级的通信机制进行协作的技术。通过单体型构与曲服务架糊的对比，微服务在交付速度、吞吐量、系统扩展性、技术栈多样性、可用性上的优势，无，将成为三企服务建设的得力臂助。当然微服务在带来效率与质量的提升的同时，也增加了整体过性、架构层问题排查分析的难度，但这些弊端在开源体系下配套的中间件、容器与DevOps技术得到化解。虽然微服务与SOA架构在些方面存在相似之处，但微服务更加注重业务导向、服务粒度的精细化以及服务之间的独