嵌入式系统开发中的静态分析

由于嵌入式系统行业的快速发展，嵌入式设备的代码质量成为首要关注的问题之一。考虑到嵌入式系统开发的特殊性（调试困难、出错成本高等），开发人员需要使用专门的工具来提升自己的代码质量。

静态代码分析器就是这些工具之一。本文描述了静态分析以及它如何在嵌入式系统中受益。

静态代码分析

首先，让我们弄清楚静态代码分析器是什么以及它们可以执行哪些功能。

静态代码分析器是分析程序而不实际执行它的软件。静态分析工具比编译器对源代码进行更深入的检查。通常，编译器只发现语法错误。

静态分析工具的工作原理：

分析器的输入数据是源代码（最好是可编译的）

分析器将源代码转换为特殊模型以供进一步分析（AST、语义模型等）；

分析器通过对模型应用一组诊断规则来搜索缺陷。诊断规则基于各种方法；

分析仪以方便您的格式保存所有发出的警告；

开发人员只需要研究报告并修复所有缺陷；

利润！

静态分析仪可以执行广泛的任务。让我们介绍分析器最常见的任务：

程序代码中的错误检测。在这种情况下，静态分析极大地补充了代码审查。它允许您在您和您的同事开始繁琐的代码审查之前发现并解决许多问题；

广义上的代码质量增强。代码质量可以包括可读性、可维护性、代码复杂性、内聚程度以及可以直接或间接影响错误数量的其他方面。因此，静态分析器有助于遵循编码标准（在公司内接受并普遍接受）；

代码分析作为 CI/CD 中质量门机制的一部分。分析器不仅可以警告代码中的潜在错误，还可以作为一种保护机制。如果代码质量水平不符合规定的要求，他们就会停止持续交付。如果检测到错误或不符合标准的代码片段，此类代码分析器会扩展编译器行为并阻止构建；

项目指标的收集、统计数据的收集、反映项目“总体健康状况”的图形和图表结构。

实施效益

静态分析器已被证明对嵌入式软件非常有用。让我们看看静态分析最明显的积极方面。

首先，静态分析的使用减少了昂贵的（如果不是不可能的话）已经发布的设备“闪烁”的可能性。

嵌入式系统软件中的错误非常麻烦。问题是一旦开始大规模生产，这些错误就不可能或几乎不可能纠正。假设一家公司已经生产了数千台洗衣机并将其交付给商店。但是，结果机器在某种模式下无法正常工作。公司应该怎么做？一般来说，这个问题是修辞性的，有两种实际选择：

顺其自然，在各个网站上收到负面的客户反馈，破坏声誉。当然，公司可以发布并发送手动添加说“不要这样做”。然而，这是一个“弱”的选择；

退出销售机器并开始更新固件。这是一个昂贵的选择。

发布多少设备并不重要。修复错误可能有问题，甚至为时已晚。火箭坠毁——错误被发现，但为时已晚。患者死亡——错误被检测到，但它不会让人们回来。导弹防御系统的目标精度损失- 检测到错误，但损坏已经造成。汽车休息不起作用- 检测到错误，但这无助于车祸受害者。程序错误的代价是可怕的，不是吗？

结论很简单：嵌入式设备的代码应该尽可能彻底地测试。特别是如果错误可能导致人员伤亡或巨大的经济损失。

静态代码分析是检测错误的过程，但它不保证会发现代码中的所有错误。但是，开发人员应该利用任何机会额外检查代码的正确性。静态分析器可以指出即使在多次代码审查之后仍然存在的各种错误。

如果静态分析可以帮助减少设备代码中的错误数量，那就太棒了。也许这些特殊错误的发现将防止生命损失。或者，也许这些公司不会浪费很多钱，也不会因为客户投诉而失去良好的声誉。

其次，静态代码分析器显着降低了软件测试和调试过程的成本。

静态分析允许您在编码期间或夜间构建期间发现错误。结果，大多数错误的搜索和修复可以便宜得多。

可能每个开发人员都尝试过“刷新”设备，但没有成功。例如，在此过程中，设备没有设置正确的电压或完全烧坏。发生了什么，您在哪里寻找问题？毕竟，不仅仅是软件错误可能是问题的根源。也可能是硬件本身的错误或质量差的布局。因此，发现错误的过程可能需要很长时间。

最悲伤的场景：

开发人员 100% 确定他编写的代码是正确的；

电路工程师和其他负责硬件的同事参与了该项目；

寻找问题的过程缓慢而费力；

开发人员再次查看代码并突然发现 - 一个错字；

超级低效浪费队友的精力和时间；

这很尴尬和不愉快。

由于以下原因，可能会弹出此类错误。在正在进行的项目中，开发人员使用了他的旧做法，他需要至少适应项目。例如，他可以编写以下代码片段：

uchar Arr［3］;

。..。

for （uchar idx = 0; idx ！= 4; idx++）

avg += Arr［idx］;

avg /= 3;

这个错误的背景如下。开发人员以他之前的开发为基础，代码主要是使用复制粘贴方法编写的。他没注意，忘了把4换成3在一行。结果，他在访问位于数组边界之外的索引时出现了未定义的行为。这样的代码可能是阴险的。程序在调试过程中可以正常工作。但是，在实际情况下，当客户端多次运行它时，它可能会崩溃。如果静态分析器发现这样的错误，那就太好了。

因此，为避免调试过程曲折而费力，在刷机之前尽可能多地检测出缺陷位置非常重要。

第三，静态分析的使用保证了没有太多经验的开发人员。

程序错误可以形象地分为两种类型。开发人员知道第一种类型的错误。由于疏忽，这些错误意外地出现在代码中。第二种错误出现在开发人员根本不知道不可能以这种方式编写代码的情况下。换句话说，他们可以随心所欲地查看此类代码，但仍然不会发现错误。

