汽车软件平台演进：从AUTOSAR到Hypervisor，如何重塑开发与商业模式

1. 汽车软件平台现状：从“硬骨头”到“乐高积木”的演进

干了十几年汽车电子，我亲眼看着车里的代码从几万行膨胀到上亿行。十年前，我们还在为某个ECU（电子控制单元）里塞进一个简单的网络协议栈而通宵调试；现在，一辆高端智能汽车的软件复杂度已经堪比一架现代客机。行业里有个老笑话：以前卖车是“卖钢铁”，后来是“卖沙发加轮子”，现在彻底变成了“卖四个轮子上的智能手机”。玩笑归玩笑，但背后的逻辑很清晰：软件正在重新定义汽车的价值和开发模式。对于所有从业者——无论是主机厂、Tier 1供应商，还是我们这些一线的工程师和架构师——理解当前汽车软件平台的格局，已经不是“要不要学”的问题，而是“怎么活下去”的关键。

为什么软件平台突然变得如此重要？核心就一句话：降本、增效、加速迭代。传统的“一个功能对应一个ECU”的烟囱式开发，在功能爆炸的时代已经彻底行不通了。想象一下，你要为几十个、上百个分散的ECU分别开发、测试、维护和升级软件，其成本、时间和不可靠性将是灾难性的。软件平台化的思路，就是把那些通用的、基础的、重复的“轮子”标准化、模块化，形成一套可复用的“乐高积木”。上层应用开发者只需要关心业务逻辑，像搭积木一样组合这些模块，就能快速构建出功能。这不仅能大幅缩短开发周期，更能通过平台的持续优化和漏洞修复，提升整个软件体系的可靠性和安全性。

当前，汽车软件平台已经渗透到从底层芯片到顶层应用的各个层面，形成了一个多层级的生态系统。对于想进入或深耕汽车软件领域的朋友来说，摸清这几个关键平台的现状、玩家和趋势，是设计架构、选型技术栈、规划产品路线图的基础功课。这篇文章，我就结合一线的实战和观察，带你拆解一下几个核心的汽车软件平台领域，聊聊其中的门道和坑。

2. 软件平台的核心价值与汽车行业的特殊挑战

在深入各个具体平台之前，我们必须先统一思想：到底什么是软件平台？它在汽车这个特殊行业里，解决了什么痛点，又带来了什么新问题？

2.1 平台思维：从“造轮子”到“用轮子”的范式转移

一个技术平台，本质上是一套经过验证的、可复用的技术资产和规范集合。它的目标不是一次性完成某个特定产品，而是为了能高效地、低成本地衍生出一系列相似或未来的产品。在汽车行业，我们最熟悉的硬件平台例子是“底盘平台”。大众的MQB、MEB，丰田的TNGA，都是典型的底盘平台。基于同一个底盘，可以开发出轿车、SUV、MPV等不同形态、不同动力总成的多款车型，极大地分摊了研发和制造成本。

软件平台是完全相同的逻辑。它把操作系统内核、中间件、通信协议、驱动框架、安全模块等基础软件组件标准化、接口化。开发一个新的车载功能，比如智能座舱里的多屏互动，工程师不再需要从零开始写底层图形渲染、进程间通信、电源管理的代码，而是直接调用平台提供的稳定API，专注于实现“如何让中控屏的地图流畅地滑动到副驾屏”这个业务逻辑。

这种模式带来的核心优势是压倒性的：

1. 成本与时间优势：复用率越高，单次开发的边际成本越低，上市时间（Time-to-Market）越快。这是应对汽车行业“软件定义”时代快速迭代需求的不二法门。
2. 质量与可靠性：平台代码经过多车型、多批量的长期测试和验证，其稳定性和成熟度远高于从零开发的新代码。每一次平台版本升级，都是在修复已知缺陷的基础上进行有限的功能扩展，引入新Bug的风险可控。这完美契合了汽车行业对功能安全（ISO 26262）和可靠性的严苛要求。
3. 生态与人才：一个成功的平台会吸引大量的第三方开发者、工具供应商和服务商，形成繁荣的生态系统。同时，围绕主流平台（如AUTOSAR、Android Automotive OS）会积累大量熟悉其架构的开发人才，降低了企业的招聘和培训成本。

2.2 布鲁克斯法则在汽车软件中的现实映照

