软件定义汽车，架构定义软件

Posted 2023-05-12

参考技术A

编者按：本文转载自微信公众号： 汽车 电子与软件。 汽车 之心经授权转载。

8月26日，江铃 汽车 CTO兼总裁助理黄少堂受邀出席 “SAE 2020 汽车 电子与软件技术论坛”，发表《软件定义汽车，架构定义软件》的主旨演讲。系统地阐述了软件定义 汽车 的背景、机会和挑战，并分析了顶层设计和实际执行中的痛点。

汽车 圈内人士更习惯称他黄堂主，笔者听过很多CTO的演讲，很少有黄堂主这样，纯干货、零带货的。听众评价他的演讲，不仅有掌声，还有笑声，掌声代表礼貌和敬意，笑声才是内心的共鸣。

*本文是根据现场演讲整理而写，尚不能领悟黄堂主精髓是万一，仅供交流、参考。

01

为什么强调软件定义 汽车 ？

今天所处的 汽车 时代，我们前人从来没有这么幸运过，也从来没有这么焦虑过，更没有体验过。每一天都不一样，即使我这样有几十年 汽车 电子经验的老行家，面对今天这样从未经历过的世界，又能好到哪去了？

最近，我们一直在思考，为什么业内突然兴起软件定义 汽车 ，而且如此红火。事实上，过去几年，如发动机的点火、喷油、排放，已经是软件控制了，底盘的AEB，还有自动刹车控制，包括自动转向。其实从底盘、传动、动力、车身，软件已经渗透到了几乎所有的 汽车 系统。但过去从没有像今天这样强调软件定义 汽车 。

为什么今天突然间强调软件？最近我拿了一台华为的P40，内存到达516G，相当于一台电脑。因为得益于芯片、互联网、大数据等技术的发展，在硬件的基础上，我们才得以在小的空间内做很多的事情。

另外，消费电子对 汽车 行业的冲击，人们的消费习惯和生活方式已经发生变化，促使人们的期望值不断的增加，人们不再忍受开一个豪华车，还用一个手机去导航。特别是90后、00后的消费者，他不再像我们这一代人买个宝马、奔驰，做点小生意，他们更强调个性化的展现。而当我们打开 汽车 行业的软件库时，发现我们的软件代码量已经超过了飞机，并不在其他行业之下。

02

特斯拉效应

记得2003年特斯拉成立的时候，当时我们在美国通用，对它不屑一顾，觉得它就像小孩玩玩具，闹不了几年的。时至今日，还有哪一个老牌 汽车 企业敢轻视特斯拉？人家只卖36万辆车，还不用赚钱，而大众、宝马、奔驰、通用、福特，这些传统车企加起来卖2000多万辆，但他们加起来的市值却抵不过特斯拉。说明 社会 不认可传统车企在创造价值。包括国内的新势力，别看车子只卖几万辆，甚至亏本，但与国内领头的销售几百万辆的车企，市值相差并不多。

在国外，上市企业经营的目的就是为股票的拥有者创造价值，经营者的工资是以股价来论的。你可以想象传统车企的管理者的压力，当初的通用贱卖土星、庞蒂亚克、悍马也是不得以而为之，华尔街的人坐在你办公室，你不卖，就得自己下岗。克莱斯勒当初也是因为股票不景气，迫使被菲亚特接收。

像我这样早期对特斯拉不屑一顾的，今天再来看他们，Model S的网络架构拓扑图，非常规矩，这样的拓扑图很好，拿到一个拓扑图，用一个CANoe或者Vehicle Spy工具可以立项他的原始结构。第二代适当加了一个集成，到了第三代，你再用传统的电子电气拓扑图去画，画不了，也立项不了，简直就是杂乱扔在一起的。它的能力在域控制器里面，在软件里面，你从外表去仿画他的架构，很难做到。 特斯拉重新换了一种不遵守 汽车 行业传统法则的方式，自己单跑了 。杂乱中，其实彰显了它的软件能力。

03

架构定义软件

我们注意到，最近各大车企成立软件中心，但很难招到人，IT的人做嵌入式软件是一个鸿沟，虽然都是软件，但不用的平台，不同的应用，有着相当大的差异。从架构到云管端，因为结构不同，控制方法不一样。我们通常讲结构下的软件。我们先要定义软件架构本身，再定义功能，再建立通讯网路。

首先要定义好架构，然后针对场景的设计，比如自动驾驶的场景、路面， 娱乐 系统，商用车、物流车的场景跟乘用车又不一样，场景定义就不一样。回顾 汽车 网络架构，以前只有电器架构，没有什么电子和软件。比如发动机点火就是用一个高压线圈，开关一弹，能量释放，产生火花，点火。油是共轨的，哪个阀门开了，就滴到哪个油缸里。后来才有了基于发动机的电子模块，也就有了电子电器架构。现在，随着智能网联 汽车 的发展，特别是自动驾驶以后，将演变成车、路、人协同电子架构。

在传统 汽车 人看来，Model 3 的架构简直是一个大杂烩，而传统的车企，如大众MEB的架构就比较规矩，很难说谁的更好。但用户其实并不关心你背后的设计，这就是我们需要思考的。

打通任督二脉的关键恰恰在于整体架构，而软件是架构的关键要素，软件实现是战术，架构是战略。

车云一体电子架构是我们今后要做的事情，我们以前总是在做车上测试、网络测试、模块之间的测试。既然车云已经形成了，为什么不把车网跟后端网一起进行测试呢，每个信息传到后面如何保证是正确的。我们的测试流程里并没有涵盖ISO 26262，ios 26262只是定义到车上的，如今的 汽车 哪里只是车上的呢？

所以你说特斯拉完全不遵守26262和AUTOSAR，也有一定的道理。 当他发现传统标准局限的时候，就需求创造出自己的路。

同样，车云一体的电子架构，他们各模块之间的协同，有哪个现有的标准可以参考呢？标准体系并没有完全跟上行业发展和产品的需要。我曾经当过两年ISO的编委，召集一帮人讨论两三年，究到每一个0和1, 严肃性是有的，但你可想而知，每个企业派出去的人，一般也不是最有价值、最忙的，我们不必将标准当成是圣经。我们需要尊重标准，但如果仅是知其然不知其所以然的使用，消费者并不会为这个买单。在传统的主机厂，上万人，最顶端的很难知道下面的事情。

我们的中央计算器，一定程度上要感谢芯片商的能力， 芯片能力的提升，促使电子架构向区域架构发展，从而为软件功能迭代提供硬件平台。 我们最早做ADAS，一个机械式的毫米波雷达的成本是3000美元，只有凯迪拉克上能配，今天已经下降到了两三百人民币。硬件成本的大幅度下降，才让智能 汽车 成为现实。我们今天谈智能，并不是我们的前辈很蠢，而是没有如今的整个技术环境支撑。

Model 3 的中央计算模块，采取区域控制，不是功能域控制，有人说是为了节省线束的成本。我的理解是，它把模块、智能配电、传统保险，都用电子保险控制了。而我们传统的网络架构，控制0和1，起步、唤醒、休眠。如果把电源都控制了，就不存在休眠、唤醒了，一通电都醒了，一断电都休了。既然把电分开了，就必须有前、左、右控制，如果把所有的保险都放一个盒子里，就变成烤箱了，所以有几级分电。这是基于功能的需要进行这样的定义。

传统的软件架构，有以下特点：

如果我要更新一个ABS，那关联的BCM、仪表、网关都要改，而且都分属于不同的供应商，代码也是别人写的。从这一点也应证传统车企被供应商绑架了。

新的软件架构下：

今天，在域控制器的概念下，关键的模块都是自己开发的，你要改一个节点，或者要改不同的节点，可以通过功能定义，不再以模块去刷新一个，而是以服务包的形式进行更新。而且软件还可以进行整个生命周期的收费，改变车企的运行模式。原来 汽车 卖出去以后，跟车厂就没有多大关系了。

