通过 Polyspace 静态代码分析简化 ASPICE、ISO 26262 和 ISO/SAE 21434 的遵循过程

在当今汽车的安全性、可靠性和效率方面，汽车软件系统发挥着日益重要的作用。为此，工程团队需要专注于为高级驾驶辅助系统 (ADAS)、电池管理系统、稳定性控制和类似应用提供创新功能。此外，他们往往还需要证明符合 ISO^® 26262 和 ISO/SAE^® 21434 标准，以此确保满足功能安全和网络安全要求。

作为一家全球顶级汽车供应商，Ficosa International 致力于开发适用于各种汽车应用的软件。在为确保符合行业标准而建立的流程中，我们的工程团队使用 Polyspace^® 静态代码分析产品来衡量并提升代码质量，并将这一做法贯穿于从实现到单元验证、集成和鉴定测试的整个开发生命周期。我们使用的许多流程都是依据一组明确定义的软件质量目标建立的。这些目标围绕着正在开发的组件的关键程度和项目的成熟度而制定。软件质量目标清楚地阐明了 Polyspace 静态分析度量和编码规范（如 MISRA™ 和 CERT^®/CWE™）的验收标准和阈值，以及运行时错误。目前，在每次进行软件更改时，都会自动评估并强制实施这些标准，作为我们软件开发过程不可或缺的一部分。因此，我们最大限度地减少了代码质量评估的主观性，同时提高了整个软件开发生命周期的总体开发效率。

Ficosa International 的 Polyspace 使用历程

2010 年，我们开始研究一个与车辆通信模块有关的项目。作为此项目要求的一部分，我们需要利用静态分析来检查 MISRA C™ 合规性。经过对市售静态分析产品的全面评估，我们根据性能和成本选择了 Polyspace 产品。与此同时，我们还在逐步实现 Automotive SPICE^® (ASPICE) 能力 2 级合规性。我们开始使用 Polyspace Bug Finder™ 和 Polyspace Code Prover™ 进行静态分析，从而为软件单元验证活动提供支持。

很快，我们的工程团队就开始涉足 ADAS 的其他领域。客户也开始要求我们实现 ASPICE 3 级合规性。我们同时启动了多个项目，这些项目要求满足 ISO 26262 的功能安全标准。不久之后，我们的一些客户又开始要求进行 CERT C 合规性和常见弱点枚举 (CWE) 检查，以确保符合安全编码标准；具体到我们的情况，客户要求实现 ISO 21434 合规性。

Polyspace 产品的静态分析有助于我们支持上述各项活动。但从组织的角度来看，我们缺乏全面的计划，以明确定义我们为了确保软件质量要在开发和验证活动中应用的方法、度量和阈值以及何时应用它们。没有形式化框架的一个缺点是，开发团队往往要等到项目后期才执行静态分析，而不是从项目伊始就系统化地执行这项分析。如果仅在开发后期进行静态分析，其结果就可想而知了，一定包含许多违规行为，其中包括诸多不符合 MISRA C 的情况。由于在发现问题时项目已经接近尾声，因此，很难通过解决这些问题或证明其合理性来纠正如此多的违规行为。

为了应对这一挑战，我们抓住了 2020 年新冠疫情期间活跃项目相对空闲的机会，全面分析了 Ficosa International 如何才能在可靠性、功能安全和网络安全等多个方面最好地实现我们自己和客户的软件质量目标。根据此分析，我们最终得到了一个软件质量目标文档。目前，我们的团队使用该文档作为确保所交付软件系统质量的依据。

制定软件质量目标

在 Ficosa International 的软件质量目标文档中，我们定义了在验证我们开发的软件时应用的各种度量和规则，包括基于 MISRA C、CERT C 和 CWE 的度量和规则，以及圈复杂度和注释密度等软件度量。

接下来，我们根据所验证代码的来源、正在开发的组件的类型及其成熟度定义了应用度量和规则的标准。

例如，我们针对第三方代码、现有代码、自动生成的代码和手写代码制定了不同的目标（图 1）。对于第三方代码，我们只运行强制性的 MISRA C 规则，并假设这种类型的代码附带其他补充性质量证据。而对于现有代码、生成的代码和手写代码，我们强制实施越来越严格的规则集。根据 ISO 26262 的汽车安全完整性等级 (ASIL) 要求和 ISO/SAE 21434 的网络安全保证等级 (CAL) 要求，在功能安全或网络安全方面受到影响的组件需要进行额外的检查。