文章里提到了软件工程领域的经典《人月神话》和布鲁克斯法则（Brooks‘s Law）：“向进度落后的软件项目增加人手，只会让进度更加落后。” 这一点在汽车软件开发中，被放大得尤为明显。

汽车软件项目通常是超大规模的（数千万甚至上亿行代码）、强实时、高安全要求、且与硬件深度耦合。当项目初期因为需求不清、架构设计有缺陷或技术选型失误而延误时，管理层本能的想法是“加人”。但新加入的工程师需要时间熟悉复杂的整车网络架构、特定的工具链、严苛的开发流程（如ASPICE）和已有的“祖传代码”。他们的沟通成本呈指数级增长，反而可能干扰原有核心团队的节奏，导致更多的集成问题和返工。

因此，汽车行业应对布鲁克斯法则的答案，恰恰就是“平台化”。通过采用成熟的软件平台，项目在启动时就拥有了一个稳定、可靠、文档相对齐全的基础。团队可以将宝贵的人力资源集中在创造差异化的应用功能上，而不是耗费在调试底层驱动的兼容性上。平台相当于一个“经验丰富的默认团队”，默默承担了最复杂、最容易出错的基础工作。

2.3 汽车软件平台的独特挑战与权衡

当然，平台化并非没有代价，在汽车领域尤其需要权衡：

1. 性能与资源开销：平台为了通用性，通常会引入抽象层，这可能导致代码体积增大、运行效率降低、内存占用更多。对于资源受限的微控制器（MCU）类ECU（如车门模块、传感器控制器），这可能是个问题。因此，汽车软件平台也分“Classic AUTOSAR”（针对资源受限的MCU，强调效率和确定性）和“Adaptive AUTOSAR”（针对高性能的MPU/SoC，强调灵活性和服务化）。
2. 供应链与自主权：采用第三方平台（如QNX、Android）意味着将一部分“灵魂”交给了供应商。你受制于该平台的更新节奏、许可费用和技术支持。同时，如何与平台供应商的竞争对手（可能也是你的合作伙伴）共享技术细节，需要复杂的法律和合同管理。
3. 集成与测试复杂度：虽然平台本身是稳定的，但将多个不同的平台（如仪表用QNX、娱乐用Android、智驾用ROS 2）集成到同一辆车里，并确保它们之间安全、可靠、实时地通信，其集成测试的复杂度和工作量是惊人的。这催生了“Hypervisor”（虚拟机监控器）技术的广泛应用。
4. 长期维护与技术债务：一个平台一旦被车型选用，就需要在整个车辆生命周期（可能长达10-15年）内提供支持，包括安全补丁和兼容性更新。如何管理多个车型、多个平台版本的技术债务，对企业的软件资产管理能力提出了极高要求。

理解了这些底层逻辑，我们再看各个具体的软件平台领域，就能更清楚地看到它们的选择为何如此，以及未来的演进方向。

3. 基石之战：车载操作系统与虚拟机监控器

如果把整车软件比作一座大厦，操作系统就是承重墙和地基。它的选择决定了上层应用的开发方式、性能上限和安全底线。

3.1 AUTOSAR：传统汽车电子的“宪法”

在谈论Linux、QNX之前，必须首先理解AUTOSAR。它不是一个具体的操作系统产品，而是一套由全球主要汽车制造商、供应商和工具商共同制定的开放式软件架构标准。你可以把它看作是汽车基础软件的“宪法”，定义了ECU软件应如何分层、模块之间如何通信（通过标准接口）、以及如何与硬件交互。

为什么AUTOSAR不可或缺？因为它解决了传统分布式ECU网络的标准化问题。在AUTOSAR出现之前，每个供应商的ECU软件都是“黑盒”，接口千奇百怪，集成时需要对暗号一样痛苦。AUTOSAR通过标准化的应用接口和运行时环境，实现了“软硬件解耦”。应用软件开发者不需要关心底层用的是英飞凌的Aurix还是恩智浦的S32系列芯片，只需要按照AUTOSAR标准来写软件，就能在不同硬件上运行。这极大地提升了软件的可复用性和供应链的灵活性。

实战心得：Classic vs. Adaptive