当我们具备软件基础能力，软件模块需要做什么，车企的应用软件如何建立？

按传统思维，我们总希望通过智能驾驶一个方案做所有的，很多模块是一个公司做。按新的模式，做感知的、做定位的、做决策的、还有做执行的，用一个渐进的方式，不需要大，这样供应商就不是做一个模块，而是重复的流水线。我们所合作的企业并不一定要大，但是要精，然后不断地完善。这个时候软件就变成了一个标准化的工具。但我们需要把层级定义清楚，把接口定义清楚。

同样，智能座舱领域也是一样，我么把它分成几个模块，把底层定义清楚，主机厂有能力的多做一下，能力弱的少做一些。

软件的另一个核心是OTA，没有OTA软件的更新，软件也无法定义 汽车 。通过更新，可以不断地满足用户的体验，重新定义数据形态，根据软件更新的范围，内容，安全度，让 汽车 在生命周期内有再生命力。具体体现在：

OTA结合5G，再加上车路协同，整个生态链和供应链也将被重新定义。在这个全新的产业生态中，4S店的模式可能会发生颠覆。当你有大数据，有GPS定位，可以通过线上诊断、线下换件的形式。如果是涉及到软件更新，在家里就可以通过OTA修复BUG。

04

软件定义 汽车

我理解的软件定义 汽车 是： 软件深度参与整个 汽车 的定义、开发和验证流程，并不断优化客户体验，持续创造价值。

传统车企开发一个车往往需要三年，包括概念设计、定义方案，再冻结、下车体制做、样车制造、三高测试、标定等。如果软件定义 汽车 还在这样的流程下进行，三年前开发的软件，在三年后可能就已经被淘汰了。因此，软件定义 汽车 要颠覆整个 汽车 开发流程。这将是很多车企巨大的挑战，大公司制定流程往往是很大的梯队，而管理层中，基本都是做底盘、车身等传统部件的出身的，他们的软件的概念还比较缺乏。固化的流程让传统 汽车 人很安全、很可靠。这就制约了组织的更新和发展。

要实现软件定义 汽车 ，要没有一个革命性的，从组织架构，CEO层面变革，只可能被淘汰。

我读MBA的时候，去过芬兰的诺基亚。当时，整个芬兰为诺基亚自豪，这么小的国家，诞生如此成功的企业，它的手机以质量著称，充电可以用一个星期。苹果出来的时候，我们都笑了，不小心掉地上，屏碎了，每天还要跟祈祷一样，把电源插上去充电。其实诺基亚并没有做错事，当初MBA的范例都是它的成功。如果我现在再去读MBA的话，范例会不会是它如何失败的。时代在变，即使你没有做错事，但别人做的比你更好。

很多机械类的东西，要改一个字，开一个模，到今天仍然需要上千万成本。而软件只需要一次开发费。并且可以个性化的定制，借用其他行业的生态。 软件定义 汽车 的驱动因素 具体表现在：

用户层面：

OEM层面：

舒适的驾乘环境，改变未来出行方式

软件定义 汽车 赋能整个生命周期内，可以学习用户、车辆自身、周围环境并适时作出适应性调整。

05

软件定义 汽车 的要素

传统开发模型：

面向软件 汽车 的开发模型：

有人问，可不可以一步到位？虽然我们想这样，但一方面是自己没有这个能力，另一方面是供应商不是这么排的，而且这个过程是要跟供应商及整个供应链讨论的。你有多大的市场？怎么玩？谁有权力去定义这个规则？有权力定义规则的人生活已经很舒服了，为什么要颠覆自己呢？对于大多数传统车企，比较现实的策略是渐进式变革。

电气架构、远程升级、网络安全、大数据是软件定义 汽车 的基石。

智能互联和智能驾驶推动了 汽车 行业的升级。需要全新的网络架构，寻找新的合作伙伴，更广泛的生态系统和平台。比如芯片厂商、运营商、BAT等互联网公司，过去这些与 汽车 没有联系的企业都渗透到了 汽车 行业。再往后，公路局、收费站，国家检测局都将加入 汽车 生态圈。

06

软件定义 汽车 带来的挑战

随着软件越来越多，越来越复杂，软件之间的交互、测试，需要行业的共同努力，如果每个车厂都搞个自己的操作系统，都认为自己是最牛的，打开一看，其实都是抄了别人的，就改了两个字，把一个完美的东西改成了不完美的东西。

软件开发模式仍然 苦难重重 ：

短期阵痛：

软件定义 汽车 中长期挑战：

07

结语

我们今年所经历的时代是 汽车 行业前所未有的，在软件定义 汽车 层面，中国与世界同步甚至走在前列，没有对标与参考，在焦虑的同时，也是幸运的。需要行业同仁齐心协力、共同努力，我们要共享、讨论、坦诚布公，才可能取得共同的、共有的进步！

最后借用一句七绝：

百舸争流千帆竞

借海扬帆奋者先

软件定义汽车产业生态创新白皮书

1 什么是软件定义汽车

1.1 驱动因素

汽车“新四化”的发展需要软件的加持

据大众汽车公开披露信息，未来平均每辆普通汽车软件代码量超 1 亿行。在电动化、智能化和网联化等的发展推动下，汽车将加速向高度数字化、信息化、智能化的移动终端发展。座舱娱乐体验、智能驾驶、智能车控等应用，都离不开软件的加持。以智能驾驶为例，预计到 2030 年 L5 级别自动驾驶车辆代码量将接近 10 亿行代码。随着软件代码的增加，软件在汽车上的价值也将进一步提高，据麦肯锡测算，到 2030 年汽车软件全球市场为 840 亿美元，其中自动驾驶超过 430 亿美元，娱乐/互联/安全为180 亿美元。

软件为汽车带来新的附加值，加速整个汽车价值链转移

过去汽车硬件系统同质化现象严重，整车厂在硬件上很难打造差异化，现在随着软件在汽车上的应用，软件将成为新的核心竞争力，将打破一次性汽车销售模式，形成“汽车销售和持续的软件及服务溢价”的新商业模式，并重新进行价值分配，使得汽车软件设计开发以及以软件为核心的后市场服务成为汽车价值的关键。

以特斯拉为例，特斯拉自 2012 年首次实现 OTA 升级以来，前后推出了多项与软件服务相关的功能产品，包括其选配的自动驾驶功能包（含增强型和完全两种套餐）、OTA升级包（如加速包）以及软件订阅服务等三种主要收费套餐，通过快速的软件迭代升级，进而建立软件付费模式，进一步打开盈利空间。据报道，目前特斯拉已实现了软件盈利，2021 年软件服务和其他业务收入为 38 亿美元，而且软件服务作为特斯拉收入非常重要的一环，其未来的营收比重将进一步上升，预计到 2025 年将突破 200 亿美元。

消费者需求和整个行业发展方向

随着互联网和智能手机的兴起，产生了大批互联网消费群体，通过移动互联网改变用户对智能手机的使用习惯，并带来全新智能化体验。汽车作为大型的移动终端，也是新一轮移动智能体验终端，是汽车智能化的重要发展方向。而这一发展方向又能满足消费者对汽车从单一出行产品向个性化体验型产品转变，同时随着智能汽车的快速发展，智能座舱和高级驾驶辅助系统不断完善，进一步激起消费者对于汽车智能化体验的期待。未来，数字化、个性化、体验化将成为汽车消费者的主要考量因素，而可持续迭代的软件将成为关键。

据麦肯锡《2021 年中国汽车消费者调研》结果表明，中国约有 69%的消费者认可通过 OTA 来升级车辆功能和性能，并且在这 69%的比例中有 62%的消费者愿意为此付费，因动力系统与制动系统升级、驾驶辅助、语音交付以及自动驾驶等功能升级将极大满足用户个性化和体验化的需求，用户的付费意愿更高，巨大的终端用户市场需求是驱动软件定义汽车快速发展的根本原因。

1.2 概念理解

