十年前，一台主流车型所需的代码量可能只有1000万行，而如今，一辆高端汽车可能包含多达五亿行代码。放眼未来，l5级自动驾驶车辆所需的代码量有望提高到十亿行。

不难看出，“软件定义汽车”催生出更多创新产品的同时，也于无形中增加了整车系统的复杂性。某种程度上，这亦成为车企向智能化更进一步的阻力。

比如，当车企采用传统方案进行新车设计时，往往会遇到资源不足、后续开发及维护成本难以负担的窘况。归根究底，新增一项智能化功能，即意味着要加入更多的程序代码，投入更多的人力成本。

另外，东风汽车技术中心智能软件中心总监赵宁早前也表示，在汽车智能化转型的过程中，软件面临的挑战越来越多。包括但不限于，更复杂的系统架构和模块化设计需求，不断缩短的开发和迭代周期，更高的安全性和可靠性，以及要解决不同供应商产品的兼容性问题等。

因此随着大算力芯片逐渐普及，汽车电子电气架构得到了快速发展。以现阶段的域控/区域式架构来看，大量的ecu通过软、硬件剥离，将分散的功能集成在几个域或者区域控制器里，从而实现更简化的系统设计。

但考虑到自动驾驶汽车需要更快速的反馈机制，此类架构无法满足更高效率的通讯需求，中央计算架构由此就成了解决问题的关键所在。继续往下发展，便是车云协同阶段，大部分计算会迁移至云端。

而无论是硬件升级，还是架构变革，都亟需一套标准化的软件对车辆进行控制。arm推出的soafee (scalable open architecture for the embedded edge,面向嵌入式边缘的可扩展开放架构)正是在这一背景下诞生的。

“soafee可以兼容现有的车企架构，arm目前正在开发相应的工具，将以‘容器化’的形式来协助两者之间的转移与兼容。”arm汽车事业部亚太区高级市场总监邓志伟称。举例来说，车企有一系列软件跑在原来的系统上，在应用了soafee后，无需修改代码即可将这些软件放置在一个“容器”里。

这个“容器”相当于一个软件执行环境，可以把应用程序和作业系统相抽离。同时“容器”会把其中的软件进行标准化处理，如此一来，“容器”的概念便可持续往下拆解，将原有架构系统拆分成各种功能，得到一个个小的容器程序，进而被反复利用。

要知道，在软件定义汽车的趋势下，软件不仅需要具备可移植性，还需基于云端构建与升级，以使开发和维护成本能够降到最低。再者，智能汽车除了对实时性、安全性提出了更高要求，也对开放性有着新的追求。

博世中国创新与软件开发中心总经理王志煌举过一个关于esp的例子：处于云端协同阶段的智能汽车，可以真正实现“信息共享”。例如，当一辆车发现前方路段是冰面，这个信息被上传到云端后，相邻的所有车都会接收到警告信息。即便有的车没有esp装置，也能获得相似的功能效果。

这也解释了基于软件定义下的esp功能。而soafee大致是一样的道理。

据了解， soafee 是一个基于开放、标准化原则的供软件定义汽车使用的架构，可将现代的软件开发技术导入车用市场。更重要的是，基于这个架构，整个行业可以分享彼此的专业知识、技术与产品，加速推动软件定义汽车的到来。

只有开放、标准式的架构才能创造更强大的生态系统，这显然是智能汽车时代所需要的。

soafee推出的第一年，重点着力于对架构规范和定义的商讨与制定，确保所有参与成员达成一致的共识和目标，而后便开始展开实际的工作交付，包括参考设计、软件开发等产出成果。去年，soafee已成功交付首个开源参考实现，并通过设立实验室，以及扩大开源合作关系等途径，持续加速soafee的实际交付。

而这个过程里，arm 也将提供预验证，帮助车企将原有系统无缝转换到soafee中。此外，arm还提供了一种新的可能——通过虚拟硬件 (arm virtual hardware)，开发者可以在硬件尚未就绪的情况下开始软件开发工作，从而缩短开发时间。

截至目前，已有100多家行业伙伴加入soafee，包括芯片厂、一级供应商、软件公司等等，预计规模将持续扩增。

软件定义汽车究竟会带来哪些巨变，仍待观察，但这一趋势的发展已经得到行业的一致认可。

罗兰贝格在2023年发布的报告中指出，到2023年，单车软件价值将从当前的8,000~16,000元增长至16,000~32,000元，其价值占整车bom的比重预计将从当前的4~9%增加至2030年的8~12%。值得一提的是，自动驾驶系统单车软件价值到2030年将占据整车软件价值约43%。软件将逐渐成为车企成长的新引擎。

就像oem积极推进中央计算架构、自动驾驶技术，上游产业链企业积极开发更灵活的ip、更高算力的芯片、更趋标准化的软件架构一样，只有充分准备，才能更好迎接这场变革，挖掘出更大的增长空间。

以上是网络信息转载，信息真实性自行斟酌。