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 等论证手段，评估自动驾驶安全风险，完成预期功能安全发布；

（5）安全监控技术：通过车载和远程手段，监测自动驾驶运行过程中的安全表现，识别安全风险并开展必要的风险控制措施，以确保自动驾驶运行安全。

4.2.3 网络安全

智能汽车车辆端、通信管道、云平台以及移动应用均面临一系列的信息安全威胁。从汽车网络空间维度出发，通过多重技术协同、不同手段互补、从外到内多层次部署安全防线，满足车辆信息安全防护的纵深性、均衡性、完整性的要求。需要依据新一代车辆电子电气架构，从网联安全、内网安全、ECU 安全角度实施部署相应防护措施。

⚫ 网联安全

网联接入层主要抵御针对以太网的 DOS、PING 类型、畸形报文、扫描爆破、欺骗、木马等网络攻击。需要具备车云联动机制的主动安全防护能力，可通过云端系统实时配置防护策略，主要包括接入认证机制、通信保护机制、以太网防火墙机制和入侵检测与防御（IDPS）机制。

⚫ 车内网安全

车辆内网安全主要抵御针对车载 CAN/CAN FD、车载以太网的攻击入侵，包括报文监听、错误注入、报文重放等攻击。防护的策略包括：总线入侵检测机制、内网防火墙机制、功能域隔离机制、总线通信保护机制和诊断安全保护机制。

⚫ 关键 ECU 安全

为确保车辆系统或关键数据不被破坏，在车辆关键 ECU 层面需具备安全启动、关键数据安全存储、系统安全运行的安全能力，并可为应用运行提供权限管理能力。

⚫ 服务安全

SOA 安全框架需要遵循五个基本原则：机密性、完整性、真实性、授权性和可用性，通过信息加密、数字签名、密码认证、设计访问控制列表 ACL、DOS 攻击监控等多种方案及产品实现网络安全，同时保证这些网络信息可被发现、被访问、被通信以及被监测。

⚫ 在服务发现上，设定信息安全分组隔离机制，使得服务广播消息只发给有需要的的服务使用者；

⚫ 在服务访问上，为服务提供方设置信息安全访问控制机制，认证并授权服务使用方发起的服务请求；

⚫ 在服务通信上，根据 SOA 服务实际的业务应用场景决定 SOA 消息应采用的信息安全传输机制；

⚫ 在服务监测上，设置服务安全监控机制，发现 SOA 服务相关的异常事件及安全响应处理机制。

4.3 流程变革：敏捷开发，迭代发布

汽车上的功能日新月异，软件代码量日益增加，传统 V 模型下的瀑布式开发已经不堪重负，为了快速交付给客户最迫切需要的功能，软件开发流程的转变至关重要。目前，越来越多的汽车零部件供应商转向了敏捷开发。在系统架构实现软硬件解耦，层次化架构系统软件、中间件和应用软件的基础上，实现软件功能的快速迭代、发布，使得整车厂可以快速占领市场。

敏捷开发流程的核心是培养研发人员的协作意识、责任意识、质量意识、学习意识、创新意识，进而提升整个软件研发团队的研发能力，高效地开发高质量的软件产品。

特性开发采用以月为研发周期的迭代开发模式，进一步分为详细设计与评审、特性开发与代码走读、代码质量检视与评估、测试用例设计与编写、特性功能联调、特性合入评审等多个子流程。每个子流程有具体的输出件（设计文档、源代码、评审报告、测试用例、测试报告等）和量化评判体系（设计文档章节完整性、增量代码度量报告、评审意见密度、测试用例覆盖率、缺陷密度等），确保每一个子流程均按照软件研发质量要求达成，并对所有文档归档以支持软件质量回溯。

版本发布采用以周为发布周期的软件版本快速迭代模式，每周从稳定分支发布版本，对软件基本功能、新增特性进行充分验证，对已解决的问题进行回归测试，均通过之后再发布版本。敏捷开发的业务价值：

⚫ 用户体验能以月为单位发布。

⚫ 漏洞和补丁按周进行快速发布。

⚫ 软件版本按小时迭代，部件与整车同步集成、自动化验证（7*24h 无人值守）。

4.4 工具链升级：基于 SOA 的整车服务化开发

SOA 的总体思路是设计服务模型，将不同的基础服务进行抽取，分层解耦定义恰当的API 接口，应用调用服务 API 接口实现业务逻辑。API 接口定义独立于实现服务的硬件平台、操作系统和编程语言，确保构建在不同系统中的服务可以以一种统一通用的方式进行交互。

对于汽车行业而言，SOA 是一套新引入的技术，需要一套有效的流程、方法和工具链，三者相辅相成，当前业界还没有一套非常成熟的方法论和工具链，大部分整车厂和 Tier1/Tier2 都处于探索阶段，下图展示了一种基于服务的功能开发流程方法。

首先对功能进行需求分析，输出场景定义和特性设计，以及对应的物理拓扑和模块功能定义接着继续进行系统设计，包括服务架构设计、服务设计和通信设计，服务定义需依据中国汽车工业协会软件定义汽车工作组发布的 API 接口参考规范。

4.5 产业分工升级：合理分工、开放协同

面向未来的智能汽车时代，随着原有产业价值链开始被打破，传统车企纷纷转型，新生力量奋力崛起，技术进步日新月异，跨界玩家悉数入局，产业竞争的要素和形态正在悄然变化，一方面驱动着新产业格局的形成，另一方面也催生着新产业生态的出现。智能汽车产业朝着更加多元化、复合化的方向发展，出现诸多不曾涉猎的新技术领域，开放合作才能实现共赢，优势互补才能形成合力。

4.5.1 整体建议

如前所述，汽车产业正向电动化、智能化演进，技术、用户体验等驱动汽车行业快速成长。随着智能汽车的逐步推进，整车软硬件复杂度也在持续提升，行业向软件定义汽车转型已成产业共识，但软件定义汽车还处于起步阶段，软件的大量引入给汽车产业从设计、开发、集成、测试、发布和维护都带来一系列的挑战。只有管理好软硬件组合的复杂度，才能持续满足消费者的体验需求，形成市场竞争力。

分层解耦是提升软件复用性，降低软硬件开发复杂度的关键手段，也是迈向软件定义汽车的必由之路。通过分层解耦，可以实现软件与硬件分离，应用与基础平台分离，但如何实施成为关键挑战，将直接影响软件定义汽车的战略目标和价值达成。从技术层面，架构如何分层，服务如何划分有利于最大化复用、最简化开发维护和长期演进是关键挑战。只有合理、稳定、统一的服务划分才能确保软件定义汽车价值实现最大化。从产业链方面，各方如何定位、分工、协作才能保障各方最大化利益是关键难点，开放、合作、共赢是软件定义汽车快速落地的基础。

整体建议：

从技术规范统一性和产业合理分工两方面，加强汽车产业链上下游企业合作协同，共同推动智能汽车软硬件接口标准化，构建原子服务和设备抽象层，实现应用、基础平台和硬件的分层解耦；建立 SOA 服务架构和接口规范化统一化，实现跨车型、跨零部件供应商最大化复用，减少定制加速创新，提升智能汽车产业协同效率。同时，结合产业链各方诉求和优势，基于分层架构，形成合理分工从而通力合作。

具体建议：

⚫ 在设备抽象层，实现设备与端口的解耦，屏蔽硬件功能差异和厂家差异，并且该层由行业联合定义，并实现标准化；

⚫ 在基础平台层，实现基础软件与硬件解耦，屏蔽设备与驱动差异；

⚫ 在原子服务层，实现服务与平台解耦，提升软件复用性，并且该层由行业联合定义并标准化；

⚫ 在应用/组合服务层，实现应用与服务解耦，应用跨车型复用，聚焦体验，并且该层建议由整车厂主导。

同时，API 规范化并不等于产业竞争同质化，在标准上开放，在产品上竞争。整车厂和各零部件供应商可在关键技术上分层构筑核心竞争力，在协同上构筑管理能力提升效率和规模，在商业模式上构筑保护机制确保独家/先发优势，从而最终面向用户提供独特性、可进化、更高附加值的产品。

同时，不同厂商的硬件、软件、平台等具有互操作性，即不同车型和不同部件，能够用相同的语言完成跨域调用、交换和共享信息的能力，让产业链的每一个企业都受益。

对于整车厂：

⚫ 更易管理：向面向对象软件管理模式转变，软件 Onetrack，更易管理更复杂的整车软件系统和供应商，并可聚焦集成能力构建竞争力；

⚫ 更快上市：基于 SOA 高效软件开发，并可预集成服务 API，加速车型上市速度。

对于零部件供应商：

⚫ 减少定制：减少不增值的繁复工作，降低面向不同车型开发和维护成本；

⚫ 加速创新：释放人才聚焦创新，构建差异化技术和产品。

对于软件开发企业/开发者：

⚫ 更易上手：容易理解，整合开发资源，快速开发；

⚫ 更多机会：跨界人才新思维带入汽车行业，持续挖掘后市场价值，带来更多变现空间。

4.5.2 整车厂

整车厂直接面向终端用户，提供满足用户需求的汽车产品，将软硬件、应用功能及生态服务等各方集成起来，完成从整车制造到长期出行服务的交付。

整车厂不仅仅是生产汽车的制造商，也会面向消费者提供移动出行相关服务，通过软件的开发、配置、迭代升级来满足用户多种多样的用车需求。用户能通过软件设置汽车产品的不同功能，甚至可以根据个人喜好编辑出行场景或下载需要的特定场景功能。为此，整车厂需要完成以下平台的搭建及开发：

1. 硬件平台整合

硬件平台是软件定义汽车的基础，现阶段各个整车厂规划的电子电气架构主要有三种：集中功能域、跨域融合、中央计算域+区域接入。为应对智能化汽车和软件定义汽车的需求， 中央计算域+区域接入将会是未来的主流电子电气架构。整车厂需要根据自身情况合理分配各域的功能及区域接入硬件的接口。

2. 软件集成

整车厂需要具备软件集成能力，构建“软件中心”或者“用户体验中心”，并建立相应的组织架构，提升整车软件开发能力。

第一阶段：关注整车控制应用层软件和与用户体验强相关类软件，形成品牌特色，提高用户粘性。搭建软件开发环境，按照软件开发流程，例如导入 AUTOSAR 规范等，实现应用层软件和供应商硬件在开发层面解耦，应用层软件封装后交给供应商集成和配置，而不需要对其开放应用层，可以指定几个硬件供应商。同时可与生态服务商合作，将第三方软件嵌入应用层。应用层自主掌控后可实现快速移植，提高开发效率，也为功能持续迭代、用户常用常新提供基础。OTA 是核心通道，第一阶段实现是迈向软件定义汽车的第一步。

第二阶段：通过购买配置工具逐步实现应用层与底层的集成，硬件供应商提供“白盒”，在整车厂进行集成和刷写。实现真正意义上的软硬件解耦，扩大硬件的采购范围，降低采购成本。但是底层配置功能需要整车厂大量的投入，整车厂根据自身能力考虑是否入局。

