您正在访问亚汇网香港分站,本站所提供的内容均遵守中华人民共和国香港特别行政区法律法规。

汽车软件黄金赛道,多维度剖析厂商成长性

文 / 雅山 2022-03-12 10:17:48 来源:亚汇网

   1. 汽车智能化推动软件定义汽车时代的到来

   回顾汽车产业发展历史,汽车产业经历了从机械时代到电子时代到如今向软件时代迈进的发展历程。上个世纪 80 年代以来 ECU 开始不断上车,汽车行业以 Tier1 为中心通过增加 ECU 来提升车辆功能,这一过程中汽车软件以和硬件深度耦合的方式得到发展;现如今,各汽车企业生产的不同车型的硬件配置已逐渐趋同,成本和功能改善空间有限,而新能源和智能化逐渐获得成功,汽车软件开始成为车企打造差异化的核心要素,汽车行业逐渐迈向软件定义汽车(Software Defined Vehicles, SDV)的时代。

   整个汽车行业都在向智能化转型。不同于传统汽车,智能汽车通过全新的软件技术, 能够为车主创造丰富的可感知价值和更安逸的驾驶体验。近年来,全球越来越多的整车厂、零部件厂商以及谷歌、苹果、百度等科技公司开始投入智能化汽车的研发中来,智能汽车正在快速抢占汽车市场。就自动驾驶功能举例来说,全球主流车企正密集研发 L3 级以上自动驾驶,未来自动驾驶的搭载率及自动驾驶等级将不断提升。汽车智能化将推动汽车软件开发需求爆发式增长。一辆“数字”汽车(2015 年)的软件代码量能够达到 1 亿行,远高于 facebook、战斗机、人造卫星等高科技产品的代码量。而随着智能座舱、自动驾驶等智能化模块的发展,汽车软件代码量仍在以超过 20%的年增长率剧增。一辆 2025年生产的智能汽车代码量预计将达到 7 亿行, 相较于 2020 年增加了 2.3 倍。由此可见,汽车制造的技术壁垒也由传统三大件以及零部件的集成能力转变为代码研发的能力,随着汽车智能化不断升级以及软件生态的逐渐繁荣,汽车软件开发需求将爆发式增长,整车软件成本占比将大幅提升。

   汽车软件市场规模将持续扩大。全球汽车软件市场:Berylls管理咨询公司预计汽车软件市场规模将在 2020-2030 年期间增长逾三倍,年均增长率为 13%,市场规模将从 760 亿欧元增长到 2520 亿欧元。具体来看,智能驾驶领域(ADAS/AD)将在 2020 年至 2030 年期间占据汽车服务市场增长的最大份额,软件平台、安全以及集成测试验证也将有较高的复合增速,当然增速最快的将是高性能计算平台(HPC),预计将达到 37%。如果要将整个市场增量做进一步拆分,核心增量(约 2100 亿欧元)来自于智能化功能复杂性的提升,同时由于软件模块化及开发方式转变带来的效率提升也会减少开发支出 620 亿欧元。1.1. EE 架构升级是软件定义汽车的硬件基础

   智能化与网联化必须建立在电子电气架构核心的计算能力上,没有硬件基础无法实现软件定义汽车,汽车 EE 架构的变革主要体现在一下 4个方面:

   计算性能:汽车芯片由 MCU 转向 SoC.MCU 芯片通常只包含一个 CPU 处理器单元、存储和接口单元,算力一般仅几百 DMIPS;而 SoC 是系统级芯片,一般采用“CPU+AI 芯片(GPUFPGAASIC)”架构方案,如英伟达 Orin X 算力高达 254TOPS.智能座舱和自动驾驶对汽车的智能架构和算法算力带来了数量级的提升需要,以 MCU 为主的汽车芯片将无法满足这些需求,转向搭载算力更强的 SoC 芯片;

   通讯带宽:车载以太网成为汽车骨干通讯网络。传统的分布式架构中 ECU 之间大多通过 CAN 通讯、LIN 通讯、Flex Ray 等通讯,数据的传输速度非常有限,一般只有几兆每秒。随着车内传感器数量增加,数据传输体量和速率要求大幅提高,未来车载以太网将成为汽车骨干网,在单对非屏蔽双绞线上可实现 100Mbit/s,甚至 1Gbit/s 的传输速率。

   软硬解耦实现 OTA 升级。软件不再是基于某一固定硬件开发,汽车原有 ECU 软件烟囱式垂直架构转变为通用硬件平台+基础软件平台+各类应用软件的水平分层架构,实现软硬件的解耦。硬件预埋,软件后部署,通过不断 OTA 实现软件功能迭代推动整车功能升级。

   更好的成本管控。目前在高端车型与智能化程度高的车型中主要 ECU 的数量达到 100 多个,加上一些简单功能的 ECU 总数可以超过 200 个,ECU 增加对应线束增加带来成本提升,通过域控集成方式可较大幅度减少 ECU 数量;此外,ECU 由不同供应商提供,任何功能修改涉及多个控制器重新开发、验证, 耗时耗力,且软件逻辑被供应商把控,主机厂无法对软件功能实现高效管理。在智能化、网联化变革趋势下,软件和硬件在零部件层面解耦,软件独立成为核心零部件产品。汽车软件产品获得的多维的车辆数据和控制权限,实现复杂的功能和任务执行。汽车软件的越来越复杂,行数快速提升,逐步形成系统 OS 和应用软件的架构,汽车软件开发难度提升。

   1.2. SOA 是软件定义汽车的软件趋势

   传统分布式 EE 架构下,汽车软件的运行主要基于面向信号架构(Signal-Oriented Architecture),这种软件架构无法满足智能化汽车的需求:

   固定化的架构缺乏灵活性。ECU 各功能的编码在架构设计阶段被预先定义在 ECU 排序文件中,运行过程中依次调用、逐个运行。ECU 间信号收发关系是静态的,信号只能由网关转发,不具备灵活性。同时,这种固定化的软件架构限制了使用者个性化开发的需求,OTA 外部开发者无法由软件定义新功能,且无法支持在线升级和软件的迭代更新。

   面向信号架构无法实现人车交互。面向信号架构仅支持接受和发送模式,不支持请求和响应模式,不能实现交互,智能汽车的特点无法发挥。

   分布式架构下软件与硬件高度耦合,软件运行依赖于硬件。当软件发生改动或升级时,需要对整车进行集成验证,时间花费较长且难度较大。此外,当某一控制器出现问题时,相应的功能也可能全部失效,既造成了成本上升,在智能座舱、自动驾驶等智能功能下也将造成极大的安全问题。

   软件功能改动成本高,难度大。在传统的面向信号架构下,如果某个软件功能需要改动,整车通讯系统和 ECU 都要发生改动,而 ECU 数量的急剧增加使得这一过程的成本和复杂度显著上升。

   SOA 将车端不同功能及硬件能力划分为服务,并按整车的原子能力将服务拆分为颗粒度更小的接口。各服务组件的接口进行标准化封装,可通过既定协议互相访问、 拓展组合;SOA 的核心要素包括松耦合、标准化定义、软件复用等。SOA 使应用层功能可在不同车型上复用,且能够基于标准化接口快速响应用户新的功能需求, 软件工程师在修改或新增某一软件功能时,只需对上层相对应的服务组件进行代码编写,而无需进行基础软件层、运行环境层和其他软件组件的重新编译和重复开发, 这极大地减少了软件升级的复杂度和成本,提高了效率。从长期来看,汽车企业将引入大量算法供应商、软件开发商和服务厂商共同搭建 SOA,为智能化的汽车软件提供优质的运行平台,也为客户提供全覆盖的软件服务。 因此,各大汽车企业逐渐将工作重心转移到 SOA 的合作开发,预计未来 5 年将迎来 SOA 的量产高峰期。

   当然,要清醒的认识到理想的 SOA 开发成本较高,跨 ECU 的 IPC(进程间通信) 一定比 ECU 内 IPC 更复杂,需要做额外的接口包装,会增加额外的调度和计算资源,且这些代价和成本并不直接带来用户体验的提升。因此,SOA 式架构不会是一蹴而就的。

   2. 汽车软件架构

   智能汽车软件分为三层架构,包括:1、底层系统软件层,包括 BSP、虚拟机、系统内核、中间件组件等;2、功能软件层:包括库组件、中间件等,位于操作系统、网络和数据库之上,应用软件的下层,为应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件;3、上层应用算法软件层,包括智能座舱 HMI、ADAS/AD 算法、网联算法、云平台等,用于实际实现对于车辆的控制与各种智能化功能。2.1. 系统软件层——狭义操作系统

   汽车操作系统是管理和控制智能汽车硬件和软件资源的底层,提供运行环境、通信机制和安全机制等。按照对底层操作系统改造程度以及能力深度的不同,主要可以分为以下几种∶

   基础型操作系统:如 QNX、Linux、WinCE 等,包含全新底层操作系统和所有系统组件,如系统内核、底层驱动等,有的还包括虚拟机。

   定制型操作系统:指在基础型操作系统之上进行深度定制化开发(包括修改内核、硬件驱动、运行时环境、应用程序框架等),最终实现座舱系统平台或自动驾驶系统平台,如大众 VW.OS、特斯拉 Version、google 车载 Android、华为鸿蒙 OS、AliOS 等。

   ROM 型汽车操作系统:基于 Linux 或安卓等基础型操作系统进行有限的定制化开发,不涉及系统内核更改,一般只修改更新操作系统自带的应用程序等。 大部分车企一般都选择开发 ROM 型操作系统。

   超级 :又称车机互联或手机映射系统,不是完整意义上的汽车操作系统, 其借助手机的丰富功能映射到汽车中控,以满足车主对娱乐的需求,代表有苹果 CarPlay、百度 CarLife、华为 Hicar 等。2.1.1. 底层 OS:决定系统性能,是软件定义汽车的关键

   操作系统内核又称为“底层 OS”,提供操作系统最基本的功能,负责管理系统的进程、内存、设备驱动程序、文件和网络系统,是系统软件层的核心。由于开发难度最大且安全性要求最高,其市场竞争格局较为稳定,主要以 QNX、Linux、Android、 WinCE 为主。

   长期看,未来市场将是 QNX、Linux、Android 三足鼎立的局面。根据 IHS Automotive 数据统计,系统内核目前主要以 QNX 和开源的 Linux、Android 为主,合计市占率已近 90%。从系统性能上,三大主流系统各具优势。目前 QNX 凭借高安全性、高稳定性和高实时性,牢牢占据汽车嵌入式操作系统市占率第一的位置。Linux(包括基于 Linux 开发的 Android)与 QNX 相比最大的优势在于开源,具有很强的定制开发灵活度、扩展性强。从适用领域上看,QNX 系统更适用于仪表系统、动力系统等对安全性能要求更高的领域,而 Linux 和 Android 在车载信息娱乐领域更具优势。

   预计 Android 系统市场比重将不断提升。相比于 Linux,Android 系统在国内应用更广,在车载信息娱乐领域发展空间大,因为安卓是对接移动互联网内容最好的工具。 尽管存在安全性、稳定性差的问题,但其凭借开源、灵活性强、生态丰富的优势在国内占据主流地位,特别是在安全性要求相对较小的车载信息娱乐领域发展空间大。 国内自主品牌和造车新势力也大多基于 Android 定制 ROM 型汽车操作系统。2.1.2. 头部车企和科技企业入局操作系统,旨在建立领先优势

   车载操作系统是汽车生态关键,头部主机厂和第三方企业都积极布局汽车操作系统。 在车企中,类似于 Tesla.OS、大众集团的 VW.OS、戴姆勒 MB.OS、 BMW-OS、吉利 GKUI 等,都是基于 Linux、QNX 和其他 RTOS 等内核实现硬件抽象化,形成支持应用开发的中间层操作系统,定义开发者交互逻辑,搭建应用层。

   自研操作系统有助于简化车辆软件开发流程及增加 OTA 频率。以特斯拉为例,由于采用开源 Linux 自研操作系统,特斯拉可以不再依赖于软件供应商,而是自己完全掌握堆栈,一旦发现问题即可通过 OTA 进行快速修正与升级,提升用户体验。自 2014 年首次在 Model S 上使用自研操作系统以来,特斯拉已通过 OTA 技术对其操作系统进行了多次重大升级。

   自研操作系统而后向产业链企业开放车辆编程,可以掌握开发者生态资源,形成一定垄断优势。有了操作系统就可以建立生态垄断,对上层各组成部分和应用进行全面的把控。例如德国大众自研 VW.OS,依托自身近千万辆汽车年销量,迫使 Tier1 以及软件供应商甚至其他 OEM 在 VW.OS 的基础上进行开发,使之成为智能手机领域的 IOS,最终形成“OS 授权许可费+车联网服务+ 对接许可费+ 增值服务分成”的商业模式,获得超额利润。第三方汽车操作系统玩家包括 TINNOVE 梧桐车(腾讯系)、斑马智行(阿里系)、 国汽智控、百度和华为等,这些企业主要是在主流底层 OS 基础上进行独立操作系统的研发。从技术上看,互联网及科技企业凭借自身软件研发的优势,对系统改造程度高、产品生态丰富。因此,第三方企业产品本身具备较强竞争力,可与生态较单一、研发能力欠缺的车企进行合作,形成良性互补。

   从与车企合作情况上看,第三方企业与车企积极合作,伙伴众多。2016 年斑马智行与上汽合作推出搭载 Alios 系统的荣威、名爵等十多款车型,2017 年与神龙汽车合作。华为超级 系统 HiCar 目前合作的车企超过 20 家,包括沃尔沃、长安、吉利、东风、广汽传祺、比亚迪等品牌,合作的车型超过 150 款。2.2. 系统软件层——BSP 层

   BSP(板级支持包)是内核与硬件之间的接口层,一般认为它属于操作系统一部分。 BSP 中主要包括 Bootloader(以基础支持代码来加载操作系统的引导程序)、HAL (硬件抽象层)代码、驱动程序、配置文档等。对于具体的硬件平台,与硬件相关的代码都被封装在 BSP 中,由 BSP 向上提供虚拟的硬件平台,与操作系统通过定义好的接口进行交互,使之能够更好的运行于硬件主板。其目的在于为操作系统提供虚拟硬件平台,使其具有硬件无关性,可以在多平台上移植。

   BSP 是相对于操作系统而言的,不同的操作系统对应于不同定义形式的 BSP.例如 VxWorks 的 BSP 和 Linux 的 BSP 相对于某一 CPU 来说尽管实现的功能一样,可是写法和接口定义是完全不同的,所以写 BSP 一定要按照该系统 BSP 的定义形式来写,这样才能与上层 OS 保持正确的接口。

   Tier1、OEM、Tier2 厂商均有参与 BSP 市场,而由于高端芯片 BSP 开发需要深度理解芯片架构,目前市场中以和芯片厂商紧密合作的第三方公司如中科创达等公司为主要力量。中科创达与高通、瑞萨、德州仪器、恩智浦等领先芯片供应商保持深度合作,对相关公司的芯片具有深刻理解,可以代表芯片厂商为车厂/Tier1 提供 BSP 技术支持。(报告来源:未来智库)2.3. 虚拟层(Hypervisor)

   为了让不同类型的操作系统运行在一个计算平台上,最直接的技术路径就是虚拟化 (Hypervisor),虚拟化技术可以模拟出一个具有完整硬件系统功能、运行在一个完全隔离环境中的计算机系统,此时供应商不再需要设计多个硬件来实现不同的功能需求,而只需要在车载主芯片上进行虚拟化的软件配置,形成多个虚拟机,在每个虚拟机上运行相应的软件即可满足需求。因此,车载虚拟化操作系统要求具备以下三点技术要求:(1)使用资源分区技术严格隔离和分配资源;(2)具备灵活高效的实时和非实时任务调度机制;(3)进程间通信,实现消息在虚拟机之间通信。

   目前主流的虚拟化技术提供商为 QNX 和 ACRN.常见的 Hypervisor 包括黑莓的 QNX、英特尔与 Linux 主导的 ACRN、Mobica 为代表的 XEN、松下收购的 Open Synergy 的 COQOS、德国大陆汽车的 L4RE、法国 VOSyS 的 VOSySmonitor 等, 其中最主流的是黑莓的 QNX 及英特尔与 Linux 主导的 ACRN,而 QNX 作为唯一被认可达到 ASIL D 等级的虚拟化操作系统,已经量产应用到实际车型中。整个操作系统是由微内核调度管理的一组进程集合,安全性与实时性有保障。目前,黑莓 VAI 项目的中国区系统集成商类的合作伙伴主要包括中科创达、武汉光庭信息、 南京诚迈科技等。2.4. 中间件:软件开发的关键“纽带”

   在中间件出现之前,系统软件是直接基于操作系统开发,导致软硬件高度耦合。随着车内代码量的增长导致系统的复杂性和成本剧增,为了提高软件的管理性、移植性、裁剪性和质量,需要定义一套标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统。中间件将软件、硬件进行分离,对下层硬件资源进行抽象、利用,对芯片进行驱动并优化操作系统,对上层软件提供服务接口, 为不同算法提供不同类型的插件。中间件解决数据传输、应用调度、系统集成和流程管理等问题,可大幅提升应用层软件的开发效率。

   经典中间件设计标准:AUTOSAR.汽车电子软件标准主要包括 AUTOSAR、 OSEK/VDX 等,其中 AUTOSAR 标准发展了十多年,已经形成复杂的技术体系和广泛的开发生态,是汽车中间件主流设计标准。AUTOSAR 规定了分层架构、方法论和应用接口规范,使得汽车嵌入式系统控制软件开发者,得以在 ECU 软件开发与验证过程中,摆脱对硬件系统的依赖,实现了软硬件的分离。AUTOSAR 整个架构从上到下分层依次为:应用层(Application Software layer),运行时环境(Runtime Environment,RTE),基础软件层(Basic Software layer,BSW), 微控制器(Microcontroller)。每层之间为保持独立性,每一层只能调用下一层的接口,并为其上一层提供接口。

   AUTOSAR 的优势主要有:1.有利于提高软件的复用度,使软件可以跨平台复用; 2. 便于软件的交换与更新;3. 软件功能可以进行先期架构级别的定义和验证,从而减少开发错误;4. 减少手工代码量,减轻测试验证负担,提高软件质量;5. 使用一种标准化的数据交换格式(ARXML),方便各个公司之间的交流合作。

   AUTOSAR 分为 Classic Platform 和 Adaptive Platform 两大平台,其中 Classic Platform 主要面向分布式 ECU,Adaptive AUTOSAR 主要面向更复杂的域控制器和中央计算平台的电子电气架构。相比于 Classic AUTOSAR ,Adaptive AUTOSAR 的优势在于:实时性强、操作系统移植性高以及软件升级更灵活。

   AUTOSAR 是传统汽车行业巨头们制定的游戏规则,目前已有超 300 家生态伙伴企业。目前全世界范围内能开发完整的基于 AUTOSAR 架构底层协议栈的公司寥寥无几,目前全球知名的 AUTOSAR 解决方案厂商包括 ETAS(博世)、EB(Continental)、 Mentor Graphics(Siemens)、Wind River(TPG Capital),以及 Vector、KPIT(美印合资)等,大部分 Tier 1 和主机厂都需要向上述几家供应商购买底层软件。在中国, Classic AUTOSAR 标准下的开发工具链及基础软件上述海外供应商占据主导地位, 国内主要是东软睿驰、华为、经纬恒润等;Adaptive AUTOSAR 方面,仍处于起步阶段,大陆 EB 与和大众合作将 AP AUTOSAR 和 SOA 平台应用于大众 MEB 平台 ID 系列纯电动车型上。国内厂商纷纷将 AP AUTOSAR 作为发力重点,推出相应的中间件及其工具链产品,抢占市场先机。整个 AUTOSAR 的框架中真正对控制有作用的只有 Application layer,其他 RTE 及以下层都是起辅助作用的,不同 Application 层的功能对应的 BSW 基本相同,而且 AUTOSAR 要求软件工程师严苛的按照标准进行“写作”。这样在分布式架构下会造成控制器数量越多,软件行数越多,软件开发成本也就越高。在域控架构下由于 ECU 和执行器还仍然遵循 AUTOSAR 这个标准的时候,无法大幅度减少代码量。因此特斯拉不用 AUTOSAR,依托自研的操作系统和基础软件实现更高效的开发。

   2020 年 7 月 22 日,一汽、上汽、广汽、蔚来、吉利、长城、长安、北汽福田、东风、一汽解放、小鹏汽车、东软睿驰、恒润、拿森、地平线、苏州挚途、万向钱潮、 威迈斯、重塑、中汽创智这 20 家企业组成中国汽车基础软件生态委员会 (AUTOSEMO),旨在形成由本土企业主导具有自主知识产权的基础软件架构标准和接口规范,共享知识成果,建立产业生态。

   2.5. 功能软件层

   在汽车软件架构中,功能软件主要包含自动驾驶的核心共性功能模块。核心共性功能模块包括自动驾驶通用框架、网联、云控等,结合系统软件,共同构成完整的自动驾驶操作系统,支撑自动驾驶技术实现。

   目前在功能软件层面,传统 Tier1、OEM、科技巨头、第三方软件供应商都有一定布局。各方可凭借自身的优势提供解决方案,选择擅长的模块进行开发,例如在传感器领域有优势的算法厂商可以专注于功能软件中传感器模块的开发,实现整个行业更为有效的分工与合作。

   在功能软件领域,与供应商合作的模式有助于满足车企自身对于智能汽车产品功能研发的需求。相比于车企,各大供应商开发的软件模块经过不同情景、在不同产品上的检验,质量更具有保障。且一些软件供应商可根据车企自身特色,提供更适合车企的解决方案,加快研发效率。例如为研发能力比较强的车企提供功能模块方案,开放干净的接口,让车企自己去控制整个用户体验和产品定义。而面向软件能力还不完善的车企,可以提供软硬件集成交付方案,大大缩短车企研发周期。2.6. 应用软件层

   应用层软件运行在广义操作系统之上,具体负责功能实现。主要包括面向自动驾驶算法、地图导航类、车载语音、OTA 与云服务、信息娱乐等。典型的计算平台,在装载运行系统软件和功能软件构成的操作系统后,向上支撑应用软件开发,最终实现整体功能实现。上层的应用软件层是 OEM 重点研发打造差异化的领域,比如座舱 HMI、自动驾驶等。因此,目前整车厂、传统 Tier1、初创企业、科技巨头以及独立的软件企业等在上层软件领域都在积极发力。

   从长期来看,上层应用与算法价值量最大。在短期内,汽车软件领域内企业若想真正落地 SOA 软件架构,虚拟化技术、系统内核及中间件(AUTOSAR)等系统软件至关重要。但从长期来看,在 SOA 架构以及广泛的操作系统框架构建成熟后,丰富的上层应用生态与算法将具备更大的价值空间。

   典型上层应用示例一:自动驾驶域上层的应用算法

   自动驾驶域控制器上层应用算法包括场景算法(涵盖数据感知、决策规划、控制执行等)、数据地图、人机交互(HMI)等,其中场景算法最为复杂,典型的包括感知、 决策、执行三个维度的算法,进而实现各类场景下的自动驾驶功能。主机厂自研自动驾驶算法成为未来趋势。中短期看,由于大多主机厂自身算法能力缺失,主机厂会选择与具备明显算法优势的 Tier1 或者软件公司合作,在这个阶段博世、大陆、德赛西威、中科创达等企业具有明显优势。但从长期来看,当主机厂在拥有人才、数据优势后,将从关键算法(如融合/决策算法)上逐步自研,以最终延伸全栈式算法能力。在这样的趋势下,供应商应跟随当前 OEM 需求明确自身定位,或者专注于自动驾驶应用层的某一领域,使对某领域算法精通、能力突出,才能保持持久竞争力。

   典型上层应用示例二:数字地图

   在自动驾驶领域,高精度定位与地图(数据地图)的支持是实现高级自动驾驶的保障,市场规模将不断扩大。高精度地图不仅可以保证特殊天气条件下依然发挥作用, 还可以有效消除部分传感器误差并对现有传感器系统进行补充修正。此外,高精度地图还可以构建驾驶经验数据库,分析危险区域,为驾驶者提供新的驾驶经验数据集。

   当前,高精度地图领域主要玩家有四维图新、高德、百度,三家公司呈三足鼎立态势。三家公司各有优势:百度为国内最早开展高精度地图研究的公司,2013 年启动无人车项目研发;高德拥有阿里巴巴全力支持,进展较快;四维图新为国内老牌图商。2020 年三家公司占据 65%以上的市场份额,形成“三足鼎立”局面。3. SDV 带来产业链重塑及竞争格局分析

   3.1. 产业链重塑

   3.1.1. 主机厂尝试主导整车软件部分,软件厂商向 Tier1 进阶

   主机厂开始深度参与软件开发。在传统的汽车产业链中,各系统软件的开发几乎全部由 Tier1/2 完成,黑盒供应给主机厂,主机厂只是整体架构的定义者,负责设计、 管理系统概念的定义,最终完成系统集成和检验的工作,即下图中黄色部分。随着汽车软件的重要性不断提升,主机厂开始重视定义软件,深度参与系统架构、功能需求分析等环节,甚至主导软件单元设计与研发,即下图绿色和红色环节。

   软件供应商向 Tier1 进阶。主机厂无论是同核心软件企业建立合作还是自主研发, 传统供应链关系都将发生根本性的变化。车企与软件供应商的协作将进一步加深, 整车厂为了掌握主导权并降低高昂的研发成本,会选择直接与具备较强的独立算法研发能力的软件供应商合作,因此这些软件供应商一跃成为了 Tier1 厂商,打破软件厂商作为 Tier2 先供应给 Tier1 再到 OEM 的塔状供应模式,向扁平化的供应网络模式发展。

   对于软件供应商来说,随着 OEM 主机厂自主权和软件自研能力的不断加强,OEM 主机厂开始寻求与软件供应商的直接合作,比如 OEM 厂商将首先寻求将座舱 HMI 交互系统功能收回,UI/UX 设计工具、语音识别模块、音效模块、人脸识别模块等应用软件则直接向软件供应商购买软件授权,从而绕过了传统 Tier1,实现自主开发。 对于软件供应商来说,能提供越多的软件 IP 产品组合,就可能获取更高的单车价值。同时,软件供应商也正寻求进入传统 Tier1 把持的硬件设计、制造环节,比如域控制器(中科创达)、TBOX 等,以提供多样化的解决方案。3.1.2. 软件开发向分层化、模块化演变,中间模块供应商市场机会大

   从传统 V 型开发转向面向软件定义汽车的分层式开发,转变基础是中间件的引入。 域控架构下应用算法复杂程度高,尤其是自动驾驶领域几乎没有任何一家公司能够提供一整套的软件系统,所以需要多家供应商来合作完成整套软件包,由于中间件的引入实现了软硬件的解耦,为第三方软件的引入提供了可能,而第三方软件需搭载在中间件提供的功能接口上。这需要负责系统集成的车厂或者供应商具备非常强的软件系统架构能力和中间件平台设计能力。

   从软件本身的开发模式来讲,软件的分层和模块化是在每一个行业被软件重塑时的必然事件。以手机领域安卓和 ios 平台为例,各平台生态下都有非常丰富的开发工具和基础软件的模块,安卓生态下常见的 SDK(Software Development Kit)类别众多,绝大多数模块都是由第三方提供的独立模块。手机领域模块化的行业分工给标准模块供应商带来了较大的市场机会,代表上市公司有 Twilio、 salesforce 等。Twilio 作为一家云通信公司,提供的应用程序编程接口可以帮助开发者轻易地在其他应用程序中加入短信、语音和网络电话等功能。根据 CPaaS(企业通信平台及服务)的整体服务框架,CPaaS 可分为 5 个层级。Twilio 能够提供其中的部分内容服务,包括许多用户关注的 SMS、Voice、Phone Number 等基础型模块,是目前客户普遍要求的通用 API,构成了当前 CPaaS 90%以上的收入。 公司网页交流、RCS、邮件、视频等需求在 2020 年实现了爆发式的增长,越来越多的企业和用户接受电子邮件和全渠道通信,而未来在 IOT、AI、远程医疗、支付、 生物识别安全等模块的需求上将持续高速增长。公司的业务收入随着支持的第三方应用程序的增长而增长。

   自成立以来,公司营收持续保持高速增长,2021 年收入体量已经超过 180 亿元,市值一度高达 800 亿美金。

   在“软件定义汽车”的趋势下,汽车软件行业也必将迎来分层化与模块化,将诞生一批专业化中间模块供应企业。车企很难完成全链条软件模块的研发,而标准的第三方模块会经过更多不同的场景和不同的产品测试,具有更高的质量和生命力,还能分摊、降低各模块成本。例如,在座舱领域,镁佳科技就抓住了行业分工发展趋势,为理想汽车提供数字座舱方案,并开放干净的接口,让广汽蔚来、理想汽车去控制整个用户体验和产品定义。在智能汽车软件功能系统中的核心功能模块也涉及多方合作,包括自动驾驶通用框架模块、网联模块、云控模块、AI 与视觉模块、传感器模块等。利用这些共性功能模块,开发者可更高效地进行自动驾驶业务层面的研发。供应商可凭借自身优势为车企提供解决方案,实现更为高效的分工和合作。

相关新闻

加载更多...

排行榜 日排行 | 周排行