虽然软件定义汽车已成为产业共识，认识到软件在汽车产品中承担或扮演的角色越来越重要，但行业对于软件定义汽车尚缺乏标准定义。

“软件定义汽车”是一个术语，描述的是一种主要通过软件实现特性和功能的汽车。这是汽车从主要基于硬件的产品向以软件为中心的车轮上电子设备不断转变的结果。

许多汽车驾驶员希望他们的汽车能完全融入他们的数字生活。 此外，新的互联化、自动化和个性化功能在未来将越来越多地通过软件实现。 过去，客户对汽车的体验主要由硬件决定，而现在软件正承担着更重要的角色。**软件极大地影响了客户体验，在某些情况下甚至影响了硬件规格的这种趋势，**被称为“软件定义汽车”(SWdV)。

目前行业普遍认为比较合理的描述是：“软件定义汽车就是软件深度参与到汽车的定义、架构、开发、验证、销售、服务等全生命周期的过程中，并不断改变和优化各环节，实现驾乘体验持续优化、汽车价值持续增值”。

从外延上来讲，软件定义汽车既是一种整车设计、开发、销售、服务的全新模式，也是新的整车软硬件技术架构，软件定义汽车是驱动传统汽车升级为智能汽车的关键，将涉及到商业模式、产品竞争力、组织与研发流程、人才体系、供应与生态体系等的全面变革。

1.3 架构特征

软件定义汽车架构层面最核心的特点为：软硬解耦。与过去软硬紧耦合不同，在软件定义汽车时代，软硬解耦是面向服务架构进行功能迭代，促进汽车“成长进化”的重要途径，主要特征包括：

• 面向软件开发商/广大开发者实现软件可跨车型、跨平台、跨车企重用，支持应用快速开发、持续发布；

• 面向零部件提供商实现硬件可扩展、可更换，执行器、传感器等外设硬件可即插即用；

• 具备整车级数字安全与纵深防御系统；

• 让汽车逐渐成为可持续保值增值平台，全生命周期投资回报最优。

另外，系统开放、生态融合是软件定义汽车时代的另一个典型特征。在软件定义汽车时代，信息孤岛式的封闭系统已成为过去，汽车产业亟需开放融合。在构建满足人-车-路-网-云产业融合协同发展的过程中，系统开放和生态融合成为必然。如通过开放系统，让汽车与信息娱乐、智能家居、智能交通、智慧城市等更多领域深度融合，构建“汽车＋”产业。

2 软件定义汽车的价值

2.1 产业链升级优化：大幅提升开发维护效率，缩短 TTM

随着汽车智能化的深入发展，汽车的软件和硬件复杂度将越来越高，传统以硬件设计为中心的 V 型开发流程亟需优化。传统分布式电子电气架构对新功能的持续迭代、快速升级变得越来越困难，很多机械类的硬件产品即便一个很小的变更，也要牵动整车的更改，要按照 V 型开发流程进行严格验证，是导致传统整车开发周期长的主要原因。

而通过软硬件分层解耦架构，汽车开发将进入到以软件为核心的迭代开发新模式。在该模式下软件和硬件不仅可以同步进行平台化开发，还可保持差异化上市和持续升级迭代，从而大大缩短产品的研发周期。如现在大多数智能汽车在开发时，会优先进行硬件的冗余设计，以便日后通过 OTA 功能来持续升级，而用户在购车的时候无需一次性购买一整包的全家桶，用户可以自由选择配置。

• 软件功能的开发不再受整车上市流程约束，具有一定的灵活性；

• 软件功能可灵活复制到其他车型，而无需同一功能在不同车型上开展大量重复性定制开发工作；

• 在使用车辆的过程中，用户可以按需订阅新功能，让整车厂与用户的联接不单单是买车环节这一次，而是用车的全生命周期的互动，产生更多交易的可能。

如处于转型中的德国大众汽车，在面向未来发展时，其正在进行研发流程和组织管理优化。据报道，大众将以软件优先，聚焦车辆的系统和功能，使得技术研发更加高效互联，实现车辆研发周期缩短 25%，从 54 个月缩短至 40 个月。

此外，过去汽车出现了大批因软件问题而发生的召回事件，大大增加了整车厂的召回成本。而在软件定义汽车的开发模式下，整车厂可通过 OTA 远程进行问题修复，并可减少召回引起的运营支出，同时快速响应客户的需求。进一步来看，未来在用户同意的前提下，还可利用远程技术对车辆状态开展在线实时监测，做到故障和危险提前预警，真正保障用户安全出行。

2.2 消费者体验提升：千车千面常用常新，提高保值率

过去，汽车对于消费者而言更多是交通工具，消费者主要关注安全性、可靠性、舒适性等驾乘基本需求。

现在，随着智能汽车在国内外的快速发展，用户需求和预期在不断上升，汽车对于消费者而言，不仅要好开、好看，还要变得好玩。用户可通过选配、订阅以及升级等多种方式实现汽车个性化配置，同时整车厂在征求用户许可的前提下，可通过分析和管理用户在车辆使用过程中所产生的的车况数据、用户数据等，与用户进行产品开发共创，来进一步挖掘用户的个性化需求，从而实现千车千面。如现阶段许多车企在车灯、座舱和辅助驾驶等多个领域开发了多样化、个性化用户体验模块，通过设置不同的配置车型，供用户自定义、自升级，来进一步提升用户的个性化体验。

在软件定义汽车的技术体系内，OTA 产生的盈利不会随着第一次销售而停止，而是以此为起点，在汽车全生命周期内持续创造丰厚的回报并保证最新的产品功能体验。另外，随着软件标准化的可复制性以及整车硬件进一步标准化，整车成本将得到极大的优化。基于上述原因，软件定义汽车会极大提高整车厂的盈利能力，尤其是常用常新将有力提升汽车的保值率。以特斯拉为例，波士顿咨询公司通过对比纯电动汽车、内燃机车和 Model S 三款车型的售后保值率发现，特斯拉 Model S 的产品保值率明显高于同级别车型，到第七年，Model S 的保值率约为 47%，高出同级别车型 11%-14%。

2.3 新商业空间激活：以体验为中心创造出更大的市场机会

在汽车产业链重塑升级过程中，软件定义汽车将推动整车厂由传统汽车的硬件、造型、动力等向智能服务（如体验类/出行类/数据类服务）、可快速迭代的软件方向等转化。而这也将汽车商业模式转变为包含“一次性购车”和“软件服务”的新商业模式，软件服务也将持续不断的为车企创造新的价值。

在软件服务方面，围绕用户数据、车辆数据和场景数据，软件可提供车辆相关服务和拓展类服务。

• 在车辆相关服务方面，包括车辆管理与驾驶服务、车辆后市场服务、车辆智能服务。其中车辆管理与驾驶服务主要聚焦车辆状态监测和升级优化；车辆后市场服务主要包含保养、二手车残值、保险金融等服务；车辆智能服务则主要包含自动驾驶、辅助驾驶和智能交互等相关功能。

• 在拓展类服务方面，包括出行服务、生态服务和数据/用户洞察服务。其中出行生态服务将向满足消费者高体验出行需求，提供智慧停车、补能、代驾等服务；生态服务则将构建车与外界的融合生态，包含车家互联、车机互联和车载应用生态等；数据/用户洞察服务则能进一步优化需求，进行数据管理、维护、使用和变现等。

伴随着汽车产业链价值重构，一方面汽车产业将面临着行业重新洗牌，传统整车厂、零部件公司、互联网公司、出行服务、后市场服务公司、ICT 科技公司等企业，均有望获得进入智能汽车市场的机会；另一方面智能汽车的基础技术突破和产业化将创造出重要的投资机会，如车载高精度传感器、车规级芯片、车载操作系统和智能计算平台等领域。

3 软件定义汽车面临的挑战

如前面所述，软件定义汽车是大势所趋，在业界已经形成基本共识。但如何落地，落地过程中需要解决哪些关键问题？是每一个参与企业需要首先面对、认清和解决的难题。

