从ISO 26262到IEC 61508的软件安全映射研究

多年来，从 IEC 61508（通用）演变而来的是多项功能安全标准，例如 ISO 26262（汽车）、IEC 61511（工艺）、EN 5012X（铁路）、IEC 62061（机械）、IEC 61513（核能）等。标准的演变伴随着特定行业的额外要求和指导。然而，在某些情况下，技术进步的速度太快，标准无法规范，因此除了有可能使现有设计过时之外，还会产生无指导性的解释和混淆的空间。为了解决这个问题，正在推动跨行业资源（例如安全工件）的再利用，从而更符合最先进技术的行业将帮助弱势行业填补空白。然而，明确定义行业间交流的框架以避免混淆非常重要。本文的目的是研究是否以及如何将按照 ISO 26262（汽车）开发的软件的安全级别映射到按照 IEC 61508 开发的软件的安全级别。本文以文献和标准回顾为基础，重点关注软件元素。

一、简介

2011 年之前，汽车行业依靠 IEC 61508 进行功能安全开发。然而，2011 年，该行业凭借 ISO 26262 第一版和 2018 年底的第二版树立了自己的品牌。随后，全球技术领域的快速变化随之而来，并与汽车行业产生了共鸣，引领其在先进硬件和软件（基于 ISO 26262）的开发方面快速发展。与此同时，基于 IEC 61508 的开发滞后。然而，一般工业部门（基于 IEC 61508）发现了一个机会，可以重复使用汽车行业的硬件和软件，以便跟上技术变化的步伐，缩短上市时间，并通过新产品提高财务利润。与此同时，汽车行业仍敞开大门，允许其他领域的有趣安全元素流入其中，ISO 26262 中的“独立于上下文的安全元素”（SEooC）规定对此提供了支持。ISO 26262 中外部安全手册的重用与 SEooC 概念相关。然而，它只在 IEC 61508 中定义和描述，其中内容列表在第 2 部分和第 3 部分的规范附件中列出。这意味着在某些情况下，子标准并不完全脱离母标准，两者仍然可以在某些方面相互加强。

软件，无论其应用是什么，都不会发生随机故障，因为它们是不可降解的（即没有故障率），是无形资产。因此，软件的（定量）随机安全完整性没有依据。但是，软件可能会出现系统性故障（例如，架构和/或编码缺陷）。因此，对于电气、电子和可编程电子 (E/E/PE) 安全相关系统，软件的安全完整性是根据所应用的功能安全标准定义的软件开发保证来确定的。开发保证是一个涉及特定计划和系统性行动的过程，这些行动共同确保已识别并纠正需求或设计中的错误或遗漏，从而使实施的系统满足适用的认证要求。软件开发保证级别基本上由软件开发的严格程度或严格程度定义，与标准规定的方法、技术或措施的实施有关。方法在 ISO 26262 中使用，类似于 IEC 61508 中使用的技术和措施。

目前，对于最初按照 ISO 26262 开发但计划在 IEC 61508 方面重复使用的软件，尚无标准化基础对其进行重新认证。将软件从一个领域重新认证到另一个领域可能是一项艰巨的任务。因此，对于认证机构而言，拥有一个通用的转换框架/模板非常重要，这将减少繁琐的工作并消除混乱。此外，如果从头开始开发的软件没有按照适用的领域标准（例如 ISO 26262）正确开发，要根据另一个领域的标准（例如 IEC 61508）。因此，如果一家公司决定实现市场或产品设计的多样化，那么无论在哪个领域的软件开发过程中，只要严格遵守规则，那么在以后缩小标准差距的过程中，就会更便宜、更快捷。目前已经发现了一些关于功能安全标准各方面跨领域映射的同行评审出版物，但并未得出任何最终结论。因此，需要进一步研究。

本文的目的是根据 IEC 61508 的安全级别对最初根据 ISO 26262 开发的软件进行重新认证，以便重复使用。本文仅关注软件元素，包括其系统安全完整性。本文将比较 ISO 26262 与 IEC 61508 中的软件技术和措施 (T&M)。研究结果有望支持技术报告 (TR) IEC TR 61508-6-1“根据 ISO 26262 开发的硬件或软件处理”的发布，该报告预计将由 JTG20 工作组于 2025 年完成。本文其余部分的结构如下。首先，对四种功能安全标准的软件开发保证进行了比较。其次，对 ISO 26262 和 DO-178C 的软件开发保证进行了更详细的比较。随后，根据 ISO 26262 开发的软件将映射到 IEC 61598，同时考虑工件、支持流程和软件安全级别。接下来，提出讨论和建议，然后得出结论。

