我感兴趣的是IDE、编译器或链接器在IEC62304中是否被认为是“汤”。我发现了一个网站,它声称情况并非如此。我想我同意根据我对标准的解读,不过,我想再看一遍。
发布于 2017-09-13 18:03:48
对于“是特定类别的开发人员工具汤”这一问题,任何有意义的回答都必须考虑为什么人们首先需要汤开发工具(即出于安全原因)。
从实际角度来看,开发中的软件必须是安全的,而不一定是用来开发它的工具。C和C++被广泛用于开发安全系统,尽管任何熟悉这些语言的合理开发人员都会认为它们非常不安全。您可以通过遵循使其安全的设计技术和使用完全符合其各自语言标准的编译器来确保它们的安全性。
相反,仍然有可能使用非常安全的语言,如ADA,如果你不遵循正确的程序,仍然会出现系统故障,正如Ariane 5爆炸所有效地证明的那样。
所以问题不一定是“编译器被认为是汤吗?”是“我的特定编译器IEC62304认证了吗?”从我对标准的解读来看,它似乎专注于严格的软件开发过程,而不是具体的开发工具。
这篇文章问:“Visual / MS是否根据BS/IEC 61508英国/欧洲标准建立了一个经过认证的工具?”部分答覆是:
我想你误解了IEC和Visual的“球体”。IEC标准是在一些安全涉及硬件控制和操作(结合软件)以确保安全可靠的行业中,为保证安全而制定的通用规范。本规范是在工厂自动化、油气生产和其他安全关键环境中使用的更具体标准的基础。国际电工委员会规范只列出了用于执行必要操作的过程、硬件和软件中必须存在的一般特征。它不适用于Visual Studio或托管代码,因为它们解决了两个不同的问题。
它进一步说,即使是Windows操作系统本身“从来都不是(也可能永远不会)硬实时操作系统,这通常是对安全关键软件的要求。”
因此,要回答您的具体问题,我不认为您可以明确地说明编译器作为一个整体是否是“汤”,因为您必须独立于其他编译器来评估每个编译器及其软件开发生态系统。即使您能够对这个问题提出一个合理的答案,我也不确定它在一个标准中是否特别有意义,这个标准认为您整个软件开发过程的严格性是重要的,而不仅仅是您的工具。
换句话说,不是软件的类别(在本例中是编译器)使其变得复杂,而是它的开发方式。
进一步阅读
发布于 2017-09-15 00:49:15
虽然罗伯特的回答非常翔实,但我想我可以提供一个稍微不同的观点。
工具本身(编译器、链接器等)通常不被认为是“汤”,因为它们不构成经过验证的最终软件映像的一部分。但是,它们确实生成了该映像,因此您需要考虑您对这些工具的信任程度。问自己以下问题:
在软件系统安全分类的背景下进行基于风险的分析是合适的。
您的工具链供应商提供的任何源代码或目标代码都被认为是使其成为可执行映像的源或对象代码。这包括平台的任何运行库实现(例如标准C库),以及任何启动代码(例如,对于嵌入式平台,创建C运行时环境的代码)。这些都需要按照62304标准和软件的安全分类来处理。
https://softwareengineering.stackexchange.com/questions/357298
复制相似问题