随着智能汽车的逐步推进，汽车的复杂度在持续的提升，造成智能汽车的开发复杂度越来越难以管理。影响或滞缓智能汽车产业升级发展的主要原因有以下四点：

• 第一：用户体验带来的复杂度提升。随着智能化的发展与普及，用户驾乘体验逐渐从传统的交通工具向第三空间扩展，汽车使用的场景、用户功能等均在大幅度扩展，成百上千的场景、功能组合形成了现在越发复杂的智能汽车体系。

• 第二：技术进步带来的复杂度提升。如越来越大的电池能量密度的追求和快充性能的追求带来了严重的电池安全挑战；人工智能、5G 通信、云计算等多种数据驱动汽车向智能化不断进化的同时，也大幅度增加了软硬件开发复杂度。

• 第三：竞争带来的堆料、堆配置、各种选配等模式导致汽车配置多样性、复杂度快速增长。

• 第四：监管&法规带来的复杂度提升。智能化、网联化赋予汽车智能、便捷体验的同时，也带来了黑客攻击、数据滥用等严重的安全问题。

对于传统汽车产业链上下游企业而言，复杂度提升的四大原因，到底意味着什么？这些原因对汽车产业的具体影响和挑战是什么？

这都将导致未来智能汽车在配置、硬件、外设、软件的种类与数量将分别增加 10 倍以上。

尤其是软件的大量引入将给汽车产业带来五大挑战：

• 第一：技术架构方面，当前架构下任何一个部件的增加、修改、更新都会对整车带来影响，以传统通信矩阵为例，当前修改和配置需要 N 周时间。未来电子电气软硬件数增加 10 倍以上，大量软件的引入，那又意味着什么呢？

• 第二：安全和隐私保护方面，全量测试时间长、代价高，如果部分测试造成漏测会导致什么后果？尤其是安全漏洞被黑客劫持，那对整车厂的品牌和用户粘性会带来什么样的后果？

• 第三：组织流程方面，整车厂如何建立与软件定义汽车开发模式相匹配的组织架构？面对消费者上千种配置组合、上千种体验场景、上万种组合服务和应用，哪些更新推送给所有的用户？哪些推送给限定的用户？

• 第四：商业模式方面，面对软件定义汽车对传统汽车供应链与合作模式的颠覆，产业中各方利益如何分配？如何共同做大产业蛋糕？

• 第五：生态协同方面，传统汽车供应链是 Tier2->Tier1->整车厂线性模式，但对于软件定义汽车时代，一方面会出现新的玩家，比如互联网公司、ICT 科技公司等，甚至出现个人开发者，另一方面整车厂按照传统的采购和项目模式难以满足消费者对汽车常用常新、千车千面的需求，故各企业将围绕以消费者为中心进行产品创新、研发和供应，传统线性模式将被打破，出现以网状合作的形态。但如何合理分工从而优化整车研发效率和成本，成为行业发展的难题。

3.1 技术架构方面

3.1.1 软件定义汽车技术亟待提升

面向汽车行业转型发展，需要产业链中各利益相关方共同推动完成。当前，整车厂、Tier1、Tier2、ICT 科技公司等均从不同视角推出软件定义汽车相关技术能力规划和解决方案，技术着力点不一致，行业级技术协同方案尚未形成，如下图所示，当前仍处于行业技术方案促动期。

• 从整车厂视角来看

传统“以整车硬件产品为主销点”的技术能力逐渐转变为“软硬件融合，且以软件产品为主销点”的技术能力，需要在完成整车电子电气架构升级的基础上，依据研发主导程度和软件能力两个维度上进行技术能力规划。

一般会形成四种模式：全栈技术布局；核心领域技术重点突破；与软件企业战略合作；同主流核心 Tier1 深度绑定。

因此，要形成长期清晰的软件技术能力发展规划、相应技术能力和软件生态方案，都需要一定的探索论证周期。

• 从零部件供应商（Tier1/Tier2）视角来看

在“软件定义汽车，整车架构升级”的背景下，既有的产品供应方式和技术能力存在严重挑战，需要深刻调整，如何实现与尽可能多的整车厂技术方案对接，需要完成哪些关键技术能力储备，需要一定的探索论证周期。

• 从 ICT 科技企业视角来看

软件定义汽车如同是“四个轮子的智能手机”在手机端的相关成熟技术能力可直接借鉴，跃跃欲试，和其他相关方存在一定程度认知偏差和技术能力对接偏差，需要一定的探索论证周期。

软件定义汽车刚刚在行业内达成共识，产业链中各利益相关方在软件定义汽车技术能力方面仍处于探索储备期，行业内缺少成功案例，没有成熟经验借鉴，大规模尝试一旦选错技术路径将带来巨大的风险。

因为产业链中各利益相关方基本处于同一起跑线，所以在软件定义汽车探索中会发现很多新技术在消费电子领域成功应用过，但在车辆领域并没有应用过。有的芯片产品规划路线图不满足控制器和整车开发计划；有的操作系统、协议栈、中间件还处于一种不成熟状态；原有的电子电气架构不满足快速响应市场的需求；原有的开发流程和开发工具不满足快速迭代的开发需求。

要解决这些问题，需要整个产业链，包括整车厂、零部件供应商、软件开发商、芯片厂商、工具厂商、ICT 等企业共同努力。

3.1.2 定制和私有接口，造成开发低效和浪费

汽车行业自身存在的大量定制化与私有化接口，这种低效、浪费的的传统开发模式却还在持续。

• 软件方面：

软件定制化将带来大量的接口适配、驱动适配、反复标定、通信矩阵的反复调整等重复性劳动，端到端软件开发效率低，人力资源浪费严重。在传统汽车时代，这种传统模式可以基本维持，但随着整车智能化加快，软件将呈现指数级的增长，软件开发模式转型将势在必行。

• 硬件方面：

硬件定制化导致的结果就是硬件的频繁定制、线束定制、重复的 DV/PV、认证等，使端到端管理复杂度和成本居高不下，频繁的产线调整导致产能浪费，型号的切换导致备件和库存总量的线性增加等。随着汽车智能化的发展，对硬件的要求越来越高，如果延续这种硬件定制模式，那硬件的定制工作量以及由此带来的软件的适配工作量是难以想象的，故这种硬件模式也亟待优化。

3.2 安全&隐私保护方面

3.2.1 安全威胁日益严峻

汽车生产供应链和制造流程复杂，需要各级的供应商配合参与，若其中有一个供应商环节出现安全隐患，就会影响到最终消费者的安全。如何构建贯穿全流程涉及研发、生产、供应链、销服、消费者等多个环节的整车数字化安全防护体系是智能网联汽车的巨大挑战。

从汽车产业发展方向看，未来以车内网、车际网和车载移动互联网为基础，在 V2X 之间实现智能化交通管理、智能动态信息服务和车辆智能化控制的一体化网络将是大趋势。随着智能汽车产业的发展，汽车行业将安全的范畴从功能安全延伸到网络安全。

智能网联汽车网络攻击风险加剧，将对社会和生命造成安全威胁。

汽车行业安全事件频发，整车厂越来越重视汽车网络安全。汽车智能化程度越高，所遭受的安全攻击面越多。在智能化背景下，全球整车厂无一幸免，例如奔驰、宝马、奥迪、大众、丰田、本田、现代等国际一线品牌，均遭受了不同程度的安全攻击。数据安全对智能汽车甚至国家安全都有重要影响，未来不排除将进一步出台更多政策规范。

3.2.2 网络安全的技术挑战

第一：智能网联汽车的攻击面广

智能网联汽车的产品形态决定了攻击面众多、物理暴露面巨大。仅无线接口安全就涉及到 WIFI 安全、蓝牙安全、蜂窝通信安全、GNSS 安全、TPMS 安全、调频安全等方面。在可接触的范围内，又有 NFC 安全、USB 安全、OBD 安全等需要考虑的暴露面。

