SDV，为什么是现在
如果要在当今汽车行业挑出一个最热门的关键词，毫无疑问是SDV（Software-Defined Vehicle，软件定义汽车）。几年前还只是会议幻灯片上的术语，现在已成为OEM管理层会议、Tier1供应商路线图、半导体公司产品战略中不可或缺的核心议题。
但退一步看，SDV究竟意味着什么，每个人的理解并不相同。有人指的是OTA更新，有人指的是集中式架构，还有人指的是软件变现模式。本文将从汽车软件工程师的视角，梳理SDV实际在改变什么，以及它对日常工作的影响。
车辆软件的现状 — 用数字看复杂度
首先需要正视现实。如今一辆高端车辆搭载的软件代码超过1亿行。ECU超过150个，半导体芯片超过3,000个。即使与智能手机和飞机相比，在软件复杂度方面汽车已处于最高水平。
问题在于应对这种复杂度的方式。过去10年，汽车软件复杂度增长了4倍，但开发生产力仅提升了1到1.5倍。全球OEM在2024年投入软件的资金约为400亿欧元，相比2021年的260亿欧元，短短3年增长了50%以上。投入在增加，但生产力没有跟上。
传统方式——为每个功能分配专用ECU，供应商以硬件和软件一体化的形式交付——已无法再应对这种复杂度，这是行业的共识。这正是SDV兴起的根本原因。
SDV的核心：硬件与软件的分离
SDV的核心概念其实很简单：将软件从硬件中解耦（decouple）。
到目前为止，汽车软件一直与特定ECU硬件强耦合。将A公司车身控制模块上运行的软件移植到B公司的硬件上，实际上需要相当于重新开发的工作量。这是PC产业几十年前就已解决的问题——操作系统抽象了硬件，应用程序在OS之上运行。
SDV就是要把同样的结构引入汽车。标准化的中间件层抽象硬件，车辆功能在其上以软件形式实现。硬件更换后软件可以复用，车辆出厂后也能通过OTA添加新功能或改进现有功能。
这不仅仅是技术层面的事。商业模式本身也在改变。车辆销售不再是收入的终点，通过软件订阅和功能更新实现持续收入成为可能。
架构的演进：从分布式到集中式
实现SDV需要车辆E/E（电气/电子）架构的根本性变革。让我们分阶段看看行业正在进行的架构演进。
第1阶段：分布式ECU架构
传统结构。按功能配置专用ECU。发动机ECU、变速箱ECU、安全气囊ECU、车门ECU……150个以上的ECU通过CAN、LIN等车载网络连接。硬件和软件1:1绑定，灵活性极其有限。
第2阶段：域控架构
将功能相似的ECU整合到域控制器中。按动力总成域、车身域、ADAS域等分组，减少ECU数量，域内可以共享软件。目前大多数新车处于这一阶段或正在转型中。
第3阶段：区域（Zone）+ 集中式HPC架构
SDV的最终目标。按物理位置配置区域控制器，在车辆中央放置高性能计算（HPC）单元运行核心软件。软件由HPC集中管理，区域控制器仅充当I/O枢纽。在这种架构下才能真正实现硬件-软件分离，同时满足ISO 26262功能安全要求和ISO 21434网络安全标准，实现灵活的软件架构。
全球OEM的SDV战略
这不是口号，实际上数万亿的资金正在流动。让我们看看主要OEM的SDV战略。
欧洲OEM：大规模投资与自研OS
欧洲高端OEM正在投入数十亿欧元开发自研车辆操作系统，目标是构建从芯片到云端的垂直整合软件栈，与半导体合作伙伴协作打造从自动驾驶到信息娱乐的统一平台。大型OEM集团设立软件专业子公司或与EV初创企业合资开发区域式SDV架构。下一代EV平台搭载集中式计算单元，实现出厂后持续功能更新。多品牌全球OEM投资数十亿欧元构建跨10个以上品牌通用的SDV架构，在软件层面抽象车型间的硬件差异，最大化开发效率。
中国OEM：快速开发周期追赶
中国代表性EV厂商在2024年发布了自研SDV架构，加速SDV转型。结合中国市场特有的快速开发周期，相比欧洲OEM在更短时间内将SDV功能应用到量产车的案例越来越多。
支撑SDV的技术栈
让我们看看在SDV架构中发挥核心作用的技术层。
Adaptive AUTOSAR — SDV中间件标准
在基于HPC的集中式架构中分离软件和硬件，需要位于两者之间的中间件。Adaptive AUTOSAR正是这一中间件的行业标准。理解AUTOSAR Classic与Adaptive的区别，就能更清楚地认识为什么Adaptive是SDV的核心。基于POSIX OS运行，提供面向服务的通信（SOME/IP、DDS等）、动态部署、OTA更新支持等SDV所需的核心功能。
Adaptive AUTOSAR的重要性已被行业参与度证明。AUTOSAR Adaptive Platform会员数在过去一年增长了22%，Eclipse SDV工作组也有50多家企业参与开发开放SDV标准。
面向服务的架构（SOA）
从传统的信号式通信到服务式通信的转变是SDV的核心。当每个软件组件以提供和消费服务的结构运行时，功能的添加和修改就可以独立进行。这是将微服务架构在云端验证的灵活性应用到车辆上。
车辆-云端联动
在SDV中，车辆不再是独立系统。它与云端持续连接，收集数据、进行远程诊断、通过OTA更新。车辆的数字孪生存在于云端，开发和验证也正逐步迁移到虚拟环境。
SDV对实务工程师意味着什么
宏观的话题到此为止，让我们看看SDV转型在实务层面意味着什么变化。
开发能力的变化
仅凭Classic AUTOSAR的ECU开发经验已经不够了。需要理解Adaptive AUTOSAR、Linux/POSIX环境、基于容器的虚拟化、CI/CD流水线、面向服务设计等新技术栈。嵌入式开发者需要了解云原生开发方法论的时代已经到来。
开发流程的变化
正在从V-Model的瀑布式开发转向Agile/DevOps的迭代式开发。在这一流程转变中，ASPICE流程指南提出的质量标准仍然很重要。当软件从硬件中分离后，即使没有实车也能在虚拟环境中进行开发和验证。所谓"Shift-Left"——将验证提前到开发早期阶段，成为核心策略。
工具和基础设施的变化
除传统嵌入式开发工具外，云端开发环境、虚拟ECU、数字孪生仿真平台等正成为必需品。开发环境本身正在发生根本性变化。
SDV时代的开发生产力 — 工具是答案
如前所述，软件复杂度增长了4倍，但生产力未能跟上。要缩小这一差距，需要开发工具的创新。
PopcornSAR提供缩小这一差距的SDV开发工具。
PARA是Adaptive AUTOSAR中间件，在SDV的HPC ECU中发挥核心作用。分离硬件与软件的中间件层——这是SDV架构的基础技术。完全支持面向服务的通信、动态部署、OTA更新等SDV所需的标准功能。
PARVIS是SDV时代的AI驱动开发自动化解决方案。从需求分析、测试自动生成到MISRA C/C++合规自动化，以AI支持V-Model全流程。相比传统手动方式，将开发时间缩短70～80%，实质性地应对SDV复杂度的增长。
SDV转型已经开始。全球OEM投入数万亿资金、重新设计架构、扩大软件组织，原因很明确——汽车的价值正在从硬件转向软件。要在这一转型中具备竞争力，高效的开发工具和经过验证的中间件是必不可少的。
如需更深入地讨论SDV开发，请通过联系页面随时联系我们。