计算机行业智能汽车深度系列之二：车载操作系统和中间件带来的机遇-20220403-东方-31正式版.pdf

计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 2 目 录 一、操作系统是汽车软件的核心，车企角力车载 OS . 5 二、中间件对于汽车软硬件解耦具有重要意义 . 11 2.1 车载中间件解决方案盘点 . 11 2.1.1 AUTOSAR：目前应用范围最广的车载电子系统标准规范 12 2.1.2 ROS 2：可支持自动驾驶场景的中间件 14 2.1.3 Iceoryx：博世自主研发的针对高级自动驾驶应用的通信中间件 18 2.1.4 其他通信中间件：SOME/IP 与 DDS 等 19 2.2 车载中间件有望成为国内汽车软件供应商的机遇点 . 23 三、相关公司介绍 . 25 3.1 中科创达：深耕操作系统底层技术多年，具备提供全栈式解决方案的能力 . 25 3.2 光庭信息：国内领先的智能汽车软件服务商 . 26 3.3 东软集团：东软睿驰是国内领先的操作系统及中间件解决方案提供商 . 27 3.4 经纬恒润： 在 AUTOSAR 软件产品方面具有深厚积累. 28 风险提示 . 29 pOqOoRyQrMtPmRzQmQpOtQ6M9R7NpNoOmOsQkPmMmQfQmMsO7NrQrOuOqRwPuOsOsR 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 3 图表目录 图 1：智能汽车软硬件架构概览 . 5 图 2：广义 OS 与狭义 OS . 6 图 3：三类车企自研操作系统 . 7 图 4：Android 内核架构 . 8 图 5：AliOS 操作系统演进三部曲战略 . 9 图 6：全球广义操作系统市场规模（亿美元） . 10 图 7：中间件对于推动汽车软硬件解耦具有重要作用. 12 图 8：AUTOSAR Classic Platform 架构 . 12 图 9：AUTOSAR Adaptive Platform 架构 . 12 图 10：AUTOSAR CP 功能安全等级高于 AUTOSAR AP . 14 图 11：ROS 的发展历史 . 15 图 12：ROS 2 利用 DDS 完成两个节点间通信 . 15 图 13：ROS 2 新增了 QoS 机制 . 16 图 14：ROS 1 与 ROS 2 的架构 . 16 图 15：Apex.OS 1.0 架构是基于 ROS 2 的 . 17 图 16：Cyber RT 架构 . 17 图 17：Iceoryx 可兼容 AUTOSAR 和 ROS 2 . 18 图 18：传统的数据传输会造成系统的低效率 . 18 图 19：Iceoryx 设计的“零拷贝”通信机制 . 19 图 20：SOME/IP 是一种面向服务的传输协议 . 20 图 21：SOME/IP 运行在车载以太网第四层以上 . 20 图 22：OMG 制定的标准 . 21 图 23：DDS 采用发布/订阅模型 . 21 图 24：RTI 是全球 DDS 最大的供应商 . 22 图 25：主机厂在中间件方案上有多种选择 . 24 图 26：百度 Apollo 也属于 ROM 型操作系统 . 24 图 27：底层操作系统能力是支撑公司各业务线的核心 . 25 图 28：公司具备提供座舱全栈式解决方案的能力 . 26 图 29：公司信息娱乐系统软硬分离解决方案 . 27 图 30：公司虚拟化座舱整体解决方案 . 27 图 31：东软睿驰系统软件解决方案 NeuSAR . 27 图 32：NeuSAR 提供了丰富的基础软件、中间件和开发工具 . 28 图 33：公司正式升级为 AUTOSAR 高级合作伙伴 . 28 图 34：EAS AUTOSAR Classic 工具链 . 29 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 4 图 35：EAS Adaptive AUTOSAR 解决方案 . 29 表 1：各 OS 内核比较 . 6 表 2：国内外车企 ROM 型操作系统对底层 OS 的选择不同 . 8 表 3：2021 与 2026 年新车座舱操作系统占有率预测 . 9 表 4：车载操作系统将经历车机 OS-座舱 OS-整车 OS 的发展历程 . 9 表 5：车载软件的单车软件 IP 授权费估算 . 10 表 6：Classic Platform 与 Adaptive Platform 的对比 . 13 表 7：ROS 2 较 ROS 1 提升了在产品环境的适用度 . 16 表 8：AUTOSAR 推动了 SOME/IP 协议的广泛使用 . 20 表 9：公司智能网联汽车业务五大产品线 . 26 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 5 一一、操作系统是汽车软件的核心，操作系统是汽车软件的核心，车企角力车载车企角力车载 OS 软件定义汽车时代下，软件定义汽车时代下，汽车软件汽车软件架构不断演进。架构不断演进。随着汽车不断向智能化、网联化方向发展，以单片机为核心的传统分布式电子电气架构已经很难满足未来智能汽车产品的开发需求。因此，汽车电子电气架构从传统分布式架构正在朝向域架构、中央计算架构转变，而集中化的 EE 架构是实现软件定义汽车重要的硬件基础。软件层面上，由于软件迭代周期越来越短，汽车软件架构也逐步由面向信号的架构（Signal-Oriented Architecture）向面向服务的软件架构（Service-Oriented Architecture，SOA）升级，以更好实现软硬件解耦与软件快速迭代。根据我们之前发布的报告智能汽车深度系列之一：汽车软件的星辰大海，目前汽车软件在智能汽车软硬件架构中自下而上可分为系统软件、功能软件、应用软件三类，软件已成为当前智能汽车差异化的关键。 图 1：智能汽车软硬件架构概览 数据来源：CSDN，东方证券研究所 车载车载操作系统操作系统是汽车软件的核心，是汽车软件的核心，可可分为分为狭义狭义 OS 和广义和广义 OS： 1 狭义 OS：指 OS 内核，又称为“底层 OS”，提供操作系统最基本的功能，负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性，是系统软件层的核心。 2 广义 OS：指控制和管理车载硬件和车载软件资源的程序系统集合，在汽车软件架构中起到承上启下的作用，不仅为上层应用的实现提供了高效、稳定环境的支持，也是各类应用调度底层硬件资源的“桥梁”。在汽车软硬件架构中，广义 OS 指系统软件层（包括硬件抽象层、OS 内核、中间件组件）与功能软件组成的软件集合。 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 6 图 2：广义 OS 与狭义 OS 数据来源：九章智驾，东方证券研究所整理 对于对于车车企企而言，而言，自研自研OS内核成本高，更多地是在现有内核的基础上内核成本高，更多地是在现有内核的基础上开发形成各自研自动驾驶开发形成各自研自动驾驶OS。目前自动驾驶OS内核竞争格局较为稳定，主要包括QNX、Linux、Android（基于Linux开发）、VxWorks、WinCE 等。因打造全新 OS 需要花费太大的人力、物力，目前基本没有企业会开发全新的 OS 内核。当前，无论是 Waymo、百度、特斯拉、Mobileye，还是一些自动驾驶初创公司、车企，所谓的自研自动驾驶 OS（属于广义 OS），都是指在上述现成内核的基础之上自研中间件和应用软件。由于各内核存在差异，车企在选择 OS 内核时，主要考虑安全性、可靠性、开放性、可扩展性、易用性及成本等因素，再结合自己的需求及能力体系来做权衡。例如，实时性、安全性好的 RTOS（Real-time OS，实时 OS），如 QNX、RT Linux 等，车企会优先考虑运用到对实时性、功能安全要求更高的驾驶域；而对应用生态丰富度要求高的座舱域，车企可以在 Linux、Android 等开放性好的内核基础上打造座舱域 OS。 表 1：各 OS 内核比较 ONX Linux VxWorks 开放性 半封闭 源代码开放 源代码开放 是否可裁剪 否 是 是 软件生态丰富程度 较丰富；商业公司提供，或自己从开源软件移植 非常丰富，主要来自开源软件社区 在自动驾驶产业影响较小 实时性 微秒级 毫秒级 （打开CONFIG_PREEMPT_RT后为微秒级） 微秒级 功能安全等级 ASIL-D 无 ASIL-D 开发工具和使用费用 昂贵 免费 昂贵 易用性 容易 最难 比较难 可拓展性 低 高 中 数据来源：九章智驾，东方证券研究所 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 7 根据根据对对 OS 内核改造程度不同，车企自研车载操作系统可大致分为三类：内核改造程度不同，车企自研车载操作系统可大致分为三类： 1 定制型操作系统：指在基础型操作系统之上进行深度定制化开发，覆盖系统内核层到应用程序层，最终（一般是 Tier1 和主机厂一起）实现座舱系统平台或自动驾驶系统平台。定制型操作系统研发成本高、开发难度大，一般需要车企进行大量、长期的投入，如特斯拉Version、大众 VW.OS、Google 基于 Linux 打造的 Android、华为鸿蒙 OS、AliOS 等均属于自研的定制型操作系统。 2 ROM 型汽车操作系统：基于 Linux 或 Android 进行有限的定制化开发，不涉及系统内核更改，一般只涉及汽车服务、车辆服务以及应用程序等内容的修改。此类操作系统研发难度相对较低，大部分主机厂一般都选择开发 ROM 型操作系统，例如奔驰 MBUX、宝马 iDrive、蔚来NIO OS、小鹏 Xmart OS 等。 3 超级汽车 APP：又叫手机映射系统，即把手机屏幕内容映射到中控大屏，通过整合地图、音乐、社交、语音等功能为一体来满足车主需求的 APP，如苹果 CarPlay、谷歌 Android Auto、百度 CarLife、华为 Hicar 等。 图 3：三类车企自研操作系统 数据来源：CDSN，东方证券研究所 国内国内外厂商在选择底层外厂商在选择底层 OS 方面存在差异。方面存在差异。从发展动向来看，主机厂一方面力图掌握智能汽车底层软件和硬件的控制权，更倾向中立的操作系统；一方面开展各种合作，利用开源软件组织，减少开发周期和成本。Linux 基金会在 2012 年启动了开源项目 Automotive Grade Linux （简称AGL），此项目的最终目标是提供满足安全关键系统的功能安全，从而服务自动驾驶应用。按照AGL的设想，未来成员企业可以共享70%的代码，另外30%则是不同品牌厂商进行差异化开发，从而保障各自的商业化利益，目前 AGL 成员已超过 100 家。由于 QNX 的高安全性以及 Linux 开源、免费等优势，国外车厂大多选择 QNX 与 Linux 作为底层操作系统进行开发；由于国内Android 应用生态更好，国内车企以及造车新势力大多基于 Android 定制操作系统。 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 8 表 2：国内外车企 ROM 型操作系统对底层 OS 的选择不同 底层底层 OS ROM 型操作系统型操作系统 国外传统车企 QNX 奔驰 MBUX、宝马 iDrive、奥迪 MMI、福特Sync3、大众 MIB、沃尔沃 Sensus Linux 丰田 G-Book、凯迪拉克 CUE Android 本田 Honda Connect、雪佛兰 MyLink 国内传统车企/造车新势力/互联网公司 Android 比亚迪 DiLink、吉利 GKUI、蔚来 NIO OS、小鹏Xmart OS、威马 Living Engine、百度小度车载 OS AliOS 荣威斑马智行系统 数据来源：CDSN，东方证券研究所 Android 内核相较内核相较 QNX 与与 Linux 在某些方面具备独有的优势。在某些方面具备独有的优势。 1 从架构来看，Android 的硬件抽象层对 Linux内核驱动程序进行了封装，把对硬件的支持分成了两层，一层放在用户空间（User Space），一层放在内核空间（Kernel Space），其中硬件抽象层运行在用户空间，而 Linux 内核驱动程序运行在内核空间。Linux 作为宏内核，把对硬件的支持和管理全部放在内核空间中，而复杂的内核结构会带来稳定性较差的问题；QNX作为微内核，内核中只有最基本的调度、内存管理，驱动、文件系统等，但频繁的系统调用与信息传递会使 OS 的运行效率较低。Android 内核居于 QNX 与 Linux 之间，较 Linux 有更好的稳定性，较 QNX 有更高的效率。 2 Android 之所以在用户空间新建一个 HAL 层（指硬件抽象层）来支持硬件设备，是由于Android 使用的开源协议是 Apache License，此协议比较宽松，其允许开发者获取并修改了源码之后，不用把源码公开出来。而 Linux 使用的开源协议 是 GPL，它的要求和限制较多，其中要求开发者添加或修改了源码之后，必须把添加或修改后的代码公开出来。HAL 层保护了开发厂家的利益，但脱离了 Linux 的开源。安卓是开放的，但不是开源的，这也是为什么把安卓从 Linux 分出去的主要原因。 图 4：Android 内核架构 数据来源：佐思汽研，东方证券研究所 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 9 未来未来 Android 在座舱在座舱 OS 的占有率有望提升。的占有率有望提升。目前座舱的操作系统可以分为三大类：（1）QNX；（2）Linux 类，包括像特斯拉这样的 Linux 直改、车规级 Linux 的 AGL、GENIVI 联盟（更名为COVESA）；（3）Android类，包括了国内Android直改，以及Google特别为车载推出的AAOS。由于 Android OS 具备独有的优势，同时国内 Android 应用生态较好，未来在座舱 OS 的占有率有望提升。根据佐思汽研预测，2026 年 Android 类 OS 在新车座舱操作系统的占有率将从 2021 年的 25%提升到 50%。由于 QNX的定制修改都需要 Blackberry 来做，BSP 需要为硬件定制，具备QNX 应用开发能力的开发者数量较少，未来 QNX 在座舱 OS 的占有率或将下降。 表 3：2021 与 2026 年新车座舱操作系统占有率预测 QNX Linux 直改直改 AGL GENIVI（COVESA） AAOS 安卓直改安卓直改 2021 55% 6% 6% 8% 5% 20% 2026 20% 10% 10% 10% 25% 25% 数据来源：佐思汽研，东方证券研究所 车载操作系统将车载操作系统将逐步逐步由座舱由座舱 OS 向整车向整车 OS演进。演进。很多汽车OS厂商是从车机 OS入局的，如苹果CarPlay、百度 CarLife、华为 Hicar 等，过去手机芯片、OS 和应用生态均优于汽车，因此将手机功能映射到汽车中控可以满足车主对娱乐的需求。随着汽车芯片以及软件生态的发展，当前汽车操作系统已步入座舱 OS 阶段，未来随着座舱域与自动驾驶域的融合，座舱 OS 将进一步向整车OS 迈进。在 2020 年初，斑马智行提出了 AliOS 操作系统演进三部曲战略，即智能车机操作系统、智能座舱操作系统、智能整车操作系统。如今斑马智行已经进入到了座舱 OS 阶段，下一阶段将重点布局智能整车 OS，以“OS+AI+芯片”为智能汽车决策核心，在操作系统层面推进汽车分布式智能向整车智能逐渐迈进。根据佐思汽研预测，2024 年以后将迈向整车 OS 阶段。 图 5：AliOS 操作系统演进三部曲战略 数据来源：佐思汽研，斑马智行，东方证券研究所 表 4：车载操作系统将经历车机 OS-座舱 OS-整车 OS 的发展历程 OS 类别类别 子类别子类别 面向整车厂面向整车厂/集成商集成商 面向用户面向用户 车机 OS AliOS 车机版、Android 等 华为 HiCar、百度Carlife 等 座舱 OS 底层 OS AliOS 座舱版、QNX、Android Automotive、鸿蒙 HOS 等 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 10 定制化 OS 百度 DuerOS、擎 OS、TINNOVE3.0 奔驰 MBUX、东风风神、Windlink 等 自动驾驶 OS 底层 OS 百度 Apollo、Apex.OS、DRIVE OS、华为 AOS 等 定制化 OS 国汽智控 ICVOS、东软 NeuSAR 等 整车 OS TINNOVE 5.0 等 VW.OS、丰田 Arene等 数据来源：佐思汽研，东方证券研究所 车企车企加大加大自研自研操作系统操作系统投入力度，行业规模有望持续增长。投入力度，行业规模有望持续增长。由于自研操作系统可以缩短中间件、应用软件等软件开发周期，并有助于生态的建立以及软件的持续迭代，各车企对实现车载 OS 自主可控的诉求愈发强烈。今年年初丰田汽车宣布计划于 2025 年推出自研的 Arene 操作系统；大众集团计划到 2025 年将自研车载软件比例提升至 60%；梅赛德斯-奔驰预计将于 2024 年发布自研的 MB.OS 操作系统完整版。根据麦肯锡数据，2020 年全球广义操作系统市场规模为 200 亿美元，到 2025 年约 370 亿美元，到 2030 年可达 500 亿美元，可见未来近 10 年内操作系统市场具有较大的增长空间。 图 6：全球广义操作系统市场规模（亿美元） 数据来源：麦肯锡，东方证券研究所 随着智能汽车功能复杂度的不断提升，单车软件随着智能汽车功能复杂度的不断提升，单车软件授权费价值有望持续提升。授权费价值有望持续提升。智能汽车软件的商业模式是“IP+解决方案+服务”的模式，Tier1 软件供应商的收费模式包括：（1）一次性研发费用投入，购买软件包，比如 ADAS/AD 算法包；（2）单车的软件授权费用（License），Royalty 收费（按汽车出货量和单价一定比例分成）；（3）一次性研发费用和单车 License 打包。若不考虑复杂度极高的自动驾驶软件，目前单车软件 IP 授权价值量大致在 2-3 千元左右。未来随着智能汽车功能以及操作系统的复杂度不断提升，单车软件授权费价值有望持续攀升，这也为 Tier1 软件供应商带来了机遇。 表 5：车载软件的单车软件 IP 授权费估算 软件软件 IP 单车软件授权费估算单车软件授权费估算 具体内容具体内容 操作系统内核优化 100-150 元 车载控制和信息娱乐两个 OS 的软件授权费用。按汽车平均单价测算，目前操作系统优化平均 100-150 元/车。 基础软件、中间件 200-300 元 CP AUTOSAR 和 AP AUTOSAR、SOA 软件平台，以及座舱中间件、自动驾驶中间件、车控中200370500010020030040050060020202025E2030E 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 11 间件等。 Hypervisor 100-150 元 以智能座舱为例，目前主要使用的方案是 QNX Hypervisor + QNX 仪表 + Kanzi 的组合，从入门费、服务费、授权费到其他开发成本，以及有效的技术支持。非开源的 Hypervisor 可能需要支付从入门费、席位费、服务费、授权费到其他开发成本及有效的技术支持，如黑莓 QNX 入门费约21 万美元。 人机交互 50-100 元 包括 UI/UX 设计软件授权费用、语音交互（前端声源定位、降噪和识别、语音云端的 ASR 和自然语义理解）、手势控制授权费等。 ADAS/AD 算法框架 200-300 元 核心共性功能模块包括自动驾驶通用框架、网联、云控等，算法的编程框架（如 TensorFlow、Caffe、PaddlePaddle 等）。 车内视觉 AI 算法软件 50-80 元 DMS 驾驶员疲劳检测、人脸识别检测、电子后视镜等。 环视和泊车软件 200-300 元 360 环视拼接、芯片内置的前视算法（如Mobileye EyeQ）、泊车软件等，视觉泊车可额外打成软件包卖给客户。 高精度地图软件 1000 元 现阶段高精度地图初始授权费 500-700 元，更新服务费 100 元/年，整车生命周期单车价值 ASP 将从过去的电子导航地图的 300 元/车提升至 1000元/车以上。 云服务、OTA和安全软件 200-300 元 SOTA、FOTA、信息安全软件、云服务。 网联软件 50-100 元 4G/5G 流量、C-V2X 软件栈和授权费、TCU 和网关软件。 数据来源：佐思汽研，东方证券研究所 二、二、中间件中间件对于汽车软硬件解耦具有重要意义对于汽车软硬件解耦具有重要意义 2.1 车载中间件解决方案盘点 软件定义汽车时代下，中间件的作用愈发重要。软件定义汽车时代下，中间件的作用愈发重要。随着 EE 架构逐渐趋于集中化，汽车软件系统出现了多种操作系统并存的局面，这也导致系统的复杂性和开发成本的剧增。为了提高软件的管理性、移植性、裁剪性和质量，需要定义一套架构（Architecture）、方法学（Methodology）和应用接口（Application Interface），从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统，这就是我们所说的“中间件”。汽车行业中有众多的整车厂和供应商，每家 OEM 会有不同的供应商以及车型，每个供应商也不止向一家 OEM 供货，中间件的存在尽可能地让相同产品在不同车型可重复利用或是让不同供应商的产品相互兼容，这样就能大幅减少开发成本。因此，可以说中间件在汽车软硬件解耦的趋势中发挥了关键的作用。 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 12 图 7：中间件对于推动汽车软硬件解耦具有重要作用 数据来源：AUTOSAR 官网，东方证券研究所 2.1.1 AUTOSAR：目前应用范围最广的车载电子系统标准规范 目前，目前，AUTOSAR 拥有拥有 Classic Platform 和和 Adaptive Platform 两大平台，分别对应传统控制类两大平台，分别对应传统控制类车辆电子系统与对应自动驾驶的高性能类车载电子系统。车辆电子系统与对应自动驾驶的高性能类车载电子系统。AUTOSAR（Automotive Open System Architecture）指汽车开放架构，是由全球汽车制造商、零部件供应商以及各种研究、服务机构共同参与制定的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构，规范了车载操作系统标准与 API 接口。AUTOSAR 拥有 Classic Platform 和 Adaptive Platform 两大平台： 1 Classic Platform（CP）：Classic Platform 是 AUTOSAR 针对传统车辆控制嵌入式系统的解决方案，具有严格的实时性和安全性限制。从架构来看，Classic Platform 自下而上可大致分为微控制器、基础软件层、运行环境层和应用软件层。 2 Adaptive Platform（AP）：Adaptive Platform 是 AUTOSAR 面向未来自动驾驶、车联网等复杂场景而提出的一种新型汽车电子系统软件架构标准。Adaptive平台修改了大量Classic平台标准的内容，采用了基于 POSIX 标准的操作系统，以面向对象的思想进行开发，并且可使用所有标准的 POSIX API，主要目的是为满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。 图 8：AUTOSAR Classic Platform 架构 图 9：AUTOSAR Adaptive Platform 架构 数据来源：AUTOSAR 官网，东方证券研究所 数据来源：AUTOSAR 官网，东方证券研究所 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 13 相较相较 Classic Platform，Adaptive Platform 更适应更适应高性能智能汽车的发展。高性能智能汽车的发展。随着通信技术的发展，汽车开始采用以太网通信，车载以太网为汽车 ECU带来了更高的带宽，使数据的大量传输能够在短时间得以实现。而 AUTOSAR CP 是为了传统的车载通信技术 CAN 设计的，不能很好地兼容以太网，难以支持基于车载以太网的通信。此外，随着汽车智能化程度提高，诸如自动泊车、环境感知、路径规划等高级功能对处理器的高算力需求远远高于对多核的需求。虽然 AUTOSAR CP 已经应用于传统的多核处理技术，但依旧无法满足车辆对 ECU 处理能力的需求；从处理器和半导体的技术角度来看，提高性能的唯一方法是多核并行运行，而并行运行以及所谓的异构计算也大大超出了 CP 能够覆盖的范围。由于 AUTOSAR CP 在通信速率及计算能力方面难以支持高性能智能汽车的发展，2017 年 AUTOSAR 联盟推出了通信能力更强、软件可配置性更灵活的AUTOSAR AP 平台。具体而言，AUTOSAR CP 与 AUTOSAR AP 主要区别如下： 1 支持的芯片平台不同支持的芯片平台不同：AUTOSAR CP 主要跑在 8bit、16bit、32bit 的 MCU 上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSAR CP 可能无法实现；而 AUTOSAR AP主要跑在 64bit 以上的高性能 MPU/SOC 上，对应自动驾驶的高性能电子系统，能够更好地支持多核、多 ECU、多 SoCs 并行处理，从而提供更强大的计算能力。 2 定义不同定义不同：AUTOSAR CP 并不只是“中间件”，而是“OS 内核+中间件”的一套完整的“操作系统”，定义了基本的上层任务调度、优先级调度等。分布式架构下的芯片主要是MCU，每一个 MCU 上都需要跑一套 AUTOSAR CP，例如在基于分布式架构的 ADAS功能中，AUOTSAR CP 便是最常见的“操作系统”。不同于 AUTOSAR CP 自身已经包含了基于 OSEK 标准的 OS，AUTOSAR AP 只是一个跑在 Lunix、QNX 等基于 POSIX标准的 OS 上面的中间件，因此它自身并不包含 OS，进一步地推进了软硬件解耦进程。 3 架构架构、通信方式、连接方式、通信方式、连接方式不同不同：（1）AUTOSAR CP 采用的是 FOA 架构，而 AUTOSAR AP 采用的则是 SOA 架构；（2）AUTOAR CP 采用的是基于信号的静态配置通信方式（CAN/LIN等），而 AUTOSAR AP采用的是基于服务的SOA动态通信方式（SOME/IP）；（3）在 AUTOSAR CP 中，硬件资源的连接关系受限于线束的连接，而在 AUTOSAR AP 中，硬件资源间的连接关系虚拟化，不局限于通信线束的连接关系。基于 SOA 通信使得 AP 中ECU可以动态地与其他ECU进行连接，此外 AP中各服务模块独立，具有更高的安全性以及部署灵活性。 表 6：Classic Platform 与 Adaptive Platform 的对比 Classic Platform Adaptive Platform 使用语言 C C+ 实时性 硬实时 软实时 适用场景 传统 ECU（如 ECM、VCU、BMS、MCU 等） 自动驾驶、辅助驾驶、车联网 应用架构 面向信号的架构（Signal-Oriented Architecture） 面向服务的架构（Service-Oriented Architecture） 功能升级 一般 ECU 开发后比较固定 可灵活在线升级 安全等级 最高到 ASIL D 最低 ASIL B（最高可到 D） 主要通信方式 CAN、LIN 以太网 操作系统 Autosar OS（OSEK OS） POSIX OS（Linux、QNX 等） 数据来源：CSDN，东方证券研究所 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 14 今后相当长一段时间内今后相当长一段时间内 AUTOSAR AP 都不可能彻底取代都不可能彻底取代 AUTOSAR CP，二者应用领域不同。，二者应用领域不同。在某些方面，AUTOSAR AP 与 AUTOSAR CP 相比是有一些“劣势”，例如 AUTOSAR CP 的时延可低至微秒级、功能安全等级达到了 ASIL-D，硬实时；而 AUTOSAR AP 的时延则在毫秒级，功能安全等级则为 ASIL-B，软实时。这也导致二者应用领域的不同：AUTOSAR CP 一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统 ECU；而AUTOSAR 则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如 ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。由于 SOC+MCU 组合的现象会长期存在，因此在今后相当长一段时间内，AUTOSAR AP 都不可能彻底取代 AUTOSAR CP。最常见的分工是，需要高算力的工作交给 AUTOSAR AP,而需要高实时性的工作则交给 AUTOSAR CP。 图 10：AUTOSAR CP 功能安全等级高于 AUTOSAR AP 数据来源：AUTOSAR 官网，东方证券研究所 2.1.2 ROS 2：可支持自动驾驶场景的中间件 ROS（Robot Operating System）指的是指的是机器人操作系统，机器人操作系统，是一套开源的软件框架和工具集，是一套开源的软件框架和工具集，用来帮助开发人员建立机器人应用程序，它提供了硬件抽象、设备驱动、函数库、可视化工具、用来帮助开发人员建立机器人应用程序，它提供了硬件抽象、设备驱动、函数库、可视化工具、消息传递和软件包管理等诸多功能。消息传递和软件包管理等诸多功能。ROS 系统是起源于 2007 年斯坦福大学人工智能实验室的STAIR 项目与机器人技术公司 Willow Garage 的个人机器人项目（Personal Robots Program）之间的合作，2008 年之后就由 Willow Garage 来进行推动。ROS 项目的初衷是为了给科研机器人Willow Garage PR2 提供一个开发环境和相应的工具。为了让这套软件在更多的机器人上运行，ROS 为机器人开发提供了一套相对完善的中间层、工具、软件乃至通用的接口和标准，机器人工业领域的开发者因此能快速开发系统原型并进行测试和验证。 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 15 图 11：ROS 的发展历史 数据来源：CSDN，东方证券研究所 ROS 2 对对 ROS 1 的部分缺陷实现了改进和提升，产品环境适用度更广。的部分缺陷实现了改进和提升，产品环境适用度更广。ROS 推出以后被大量地应用于工业领域，包括科研机器人、工业机器人、轮式机器人、自动驾驶汽车乃至航天无人驾驶设备，其原来的功能设计已经不能满足海量应用对于某些性能（如实时性、安全性、嵌入式移植等）的需求，ROS 2 即在这样的背景下被设计和开发。ROS2 与 ROS1 的主要区别包括： 1 ROS 1 主要构建于 Linux 系统之上，主要支持 Ubuntu；ROS 2 采用全新的架构，底层基于DDS（Data Distribution Service，是一种专门为实时系统设计的数据分发/订阅标准）通信机制，支持实时性、嵌入式、分布式、多操作系统，ROS 2支持的系统包括Linux、windows、Mac、RTOS，甚至是单片机等没有操作系统的裸机。 2 ROS 1 的通讯系统基于 TCPROS/UDPROS，强依赖于 master 节点的处理；ROS 2 的通讯系统是基于 DDS，取消了 master，同时在内部提供了 DDS 的抽象层实现。有了这个抽象层，用户就可以不去关注底层的 DDS 使用了哪个商家的 API，可以让开发者并行开发低耦合的功能模块，并且便于进行二次复用 图 12：ROS 2 利用 DDS 完成两个节点间通信 数据来源：CSDN，东方证券研究所 计算机行业深度报告 智能汽车深度系列之二：车载操作系统和中间件带来的机遇 有关分析师的申明，见本报告最后部分。其他重要信息披露见分析师申明之后部分，或请与您的投资代表联系。并请阅读本证券研究报告最后一页的免责申明。 16 3 ROS 1 运行时要依赖 roscore，一旦 roscore 出现问题就会造成较大的系统灾难，同时由于安装与运行体积较大，对很多低资源系统会造成负担；ROS 2 基于 DDS 进行数据传输，而DDS 基于 RTPS 的去中心化的通信框架，这就去除了对 roscore 的依赖，系统的稳定性强，对资源的消耗也得到了降低。 4 ROS 2 新增了 QoS（Quality of Service，质量服务原则），主要对通信的实时性、完整性、历史追溯等方面形成了支持。这大幅加强了框架功能，避免了高速系统难以适用等问题。ROS 1 缺少 QoS 机制，Topic 的稳定性与质量难以保证。 图 13：ROS 2 新增了 QoS 机制 图 14：ROS 1 与 ROS 2 的架构 数据来源：创客智造，东方证券研究所 数据来源：创客智造，东方证券研