车端 ECU 面临的常见网络安全风险包括：

⚫ 车内网络目前大多采用 CAN/CAN FD 协议进行通讯，而 CAN/CAN FD 的字节长度有限、仲裁机制、无源地址域和无认证域等问题有潜在的网络安全隐患；

⚫ ECU 硬件可能存在可读丝印和暴露的调试口，容易遭受防逆向分析等安全隐患；

⚫ ECU 固件刷写机制未进行信息安全保护，可能导致 ECU 固件或其配置数据被篡改；

⚫ ECU 中的敏感数据（如调校数据、虚拟钥匙数据、地图数据、配置数据等）的存储、访问过程中，若未采取加密存储和访问控制等防护措施，则可能导致数据被篡改或泄露，被篡改的数据可能导致系统功能偏离预期，甚至带来其他信息安全方面的隐患。

第二：智能网联车的漏洞更多

漏洞和缺陷多，分布在不同器件上，防不胜防。造成漏洞分布广，数量多，隐藏性强的原因是由于随着智能网联车技术架构的迭代发展，软件定义汽车概念的兴起，汽车正在软件层面被重构。

智能汽车的发展，是由智能汽车承载的应用功能发展来作为驱动力的，而且离不开电子电气架构的发展。在未来智能汽车控制器将会承载越来越多的功能，而且不同的电子电气架构下呈现的信息安全状态也有所不同，同时车载控制器复杂度越来越高，逐渐趋同于 ICT 行业的高性能计算机，也可能会带来新的信息安全威胁和攻击手段。

以智能驾驶技术为核心驱动力的智能网联汽车依赖大量的智能传感器、算法、云端平台的支撑。这些基础设施和功能单元包含了海量的代码以支撑运作，其中稍有一个环节出现问题，就会影响到整个链条的安全可靠运行。所以软件大规模的进入车辆生产制造行业，带来了机遇，同时也带来了极大的安全挑战。

3.2.3 法规监管要求

国内近几年开始重视智能汽车网络安全、数据安全、OTA 升级安全问题，在以政府引导、产业推动、标准委员会执行的模式下积极开展相关汽车安全标准制定工作。

在汽车网络安全标准研制方面已取得一定进展，如下图所示，全国汽车标准化技术委员会（SAC/TC114）2021 年 10 月 11 日已发布《GB T 40855-2021 电动汽车远 程服务与管理系统信息安全技术要求及试验方法》、《GB T 40856-2021 车载信息交互系统信息安全技术要求及试验方法》、《GB T 40857-2021 汽车网关信息安全技术要求及试验方法》和《GB T 40861-2021 汽车信息安全通用技术要求》四项国标，并于2022 年 5 月 1 日开始实施，同时启动国际汽车网络 安全、升级管理的标准法规R155、R156 的国标转化工作。

在数据安全方面，备受消费者和国家层面的关注。一方面，关于数据安全的法规相继出台，从《网络安全法》到《数据安全法》到《个人信息保护法》，进一步规范汽车数据安全管理和网络安全自查制度。另一方面，数据安全能力进一步聚焦，具体体现在：

⚫ 数据采集和处理过程可追溯，可审计；

⚫ 进一步加强中国法律法规的监管要求和个人信息的处理要求；

⚫ 进一步加强对基于密码学的通信安全的研究和监管。

为支撑 2021 年 10 月 1 日发布的《汽车数据安全管理若干规定（试行）》落地实施，全国信息安全标准化技术委员会于 10 月 8 日发布技术文件 TC260-001《汽车采集数据处理安全指南》，技术文件细化了部分《规定》条款中关于汽车数据传输、存储和出境等方面的要求，同时为遵循《规定》中的部分原则给出了指引。其中汽车采集数据是通过汽车传感设备、控制单元采集的数据，以及对其进行加工后产生的数据；不包括通过其他网络传输到汽车进行处理的数据，例如手机等车外设备采集的数据、汽车数据处理者通过销售合同等线下方式收集的个人信息等。

技术文件明确了汽车采集数据分为车外数据、座舱数据、运行数据和位置轨迹数据，

并对不同类型的数据分别提出要求。

⚫ 技术文件对车外数据，围绕车外个人信息的匿名化处理、数据的最长存储时间、

数据出境等方面提出要求；

⚫ 对座舱数据，围绕数据向车外传输和数据出境等方面提出要求；

⚫ 对位置轨迹数据，围绕数据的最长存储时间和数据出境等方面提出了要求。

同时，技术文件明确提出汽车制造商应对其生产的整车数据安全负责，除约束和监督零部件供应商处理汽车采集数据的行为外，还应将汽车采集数据向外传输的完整情况对用户披露。

构建整车级的安全能力和机制，确保智能汽车真正让消费者放心、安心成为发展的关键。而传统功能车时代，汽车处于孤立单元，整车厂具有很强的功能安全保障机制，但基本未涉及网络安全和隐私保护，也没有相关应对经验。智能汽车时代亟需构筑功能安全、网络安全、隐私保护全方位防御护城河。

3.3 组织流程方面

3.3.1 组织架构变革

组织架构决定了产品架构，想要什么样的系统就要搭建什么样的团队。目前整车厂组织架构示意图如下所示。整车研发团队主体是研发总部，同时在国内外设置分支机构。研发总部的机构划分有两个维度，一个维度是车型，根据车型划分为乘用车、商用车、客车、新能源车等车型开发部门；另一个维度是车辆功能模块，根据车辆功能划分为电子电气、发动机、变速箱、车身等总成开发部门，其中软件开发只是隶属于电子电气部门之下的一个专业模块。在软件开发专业模块下，发动机电控系统、变速箱电控系统、车身电控系统等控制单元是由不同专业团队独立开发的。

随着软件定义汽车时代到来，汽车电子电气架构向“域集中”、“中央集中”方向发展，电控单元之间的界线逐步模糊化。硬件被合并，软件运行在同一控制单元当中。

原来整车厂中很多部门的边界被打破，在向中央集中式组织架构迈进过程中，部门的边界已经变得非常模糊。

传统的整车功能软件是整体性、系统级的，在软件定义汽车趋势下，软件架构和形态上越来越强调分层解耦、标准化、模块化和开放性。模块具备标准清晰的接口，模块之间可组合扩展，且可由不同的供应商提供。层出不穷的场景会催生出新的应用，这势必要求软件架构具备足够的开放性和鲁棒性，面向不同的场景要能够有高复用度、高延展性。中央计算平台/域控制器通常采用面向服务的软件架构进行部署，下图为面向服务的软件架构示意图。

为此，产业链中各利益相关方都需要从战略出发调整公司组织架构，建立一个自上而下驱动、基于共同战略目标、能协调跨部门合作、平台型的软件组织，打破原来烟囱式的以功能模块划分的组织模式。

在组织机构变革过程中，决策层战略上的投入决心与定力起着至关重要的作用，如果决策层对软件定义汽车发展趋势缺乏判断，那么在内部变革碰到阻力时，就会碰到很多困难，结果可能是半途而废。

3.3.2 汽车软件人才

传统整车厂对软件的把控能力需要进一步提高

在过去的整车开发模式中，整车厂主要负责产品的功能需求定义与验收，供应商负责根据整车厂释放的需求规范进行软硬件开发与验证，并交付给整车厂，在这个过程中整车厂很少参与零部件产品的实际开发过程，从而导致整车厂现有研发团队相对缺乏软件开发能力。

在中央/域集中电子电气架构下，软件架构的复杂度大大提升。不同功能域的软件模型或代码如何集成到单一的 SoC 或 MCU 上，并且进行合理的算力分配与优化，融合后的集成测试与验证等都是汽车软件开发人员面临的技术挑战。

随着 SoC 等芯片技术的引入，许多 IT 技术领域的软件技术将应用到汽车中，例如操作系统、SOA 中间件、AI 技术及复杂的以太网通讯协议等等，这些都对整车厂和供应商的软件开发能力都提出了更高的要求。

