MISRA合规性的五个实用技巧，MISRA

数十种工具旨在告诉您您的 C 或 C++ 代码是否违反 MISRA 规则。但是，虽然识别和解决分析工具标记的违规行为对于单个开发人员来说可能是一项重大挑战，但它仅代表整个开发团队合规流程的一部分。

事实上，让许多人感到惊讶的是，MISRA C:2012 文档在定义指南之前就包含了六章指南！

回过头来对违规行为进行详细分析，很容易看到关于整个过程的更大问题。MISRA 的文档“MISRA 合规性：2016”比语言子集本身受到的新闻报道要少得多，但它对于了解您选择的静态分析工具突出显示的信息如何与 MISRA 合规应用程序的大局相关联非常宝贵。

很容易误解 MISRA 合规性的性质，并假设最小化的违规计数可确保优化的应用程序安全性。但要有效，MISRA 指南需要在一个框架内应用，该框架利用合规代码的优势并管理任何必要的偏差，以使合规概念具有可信度。

MISRA 合规性：2016 文档长达 33 页，像这样的短文无法触及它讨论的所有内容。但是，它可以让我们深入了解合规项目的外观。这些提示源自 MISRA 合规性文件本身概述的原则，它们反映了一点技术智慧和很多常识。

提示 1. MISRA 合规性需要记录在案的软件开发过程

MISRA 指南旨在用于正式软件开发过程的框架内（如图 1 所示）。这样的过程将确保完整、明确和正确的软件需求，并且所有且仅这些需求都反映在开发生命周期的每个阶段创建的人工制品中。

图 1：结构化开发生命周期对于 MISRA 合规性至关重要，如 LDRA 工具套件的 TBmanager 组件中的“Uniview”所示。（来源：LDRA）

如果您的代码没有违反规定但没有满足其要求的功能，那么它仍然是糟糕的代码。

提示 2. 并非所有 MISRA 指南都可以通过分析工具进行检查

MISRA C:2012 指南引入了一个系统，在该系统下，每条指南都被分类为规则或指令。

通常，规则定义得足够好，可以通过自动化工具进行检查，而指令可能更主观一些。例如，MISRA C:2012 的指令 1.1 要求“程序输出所依赖的任何实现定义的行为都应记录并理解”。

在 MISRA C:2012 中，一些规则被标记为“不可判定”，这意味着基本上不可能有一种方法可以确定是否存在违规行为。工具可能会警告潜在的问题，也可能不会。无论哪种方式，都需要某种程度的人工干预。

并非所有工具都相同。有些人会声称对规则的覆盖范围比其他人多，而有些人则无法进行更微妙的侵权。显示“无违规”的工具可能实际上是在说“没有违规，除了我没有发现的那些”。

牛津词典对“工具”的定义是“用来帮助完成工作的东西”。工具有帮助——它们不会为你完成这项工作。

提示 3. 指南只有在有执行计划时才有用

对于大多数指南，最简单、最可靠和最具成本效益的实施方式是使用静态分析工具、编译器或两者的组合（参见图 2）。

图 2：使用 LDRA 静态分析工具强制遵守 MISRA C:2012（来源：LDRA）

对于这些指南，重要的是要确保要使用的工具已被证明是合适的，并且它的类型和版本是指定和固定的。

对于那些需要手动验证的指南，还必须制定执行计划。

提示 4. “偏差”不是一个肮脏的词

对于任何现实生活中的嵌入式应用程序，很可能一些违规行为是不可避免的。如果对由此产生的应用程序的任何合规性声明是可信的，则必须通过明确定义的流程授权管理这些违规行为，并由适当的“偏差记录”文档支持。

这些偏差记录需要包括违反的准则、这种/这些违反的理由、偏差适用的情况以及它在代码库中的应用位置。

Tip 5. 采用的代码不能被忽略

与功能安全的嵌入式软件相关的许多文档和许多标准都是从“绿地”项目的假设开始的。在现实生活中，开发人员需要利用内部遗留代码或第三方代码，例如设备驱动程序、数学库或图形库。

尽管将 MISRA 准则追溯应用于此类代码显然是不切实际的，但要声称符合 MISRA，重要的是要确保这种所谓的“采用的代码”不会损害整个系统的安全性。

许多根据 ISO 26262、IEC 61508 和 DO-178C 等标准开发的功能安全系统都利用 MISRA 语言子集，这并非巧合，而且很容易假设 MISRA 合规性仅适用于这些环境。

但那将是谬误。同样真实的是，除了语言子集本身的指导方针之外，在 MISRA 合规之前要满足的许多基本要求可以合理地归结为一种常识方法，以及对“正确行事”的奉献精神。这不能是关键系统社区的专属特权，因为系统在有动力可靠地工作之前不必是关键的。

审核编辑：郭婷