汽车软件CI/CD — 与Web开发截然不同的挑战

汽车软件也需要CI/CD吗？

在汽车软件开发中尝试应用CI/CD时，会遇到与一般Web/App开发截然不同的问题。Web服务只需提交代码、运行测试、部署即可，但汽车软件没那么简单。

尽管如此，CI/CD已不再是可选项。一辆车搭载的软件代码量达数亿行，数十个ECU同时开发——在这种情况下，手动构建和手动测试根本无法赶上进度。特别是进入SDV（Software-Defined Vehicle）时代后，OTA更新、功能添加、安全补丁在量产后仍需持续进行，没有自动化流水线就无法维持持续的软件运营。

本文将探讨在汽车软件开发中应用CI/CD时实际面临的问题，以及如何解决这些问题。

与Web CI/CD有何不同

初次构建汽车软件CI/CD的团队最常犯的错误是：直接将Web开发中使用的Jenkins流水线照搬过来。当然基本概念是一样的——代码变更 → 构建 → 测试 → 部署。但每个阶段的复杂度完全不同。

交叉编译与目标多样性

Web服务通常部署到x86 Linux服务器。汽车则不同。需要为基于ARM的ECU、各种RTOS、运行在虚拟化层上的软件进行交叉编译。每个目标板的构建配置不同，BSP（Board Support Package）也不同。仅在CI服务器上管理所有这些组合就需要相当的基础设施。

测试环境的差异

Web服务测试只需启动一个Docker容器。汽车软件没有实际ECU很难测试，即使有实际ECU也需要物理连接和网络配置。HIL（Hardware-in-the-Loop）设备昂贵且作为共享资源，无法在CI流水线中自由使用。

因此，基于Virtual ECU（虚拟ECU）的SIL（Software-in-the-Loop）测试变得越来越重要。在CI流水线中自动生成虚拟ECU并行执行测试，即使没有HIL设备也能实现相当水平的验证。

构建时间

如果说Web前端构建需要2-3分钟，那么基于AUTOSAR的ECU软件完整构建通常需要30分钟到1小时以上。在CI中每次提交都运行完整构建会导致流水线瓶颈。增量构建、缓存策略、基于变更影响分析的选择性构建是必不可少的。

开发环境管理这一隐藏难题

在汽车软件CI/CD中，意外消耗大量时间的是开发环境管理。

工具链版本同步

一个项目需要编译器、AUTOSAR协议栈、代码生成器、静态分析工具、测试框架等数十种工具。如果这些工具的版本在开发者PC、CI服务器、团队成员之间不一致，"在我的电脑上可以构建"的问题就会反复出现。

特别是同步安全补丁和工具升级是一大挑战。一个团队升级了编译器，另一个团队的代码就可能出错；发现安全漏洞需要紧急打补丁时，要统一更新所有开发环境非常困难。

新开发者入职

新团队成员加入后，搭建开发环境花费数天是常见的事。AUTOSAR工具安装、许可证配置、构建环境设置、目标板连接——即使有文档，也会因OS版本或库冲突而反复试错。

通过基于Docker容器标准化开发环境可以大大缓解这一问题。将整个开发环境作为容器镜像管理，新团队成员只需拉取镜像即可立即开始开发，并且可以在与CI服务器相同的环境中进行本地开发。

安全认证与CI/CD

汽车软件CI/CD中最棘手的部分是与安全认证的关系。

ISO 26262工具资质

ISO 26262要求对安全生命周期中使用的所有工具进行工具资质认证（Tool Qualification）。CI/CD流水线中使用的构建工具、静态分析工具、测试框架也不例外。如果工具产生与安全相关的输出，就必须有该工具正确运行的证据。

这不仅仅是要求验证工具。CI/CD工具本身可能成为资质评估对象，每次更改流水线配置时可能需要进行影响分析。因此在安全相关项目中，CI/CD流水线的变更管理与软件变更管理同等重要。

静态分析自动化

MISRA C/C++合规在汽车软件中实际上是强制要求。将静态分析集成到CI/CD流水线中，每次代码提交时都能自动检测MISRA规则违规。这样代码审查时就无需逐一挑出风格问题，审查者可以专注于逻辑和设计。