第三阶段：逐步进入硬件和底层的自主开发。通过硬件降低整车成本，自主选择核心芯片，打破硬件平台化的局限，以成本和客户体验为导向，根据整车配置及功能需求进行软件模块化移植。

3. 开放平台的构建

传统汽车开发完全依托车厂的工程师理念，是一种凌驾于客户之上的开发模式。开放平台本着共赢、共生、共创的新模式，能在新形势下解决供应商、整车以及用户之间的关系。

开放平台可以为车企开发工程师、第三方、用户提供整车车辆能力，这些能力包括一些底层硬件能力、软件能力、数据及信息，根据这些能力结合使用场景可以开发出多样化的软件，为用户提供定制化、个性化、订阅式服务，即为用户和整车厂创造价值，也获得自身收益。实现用户参与车辆软件的开发，真正实现软件定义汽车。

通过开放平台，可以调用汽车上百千个硬件模块，能提供比手机更强的感知能力，更多的应用场景，更大的覆盖范围，更长的生命周期，所以汽车生态圈要比手机生态圈更广，比手机更加开放，更加贴近用户。

4.5.3 零部件供应商

对于传统零部件供应商来说，在软件定义汽车发展趋势下，整车厂在系统功能开发的话语权越来越大，借助软硬件解耦和 SOA 架构的落地，整车厂也将逐渐承担部分零部件供应商应用功能的开发，因此传统以硬件为主的 Tier1 迫切需要转型寻求新的出路。

目前来看，软硬件全栈能力的打造，是抢占下一个市场份额制高点的关键所在，很多能力非常全面的 Tier1 正在打造“硬件+底层软件+中间件+应用软件算法+系统集成”的全栈技术能力，既能为客户提供硬件、也能提供软件，同时也提供软硬一体化的解决方案。但这样的布局要求 Tier1 大量的人力和资金的投入，不是所有 Tier1 能够承担的。

对此，零部件供应商应将进一步开放硬件端口，对硬件的能力抽象化，为降低面向不同整车厂的定制成本，提高交付效率，需要将接口按照统一标准进行开放，从而降低匹配复杂度，减少软硬件耦合度，增强灵活性和复用度。并主动联合整车厂、软件供应商等多方共同打造零部件生态，吸引和创造更多元更丰富的盈利场景。

在标准接口的前提下，性能的差异性会给零部件供应商带来竞争，同时也会促进零部件供应商去创新和进步。零部件供应商的重点应该聚焦内部的核心算法，通过内部算法和代码的优化升级，实现性能和体验的差异性和持续进化。并通过和整车厂、人工智能、软件等领域的 IT 公司合作，了解最新的需求和发展方向，调整自己的研发方向和能力，立足硬件，运用积累的行业 Know-How 优势构建应用功能软件能力，反哺并带动差异化硬件销售，是很多零部件供应商的选择。

4.5.4 基础平台提供商

面向软件定义汽车时代，基础平台厂商的目标是运用自身 ICT 技术积累和优势，帮助整车厂打造适合整车上自身规划的、差异化的下一代电子电气架构，降低智能汽车研发复杂度，提高效率，加速智能车开发落地。

但目前从整车厂到一级供应商、二级供应商和三级供应商这样的供应链模式正越来越模糊，而车企越来越希望能够主导更多的内容，这迫使基础平台提供商必须以更加开放的姿态打破边界，聚焦自身优势产品，面向上下硬件和应用软件提供开放 API 接口，并为功能软件提供安全可信的运行环境和易用的服务开发及验证工具链。

建议基础平台提供商为整车厂提供一个面向智能汽车可持续进化的架构，在设计理念上应以人为本，围绕用户体验与整车厂商业成功持续创新。

4.5.5 软件供应商/软件开发者

随着整车厂自主权和软件自研能力的不断加强，整车厂开始寻求与软件供应商的直接合作，比如整车厂商将首先寻求把座舱 HMI 交互系统功能收回，UI/UX 设计工具、语音识别模块、音效模块、人脸识别模块等应用软件则直接向软件供应商购买软件授权，从而绕过传统 Tier1，实现自主开发。

随着软件定义汽车的变革的推动，汽车硬件体系逐渐趋于标准化，而软件是汽车里迭代最快、最容易个性化和差异化的部分，同时软件也将推动硬件创新，二者相辅相成。对于软件供应商来说，能提供越多的软件 IP 产品组合，就越可能获取更高的单车价值。

同时，软件供应商也正寻求进入传统 Tier1 把持的硬件设计、制造环节，比如域控制器、T-BOX 等，以提供多样化的解决方案。对智能汽车 APP 应用开发来说，基于原子服务标准 API 开发应用软件将变得非常便捷，容易上手。对于应用来说不用过多的关注底层的实现，降低不同层次、不同模块的依赖性，类似基于安卓的开发模式。针对不同的人群、不同的车、不同的生活场景，不同的应用开发商就会做出功能不同、画面不同、体验不同的应用。应用开发的门槛变低了，就有更多的软件供应商/开发者能参与到汽车应用 APP 开发中来，随之而来的就是软件开发的竞争变大了。软件供应商应该基于一些调查数据去分析不同人群的偏好，针对不同的车型，开发出适合大众并具有差异性的应用。用户可以根据自己的实际情况，选择性的安装部分功能和特性应用，通过不同的应用和服务，可以定义自己车辆的一些特性，达到通过软件进行功能升级或个性化定制的目的。

在竞争的过程中不仅会出现非常受欢迎的应用软件，也会提升应用软件供应商提升服务的主动性和精确性，提高产品创新的能力，从而繁荣智能汽车应用生态。

4.5.6 行业组织

政府应该从法规、政策、标准等方面来帮助整个汽车行业建立合理高效的管理制度，监督整个行业有序、平稳的运转，不断做大做强，并确保整个行业的公平竞争。

从政策上鼓励各企业发展新技术，比如可以奖励对汽车行业有贡献或者在某些技术方面有突破的企业单位，分享、展示创新成果，实现科技政策和科技创新的深度融合，并不断的完善政策，完善反馈体系，发挥政策对发展新技术的推动力，创造出良好的汽车软件生态系统，以智能网联汽车带动智慧交通与智慧城市的建设发展。

从标准上建立解决共性问题的通用接口等规范，实现汽车软硬件产品的互联互通，避免各企业在通用标准化接口层面各自为战，倡导各企业在统一接口下做好自身产品的创新与研发，避免重复和碎片化投入，提高研发效率，推动我国智能网联汽车发展。

5 软件定义汽车典型应用场景

随着软件定义汽车典型应用场景的落地，用户将明显体验到汽车从交通工具向智能移动终端的转变。几十年前主要用高性能的底盘操稳与动力系统定义一台好车，几年前主要用智能化系统与智能交互满足终端用户的用车体验，未来将调度全车传感器与数据驱动方式定义智能移动终端。

汽车电子从无到有，如今不断深化到座舱、车控、底盘、动力等多个功能域为用户调用整车资源，为用户不断创造增值的用户体验，基于此，在服务提供上的功能分工与数据利用也会驱使行业分工出现变化。

首先，针对不同的场景服务，整车厂与供应商开启软硬解耦、软软解耦的开发方式，不同角色负责不同层级的软件开发，以满足用户对于应用场景快速迭代与多样化服务订阅的需求。然后，针对架构解耦暴露出来的数据信息，一方面可以形成数据闭环为用户带来个性化、便捷的用户体验，另一方面整车厂和第三方可以根据数据回馈不断优化产品，并且激发出依靠汽车数据衍生的产业发展。

软件定义汽车使得整车级场景智能化成为可能，以体验为中心满足用户个性化需求，真正实现千车千面、常用常新的驾乘体验。车辆作为移动的第三生活空间，在高算力芯片、人工智能、大数据、SOA、原子化服务等的加持下，向场景多元化发展，面对日新月异的用车环境，基于车辆的个性化体验更能得到用户的认可。

任何场景逻辑可以抽象为四个部分：场景感知、场景条件、场景交互、场景执行，这四个部分无一不依赖于车辆的能力。场景感知需要通过摄像头、语音模块、车辆信号、地理位置、天气、车内操作等智能识别场景；场景条件需要判断当前的车辆状态如档位、车速、天气、位置等信息确定是否具备执行场景的条件；场景交互是通过显示屏或语音进行场景运行请求、场景运行授权、场景运行倒计时、场景运行提示等；

场景执行即执行相关车辆行为，如空调、车窗、座椅、车灯、后视镜、行驶、泊入等。这些车辆能力需要以服务的形式暴露给应用层，车辆能力暴露的越多，实现场景越多，场景功能越丰富。

在智能场景中，车、云、人得到有机的结合，通过建立场景引擎，车辆可为用户开放空调、天窗、车窗、灯光、座椅、娱乐、资讯、出行等上百个功能的服务接口，供用户自由的排列组合；云端将生态信息、账户、用户画像、运营服务等内容串联起来，与车端数据进行融合打通，为用户提供增值服务；用户可通过手机或者车机对场景进行定义，从而建立基于自身习惯与喜好的智能化服务场景库。

下面我们将举一些典型应用场景。

5.1 智能交互应用

结合场景化功能引擎实现一键休憩服务。车主可以通过 APP，开启或关闭一键休憩指令，根据车主的习惯或设置自动调整车椅位置角度、车窗开度、车灯开关颜色亮度、遮阳窗等，不需要手动一一去调整，降低了操作的复杂度，大大提升了用户体验。在具体的实现中，应用开发者通过调用各原子服务 API 来实现不同的场景 APP，提升汽车应用开发的效率。类似的软件定义汽车的典型应用场景还有很多，想象空间很大。

5.2 用户自定义场景

以威马 W6 为例，用户只需进入车内，即可直接体验官方预设的九种场景模式：休息时刻、亲子空间、智能节能、性能模式、高速无忧、充电提醒、空气净化、影院模式和忏悔模式。用户也可根据个人用车习惯，通过威马智行 APP，开启自主编程操作，实现驾驶辅助、车窗、座椅、空调、驾驶模式、音乐、氛围灯等主被动软硬件模块的自由组合和设置，并根据自己的汽车偏好制作不同风格的场景卡。操作完成后，新添加的场景模式将根据用户设置的触发条件唤醒。

同样实现场景编辑的还有小鹏 P7 语音私人定制，小鹏 P7 可在手机 APP 定制模块中，针对一系列常用的功能设定快捷方式，可以让用户一步一步自由定制输入命令、执行功能、语音回馈等各项步骤，通过简单的组合实现一个专属于用户的一串动作。以专门针对洗车场景设定的私人定制模式为例，在准备洗车的时候，一句已设定好的话将会执行提醒天气、关闭车窗、关闭空调、关闭车顶、折叠后视镜、挂 N 档这一系列动作，实现了场景自主编辑与语音指令对场景的控制。

以联合汽车电子预约智能充电为例，由于不同驾驶员在不同场景下对于充电的需求不同，有的可能需要在尽量短的时间内完成尽量多的电能补充；有的需要充电尽量不影响电池寿命，从而延长电动车动力电池的使用年限；有的需要尽量在电费波谷期充电，从而减少充电的费用。预约智能充电功能可以让驾驶员在进行充电时，根据充电的实际需求和相关信息对比，选择四种模式：经济模式、健康模式、快充模式、正常模式。

