c++ - Boost 是否曾用于受监管的项目（FDA、FAA）？

Question

最近发表评论时，我发现自己说，根据我的经验，Boost 并未广泛用于受监管的行业（FDA、FAA）。事实上，我不知道有任何项目使用它或使用过它。不过，我意识到我的经验可能在这里有所欠缺，所以我想知道是否有人知道在医疗设备或航空飞行系统（照明、机舱控制、驾驶舱设备等）中使用升压的项目。

我不确定这是问它的正确地方（也许是其他一些 SO 网站），但我认为这是一个很好的起点。

这不是关于是否应该在这些领域使用 boost 的问题，而是关于是否有人知道它是否已被使用的问题。

编辑一些可能有助于澄清这一点的示例项目：飞机客舱照明系统、客舱管理系统、驾驶舱仪表、输液/食品/胰岛素泵、透析机、实验室诊断设备、血液中心数据收集系统等。有些是维持生命的或潜在的飞行关键，一些收集数据，一些收集用于做出医疗决策的数据等，但我相信所有这些都被 FAA/FDA 列为受监管的设备。

EDIT外部（没有随开发链提供）库通常被带入这些类型的项目以用于其他目的（图形库、驱动程序、USB 堆栈等）。这些被视为SOUP。使用 boost 将属于这种方法。有人知道以这种方式使用 boost 的项目吗？

EDIT Boost 是一个非常大的框架，包含多个组件。我正在寻找已在项目中使用的任何部分。例如“Boost smart pointers”或“Boost Enable”或“Boost Array”或“Boost Optional”等。但用于“整体”，而不是部分。不通过查看 Boost 代码和重新使用该想法来使用；用作系统的一个整体组成部分（即法律意义上的）。

这是问题的核心，因为以这种方式使用意味着必须处理处理 SOUP 的权衡。 这可能会将这个问题放在这个 SO 网站的范围之外......不确定。

Answer 1

我认为我们可以在这里得到的最佳答案是“是和不是”。我将尝试解释原因。

Boost 是许多组成库的巨大保护伞。其中一些以各种方式相互依赖（例如，当更高级别的库需要 Boost 的较低级别部分提供的功能时，例如 Type Traits）。这引发了对该问题的简单回答是否有用的问题，因为如果 Boost 的三个部分已在受监管的项目中使用，但它们与您想要使用的部分不同，那么了解这一点具有不小的价值。而且我们永远不会知道所有部分的完整答案，因为您无法证明是否定的（并且有太多部分无法期望“100% 是”的答案）。

Boost 正在（并且一直在）迅速发展。一直在添加全新的库。ASIO 是一个大公司，直到最近才出现。这使得回答这个问题变得更加困难，因为随着时间的推移，Boost 的某些部分还很年轻，并且没有像其他部分那样经过很好的测试。此外，现有库有时会经历向后不兼容的修订（例如不久前的“Boost Filesystem 3”）。

Boost 的许多部分最终不是通过传统的依赖项而是通过从 Boost 复制粘贴代码并可能修改它以适应项目（例如添加或删除对特定编译器的支持）。同样，Boost 的许多部分最终都在项目中，因为 Boost 是许多新 C++ 标准库功能的试验场，例如 shared_ptr (C++11) 和 unordered_map (TR1)。今天作为语言一部分的一些功能最初是 Boost 的一部分，所以很多人甚至在不知情的情况下使用了“Boost 代码”。

请注意，当代码在语言中转换为正式状态时，代码并不会变得更安全——GCC 存在相同概念的 Boost 等效实现中不存在的错误。在考虑诸如“我们应该允许在我们的项目中使用 Boost 还是应该将自己限制在编译器供应商提供给我们的东西”之类的实际问题时，这一点很重要。如果您正在考虑使用由您的编译器供应商最近实现的功能（例如，在过去一年内），您最好使用更成熟的第三方（例如 Boost）实现。

最后，因为这个问题的动力似乎是为了获得一些保证，即使用 Boost 对于生产项目来说并不是一个坏主意：我当然会说，总的来说，使用 Boost 是好的和好的，但需要注意的是Boost 的本地专家，他知道 Boost 的哪些部分不应该在您的域中使用。例如，Boost Spirit、Phoenix 和 Wave 是已经在 Boost 中使用了一段时间但很少有人真正深入理解的库的示例。使用您不完全理解的库代码（我们都这样做）是一回事，但使用地球上几乎没有人理解的代码则是另一回事。

总之，我认为没有人能够向您保证，您寻求 Boost 对于安全关键系统是可以的。您需要自己评估它，就像您需要评估自己的编译器供应商的软件、其他第三方依赖项以及您自己编写的代码一样。我已经大量使用了所有四类软件，根据我的经验，Boost 的严重错误比其他任何软件都少，并且比 GCC 或我自己的代码更少的回归。