静态分析器包含有关各种代码模式的知识库。在某些情况下，这些模式会导致错误。因此，他们可以指出开发人员自己不会发现的错误。一个例子是使用 32 位 time_t 类型，这可能会导致设备在2038之后无法正常工作。

另一个例子是程序的未定义行为，这是由于不当使用移位运算符《《/》》而发生的。这些运算符在微控制器的代码中被广泛使用。不幸的是，开发人员经常非常粗心地使用这些运算符。这使得程序不可靠并且依赖于编译器的特定版本和设置。同时，程序可以运行，但这不是因为它的代码写得对，而是因为开发者很幸运。

使用静态分析器，开发人员可以对冲许多此类不愉快的情况。此外，您可以使用分析器来控制整体代码质量。当项目的团队正在成长或变化时，这一点很重要。换句话说，分析器有助于跟踪初学者是否开始编写糟糕的代码。

第四，现代静态分析器不仅能发现代码错误和漏洞，还支持嵌入式系统的编码标准。这些标准提高了程序的安全性、可移植性和可靠性水平。

C 和 C++ 被称为嵌入式系统的流行编程语言。MISRA C、MISRA C++ 和 AUTOSAR C++ 等标准是为这些语言开发的。每个标准都有相当多的规则和建议（MISRA C：143，MISRA C++：228，AUTOSAR C++：超过 350）。在没有静态代码分析器的情况下编码时，根本不可能遵守这么多的规则和建议。这些规则是开发人员需要避免的编码模式，从而减少出错的可能性。目前，所有主要的静态分析参与者（Coverity、Klockwork、PVS-Studio，。..）都在努力尽可能地增加标准的覆盖范围。

编码标准

MISRA 的历史始于很久以前。回到 90 年代初，“安全 IT”英国政府计划为各种与电子系统安全相关的项目提供资金。MISRA（汽车工业软件可靠性协会）项目本身的成立是为了创建用于开发陆地车辆微控制器软件的指南 - 主要是汽车。

MISRA（作为一个组织）是一个由来自各种汽车和飞机行业的利益相关者组成的社区。

宾利汽车；

福特汽车公司；

捷豹路虎；

德尔福柴油系统；

堀场米拉；

千变万化电气；

伟世通工程服务；

利兹大学；

英国里卡多；

采埃孚天合。

非常强大的市场参与者，不是吗？毫不奇怪，他们的第一个与语言相关的标准 MISRA C 在关键嵌入式系统的开发人员中获得了广泛的认可。不久之后，出现了 MISRA C++。逐渐地，标准的版本已经更新和修订，以涵盖语言的新功能。目前，当前版本是 MISRA C： 2012 和 MISRA C++： 2008。

MISRA 最显着的特点是其对细节的难以置信的关注和在确保安全和安保方面的极度细致。作者不仅将所有 C 和 C++ 缺陷集中在一个地方（例如 CERT 的作者）。他们还仔细制定了这些语言的国际标准，并写出了所有可能出错的方法。之后，他们添加了关于代码可读性的规则和建议。毕竟，在简单易读的代码中更难出错，在 Code-Review 期间更容易发现错误。

通常，第一次遇到 MISRA 的人会觉得该标准的目的是“禁止这个和禁止那个”。事实上，确实如此，但只是部分如此。

该标准确实有许多禁止某些行为的规则。但是，这并不是要全面禁止，而是要列出所有可能导致安全漏洞的方式。对于大多数规则，您自己选择是否需要遵守它们。让我更详细地解释一下。

MISRA C 规则分为三个主要类别：强制、必需和建议。在任何情况下都不得违反强制性规则。例如，本节包括规则：“不要使用未启动变量的值”。所需的规则不那么严格。它们允许偏差的可能性。但是开发人员需要以书面形式证明这些偏差的合理性并详细记录它们。其余规则属于咨询类别——它们是非强制性的。

MISRA C++ 有点不同：没有 Mandatory 类别，大部分规则属于Required 类别。因此，事实上，您有权违反任何规则——只是不要忘记记录偏差。还有文档类别。它包括与一般实践相关的强制性规则（不允许有偏差），例如“必须记录汇编程序的每次使用”或“包含的库必须符合 MISRA C++”。

该标准既包含对问题问题的描述，也包含在承担某项任务之前必须了解的提示：如何根据 MISRA 设置开发流程；如何使用静态分析器检查代码的合规性；一个人必须维护哪些文件，如何填写它们等等。

目前，MISRA 不断发展。例如，MISRA 在 2019 年初发布了《MISRA C:2012 第三版（第一次修订）》。这是 MISRA C:2012 版更新和扩展了新规则。同时，即将发布的《MISRA C： 2012 Amendment 2 – C11 Core”公布，这是 2012 年的修订标准。

MISRA C++ 也不会停滞不前。如您所知，MISRA C++ 的最后一个标准可以追溯到 2008 年，因此它所涵盖的语言的最新版本是 C++03。正因为如此，还有一个类似于MISRA的标准，它的名字叫AUTOSAR C++。它最初旨在作为 MISRA C++ 的延续，并旨在涵盖该语言的更高版本。与其策划者不同，AUTOSAR C++ 每年更新两次，目前支持 C++14。新的 C++17 和 C++20 更新尚未到来。

结论

在本文中，我想说明使用静态分析器对任何嵌入式项目都绝对有用。使用静态分析将帮助您：

减少查找和修复错误所需的时间；

减少严重错误的可能性；

减少对固件更新的需求；

监控整体代码质量；

监控新团队成员的表现；

严格遵守一定的软件开发标准；

监控第三方模块/库的代码质量。

审核编辑：郭婷