什么是行话？

「行话」，是极狐 GitLab 推出的全新内容系列，探讨 Git 与 DevOps 在不同行业的实践场景与解决方案，希望能够为不同行业的软件开发者带来一些全新的思考和输入。

说行业，讲行话。

这一期，我们选择了「汽车行业」，讲「汽车行话」。

以下，enjoy。

本文来自：

卢东晓安波福（中国）科技研发有限公司软件质量高级经理

极狐(GitLab) 市场部内容团队

近年来，「软件定义汽车」兴起，但各方观点众说纷纭，直到最近才有了标准化组织的官方理解，即来自中国汽车工业协会下属的软件定义汽车工作组（以下简称SDV工作组）发布的《软件定义汽车产业生态创新白皮书（V1.0）》（以下简称白皮书）。

白皮书引用了 APTIV（安波福）和 BOSCH（博世）对于「软件定义汽车」的理解：

APTIV（安波福）

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

BOSCH（博世）

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

头豹研究院《汽车软件行业概览：软件定义汽车》

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

这只是一个阶段性的概念理解，距离形成标准定义仍有一段路要走，但确实标志着，行业已经发展到了新的里程碑。受各种因素影响，汽车市场前景仍不明朗，但软件在汽车行业的重要度不断提升的趋势，已然不可逆转，相应的机会也越来越多。

在这样的背景下，越来越多的企业与个人源源不断地涌入，而市场竞争的大浪淘沙下，并非所有人都能生存下来。

入局「软件定义汽车」，你真的准备好了吗？

过去深耕传统汽车的整车厂，能适应快速迭代的敏捷开发吗？

软件外包团队，能应付数据激增、算法和架构高度复杂的系统吗？

互联网公司、ICT 科技公司，入局汽车能符合汽车行业的各项合规要求吗？

我们正处在汽车行业历史的关键节点

1. 主流汽车软件架构路线图

上述 SDV 工作组引用的两家企业，对「软件定义汽车」这一转变，有各自的行业洞察：

APTIV（安波福）的前身是从通用汽车公司分离出的德尔福，总部曾从美国迁到伦敦，后至爱尔兰，在一定程度上代表了「英美法系」的技术见解。

在《安波福智能汽车架构白皮书》中，可以看到如下「汽车软件架构路线图」：

图 / 逐步全面实现 SVA

来源：《安波福智能汽车架构白皮书》

翻译如下：

简言之，根据安波福发布的这份白皮书，当下的汽车软件架构正处于域（Domain）和区域（Zone）架构的阶段，2025 年将真正进入「软件定义(Software Defined)」元年。

BOSCH（博世）总部位于德国，长期居于 Tier1 榜首的公司，在一定程度上代表了欧洲「大陆法系」的行业洞察。

图源：The Wild West Of Automotive

翻译如下：

该时间表是博世于 2015 年提出，而当下的架构演化进程完全符合预测，正处在所有域控单元向「融合于一个集中式计算单元」发展的进程中。

结合国情理解「软件定义汽车」这一转变给行业带来的影响，我们可以参考头豹研究院《汽车软件行业概览：软件定义汽车》报告：这是覆盖「汽车的定义、架构、开发、验证、销售、服务等全生命周期」的颠覆性变革。

2. 历史 vs 当下

事实上，随着「软件定义汽车」的演进，汽车软件产业链金字塔型结构，即「主机厂 - Tier1 - Tier2 - Tier3」，也已发生改变。

在过去传统汽车供应链中，Tier1 为汽车软硬件集成负全责，如电装之于丰田、德尔福之于通用、伟世通之于福特。

而当下，Tier1 不再是 OEM 软硬件的唯一来源，取而代之，OEM 可能会从第三方软件、OEM 本身软件、软件栈工程集成服务商、面向 OEM 的硬件提供商、硬件工程服务商、EMS 服务商等多个来源获取对应的软硬件组件进行集成。

在这样一个新的产业链关系中，甲乙双方的合作模式如何？

理想的开发状态当然是甲方和乙方基于统一标准和工具链，如双方 PM、程序员、测试均在同一套软件平台进行需求管理、开发与评审。

但目前，甚至很少企业能做到甲乙双方 PM 针对 Jira 上的一个 story 跟踪状态；双方需求人员基于同一个 Polarion 里的工作项进行评审；双方程序员基于极狐GitLab 进行软件研发等，更遑论在同一个平台进行研发管理。

要实现理想状态，不可能一蹴而就。现阶段，「软件定义汽车」对汽车软件链条中的不同角色都提出了新要求：

更快捷

对于项目的开发和管理人员而言，这或许意味着需要通过敏捷方法推动持续软件开发，比如采用目前在互联网大规模落地实践、并已证明有效的 DevOps 方法，使汽车制造商能够在车辆出厂后持续将软件高效地部署到车辆上。

更可控

对于定义业务功能的产品经理和搭建架构的架构师而言，车辆软件和电气电子架构转向更模块化的面向服务架构（SOA）模型，使软件组件更易以构建块格式重用。随着软件复杂度提升，对于代码追溯和版本管理的可控性要求也进一步提升。

更安全

对于网络安全专家和测试验证团队而言，为了避免、检测和防御网络攻击，安全策略变得更加关键。相较于事后补救，更需要防患于未然，提前实施安全测试，软件安全左移，在早期将安全要素融入到设计、开发、测试和部署的每个阶段。

汽车行业软件研发三大挑战

面对「更快捷」、「更可控」、「更安全」的行业要求，汽车行业软件研发链条上下游面临着诸多挑战，聚焦软件研发方面包括：

1. 缺乏研发运维一体化标准平台

软件研发过程中，需求管理、源代码托管、CI/CD、安全扫描等，都有对应的工具平台，若缺乏有效整合，研发团队面对的将是许多复杂的工具，研发流程节点之间难以流转；且工具之间数据结构不同，API 丰富程度不一，集成难度大，团队需要花更多时间和精力在工具细节上，难以实现敏捷。

2. 缺乏确保标准合规的手段和机制

尽管软件架构方面有了 AUTOSAR（汽车开放系统架构）、代码质量方面有了 MISRA（汽车工业软件可靠性联会）、开发流程方面有了 ASPICE（汽车产业软件流程改进和能力测定标准）和规模化敏捷等标准，但具体落地中，仍然没有形成有效的机制强制标准合规。例如：只有评审通过的代码才能上传、不合规问题及时检出报告、支持版本控制、确保可追溯性等，这些机制的缺失，可能最终导致整个项目失控。