传统整车厂人才结构以机械和动力为主，目前各整车厂正积极引入软件工程、人工智能、车联网、自动驾驶、电子工程等复合型人才，以快速调整现有人才队伍结构，增加软件工程师的比例，确保企业在向软件转型、产品创新过程中保持竞争力。

汽车软件人才紧缺的主要原因

汽车电子软件开发属于嵌入式软件的一个分支，行业相对封闭，从业人员来源相对较窄，人员能力储备不足，高度紧缺。

汽车工程师需要跨界，传统的汽车电子电气架构工程师和嵌入式软件开发工程师主要领域是 CAN 总线通信、控制器配电和线束、车辆物理拓扑、动力、底盘、娱乐、AUTOSAR CP 等，而软件定义汽车大趋势下，更多的 ICT 能力需要融入，增加了以太网、TSN、SOME/IP、SOA、Linux/QNX、Hypervisor、AUTOSAR AP 等领域技能。而来自互联网企业的软件工程师，IT 软件开发虽然能力强，但在汽车电子嵌入式硬件等领域，缺乏汽车工程和软件技能。

综上所述，行业中缺少既懂软件又懂汽车的人才，尤其是系统架构工程师，汽车软件工程师处于紧缺的状态。因此，很难通过短时间集中一大批的软件人才形成成熟的软件开发团队。

3.3.3 开发模式变革

传统汽车的软件开发采用 V 字形瀑布式开发模式，如下图所示。由于各开发部分之间相对独立，更多只是在部分内部展开局部性优化，缺乏系统级平台级的开发全局观，很难做到整体优化。同时各部分的开发时间都不一致，各部分之间的进度顺序依赖很容易造成队列效应，一旦出现某个部分开发发生延误时，便会影响整体的开发进度。

每个阶段都过于依赖上个阶段成果，导致开发成本较高且周期过长，而这些都是与“软件定义汽车”要求整车厂必须缩短产品上市周期、产品基于消费者需求、支持不断的迭代、对市场需求迅速响应等相矛盾。

在软件定义汽车背景下，汽车软件开发将由传统的瀑布式开发向敏捷开发模式转变。敏捷式开发模式既有利于达到密切的协调合作，最大限度地减少管理成本，同时因其灵活的工作模式，使开发团队可与用户实现高度互动，采用最低可行性产品的形式快速满足用户需求，并在使用中不断创新迭代，实现持续开发、持续集成、持续交付，体现软件定义汽车的优势。主要体现如下：

⚫ 软件开发流程

传统控制器的开发，遵循 V 型开发流程，以整车厂的需求为输入，考虑信息安全和功能安全，严格执行设计、实现、验证的完整流程，最终也以控制器为对象完成需求的验收，该流程的执行有利于保障需求的完整实现。同时，整个流程也有质保、流程、售后等部门参与其中进行评审和审核，以此形成良好的质量管理和质量保证体系。但整个流程相对封闭，不符合软件快速迭代的开放性和扩展性要求。

⚫ 开发交付方式

传统汽车软件的开发场景明确，软件与硬件紧密耦合，对于嵌入式软件的交付，并没有明确的“软件交付”的概念，软件随着控制器硬件一起交付。从技术层面，应用软件与基础软件一起集成和固化，有明确统一的释放节点。

随着软件定义汽车时代的到来，“软硬分离，软软分离”逐渐成为了主旋律，嵌入式软件从依附于硬件的一堆“代码”真正脱胎换骨为独立可售卖的产品；且这项产品可以在整个车辆的生命周期内持续产生价值。从嵌入式软件开发和验证的技术层面，这样的趋势使得软件要能够快速迭代，持续更新持续交付。

⚫ 项目管理

在传统控制器开发中，在项目前期形成相对完备的系统架构和软件架构，再向下分解到软件组件，经由详细设计到达软件开发。这样的开发模式适合控制器的产品形态，依赖成熟技术的完整积累。

面向开放架构/持续交付的软件特性，在项目管理上，敏捷成为了关键词，随着软件交付不再是统一固定的交付节点，软件模块在整个车辆生命周期都有新增的机会：模块化软件具备单独交付的条件和场景，随之而来的是软件的设计/开发/测试/验证的节点也随之迭代起来，变化和持续交付是常态，这对整体的软件项目管理提出了更高的要求。

综上，汽车软件开发模式由传统的瀑布式开发向敏捷开发模式的变革，为软件定义汽车落地面带来巨大挑战。

3.4 商业模式方面

3.4.1 产业分工价值链转移

软件定义汽车对产业链分工产生了颠覆性的改变，各利益相关方的分工变化如下图所示：

⚫ 过去

大部分整车厂的职责是定义整车电子电气配置特性，描述车型特性及功能，明确用户明显可见的汽车特征，比如“电动天窗”、 “全景天窗”等能够被驾驶员或乘客所应用的功能，“防抱死系统 ABS”或“车道偏离报警 LDW”等用户能够感受到的增加汽车安全的特性。

传统模式下，整车厂协调各 Tier1 开发产品，装配成试验车，并通过一系列整车试验完成产品认证，变更周期长。这种完全依赖 Tier1 的方式存在着执行不灵活、业务效率低、数据碎片化等弊端，不满足功能迭代快速上市的需求。

⚫ 现在

各个整车厂在新型电子电气架构开发过程中，希望自上而下定义需求、功能和标准。在定义整车电子电气配置特性时，需要讲好用户故事（User Story），明确作为一个<角色>, 想要<活动>, 以便于<取得商业价值>。并在此基础上完成用例（Use Case）设计，复杂的系统设计和软件设计，从而形成各电控系统的硬件需求和软件需求，再分软件、硬件单独采购。当前电子电气架构实现方式一般有两种，一种方式是与基础平台厂家建立合作，另外一种方式是自主研发、垂直整合。两种方式都将导致供应关系发生根本性变化，原有传统供应链体系变革存在阻力。

⚫ 未来

整车厂、Tier1 和 Tier2 各司其职的价值链将被进一步打破，Tier1 甚至 Tier2 将深度参与整车厂主导的复杂系统设计和软件设计，ICT 科技公司、互联网公司、车载软件公司等的涌入带动供应链管理扁平化，产业链的各利益相关方还没有明确边界。软件定义汽车总体规划，SOA 顶层设计，整车厂应该负责哪一部分？Tier1 应该负责哪一部分？这些都是摆在整车厂面前的难题，如果全部自己做会耗费大量精力和财力，全部交给 Tier1 厂家又很难形成产品差异化，如何进行业务分工，厘清整车厂与 Tier1 厂家边界是目前面临的挑战。

3.4.2 车企传统供应链模式转变

整车厂传统采购模式主要围绕硬件制定组织、流程和工具，而面向当前及未来软件定义汽车所要求的电子电气架构正由信号导向向服务导向转变，并带来软硬件的充分解耦与供应链协同模式的转变。整车厂已经开始思考软件的 Maker-or-Buyer 策略、采购策略、质量保障以及组织优化等关键问题，比如：

⚫ 软件价值链的哪些环节应由整车厂自研把控？哪些环节应该交给外部供应商来提供？

⚫ 整车厂如何与供应商协作以有效保障和把控软件系统的开发成熟度与完成度？

⚫ 针对软件开发，整车厂如何调整长期合作关系与并购投资规划？如何拓展与软件供应商以及其他伙伴的合作关系？

3.4.3 行业盈利模式变革

传统模式下汽车行业都是通过汽车销售挣钱，用户花钱买到的也是车辆本身，例如发动机、变速箱、底盘、驾驶室等，整车厂赚的是材料成本和汽车售价的差价。现在汽车硬件越来越同质化，配件行业越来越透明，整车厂利润越来越薄。