二、四项标准软件开发要求比较

比较四项安全标准的软件开发要求：前已建立了三个维度来比较根据不同功能安全标准开发的软件的开发保证，即：支持流程、开发流程和验证流程。但这应该包括工具鉴定，这是一个关键维度，本文的后续部分将填补这一空白。在功能安全标准中是否指定软件开发和验证方法方面，不同领域的相似之处如下图所示表格1。此外，还建立了六个维度来比较软件开发保证水平（DAL）对软件安全保证水平的影响，如下所示表 2。第二节开头提到的三个维度是表 2以这些维度作为比较的基础，两个表格都表明 ISO 26262 的软件与 ISO 26262 的软件和 IEC 61508大致相当，从而为两种标准之间更详细的差距分析提供了有希望的基础。当仅限于源自或受 IEC 61508 影响的标准时，建立 IEC 61508 与其他标准之间的跨域等效性预计不会那么繁琐。这是在进一步研究之前保持谨慎乐观的原因，因为预计会进行更细粒度的映射。

表 1.软件开发和验证手段的标准

表 2.开发保证水平对安全保证水平的影响

三、从ISO 26262到DO-178C

从ISO 26262到DO-178C的软件开发映射：本节的目的是确定一个框架，该框架可在下节中用作映射 ISO 26262 软件开发的基础至 IEC 61508。为此，引用本节正在审查汽车安全标准 (ISO 26262) 与其航空电子标准 (DO-178C) 之间的映射软件 。

图 1和2分别显示了 ISO 26262 和 DO-178C 之间关于工件和支持过程的软件相关映射。工件（在 ISO 26262 中也称为工作产品）是显示设计过程输出的可交付成果，而支持过程是支持软件开发并建立审查和认证活动接口的水平过程。所选工件如图所示图1是那些与安全性论证相关的内容。通过从语义和语用上比较文物的名称，可以看到两个领域之间存在良好的相关性，而且随着内容的不确定性最终得到解决，这种相关性将会改善。在图 2，仅考虑可映射的流程，而忽略了 ISO 26262 支持流程，例如分布式开发中的接口、文档和已证明使用的参数。这意味着在将软件从 ISO 26262 映射到 DO-178C 时承认支持流程的证据时，存在可接受的不确定性水平，而不是相反。基于这一有希望的评论下一节中进行进一步研究，并且本节中 ISO 26262 中未使用的支持流程将根据 IEC 61508 重新考虑，以查看它们是否合适。

图 1.比较 ISO 26262 和 DO-178C 的软件工件

图 2.比较 ISO 26262 和 DO-178C 的支持流程

四、软件安全等级映射

ISO 26262 到 IEC 61508的软件安全等级映射：本节的目的是从已实施的方法中吸取的经验，从而映射 ISO 26262 和 IEC 61508 之间的软件开发保证。这将与对标准与涵盖三个维度（即开发过程、验证过程和支持过程）的技术 / 措施的更详细调查相结合。

在图 3，软件相关工件从 ISO 26262 到 IEC 61508 的映射令人满意。这可能是因为当 ISO 26262 从 IEC 61508 衍生出来作为汽车领域的行业特定安全标准时，其目的并不是与 IEC 61508 完全决裂，而是一个机会，使某些方面更适合汽车行业，从而强调该领域与其他领域不同的一些观点，例如在风险管理方面。然而，从ISO 26262映射到IEC 61508时，仍然需要对工件进行详细的内容分析，以减少不确定性。

图 3.比较 ISO 26262 和 IEC 61508 的软件工件

关于支持流程的比较，图 4显示了从 ISO 26262 到 IEC 61508 的完美映射。在这种情况下，ISO 26262 支持流程（例如分布式开发中的接口、文档和已证明的使用中的参数）也包括在内，这些在 ISO 26262 和 DO-178 之间的映射中被省略（如第 3 节所述）。但是，流程的内容也需要详细分析以减少不确定性。在表 3-6。

图 4.比较 ISO 26262-6 和 IEC 61508-3 的支持流程