• Classic AUTOSAR：基于OSEK/VDX标准，采用静态配置、事件驱动的运行模式。它非常高效、确定性强，专为对实时性和功能安全要求极高的控制类ECU设计，如发动机控制器、刹车控制器。它的开发流程偏“V模型”，配置工作极其繁琐，需要依赖Vector、ETAS等公司的昂贵工具链。
• Adaptive AUTOSAR：面向高性能计算平台（如座舱域控制器、自动驾驶域控制器）。它采用了更接近通用计算的概念，如基于POSIX的操作系统接口、面向服务的通信架构。这使得它能支持更复杂的应用、动态部署和OTA升级。Adaptive AUTOSAR的出现，是为了填补传统实时OS与高功能富OS（如Linux）之间的鸿沟，在保证一定实时性和安全性的前提下，提供更大的灵活性。

选型建议：对于纯粹的车辆控制（车身、底盘、动力），Classic AUTOSAR仍是主流和必选项。对于需要复杂计算、AI处理、生态应用的域控制器，Adaptive AUTOSAR是连接底层可靠控制与上层丰富生态的关键中间层。

3.2 富功能操作系统：QNX、Linux与Android的“三国杀”

对于信息娱乐系统、数字仪表盘、ADAS域控制器这些需要强大算力、丰富图形界面和复杂生态的系统，AUTOSAR就显得力不从心了。这时，来自消费电子和IT领域的操作系统便登堂入室。

1. QNX：安全与可靠的“贵族”QNX是微内核实时操作系统，以其极高的可靠性、安全性和实时性著称。它是最早通过ISO 26262 ASIL D等级认证的车载OS之一。在关乎行车安全的领域，如数字仪表（因为仪表显示车速、报警灯等信息，失效可能导致驾驶员误判），QNX曾是几乎唯一的选择。它的商业模式是闭源，收取版权费。优势是“稳”，缺点是生态相对封闭，开发工具和社区活跃度不如Linux。

2. Linux（特别是AGL）：开源与灵活的“革新者”以Automotive Grade Linux为代表的开源Linux发行版，正在快速占领市场。AGL由Linux基金会牵头，得到了丰田、本田等众多主机厂的支持。它的核心优势在于：

   • 零许可成本：对于动辄百万辆级别的车型，这能省下巨额费用。
   • 极强的定制性：厂商可以深度定制系统，打造独特的用户体验。
   • 丰富的开源生态：可以引入无数成熟的开源软件包。 但Linux的挑战在于，其内核并非为实时和安全关键场景设计。虽然可以通过打补丁提升实时性，但要达到ASIL级别的功能安全认证，过程非常漫长和昂贵。因此，Linux目前主要应用于对安全要求相对较低的娱乐信息系统。

3. Android Automotive OS：生态与体验的“降维打击者”这是谷歌专门为汽车推出的全栈式、开源操作系统平台。注意，它不同于需要通过手机投射的Android Auto，而是直接运行在车机硬件上的完整OS。它的杀手锏是完整的移动应用生态和谷歌服务。对于主机厂而言，采用Android Automotive OS可以瞬间获得数百万个经过验证的移动应用（当然需要适配车规级交互），以及谷歌地图、语音助手、应用商店等一整套服务。这极大地缩短了智能座舱应用的开发周期。 然而，代价是对数据和生态控制权的部分让渡。你的车机体验将深度绑定谷歌。沃尔沃、极星、通用等品牌已全面拥抱。国内情况特殊，由于谷歌服务不可用，衍生出了基于AOSP（Android开源项目）深度定制的各种版本，如比亚迪的DiLink、吉利的GKUI等，它们在应用生态上主要依靠国内的应用商店。

选型背后的商业考量： 选择哪个OS，远不止是技术问题。它关乎：

• 品牌定位：追求极致安全和可靠（如豪华品牌），可能倾向QNX；追求科技感和生态，可能选择Android。
• 研发能力：有强大软件团队，希望深度定制、掌握核心，AGL是优选；希望快速上市、借助生态，Android更省力。
• 成本结构：前期投入和长期许可费的权衡。
• 区域市场：在中国市场，基于AOSP的定制版是绝对主流。

3.3 Hypervisor：一机多系统的“魔法师”

随着域控制器和中央计算单元的发展，一个高性能硬件上需要同时运行多个不同特性、不同安全等级的操作系统。例如，在同一块芯片上，既要运行富功能的Linux来支持大屏娱乐，又要运行高安全的QNX来驱动数字仪表。如何让它们互不干扰、安全共存？答案就是Hypervisor。