在软件定义汽车时代，不拼硬件拼软件。整车厂将车辆提供的所有服务在服务注册中心进行注册，所有用户，包括企业用户、个人用户和生态用户都可以通过服务注册中心订阅服务。服务订阅示例如下图所示。例如通过服务订阅可以让用户的车辆具有语音控制功能，包括控制车速、灯光开启和亮度、车窗升降、空调温度和风量等等，语音控制服务可以一次性付费购买，也可以每月付费租用。这些功能不需要额外安装硬件，只需要软件工程师编写代码即可，而软件开发可以在不增加任何成本的情况下进行不断复制，所以只需要有好的创意，利润空间无上限。

整车厂通过硬件预埋和服务订阅将后市场打造成新的利润增长引擎。越来越多的整车厂将以接近成本价的价格销售汽车，并主要通过软件为用户提供附加价值，这不仅会降低消费者的购车成本，更会让用户享受到万物互联的实质便利。整车商业模式由一次性前装收费转变为后市场订阅持续收费，构建有竞争力的盈利模式并真正带来商业价值是很大的挑战，挑战主要体现在：

一、后市场持续变现能力有待进一步挖掘

软件落地应用后，复制成本微乎其微，软件的盈利规模完全基于目前软件载体（车）的保有量和选装软件的用户占比。然而后市场持续变现能力还有待进一步挖掘。

⚫ 造车新势力创收潜力大，但难于形成规模。最大的问题是自费选装软件普及率低，比如，中国市场特斯拉 FSD 的选装率仅有 1%-2%；其次造车新势力的用户基数与传统整车厂的差距悬殊。

⚫ 传统整车厂拥有着大批品牌簇拥者，这使得传统整车厂的营商环境比新势力更友好。但也正是由于用户黏性的存在，传统整车厂在转型过程中又不得不兼顾到各个年龄段的用户，而开发各年龄段、多层次的用户都能够轻松上手的智能软件也绝非易事。

二、硬件预置与成本压力难平衡

虽然软件决定产品性能，但是硬件决定产品性能的天花板，再强大的功能也要依托硬件来实现。所以为保证车辆在一段时间内的成长属性，需要预置更多的硬件设备。而传统整车厂的商业模式很少考虑后续的升级需求，在成本压力巨大的竞争模式下，很难预留芯片算力、存储空间、冗余模块用于后续升级，基本上都是刚刚好满足当前功能需求。所以在如何平衡硬件预置与成本压力方面存在挑战。

三、软件产品思维转变的挑战

新的商业模式将更多地关注驾乘人员的个性化、体验化的功能需求。这将在产品开发最前端进行转变，需要更多深谙用户体验的产品经理来根据不同细分消费群体的特征来设计定义相关的功能需求，而往往这些产品经理通常对汽车的了解较少，设计的功能往往在落地性方面难度较大。

如何构建具有竞争力的商业模式形成大规模持续变现，技术上如何选择可持续演进的软件架构，以支持未来的附加功能或按需服务，目前还处于雏形阶段。

3.5 生态协同方面

在新型电子电气架构领域，目前大部分整车厂和供应商短期内都聚焦在平台基础建设，例如新架构的硬件、软件中间件、SOA 架构及原子服务等开发落地。长期来看，在 SOA 架构及广义的整车操作系统建设初步成熟后，丰富的上层应用生态才是未来价值增长的关键点，拥有巨大的想象空间。而创造出丰富的应用的核心是打造繁荣的开发者生态，以智能手机行业在中国的开发者生态数据为例，详见下表。

部分整车厂和零部件供应商已经开始布局并建设汽车应用软件的开发者生态，但是相比于智能手机行业，汽车应用软件开发者生态的挑战更大，主要体现如下：

第一：各整车厂之间的标准、接口规范不统一

汽车是一个定制化、非标化程度很高的产品，各整车厂设计的电子电气架构下的软硬件接口各不相同，并都在开发定义自己的汽车操作系统、服务接口、开发工具链等，这意味着同一个应用要落地到不同品牌的汽车上可能需要经过大量的开发适配工作，从而导致应用开发和部署成本很高，一定程度上会影响开发者参与的意愿度。

第二：单一整车厂的体量和用户基数有限，难以吸引到大量的开发者

单一整车厂的用户数量有限，大部分国内整车厂每年不到 200 万辆，小整车厂可能只有 10 万量不到，再加上前面提到的各车厂的标准、接口都不相同，意味为单次应用开发及部署开发可触达的用户有限。

第三：汽车软件开发的专业性要求度高，落地见效周期长

汽车作为安全属性很高的产品，这就需要开发者具备较强的专业知识背景，所开发的应用要确保不能影响功能安全及信息安全要求，需要经过长时间的测试验证才能部署到汽车上使用。

4 软件定义汽车如何落地实现

4.1 架构升级

4.1.1 软件架构：分层解耦、服务化、API 接口标准化

随着企业向软件定义汽车开发方法的转变，软件架构也需要同步进行升级，引入面向服务的架构（Service-Oriented Architecture，简称 SOA）方法论。汽车 SOA 是对整车智能化的底层能力进行组织。将车端的硬件能力和各种功能服务化，这些服务根据 SOA 标准进行接口设计，基于 SOA 标准协议进行通信。这样，各服务组件之间就可以相互访问，从而扩展了服务的组合形式。

SOA 的引入使汽车传统封闭、固化的软件系统逐渐成为具备开放性、重用性的软件生态。在新一轮的软件架构升级中，基于分层解耦的 SOA 服务化架构，利用设备抽象和原子服务实现硬件能力的充分服务化，具体对象包括控制器周边的传感器、执行器、传统总线通信，以及控制器自身的诊断、存储设备。同时，基于“逻辑语义转换”的设计思想，完成接口标准化，实现不同平台、不同车型的接口重用性目标。

随着基础架构及开发方式的变化，“软件定义汽车”会颠覆整个汽车开发流程，基于SOA 的软件架构方案为智能汽车系统提供了重要的服务抽象。严谨的封装和分层结构支持使用敏捷开发方法和针对接口进行测试，并降低了系统的复杂性，将大大简化软件组件在车辆更新换代时的重用。

架构标准化：

分层架构，在原有的整车架构中，引入原子服务层和设备抽象层。

⚫ 设备抽象层负责封装底层的硬件差异，并把硬件层的特性以服务的方式提供接口，供原子服务层进行调用，硬件的调整不应导致系统软件对外提供的接口发生变化，使得应用逻辑摆脱底层硬件平台的束缚；

⚫ 原子服务层作为中间层，与平台解耦，对上承接应用服务的调用，对下进行设备抽象的访问，体现车型差异，并配置化适配，使能上层应用跨车型复用；

⚫ 应用/组合层服务主要负责用户需求逻辑的实现，通过调用原子服务层提供的接口，组合出千变万化的场景化应用。

接口标准化：

跨车型、跨零部件供应商，最大化复用，降低软件定义汽车软硬件开发复杂度。在架构标准化的基础上，如何能实现软件的跨车企使用？就需要对层与层之间的接口进行标准化，不同整车厂、Tier1、平台供应商定义同一套服务接口，使得不同整车厂之间，不同 Tier1 之间的软件可以相互调用，大大增加软件的复用性，缩短车辆开发周期。

在接口标准化推动方面，中国汽车工业协会已经发布了第三版《软件定义汽车原子服务 API 接口与设备抽象 API 接口参考规范》，包含 700 多个 API，涵盖车身控制、热管理、能量管理、运动控制、智驾域、动力域、底盘域等多个功能域，参与接口标准化定义的成员包含整车厂、零部件、基础平台供应商、软件供应商等 100 多家公司。

4.1.2 通信架构：基于车载以太网的技术应用

随着车辆功能的不断增加，特别是自动驾驶、智能座舱的不断发展，需要传递的信号已呈爆炸式增长，车辆功能不断升级更新，用户对于 OTA 升级体验提出更高的要求，传统的 CAN 总线通信的方式已不能满足车辆功能的增长速度，采用基于以太网服务的通讯方式，可实现功能的灵活重组，有效解决传统面向信号的通信架构中因个别信号增减/变更，而导致功能相关的所有系统均产生变更的问题。

