Linux可以用于关键任务应用程序吗？

文章作者:Mark Pitchford

Linux的崛起一直没有陨石。根据英特尔X86架构的基于Intel X86架构的个人计算机开发，它现在在最微小的嵌入式设备上运行，但也可以在世界上最快的500个最快的超级计算机上找到TOP500.，一个独立的标杆项目。它在手机(以Android的形式)、消费电子产品、车载信息娱乐系统(IVI)、网络设备中很常见，这个列表几乎是无穷无尽的。

Linux只是一种操作系统，如任何其他操作系统，但其免费的开源状态提供明显的商业优势。严格来说，术语“Linux”专门指的是内核 - 操作系统的一部分促进硬件和软件之间的交互。熟悉的Linux桌面发行版，如debian，fedora和Ubuntu补充，即Linux内核，带支持的系统软件和由GNU项目提供的库。

Linux在这些桌面机器上的相对罕见充当提醒Linux对突出的突出并没有在所有部门和环境中同样分布。特别是，安全关键嵌入式软件的世界提出了一个基本的阻塞问题，因为该标准的可追溯性需求需要遵守这些系统。由于嵌入式项目已经发展到复杂的计算机系统，构建技术将各种模块聚集在一起，并且围绕安全的要求变得越来越复杂。没有人可以完全了解每个模块是如何构建的，也不知道代码如何在模块之间交互。

嵌入式Linux的警报器

想象一下，有一个关于安全关键应用的好主意的初创公司。它可能是一个工业控制器，或者一个创新的汽车制动系统，但现在考虑一个改变生活的医疗设备的具体例子。在美国寻求FDA的批准是一个痛苦的世界，而欧盟的MDR/IVDR合规规则要求遵守最佳实践，但没有明确说明这是什么。但是现在，还不能确定这个想法是否可行——主要的焦点是科学;软件仅仅是达到目的的一种手段。概念证明(PoC)似乎是一个合理的起点。稍后再考虑认证问题。

在这种情况下，预算可能会很紧张，选择Linux是显而易见的。你可以在几分钟内下载它，网上有很多建议、支持和指导。它不需要任何成本——不需要开发席位费用，不需要许可——如果您需要帮助，可以求助于大量开发人员专业知识。会出什么问题呢?

问题是什么?

一些挑战可以很容易地处理。例如，标准Linux没有这些扇区中许多应用程序可能需要的实时功能。在Premempt_RT补丁形式的实时Linux的开发代表了Linux基础对这些问题的答案，并且在需要寻求替代方案时，仍然有关硬实时应用的适用性（见实时Linux内核：Premempt_rt的调查。ACM计算调查)。尽管这是其开发人员的最终目标，但它还有待改进到可以并入主流Linux内核的程度。