⚫ 经济模式：根据客户的充电时间需求、电池状态、不同时段的电价等信息，通过软件计算，提供终端客户电费最低的充电选择；

⚫ 健康模式：根据客户的充电时间需求、电池状态等信息，通过软件计算，提供对动力电池最健康的充电选择；

⚫ 快充模式：根据客户的充电时间需求、电池状态等信息，通过软件计算，提供动力电池充电速率最快的充电选择；

⚫ 正常模式：根据客户的充电时间需求、电池状态等信息，提供电池管理系统标定好的充电选择 。

根据驾驶员在人机交互界面输入充电需求，车载电脑会根据动力电池的实际状态，通过预测估计算法，计算不同模式下的充电信息，展示给客户进行对比，告知客户不同充电模式下的收益，其包含：预计充电总费用、预计取车时间、预计动力电池延长的寿命（对比正常充电模式）、完成充电的电量（SOC）。

此外，车企在车联网平台的加持下，智能汽车可以实现动态的管理，在车主的意愿下，服务平台能够帮助车主实现车辆模式的转变，比如车辆长时间停放的场景，就可以从停放到共享的模式切换，智能汽车变成了一个会盈利的移动空间。

5.3 智能汽车应用商城

随着智能网联汽车的快速推广，车机端所需要的应用程序开发及管理成为了一个新的业务增长点，通过建立企业和品牌专用的应用商城，为厂家、合作企业、三方软件的开发者提供一个方便又高效的应用推广、销售、管理平台，能够有效管理各类应用，为车主用户提供方便，同时也在一定程度上促进了智能汽车品牌的科技卖点。

未来汽车应用商城的发展生态有望采用类似手机产业的逻辑，按照开发的应用程序类型，汽车应用商城将应用进行分类，开发者在发布新的应用程序时，需要选择应用程序所属的分类，同时管理员可以调整应用程序的分类。应用分类包括生活、信息、地图、音乐、视频、图像、资讯、商务、游戏等 APP。在运作模式方面也可以采用热门应用软件、最新发布软件、应用软件排行榜、应用下载及社交应用评论等方式管理，打造全产业链生态伙伴平台共同开发、利益共享的盈利模式。

苹果通过软硬一体化发展策略，构建了“终端+软件+服务”的全产业链，持续扩展增值服务。苹果手机基于流畅 iOS 系统，突破传统只靠销售终端获得盈利的商业模式，通过 iTunes 和 AppStore 等为用户持续输送优质的服务和内容，实现场景细分、高度集成和个性化，改变消费者以往从搜索获取服务的习惯，持续扩展增值服务的边界。类比苹果，特斯拉打造了硬件平台（汽车）、超级充电服务（基础服务）、应用软件商店（特斯拉 APP）及娱乐服务应用等，加速软件服务生态付费模式，“类苹果模式”在汽车产业中开始创新发展。

5.4 智能驾控应用

出行场景和生活场景联接将提升车主的用户体验。在智能互联时代，人车关系的建立依赖基础数据的获取，车辆通过智能获取用户生活数据、出行数据，实现对用户的洞察，从单纯的出行工具向在线生活工具进化，通过场景化的服务准确预判用户需求，满足用户个性化需求。而智能汽车网络（车辆、道路、网络、云端）的应用将不断进行数据驱动自学习，完善用户体验。车辆行驶的道路越多，越能记忆更多的道路信息，特别是危险道路信息，通过数量巨大的智能汽车对道路信息的不断学习，云端的智能 AI 算法会按照学习数据生成动态的汽车能力，并通过网络分发给还未有大量道路行驶里程的新车，新车一跃获得了高智能的自动驾驶能力。车辆可不断适应环境和人，实现不断进化，且通过对道路信息的获取，可实现更多功能的应用。

⚫ 预测性经济车速规划服务应用场景

预测性经济车速规划功能是借助高精度地图和定位系统，提前获知前方区域路况和交通信息，以节能与驾驶时间综合最优作为目标，驾驶性和安全性作为约束，利用动态规划算法规划前方车速曲线。该功能对象为车辆纵向动力学模型，通过控制动力源扭矩得到最优的车速曲线。

该功能可适配多种动力结构和系统配置，应用场景广泛，包含前方有限速区、弯道、拥堵、到达目的地等均可适用，并且可针对驾驶员风格和行驶工况进行自适应优化，构筑更贴合驾驶员意图的车速曲线规划。行车场景下主要结合自车车速、平均车速、前方限速信息、前方道路坡度、前方道路曲率、自车定位、驾驶员允许功能激活按键及前方红绿灯信息等综合要素判断，在车机界面上实时显示一条当前定位的优化车速区间颜色带，驾驶员可通过观察当前车速落在颜色带的区域判断车辆需要加速或者减速，从而辅助驾驶员在更加经济的车速段内运行，并且可与 ACC 结合，实现更加智能和安全的 PCC 功能。通过该种服务应用可以提供更加智能安全以及行车经济性更好的驾驶指导建议，进而有效节省驾驶成本。

⚫ 预测性续驶里程功能应用场景

目前电池储能技术所限和公共充电设施不完善，车主在驾驶时会面临“里程焦虑”，而电池续航里程估算的不准确，更是加剧了这种焦虑。预测性续航里程功能，充分利用智能网联车辆可以获取环境和驾驶员信息的优势，全面考虑了实际道路交通环境以及驾驶员驾驶风格和习惯对续航里程的影响，例如环境温度对电池的影响，电池使用状态对电池剩余电量的影响，驾驶员驾驶风格对驱动能耗的影响等，结合车辆工作状态信息及车辆动力学模型预测车辆在未来路程中的能量消耗，并基于精准的电池状态估计算法得到车辆到达导驶终点时可能的 SOC 及剩余续驶里程，并根据估计结果进行充电推荐。从而大大缓解了车主的“里程焦虑”的问题，改善了电动车的使用体验。

⚫ 预测性滑行回收功能应用场景

预测性滑行回收功能是基于智能网联信息的减速场景驾驶辅助功能。其借由智能网联系统获取前方道路和车辆信息，在前方有减速需求时通过 HMI 或提示音提醒驾驶员松开踏板，并规划滑行车速轨迹，使车辆在滑行过程能安全舒适的减速到需求的目标车速，且同时回收部分动能。

该功能可适配多种动力结构和系统配置，应用场景广泛，包含前方有限速区、弯道、拥堵、到达目的地等均可适用，并且可针对驾驶员风格和行驶工况进行自适应优化，构筑更贴合驾驶员意图的减速策略。该功能主要结合行车场景下的车速服务、油门踏板服务、制动踏板服务、前方限速信息服务、前方道路坡度服务、前方道路曲率服务、自车定位服务、驾驶员允许功能激活按键服务、电机扭矩及限值服务、电机转速服务、前车信息及前方红绿灯信息等因素，规划滑行车速轨迹，提示驾驶员松踏板，将车速滑行减速至目标车速，包含与前车保持距离、限速区减速至目标车速、入弯降速、减速通过红绿灯等不同场景。

在减速的过程中能够有效回收动能，可以提升续航里程。且由于有效减少了操作制动踏板频次，零部件磨损得到缓解，车辆维护成本有所下降。在驾驶感受方面，预测性滑行回收功能很好的缓解了驾驶员的关注焦虑，驾驶员无需在减速过程中持续关注自车车速是否超出限速车速值，仅需听从提醒松踏板指令，便可将车辆安全的减速到所需车速范围。

5.5 智能底盘驾乘新体验

智能底盘具备大量传感器，基于传感器信息，可以学习车辆当前运动工况，同时由于智能底盘控制自由度多，尤其是针对具备分布式转向、分布式驱动、分布式功能的底盘，每个角模块都可以独立调整，可以提供更多的传感器信息。基于识别的运动工况，通过软件优化底盘控制，深度协同底盘系统横纵垂向，保证整车车身始终保持在平稳状态，提升驾乘舒适性，给驾驶员和乘客打造一个更舒适移动的空间。

驾驶员通过加速踏板、制动踏板、方向盘实现对底盘系统的控制，智能底盘系统可以直接获取驾驶员的输入，软件可以基于驾驶员的驾驶数据进行驾驶风格分析，自适应的调整智能底盘的驾驶响应。与传统底盘系统响应单一、性能单一相比，智能底盘通过学习不同驾驶员的驾驶风格，提供更符合驾驶员心理预期的驾驶体验。同一个底盘系统，不同驾驶员驾驶，底盘系统都可以表现出不同风格，真正实现千人千面的驾驶体验。

在软件的帮助下，智能底盘除了创造更多人性化外，还可以增加更多的驾驶可能，提升驾驶乐趣。

⚫ **坦克掉头：**在装有分布式驱动的汽车底盘上，让车辆近乎原地转向的方式来掉头。通过软件控制汽车左侧车轮和右侧车轮朝相反方向转动，达到缩小转弯调头的半径，确保在非常窄的路面能调转方向，进一步增强了汽车的机动性、灵活性和越野能力。

⚫ **汽车跳舞：**在装有主动悬架的汽车上，通过软件控制汽车悬架有节奏的升降，达到跳舞的效果，观赏感十足。

⚫ **汽车 90°横移：**在机械允许车轮旋转 90°的前提下，通过软件控制 4 个车轮旋转90°，实现侧向移动。车辆运动方向和车身方向垂直，驾驶乐趣十足。

通过软件定义汽车的智能底盘可为用户带来四大体验：

⚫ **个性化体验：**在 SOA 和敏捷开发技术支持下，底盘域可根据终端用户习惯提供个性化的定制服务，满足差异化和个性化体验。如智能悬架系统 HMI 具备运动、舒适、标准、越野、雪地等多种供选择的模式，车身高度具备手动调节功能，供终端用户根据驾驶环境和个人需求设置。

⚫ **高性能体验：**伴随着汽车集中式电子电气架构的逐步成熟、底盘各个系统的紧密关联，动态响应更加精准和迅速，可提供更优质的高性能驾乘体验。如智能悬架系统能够精准地感知车辆状态和路面信息，并结合高精度感知层信息自动调整悬架高度、刚度和阻尼，大幅度提高车辆操稳和舒适性，为终端用户提供高性能的用车体检。

⚫ **可成长体验：**利用深度学习算法和 OTA 等技术，底盘域系统具备自学习能力并支持 OTA 终身服务升级，使得底盘域系统具备自学习和可成长的功能体验。如智能悬架系统能学习用户的驾驶习惯，并合理调节出最适合用户的悬架控制策略。

⚫ **高安全体验：**汽车行业各项强标逐渐推出，功能安全 ISO26262、预期功能安全ISO21448 和信息安全 ISO SAE21434 成为汽车必备的多重安全保障，为底盘域系统提供更高安全的用车体验。

5.6 基于数据的个性化应用

软件定义的前提是数字化，需要能提前获取相对应的数据。在万物互联的趋势下，可将车辆数据、用户数据、外联生态数据、交通数据等进行收集，通过 AI 算法进行处理，建立基于账户的用户画像。

