翻译整理：土豆丝624
原作者：
Andreas Platschek [email protected]
Nicholas Mc Guire [email protected]
Lukas Bulwahn [email protected]
说明：
文章版权归原作者所有。
由于safety和security中文难以区分，保持不变。
码字不易，转载说明出处，谢谢。
摘要
当SIL2LinuxMP项目三年前开始启动的时候，一些对safety没要求的系统已经开始构建并使用Linux了。工业界使用Linux主要是因为它强大的security能力以及对现代硬件无与伦比的支持。这两个要求对现代工业应用很重要，可以在多核CPU上使用Linux来满足。但是，是否存在基于Linux系统的safety论证和维护问题，依然是开放的。
到目前为止，虽然还未实现基于Linux的系统的safety认证的最终目标，但对于基本组件(Linux，glibc，busybox)的认证已经实现。
SIL2LinuxMP项目是作为工业研究项目而启动的，目的是确定是否有可能使用Linux操作系统作为基础来构建复杂的软件密集型safety相关的系统。在过去的几年中，最初发现的许多潜在的问题几乎都可以解决，但是其他的问题令我们惊讶。到目前为止，似乎没有经过safety认证的多核CPU（具有四个或更多核）
这篇文章不仅说明了在过去三年我们碰到的问题和取得的成就，也讨论了目前提出的解决这些问题的方法。
这些方法涵盖了系统safety生命周期的所有方面。在系统工程系别，我们设计了适当的过程来量身定制safety过程，从开发到可控制的选择过程。我们开发了分层的系统危害分析，以系统地得出足够的Safety属性，并在用例上演示了此分析的功能。我们在评估中涵盖了Linux开发过程，为此我们设计了数据挖掘方法，以利用可用的开发数据来量化软件质量。基于这些数据，我们得出了统计论证来证明开发过程的适用性。为了解决Linux源代码及其评估方面的剩余不确定性，我们将能够缓解同一系统故障的多个半独立Linux特性的质量评估合并为一个safety论证。这种残余故障的多层处理是基于软件保护层的分析。
这些方法为Linux认证路线提供了必要的方法，使得Linux能够达到符合IEC 61850(SIL2)的safety等级2。
关键词：Linux，safety，预存在的软件
1 引言
近些年来，整个行业的发展是越来越依赖高度复杂的系统。比如汽车自动驾驶，工业机器人和共享的工作环境。这些新的发展有望为个人生活和工作生活带来巨大的改善。但是目前为止，大多数都只解决了功能问题。除了从功能方面着手外，还需要考虑非功能属性，比如security和safety要求，然后才能让大众使用这些系统。
本篇文章重点是复杂系统的safety特性以及深入介绍在SIL2LinuxMP项目最初三年的经验。这个项目由由开放源代码自动化开发实验室（OSADL）和各个行业的许多合作伙伴公司管理。
SIL2LinuxMP项目的目标是创建一个可用于提供主线Linux内核safety论证的框架，该框架可指导认证过程并尽可能减少认证过程的工作量。我们通过尽可能多的自动化过程来减少工作量，并使Linux的质量评估对不断发展的Linux内核可重复使用。
为了验证该框架是否实际可用，我们针对特定用例对Linux进行了验证。
在研究解决方案之前，与其他之前存在的safety关键的系统相比，本文在复杂性规模上迈出了重要的一步。在第2部分讨论的这些含义证明了对SIL2LinuxMP项目以及其所涉及的（safety关键的系统）过大的软件堆栈的必要性。
然后，本文介绍了项目中要解决的最重要问题，并展示了目前的中间结果。我们把这些问题的讨论分成了两部分。第三部分介绍了从项目开始就讨论的问题。第四部分介绍了在这个项目的过程中意料之外发现的问题。
请注意，尽管本文提出了更有趣和新颖的方法，但并未提及设计传统safety工程活动的那一部分工作量。这些目标在这里被描述为明确的反陈述，以防止再次引起误解。这些误解曾经导致了讨论伙伴的困惑。
A．SIL2LinuxMP的目标和常见误解
在我们开始讨论第3到5的技术部分之前，我们首先展示SIL2LinuxMP项目的目标。这里明确了期望和不期望的内容，并总结了SIL2LinuxMP项目如何处理特定的问题。
澄清目标是很有必要的，因为它需要对习惯于购买和将操作系统视为黑盒的公司进行重大的范式转换。尽管Linux具有为每个已部署的系统提供免版税使用许可的优势，但成本却转移到了建立各个公司适合的safety工程知识方面。
目标1：
建立一个框架，能够给如何构建基于Linux的safety相关系统提供指导
常见误解：有些人认为SIL2LinuxMP正在创建一种产品，该产品将以收缩包装的形式提供，而无需额外的工程工作。
SIL2LinuxMP创建打包产品的想法是一个非常普遍的误解，但不幸的是，这似乎使某些公司无法积极参与SIL2LinuxMP项目。
作者们认为，将来不会存在缩水打包的Linux软件包，该软件包可以在任意硬件上执行而没有任何限制，并且仍可用于对safety要求很高的应用程序。
这是许多人似乎拥有的梦想（有的人将其命名为梦想SEooC），但是不幸的是，由于多种原因，这个梦想是不现实的。最重要的是，Linux内核的接口相当庞大。 它大概有1500次API调用，甚至不包括内核中的其他接口，例如 proc或sys伪文件系统。
从理论上讲，直到最后一次系统调用为止，对其进行分析都是可行的，但它绝对不可维护，因此从经济上来说并不划算。在撰写本文时，在SIL2LINUXMP用例中大约使用了30~35个API调用（系统调用以及库调用，例如memset()），并且对其参数有额外的限制，比如仅允许使用某些标志。并且对用法也有额外的限制，比如某些调用只能在系统初始化期间使用。所有这些API调用都是在Linux上运行的，大多数现有应用程序中普遍使用的方法，没有任何较深奥且很少使用的调用。
此外，它们的用法仅限于特定的组合，比如 内存分配需要组合调用malloc()，mlockall()和memset()，并且只允许系统初始化的时候调用。
此外，我们仅实现机制来抵消危害分析过程中发现的用例特定故障。
与不切实际的，预认证的缩水打包的Linux包相比，SIL2LinuxMP项目的目标是创建一个框架，以指导safety工程师完成基于Linux的系统认证过程。
这意味着，有必要对每个基于Linux的safety关键的系统进行特定的分析。当然，随着时间的推移，将会出现某些模式，并且在safety关键型系统中使用Linux会变得更加容易。但是，尽管如此，如此复杂的操作系统在任何当前和将来都无法抵御在当前应用和未来应用程序中所有可信任的故障。
目标2：
为safety关键型应用程序提供最小的运行时环境，最高级别达到SIL 2。
常见误解：一个完整的发行版，比如可用的Debian, Yocto。
不行的是，运行一个完整发行版是不行的（就此而言，这很实用），因为发行版中所有软件包的代码库都太大了。
因此，SIL2LinuxMP项目仅限于Linux内核，最少的标准库集和最小的运行时环境（基于busybox）。 尽管有些人可能仍然希望获得SIL2认证的Android或基于Yocto的系统，包括图形堆栈和所有其他东西，这当然不是我们的目标。
正在考虑将SIL0的Container放在整个关键混合的系统中。尽管这将允许更多非safety的功能并行运行，但它也不会提供没有任何限制的完整Linux发行版。
SIL2LinuxMP的方法是将那些软件元素保留在可以执行各种非safety应用程序的QM / SIL0 Container中（请参见图3），并将对Safety关键的应用程序保持在最低限度。 使用Linux内核中的隔离机制完成混合关键性的应用程序的集成，稍后在第3章C小节中讨论。
2 复杂性增加的含义
正如引言中已经提到的，许多行业的复杂性正在显着增加。 这种复杂性的提高是由为不久将来开发的应用程序驱动的。 我们从这些预期的应用程序中得出了许多含义，这些含义对系统的非功能特性具有重大影响。
1) 计算性能
这些高度复杂的应用程序对性能的要求比传统系统要高得多。 这不仅意味着更高的功耗[3]，而且还意味着需要使用迄今为止尚未在工业应用中使用的CPU，例如在服务器中使用的CPU，否则将无法提供必要的性能。
2) 并发计算能力
性能要求不仅是对最先进处理器的需求，也要求操作系统能够管理此类多核CPU，并能够利用尽可能多的性能增强功能。
3) Security
另一个所有行业通用的需求是系统需要和外部世界互联，通常是通过互联网。这不可避免的导致Security问题。
尽管SIL2LinuxMP并不专注于Security，但该项目设定了自己的目标去检查体系架构上每个设计决策，以确保设计与一般应用程序的Security概念不冲突。
由于Linux多年来一直用户高性能以及对Security要求很高的应用程序中，因此它成了即将出现的高复杂度应用程序计算平台的主要考虑对象。因为它提供了一系列的机制，在提供出色的Security功能（保护和监控）的同时，能够最优的利用现有资源。
但是，到目前为止，Linux在Safety关键系统的使用仅限于某些特殊的情况[4][5]。即使在过去进行过讨论[6]，也无法使用通用的方法来验证未修改的主线内核。为了缩小这个差距，所以启动了SIL2LinuxMP项目，能够使未来的应用程序运行在基于Linux的计算平台上，同时满足性能和Safety的要求。
3 预期研究的问题
本章节总结了我们从项目开始就预期研究的问题。这并不意味着解决方案都是完全明确的，只是在原则上认识到如何解决这些问题的概念。
A. 从实现到选择
SIL2LinuxMP平台与常用方法之间的主要区别在于，基本软件元素是尚未进行专门开发的预存在的软件。
这意味着在生命周期中没有消除故障的措施，意思是着重于减轻故障是从根本上错误的系统safety方法。
因此，通过调整Safety生命周期来减轻此缺陷。 具体来说，V模型分为两部分，上部是系统规范和架构。此部分是为该特定系统开发的，因此可以按照IEC
61508 [2]中定义的常规路线1S开发来完成。底部通常是设计，开发和集成专用软件。 由于使用了预先存在的软件，因此该底部由软件选择过程代替，如图1所示。
这种经过调整的生命周期模型描述了元素选择的工作流程。 根据元素的不同，可能的选择项也有所不同。 对于SIL2LinuxMP项目中的元素，可以选择以下变量：
* 内核版本
大概每两个月发布一个新的稳定的Linux内核版本。此外，大概每一年，这些稳定版本的其中一个版本作为一个长期稳定（long-term stable LTS）的版本发布。并非每个版本都像其他版本一样稳定，因此SIL2LinuxMP项目选择过程的一个重要部分是选择稳定的内核（有关如何使用开发数据来识别稳定版本的详细信息，请参见第3章D小节）。这个内核是长期支持并且在非常广泛的上地下文环境中使用的稳定内核（例如，使用主要发行版本），因此经过了充分的测试。
* 内核配置
SIL2LinuxMP项目的目标不是提供一个认证的完整内核然后进行配置，而是建立一个对特定配置进行认证的框架。假设此配置被简化为以下功能：
应用程序满足功能或非功能需求需要的功能，而它们的选择受各个候选项的成熟度和质量驱动。
事实标准的功能，即没有该配置的内核配置与正在使用的其他内核配置相差甚远。
因此，内核的配置还允许某些子系统的选择基于某些标准，诸如其开发历史，设计的新颖性，大小和已知的bug率。
*非内核元素
除了内核，其他预存在的元素也会被用到，比如C函数库和math函数库。通常，这些库有不同的变体。对这些非内核元素，开始的时候都会选择已经被广泛使用的那些变体。此选择还可以包括部署的宽度和开发的活动。使用仅部署在少数系统中并且几年未维护的C库没有任何意义。这个选择的标准也用在内核版本的选择中。一个积极健康的项目必须考虑广泛而活跃的社区这个优势。
B. 适配方法
在很多Safety相关的项目中，一个争论点是量身定制方法还是论证一个全新的方法。SIL2LinuxMP项目概述了预存在软件的选择过程，不仅需要考虑软件本身（即源代码），而且需要调查开发预存在软件的开发环境，包括开发过程中所使用到的所有工具。需要调查分析工具（如果有）对safety的贡献。
此外，复杂性的增长要求将不适合此类应用的方法替换为可以处理这种复杂性的最新方法。 不幸的是，标准建议的方法（例如IEC 61508 [2]）大部分都是过时的，需要讨论适当的替代方法。
最后，使用预存在方法的应用程序也改变了已有方法的属性，比如，回顾预存在元素的规范中不能提供在附件C提到的措施和技术实现中提出的建议即61508-3 Table C.1 “摆脱固有规范的错误。。。”。
因此，定制或新引入方法列表非常重要。我们认为这是一种很好的做法，不是尝试论证各种方法，而是应该建立一个系统的过程，不仅允许论证定制的方法，也允许对新方法进行论证。而且表明使用新方法和已有方法的组合可以满足ICE 61508[2]关于覆盖性的初衷。
图2概括了定制方法的工作流程。黑色虚线表示从当前方法过渡到新的或定制的方法。
所采用的方法（图2区域（1）中的红色路径）是对IEC 61508-7中的基本原理进行逆向工程，以便找出原始设计意图。然后使用IEC
61508-3附录C检索该方法对系统开发有贡献的属性。 接着评估新引入（或定制）方法对这些属性的贡献。
接下来（跟随图2中区域（2）中的绿色路径），将新方法对特性的贡献与原始方法的贡献进行比较。请注意，此时可以使用多种新方法来代替原始方法。如果是这种情况，至少在半定量水平上将所有（相关）新方法的贡献与原始方法的贡献进行比较。
最后一步（跟随图2中区域（3）中的蓝色路径），在新方法和原始方法对特性的贡献之间进行差距分析，并在必要时调整方法集以弥补这些差距。直到所有的范围都被覆盖，这个迭代过程才算完成。
C. 隔离特性
隔离机制是Linux内核广泛使用的关键功能之一。以前，它们主要用于具有security意识的系统中。但是如今，随着Container技术的兴起，由于Container技术能够简化系统部署，系统管理和应用程序开发，这些隔离机制实际上已在每个运行的系统中使用。这些隔离机制用于构建与系统其它部分隔离的Container，为了确保所包含的应用程序的故障独立于核心系统，从而限制Security漏洞对容器的影响，并确保不相关的应用程序不会彼此崩溃导致核心系统崩溃。
多个独立设计的隔离和保护机制建立了一个分层的隔离体系结构。图3说明了如何使用多层保护隔离混合临界的独立应用程序。
值得注意的是，在SIL2LinuxMP中使用这些隔离属性有以下两个边界：
*实现独立应用程序（具有不同重要性）之间的隔离
*确保遵守由危害分析结果指定的API约束（请参阅第4章B小节）。
这听起来很吸引人，不用担心不相关的应用程序甚至是具有混合关键性的应用程序之间的相互依赖性，但是调查Safety可用性的问题时出现的老问题一直是如何验证这是足够Safe，并且允许应用程序独立发生故障的隔离属性值得信赖。
在这种特殊情况下，人们意识到这是一个工业过程中众所周知的问题类似的问题，该问题由Audrey
Canning提出。
然而进一步关注的是后果是否可能如此严重以至于不应考虑危险情况的发生频率，因此在选择适当的实施技术时就忽略了“风险”的概念。为了解决这一问题，IEC 61511正式确立了“保护层”的概念，要求不同层之间具有多样性。[7]
这种特殊情况也相似。到目前为止，由于危险情况的发生频率无法评估，因此无法评估风险，至少不能以一个合理的工作量进行评估。因此，我们的解决方案依赖于保护层分析（layers of protection analysis, LOPA）的基础，目的是为每种危害分配多层保护。只有在所有保护层同时失效的情况下，危险情况（通常已经非常不可能）才会被发现。使发生危险情况的可能性更小-可以说极不可能。
为了采用LOPA并如实得出上述结论，隔离机制满足独立保护层（independent protection layer, IPL）的基本属性，请参见[8，第1.3节]。
* 独立性
仅当保护层彼此足够独立时，LOPA才能进行正确的风险评估。如果目标是物理隔离，那么软件可能是有问题的。因此，重点转向了逻辑隔离。
* 高效率性
需要确保的是，即使发生危险，该层的功能也可以保护或减轻所研究的后果并起作用。每个保护层都应自行提供足够的保护或缓冲措施，多层的使用旨在为论证或分析各个层的弱点增加一个额外的Safety网络。这并不是说，开发人员可以不进行分析，而仅指完全无法获得确切的失败频率或者存在不确定性过高而无法进行正确论证的情况。
* 可审核性
应该可以检查IPL的设计和开发以及IPL本身，以确保各个IPL的Safety。由于SIL2LinuxMP项目仅使用自由开源软件（FLOSS），根据大量的文档和开发历史记录（修订控制系统，邮件列表，错误报告等），因此IPL本身的源代码可用于分析。
通过执行此LOPA，我们展示了隔离机制足以为在基于Linux的共享系统上运行的不同应用程序提供适当的逻辑隔离。
D. 统计模型
传统式，Safety关键的软件开发在相关标准的指导下遵循严格的开发流程。假设是，此严格的开发过程会导致残留的bug率达到目标SIL级别。或者我们可以问这样一个问题：“什么过程负责软件Bug的存在？”。我们期望使用SIL2LinuxMP中的统计方法来回答这个问题。换句话说，我们的目标是提供有关在开发生命周期活动中由随机过程（人）引入的故障统计报表。
不足为奇的是，传统的与Safety相关的系统由于软件规模小和迭代式重新设计的统计数量少，因此无法量化软件中的系统故障。取而代之的是，考虑定性的防御和更深入的分析。从本质上讲，可以采取多种方法，由合格的工程师团队应用这些方法，并将其全部打包到一个受控过程中，过程指标可以用作赋予软件元素系统能力的指标。
如果有足够的跟踪数据和开发元数据可用于此类预先存在的元素，我们可以通过不合规开发的间接指标统计推断出足够的过程合规性。图4描述了这个基本模型。
构建高度复杂软件（比如Linux内核）的过程合规性，需要两步：
1) 建立强制性活动的原则，本质上这就是IEC 61508-3 第二版7.4.2.13 a-i中的3S路由编码。
2) 基于过程元数据的统计分析，建立这些方法的实际有效性。
Linux内核开发者定义了一个相当严格的开发过程[9]，原则上可以满足IEC 61508 第二版第3部分中提出的结构化和管理过程的大多数要求。但是很明显，该FLOSS项目缺乏Safety管理结构，无法对应用方法论提出任何特殊要求，即使是严格的R1（详见IEC 61508-3 Ed 2 Annex C.1.1）。
R1：没有客观的接受标准或客观接受标准有限。比如基于判断和现场试验的黑盒测试。
似乎要求很少。如果我们从统计学上在要求的活动和有效发现之间建立明确的联系，则可以确立实现IEC 61508目标原则的总体主张。具体来说，第7.4节的第5个目标在这里得到解决[2，Part3，7.4]。
本条款要求的第5个目标是验证Safety相关软件的需求（就所需的软件Safety功能和软件系统能力而言）已经达成。
这种预测模型是对假定的稳定的基础发展过程的评估，而不是评估特定版本本身中的系统故障。为此，我们对内核DLC的连续周期进行建模，并推断出整个内核以及特定配置的连续性和改进趋势。本质上讲，使用在Linux内核的开发跟踪数据上引导的负二项式回归模型，对长期稳定的内核稳定版本进行回归分析。
通过分析图6中的在选定的内核功能集中应用的补丁的特定功能的分析，分别基于图5所示的基于稳定内核补丁的开发进行建模，可以估计内核中的剩余bug以及对过程健壮性进行总体判断。这种模型的目的并不是要暗示我们知道内核中尚未发现的错误数量，而是判断开发过程是否完美，并且同样重要的，是否可以在Safety生命周期中管理所报告的Bug率。
目前来看，从目前仍然十分有限的根本原因分析数据集中，也就是分析稳定内核中的错误bug的数据，我们估计不超过1/30的Safety相关的bug是跟我们的特定用例相关的，因此可预估的Bug数量是可控的。不过，回归假设错误是在现场发现的，因此是通过与时间相关的过程来发现的。自然，并非所有错误都如此。最近出现的融化和频谱错误导致对关键内核非常重要的更新，表明此类预测有其局限性。然而，这是对潜在影响的首次量化，因此这是选择特定内核版本和配置选择的重要指标。
4 意料之外的麻烦
上述我们展示的问题一开始就知道了，这里还有些问题在SIL2LinuxMP项目开始的时候我们并没有认识到。
A. 影响分析
在讨论过程经常提到的一个问题是如何计划认证一个1900万行代码的操作系统。答案很简单：这从来都不是一个计划。如第3章A小节提到的那样，配置项的选择是Safety开发生命周期的一部分。从本质上讲，选择不仅是消除故障并最大程度地减少残留Bug的步骤，并且还是可以大大减少代码量的步骤。
Linux内核配置要确保仅实际使用一部分实际上的代码库。除此之外，最终完成的所有分析（例如第3章D小节展示的统计模型）都应将其考虑重点放在那些对特定配置有影响的提交上。
为了做到这一点，SIL2LinuxMP项目使用了在项目中开发的两个工具。
* minimization[10]工具是由Hitachi在SIL2LinuxMP项目中开发的。它允许基于内核配置生成代码库，其中所有未使用的代码都基于用于配置的C宏进行剥离。
* patch impact tester(PIT)工具仍在开发当中，但是结果很乐观。与minimization工具相比，它不适用于单个版本的内核，而是测试给定补丁对给定配置是否有影响。这样，可以保存各个变更的开发数据，并减少了必须考虑的提交次数。
尽管这个问题乍看之下并不重要，但在很多情况下，这并不是一个简单的问题。
PIT本身是基于GCC插件开发的。这个插件编译内核和配置的时候会用到。这个插件收集的信息会存在数据库中，可以用来检查一个给定的补丁包是否对配置有影响。
B. HD3-危害驱动的解耦，设计和开发
尽管SIL2LinuxMP项目中考虑的用例的复杂性远低于预期的未来应用程序的复杂性，比如，自动驾驶，在危害分析过程中，很明显，这种复杂性用传统危害分析方法无法控制的。由于这个原因，研究了一种基于危害和可操作性研究（hazard and operability study, HAZOP）的新的方法。这种新的方法叫做危害驱动的解耦，设计和开发（Decomposition, Design, Development, HD3）。
HD3的主要前提是系统的设计应由确定的危险驱动。这个想法是将危害作为设计输入，并在可能的地方在设计级别消除危害。这样，减少了对缓解机制的需求，从而防止不必要地增加系统复杂性。
HD3的一般过程是从系统的基本功能开始。在SIL2LinuxMP用例中，这是“测量水质”。基于此基本功能，得出了与技术无关的过程。换句话说，这个过程就像是有生化学家在实验室中完成的一样。然后，对该技术无关的过程进行第一次危害分析。传统的HAZOP在与技术无关的过程中进行，从高度抽象的层面揭示了危害。对于每个层级的分析，消除条件和缓解能力以Safety应用程序条件（safety application condition,SAC）的形式记录下来。然后将这些SAC合并到一组派生项中-仍在技术无关的级别。
技术无关的危害分析结果将用作技术意识设计的输入，同时仍保持技术不确定性。意思是，设计一个自动系统，分配不确定的设备（马达，泵，阀，传感器等）去执行由生化学家在技术无关过程中执行的动作。在这个级别，不会分配特定的设备（比如，仅使用“泵”而不知道它是隔膜泵，径向泵，蠕动泵等）。
这种技术意识非特定设计作为另一轮危害分析的输入。第二轮灾害分析的结果用作使用特定设备的技术意识设计输入。最重要的是，基于更高抽象层的危害，可以选择特定的Safety设备识别大量的故障。这留下了有限的（理想情况下是最小化的）危害，这些危险无法通过这种方式消除。仅对于此有限的集合，必须将缓解机制引入系统设计中，以确保较低的故障残余概率。
缓解机制的分配可以是跟Safety相关的应用程序，也可以是非特定元素的非特定级别（参见LOPA）。
第二轮危害分析的结果用作第三层危害分析的输入。在第三层，将未指定的设备替换为选择的特定的设备。
最重要的是要注意，HD3方法接着使用派生需求的中间层来完成，这些中间层对于下一层设计需要的危害信息是必须的。
此外，每层危害分析都会产出Safety应用条件（SAC）。系统必须满足这些条件。HD3方法导致SAC也是分层的，SAC会从更高的抽象映射到更细粒度的SAC。比如，在技术无关的几倍，SAC是这样描述的：“关键数据写入后必须验证”。在技术无关的级别后要进行改进。在非特定的技术意识级别，是这样描述的：“灰通道存储介质”。在特定的技术意识级别变成了“写入的数据必须可以回读”，“各个测量值应加盖时间戳”，“存储的每个测量数据时候都应该加CRC校验”。
这个简单的示例说明了如何在各种抽象级别上进行危害分析时完善SAC。要求的API清单情况也类似。在这个例子中没有看到的是SAC和所使用的API调用作为结果的一部分包括：
* 参数受限的API调用的最小集
* 约束的最大集
因此，需要进行分析减少功能子集。这样就可以以最小的投入对软件组件的复杂性进行分析。
由于技术的创新性，HD3的使用经验仍然有限。但是从初步成果来看是很有希望的。从高层设计到实现对SIL2LinuxMP用例进行全面分析是可能的。对这种级别的复杂度，传统的危害分析方法也许是可行的，但是根据我们的经验，投入的工作量比HD3要大的多。更重要的是，要兑现“先消除再缓解”这一重要原则，是不可能做到的。
5 结论
尽管在SIL2LinuxMP项目开始的前三年并没有完成SIL2认证平台这个目标，部分原因是因为没有认证的多核CPU，但是证明了这个并非遥不可及，特别是对于我们的主要调查主题-Linux内核。
以上各章节介绍了在Safety生命周期的各个部分所取得的进展。这个项目的最大问题是寻找解决复杂性的方法。这个目标可以使用HD3（第3章B小节介绍）进行危害分析和系统设计来达成。其次，软件LOPA（第3章C小节）论证了对重要性相同和不同的应用程序进行分区并进行单独处理。最后，影响分析，如在第4章节A小节描述的那样，允许将Linux内核代码库自动缩减为对使用的特定配置有直接影响的那些代码行，因此其他部分可以忽略从而降低工作量。
对于重用那些已经存在的开源元素，最重要的步骤是从传统的软件开发V模型过度到第3章A小节介绍的选择过程，以及第3张B小节讨论的论证新方法使用和量身定制已有方法的系统过程。
简而言之，SIL2LinuxMP项目的总体进展是，作者有信心通过完成这些概述的活动实现目标。
致谢
SIL2LinuxMP项目由开源自动化开发实验室（OSADL）管理以及SIL2LinuxMP合作伙伴公司参与。感谢他们的支持和赞助。
参考文档
[1] OSADL, SIL2LinuxMP Webpage,https://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html, 2016
[2] IEC 61508 Edition2, Functional safetyof electrical/electronic/programmable electronicsafety-related systemsIEC,2010
[3] Bloomberg, Driverless Cars GivingEngineers a Fuel Economy Headache,https://www.bloomberg.com/news/articles/2017-10-11/driverless-cars-are-giving-engineers-a-fuel-economy-headache,October 2017
[4] Andreas Gerstinger, Heinz Kantz andChristoph Scherrer, TAS Control Platform: A Platform for Safety-CriticalRailway Applications,https://publik.tuwien.ac.at/files/PubDat167529.pdf
[5] Peter Sieverding and Detlef John, SICASECC - die Platform fr Siemens-ESTW fr den Nahverkehr, Signal und Draht,May 2008
[6] CSE International Limited for theHealth and Safety Executive, RESEARCH REPORT 011: Preliminary assessment of Linuxfor safety related systems, 2002
[7] Audrey Canning, Functional Safety:Where have we come from? Where are we going? in Proceedings of theTwenty-fifth Safety-critical Systems Symposium, Briston, UK, 2017
[8] Guidelines for Initiating Events andIndependent Protection Layers in Layer of Protection Analysis, Center forChemical Process Safety (CCPS), 2015, Published by Wiley&Sons
[9] A guide to the Kernel DevelopmentProcess, https://www.kernel.org/doc/html/latest/process/developmentprocess. html, 2018
[10] GIT Repository of the MinimizationTool, https://github.com/Hitachi-India-Pvt-Ltd-RD/minimization, 2017