认识ISO/PAS 8926标准-MUNIK知识普及课堂

国际标准组织ISO新编写的ISO/PAS 8926:2024《道路车辆 — 功能安全 — 使用预先存在的软件架构元素》- 作为一个公开可用规范（Publicly Available Specification）- 提供了一套框架，用于在符合ISO 26262:2018系列标准的安全相关嵌入式软件中，使用那些并非最初按照该系列标准开发的预先存在的软件架构元素（Pre-existing Software Architectural Elements, PSAEs）。之前聊过ISO26262中的软件复用话题（点击链接，可以跳转），而这个新标准ISO8926可以说是为软件复用实践中长久以来的争论落实了一种具体的做法和流程。

图四 ISO/PAS 8926封面

ISO8926标准的核心方法论可以说是参照ISO26262第8部分Clause 13“硬件要素的评估”制定了一个对于预先存在的软件架构元素（Pre-existing Software Architectural Elements, PSAEs）的分级方法，如图5。在汽车行业中，许多软件组件在开发时并没有考虑到严格的汽车安全标准（如ISO 26262），但它们可能对实现某些功能非常有用。PSAE就是这类软件组件的总称，它们可能包括操作系统、数据库管理系统、中间件或其他库等。想象一下，你要建造一座房子，但不是从零开始，而是使用一些旧的、预先做好的砖块。这些砖块可能很结实，但你知道它们不是专门为你的新房子设计的。ISO/PAS 8926:2024就是一套规则，教你如何检查这些旧砖块是否足够结实，能否安全地用在你的新房子里。

使用ISO/PAS 8926:2024标准对软件组件进行安全评估的具体步骤可以概括如下：

1.       确定适用性：首先确定预先存在的软件架构元素（PSAE），即那些不是为ISO 26262标准开发的软件组件，是否符合ISO8926的适用范围。

2.       收集信息：搜集有关该PSAE的所有相关信息，包括设计文档、源代码、使用情况、维护历史等。

3.       进行PSAE分类：根据PSAE的来源和复杂性对其进行分类。分类基于两个维度：

o       来源（Provenance）：考虑软件开发过程的不确定性。这指的是PSAE的出身和历史，包括它们是如何开发、测试和验证的。如果PSAE的开发遵循了良好的软件工程实践和标准，那么它们的风险可能较低。

o       Provenance的分级示例如下：

o       P1：基于IEC 61508、RTCA DO-178C，或ISO/IEC/IEEE 12207开发的软件。

o       P2：实施了软件开发流程，与P1有差距，并且安全风险可以弥补或可接受。

o       P3：除了P1、P2以外的其他情况都视作P3（未实施软件流程，直接写代码，文档说明零散）。

o       复杂性（Complexity）：考虑软件设计和实现的难度。这涉及到PSAE的设计和实现的复杂度。如果一个PSAE有很多复杂的功能和交互，那么理解和验证它们是否安全可能更加困难。

o       Complexity的区分标准参考标准附录B，有圈复杂度、全局变量等。

o       C1：复杂度没有超标；

o       C2：复杂度超标但可接受；

o       C3：其他情况都是C3。

o       综合两者我们可以查表得出PASE的分级如下：

图5 PSAE的分级（来源：ISO/PAS 8926）

o       综合两者我们可以查表得出PASE的分级如下：

o       Class I：低风险，可能不需要额外的验证和测试。这里我们推荐直接采用ISO26262第8部分Clause 12，可参考前面的案例1。

o       Class II：中等风险，需要进行一些额外的验证和测试来确保它们可以安全使用。在这个级别的PSAE需要细化需求和架构，细化安全分析以及测试验证。

o       Class IIb：较高风险，需要更多的安全措施和严格的测试。

o       Class NR：不推荐用于功能安全，因为风险太高。

4.       影响分析：分析PSAE在目标软件架构设计中的操作环境、外部接口、目标环境、调度、时间以及并发性等方面，评估其对功能安全的影响。

5.       分配软件安全要求：将软件安全要求分配给PSAE的相应功能和属性，并评估PSAE是否符合这些要求。

6.       审查PSAE现有文档：评估PSAE现有文档是否提供了足够的证据来支持其在目标软件架构设计中的功能安全。

7.       规划安全活动：根据PSAE的分类，规划必要的安全活动，以识别和减轻PSAE潜在的系统性故障，并确保实施必要的安全措施。

8.       适用性评估：对于Class II PSAE，进行细化的架构设计、软件安全要求的细化、安全导向分析，并验证PSAE的适用性评估结果。

9.       安全措施的实施和验证：实施从安全导向分析中得出的安全措施，并验证这些措施的有效性。

10.       PSAE使用验证：验证PSAE及其在目标软件架构设计中的集成是否符合影响分析和适用性评估的要求。

11.       设计变更管理：如果需要对PSAE进行修改，执行变更管理流程，包括变更请求分析、实施变更，并更新相关文档。

12.       编制工作产品：编制和更新各种文档，如影响分析报告、安全计划、软件安全要求、硬件-软件接口规范、软件架构设计规范、安全导向分析报告、软件验证报告以及变更报告。

13.       持续监控和更新：在PSAE的使用过程中持续监控其性能，并根据需要更新安全评估。

结论

经过前面 ISO/PAS 8926的内容介绍，我们可以大致总结出PSAE的分级与ISO 26262标准的匹配方式如下：

·       Class I PSAE：通常是那些开发过程符合ISO 26262或其他功能安全标准，且复杂性较低的软件组件。这些组件可能不需要额外的验证活动，因为它们已经被证明是安全的。

·       Class II PSAE：可能需要一些额外的验证和测试来确保它们满足功能安全要求。这些组件可能来源于非汽车行业的标准，或者它们的复杂性较高，需要更多的审查来确保它们在汽车系统中的安全使用。

·       Class IIb PSAE：具有较高的复杂性，需要更严格的测试和审查。可能需要对这些组件进行特定的安全活动，如额外的测试、代码审查或安全分析。

·       Class NR PSAE：不推荐用于需要符合功能安全的应用，因为它们的来源或复杂性使得无法合理地验证它们的安全性。

通过这种分级，就如前面的比喻中所说，我们可以比较清晰地确定需要对每个砖头（PSAE）采取哪些措施，以确保它们在建造的房子（汽车软件系统）中的使用不会违反ISO 26262标准的功能安全要求。可以预见，这样系统化的方法定义在汽车行业向智能化和网联化转型的今天将得到广泛的应用，因为开源软件和Linux系统在汽车行业的应用正变得越来越广泛，主要得益于其灵活性、成本效益和强大的社区支持。