不过，静态分析工具的执行时间可能较长，因此将仅分析变更文件的增量分析与分析全部代码的完整分析分开运行是实际可行的策略。提交时运行增量分析，夜间构建运行完整分析。

认证流程的瓶颈

安全相关系统需要广泛的验证。如果不自动化这些验证，认证流程本身就会成为项目瓶颈。手动执行测试、收集结果、生成报告、更新可追溯性矩阵，每次发布都要花费数周。

将验证自动化集成到CI/CD流水线中，每次构建都会自动生成测试结果和覆盖率报告，认证所需的证据会持续积累。到发布时不再是"当时运行的测试结果在哪里"，而是所有构建的验证记录都已存档。

ASPICE 4.0与DevOps

2023年11月发布的ASPICE 4.0为汽车软件开发方法论带来了重大变化。关于从3.1到4.0过渡的详细内容，请参阅ASPICE 4.0迁移指南。此前的ASPICE以V-Model为基础的顺序开发流程为前提，而ASPICE 4.0将范围扩展到明确包含Agile和DevOps方法论。

这不仅仅是文档更新。对于那些在OEM审核中烦恼"用Agile开发的话ASPICE评估怎么办"的团队来说，ASPICE 4.0提供了DevOps开发与ASPICE兼容的官方依据。

但这并不意味着"只要搭建CI/CD就完成了ASPICE 4.0合规"。ASPICE要求的是流程的系统化执行及其证据。CI/CD是自动生成和管理这些证据的工具，而非替代流程本身。

中央集中式HPC架构与CI/CD

近年来，汽车E/E架构正从分布式ECU结构向中央集中式HPC（High-Performance Computer）结构转型。将数十个ECU承担的功能整合到几台高性能计算机中。

这一变化对CI/CD也有直接影响。随着单个HPC上运行的软件规模增大，构建和测试的复杂度成比例增加。多个领域（ADAS、信息娱乐、车身控制）的软件需要在同一平台上集成，因此集成测试的重要性进一步提升。

主要云/IT企业开始提供SDV DevOps工具链参考架构，也是应对这一变化的行业动向之一。这意味着对面向汽车软件开发的专用CI/CD基础设施的需求正在增长。

实际工作中如何开始CI/CD

汽车软件CI/CD很难一次性完美搭建。分阶段推进是现实可行的做法。

第1阶段：构建自动化

从手动构建的自动化开始。代码提交后自动触发构建，构建失败时通知负责人——仅这一点就是巨大的改进。

第2阶段：集成静态分析

将MISRA C/C++静态分析加入CI流水线。提交时运行增量分析、夜间运行完整分析，可以减轻执行时间压力。

第3阶段：测试自动化

从单元测试开始集成到CI，逐步扩展到集成测试、SIL测试。利用Virtual ECU，即使没有HIL设备也能实现相当水平的自动化。

第4阶段：基于容器的环境标准化

用Docker容器标准化开发环境，确保本地开发与CI环境的一致性。

第5阶段：认证证据自动化

自动生成测试结果、覆盖率报告、可追溯性矩阵，实现ASPICE/ISO 26262认证应对的自动化。

PopcornSAR的CI/CD解决方案

PopcornSAR提供面向汽车软件开发的专用CI/CD工具和解决方案。

PopcornSAR支持基于Docker容器的开发环境标准化。整个开发环境以容器方式管理，保证团队环境的一致性，加速新开发者入职。CI/CD流水线可自动生成Virtual ECU，在多个虚拟ECU上并行执行测试，在降低HIL设备依赖的同时扩大验证范围。

PARVIS通过AI自动化强化CI/CD流水线的各个阶段。PARVIS-Coder自动化MISRA C/C++合规，集成到CI的静态分析阶段。PARVIS-Verify自动生成测试用例，投入CI/CD测试阶段。需求变更时自动识别受影响的测试并进行更新。了解更多请访问PARVIS产品页面。

AutoSAR.io支持ARXML配置文件的配置管理，使CI/CD工作流中的AUTOSAR配置变更得以系统化管理。

如需进一步了解汽车软件CI/CD搭建，请通过咨询页面随时与我们联系。