在处理的过程中，车辆可以提供车辆行驶信息、各传感器数据等，同时还可以收集用户对车辆的操作习惯等数据信息，生态可以提供天气、餐饮娱乐等数据信息，通过云平台连接的交通数据可提供路况等信息。将以上信息汇总到算法模型中，通过筛选去重融合等处理方式，建立用户画像，判断用户的需求和意图。在长期的使用过程中，数据处理中心还可根据更完善的数据修补用户画像，实现数据闭环，为用户提供最贴切的符合用户特征的个性化服务，进而实现基于数据回馈的服务成长。

示例：

用户李先生是城市里常见的上班族，他喜欢早晨的清爽空气，于是经常在上班路上将车窗开启 25%，然后到公司后把车窗在关上以免天气突然下雨。用户刘先生也是城市里的上班族，但是他不喜欢开窗，因为担心早高峰的尾气飘入车窗，影响身体健康。

这里面我们提到“影子软件”。通过影子模式可获取用户的开窗数据和开窗习惯数据，同时进行打包上传，按照通讯协议进行加密发送，最终在云端进行解密接收。然后进行大数据的分析，最后根据某一类用户的特性，进行软件调优，最终通过影子软件释放给用户，但是影子软件是在后台默默运行的，并不直接代替用户操作。然后，通过评分模块将软件估计跟用户一致的部分给予高分，将用户跟软件影子评估不一致的给予低分，并且将低分软件上传至系统，进行多轮的迭代。最终将高分的软件，真正的推送给用户代替之前的软件。

5.7 衍生更多后市场应用场景

软件定义汽车背景下，基于用户数据、车辆数据、场景数据的出行服务新兴模式也将获得高速发展，通过车辆数据智能化存储及应用可以实现人-车-家生活服务连接，车辆保险理赔等后市场服务，及智慧出行共享等带来创新应用场景。

随着 V2X 技术的发展，汽车的控制功能不仅限于汽车本身，汽车实现对智能家居如冰箱、电视、洗衣机、空调等控制，反过来车端部分功能也能被家居控制，形成人-车-家-可穿戴设备等万物互联的产业生态。如小鹏 P7 车型当前与小米合作，采用车载米家系统，与智能家居相连，还可通过智能家居了解车辆信息，甚至可实现预约充电。而威马 EX-6 采用米家系统可通过小爱音箱查询车辆电量及车门、车窗、天窗和后备箱是否关好，远程打开空调，通过车机系统控制米家空调、屋灯、净化器、扫地机器人、插座等产品。

当前，在整车厂内部、汽车或交通相关科研机构、部分大数据公司都在积极挖掘车联网数据的价值，以数据驱动的新商业模式开始出现。以 UBI 车险为例，整车厂联合互联网数据分析公司、保险公司，基于 CAN 总线数据判断车主驾驶行为、驾驶习惯、事故发生时的状态等，协助保险公司量化保费、调查事故。未来，结合车联网大数据，还有望看到更多实用有趣的车联网应用服务。以道路维修保养为例，在全国范围内行驶的智能汽车相当于高精度的传感器，通过车辆行驶相关环境采集数据，可发现道路设施的异常点，在出现重大问题之前及时修补。还可基于车辆传感器采集的数据，提供区域性天气变化、危险事故预警等。

6 软件定义汽车落地实践案例

6.1 敏捷开发流程方法方面

一汽集团：

一汽集团在构建整车 SOA 架构平台时，从端到端的车云一体化层面出发，充分执行软硬解耦的开发流程，对合作伙伴的资源进行生态聚合。

软件方面在基于满足用户需求的前提下不断提取和设计全新的应用功能，自上而下对应用进行定义和设计。

硬件方面在硬件资源支撑的情况下，自下而上充分对基础服务进行分解来，设计为用户提供全新功能的应用软件。

在实际开发过程中，保证技术先进性的前提下，无论是硬件、软件、人力等各个方面都进行了全方位的平衡，采用了全新的前、中、后台互相配合的敏捷开发模式，在公共基础平台的配合下明确需求团队和实现团队的强交互，确保开发团队在 SOA 设计思想指导下能够从用户角度出发进行设计开发，从而保证质量。

一汽在打造全新的 SOA 架构平台的同时，从后期运营和运维的角度出发，着手打造“开发者平台”突破传统汽车的局限，打通汽车上万个零部件和应用软件之间的协同，让汽车成为移动的智能终端，分享软硬件底座、数据资源、出行场景，实现与生态伙伴的共赢发展，实现真正意义上的“软件定义汽车”。

MBSE 是方法学，亦是相关流程、方法和工具的集合。MBSE 方法结合系统工程思想，通过模型贯穿系统全生命周期全流程，其中模型是整个 MBSE 方法实现的核心，也是 MBSE 方法在系统研发中实现高效研发、高质量设计的基础，还是系统研发过程中系统技术和工程经验的积累和体现，是企业的核心资产。

一汽在实践过程中基于 MBSE 的开发方式，建立了强追溯关联的工具链体系，采用了UML 建模方法和建模工具完成了 SOA 架构设计工作，输出标准化的 ARXML 模型文件。

一汽采用敏捷开发方法，以功能域为单位成立了自组织、跨职能团队，明确以人为本，面对面交流的开发方式，基于互相信任的前提，敏捷提倡自治的全功能团队。全功能团队中每个角色都更容易从全局视角去思考任务，避免了视角割裂和协作障碍。

轻量级的文档策略有助于团队高质量交付可工作的软件。达到主动拥抱变化，及时响应，持续交付的开发目标。

6.2 SOA 软件架构设计方面

联合汽车电子：

在某客户项目中，整车厂规划基于新一代中央域控+区域接入的电子电气架构实现整车功能服务化，联合电子应用业务驱动型开发方法帮助整车厂完成整车服务架构设计。

业务驱动型指从业务用例出发，以服务为导向，正向设计 SOA 汽车软件的开发方法。在设计过程中，通过“业务过程分析”、“服务操作分析”、“候选服务分析”三个步骤，解决“应该构建哪些服务？”、“每个服务应该封装什么逻辑？”两个核心问题。

以雨刮子系统为例，客户提出雨刮低速、雨刮高速、雨刮点动等多个场景用例，分析过程如下：

⚫ 业务过程分析：

采用用例驱动的方法来分析业务需求和过程。用例驱动指从用户使用的角度而非开发人员的角度考量功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和服务操作之间清晰的追溯关系，为抽象和封装服务提供充足的语境信息。

⚫ 服务操作分析：

服务封装的业务逻辑，由服务操作实现。服务操作代表了服务所执行的特定动作，可类比软件中的方法或函数。

⚫ 候选服务分析：

“SOA 汽车软件分层模型”为候选服务分析提供了有价值的参考。根据重用性和自主性的面向服务设计原则，参考三层模型设计元服务和基础服务。对元服务和基础服务的设计，SOA 鼓励即使没有立即重用的要求，也要根据服务导向的设计原则促进重用，因此潜在的重用也要考虑在内。通过良好的 SOA 设计，当业务用例增加，或原有业务用例发生变更时，良好的基础服务和元服务设计，保证了重用性和较少的软件变更，从而实现更快速高效的功能迭代和清晰明确的版本管理。

⚫ 服务接口设计：

服务接口设计是服务架构设计过程中的重要一环，在候选服务分析完成后，大致暴露的服务接口会被确定，服务接口决定了服务之间的动态数据交互，决定了业务逻辑的行为和功能，需要在迭代中不断完善，反复更新。

此处，值得一提的是原子服务和设备抽象服务接口的设计和定义), 设备抽象服务解决电子电气架构中不同执行器/传感器暴露统一的接口问题，原子服务则对传感/执行器的语义做统一的规划和定义。联合电子将对原子服务和设备抽象服务接口的设计定义为平台驱动型(由下至上)设计方法下的工作产出。

当前，软件定义汽车工作组发布的 API 参考文档为定义智能汽车软硬件接口标准化的规范性文件。工作组通过对 API 接口的标准化定义，为各领域带来全新的体验，联合电子也正在参与 API 接口定义工作，并在项目上进行应用实践。

⚫ 服务部署：

在 SOA 软件开发过程中，服务的部署涉及到整车电子电气架构的信号矩阵。对于业务驱动型分析方法，功能需求导向是设计原则，对于 Tier1 熟知的业务逻辑领域，推荐Tier1 提供具体服务模块的部署信息， 这些部署信息作为正向设计的产物，会体现在后续的整车厂整车软件架构之中，是整车厂设计整车信号通讯矩阵不可或缺的重要一环。

在 SOA 软件架构下，整车厂整体把握软件架构的总集成方，Tier1 作为各个业务领域(车控、底盘、动力、高级辅助驾驶系统等)的合作伙伴，将作为组件负责人向整车厂提供对应的架构描述文档，最终系统级的架构设计文档由整车厂输出，并结合软件模块和基础软件部分，完成各个子系统的集成。

联合电子认为， 面向服务化的软件架构，未来将促进多个供应商体系下软件集成互相协同。在这样的方案里， Tier1 会充当 Component Designer 的角色，是Component 的“专家”，对组件内部的架构设计和业务逻辑有着主导权；组件与组件之间的接口则由整车厂来承担和定义，Tier1/软件供应商在严格遵照该定义后，将软件架构和软件模块以固定的形式持续向整车厂推送。未来逐步迭代和成熟的接口也将是软件定义汽车的标准接口，其一定程度的抽象可以形成行业内的标准规范。

6.3 SOA 服务化设计、开发与测试验证

威马汽车：

威马汽车将汽车看做万物互联中智慧城市分支的一部分，在设计时将中央大脑作为车辆与外界互联的网关，负责提供车辆信息、车辆控制等服务。威马汽车在向 SOA 架构的转型中不仅考虑车内服务的互相调用，还考虑将服务提供给移动设备、智能穿戴、第三方 APP、路端设施和其他车辆，在满足安全性的前提下让威马汽车更加符合互联的需求。

威马汽车对 SOA 理念的首次尝试是座舱系统“威马快捷”APP 的开发：将座舱可实现的车辆控制功能（车窗控制，灯光控制，座椅控制，空调控制等）在 APP 端包装为一个个服务元素，用户可创建卡片自由组合编辑这些服务元素。激活卡片后，座舱系统依次下发卡片中服务对应的控制信号，呈现出独特的场景控制，满足用户的个性化需求。这种方式是将 APP 模拟为一个服务器，为用户呈现可提供的服务，同时将这些服务的执行命令进行后续的下发。

第二次应用是出于对座舱软件优化的目的：座舱硬件和通信的变化，以及关联零部件方案的变更，往往都会影响到座舱应用层软件的变更。同样的功能，在不同的项目中，应用层都需要重新开发调整。出于减少应用层开发工作量，和增加应用层可移植性的目的，在应用层和通讯层之间，构建一个 S2S 模块，将整车相关的信号（车辆控制信号，车辆设置信号，车辆状态信号，车辆报警信号）按照 SOME/IP 的标准，封装为一个个服务，应用层直接调用相关的服务接口，信号的控制逻辑由 S2S 模块来传递执行。

