中国汽车基础软件发展白皮书3.0阅读版

中国汽车基础软件发展白皮书3.020222022年9月18日序序言PREFACE面取得了巨大的进步，进一力、加快车用操作系统等关键技术攻关和产业化落地已成为中国汽车基础软件发展的重中之重。圩在全球新能源与智能允许多路径并存，为车用操作系统企业预留试错空间，装备软件领前言》发布之后，在工业信息化部装备一司和装备中心的指导下第三次发布中国汽车基础软件白盟以及AUTOSEMO80余家成员单位，根据各家在生态领域积累的经验，结合目前汽车软关键技术和关键标准研究进展进行总结。本书内容涵盖市场发展情况，关键汽车软件技术趋势、关键标准研究情况、汽车软件产业生态发展建议等方面。旨在鼓励行业内的技术交希望借此书，能和各行业内单位共同探讨基础软件技术发展、生态建设、人才培养等关键问题。旨在承担中国汽车产业变革中的生态发展任务，为将来具有多要素、多维度、。2022年9月础软件发展白皮书3.0目录CONTENTS 1.1智能汽车车用基础软件平台的定义与分类……………0011.1.1智能汽车车用基础软件平台定义………………0011.1.2智能汽车车用基础软件开发平台分类…………0011.2智能汽车车用基础软件开发平台的要素………………0021.2.1嵌入式软件………………………0021.2.2开发方法论………………………0031.2.3配套工具链………………………0031.3智能汽车车用基础软件平台发展现状…………………0041.3.1大众VW·OS……………………0041.3.2丰田Arene·OS…………………0051.4白皮书内容简介…………………………005 2.1AUTOSARCP…………………………0072.1.1技术形态…………………………0072.1.2技术发展趋势……………………0102.1.3关键技术解读……………………0112.1.4典型应用案例……………………0142.2AUTOSARAP…………………………0172.2.1技术形态…………………………0172.2.2技术发展趋势……………………0192.2.3关键技术解读……………………0212.2.4典型应用案例……………………0212.3操作系统内核……………0242.3.1操作系统内核技术架构…………0242.3.2技术发展趋势……………………0252.3.3关键技术解读……………………0262.3.4典型应用案例……………………037I2.4虚拟化……………………0392.4.1技术形态…………………………0402.4.2技术发展趋势……………………0412.4.3关键技术解读……………………0442.4.4典型应用案例……………………048 3.1基础软件开发平台………………………0523.1.1基于功能软件的自动驾驶平台…………………0523.1.2基于ASF的生态框架……………0573.2基础软件验证平台………………………0623.2.1验证平台概要……………………0623.2.2验证平台典型案例………………063 4.1功能安全与基础软件……………………0754.1.1相关标准介绍……………………0754.1.2功能安全软件架构………………0784.1.3内存分区静态分析技术解读……………………0834.1.4工具链的功能安全要求…………0844.2信息安全与基础软件……………………0864.2.1相关标准介绍……………………0864.2.2信息安全软件架构………………0894.2.3关键技术解读 090 4.3.1汽车数据智能背景介绍 0944.3.2基于边缘计算的嵌入式车端数据管理系统 1004.3.3数据驱动能力分级 104 4.4.1双态敏捷开发模型 1054.4.2自动化编译框架 1084.4.3持续集成持续交付 111 4.5.2DDS 123础软件发展白皮书3.0 4.6.1国内本土化芯片发展现况 1264.6.2关键硬件技术 127 2第1章智能汽车车用基础软件平台概述基于一个整车平台，车企可以衍生出多款车型，从而全面提升硬件资源的复用性。纵观汽车工业的提升产品的可靠性和一白皮书3.0旨在分析汽车基础软件平台及其关联技术的发展趋势，除了对其技术形态做一般性定义用基础软1.1智能汽车车用基础软件平台的定义与分类1.1.1智能汽车车用基础软件平台定义汽车软件主要分为应用软件和基础软件。应用软件和业务形态高度关联，不同控制器的应用软件之实现应用软车用基础软件开发平台和车用基础软件验证平台在汽车软件中的位置如图1.1-1所示。基础软件平件开发平台包含内核、虚拟化模块，中间件，功能软件以及与之相配套的开发工具链，用于支撑应用软件的快速迭代开发。基础软件车用基础软件开发平台车用基础软件验证平台1.1.2智能汽车车用基础软件开发平台分类2019年10月，汽标委发布了《车用操作系统标准体系》，参考该标准可以类似地将智能汽车车用载信息娱乐基础软件全车控基础软件开发平台基础软件开发平台对实时性和安全性的要求极高。目前，主流的安全车控基础软件开发平台兼容OSEK/SILD2.智能驾驶基础软件开发平台智能驾驶基础软件开发平台主要面向智能驾驶领域，用于智能驾驶辅助，以及全自动驾驶功能的控l要中国软件测评中心2019年发布的《车载智能计算基础平台参考架构1.0》就是智能驾驶基础软件开3.车载信息娱乐基础软件开发平台车载信息娱乐基础软件开发平台主要为车载信息娱乐服务以及车内人机交互提供控制平台，是汽车随着车辆由单纯的交通工具向智能移动终端转变，车载信息娱乐基础软件开发平台需要满足如下l支持多生态资源，将手机端庞大的信息娱乐服务生态资源，通过采用相同或类似的操作系统，快免重复开发l安全，通过深度定制达到车辆信息安全和功能安全的标准1.2智能汽车车用基础软件开发平台的要素1.2.1嵌入式软件一是标准化/可扩展的功能实现。标准化/可扩展的功能实现既要充分满足整车应用对基础软件开发平台的功能需求，又要充分考虑这些功能需求的标准化/可扩展性。总结和归纳共性的需求，基于共性需求参考和借鉴国内外的优秀案例，充分考虑未来汽车基础软件的发展趋势，提出更加成熟的软件设础软件开发平台的发展。二是符合功能安全要求。基础软件开发平台支撑着整车应用的实现，如果不能守护好安全这道大门，础软件发展白皮书3.0后果不堪设想。ISO26262(2018)对基础软件开发过程的各个阶段提出了充分的要求和建议，可以作1.2.2开发方法论开发方法论是基础软件开发平台的重要组成部分。清晰的开发方法论可以最大程度发挥出基础软件交互规则不仅定义了基础软件开发平台内部之间的交互规则，还定义了基础软件开发平台与应用软件、其他开发工具之间的交互规则，以便基础软件开发平台可以与其他开发环境更好地兼容与交互。详TOSARCP开发方法论为例，图1.2-1展示了从系统层级配置到ECU可执行文件生成的过程以及该过程中的文SARCPAUTOSARCP法论概览1.2.3配套工具链配套工具链是基础软件开发平台的必要组成部分。使用工具链自动生成基础软件开发平台的配置代放完整的要求。详见图1.2-2。基础软基础软件开发平台工具链路的数据处理、原安全耦、自动代码的生开放完整是提高开发效率的重要保证。工具链需要：配合基础软件开发平台对新技术新功能不断开供开放的场景模型库；需要兼容不同OEM的应用场景及第三方应用软件开发；需要通过工具链的开放生态助力基础软件开发平台的生态化发展。工具链的完整性不仅是单一业务场景下的功能完整，更是覆盖全流程的完整。以自动驾驶为例，工具链需要覆盖从算法模型训练到芯片运行模型预测的完整AI开发过程，并通过其开放性不断丰富自动驾驶应用场景库以加快开发速1.3智能汽车车用基础软件平台发展现状国内外主机厂、造车新势力、零部件供应商等都在着力打造其专属的基础软件平台，并已形成以OS为核心向基础软件平台进化的趋势。此处挑选两个国外主机厂基础软件开发平台的案例进行介绍，国内1.3.1大众VW·OS专门从事自主软件平台VW·OS的研发。计划于2025年，旗下所有新车型均搭载VW·OS，以实现车中式E/E架构ICAS。其中AdaptiveAUTOSAR的实现采用了EBxelor高性能计算软件平台(基于AU-TOSARAPRID系列车型上的搭载。大众VW·OS如图1.3-1础软件发展白皮书3.01.3.2丰田Arene·OS为了更好地应对软件定义汽车的发展需求，2021年8月丰田宣布将在未来五年内打造整车软件平丰田Arene·OS软件平台如图1.3-2所示，其主要包括软件工具包和AreneAPI车辆应用程序编PIRustCCECU上，并可实现跨平台部署。Arene·OS软件工具/服务包括APPSDK(用于开发、测试和部署应用到虚API拟仿真/测试平台(支持虚拟场景创建、软件在环和硬件在环仿真)和基础开发环境(采用基于云的数据管道技术，结合可自动创建AWS沙箱的Ansible和Terraform模板来实现数据处理和索引)。借助Arene·OS的车辆抽象层,开发者可以将相同的源代码部署到任何运行解决方案；在智能驾驶基础软件平台方面，还存在多处“卡脖子”技术短板，尚未出现足够成熟的解决1.4白皮书内容简介软件发展白皮书3.0UTOSAR第3章智能汽车车用基础软件平台分别介绍了基于功能软件的自动驾驶平台和基于ASF(AU-第4章智能汽车车用基础软件开发平台关联技术以六个技术领域为切入点，分别研究了基础软件平台对支撑功能安全所起的作用；研究了基础软件开发平台对支撑信息安全所起的作用；研究了边缘计算如何更好地驾驭数据以支撑车企数字化转型；研究了双态开发模型和持续集成持续发布CI/CD如何支撑A础软件发展白皮书3.0第2章智能汽车车用基础软件的内核和中间件面对基础软件开发平台的重2.1AUTOSARCP2.1.1技术形态SARCP规范不仅提出了软件分层架构，而且定义了基于该规范的标准开发流程，即开发方法论。下面从开发方法论AUTOSARCP为基于该规范的系统开发提供了一个通用的技术方法。它定义了从系统开发到单个ECU开发的各个阶段，以及在各个阶段需要完成的工作内容、需要提供的成果物。开发一个系统可分解ECU个数和网络拓扑无关)的系统描述，如图2.1-1所示。该阶段首先基于功能提出对整个系统的技术要求和约束条件，并且从功能视角设计合理高效的系统架构。其次，工程师在车辆电子电气架构尚未确VFBSWCECUVFB接口转换成能够在通信总线上传输的CUExtractECUC四、ECU软件集成。当ECUExtract、基础软件、原子级SWC都开发完成后即可进行ECU软件集进行整车级别的软件架构设计以及相关功能模块的定义。ECU级开发则着重开发单片机底层软件。SWC级开发则主要开发具体控制算法。各级开发可以并行，不同的开发之间通过标准化的ARXML文件进行2.软件分层架构在AUTOSARCP分层架构中，自上而下分别为应用软件层(ApplicationLayer)、运行时环境 (RuntimeEnvironment)、基础软件层(BasicSoftwareLayer),如图2.1-3所示。应用软件层包含若干个软件组件，软件组件间通过端口进行交互。每个软件组件可以包含一个或者RTE件触发。RTE可以实现软件组件间、基础软件间以及应用软件组件与基础软件之间的通信。RTE封装了基础软件层的服务、提供了标准化接口，使得应用软件层可以通过RTE接口调用基础软件服务。此外RTE抽象了ECURTE准化接口将ECU之间的通信抽象为软件组件之间的通信。础软件发展白皮书3.0AUTOSARCP分层架构管理和实时操作系统等服务。ECU抽象层与ECU平台相关，但与微控制器无关，包括板级硬件抽象、存储硬件抽象、通信硬件抽象和I/O硬件抽象。该层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者I/O的访问，从而不需要考虑这些资源是由微控制器片内还是片外提供的。微控制器抽象层是实现不同硬件接口统一化的特殊层，包括微控制对微控制器的寄存器进行操作。最后，由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，3.工具链V模型是目前汽车电子软件开发过程中采用的主流开发模式，V模型左侧统称为设计阶段，主要涵盖业务需求分析(RequirementAnalysis)、系统设计(SystemDesign)、架构设计(ArchitecturalDe-sign)、模块设计(ModuleDesign)和编码(Coding)五个阶段。V模型右侧统称为测试阶段，涵盖单元测试(UnitTesting)、集成测试(IntegrationTesting)、系统测试(SystemTesting)和验收测试(Ac-UTOSARCPAUTOSARCP链CPEM行实体、触发事件)的设计及框架代码生成；实现软件组件间通信端口的连接；导入DBC、LDF等传统三、MCAL/BSW配置及RTE代码生成工具。MCAL配置工具主要用于底层驱动的配置与配置代码BSW应商提供的静态代码一同进行ECU软件集成。RTE代码生成工具以软件组件ARXML或基础软件配置此外，目前市面上的AUTOSAR工具链都是桌面应用程序，这使工具链的维护和升级都不方便，并且由于应用程序在各个电脑上都是独立的，所以其资源是不可共享的，使开发效率降低。而随着5G和在未来，AUTOSAR工具链由桌面应用程序发展为Web应用程序成为可能。具有超大者们更加高效、友好的合作2.1.2技术发展趋势AUTOSARCP发展历史悠久，从诞生到现在已经有近20年的历史。本章节将从当前痛点分析角度础软件发展白皮书3.0CPAUTOSARCP带来的优势和便利前文已经叙述了很多，但是它也不是完美的，在实际应用过程中也不可否认AUTOSARCP的规范文档非常详尽，但正是统的嵌入式工程师望而止步。同时AUTOSARCP提出了很多新概念，比如标定量通过描述文件进行描述；应用接口不通过传统全局变量的方式与底层软件交互，而是对接口进行描述定义通过RTE统一接口进行匹配等。AUTOSARCP的软件开发理念和传统嵌入式工程软睿驰、中汽创智等几家供应商开际项目中并没有体现出AUTOSARCP软件模商对AUTOSARCP规范的理解并不完全一致，而且各厂商的工具也并不完全兼容，导致OEM集成各家供应商开发的软件模块需要花费大量的精力和时间。原本希望借助AU-TOSARCP标准统一的优势合作开发，但是因为工具链的兼容性问题而不得不统一工具链的使用，严重工SAR具箱生成的代码一样，一些AUTOSAR工具链的RTE代码生成工具生成的代码可读性也较差，这给软件调试带来了不少麻烦。例如在调试基于SOMEIP的服务通信时需要根据服务请求信号、提供信号的数据2.1.3关键技术解读基础软件多核分配关键技术。没有基础软件的多核分配，就算应用软件做了多核分配，多核系统的优势将受到核间通信效率的制约，甚至系统整体性能还不如单核。实现基础软件多核分配的主要技术手段有主卫星方式(Master/Satellites)和通信协议栈分割(Com-StackSplit)两种。方式，即卫星给其所在核的其他模块提供服务接口并将收到的服务请求通过主卫星通信传递给主星，主星通信反馈给卫星。由于主卫星仅为同核其他模块提供服务接口并将服务请求转发到主星上处理；另一种极端情况是卫星和主星一同步。由于卫星提供的接口可以被该核的其他模块直接调用并通过高效的主卫星通信与主星交互，从而避免了低效的Client/Server通信，大大提高了多核系统中基础软件的服务效率。另外由于主卫星可并行处要配合自旋锁)这样的数据结构对跨核PDU进行路由，可将不同类型的总线协议栈分配到不同的核，如将CAN协议栈和以太网协议栈分配到不同的核。通过这样的协议栈分割可达到CPU负载均衡及提升多2.软件集群技术软件集群(SoftwareCluster)在R20-11版本中被首次提出，是AUTOSARCP在软件架构方面的础软件发展白皮书3.0如图2.1-6软件集群技术示例所示，通过软件集群技术AUTOSARCP软件架构被分割成了两个独立的软件集群，分别为应用软件集群(ApplicativeSoftwareCluster)和主软件集群(HostSoftwareCluster)两部分。其中应用软件集群可以单独编译，其搭载一组关联度较高的SWC；主软件集群也可以单独编译，其除了可以搭载SWC之外还必须搭载基础软件(包含OS和MCAL)。一个控制器中可以存在多个高度解耦的应用软件集群，但是只能且必须存在一个主软件集群，分别将应用软件集群和主软件使得软件的开发与集成变得更软件集群即可。如图2.1-6软件集群技术示例中的蓝框所示，各个软件集群就像是控制器上的一块块拼图，而这些拼图之间是通过软件集群连接块(SoftwareClusterConnection)拼接起来的。软件集群连接块由三部分组成，分别是二进制清单(BinaryManifest)，跨软件集群通信(CrossClusterCommunication)，代理模块(ProxyModules)。其中最关键的是二进制清单，它在编译阶段产生且AUTOSARCP规定了其标准格式，它为各个软件集群编译后文件(BinaryObjects)之间提供了定义良好的接口，从而能将其连接在一起形成完整的可执行文件。图2.1-7软件集群的连接展示了二进制清单连接两个软件簇的例子，其中软件集群A运行时需要一个资源(RequireResource，指软件集群运行时所需要的一切，或是S/RNVBProvideResource。软件集群A/B的二进制清单中都分别存储了这个资源的基本信息包括：资源属性(Require/Provide)、资源类型(S/R、A没有相应的ProvideResource，所以其二进制清单的句柄一览表被默认值填写且是可修改的，如图2.1-7黄色框所示。对于软件集群B来说，因为其具备固定的如果在烧写时进行软件集群连接，那么目标板内的软件集群连接器软件(On-boardSoftwareClusterConnector)负责在烧写的同时，将软件集群B中资源的句柄拷贝至软件集群A中资源的句柄，从而完跨软件集群通信用于支撑VFB通信。而代理模块分为高代理模块(HighProxyModules)和低代理模块(LowProxyModules)两部分，其中高代理模块位于应用软件集群代替原先的基础软件模块提供符合AUTOSAR标准的接口，低代理模块位于主软件集群负责实现真正的基础软件模块功能，二者之间2.1.4典型应用案例1.SOME/IP应用案例SPONSE。其中REQUEST为期待响应的请求，客户端有需求时才会向服务端发送请求，且客户端会等待服务端反馈的结果。例如，客户端如果需要向服务端请求VIN码，则可发送REQUEST类型的消息。RESPONSE则为响应消息，即服务端的用于响应客户端REQUEST类型的报文。例如：客户端向服务端不期待响应的请求，客户端有需求时才会向服务端发送请求，但客户端不关注结果。例如，客户端如果件通知，客户端先向服务端订阅消息，服务端当发现被订阅的消息发生变化时则主动通知客户端。例如，础软件发展白皮书3.0a 航、智能摄像头等传感器数据；IDC(InternalDataCenter)将预处理后的CAN数据转换成以太网数据并通过SOME/IP协议发送到SOC一侧。SOC一侧基于AUTOSARAP搭建，其中SDC(ServiceDateCenter)将以太网数据转换为SOC应用模块所需要的数据。在SOME/IP通信中，SOC侧的SDC作为MCUMCU一侧收到订阅后即开始以固定周期向SDC侧SOMEIP的数据传输周期与CAN报文周期一致。SOME/IP序列化方式采用大端一字节对齐。因为一字节对齐是最简单的对齐方式，大多编译器很容易实现；并且采用一字节对齐，序列化后没有冗余数据，报文的有效负载段都是有意义的数据，所以总SOMEIP报文结构如图2.1-9所示。本案例中的SOME/IP协议均基于UDP协议开发，它在用户有需求的时候才发送报文，这种方法有一、传输效率高。与CAN等周期性的网络相比，总线上不会出现过多不必要的数据，从而减少了资Cray长度最大254字节，而基于UDP的以太网单帧报文长度可达1500字节，能满足大数据的2.时间同步应用案例在智能驾驶中，时间是一个非常重要的参数，各个系统中需要保证时间一致，其中包括车云系统之车内系统(域控之间、域控与ECU之间、ECU与传感器之间)为保证时间一致主要采用：PTP(Precision如图2.1-10多传感器融合系统中，CameraECU通过高精度摄像头采集车道线、障碍物、标识等信息；RadarECU通过毫米波雷达进行障碍物、障碍物速度等信息的采集；Camera/RadarECU通过该系统对数据实时性、真实性要求比较高，所以需要保证Camera/RadarECU采集的数据时间一致。为了达到该目的，如图2.1-11时间同步步骤所示，本案例采用了AUTOSARCP时间同步解决方案，即三、ADCU间隔固定时间(100ms)后发送跟随帧，发送内容即Δt0时间。O础软件发展白皮书3.02.2AUTOSARAP2.2.1技术形态新四化(电动化，网联化，智能化，共享化)的变革驱使汽车软件系统变得更加灵活。汽车软件既要安全又要可持续更新以反映新的功能特性或法规要求，为此需要新架构支持软件组件的动态部署以及ux商业化的通用操作系统，车身控制则使用标准的AUTOSARCP。随着未来新技术及深度嵌入式系统对计。在未来，随着汽车电子及软件功能的大幅增长，E/E架构最终可能向基于中央计算平台的整车集中软件分层架构据融合和控制逻辑的功能模块，作为服务的最小单位与单一执行实体，通过API为应用提供可按需编排的基础服务，实现一次开发多次复用，最大化提升开发效率。该层的设计目标是。力的业务图2.2-2AUTOSARAP在软件架构中的位置2.工具链、软件开发阶段、集成部口及框架设计,最终导出AP平台的ARXML文件。产品工具应具备支持导入导出、解析、编辑lAP于实现组件API代码及Manifest配置文件的生成。输ARXMLManifest另外需要包含应用层的代码编辑器3.开发方法论AUTOSARAP开发方法论涉及工作产品的标准化，用于描述工作产品(如服务、应用程序、机器及其配。图2.2-3简要展示了AP平台的开发工作流，总体来说需要经历三个阶段七个步骤，最终将开发的础软件发展白皮书3.0 (1)架构设计阶段①服务接口设计(DefineServices)：主要是定义服务接口及数据类型，包括定义服务所包含的②机器配置设计(ConfigureMachine)：定义和配置机器的网络通信属性，包含网络连接配置，服 (2)软件开发阶段 (3)集成与部署阶段t图2.2-3AUTOSARAP开发方法论2.2.2技术发展趋势架构发展趋势 (1)AdaptiveAUTOSAR的历史标准。目前最新版本为R21-11。 (2)AdaptiveAUTOSAR的发展趋势①技术趋势在汽车行业，智能网联、自动驾驶、V2X、OTA等功能逐渐成为标配，AdaptiveAUTOSAR面向POSIX标准的操作系统，可以更好支持这些功能。在最新的标准中为了更好的支持开发，在可用性及稳A控制器的异构平台，新版本在AP与CP的共用特性及方法论上进行统一，定义了自动驾驶的传感器接口、整车级健康管理的架构与接口、针对整车OTA升。b.稳定性：增加针对系统稳定的特性。如在EM细节中增加了配置进程错误码、功能组增加unde-同时在这些功能场景下，信息安全与功能安全成为不可或缺的关键机制。AdaptiveAUTOSAR针对a含以下内容：l根据健康指标进行的机器恢复(例如降级)；l增加了确定性同步的内容，描述了同步行为和周期性激活的要求，包括时间同步和数据同步。b.面向信息安全：增加了入侵检测系统管理，由标准化的接口来报告安全事件。通过标准化的过滤l软件和硬件解耦；l支持分离式非耦合开发；l应用程序独立于加密解决方案。②基础软件技术路线随着各种域控制器方案陆续问世，各细分赛道由分散到集中，由独立到整合。目前整车域控制器，例如智驾域控，中央域控，智能座舱域控等均需得到高性能MPU芯片的支撑，因此POSIX标准系统的③新的分工趋势受域控制器行业的蓬勃发展以及各项政策利好，越来越多的参与者以各种新的身份加入进来，整体的行业角色将不再是E/E时代的OEM、Tier1及Tier2三种。随着产业链结构的变化，位于下游负责整车生产和组装的主机厂(即行业所说的OEM)，将不再通过系统与设备集成来获取价值增量，而会转向r2.工具链发展方向工具链(toolchain)是在一套流程里面用到的所有工具和相关库组成的集合，上一个工具的输出或础软件发展白皮书3.0环境状态成为下一个工具的输入或启动环境。因此，工具链的效率决定了整个系统的开发效率。所以随着行业的发展成熟，工具链的发展将由现在分散的多工具相互切换配合形态，逐步升级到成熟开放的中产生信息数据孤岛。AUTOSARAP论实现功能，各家比AP供后，要比拼的就是在整个产业上下游的Linux使用的问题，因此亟需一套集成开发环境来简化用户桌面，为基于AP的应用开2.2.3关键技术解读1.面向服务的架构(SOA)当前整车电子电气架构，功能不集中，分散到不同ECU，使得功能和信号交互异常复杂，代码和逻尽快适应变革。面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种这类系统中的服务可以以一种统一和通用的方式进行交互。通过信息安全能和云端环境产生很好的协同，实现一整套车云生态环境，因此车端采用基于服务的通信SOA2.软硬分离依赖于硬。3.虚拟化当前高算力芯片层出不穷，通过虚拟化技术，将芯片上所跑的各类业务分类进行隔离已经是目前很多车企的选择。同时，在软硬分离的背景下，在x86架构PC机上或云端通过虚拟化技术运行虚拟控制2.2.4典型应用案例 日志作为行为或状态详细描述的载体，提供可用于分析系统的活动和诊断问题的跟踪记录。在安全LogandTraceAP的时间同步及通信管理等模块交互。基架构图如图2.2-4所示：Daemon表示DLT守护进程，它接收并处理来自AP应用程序的日志信息，并根据配置对日志进行 息，Dlt-Viewer可以提取出我们所关注的数据，如图2.2-5所示。DltViewerDLT，除了日志显示、日志导入/导出等功能外，还提供了强础软件发展白皮书3.0UTECU1GWUTECU1GW (3)系统启动监控通过解析各功能模块产生的DLT日志，可以分析出整个系统上电启动过程，用户可以直观地观测各AP用场景介绍本节主要介绍基于AP的智能域控制器(后续简称IDC)OTA升级场景及其实现方案。IDC的OTA、软件升级、可追溯性、安端信息展现单元HeadUnit&Telematics)推送升级任务，用户确认升级后，HUT会通过网关向IDC及OTA服务器4/5G/WiFi (1)数据传输与管理TADC (2)软件升级①OTA采用双分区机制，通过活跃分区去升级备份分区，升级成功后重启备份分区，完成备份分区 (3)可追溯性A (4)安全性TAOTAIDC证在安全的情况下进行IDC软件CO2.3操作系统内核2.3.1操作系统内核技术架构简要架构在车辆动力电子，底盘电子和车身电子等实时控制功能实现当中，经常会使用到一些功能相对简单的微控制单元(MCU)芯片(如单片机)，这类芯片资源配置较低，硬件上没有为操作系统内核提供复杂的内存管理和特权级别的隔离功能，因此会采用一种简要的操作系统内核结构设计。在简要结构设计当中，内核服务与应用程序会被放置在同一地址空间，应用程序无需切换地址空间和权限层级就能够直设计，简要架构系统缺乏内核隔离保护能力，任何一个模块(无论是应用还是内核服务)出现问题都可AUTOSARCP式实时系统eeRTOS2.宏内核架构宏内核(MonolithicKernel)架构在计算机和通信领域是应用最为广泛的一类操作系统架构，其相关Unix，Linux)和主流手机操作系统(Android，iOS)均是基于宏内核架构。宏内核架构操作系统在智能驾驶和智能座舱领域也有大量应用。宏内核的特点是将所有传统的操作系统服务(例如进程调度，内存在硬件能力的支撑下，宏内核可以实现用户程序和内核的安全隔离保护，采用合适的进程调度机制(优先级抢占式)时也能够满足车用领域的硬实时性任务要求，并能支持虚拟化等新技术来满足汽车E/E架但是应该看到，由于面向通用业务而设计，随着宏内核功能的丰富，其代码量也会变得越来越庞大，域这不仅意味着软件复杂度和硬件成本的增加，也意味着更高的信息安全和功能安全挑战。目前，业界础软件发展白皮书3.0操作系统产品通过功能安全ASIL-B以上的安全认证。l模块化：内核通过模块化的策略来组织功能，提供可加载内核模块(LKM)机制。例如将大部分。l层级：对于内核的资源管理引入层级的概念，如进程调度优先级的分类等。3.微内核架构从功能服务的角度看，微内核(Microkernel)操作系统和宏内核系统并无本质差异，只是采用了不同的内核架构设计思路。由于宏内核架构系统将所有的服务都运行在内核态，任何一个模块出现错误或者被攻击就有可能引发内核的崩溃，从而影响到整个系统的稳定性。而且随着内核代码量越来越大，这核中剥离出来作为独立服务，并挪到用户态去运行(比如文件系统、设备驱动)。内核为这些剥离到用户态的服务提供各种通信机制，以保证这些服务能够相互协作，这样即使单个服务出错或者被攻破也不会微内核的最小内核设计原则主张保留尽量少的功能在内核态运行(如进程调度、内存管理、进程间通实现机制保留在内核态运行，这样可以根据应用场景适配不同的内核服务实现机制。微内核的这两个设计理念不仅提高了安全性，而且由于内核功能相对简单，其内核服务的时延相对比较容易控制和估算，不过由于第一代微内核系统代表Mach采用了一种过于通用的进程间通信IPC(Inter-Process系结构相关的，过度抽象将极大影响IPC的性能，而利用体系结构相关的状态进行优化则可将IPC性能”。经过改进和优化，第二代微内核系统代表SeL4在采用了最小化设计原则的情况下，也达此外，SeL4系统还通过了形式化验证。 (如QNX)通过了汽车行业的ASIL-D功能安全认证。2.3.2技术发展趋势前面已经提到，影响OS内核架构技术发展和应用的因素主要还是来自硬件约束、安全性(含功能安及相应框架已经得到业界广泛认可。当前汽车E/E架构正逐步迈入跨域集中式阶段。新阶段E/E架构的能域将明显出现计算平台从功能安全的角度看，不同功能域对于操作系统内核的要求也不相同。例如在功能相对简单的安全简要架构内核系统技术本身发展空间非常有限。考虑到基于微内核的RTOS实时系统已经有支持ASIL-D域部分业务属于软实时业务，且对功能安全等级要求相比安全中控和仪表分离的智能座舱解决方d在智能驾驶领域，能够满足高功能安全(ASIL-D)和高性能要求的微内核实时操作系统将被广泛应用。与此同时，为满足机器学习和视觉AI算法的操作系统层接口要求，基于宏内核的安全操作系统(如功能采用ISO26262形式化或半形式化方法完成正向设计和验证，以满足高功能安全等级和高可靠性的在简要架构操作系统产品领域，有国外大量的OSEK/VDXOS系统可供选择，国内部分厂家开发的LinuxAndroidIT场上建立的强大生态占据了主导地位，但是国内部分头部厂商都在积极发展自己的系统生态。与此同时，不少国内厂家还积极参加了Linux基金会的ELISA项目，旨在构建和认证基于Linux的安全关键应用程2.3.3关键技术解读IPC术都可能对应着一个或多个进程，用户应用进程之间由于可靠性和信息安全的需要采用了各种严格的时空隔离手段(技术原理参见2.3.3.2节)进行隔离，不能直接进行通信。但是用户进程间的协作又必须要进在实现进程间的数据传递功能的同时，还需要内核通过对进程的运行状态和运行时间的控制来实现控制流从发送者进程到接收者进程的切换(返回的过程类似)，从而直接影响系统运行效率。C础软件发展白皮书3.0 (宏内核为例)Pipe(0)Pipe(0)Pipe(1)发送者进程Write()接接收者进程Read()管道(匿具有父子的两个亲缘间述符(读写端口)FIFO(命可以在两进程通信通过全局的文件名 (管道名)建立连接并进行读写操作；它以一种特殊设备文件形式存在于文件系统中消息消息个型据消息队消息队列限息队首通通过消息进程间传进程n进程1PP进程n进程1PP信号量 (计数器)进程2VV用于进程PV共享内存两个或多享内数据数据发送者数据数据发送者进程 接收者进程操作系统内核进程2操作系统内核进程2 (宏内核为例)SIGKILL发送者进程SIGCHILDSIGKILL发送者进程SIGCHILD信号编号接收送者进程n接收送者进程1接收送者进程接收送者进程2接收者接收者进程发送者进程SendSendRecvTCP/UDP/IP/…基于TCP/IP协议出于最小内核服务设计的考虑，在微内核架构系统中，类似于驱动，文件系统等传统的内核服务被移到了用户态，许多原本可以通过简单系统调用就可实现的内核功能也必须使用IPC机制来提供服务，在系统负荷较高的情况下可能会面临着比宏内核更加严重的效率问题。因此对微内核系统的研究一般都PC传统的微内核IPC机制设计是通过端口(port)和消息(message)来实现进程间接通信。通信的双方不需要显式指定另一方，而是通过端口进行通信，这样可以将用户进程本身和IPC通信隔离开，只要一个进程在内核拥有某个端口，就能通过这个端口和另一端的进程通信。进程之间通过端口流通的数在微内核IPC通信机制优化方案当中，还有一些比较极端的手段，如迁移线程技术(threadmigra-移线程技术就是把其他进程的代码拉进当前进程中运行，这样就会大量减少内核进程切换的代价，同时在一些学术文献中，迁移线程模型被用在了LRPC(轻量级远程过程调用)技术当中。态进程1进程2操作系统内核进程1础软件发展白皮书3.0进程1用户态操作系统内核进程2线程池射内核态进程1用户态操作系统内核进程2线程池射内核态进程1进程2操作系统内核进程2上面两张图(图2.3-1和图2.3-2)是主流IPC和迁移线程IPC设计的对比。“要做到‘将代码拉到本地’，迁移线程首先需要对线程结构进行解耦，明确线程中哪些部分是对通信请求处理起关键作用的。然后，这部分允许被调用者(负责处理请求的逻辑)运行在调用者的上下文中，将跨进程调用变成更接d内核)就使用了BinderIPC机制来改进进程通信效率。BinderIPC机制中发起通信请求的用户态进程被代表服务端处理客户端的请求并返回结果。客户端首先从内核和ContextManager处获取服务端信息，然后通过内核对服务端发起通信请求，内核会从对应的服务端线程池里找到空闲的线程来响应处理(通过内存映射方式仅用一次拷贝完成数据内核Binder驱动也允许用户为服务端配置一个最大上限线程数，这样动态分配结合最大上限配置能够防nder.3-3实线部分)。服务端进程客户端进程IPC服务端进程客户端进程获取服务信息注册服务用户态Contextopen/ioctlopenopen/ioctlopen/ioctlopen/ioctlBinder驱动应用AOS内核处应用AOS内核处理器1在车用环境中，无论是基于宏内核还是基于微内核架构搭建的操作系统，使用什么样的IPC通信机2.时空隔离技术功能安全等级、不同重要程度的任务同时在一个计算单元中运行的情况。如果不采用一定的隔离措施，就会出现低功能安全等级或者非关键任务进程有意无意地干扰高功能安全要求或者重要任务进程的运行的情况(因自身缺陷或离。第一个层次是处理器级别的物理空间隔离(图2.3-4)，例如可以将A和B两个应用分别独立运行在同一计算单元的不同处理器中，每个处理器都是一个独立的运行系统。即使A应用所在处理器发生系统崩溃(无论是否由A应用触发)，也不会影响B应用的运行，反之亦然。应用BOS内核处理器2第二个层次是虚拟机/容器级别的时空隔离(图2.3-5)，例如可以在同一个计算单元(可能有1到多个处理器)上虚拟出多个资源独立的虚拟机空间，每个虚拟机/容器分配有独立的物理地址空间和处理器资源。将A和B两个应用分别运行在不同的虚拟机/容器空间中，即使A所在虚拟机空间发生了系统崩溃(无论是否由A应用触发)，也不会影响到B应用所在的虚拟机空间的运行，反之亦然。应用AGuestOS核应用BGuestOS核虚拟化处理器硬件第三个层次是内核和应用间的隔离(图2.3-6)。因为所有应用都不可避免地要调用内核服务，一旦内核出现问题，很容易导致系统故障，从而影响到所有运行在该内核之上的应用，所以需要将内核空间与用户空间隔离开来。用户应用程序只能运行在被内核映射分配好的地址空间，并限制用户态进程访问内核地址空间，系统同时会禁止用户进程执行某些可能破坏内核服务的机器指令，运行这些指令只能通过调用系统内核服务、中断等方式来完成。这一层次的隔离通常也需要硬件内存管理单元(如MMU)提础软件发展白皮书3.0分区2应用BOS分区2应用BOS服务层应用OS内核OS内核处理器分区是对一个相对独立的空间、时间、设备资、合，由操作系统内核对分区资源(CPU时间、内存、IO端口)实现配额管理，分区对核心资源的访问需通过内核的分区1应用AOS服务OS服务层OS微内核处理器硬件行隔离外，还需在负责时空隔离的操作系统内核和分区内进行实时调度(见2.3.3.3章节)。在分区隔离机制中，操作系统内核实施管理和安全验证所有核心资源的配额和访问，以保证系统的可靠性。操作系统内核为每个分区配置独立的CPU时间和内存空间，并在分区内提供分区操作系统服务，实现分区内资区发送虚拟中断，相应的分区操作系统在分配到的时间片中截获信号，完成中断处理，保证分区时间窗口的确定性，防止中断处理过长导致分区调度时钟窗口的不确定性。操作系统内核的空间域可以定义出一个空间保护模型，每个空间域(分区)有自己的内存地址空间，每个空间域类似于传统的操作系统的进程，空间域内的任务类似于传统的操作系统的线程。分区内调度的是任务，应用层和分区操作系统服第五个层次是应用任务进程或线程之间的时空隔离(图2.3-8)。即操作系统内核/或者分区操作系统负责为每个任务进程分配独立的地址空间和处理器服务时隙，并禁止进程之间的直接访问。进程之间的信息交换必须通过调用内核提供的IPC(见2.3.3.1章节)进程通信服务来完成。这一层次的隔离可以应用B应用B应用AOS内核/服务层处理器硬件上无法直接提供地址空间的隔离机制，需要通过软件技术来实现隔离保护。基于软件的隔离保护技术包括段保护、段匹配和地址沙箱技术。其具体的实现原理和特点见下表2.3-2。但无论是哪种基于软件在目标代码中的内存访问指令前插入优化过的运行时检测代码，如果发现要访问的段地址与当前段寄存器冲突，则抛出异常，并在系统失正动作依赖于处理器硬件结构和机器把指令分为安全指令和不安全指令。针对不安全指令(跳转指令、访存指令)进行检查。不安全指令可分为：可静态验证的指令(不通过运行就可确定其访问地址的指令)和不可静态验证的指令(其访问地址在程序运行时可能变需要四个专门的寄存器来存储且与处理器依赖关系强，移植在段匹配技术中，把每一个不安全指令的插入代码中的地址高位填充为预定的段标识符，地址填充并不捕捉非法地址，它仅仅阻止影响的任务的访存地址都在本段内部。地址填充需要在每一个不安全的存储或跳转指把结果存储到专用寄存器2.设置段标识符的正UMMU种是分段机制，一种是分页机制。分段机制只是在早期的X86架构处理器上引入(在X86-64架构之后转向了分页机制)，现代操作系统目前广泛使用的(无论是X86还是ARM架构)都是分页机制，后来还引入了多级页表机制。虚拟地址的哪个页面映射到物理内存的哪个页帧是通过页表(PageTable)来描础软件发展白皮书3.0MMU配合操作系统内核完成了诸多空间隔离功能，比如通过特权模式划分了内核空间和用户空间，用户空间无法直接访问内核空间，必须通过某些手段(系统调用，异常，中断等)切换到特权模式才能间接访问内核。此外，每个进程都拥有自己独立的地址空间，进程切换时地址空间也会切换。不同进程都拥有自己的一套页表，因而即使两个进程虚拟地址相同，映射的物理地址也是不同的。切换地址空间此外，操作系统内核还可以对每个页表的访问权限进行设置，当进程要访问不可访问权限的内存地址时，会产生一个异常通知处理器，操作系统内核可以通过捕获这种异常和对这种异常的合理处理来实随着计算单元硬件和虚拟化技术不断地进步，配合操作系统内核所能提供的软件隔离保护手段，基本上能够满足未来整车E/E架构智能集中化趋势下的时空隔离要求。具体使用哪种隔离机制或者几种隔3.实时任务调度技术在汽车应用领域，不可避免地要应对两类实时任务。一类被称为硬实时任务，这类任务无论在什么样的情况下都必须在规定的截止时间内执行完毕，否则会造成不可接受的后果(如因碰撞传感器引发的不会酿成安全事故。实时任务又可分为周期性任务，偶发任务(通常是硬实时)和非周期任务(通常是软实时)。无论是哪种车用操作系统，都面临着多个软硬实时任务(进程/线程)同时争夺有限资源的问题，需要操作系统内核提供合适的调度机制来满足硬实时任务截止时间要求，在此基础上，还需要满足其他系统和应用指标(周转时间，资源占用效率)。操作系统内核的任务调度机制通常可分为两大类-抢占式l非抢占调度方式是指当一个低优先级任务获得了处理器执行资源后，即使内核知道有更高优先级的任务在等待处理器资源，仍然会让这个低优先级任务继续执行，直到当前任务完成或发生某种事件而进入阻塞态时，才会把处理器资源分配给当前最高优先级的任务。虽然这种调度方式比较l抢占式调度方式是指当一个低优先级任务正在处理器上执行时，如果有更高优先级的任务出现需这种方式对提高系统的实时性和响应效率有明显的好处，但也要遵循一定原则，否则可能因为频能。很显然，车用领域的操作系统内核都必须支持基于任务优先级的抢占式调度方式。内核任务调度系统设计的核心是如何为每个任务定义合适的优先级，以保证包括任务截止时间在内的各项系统性能指标队列0当队列2为空队列0当队列2为空阻塞队阻塞队列时间片耗尽CPUCPU当队列0为空队列1当队列1为空队列2队队列n)为了简化系统设计，有的简要架构系统(如uC/OS-II)甚至规定所有任务的优先级都不同，任务的优先级也同时唯一标识了该任务本身，但在复杂系统下这个方法不太适用。通常我们会将系统中所有的任务按照一定的优先级定义划分为若干个不同优先等级的多级队列(Multi-LevelQueue，MLQ(图2.3-低优先级队列才能得到服务。此外，还需为每个任务队列采用合适的任务调度策略来决定哪个任务该优先获得资源(一般会采用FIFO和RR机制)。MLQ方法中，系统性能表现主要依赖于对任务优先级的合常用的任务调度策略和对应的任务优先级定义如下表2.3-3所示：法级高非抢占式，当长短任务混合时对短SJF优先级高非抢占式，必须预测任务的运行时间，而且性能严重依赖于任务到达时间(流量模型)。STCF短的优先级高抢占式，倾向于完成较短任务，导RR在任务运行时间相似的情况下平均WRR高的任务得到服务的比例高需为每个任务定义权重针对MLQ调度策略可能带来的低优先级任务饥饿(长时间得不到服务)和优先级反转问题(高优先Q础软件发展白皮书3.0同时还会对任务的运行时间做评估，即统计每个任务已经执行了多长时间，并据此判断此任务是长任务还是短任务，然后调整对应任务的优先级，被判断为长任务的优先级会被逐次调低。为避免低优先级任务长期得不到服务，还可以定时/不定时将所有任务优先级提到最高，再根据任务实际运行长短动态逐这种策略是要预先知道任务的周期，并根据周期静态地为每个任务分配一个优先级：任务的周期越短，RM以支持抢占式调度，高优先级的任务可以抢占低略。在实时性任务调度中，还可以采用最早截止时间优先(EarliestDeadlineFirst,EDF)策略。这种策，然后把不同线程分到这些分区里按上述调度策略进行调度。当分区里的处理器资源预算被用完以后，该同样可以采取“自适应分区调度”机制来改进调度性能，即定时计算各分区的算力闲置情况，在分区算需要指出的是，内核硬实时调度机制只是支撑硬实时任务的一部分，整个任务的实时性还需要依赖于应用本身的设计，例如在AUTOSARCP中还提出了通过将应用和CPU核(多核情况下)绑定，禁止总之，从技术发展趋势看，上述的这些基于优先级的抢占式进程调度机制通过一定程度的“动态”优化，都能很好地在满足硬实时任务的截止时间要求的基础上，照顾到软实时业务和其他非实时业务的4.健康监控在汽车安全车控和智能驾驶应用领域，操作系统内核除了要满足应用的实时性和确定性要求外，功能安全的保证也同等重要的。由于操作系统内核是由软件代码组成，从软件工程的角度来看，缺陷几乎是不可避免的，而这些缺陷在某些特定条件下有可能会引发功能安全故障。因此，为了及时在系统运行过程中发现这些故障，并及时处理以防止故障的扩散，避免引发功能安全事故，采取健康监控是一种必时，需进行记录故障、识别故的操作。在安全可靠性要求极高的飞行器航空电子领域中，健康监控功能已经成为飞行器安全的重要保障机制。国际航空电子标准PU车电子系统虽然没有统一的故障处理级别标准，但也可以参考航空电子标准中的健康监控机制，例如可将故障级别划分为分区级、管理级和核心级三个等级，并可对不同级别的故障设置不同的处理策略(图2.3-10)。级启动核心级健康监控模块，查询核心健康监控表，进行核心级故障处理启动分区级健康监控模块，查询分区健康监控表，进行分区级故障处理将异常分区挂到异常分区队列级启动核心级健康监控模块，查询核心健康监控表，进行核心级故障处理启动分区级健康监控模块，查询分区健康监控表，进行分区级故障处理将异常分区挂到异常分区队列故故障产生检测故障产生时的系统状态，检测故障产生时的系统状态，注入故障事件查查询系统健康监控表判判定故障级别启启动管理级健康监控模块，查询管理健康监控表，进行管理级故障处理UCPU底层硬件抽象层的异常处理程序首先会根据异常产生的位置来判定异常处理级别，然后健康监控系统根l如果CPU异常产生的位置是在操作系统内核态，则该异常属于核心级异常；l如果CPU异常产生的位置是用户态，则进行以下判断：如果用户分区产生的异常不是二次异常(用户分区触发异常的处理过程中再次触发的异常被认定。l分区级础软件发展白皮书3.0l管理级每个用户分区可以配置一个管理分区，用来帮助被管理用户分区处理自身无法处理的异常。被升级起)l核心级主要处理内核态程序运行过程中产生的一些异常和管理分区无法处理的被管理用户分区产生的异常，内核态程序运行过程中产生的异常需要执行健康监控中的内核默认异常处理，如记录异常上下文信分区内应用应用分区分区内应用分区级健康监分区级健康监控应用故障产生管理分区管理级健康监控操作系统内操作系统内核分区分区级管管理级系统健康监控表核心级健康监控核心级故障注入系统健康监控表核心级健康监控核心级故障注入产生整个健康监控系统的故障分派及处理的架构如图2.3-11所示，其核心是由操作系统内核所维护的内核检测到一个故障时，在系统健康监控表中通过系统状态和故障类型，获取事先定义的故障处理级别。系统健康监控表根据错误代码和注入时的系统状态指定故障的分派级别(分区级、管理级或核心级)。系统健康监控表是作为健康监控总体故障处理派发的一级表，当故障处理进入对应故障级别的处理流程后，根据各自故障级别的健康监控表(分区健康监控表、管理健康监控表、核心健康监控表)中对应的故障类型调用相应的处理程序(系统默认处理或用户自定义处理)。2.3.4典型应用案例国产车用操作系统应用案例从2017年开始，一些国内供应商本土化研发的车用操作系统已经陆续在上汽、一汽、长安等OEM厂商的验证交付项目和研发量产项目中得到应用。现阶段，一些有代表性的基础软件供应商正在与国内x (1)虚拟仪表量产项目nux大产品，其中，Hypervisor提供半虚拟化功能并提供隔离保障，微内核RTOS运行紧急仪表，Safetyl提供快速启动方案，支持启动动画；l提供中控投屏视频与仪表画面的融合方案；l提供仪表画质监控功能；l提供业务稳定性监控功能，异常情况下及时切换到紧急仪表。 (2)双内核智能驾驶操作系统解决方案RTOSSafetyLinux但获得所需功能安全等级认证较难。考虑到这些问题，某厂家基于自研车用操作系统产品系列，推出基SafetyLinux驶操作系统解决方案(图2.3-13)，可完整兼顾智能驾驶对功能智驾应用软件智驾服务框架及功能软件AUTOSARAPAILIBAUTOSARCPMicrokernelAUTOSARCPHypervisor异构SoC智能芯片础软件发展白皮书3.0lRTOSAI融合感知处理及算法类业务需要使用图形图像处理以及深度学习算法模型框架，对底层算力芯片的驱动适配要求也较高，这部分服务由SafetyLinux承载，可充分利用其既有成熟的软硬件生态快速完成开发。SafteyLinux支持POSIX标准中的大部分实时信号处理机制和功能，同时通过开源实时性RT同时，依托于某厂家微内核RTOS的ASIL-D级功能安全能力，通过在SafetyLinux中部署健康监控代理，实时对SafetyLinux的关键应用、内核和BSP进行异常监测和故障诊断，并根据故障等级和处众所周知，自动驾驶系统中有着大量的算法任务调度，海量的传感器数据交互，加上自动驾驶特有的应用场景，因此对操作系统有着非常严格的要求。对于操作系统而言，不但对实时性有着非常严格的微内核架构不仅保证了操作系统服务的硬实时性，并且在软件架构上也契合了SOA的软件开发思路，使得小魔盒在软件架构的设计上更简洁。QNX功能安全更是其优势所在，OSforSafety2.2通过了ISO26262ASIL-D认证，得益于此，小魔盒的安全认证变得更为简单。下半年首发于长城摩卡dht-phev激光雷达版，独有的城市NOH功能更是2.4虚拟化随着ICT技术的发展，单SOC算力可以承担更多业务，网络带宽拓展及低时延、区分服务等特性使汽车电子底层硬件不再是由单一芯片提供简单的逻辑计算，而是需要复杂的多核SoC芯片提供更为复杂控制逻辑以及强大的算力支持。但是多域业务具有不同的技术需求，比如座舱域IVI业务强调交互体oidRTLinuxRTOS时性、可靠性要求，也会选SOC干扰。、进程隔离等。硬件隔离的隔离性最好，单隔离域的性能、安全可靠性最好，但灵活性、可配置性差，不能实现硬件共享，离、进程隔离可以更轻量级地的优选方案，是软件定义汽车的重要支撑技术。典型应用场景如图2.4-1所示：2.4.1技术形态U按需分配给每个虚拟机，允许它们独立地访问已授权的虚拟资源。Hypervisor实现了硬件资源的整合和隔离，使应用程序既能共享CPU等物理硬件，也能依托不同的内核环境和驱动运行，从而满足汽车领域础软件发展白皮书3.0rlCPU虚拟机提供VCPU资源和运行环境；l虚拟机设备模拟：根据需求创建虚拟机可以访问的虚拟硬件组件；lCPUIO资源进行配置和管理；l虚拟机通信：为虚拟机提供IPC，共享内存等通信机制。l虚拟机调度：为虚拟机提供优先级和时间片等调度算法；l虚拟机生命周期管理：创建，启动和停止虚拟机；l虚拟机调测服务：提供控制台，日志等调试功能；l轻量高效。Hypervisor在带来软件定义的灵活性的同时，也导致了软件栈层次增加，不可避免会有性能损耗。汽车领域的成本敏感特性，注定了降低CPU、存储、网络、GPU等外设性能损耗的l安全可靠。相较于互联网领域看重的资源动态分配和闲置利用，汽车领域更看重Hypervisor的实2.4.2技术发展趋势边端虚拟化关键技术差异化的 (1)云侧虚拟化其特点是硬件平台基本同构，大量节点构成集群，架构设计以吞吐能力优先，要支持多业务并发，中断迁移。虚拟机故障时，要能保证从检查点恢复，减少业务损失，虚拟机要能支持CPU算力、内存、 (2)边侧虚拟化是在某些特定业务的边缘节点上，采用通用ICT架构，支持多种业务的动态部署，典型如SDN、 (3)端侧虚拟化案，不存在着集群、主备间的虚拟机迁移，因此比较强调高安全、单节点高可靠，比如会有功能安全ASIL等级要求，同时对于实2.虚拟化模型趋势rorVM地会存在延迟、性能损耗，同时宿主操作系统的安全缺陷及稳定性问题都会影响到运行在之上的VM(虚TypeHypervisor功能。设计上更简洁，直接运行于硬件之上，整体代码量和架构更为精简，对内存和存储资源要求更少，可满足自动驾驶车控系统功能安全等级要求，也具备进行形式化验证的条件。所以汽车操作系统更适合使用Type1型Hyper-础软件发展白皮书3.0 (1)全虚拟化过软件虚拟硬件设备提供给GuestOS使用，优点是GuestOS不感知外部真实硬件环境、不用改动。由一般只用来模拟如串口等比较简单的硬件。对硬件的模拟可以在Hypervisor中直接模拟，也可以将请求 (2)硬件辅助虚拟化Intel最早提出硬件辅助虚拟化技术，由硬件直接提供共享功能，支持多GuestOS的访问，减少软Intel别针对处理器&内存、IO、网络的IntelVT-x、Intele (3)半虚拟化SPassthrough对应的虚拟中断到该VM，直接透传的方式2.4.3关键技术解读1.CPU虚拟化和节能降耗技术车载高性能处理器一般采用多核CPU架构。在SMP(SymmetricMulti-Processing对称多处理)的操作系统可按照自己的调度方式，比如:：优先级方式在CPU上进行任务调度。为了最大化地利用系或时间分区方式对虚拟机进行调度，确保虚拟机运行时间和调度策略是确定的。Hypervisor的调度算法需要确保不能够出现分区内某个虚拟机出现死循环或故障而长期占用处理器资源，导致其他虚拟机的业虚拟机调度还需要考虑节能降耗问题，在工作负载较高的情况下系统提升主频提升用户体验，在工作负载较低的情况下系统自动节能降频提升续航。车载高性能处理器本身为了节能降耗需求设计为大小休眠(SuspendtoRAM/SuspendtoDisk)等节能降耗功能。系统虚拟化后，CPU等物理资源都需要VirtioOASISVirtio标准采用通用和标准化的抽象模型，支持设备类型不断增加，性能高效，在云计算领域广泛应用，Virtio的实现，如图2.4-6所示，在GuestOS内部虚拟一条设础软件发展白皮书3.0l利用virtio-blk技术实现块设备共享块设备是使用缓存机制读写的存储设备，分配给Hypervisor所在的操作系统进行管理。vir