Hypervisor，或称虚拟机监控器，是一种运行在基础物理硬件和操作系统之间的软件层。它创建并管理多个虚拟机，每个虚拟机可以独立运行一个完整的操作系统及其应用。Hypervisor负责硬件的抽象和资源的严格隔离与分配（如CPU核心、内存、外设）。

汽车中Hypervisor的典型应用场景：

1. 座舱域控制器融合：这是目前最主流的应用。将原本独立的仪表和中控娱乐系统，合并到一个硬件平台上。仪表运行在通过ASIL认证的QNX或Integrity等RTOS虚拟机中，确保安全；娱乐系统运行在Linux或Android虚拟机中，提供丰富功能。两者在物理上隔离，即使娱乐系统卡死或崩溃，也绝不会影响仪表显示。
2. 功能安全与非安全功能的整合：例如，基于摄像头的驾驶员监控系统需要较高的功能安全等级，可以与信息娱乐系统整合在同一芯片的不同虚拟机中。
3. 降低成本与布线：用更少、更强大的计算单元替代大量分散的ECU，通过Hypervisor实现功能隔离，能显著降低硬件成本和车内线束复杂度。

主流玩家与选型要点： 市场上的主流汽车Hypervisor包括黑莓的QNX Hypervisor、英特尔的ACRN、开源的车载虚拟化方案如Xen等。选型时需重点考察：

• 安全认证：是否支持ISO 26262认证，能达到哪个ASIL等级。
• 实时性能：对仪表、ADAS等实时性要求高的虚拟机，其调度延迟和确定性是否满足要求。
• 资源开销：Hypervisor本身占用的CPU和内存资源。
• 生态支持：是否支持你选定的Guest OS（如QNX、Linux、Android）以及底层芯片平台。

注意：引入Hypervisor虽然解决了集成问题，但也增加了系统的复杂性、调试难度和成本。它是一剂“猛药”，需要用在对集成度和成本有极致要求的场景。对于功能相对独立的系统，用独立的硬件可能仍是更简单、更可靠的选择。

4. 上层应用平台：生态整合与用户体验的关键

操作系统提供了舞台，而上层应用平台则决定了舞台上能上演什么样的节目，以及观众的体验如何。这部分是用户能直接感知到的“智能”所在。

4.1 智能手机互联：CarPlay与Android Auto的“事实标准”

几乎成为新车标配的CarPlay和Android Auto，是软件平台“生态力量”的完美例证。主机厂曾尝试开发自己的手机互联方案，但最终几乎全部转向了拥抱苹果和谷歌的这两大平台。

它们成功的原因非常直白：

1. 无缝的用户体验：用户早已习惯了iPhone或Android手机的操作逻辑。将这种体验无缝延伸到车机上，学习成本为零。用户上车，数据线一连或无线一配对，熟悉的界面、通讯录、音乐播放列表、导航历史就出现在车机大屏上。
2. 强大的应用生态：开发者只需要为CarPlay或Android Auto做一次适配，其应用就能覆盖所有支持该平台的车型，潜在用户量巨大。这吸引了大量导航、音乐、播客、通讯类应用开发者积极适配，形成了良性循环。
3. 降低驾驶分心：针对驾驶场景优化的界面和语音控制，比让驾驶员直接操作手机更安全。

对主机厂的启示与挑战：

• 启示：在用户体验和生态建设上，与消费电子巨头正面竞争极其困难。与其投入巨资打造一个可能没人用的封闭生态，不如接入成熟平台，快速满足用户基本需求。
• 挑战：这也意味着主机厂在“智能座舱”入口的体验上部分“失权”。你的车机界面、交互逻辑、甚至部分数据，都被苹果或谷歌定义。为了平衡，许多主机厂采取了“双轨制”：既支持CarPlay/Android Auto，也保留一套自研的底层系统，用于控制车辆核心设置或提供独家服务。

国内市场的特殊性： 由于谷歌服务缺位，Android Auto在国内无法使用。这给了百度CarLife、华为HiCar等本土方案发展空间。它们的工作原理类似，但生态基于国内互联网服务。同时，国内主机厂自研系统的意愿和能力更强，形成了百花齐放的格局。

4.2 虚拟个人助理：车内交互的“新入口”

语音交互正在成为继触摸屏之后最重要的人车交互方式。一个好的车载语音助手，不仅能执行“打开空调”、“导航去公司”这样的基础指令，更能实现多轮对话、上下文理解、跨应用操作（如“帮我找一家评分高的餐厅，并把地址发给副驾的手机”）。