这些人的素质如何?Linux内核和系统软件的开发人员主要是软件专业人员。Linux基金会之外的许多内核贡献者都是有薪水的，因此他们的专业性是毋庸置疑的。事实上，开源软件(OSS)可能更“正确”(开源倡议，2018年）因为通过每个人都可以访问，所以源代码被一个大型社区持续分析，任何人都可以在找到它们时修复错误。这反过来意味着最终用户不必等待下一个官方版本。

到现在为止还挺好。但这些项目的功能安全标准必须遵守必须遵守的核心目标，包括IEC 61508（国际电工委员会，2010），ISO 26262（国际标准组织，2018）和IEC 62304（国际电工委员会，2010年）分别为我们的工业，汽车和医疗例子。这些标准放下了一个开发生命周期，该循环被设法在质量保证，配置管理，变更管理和验证/验证方面确保严谨：

质量管理：在任何关键系统的核心中，任何强大的质量管理过程，通常都是ISO 9001（国际标准组织，2015年）的最低限度。作为概括，开源软件环境中的质量管理趋于较小的刚性。也就是说，遵守诸如ISO 9001的标准确保仅定义和遵循该过程，并且产品质量是可重复的，不一定高。

更换管理层：任何能够在开源开发中找到错误的人的缺点是它绕过了正式更改控制过程。

配置管理：通常，开源项目和更传统的开发都使用存储库(例如Git、SVN)，它不仅为最新的开发版本提供受控环境，还为构建、候选和实际发布提供受控环境。

验证和验证：关键任务软件的关键问题区域在验证和验证活动中。安全案例要求证据支持软件适合目的的论点;也就是说，它符合记录的要求。

与许多行业特定的功能安全标准一样，ISO 26262描述了一种用于汽车开发的v型(图1)。

点击查看完整大小的图片

图1：用于将自动刀具链应用于ISO 26262过程指南的传统序列。（来源：LDRA）

这需要整个生命周期中需求的可追溯性，设计的验证和确认，以及实现的验证和确认。当采用开源解决方案时，这些阶段都很难实现。

功能安全标准通常还建议采用语言子集（通常称为编码标准），例如所描述的流行指南臭马克拉。经验证据表明，采用此类准则在开源社区内很少，也许是因为指导方针本身不是开源。

网络结果是您可以根据所选功能标准开发示例性质量的应用软件。但是，如果您的操作系统还没有实现质量水平 - 同样重要的是，并不提供质量的证据 - 那么您的系统无法符合符合要求。

ELISA项目

Linux基金会对这个难题没有陌生人。2019年2月，在安全应用程序中启用Linux（伊利安斯）开源项目推出，目的是帮助公司“构建和认证基于Linux的安全关键应用程序和系统，其失败可能导致人类生活损失，重大财产损失或环境损害。”虽然这是一个值得称赞的目标，并且该项目被一些非常重要的支持者支持，如ARM，BMW和TOYOTA，它仍然是明天的愿望，如果您的开发项目是今天的。

一枪收养

目前，在任务关键字项目中，无法使用，不受控制和逐步使用开源操作系统。但是，这并不意味着OSS根本不能使用（如果知识产权是一个问题，许多OSS许可证要求任何派生代码也是OS，必须返回到存储库）。

Linux是一个开源包与其他任何外部开发软件包(如库或驱动程序),它应该被视为软件未知的血统(或汤)和一个完整的验证和确认过程应用在事件的任何变化——重新应用基础包,这应该只通过一个管理的变更控制过程来引入。

ISO 26262'V'模型图中示出了形式测试工具的传统应用。面临在开源操作系统上建立标准兼容应用程序的任务的团队将需要遵循更务实的方法，不仅是因为代码已经存在，而且因为代码本身可能是唯一可用的详细的“设计”文档。”换句话说，现有代码有效地定义了系统的功能而不是任何文档。

一般来说，对于图书馆或司机来说，这可能是一个实际命题。但思考回医疗设备的例子，这样的发展团队真的想花时间逆向工程的操作系统吗？例如，即使通过使用Yocto最小化OS足迹，例如，这种练习将需要了解对低级软件的了解，这是最好是一个重大分心，并且在最糟糕的情况下，在应用程序开发人员的舒适区之外可能很好。

今天的务实解决方案

如果所有概念证明开发将在可证明的操作系统上完成，那么其中许多人甚至都不会开始。任何务实的解决方案都必须承认以某种形式使用Linux几乎是不可避免的。

在这之后发生了什么，这取决于时间尺寸。发展需要多长时间？什么时候ELISA会变成年龄？

可移植性是任何便携式操作系统接口（POSIX）兼容开发的主要优点之一。虽然许多Linux实现不是完全POSIX兼容，但完全可以限制它们的功能对这些功能，并且仍然具有更适用于构建实用系统的工具包。

即使当应用程序开发从沙箱“破解并查看”的方法转移到正式的文档化的、兼容的开发生命周期时，即使是扩展的开发团队继续以这种方式利用Linux也是完全可行的。这意味着执行所选择的功能安全标准所要求的所有验证和确认活动，包括需求跟踪、编码标准的应用、单元测试(图2)、结构覆盖分析和其他任何需要的东西。

点击查看完整大小的图片

图2：使用LDRA工具套件执行单元测试。（来源：LDRA）

最终，当产品必须准备好上市时，清算的日子将会到来。到那时，ELISA有可能被应用，在这种情况下，前面的道路是明确的。但是，如果不符合POSIX标准，则有几种符合POSIX标准的商业可用RTOS，例如QNX和Lynx的RTOS，这些RTOS经过了使用认证。原则上，用商业RTOS的单一许可证重新编译应用程序，在新环境中重新运行动态分析测试，然后投放市场是一项简单的任务!

为了使这一实践命题，项目早期考虑有两个关键因素。

POSIX合规性和一致性：术语“合规性”和“一致性”似乎是同义词，但要小心！图3突出显示了可能的微妙不匹配度，捕获简称的捕获基于POSIX规范之间的边界的模糊，以及在实践中实施的内容。

点击查看完整大小的图片

图3：开放组的架构合规性和一致性的插图。（来源：LDRA）

这提出了关于假设便携性的问题。例如，如果您开发了一个系统部署包含不合形特征的RTOS，则任何RTO的变化可能涉及至少部分重写。

现在假设您的原始系统使用完全POSIX符合性RTOS，并且您所选的替换是一致性的，但不完全符合。如何确定新操作系统实现代码库中杠杆的所有功能？

全自动测试和需求可追溯性:“重新运行新环境中的动态分析测试”是一个指令短语的东西，但如果所有这些测试都是通过手动手段执行的，那么即使事情顺利进入，可能会有相当大的开销。

现在假设转移到所认证的RTO的选择，需要部分重写。跟踪对要求的任何影响，设计和测试很容易成为项目管理头痛，在项目最不受欢迎的时候。

确保完全集成，自动化的测试和需求可追溯性可以最大限度地减少影响，使得必要的重新测试变得容易，并且他们的执行简单地重新运行它们。

点击查看完整大小的图片

图4：使用LDRA工具套件改变要求的影响分析。（来源：LDRA）

结论

现在，使用Linux作为最安全关键型应用程序的首选操作系统不是一个选项。但这并不意味着它无法在这种应用程序的发展期间使用。

如果ELISA或类似的发展使其成为可实现的目标可能会改变。但是，如果不是，POSIX中固有的可移植性为从概念证明转换为可证明项目提供了一个选择。

使实际命题需要仔细使用POSIX功能，以及如果在将应用程序从Linux移植到符合标准的替代方案时，则重新测试的无缝机制。

马克Pitchford是技术专家LDRA软件技术。Mark拥有超过30年的工程申请软件开发经验，并在英国和国际上致力于开发和管理的许多重要的工商项目。自2001年以来，他曾与寻求在安全和安全性关键环境中实现符合符合软件开发的开发团队，与DO-178，IEC 61508，IIRA和Rami 4.0等标准一起使用标准。马克赢得了诺丁汉特伦特大学的科学学士学位，他是一个超过20年的特许工程师。他现在担任LDRA软件技术的技术专家。