汽车电子软件规模化开发趋势
1. 引言 #
软件逐渐重塑着汽车的功能与潜能，正如我们在《驾驭未来：软件定义汽车及其对行业的全面影响》一书中所讨论的，汽车产业正向着智能化、个性化以及服务化的方向发展。在这个新时代，汽车已经转变成一个可持续更新与升级的动态平台。因此，企业必须适应并寻找新的研发模式。构建强大的软件平台能力和生态系统成为了行业的核心任务。目前，许多企业在这一进程中挣扎，希望能够跟上这一发展趋势。
2. 推动技术融合的新电子电器架构 #
当前，汽车行业的主要参与者正在积极推动第五代电子电气架构平台的产品化。第五代架构的核心在于通过将大多数功能整合到几个关键平台控制器中，从而减少控制器数量。以下是麦肯锡公司提供的第四代与第五代电子电气架构之间的简要对比说明。
第五代架构通过引入中央计算单元和区域控制器单元，模糊了传统功能域（Domain）控制器的界限，并实现了车辆各域功能的进一步融合。这种架构带来了许多优势，包括：
- OTA优化：新架构使得安全的OTA（Over-the-Air技术）实施更加容易，减少了需要进行OTA的控制器数量，大大降低了整车OTA的瓶颈，简化了OTA流程，并减少了失败及回退的概率，提高了传输的可靠性与安全性。
- 减少线束复杂度：在整车成本中，线束通常占比约20%。将大部分功能集中在少数控制器中，并在必要位置部署IO聚合控制器，可以在保障功能和安全的基础上，减少控制器数量，进而简化线束。这不仅降低了成本，还减少了设计、验证及生产制造的复杂度，并降低了对人员的技能要求。
- 提高芯片集成度：控制器的融合使得单一控制器单元能够实现以前多个单元的功能，这些功能甚至可在同一芯片上执行，从而提高了整车芯片的集成度，减少能耗并提升能源利用率。
- 软硬件解耦：软硬件的解耦潜在地提升了软件开发的效率，缩短了功能上线时间，并加速了产品的市场推广。通过使用少数控制器实现大多数功能的融合，不仅提升了单个控制器的计算能力，也促进了更好的软件抽象、分层和模块解耦，这些都是构建软件平台的核心要求。
3. 技术栈和开发模式 #
3.1 传统的以控制为边界的开发模式 #
在传统的电子电器架构下，现代汽车通常需要装配100到150个电子控制单元（ECU）。这些控制器分散布局，每个承担的功能相对单一。控制器之间主要通过如CAN、LIN等总线通讯方式进行互联互通。通常情况下，单一控制器的供应商（多为Tier1级）会根据自身的技术积累及供应商的解决方案来选择成本、质量和交付时间最优化的技术栈。OEM的主要任务是整合这些供应商的控制器进行整车集成。虽然有些OEM会对关键的控制器进行自研开发，但从整个产业的角度来看，参与整车功能软件开发的团队通常以控制器为界限，独立完成各自负责的部分，技能水平相近，容易形成封闭的小团体。
在传统的架构下，以单个控制器为边界，功能相对集中和单一，开发模式相对封闭，一个公司/团队只需要保证自己开发的软件和控制器能够按照预期处理输入并产生相应的输出即可，尽管为了高效高质量的开发，控制器的技术栈通常也会采用分层结构，但这个在不同的控制器开发主体之间并非有一个统一的共识，是否分层、如何分层并没有一个统一的定 义，当然随着行业的发展，也出现了AUTOSAR这样的标准分层结构，但这个并非是强制性的，排除掉开发效率，主体的开发能力等因素以外，是否选择AUTOSAR并非有一个明确的要求，因此，分层技术栈的选择在不同的控制器开发主体之间可能差异很大。
以下图示展示了一个AUTOSAR的分层结构：从最底层的硬件层，到上层的基础软件层（BSW），再到运行时环境（RTE），以及最顶层的应用层软件。BSW层提供了汽车行业中非应用领域的通用功能，如诊断、通讯、存储和网络管理等；而RTE层则为应用层软件提供了执行环境和接口交互环境，允许构建应用或业务领域的软件模块。
虽然在传统电子电器架构下的控制器开发中，采用AUTOSAR技术栈越来越受到欢迎，其根本原因在于开发主体致力于如何快速且高质量地开发出支持特定应用领域的控制器产品。相对而言，通用的行业标准化功能并非他们的重点关注领域，这部分软件通常选择通过外部采购成熟的供应商方案（例如Vector、ETAS等）来快速实现。这种做法并没有改变以控制器为界限的开发模式。
在这种模式下，通常参与同一控制器的开发的人数不会超过20人，涵盖了应用软件、底层驱动、基础软件的配置与开发以及软件集成等方面。这种开发模式并未形成在同一软件架构下不同领域间进行联合开发的规模化效应。
3.2 新架构下的融合式开发模式 #
在第五代电子电器架构下，汽车软件的技术栈呈现出层级结构，从整车的维度来看，整车电子控制器及相关的传感器、执行器等物理单元共同构成了车载物理平台。在第五代架构中，这个物理平台通常由几个大型控制器和相应的传感器执行器组成。这种架构强调了控制器的集中化和功能的集成，使得车辆的电子系统可以更加集中的管理。
在第五代电子电器架构下，物理平台之上建立了标准化的操作系统和行业标准系统服务，共同形成了车载软件平台。所有的软件功能都是基于这个软件平台构建的。在这种架构中，控制器的边界所涵盖的领域功能远比传统开发模式下的多，从而催生了融合开发模式。例如，原本分散在车身控制器、灯光控制器、空调风门控制器等各个控制器的车身和舒适性相关功能，现在都可以集中到同一个ZONE控制器中。在算力充足的情况下，可以融合更多的功能。
从软件开发的角度来看，这意味着原本在传统模式下独立工作的控制器开发团队成员现在需要共同在同一个控制器上进行开发、部署和系统性调优。这种跨领域的协作为团队带来了不小的挑战，因为它要求团队成员不仅要有深厚的技术专长，还需具备跨领域协作的能力，以确保各功能模块的顺利整合和优化。
这种新的架构和开发趋势彻底打破了传统的控制器界限，实现了控制器的融合，使得更多功能可以集中部署在ZONE控制器和中央计算单元中。这样的变革可以将一台车上的电子控制单元数量减少约20%到30%。具体来说，这意味着将20%到30%的控制器软件集中到少数几个控制器中。这一变化为汽车行业的软件开发带来了以下几个挑战：
- 软件架构的融合与重构：不同领域的历史代码如何高效迁移到新架构，以及如何在新开发中保持架构一致性，都是需要解决的问题。
- 调度复杂性与安全隔离：将不同安全等级的软件融合到同一个控制器，甚至同一个CPU中，需要确保各功能调度正常，满足时延和时序要求，同时在保证隔离的情况下，确保功能的全场景可用性，并将系统资源消耗优化到最佳，这是一个极具挑战的系统性问题。
- 开发人员规模的激增：不同领域的开发人员可能使用不同的编程语言和开发工具，如何使大规模且背景不同的开发人员高效协作，并确保最终集成后的软件具有较高的质量，也是一大挑战。
- 多方合作开发及IP保护：在跨公司的合作开发中，如何安全地保护企业知识产权，也是需要考虑的重要问题。
4. 谁将面对挑战 #
通过深入研究汽车行业新的电子电器架构的发展趋势，以及对比新的融合式开发模式和传统以控制器为边界的开发模式的区别，我们发现汽车电子软件复杂度的提升带来的规模化开发效应，对企业的软件开发能力提出了前所未有的挑战。这里所说的软件规模化开发，简而言之，就是在同一个CPU上，基于同一个操作系统进行业务开发的人员规模和代码规模都有了显著增长。因此，面临这些挑战的，将是那些围绕着中央计算单元和区域控制器这几个关键控制器提供系统性解决方案的企业，包括OEM、车载物理控制器平台提供商、车载软件平台解决方案提供商。特别是OEM，由于构建车载平台（物理和软件）是其核心诉求，因此受到的影响尤为显著。这背后的深层原因是，通过构建平台化方案，企业能更好地应对软件定义汽车的趋势，否则可能会在未来的市场竞争中逐渐失去影响力。
根据麦肯锡的一份调查报告，我们的能力建设尚未能跟上行业软件复杂度的增长，即使是行业领军企业也存在明显差距。那么，企业应该如何发力，弱点又在哪里？这是一个复杂的问题。但基于我们对当前挑战的识别，可以确定的是企业需要更加重视软件架构的投入，以应对“软件架构的融合和重构”及“调度复杂性和安全隔离”的挑战。另一方面，企业还需要在软件工程和工具层面，特别注意提高“开发人员规模激增”和“多方协作开发”中的协作效率和软件质量。
