MISRA C++ 代码合规性如何确保功能安全和质量？ [关闭]答案

【问题标题】：How does MISRA C++ Code Compliance ensure Functional safety and Quality? [closed]MISRA C++ 代码合规性如何确保功能安全和质量？ [关闭]
【发布时间】：2021-02-04 14:08:24
【问题描述】：

谁能向我解释 MISRA C++(2008) 如何不符合功能安全 (ISO 26262)，如果它真的符合哪些规则有助于功能安全？是否有文件或证据表明 MISRA C++ 符合 ISO26262 和 AUTOSAR？对于质量保证，遵循 MISRA C++ 编码标准对软件开发代码有什么保证

【问题讨论】：

"如果我盲目地遵循这个编码标准，我会合规吗？"可能不是。采用诸如 MISRA 之类的编码标准将帮助您实现合规性，让您远离语言中更具爆炸性的部分。但这只是其中的一小部分，最终是您的代码必须符合要求，编码标准与否。
我们面临的最大问题之一是 QA 经理（或类似人员）要求 100% MISRA 合规且没有偏差 - 当我们（在 MISRA 中）定义需要时的偏差过程！盲注是有缺陷的！
@Andrew 我在实施 MISRA-C 时的建议是实施公司标准并要求 100% 符合该内部标准。这样，您可以禁止个人偏差，但允许将公司范围内的偏差作为编码标准文档的一部分。然后相应地配置 MISRA-C 检查器，仅删除对公司范围偏差的检查。根据我的经验，它非常有效，因为每当有人提出偏离的想法时，你都会强迫其他人进行讨论和审查。我不会相信个别程序员会这样做，除非他们非常有经验。
是的......完全同意@Lundin。重要的是你偏离规则的地方，你知道为什么和后果是什么......以及采取什么额外的补救措施（例如增强测试）
我目前无法访问这些标准，但通常 ISO 26262 将“语言子集的使用”列为所有 ASIL 级别的强烈推荐内容。通常，这些标准也有一个合适的编程语言列表。传统上，只有具有安全子集的 C（MISRA-C 等）或具有安全子集的 Ada（SPARK Ada 等）被认为适用于安全关键系统。我不知道这些年来游说者是否改变了这一点，但我怀疑工程师或专家是否会批准 C++。我会将所有此类适用性声明视为销售工具的骗局。

标签： c++ coding-style misra software-quality autosar

【解决方案1】：

正如 MISRA C 和 MISRA C++ 自己所说，它们要求开发成为记录在案的软件开发生命周期的一部分 - 它们（它们自己）不能保证您的系统正常工作。

MISRA C/C++ 满足 ISO26262 的许多要求...但这是一个相当冗长的话题，而且 StackOverflow 不是给出完整答案的理想场所，因为它非常依赖于上下文。

作为一个涉足两个阵营的人（请参阅简介），我已经在 ISO 26262 上下文中就MISRA C做了几次演示（同样适用于 MISRA C++）。例如：

https://www.slideshare.net/AdaCore/misra-c-in-an-iso-26262-context

（提前为公司的胡言乱语道歉！）

但由于您还提到了 AUTOSAR Adaptive - 这需要符合 MISRA C++

https://www.autosar.org/fileadmin/user_upload/standards/adaptive/18-10/AUTOSAR_RS_CPP14Guidelines.pdf

5.1.1 根据与 MISRA 的兼容性进行规则分类
本文档中的规则被定义为 MISRA C++:2008 的“增量”

【讨论】：

您知道 ISO 26262 是否扩展了合适的编程语言列表以包括“带有子集的 C++”？ “父”标准 IEC 61508 尚未完成此 AFAIK。
61508 目前正在修订中......我没有参与，并且不知道 C++ 是否被提及。 26262:18 没有明确提到 C++，鉴于 AUTOSAR 自适应是 C++，这可能是一个惊喜，但话又说回来，它不要求任何特定的语言......适用 26262-6 第 5.4 段。
我想到的是相当于 IEC 61508-7 表 C.1 的合适语言表。对于更高的 SIL 级别，“强烈建议”仅使用具有安全子集的语言。我的 IEC 61508-7:2000 版本根本不包含 C++。
在 2000 年（早于 MISRA C++）C++ 被认为是不合适的......随着 2005 年 JSF-AV 编码标准的出现（基于 MISRA C，作为垫脚石MISRA C++ 背后的一些人并让他们参与其中）将其带入了对安全至关重要的主流......
@VaishnaviS 我个人的看法是，C++ 是一种非常危险的语言，不应该被允许接近任何对安全至关重要的项目。如果要创建 C++ 的安全子集，则必须禁止 90% 的语言。如果它没有被 ISO 26262 列出，那么这很有意义。使用 C 已经够糟糕了，但至少 C 的所有缺陷都是众所周知的。

【解决方案2】：

MISRA C++ 代码合规性如何确保功能安全和质量？

我倾向于认为它不能确保安全或软件质量。它确实贡献（在其他更重要的因素中，包括项目管理、开发人员的工作经验、分配给code refactoring ....的努力）。

这是一个人的过程。它可能会失败。很有帮助。

您可以使用软件静态或动态分析工具（如Frama-C、Bismon、Clang static analyzer、Fluctuat、AbsInt、Astrée、Cadna、Cadna、CompCert、或使用最近的 GCC 编译器 with gcc -Wall -Wextra -fanalyzer 甚至可能编写自己的 GCC plugin 等...）但归根结底，您需要人工合作和 code reviews。

另请参阅 DECODER、VESSEDIA（或 CHARIOT）等项目。

注意Rice's theorem。

请记住，Boeing 737 MAX 崩溃涉及软件问题（但不仅仅是）。

请注意，主要的 C++ 编译器（包括 GCC 和 Clang）不兼容 MISRA C++。它们的一些改进版本已经过认证。而且 GCC 和 Clang 大多是用 C++ 编写的...

一些关键软件（例如 Recovid 的软件部分 - COVID 呼吸机 - 法国的开放硬件/开放软件）未通过 AFAIK 认证（但已通过其他标准认证）

例如规则

规则 M0-1-1（必需、实施、自动化）项目不应包含无法访问的代码。

真的很难证明（仅通过检查或自动分析源代码）。

【讨论】：

737MAX不是软件问题...这是一个有缺陷的系统设计问题，其中软件完全按照指定的情况执行。不幸的是，系统规格是错误的，传感器不适合飞行关键程度:(
此答案与 MISRA-C++ 或 ISO 26262 无关，因此无法回答问题。
引用技术标准的部分内容或仅将章节作为来源并不侵犯任何版权。否则一半的 SO 将被 ISO 关闭。
@VaishnaviS 有（昂贵的）程序可用于 ISO 26262 需求跟踪。您可以将每个要求与您自己的指令、测试等联系起来，从而证明合规性。无论哪种情况，您都需要编写大量文档，但此类工具可能会为您节省一些文书工作。
“项目不应包含无法访问的代码”可以通过动态分析来证明，这就是在最关键的系统中的做法。也就是说，您必须在记录程序计数器时通过所有可能的用例来处理实时程序。然后，您只需将执行的行与 C 源代码和/或机器代码进行比较。这一点也不难证明，尽管将动态分析工具与您的项目集成起来很麻烦。其他的方法是正式的方法，但这不是我个人使用过的方法。