什么是行话？

「行话」，是极狐 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 榜首的公司，在一定程度上代表了欧洲「大陆法系」的行业洞察。

图源：https://semiengineering.com/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（汽车产业软件流程改进和能力测定标准）和规模化敏捷等标准，但具体落地中，仍然没有形成有效的机制强制标准合规。例如：只有评审通过的代码才能上传、不合规问题及时检出报告、支持版本控制、确保可追溯性等，这些机制的缺失，可能最终导致整个项目失控。

3. 复杂度和性能要求进一步提升

涉及更多兼容、安全要素的行业标准正在制定或刚刚发布，但在落地层面仍然存在很多不确定性。例如 2021 年 8 月发布了 ISO21434，但实际上的产品架构设计、代码实现、验证检测方面都还处于初级阶段，缺少安全保障很可能酿成严重事故。

应运而生的 DevOps

更复杂的系统、更严格的标准、更紧迫的交付时间、更剧烈的竞争……一切都在层层「做加法」。

DevOps 应运而生：旨在让软件研发链条上的所有人紧密协作，加速软件交付。

近年来，DevOps 被各大行业所追捧和实践，尤其在互联网领域，已获得巨大成功。

但对于车企而言，关于 DevOps 的落地实践仍存在误区：

1. 过分关注工具链建设

工具是 DevOps 落地实践的有效支撑。因为 DevOps 涉及多阶段，每个阶段都会用到很多开源或闭源工具。企业往往陷入各种工具链的建设，然而每个阶段使用一种工具，最后将耗费大量的时间和精力在工具运维上（采购、安装、补丁升级等），而无力投入到汽车软件研发和团队创新的核心工作上。

因此，切记一点：工具只是手段，不是目的。理想状态下，好的研发平台应当屏蔽所有工具底层细节，车企直接使用开箱即用的能力。

2. 忽略规范化、标准化流程的构建与沉淀

规范化、标准化流程是研发效率提升的重要手段之一，能够让研发团队遵循同样的流程进行研发，减少无序和混乱；也能够让团队新成员快速熟悉团队工作、进入状态，最终提高团队端到端交付能力。

同时，规范化、标准化流程可以沉淀为最佳实践，在团队、组织间大规模推广，有效提升生产力。

3. 忽略「数据孤岛」的治理

工具、流程的背后，其实是数据。数据为研发、测试、运维、决策者等角色，提供诸如变更代码质量如何、安全如何等的直观感受。

但软件研发流程的每个阶段都有很多数据产生，如果不能够被有效整合，就容易形成 “数据孤岛”，让 “数据驱动决策” 成为口号。

另外更为重要的是，所有数据应该 “左移”，让研发、测试、安全等第一责任人在第一时间掌握现状，对于有问题的代码进行及时修复，降低修复成本。

4. 安全「扫而不修」，无法「安全闭环」

为确保汽车软件安全交付，常规的思路是选择安全工具进行扫描，但往往只扫描，不修复，因为缺少完整的机制来落地「安全扫描 → 漏洞管理 → 安全修复」的闭环。

汽车行业 DevOps 的最优解

因此，一个适合汽车行业使用场景、满足汽车软件需求，且能帮助车企快速完成「软件定义汽车」转变的 DevOps 平台，应该满足：

• 一体化：方便所有人员在同一个平台上协作、所有信息公开透明，有效消灭「数据孤岛」；

• 体系化：能够屏蔽工具细节，直接为用户提供开箱即用的 DevOps 能力，构建体系化、标准化的 DevOps 流程；

• 安全可控：确保软件安全左移，及时修复，落地「安全闭环」。

极狐 GitLab ，安全的企业级一体化 DevOps 平台。

从 2011 年面世之初的源代码托管工具，已经演变成为集项目管理、源代码托管、CI/CD、DevSecOps、GitOps 等能力于一身的一体化平台，实现高质量软件创新落地。

1. 极狐 GitLab workflow，标准化敏捷研发流程，提升研发效率

极狐 GitLab workflow 将需求管理、代码变更与托管、CI/CD、安全扫描、代码准入融合在一起，在一个流程上完成代码变更到上线，兼顾效率和质量。

这种 workflow 让研发流程规范化、标准化，减少了软件研发的无序和混乱，节约了不同角色之间的沟通、协作成本，可极大提升研发效率。

2. 版本控制，实现变更可追溯、可审计

极狐 GitLab 版本控制功能，能够实现对文件、代码的版本控制，记录每次变更的时间、范围、变更人员等信息。在后续的故障回溯、安全审计中，可以快速查阅对应信息。

3. 极狐 GitLab CI/CD，为软件研发提速

极狐 GitLab CI/CD 无需安装第三方工具即可使用：

• 只需要通过创建 .gitlab-ci.yml 文件，并且使用内置的关键字完成 YAML 文件的编写即可使能 CI/CD Pipeline；

• 内置的 include 语法能够减少 CI/CD Pipeline 的冗余，便于 CI/CD Pipeline 的维护与快速构建；

• 多种流水线类型，注入父子流水线、多项目流水线、合并请求/结果流水线等，方便不同规模团队、不同应用场景的使用。

4. 安全可控，为车企软件构建安全生命线

极狐 GitLab 的安全表现在多个方面：

• 私有化部署，保护代码安全

极狐 GitLab 支持私有化部署，方便用户在数分钟之内快速构建起可用的极狐 GitLab 实例，同时，所有数据都在用户侧，确保数据安全可控。

• 安全审计，防止核心资产外泄

极狐 GitLab 内置安全审计功能，对于代码的相关操作会都会有对应的审计事件。通过对审计事件的监控，可防止代码核心资产的外泄。

• DevSecOps，构建应用纵深防御体系

DevSecOps 是 Security 与 DevOps 的结合，意味着在软件研发的每个阶段，都嵌入对应的安全防护手段，构建纵深防御体系。

极狐 GitLab DevSecOps 提供敏感信息扫描、依赖项扫描、SAST、DAST、容器镜像扫描、License 合规以及模糊测试等安全防护手段，提供从静态到动态的安全防护能力，同时所有的扫描报告会统一展示，并且嵌入到对应的 MR 下，实现真正的安全 “左移”。

软件定义汽车的征途刚刚开始，产业链条正在日趋完善，相信支撑软件定义汽车的研发团队通过实践 DevOps，将推动汽车产业加速驶入“软件定义汽车”时代。