表 3.软件安全需求管理技术比较

表 4.比较设计和编码要求

表 5.比较错误检测和处理要求

表 6.比较软件工具的要求

在表 3-6，实现了对工件内容和支持过程的详细映射。这些表格包括规范性和信息性技术/措施（有助于避免或控制系统故障）及其建议（即 - = 不适用、O = 可选、NR = 不推荐、+ 或 R = 推荐和 ++ 或 HR = 强烈推荐）。排名与目标软件安全级别（ISO 26262 定义的 ASIL 和 IEC 61508 定义的 SIL）相关，有望完善映射过程。

让我们考虑一下表 7为了本次讨论的目的，因为它基于最近一篇论文中审查的所有文献中最有力的科学论证关于 ISO 26262 和 IEC 61508 之间系统安全等级映射的问题。基于此，在很大程度上观察到表 3-6ASIL D 与 SIL 3、ASIL C 与 SIL 2、ASIL B 与 SIL 1 之间映射的技术或措施的推荐之间存在相关性。因此，映射方案已针对软件进行验证。

表 7.不同域安全级别的映射

此外，在基于技术/措施及其建议的相似性（即在表 8) 与期望的安全等级的关系，需要考虑在实现目标安全等级（或系统安全完整性）的技术/措施上所花费的开发工作量（也称为严谨性）。系统安全完整性在 IEC 61508 中也称为系统能力。

表 8软件系统能力技术/措施和特性严谨性建议。

IEC 61508 为软件建立系统安全完整性提出了两个标准：1）选择与给定 SIL 相对应的技术或措施，2）展示严谨性（在表 8) 来确保所选技术或措施满足软件系统安全完整性的属性。严谨性在表 8，等级如下：R1（最低 - 适用于 SIL 1/SIL 2 应用）、R2（中等 - 适用于 SIL 3 应用）和 R3（最高 - 适用于 SIL 4 应用）。软件系统安全完整性的属性包括：1）相对于安全需求的完整性，2）相对于安全需求的正确性，3）不存在固有规范故障，包括不存在歧义，4）安全要求的可理解性，5）不存在非安全功能对安全需求的不利干扰，6）能够提供验证和确认的基础。

在表 9，ISO 26262规定的技术映射到IEC 61508（使用表3（作为示例）按照 IEC 61508-3 附件 C 第 C.2 节所规定的软件系统安全完整性属性进行严格处理。

表 9.系统安全完整性的属性——软件安全要求规范

五、讨论和建议

本文的目标是使最初根据 ISO 26262 开发的软件符合 IEC 61508 安全完整性等级的要求，并可供重复使用。这已在第 4 部分实现，本文总结并推荐了如下系统方法：

根据表格，将 ISO 26262-6 中的技术/措施映射到 IEC 61508-3 中的系统安全等级（即 ASIL 和 SIL）。

应用ISO 26262的适用技术/措施、IEC 61508-3附录C第C.2节规定的保证软件系统安全完整性的特性和严谨性。

按照IEC 61508的建议，优先考虑ISO 26262的适用技术/措施。

总体而言，ISO 26262和IEC 61508的软件属性可以方便地相互映射，从而可以重新定义安全级别，如本文所示。值得注意的是，ISO 26262 采用了 IEC 61508 的基本原则，此外还包含一些汽车行业特定的要求和指导，因此从 ISO 26262 过渡到 IEC 61508 比从 IEC 61508 过渡更容易。当 IEC 61508 没有提供满足某些要求的具体细节（例如，与工具鉴定有关）时，也建议联合使用 ISO 26262 和 IEC 61508。与 ISO 26262 不同，IEC 61508-3, 7.4.4.5 规定“当识别出此类故障机制时，应采取适当的缓解措施”，但没有提供这些措施的详细信息，从而留下了更多的解释空间。

六、结论

本文实现了一个框架，用于将基于 ISO-26262 的软件映射到 IEC 61508 的安全级别。这有望指导汽车行业在通用行业中重复使用与安全相关的资源，而不会损害安全性。本文以文献和标准回顾为基础，它旨在让工程师、标准组织和认证机构更深入地了解汽车行业（基于 ISO 26262）和通用行业（基于 IEC 61508）之间的跨领域软件合作，以便共同赶上技术发展的步伐，一个行业可能已经在与最先进技术保持一致方面领先于另一个行业。