Answer 2

如果归结为系统设计人员如何在架构级别处理系统安全，我会说很多。

三倍

例如，如果采用的方法是与受信任的选民进行三次冗余，那么系统试验/测试将是批准实施的主要步骤。假设一式三份的开发团队之一选择使用 Boost。如果系统作为一个整体通过了它的所有测试向量，那么人们可能会争辩说不需要通过 Boost 本身来寻找实现错误。显然，如果所有三个一式三份都选择使用 Boost，那么这将引起关注，因为测试向量的范围变得难以管理。

三重法是处理使用软件资源（如编译器、库和程序员）问题的标准方法，所有这些都有出错的风险。Boost 只是其中之一。有人可能会争辩说，Boost 共享指针显然是一种降低程序员错误风险的方法。这一轮最有可能对整个系统有益。

重要，但不是安全关键

有趣的地方是没有使用三倍法，而现在正处于真正必须信任事物的领域。有趣的是，许多系统似乎绕过这个问题的方式是说最终有一个人在控制，他在监督并能够在系统错误的情况下进行干预。

例如，汽车行业有一套称为 MISRA 的编程规则。ABS 系统的软件应该被写入这个规则集，并且开发工具应该被设置为在源代码上强制执行这些规则。这个想法是，这会将未检测到的错误的风险降低到可接受的水平。而且因为最终会有一个司机驾驶汽车，所以他们总是可以自己进行踏频制动。因此，汽车行业避免了必须三次实施 ABS。

他们正在将同样的理念扩展到更复杂的汽车系统，如自适应巡航控制和自动驾驶汽车。我个人认为这样的延伸对于自动驾驶汽车来说是不合理的。相关立法明确规定，如果此类车辆发生碰撞事故（即您仍在“驾驶”它）是“驾驶员”的过错，但光鲜的广告不会详述这一重要方面。

在医疗器械领域也是如此。无论如何，应该有护士或监视病人的人，所以偶尔的小插曲是由监督覆盖的。无论如何，整个事情都很糟糕；虽然医疗设备的软件可能已经过编写测试和批准，但这些软件通常在嵌入式 Windows XP 上运行。他们都联网并最终感染了计算机病毒等。FDA 不会让你有一个自动更新系统，只有设备供应商可以更新它，当然他们不可能希望跟上. 因此，您最终会得到一个编写良好且经过良好测试的优质医疗软件，该软件运行在操作系统安装之上，世界上所有的黑客都在它里面跑来跑去，天知道会发生什么。

因此，如果符合 MISRA 的工具链提供 Boost 作为该工具链的一部分，那么我不明白为什么这与提供标准 C 库的工具链有任何不同。如果工具链供应商正在对其进行认证，那么与其他任何情况都没有什么不同。

这种方法有缺点。根据我的经验，我遇到了一个广泛使用的兼容 MISRA 的工具链，当所有优化都打开时，它的编译器会生成垃圾目标代码。我实际上能够在反汇编中验证这一点。然后我查看了工具链的标准 C 库的源代码，它本身显然没有写入 MISRA 规则集，而且它包含明显的可怕错误。

然而，只要您在项目设置中勾选 MISRA 复选框，使用此工具链构建、测试和销售汽车 ABS 系统就没有监管障碍。将 Boost 添加到该工具链几乎不会让事情变得更糟。

安全关键不重复

最后一种方法是没有重复，也没有人工监督。这真的很难，因为您需要正式证明工具链、操作系统、驱动程序、芯片等的每个组件的正确性。AFAIK 从来没有为真正的安全关键系统（如核反应堆、飞行控制航空电子设备或其他）做过如果系统出错，确实会杀死人。

据我所知，唯一接近的就是 Greenhill 的编译器套件和他们的 INTEGRITY 操作系统。他们可以为您（收取高额费用）为操作系统的每一行、所有库和编译器等所有内容提供正式的测试和验证证据。如果有人要尝试一个真正的安全关键系统，而不会重复，那将是一个起点。

我认为他们还没有完成 C++11，尽管我已经将 Boost 添加到他们的工具链中并且它工作得很好（它不在我急于添加的安全关键系统中）。

结论

当然，如果像 Greenhills 这样在可靠且经过全面测试的工具链方面享有当之无愧和良好声誉的公司提供 Boost，那么我认为可以在受监管的系统中使用它。但是我怀疑整个 Boost 是否会以这种方式提供。他们更有可能遵循编译器标准。

我也知道 GCC 过去已经通过了正式的编译器验证测试，以便可以在 Stuff That Matters 中使用。我希望这会在不久之后重复出现，因为最近出现了 Boost 方面的问题。