c++ - Boost是否曾用于受监管的项目(FDA，FAA)？

Question

在最近发表评论时，我发现自己在说，根据我的经验，Boost并未广泛用于受监管的行业(FDA，FAA)。实际上，我不知道有任何项目使用或使用过它。不过，我意识到自己可能缺乏经验，因此我想知道是否有人对医疗设备或航空飞行系统(照明，机舱控制，座舱设备等)中使用Boost的项目有所了解。

我不确定这是问这个问题的正确位置(也许是其他SO网站)，但是我认为这是一个不错的起点。

这不是关于是否应在这些区域中使用boost的问题，而是有关任何人都知道是否已使用boost的问题。

编辑一些示例项目可能有助于阐明这一点:机舱照明系统，机舱管理系统，座舱仪表，输液/食品/胰岛素泵，透析机，实验室诊断设备，血液中心数据收集系统等。其中一些可以维持生命或潜在的飞行关键，一些收集数据，一些收集用于做出医疗决定的数据，等等，但我相信FAA/FDA将所有这些都作为受管制的设备。

编辑外部(未随开发链一起提供)库通常被带入这些类型的项目中以用于其他目的(图形库，驱动程序，USB堆栈等)。这些被视为SOUP。使用boost将属于这种方法。有人知道这样使用boost的项目吗？

编辑 Boost是一个非常大的框架，包含多个组件。我正在寻找已在项目中使用过的任何部分。例如“boost 智能指针”或“boost 启用”或“boost 阵列”或“可选 boost ”等，但在“整体”中使用，而不是一部分。通过查看Boost代码并重新使用该思想而无法使用；用作系统的整体组成部分(即法律意义)。

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

Answer 1

如果要归结为系统设计师在体系结构级别处理系统安全性的方式，我会说很多。

三重

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

三重处理是解决使用诸如编译器，库和编程器之类的软件资源的问题的标准方法，所有这些软件资源都有出错的危险。 Boost只是其中的另一个。有人可能会说Boost共享指针显然是一种减少程序员错误风险的方法。该回合最有可能对整个系统有益。

重要，但非关键

有趣的是当不使用三重运算时，而现在正是真正必须信任事物的 Realm 。有趣的是，许多系统似乎都可以解决该问题，这就是说，最终有一个控制权的人来监督并且能够在系统错误的情况下进行干预。

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

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

在医疗设备 Realm 也是如此；无论如何，应该有护士或某人在监视病人，因此偶尔出现的问题都可以由监督来解决。整个事情还是很糟糕。尽管用于医疗设备的软件可能已经过书面测试和批准，但是这些东西通常都在嵌入式Windows XP上运行。他们都连在一起，最终被计算机病毒等感染。FDA不允许您安装自动更新系统，只有设备供应商可以更新它，当然他们永远也希望保持最新状态。因此，您最终会在操作系统安装的基础上运行一个编写良好且经过良好测试的医学软件，并且该操作系统中安装了全世界所有的黑客，令上帝知道。我认为在这种情况下使用Boost不会增加整体系统风险。

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

这种方法有一些缺点。以我的经验，我遇到了广泛使用的符合MISRA的工具链，当所有优化打开时，其编译器将显示垃圾目标代码。我实际上能够在反汇编中对此进行验证。然后，我看了一下工具链的标准C库的源代码，很显然它本身并不是写给MISRA规则集的，而且还包含明显的，可怕的错误。

但是，只要您在项目设置中的MISRA复选框中打勾，使用此工具链构建，测试和销售汽车ABS系统就不会受到任何法规的限制。在该工具链中添加Boost几乎不会使事情变得更糟。

安全关键无重复

最终的方法是没有重复，也没有人工监督。这确实很困难，因为您随后需要正式证明工具链，操作系统，驱动程序，芯片等每个组件的正确性。对于真正安全的系统(如核 react 堆，飞行控制航空电子设备或其他)，从来没有做到过如果他们出了错，这些系统肯定会杀死人。

据我所知，唯一接近的是Greenhill的编译器套件和它们的INTEGRITY操作系统。他们可以为您(收费)为操作系统的每一行，其所有库和编译器以及所有内容提供正式的测试和验证证据。如果有人曾经尝试过一个真正的安全关键系统而又没有重复，那将是一个起点。

我认为他们还没有完成C++ 11，尽管我已经将Boost添加到了他们的工具链中，并且效果很好(它不是在我必须添加的安全性至关重要的系统中)。

结论

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

我还知道，过去，GCC已通过正式的编译器验证测试，因此可以在“最重要的事情”中使用它。我希望对于Boost方面的最新化身，这一点会在以后更快地重复。