这种方式在一定程度上实现了应用层通讯逻辑的解耦，避免了一个功能点的变更，带动多个应用变更的情况：比如车窗纹波防夹和霍尔防夹方案的选择，影响座舱车辆控制、语音控制、车辆状态显示等多个应用的软件变更，通过服务化，将差异化的信号定义为标准化的服务接口，增加了应用层软件的适配性和可移植性。

随着中央计算平台+区域网关的架构方案在项目中应用，威马汽车目前正处于第三阶段的 SOA 工作：整车级的服务定义及软件开发。整车级的服务定义，依托业内统一的标准，才能更大程度发挥出优势。现阶段，威马汽车参照中汽协软件定义汽车工作组发布的《原子服务 API 参考》，进行车身、热管理、动力、能量管理、驾驶域、人机交互六个部分的服务接口定义。

服务接口的定义原则，主要就是解耦和稳定。从请求到执行，再到状态改变，定义为不同的服务接口，各个接口在功能层面上是互相联系的，但从服务的角度看，每个接口都是独立存在的，请求不关心执行的逻辑，执行不追溯需求的来源，也不跟踪状态的变化，状态仅是当前最新信息的体现。

示例：车窗服务

每一个车窗状态作为一个服务，服务接口包含车窗解闭锁控制、锁状态信息、开度控制及状态信息、升降控制、以及学习状态、防夹状态等信息。车窗的相关信息由区域控制器传输给中央服务器；对于需求方，控制请求的下发和状态的获取全部面向中央服务器，不与区域控制器直接对接，由中央服务器进行优先级和前置条件的判断，并将控制信息传递给区域控制器。

软件定义汽车的定义中，都属于原子服务的范畴，整车厂和第三方应用可以基于这些原子服务，搭配出更加满足用户需求的组合服务和应用服务，提升产品的竞争力。

岚图汽车：

传统智能驾驶辅助系统的功能开发都是通过“定制开发的软件+特定硬件”的方式实现并交付给整车厂，软件和硬件之间是紧耦合的。程序代码根据需求是固定式的，后期如果需要系统升级，软件程序将重新编写。同一个功能在不同的车型搭载时，因为硬件不同，软件无法复用，软件灵活性差；另外，功能软件移植到新的硬件时，需要重复的设计、开发、测试。耗费大量的重复工时，影响到功能的迭代周期。随着用户需求的日益增加，这种开发方式远远满足不了用户的需求。

在软件定义汽车的背景下，面向服务的软件架构能从根本上解决了这个问题。通过全新的电子电气架构实现软硬件解耦，产生出硬件抽象层，将原有的硬件资源抽象成为一个共享的资源，实现整车的信息共享，供其他功能调用，从而演变出新的功能，满足客户不断增长的需求。

基于整车 SOA 软件分层架构，根据驾驶辅助系统的特性，岚图汽车基础平台架构将整车应用软件细分为云端控制的车队管理层、本地功能控制的功能管理层、用于功能实现的规划控制层、用于获取环境感知的传感器感知层、控制执行的执行器层。该分层架构可以实现各层级之间软件模块解耦，其需要遵循以下规则：上层服务可以依次或跨层依赖下层服务；不允许下层服务依赖上层服务，实现本层的软件模块执行。

将基于 SOA 的软件开发方法以驾驶辅助系统 ICA 为例阐述其实现过程。

⚫ ICA 需求场景流程分析

用户期望车辆能分担驾驶负担，降低用户高速使用场景下频繁的纠正方向盘、控制安全距离及车速频率。

⚫ ICA 服务与接口定义

根据驾驶辅助系统的 SOA 软件分层策略，将初始服务操作提炼的服务如下：

⚫ ICA 服务部署及接口映射

将服务实例化的服务映射到具体的运行环境中。基于集中式的电子电气架构拓扑，将HMI 相关的服务部署在 HMI 处理器上，将算力要求较高的服务部署在驾驶辅助系统SOC 上，将规划控制及 CAN 交互的服务部署在驾驶辅助系统 MCU 上。

面向 SOA 服务的测试实践：

在 SOA 开发实现的过程中，V 模型右侧的测试验证较传统整车架构也有了革命性的变化。主要体现在通信网络增多、链路复杂深入。

在 SOA 软件架构中，软件从上而下，分成了不同的层级和模块。可以看出功能较传统架构实现链路上复杂了，这也就对功能测试的问题分析和定位，提出了更多的困难和挑战。

不同的供应商提供不同的软件模块和接口，整车厂主导集成。测试过程中，对于跨越多个软件模块进行传输的数据对象，更难在实际的问题中进行问题模块定位。面对此类问题，整车厂需要配置人员能调动多个供应商进行问题解析，快速识别问题根源。

同时要求软件供应商做好各阶段的基础的软件模块单元测试和功能测试至关重要。对于传统嵌入式 ECU，这一部分整车厂基本没有介入，在 SOA 开发过程中容易疏漏，需要管控到位。

面向 SOA 服务的测试的通信协议目前主要为 SOME/IP 和 DDS。以 SOME/IP 报文为例，测试问题的报文定位不仅体现在特定服务中数据对象是否正确发送，还需要往前一步分析服务数据对象发送的前提是否满足。因此问题的分析和定位不仅要梳理数据对象的服务器是否正确发送 Offer 和服务内容，同时需要检查数据对象的客户端是否正确订阅。以太网的点对点数据传输，使得数据分析量也成多倍增加，如原来的一条CAN 报文，可能会变成多条 Event 报文进行传输。测试工作也会相应的增加。

面向 SOA 服务的测试完整的测试内容涉及物理层、TCP/IP 协议、应用层服务等。其中，应用层服务直接影响整车放定义的相关功能。针对应用层服务主要有一致性测试和性能相关测试。

⚫ 一致性测试

主要测试车辆的服务内容是否都按照通信矩阵定义实现。结合 SOME/IP 协议标准和整车厂自定义内容，对控制器的服务发现行为、服务中具体的方法、请求和事件进行全方位测试，确保服务端和客户端的行为都同步实现和满足矩阵要求。

⚫ 性能测试

主要测试控制器的报文处理能力，如：收到多条请求是否可以实时处理，不出现报文丢失，并驱动对应负载；收到服务的 Offer 报文后，客户端是否可以快速订阅；收到服务的订阅后，服务端是否可以快速处理并发送对应的 Event。

基于 SOA 服务的域控制器集成了更强的硬件，在软件层面可同时具备传统多个控制器的功能，如车身、舒适和动力。软件的高度集成带来了更多的产品问题，敏捷开发使得域控制器的版本释放变得更加频繁。按照整车厂传统的只在车型大阶段安排测试已经变得不再适应，需要安排不同层级的域控制器通信与功能测试，才能更好的控制器产品质量。

华人运通：

华人运通根据整车软件定义提出了自下而上的六层软件架构体系。其中第三层在设备抽象层的基础上提出设备树概念，设备树可以理解为基于设备抽象层的扩展应用，丰富了设备抽象的应用场景。

⚫ 设备树概念

设备树一词来源于计算机行业，是指系统中每个设备都有相应的节点来对应，所有的这些设备形成了一个树状结构用来描述设备的硬件信息。同样，基于整车设备抽象层也可以搭建整车上的设备树用于显示整车所有设备信息以及相关状态。

⚫ 设备树范围

由于设备抽象层的出现，整车硬件设备抽象化，对于设备抽象层之上可以获取所有设备的相关状态信息用于显示和设备管理。将设备抽象层部署在 Zonal 控制器和中央计算大脑中，抽象出整车设备包括：

1. 一级/二级控制器

2. ZCU/一级/二级 IO 开关

3. ZCU/一级/二级传感器

4. ZCU/一级/二级执行器

对于整车来说，上述任何设备是否安装在车上都可以从设备树信息显示中查看。设备树除了显示设备信息外，还可以显示设备状态。

⚫ 设备树作用及价值

通过设备树，整车厂可以对整车设备以及设备之间的关系进行查看。任何设备的信息包括生产日期、软硬件版本、供应商名称等发生任何变化，通过设备树都可以查看到。同时华人运通还在研究抽象设备即插即用，配合设备树的显示，设备树可以动态显示即插即用设备。另外，基于设备树的概念，华人运通同时提出了基于设备抽象创建整车设备诊断的方案。即通过设备抽象层，实时获取设备树上所有控制器、IO 开关、传感器和执行器的状态信息。

通过这样的方式，设备树可以实时上报任意设备的故障信息以及对应发生故障时间戳，再通过上传这类信息至后台存储，为问题分析和数据定位提供了强有力的支持。

同时，车辆下线的过程中车辆可以通过车辆本身的设备树完成相应的设备装配检查，真正意义上做到自动化的 EOL 下线检查。每次车辆上电过程，设备树也会进行设备管理和自检，相当于车辆的内嵌式诊断仪。

对于整车厂，无需每个项目针对不同配置进行定制化地开发诊断仪，设备树服务可根据不同车型进行配置，提升了车辆检查的效率同时也简化了相应流程。由此看来，设备树的提出对于车辆整个生命周期都有较深远的意义和影响。

中汽创智：

从座舱软件整体架构的角度来看，中汽创智认为在方案实施时，既要在系统上满足整车 SOA 架构的要求，又要充分利用座舱现有操作系统成熟稳定的技术方案和平台优势，目前座舱操作系统以 QNX+Android 或 Linux+Android 为主，相对于 AP 平台，Android 平台的执行管理、log 系统、持续化存储、升级等功能模块在消费电子领域也经得到了充分的使用验证。同时值得注意的是，Android 系统本身也是符合SOA 架构理念的，（android 采用了 AIDL（Android Interface Definition Language Android 接口定义语言）和 HIDL（HAL interface definition language 硬件抽象层接口定义语言）来做接口约束定义，服务需要注册到 ServiceManager 中（SOA 中的服务注册入口），通过 ServiceManager 的客户端代理获取服务本地接口再进行远端调用）。因此我们更建议以 Android 现有架构框架为主，在系统上满足整车 SOA 的需求为架构设计目标，实践总结如下：

⚫ 座舱域能够在整车系统层面满足 SOA 架构的要求，能够将其他域需要的服务提供出来，同时能够通过消费或组合其自身的服务来构建不同的应用功能；

⚫ IDL 工具能够尽可能支持不同的开发语言，能够充分发挥 SOA 架构应对分布式系统的优势，各个系统在调用时仅需关注接口约束，服务的实现尽可能发挥特定平台的优势；

⚫ 考虑到中央计算单元会采用 AP 架构，整车也大概率会通过 ARXML 做整车机接口定义，我们在选择 IDL 的时候需要考虑和 ARXML 的兼容和转换；

⚫ 充分利用遗留代码，要充分考虑代码的复用性及可测试性。

在服务的实现上，中汽创智借鉴了 Clean Architecture 的设计理念：

⚫ 单一的依赖方向，从软件的变化度思考，在特定领域场景，数据模型是基本不会发生变化的，所以我们将其放到整个依赖的核心，围绕数据模型，会产生一系列的功能用例（如空调的风量值这是一个数据，围绕这个值会产生上调风量，下调风量等功能用例），功能用例的集合就是服务实现；