此外，在组件从早期开发（“A 样本”）阶段推进到中间阶段、倒数第二个阶段和最终交付（“B、C 和 D 样本”）阶段的过程中，我们还针对项目制定了更严格的目标。最后，对于集成的代码，我们提供了单独的精简规则和度量子集。也就是说，一组通过各自软件质量目标评估的组件现在可合并成为更大系统的一部分。这在简化复杂软件的静态分析时非常有用。

将静态分析集成到开发工作流中

我们一旦拥有明确定义软件质量目标的文档，就开始使用 Polyspace 静态分析产品将这些目标集成到我们的开发和测试过程中（图 2）。

在此过程中，一个关键步骤是当开发人员在 Git™（我们的版本控制系统）中发出拉取请求时引入了一项要求。为了使拉取请求获得批准，除了单元测试之外，代码还必须成功通过 Polyspace Bug Finder 和 Polyspace Code Prover 的某些静态分析检查。这一变化使得我们的整体工作流得到了显著改进，因为它建立了一种门控机制，确保开发人员只有在根据适当的软件质量目标彻底验证其代码，并解决静态分析期间识别的任何问题或证明其合理性后，才能成功完成拉取请求。

在软件集成和测试期间，可以使用 Polyspace 产品根据集成代码的软件质量目标执行静态分析。在此阶段，仅基于系统级规则和集成的软件度量，对 MISRA C 合规性和代码度量执行检查。特别要关注集成级别的问题，如共享内存的并发访问、死代码和关键运行时错误。

随着我们越来越多地使用 Jenkins 来实现持续集成和持续交付 (CI/CD)，Polyspace 产品支持的频繁静态分析和持续反馈将发挥重要作用，可确保我们的开发人员和集成商使源代码与软件质量目标保持一致。此外，通过 Polyspace Access™ Web 界面，我们所有团队都可以访问集中式数据库以查看静态代码分析结果，并监控达成交付质量目标水平的进度。

开发功能安全产品时，需要考虑的另一个重要方面是，确保软件工具不会在大规模生产软件中引入错误或无法检测到错误。ISO 26262 明确要求执行软件工具鉴定过程，以根据工具的关键程度对其进行分类，并执行必要的活动来鉴定他们。对于 Polyspace 产品，MathWorks 提供了一个认证套件，可为 Bug Finder 和 Code Prover 提供项目级支持。

主要优势

在根据 ISO 26262 和 ISO/SAE 21434 标准开发和交付汽车软件的过程中，使用 Polyspace 产品依据明确定义的软件质量目标为 Ficosa International 带来了诸多重要优势。

其中一个优势是，我们开发人员的开发技能得到了稳步提升。Polyspace 产品能够提供详细及时的反馈，帮助开发人员了解如何以及从何处提高代码质量，进而使他们成长为更娴熟也更高效的开发人员。事实上，根据我们现有的流程，开发人员别无选择，只能了解并解决通过静态分析检测到的问题。

我们获得的另一个重要优势是，简化了 ASPICE 和 ISO 26262 的外部质量评估或其他客户要求的合规性目标。如今，我们所做的一切都更容易得到验证，因为我们有明确的软件质量目标以及相应的报告（例如说明 MISRA 和 CERT 偏差问题比过去少得多），还有证明我们的代码已通过客观质量标准的证据。

也许，最重要的是，Polyspace 产品帮助我们实现了质量目标，同时提高了效率（或至少保持效率不变）。通常，当治理团队或类似小组更改他们所在组织的开发工作流，引入我们所实施的那种早期验证步骤时，开发人员会将他们需要完成的附加步骤视为额外工作。然而，借助 Polyspace 产品，我们能够向我们的团队证明，为每个拉取请求执行静态分析的附加步骤实际上提高了他们的效率。他们可以更高效、更自信地交付高质量的代码，因为通过静态分析发现的所有错误都在开发过程的早期阶段得到了消除，而不必等到最后阶段才来解决。