车载以太网及其支持的上层协议架构如下图所示，车载以太网主要涉及 OSI 的 1、2层技术，车载以太网同时支持 AVB、TCP/IP、DoIP、SOME/IP、DDS 等多种协议或应用形式。

SOME/IP 的全称为：Scalable service-Oriented MiddlewarE over IP，基于 IP 的可扩展的面向服务的中间件，已于 2013 年纳入 AUTOSAR 4.1 规范。

通信架构升级之后带来的变化：

⚫ 更灵活的沟通机制：CAN 总线为广播式通信，多主方式的工作使得每个节点发送的信息都可能占据所有的通信媒介，只是接收节点可以选择是否接收该信息。而以太网以一对一或一对多两种方式进行通信，一对一的方式发送节点的报文中涵盖自己和一个接收节点的地址；一对多的方式中发送节点的报文中涵盖自己和多个接收节点的地址。二者都不影响其他节点的通信。

⚫ 更高的带宽，更低的时延：车内数据传输总量及对传输速度的要求持续提升，以及在跨行业的标准协议需求的驱动下，支撑更多应用场景、更高速的以太网取代CAN/LIN 等传统汽车车内通信网络已经成为必然。

⚫ 更多的应用场景，易互联易扩展：车载以太网与车外网络基于相同协议，在与车外网络进行通信时，接口过渡更加平滑。传统车内通信网络基于独有的网络协议，且接口标准化差；与车外网络进行交互时，需要对不同系统的协议进行转换。在网联化趋势下，车载以太网的协议转换成本更小。

⚫ 更快的 OTA 升级速度，更易用的体验：采用以太网进行 OTA 升级，通讯速度相对传统的 CAN 升级，提升了 10 倍以上，大大降低了用户等待的时间。采用基于服务的通讯 SOME/IP，可实现功能的灵活重组，有效解决传统以功能需求为核心的架构中因个别功能增减/变更，而导致功能相关系统均需变更的问题，降低系统OTA 升级的复杂度。

4.1.3 硬件架构：区域接入+算力集中化

整车电子电气架构是实现软件定义汽车的基石，目前市场上销售的传统汽车大部分是分布式电子电气架构，如下图所示。

在分布式电子电气架构中，首先将汽车功能划分为不同的模块，如动力控制、底盘控制、主动安全、被动安全、智能驾驶、信息娱乐和车身等。然后再将每个模块的功能再进一步细分，例如车身功能又细分为车灯控制、车门控制、座椅控制等功能。不同的电控功能采用独立电控单元（ECU）实现，不同 ECU 之间通过 CAN/CAN FD 进行通信。

因为每个 ECU 由不同的供应商开发，有着不同的嵌入式软件和底层代码，所以分布式电子电气架构在整车层面造成大量的冗余和 BOM 成本。另外，因为车内软件都分布于各 ECU 上，且 ECU 都由各供应商独立完成，其软硬件是紧密耦合的，整车厂并没有权限去维护和更新 ECU 上的软件。

快速满足用户需求是整车厂抢占市场份额的关键，而分布式电子电气架构严重制约整车厂响应市场需求的速度。假设某车型中设计完成后，用户提出增加驾驶员位置记忆功能，即驾驶员将车辆的座椅、方向盘、外后视镜等相关系统调整到舒适的位置后，可以将其设置为记忆位置，方便后续快速调整。需要对车门控制器、座椅控制器、方向盘控制器、网关等多个部件进行软件变更，只有当各个零部件供应商完成变更，并且整车厂完成集成测试和整车测试后，才能够将新功能投放市场，这将造成开发和变更周期长、成本高等问题。

为此，各整车厂早已开始储备新型电子电气架构方案，以促进软件定义汽车的快速实现。新型电子电气架构的显著特征是功能（软件）集中化、硬件标准化。通过中央计算平台/域控制器对控制功能进行统一管理，从而降低硬件冗余和 BOM 成本，减少整车厂对众多供应商的依赖。根据功能集中程度不同，新型电子电气架构主要分为三种类型。

第一种：域集中式电子电气架构

在域集中式电子电气架构中，将整车电子电气控制功能划分为 N 个功能域，每个功能域设计一个域控制器，其余控制器均为域内控制器，各域内控制器一般为智能传感器、执行器和传统控制器。

域集中式电子电气架构示意图如下图所示，示例中将整车电子电气控制功能划分为五大功能域：动力域、底盘安全域、智能驾驶域、信息娱乐域和车身舒适域。

第二种：跨域集中式电子电气架构

在域集中式电子电气架构中，域控制器只负责一个域的功能集中控制；而在跨域集中式电子电气架构中，有些域控制器负责两个或两个以上域的功能集中控制，进一步提升了系统功能集成度。比较常见的跨域集中式电子电气架构是三域架构，跨域集中式电子电气架构的示意图如下图所示。

三域架构分别为车辆控制域、智能驾驶域和智能座舱域，将原来的动力域、底盘安全域和车身舒适域整合为车辆控制域，智能驾驶域和智能座舱域专注实现汽车智能化和网联化。

三域架构有 3 个域控制器：车辆域控制器负责整车控制，对实时性和安全性要求高；智能驾驶域控制器负责自动驾驶相关感知、规划、决策相关功能实现；智能座舱域控制器负责 HMI 交互和座舱相关功能实现。

第三种：区域接入+中央集中式电子电气架构

中央集中式电子电气架构不再按照功能去部署车内的电子电气系统，而将整车所有功能域的控制逻辑均集中于中央计算平台，进一步提升了系统功能集成度。原有分布式和域集中式架构中的 ECU 的控制/计算功能被中央计算平台收编，转变为更加简单的传感器或执行器。

为了减少线束长度，简化通信，就近接入和供电，在中央集中式架构下可以按照物理位置划分区域并在区域内部署区域控制器，形成中央计算平台和多个区域控制器的架构，中央集中式电子电气架构的示意图如下图所示。

硬件架构的升级，同时需要考虑跨域功能的融合、SOA 架构下的软件功能分层、服务化后的控制实时性、功能安全设计、复杂的硬件设计与集成等等。

4.2 安全升级：构建多层次的整车纵深防御体系

4.2.1 功能安全

随着电子电气架构技术的不断升级，整车越来越多的系统和组件对功能安全产生影响，为此，功能安全也从部分关键系统开发，向整车各系统全面开发拓展。

同时，由于域控制器、中央计算平台等新架构技术的出现，对功能安全提出了新的技术挑战，功能安全必须建立针对这些复杂系统及软件的开发和测评手段。

功能安全技术也影响着电子电气架构技术的发展，从传统的失效安全（Fail-Safe）向失效运行（Fail-Operational）演变，电子电气架构设计中引入了更多的冗余（如通信冗余、冗余控制器等）及安全保障措施。

未来，车辆智能化生态的形成，将促进功能安全技术走出单车，向全链路延伸，实现整体智能生态的整体安全。

4.2.2 预期功能安全

电子电气架构相关的预期功能安全指的是规避由于功能不足、或可合理预见的人员误用所导致的人身危害。预期功能安全技术属于汽车技术的一部分，对应的标准为 ISO 21448。根据自动驾驶功能及其运行设计域，分析满足预期功能安全要求的系统配置方案，基于系统配置方案确定或选择合适的电子电气架构方案。预期功能安全关键技术点：

（1）自动驾驶安全准则制定技术：针对自动驾驶已知场景和未知场景下的安全表现，制定客观量化准则，科学判定自动驾驶的安全水平；

（2）安全分析技术：通过 STPA 等安全分析手段，识别自动驾驶安全相关功能的不足性能局限及危害触发条件，制定针对性措施，开展功能更新；

（3）多支柱法测试技术：由仿真测试、定场景测试和真实道路测试组成的自动驾驶预期功能安全测试体系；

（4）安全论证技术：基于安全开发、分析、测试等结果，制定预期功能安全档案策略，通过 GSN 等