⚫ 将所有外部依赖，诸如系统接口，数据以及数据访问，所有的支持性框架代码都放到外部，以依赖注入的方式注入的服务实现层，这样一来，数据模型层，用例层，服务实现层就只和语言相关，可以比较容易的在不同的系统上移植；

⚫ 具备良好的可测试性，每一层都有清晰的边界，由于依赖的单向性，使得可以比较容易的 mock 各层的依赖，这样比较容易构建单元测试的用例，也便于做打桩测试。

福瑞泰克：

福瑞泰克智能系统有限公司（Freetech）推出了面向 ADAS/AD 产品落地的 SOA 软件中间件产品 FTZen，如下图所示：

图 6-10 FTZen 设计框架

根据软硬件分层解耦的思想，FTZen 在整体架构中扮演了向下屏蔽硬件、外部设备和驱动，向上服务/应用层提供统一的接口，让应用开发更有效快速的进行，FTZen 具有如下特点：

⚫ 可以适配不同芯片架构和操作系统的硬件平台。FTZen 支持主流的异构多核计算平台，并可以支持多路外部传感器和外部设备，比如：多路摄像头、毫米波雷达、激光雷达、高精地图等接入。同时部署 FTZen 的控制器具有和其他 ECU 进行符合SOA 的标准协议通信的能力；

⚫ 支持执行管理统一调度多应用的部署，支持信息安全基础设施（加解密、身份认证)和 OTA 升级服务；

⚫ 通信管理模块能够支持和兼容多种通信协议，除了动态服务发现之外，还支持自适应的传输层：通过当前通信节点的位置，判断参与者是进程内、进程间还是跨芯片，从而可以做到自动选择传输层。对于应用层来说，不需要关心传输层，从而获得无感且最优的传输性能；

⚫ 向上层应用提供标准统一的接口封装，支持将算法、功能应用以及基础平台管理通过 SOA 服务提供，支持灵活跨车型、跨平台的应用开发模式；

⚫ 通过 SOA 架构的服务接口定义和子系统的划分，Freetech 设计了适用 ADAS/AD产品的标准原子服务定义，根据子系统划分的设计为：数据服务子系统、感知子系统、融合子系统、预测子系统、决策规划子系统、控制子系统。

其中，数据服务子系统定义相关传感器、外设等接入的数据服务化接口；感知子系统定义跟视觉感知和雷达/激光雷达感知相关的感知检测处理等标准接口；融合子系统定义各种传感器感知检测的目标、车道线、可行驶区域等数据融合以及定位融合的服务标准接口；预测子系统定义目标选择、目标行为和轨迹预测等相关服务标准接口；决策子系统定义跟行为决策、路径规划相关服务标准接口；控制子系统定义跟执行器控制相关服务标准接口。这些原子服务定义满足几个特性：

a) 服务接口重用性：跨产品和项目复用原子服务接口

b) 服务接口移植性：在不同的硬件芯片平台上进行移植

c) 服务接口可维护性：公司标准定义，原子服务接口统一维护

基于 FTZen 的标准原子服务定义，福瑞泰克可以在应用层进行软件架构设计和开发，通过服务组合的方式进行不同应用的系统化方案部署。福瑞泰克可以作为整体的系统解决方案提供商面向各个整车厂提供主动安全报警类、行车类、泊车类等相关功能。

同时，Freetech 域控制器 ADC 产品参考中汽协《SDV 原子服务 API 规范》，定义了面向上层应用算法的接口，ADC 通过虚拟服务总线进行服务互连，实现 APP 之间、核间、芯片间以及关联控制器之间进行标准服务通信。

FTZen 利用 SOME/IP、DDS，以及共享内存（私有协议）等技术实现标准服务接口，而上层应用、算法以及功能通过原子服务进行应用组合并向整车厂提供整车功能。通过软件平台架构定义的原子服务接口和子系统，如数据服务子系统、感知子系统、融合子系统、预测子系统、决策子系统以及控制子系统，向整车厂提供了面向ADAS/AD 的几大类功能：

a． 主动安全功能，比如：FCW/AEB、LKA、FCTA/RCTA 等；

b． 舒适行车功能，比如：ACC、PA、HWA、NOA 等；

c． 泊车功能，比如：RPA、APA、AVM 等。

Freetech 借助自研的中间件 FTZen 和基于 SOA 的软件平台化架构方案，通过服务定义将不同的硬件芯片平台、操作系统、外设传感器数据等进行抽象封装，通过服务化的方式进行交互，使得算法应用开发者更聚焦在本身的业务逻辑设计开发上，而标准的原子服务接口定义使服务移植和复用更加灵活，可以让上层应用迭代更新无感化，通过主流的 OTA 方案进行应用灵活升级。

亿凯科技：

围绕着“软件定义汽车”和“SOA”的概念，上海亿凯科技有限公司依托车用软件技术积累，打造“虚拟车辆软件台架”。该平台可以提供低成本的成熟的整车台架虚拟环境，完善的虚拟原子层服务和设备抽象层的服务，还有自定义的开放式符合软件定义汽车服务接口。

目前 Tier1 软件设计和开发方法多种多样，有手写代码的，有模型开发的。验证方法也多种多样，模型开发用 MIL,SIL,PIL,HIL；手写的用静态测试，单元覆盖测试，PIL,HIL；但最后都避免不了在装车的时候发生各种意外，修正 BUG。根本原因是没有在装车之前提供一个环境对其单独的服务或单独控制器进行测试。亿凯公司自研的虚拟车辆软件台架填补了此类虚拟软件的空白。可以针对下列痛点并以此为目标：

⚫ 只有在真实的车辆或台架上才能做所有控制器联合调试；

⚫ 只有在项目最后的阶段才能做联合调试，整车厂很难保证按时保质的完成项目；

⚫ 单独的小的供应商难以承受联合调试的成本；

⚫ 在联合调试中，信号抓取，回溯，分析困难；

⚫ 在联合调试中，完整测试用例很难自动完成，极限测试用例基本不能做。

借助软件定义汽车工作组发布的标准接口，各个服务之间交互的透明性。

6.4 面向 SOA 架构的中央计算平台

威马汽车：

威马作为造车新势力，始终走在新时代汽车的前沿，致力于为用户提供不断进化能力以及更加愉悦体验的车辆，为迎接下一步的挑战，威马基于现有的域控制平台和需求打造集中式电子电气架构的整车控制器中央计算硬件平台。

中央计算平台作为下一代整车控制系统的核心平台，采用集中式电子电气架构的中央域控制器+标准化 VIU 设计，致力于为整车的 SOA 的实现提供控制域的硬件基础，集成了整车动力控制、数据算法集成、CAN/以太网的数据路由，智能网关、车身电气控制、视觉感知、语音交互以及图像显示等功能，并实现了高度国产化，成本进一步得到优化。该架构可以让整车的软件、算法、扩展性、性能等各个方面都得到极大的提升和呈现。

整车架构以中央计算平台为核心，结合智驾、智舱、TBox 三个区域控制，通过以太网形成整车主干网络。采用 3 路高速千兆车载以太网和高速 CAN 总线与自动驾驶域、智能座舱域以及 Tbox 连接云端，可以实现高速的数据交互，SOA 软件架构的扩展，灵活的场景应用。在整车控制方面，中央计算平台支持多路标准化 VIU 互联，通过高速百兆以太网和高速 CAN 总线冗余连接，集成了整车的动力控制，车身电气控制与驱动，电源分配以及热管理等功能，通过 VIU 的增加可以实现整车功能、服务场景的灵活变通和升级。另外中央计算平台还预留了两路模拟音频输出、摄像头视觉感知输入和图像显示输出等功能，为更多样化的应用场景做好了准备。

威马对于新技术新变化的应用始终保持着务实的宗旨，中央计算平台的设计在设计之初就考虑了项目的产品化，方案的可行性甚至“缺芯”的国产化等问题，目前各车企在软件能力上多落后于传统的 Tier1 ，随着新架构的推进，更有利于车企对主导权的掌握，使创新、创造回归汽车本身。

岚图汽车：

作为全新电器架构的核心器件，中央控制器在设计过程中需要从运算性能，耐候可靠性，控制器迭代升级，跨车型平台复用等多角度进行评估。下图简要叙述了岚图汽车中央计算平台从设计到量产过程中的关键路径和实践。

6.5 汽车 SOA 开发者平台

阿尔特数字科技：

随着开发生态的不断进化，软件开发人员本身的范围和职责内容都发生了变化：除了行业内传统的整车厂或供应商软件开发人员，还渐渐衍生出行业外的第三方开发人员，这部分开发者根据对汽车和软件环境的知识理解程度不同，可分为：入门级、初级和高级。职责内容上，整车厂的软件开发人员重点也在悄悄转移，不再限于如何基于 CP 搭建模型实现某应用程序，而在于搭建基于 AP 的软件平台，处理云端、车端、车机端等不同操作系统环境所带来的实时性与安全性挑战，优化与推进平台 API 接口标准化，为上文提到的三类第三方开发者搭建快速便捷容易上手的开发环境。

而对于第三方开发人员，整车厂能否提供便捷的工具或客户端，应用开发环境是否足够友好便捷，应用的商业价值和开发反馈能否快速体现，这些问题都给整车厂提出了新的挑战。

随着汽车生态的不断扩大，越来越多的终端用户会参与到汽车产品的功能开发当中，介入的渠道包括车机端/手机端/客户端（云端），介入的方式随着用户的开发水平提高而渐渐进化，从最初的手机端（车机端）场景编辑，到客户端的简单 APP 开发，最后进化到利用整车厂开发的各类 API 接口进行深度开发，开发内容不再局限于 APP，可以是与整车厂共同开发各类开发套件/工具/封装库等内容。同时，在不同的终端用户开发层级中，需要整车厂能够满足其不同的需求，包括场景编辑、应用管理、需求反馈、个人数据管理等。

由上可以看出，为真正满足用户的千人千面需求，需要打造兼容车端/云端/手机端或其他智能终端的异构汽车软件平台，打通面向整车全生命周期的数据链路通路，让数据从开发、测试、售后（运维）、终端用户几个环节中流通起来，利用 AI 计算挖掘数据价值，借助数据压缩、5G 通信手段等先进技术实现数据有效快速闭环；同时满足不同等级第三方开发者的需求，让更多的人或角色低门槛地参与进来，参与方越多，行业也就愈加繁荣。

联合汽车电子：

在软件定义汽车的大趋势下，汽车嵌入式软件的关键字是“模块化”，“标准化”和“个性化/场景化”。前两者是整车厂快速落地/集成复杂软件的关键之道，后者则是一种趋势，存在着因果关系。当基础功能以模块化的形式被正确集成部署且能够快速验证，丰富的场景将会爆发式的增长，整体的开发者生态也会逐步落地形成。

联合汽车电子作为具备丰富车控系统能力和开发经验的供应商，从系统能力出发，将业务知识转换成模块化的车控原子服务和基础服务，支撑车规级的灵活部署；同时，提供友好易用的开发/仿真验证环境（包括咨询服务），助力开发者快速实现/验证/迭代个性化的创新应用。联合汽车电子与整车厂和汽车软件开发者一同拥抱软件定义汽车的大潮，拥抱开发者的行业生态。