市场格局： 与手机互联类似，车载语音助手市场也呈现出被消费级AI巨头主导的趋势：

• 亚马逊Alexa：凭借其在智能家居领域的领先地位和开放的合作伙伴计划，在车载前装市场进展迅速。许多品牌选择集成Alexa，让用户可以在车里控制家里的智能设备。
• 谷歌助手：与Android Automotive OS深度绑定，提供强大的搜索能力和谷歌服务生态。
• 苹果Siri：主要通过CarPlay与车辆交互，体验与iPhone高度一致。
• 本土巨头：在中国，百度小度、阿里天猫精灵、腾讯小微以及各主机厂自研的语音助手竞争激烈，通常深度整合了本土的生活服务（如外卖、电影票、停车场支付）。

技术集成模式：

1. 嵌入式：将VPA的语音识别、自然语言理解引擎直接集成到车机系统中。优势是响应快、不依赖网络；劣势是功能受限于车机本地算力和数据。
2. 云端协同：车机端只负责唤醒和音频采集，核心的识别、理解和知识查询在云端完成。优势是功能强大、可持续更新；劣势是对网络有依赖，在地库、隧道等场景体验差。
3. 混合模式：常用指令（如空调控制、本地音乐播放）在本地处理，复杂查询（如餐厅推荐、信息搜索）走云端。这是目前的主流方向，对系统架构设计提出了更高要求。

实操心得：语音助手落地的坑

• 唤醒率与误唤醒：在高速行驶的风噪、路噪环境下，如何保证高唤醒率，同时避免因广播、乘客聊天导致的误唤醒，是麦克风阵列设计、算法优化的核心挑战。
• 离线能力：必须设计完善的离线指令集和降级方案，确保在网络不佳时核心功能可用。
• 生态整合：语音助手需要深度打通车控（空调、车窗）、娱乐（音乐、电台）、导航、生活服务等多个域的能力，这涉及到复杂的系统权限和API设计，需要强有力的顶层架构支持。

4.3 信息娱乐与导航：从功能机到智能终端的蜕变

现代的信息娱乐系统早已超越了“收音机+CD播放器”的范畴，成为一个集成了导航、在线媒体、车辆设置、生活服务于一体的综合信息终端。其软件平台也异常复杂。

导航平台： 车载导航经历了从离线到在线、从静态到动态的演进。Here、TomTom、高德、百度等图商提供的不再仅仅是地图数据，而是一整套包括实时路况、在线搜索、兴趣点、甚至高精地图在内的导航服务SDK。主机厂或Tier 1需要将这些SDK与自己的HMI设计、语音助手、车辆传感器（如GPS、航位推算）进行深度集成。

在线媒体与生态： 通过车载4G/5G网络或手机热点，在线音乐（如Spotify、QQ音乐）、在线电台、播客、有声书等应用已成为标配。集成这些服务，涉及到用户账号体系打通、流量管理、内容版权、播放控制与车辆音响系统的协同等一系列问题。通常，主机厂会选择与少数几家主流服务商进行系统级深度合作。

HMI与图形框架： 为了打造炫酷、流畅且品牌独有的用户界面，车载系统的图形渲染框架至关重要。Qt、Kanzi等专业的HMI开发工具被广泛使用。它们允许设计师和工程师高效地创建复杂的动画和交互，并需要与底层的操作系统图形子系统（如Linux的Wayland）以及GPU驱动进行高效协同。这里的一个关键挑战是保证图形渲染的实时性和稳定性，避免出现卡顿、撕裂，尤其是在低功耗或系统高负载时。

跨域融合的挑战： 最前沿的趋势是“座舱域融合”，即将仪表、中控、副驾屏、HUD甚至后排娱乐屏由一个或多个高性能域控制器统一驱动。这要求软件平台能支持：

• 多屏异显与互动：不同屏幕显示不同内容，并支持内容在不同屏幕间流畅拖拽。
• 差异化安全等级：仪表内容要求最高安全等级和刷新率，娱乐屏则可适当放宽。
• 硬件虚拟化：GPU、显示输出等硬件资源需要在多个虚拟机或安全域之间安全、高效地共享。

这背后，需要强大的图形虚拟化、显示合成、以及跨进程/跨虚拟机通信机制的支持，是当前座舱软件平台研发的最前沿课题。

5. 未来已来：软件平台如何重塑汽车开发与商业模式