联合汽车电子推出软件开发者平台（Uaes Software Platform，以下简称 USP），致力于为开发者提供系统级解决方案，一站式开发者服务平台，快速开发工具、丰富的车控原子和基础服务、可视化调试工具、代码托管、应用推广等服务，帮助开发者突破技术壁垒、降低门槛和成本，让汽车软件开发像手机软件开发一样，可快速开发、验证和部署，提高软件开发迭代效率，形成开发者生态。

6.6 车云数据闭环量产实践

岚图汽车：

岚图汽车引入基于边缘计算和边缘存储技术的灵活数据采集方案，该实践提供了一整套车端数据灵活采集、存储、上传至云端、按需解析的产品解决方案。同时具备对车端数据进行大数据分析的能力、机器学习模型训练、以及支持实现高效的车云协同能力。

满足了汽车从整车开发测试、量产运营、用户体验提升、售后排故等车辆全生命周期数据应用的需求，实现车端数据灵活采集、按需低成本上传、云端数据低成本存储并可按需解析以满足不同业务部门在不同阶段对车端数据的各种使用需求。

在用户端软件使用体验上支持通过拖拉拽等简易操作模式实现灵活的模型创建和大数据分析，同时支持基于云端海量数据训练的模型算法一键部署到汽车域控进行边缘计算，支撑业务部门高效地进行智能汽车数据应用创新。方案设计如下图：

6.7 基于 SOA 的自适应 OTA 方案实践

镁佳科技：

镁佳科技在进行 SOA 服务化设计过程中，基于整车基线版本，可灵活配置升级策略&升级任务的 OTA 方式，为整车厂试验车辆、用户车辆、共享出行车辆提供远程升级服务。

OTA 云平台采用微服务架构，车辆客户端则是采用 SOA 化的服务部署方式，每个组件服务可以灵活的进行开发、配置，从而满足客户厂商对于不同情况下，需要对车辆升级的相关需求。无论是软件问题的修复、功能的更新迭代、还是系统的漏洞修复，都可以通过 OTA 的“整车基线版本”的管理方式来实现，涉及基线版本、升级策略、升级任务概念：

⚫ 基线版本：一组 ECU OTA 软件包版本的组合，其区分粒度到软件基础编码。原则上基线版本定义应包含车型下当前所有可用的 ECU 及软件基础编码。即：假设一个车型包含 10 个 ECU，平均每个 ECU 包含 2 个软件基础编码，则一个基线版本应指定 20 个软件包版本。

⚫ 升级策略：指升级过程中的各类条件、配置选项。如：本次任务采用静默下载还是通知下载、任务失败是否回滚、各类弹窗/行为的触发前置条件等。

⚫ 升级任务：一次升级的元数据信息，包括描述信息、升级范围等。

6.8 SOA 服务冲突策略设计实践

星河智联：

星河智联在软件定义汽车开发领域，提供智能化场景服务的开发及运行平台，以快速满足用户场景化、个性化和常用常新需求，平台通过智能场景推荐建设，实现车端信号可接入，实现场景的原子化，可组合形成复杂场景。对于生态服务实现原子化、可接入、可聚合，可调用，同时通过智能场景与生态交互结合，实现全场景生态服务。

需要有一套兼顾云+端的仲裁协同策略，编排串联指令，归并关联指令，消除冲突指令，避免场景指令相互冲突相互影响，同时控制触发节奏与次数，为驾驶过程提供良好交互体验。星河智联在项目实践上引入产品设计系统定义场景优先级、影响因子等策略控制，通过加权系数决定端或云优先。

⚫ **影响因子：**结合当前场景触发频次及用户喜好作为计算因子；即假设用户接受度X，X=场景执行次数/场景触发次数。如场景触发频次高，用户多次关闭，则影响因子系数小；场景触发频次低，触发时用户常进行二次交互等操作进行执行响应，则影响因子系数大。不同用户的操作针对单个场景会有对应的X，对应场景得分则为“（对应分值+X）/2”做到推送时的真正个性化。

⚫ **加权系数：**运营人员可设定加权分数 A，支持云端的编辑，允许对应场景及推荐的分数加权，使其优先级提高得到透出，原则上不得高于故障类及安全提醒。

⚫ **优先级：**按照定义的场景优先级进行分值划分，当前结合场景的属性及优先级，据此给出分值范围，在范围内根据单个场景打分。

在策略执行过程中，场景触发结果中会包含车控指令，很可能与用户语音主动触发的车控指令进行冲突，并且由于网络波动、处理逻辑等影响，易发生车控指令冲突异常，导致执行失败。面对这种情况，星云智联将云端推送的指令与语音触发的指令统一交由指令执行引擎模块处理，当收到多个执行指令，进行指令合并、去重，再排序，通过调用系统能力适配器的接口设定车身状态。

场景引擎决策过程还会与座舱 OS 系统原有的功能发生冲突。例如驾驶员正在倒车触发倒车影像，或者正在语音唤醒状态，其他功能需要暂时停止或延迟执行。因此应对这些特殊场景需要制定特定的策略。

场景引擎决策仲裁模块完成这些情形下的环境判断，并根据预定好的策略做场景的仲裁，以决定是取消指令的执行还是加入等待队列延迟执行，并需要制定场景打断策略。场景打断是指场景发生时的执行打断策略，当前场景正在执行指令过程中，另一场景或指令用户主动触发或高优先级插入，对当前场景造成打断的情况，被打断场景无须进行恢复。

对于特定模式如开机场景等串联服务场景，除非车辆故障中影响行车安全事件或用户自定义场景主动触发时进行打断，否则后续场景待具体模式串联场景执行完毕后进行推荐。

6.9 功能安全与信息安全方面

岚图汽车：

岚图汽车在设计与开发中央计算平台时，针对不同域功能的安全要求有所不同，从中央计算平台所承载的功能边界出发，通过危害分析和风险评估导出安全目标；基于安全目标和功能实现的具体链路逻辑，提出了安全技术方案，为中央计算平台的硬件开发、基础软件开发提供安全技术指导。

中央计算平台的相关项定义包含其所承载的功能、接口、运行环境条件、法规要求等，目的是为后续危害分析和风险评估、安全要求分解、ASIL 等级分配、安全要求提供充足的信息，中央计算平台的相关项定义如表 6.1 所示。在中央集成式电子电气架构中，中央计算平台扮演了整车大脑的角色，承载了基础功能域、车身安全域、智能座舱域、智能驾驶域的所有基础功能和衍生功能场景的主控逻辑，并承担了除驻车功能、行车制动、方向盘助力控制、动力电池管理之外的动态控制及能源域的基础功能和衍生功能场景的逻辑。中央计算平台对外接口简单，主要是与车辆区域控制器进行高速通信的以太网通讯接口和供电电源接口。中央计算平台布置在乘客舱内，但由于高负荷的计算，需要良好的散热系统。

危害分析和风险评估的对象是整车级功能失效造成的危害事件，针对整车级功能的危害分析和风险评估可以沿用传统架构的安全目标，中央计算平台的安全目标主要来源于其承载的整车级功能的安全目标，如表 6.2 所示。

功能安全概念的目的是从安全目标中得出功能安全要求，并将其分配给中央计算平台或整车其他部件或外部措施。每一类安全目标都有一个具体的功能实现链路，功能安全要求首先来自预期功能实现的要求，并根据预期功能实现的分配原则进行安全要求的分配。例如针对 SG_06，近光灯的预期功能实现链路，前区域控制器采集驾驶员拨动近光灯开关状态，并发送近光灯请求，中央计算平台收到请求，判断近光灯开启逻辑，并分别向左、右区域控制器发送近光灯开启指令，左、右区域控制器转发近光灯开启指令，左、右灯光控制器模块接受指令后，打开近光灯。在近光灯功能实现链路中，分配给中央计算平台的预期功能安全需求有三条，分别是正确接收近光灯开启请求、正确处理近光灯开启逻辑、正确发送近光灯开启指令。

功能安全要求还需考虑故障状态下能够进入安全状态，导出该类安全要求需要借助安全分析的手段，通常有 FMEA 和 FTA 两种方法，根据不同的 ASIL 等级，可以采用其中一种或者两种。近光灯的安全目标可以采用 FMEA 的安全分析方法，列出了安全目标 SG_06 FMEA 分析过程中的中央计算平台部分的失效分析概览。

中央计算平台承载了整车所有功能逻辑和未来衍生功能场景的应用，高度模块化的嵌入式软件和应用软件，分别拥有不同的 ASIL 安全等级，根据 ISO26262 标准要求，如果软件包含不同 ASIL 等级的 SWC，要么整个软件工程都需要基于最高安全等级的要求进行开发，要么需要保证拥有更高安全等级的 SWC 的操作不会受到其他 SWC 的干扰，做到 FFI(Freedom from interference)的设计。其中，内存、时间、执行和信息交换的错误会导致 SWC 之间产生干扰。如何保障不同 ASIL 等级的软件应用免受干扰是软件安全架构设计的核心内容。

异构部署是一个关键因素，中央计算平台在使用多种不同的 OS 时，应该将安全相关的功能应用部署在高实时嵌入式操作系统上。基于安全芯片和主功能芯片的中央计算平台的一种软件安全架构概览，与安全目标和安全要求相关的功能软件应该优先部署在安全芯片上，例如驱动控制、灯光控制、车身控制，安全芯片可以采用 AUTOSAR Classic 标准的软件平台，可满足 ASILD 的高安全要求。与智能驾驶域相关的传感融合、路径规划、决策执行等应用不仅需要高性能计算，也需要高安全性保证，应该部署在主功能芯片的安全 OS 上，可以采用 AUTOSAR Adaptive 标准的软件平台。与智能座舱域相关的仪表显示、故障提醒等安全类应用可以部署在 QNX OS 上，黑莓的QNX OS 最高可支持 ASILD 的安全要求。安全中间件也是考虑的因素之一，安全中间件包括看门狗模块、程序流监控模块、通信的端对端保护模块、芯片的健康管理模块等，中央计算平台使用的安全中间件应该按照最高的 ASILD 等级要求开发。

领科汇智：

SOA 在实现软硬件解耦、重构汽车整车软件生态的过程中，面向服务的通信标准化、基于服务的软件复用以及基于服务的软件实现，带来了整车厂、零部件企业、工具链企业的新的研发整合，因此，整车各类功能的功能安全 ASIL 实现难度大幅增加。整车整车厂开放第三方开发平台，如何保证其不影响整车的功能安全，对于第三方开发的服务，如何确保其不牵连失效影响其它已有 SIL 等级的服务，服务客户端 的 ASIL 等级的不确定性等问题都将是制约 SOA 能够有效实现的关键因素。

基于上述分析和阐述，领科汇智在参与基于 SOA 架构的服务开发过程中，总结了如下SOA 架构下功能安全的开发流程：

⚫ SOA 系统设计过程中结合安全因素将服务合理分层，针对不同开发主体采取不同限制策略；

⚫ 基于服务内容进行合理且有效分类，基于服务的安全相关性对第三方开发的服务和整车厂服务进行分区，实施过程中需要考虑严格的安全审核机制；

⚫ 为了实现物理隔离，需要考虑将供应商开发的底层服务和整车厂自己开发的顶层服务进行高性能计算分区和安全计算分区，同时，软件运行期间的动态安全监控也是必须实施的。

如上图所示，构建面向服务的功能安全开发流程及框架包含如下关键步骤：

首先是进行有效的整车功能需求分析和服务需求分析，在落实功能实现方案和服务实现方案的过程中，进行危害识别分析（SHA）和失效分析（SFA），提出安全目标；

其次是进行 SOA 架构下服务和功能的安全分类以及分配实现对应的安全目标；

在后续开发层面主要通过安全案例和服务层一致性构建安全保障体系，实现高度自动化的模型集成环境，在软硬件开发过程中实现功能安全；

最后通过单元安全测试以及集成安全测试，通过审核后发布用于生产的满足安全等级的产品或服务设计。

SOA 架构在整车功能拓展延伸带来灵活快捷的同时，必须首先确保功能安全的实现，在不同应用场景下的功能安全是汽车相关产品的基本要求，本章节根据 ISO26262 提供的方法论，从整车功能和服务定义出发，经过危害分析和失效分析、功能安全目标设计、功能安全分类与各层级间分配实现，到软硬开发的技术安全需求，为中央计算平台的功能安全开发、测试与审核，最终确保为用户提供符合功能安全要求的产品或服务。

广汽：

软件定义汽车的时代下，为支撑软件定义汽车落地，实现“千车千面”、“千人千面”，广汽研究院开发了由汽车数字镜像云和中央计算机、智驾计算机、信息娱乐计算机三个核心计算机，配以高速以太网、5G、信息安全和功能安全等技术构成、可高效支撑纯电、混动车型的车云一体化集中计算的星灵架构。在享有产品形态能够低成本快速迭代、构建新生态、自动驾驶领域更好的支持 L2++~L4、更全面的 OTA 快速升级以及远程诊断、智能诊断等技术红利的同时，星灵架构的对外开放平台和智能化场景服务的开发及运行环境也更容易遭到攻击，也暴露了更多的信息安全风险。

面对日益严峻的信息安全风险形式，和日益庞大的软件代码开发量，如何保证车辆的信息安全的前提下实现车辆功能的快速迭代，在整车开发的早期即识别出安全风险并制定相关的安全措施的挑战，广汽通过不断地探索，制定出了一套将信息安全措施与电子电气架构开发流程相结合的行之有效的流程体系，该体系结构具体如下图所示：

以下是关于信息安全设计如何与电子电气架构开发中进行结合的详细描述：

⚫ 经过一系列的用户调研、亮点和痛点分析之后，会提出新增功能并进入可行性分析阶段；

⚫ 在可行性分析阶段，传统的做法是在该阶段仅会概要分析各个系统和零部件是否有能力承接相关的需求，这样往往会导致信息安全风险的识别存在滞后的情况，并会导致后面的信息安全的设计难以执行，为此，广汽在此阶段即开展相应的信息安全风险识别，在可行性阶段即明确要求某个功能是否存在信息安全的风险，避免出现信息安全设计之后的情况；

⚫ 功能通过可行性分析之后，会相应地更新 Feature List 并进入制定功能设计规范的阶段；

⚫ 在功能设计规范阶段会详细说明功能的使用场景、激活条件等，该阶段完成后会进入功能需求规范的制定阶段；

⚫ 在功能需求规范制定阶段，会结合可行性分析阶段的风险评估结果提出相应的风险缓解措施，并最终以信息安全设计要求的形式输入至对应功能负责人，对应功能负责人结合功能本身的特性进行信息安全的设计并体现在功能需求规范中，这样做能有效避免信息安全的要求脱离功能设计的实际；

⚫ 一旦功能需求规范制定完成后，需要针对信息安全的设计要求进行评审，以判断相应的设计规范能否满足信息安全的要求；

⚫ 评审通过后会形成承载该功能的各个零部件的零部件技术规范，一般该阶段结束后形成的零部件技术规范会输出给零部件开发团队进行相应地开发，然而在实际工作开展中发现如果仅按照从功能的角度识别出的信息安全风险和缓解措施往往不够全面。为此，在该阶段我们还做了一步流程的优化，即在该阶段会结合法律法规的要求、整车和零部件的 TARA 分析结果和企业对特定资产的保护倾向形成

不同零部件的信息安全基线要求并输入给零部件技术负责人，该负责人会结合零部件本身的特点形成相应地零部件信息安全实现方案；

⚫ 零部件技术规范制定后最终要针对信息安全进行评审后才能释放给开发团队进行开发。

从以上流程可以看出，广汽在功能需求的可行性阶段仅开展相关的安全风险识别，并在功能设计和零部件设计中提出对应的信息安全需求并参与相应的方案评审，实现了信息安全开发较好的融入到了整车电子电气架构开发流程，实现了与整车开发、零部件开发的有机结合，让安全为整体的软件功能赋能。

联合汽车电子：

联合汽车电子目前已初步建成了覆盖整个产品信息安全生命周期内的防护能力体系，可以为整车厂客户提供产品信息安全方面的技术支撑。

1). 产品信息安全流程能力

联合电子已基于 ISO/SAE 21434-2021 版标准完成了企业流程的制定，并贯穿产品整个生命周期，从前期的设计开发到后期的售后运维。整个过程中的关键活动包括：需求搜集、信息安全分析和风险评估、信息安全概念设计、信息安全需求定义、信息安全架构设计、信息安全测试、信息安全情报监控、信息安全漏洞管理和信息安全事件响应等，可以配合整车厂客户通过 CSMS 认证和整车 Type Approval 认证工作。

在建设产品信息安全流程体系时，上述产品信息安全流程关键活动可作增量要求，融入到企业现有质量管理体系中，例如，IATF16949、ASPICE 等。通过此种方式来构建企业产品信息安全质量管理体系，可以较容易进行落地实施，而非“另起炉灶”地搭建新的质量管理体系。

2). 产品信息安全技术保障能力

在技术保障能力上，做好智能网联汽车的整体信息安全风险的防护措施十分重要。将智能网联汽车的通讯数据流进行抽象，可以得到从车外云服务器到车内电子控制器的 6层架构。构建整个智能网联汽车信息安全防护体系，需要在每一个层级部署相应的信息安全防护技术，来防护智能网联汽车的整体信息安全风险，保障和提升整个系统的信息安全特性。

联合汽车电子围绕其不同业务产品线建成了产品信息安全技术方案的设计、开发和测试能力，能够完成整车厂客户的信息安全需求的落地实施。

3). 产品信息安全生产能力

联合汽车电子建设了产品信息安全生产能力，包括生产工艺能力、数据管理能力、生产密钥管理平台。

**A. 生产工艺能力：**此部分能力在于将产品信息安全技术要求落实到产品生产过程中，例如，密钥注入、配置产品信息安全功能参数等；

**B. 数据管理能力：**此部分能力基于 ISO27001 和 TISAX 质量流程体系建设而成，以保障生产环节的数据安全，例如，密码材料、生产追溯信息等；

**C. 生产密钥管理平台：**此平台可以和不同整车厂客户密钥管理服务器对接并进行数据交互，实现密码材料在整车厂后台和联合汽车电子产线之间进行“端到端“的直接交互。在产品下线之初就完成密码材料写入，并开启全生命周期内的信息安全防护能力。

4). 产品信息安全运维能力

在安全运维方面，联合汽车电子目前具备了产品信息安全情报监控、产品信息安全漏洞管理、产品信息安全事件响应能力，可以配合整车厂客户完成售后阶段的安全运维要求。

**A. 产品信息安全情报监控：**产品信息安全情报监控是指持续搜集、分析和评估智能网联汽车相关的信息安全情报，并判断是否会影响到企业自身开发的智能网联汽车产品。建设安全情报监控能力，关键在于要建立和维护信息安全情报的渠道源，以便第一时间获得信息安全情报信息，并开展内部的分析和评估工作。值得一提的是，信息安全情报监控在研发阶段就可以开展了，以达到尽早发现和解决信息安全漏洞的目的。

**B. 产品信息安全漏洞管理：**产品信息安全漏洞管理类似于常规的问题管理过程。在判断信息安全情报确实影响到了企业开发的智能网联汽车产品后，说明产品中存在信息安全漏洞，便需要开展安全漏洞管理工作。区别于常规问题管理过程，信息安全漏洞管理需要增加漏洞风险的评估活动，可参考产品信息安全威胁分析和风险评估的方法论。

**产品信息安全事件响应：**产品信息安全事件响应活动，主要针对于批产之后的智能网联汽车产品。通常，批产后产品存在的漏洞需要被重点对待，因为其影响面更大，可能会引起售后召回、客户投诉等严重后果。智能网联汽车的信息安全事件响应，除了包含信息安全漏洞管理工作要求之外，还包括潜在的内外部协调/沟通/汇报等工作要求，例如，对接国家质检总局缺陷产品召回中心（DPAC）等。

7 总结与展望

近年来随着智能汽车的发展，消费者对于汽车属性的认知不断扩展，已经逐渐从交通出行+安全可靠为主向交通出行+安全可靠+主动智能+内容+服务转变。同时在政策层面，国家发改委、工信部、科技部等 11 个部委在《智能汽车创新发展战略》中提出，汽车正由人工操控的机械产品逐步向电子信息系统控制的智能产品转变。从产业层面看，汽车与相关产业全面融合，呈现智能化、网络化、平台化发展特征。汽车将由单纯的交通运输工具逐渐转变为智能移动空间和应用终端，成为新兴业态重要载体。同时指出智能汽车发展要市场主导，跨界融合，充分发挥市场配置资源的决定性作用，激发智能汽车发展活力。打破行业分割，加强产业融合，创新产业体系、生产方式、应用模式。

如前面章节所述，软件的加持将进一步加速智能汽车的创新发展，如何真正促使软件定义汽车落地，为中国智能网联汽车创新发展探索一条适合的道路，本白皮书基于智能汽车发展趋势角度，识别产业共性挑战与问题，并结合近两年来的企业实践，提出分层解耦、产业协同合作框架，同时各企业单位结合自身经验分享了围绕统一合作架构的建议方案、典型应用场景与实践案例，希望对智能汽车产业创新发展有所帮助。

展望未来，随着消费者对智能汽车的认知度越来越高，智能化技术也将越来越成熟，智能汽车产品规模化、商业化进程会更加顺利，从而将进一步推动汽车软件的开放与标准化，特别是在全球竞争加剧和经济发展不确定性的背景下，更需要汽车上下游企业形成合力，联合起来形成生态圈。通过多方协同，各企业结合自身优势聚焦产品开发与实现，通过统一接口实现不同企业产品互联互通，避免各自碎片化、重复性投入，帮助各企业集中精力开展核心技术研发、产品创新和人才发展，最终形成智能汽车产业的正向循环发展。