汽车软件平台的成熟，不仅仅改变了技术架构，更在深刻重塑整个汽车行业的开发流程、组织形态和商业模式。

5.1 开发流程：从“V模型”到“敏捷-瀑布”混合模式

传统的汽车电子开发遵循严格的“V模型”，需求冻结早，变更成本极高，周期长达数年。这与软件快速迭代的特性格格不入。新的模式是**“硬件平台化，软件分层化，开发敏捷化”**。

• 硬件预埋与平台化：基于少数几个高性能、可扩展的硬件平台（如中央计算单元、区域控制器）进行开发，硬件能力适度超前，为后续软件升级留出空间。
• 软件分层解耦：
  • 底层基础软件（操作系统、Hypervisor、AUTOSAR）：采用“瀑布模型”，追求极高的安全性和稳定性，变更需要严格的验证和流程。
  • 中间件与框架层：部分采用敏捷开发，提供稳定的服务接口。
  • 上层应用与算法：全面推行敏捷开发，甚至DevOps，实现功能的快速迭代和OTA升级。
• 持续集成/持续部署：建立强大的车载软件CI/CD流水线，实现代码的自动编译、集成、测试（包括HIL硬件在环测试）和部署，大幅缩短验证周期。

5.2 组织变革：从“部门墙”到“特性团队”

传统的汽车企业组织架构按功能划分：电子电气部、车身部、动力总成部、软件部等。软件需求需要跨多个部门传递，效率低下。为了适应软件定义汽车，领先的企业正在向“特性驱动”的跨职能团队转型。

例如，为了开发“智能灯光”这个特性，需要组建一个包含软件工程师（控制逻辑）、硬件工程师（灯组、传感器）、算法工程师（图像识别）、测试工程师、用户体验设计师的完整团队。这个团队对“智能灯光”特性的全生命周期负责，从需求到交付。这种模式打破了部门墙，提升了沟通效率和交付质量。

5.3 商业模式：从“一次售卖”到“持续服务”

这是最根本的变革。传统汽车的价值在卖出那一刻就基本确定了。而软件定义汽车使得价值可以通过软件持续创造。

1. 功能订阅：特斯拉开创的先河，如高级自动驾驶包、座椅加热订阅、性能加速包等。用户为软件功能持续付费。
2. 服务分成：主机厂作为平台方，与应用服务商（如音乐、视频、保险）合作，从服务收入中分成。
3. 数据增值：在充分保护用户隐私和合规的前提下，脱敏后的车辆运行数据、驾驶行为数据可以用于改进产品、开发新功能，或为第三方（如保险公司、城市规划部门）提供数据服务。

这一切商业模式创新的技术基石，正是强大的、可远程管理的软件平台。它需要支持安全的OTA升级、精细化的功能配置管理、以及可靠的服务开通与计费系统。

5.4 给从业者的建议与思考

面对这场席卷而来的浪潮，无论是个人开发者还是企业，都需要重新定位。

对于工程师个人：

• 深化垂直领域：在AUTOSAR、车载Linux/Android内核、Hypervisor、汽车网络安全等基础软件领域，深度专家依然极度稀缺。
• 拥抱全栈能力：理解从底层硬件、操作系统到上层应用、云端的全链路技术栈，成为“T型人才”，在汽车软件时代更具竞争力。
• 关注标准与开源：积极参与AUTOSAR、SOAFEE、ROS 2等汽车相关标准组织和开源项目，这是跟上技术前沿、构建行业影响力的最佳途径。

对于企业（尤其是供应商和初创公司）：

• 找准生态位：不要试图在所有层面与大厂竞争。可以专注于某一层（如特定的中间件、工具链、安全模块）或某一垂直应用（如智能表面控制、特定场景的AI算法），做到极致。
• 开放与集成：你的产品必须是“平台友好型”的，提供清晰、标准的API，易于被集成到主机厂或Tier 1的软件平台中。
• 重视功能安全与网络安全：这是进入汽车供应链的敲门砖和护城河。尽早建立符合ISO 26262和ISO/SAE 21434的开发流程和能力体系。

汽车软件的黄金时代刚刚开始。平台化是应对其复杂性的必然选择，它降低了入门门槛，但也抬高了竞争维度。未来的竞争，将是生态与生态、平台与平台的竞争。能否在这场竞争中立足，取决于你是否真正理解了这些平台的游戏规则，并构建起自己独特的价值。