有关安全管理的选定主题ISO26262:2018-10-5

5.1.工作成果

这一小节描述了“工作成果”一词。

工作成果是满足ISO26262系列标准相应要求的结果（见ISO26262-1：2018的3.185）。因此，工作成果可以提供符合这些安全要求的证据。

需求规范是可以通过需求数据库或文本文件记录的工作成果。可执行模型是一种工作成果，可以通过建模可以执行的语言文件来表示（例如：用于使用软件工具进行模拟）。

工作成果的文件（见【文档管理】ISO26262-8：2018的第10条）作为执行的安全活动、安全要求或相关信息的记录。这种文件不限于任何形式或媒介。

工作成果的文档可以用电子或纸质文件、单个文档或一组文档来表示。它可以与其他工作成果的文档或不直接用于功能安全的文档相结合。

为了避免信息的重复，可以使用文档内部或文档之间的交叉引用。

5.2.确认措施

5.2.1概述

在ISO26262中，指定的工作成果在随后的活动中被评估，无论是作为确认措施的一部分，还是作为验证活动的一部分。本款说明核查和确认措施的区别。

验证活动是ISO26262中的主要措施，以提供证据证明工作成果是合适的，并符合相应的要求。工作成果的验证可包括：

Ø 根据更高级别的安全要求，对导出的安全要求的规范或实施进行验证，涉及完整性和正确性；或

Ø 通过行使相关项或其要素，执行测试用例和检查测试结果，以提供满足特定安全要求的证据。

验证活动在ISO26262-3、ISO26262-4、ISO26262-5和ISO26262-6中有规定。此外，ISO26262系列标准中有关验证活动的一般要求在【验证】（ISO26262-8：2018中规定，第9条）和【安全需求规范和管理】（ISO26262-8：2018的第6条）中规定了具体的安全要求验证细节。

工作成果的验证可以通过使用技术进行，例如：

Ø 评审；

Ø 模拟；

Ø 分析；或

Ø 测试。

认可措施在【认可措施】（ISO26262-2：2018的6.4.9）中规定，并被执行以评估相关项在功能安全方面的成就。

示例：如果在系统架构设计阶段应用ASIL分解：

对由此产生的系统架构设计的验证是根据技术安全概念进行的（见【认可措施】ISO26262-4：2018的6.4.9）；及

【关于ASIL剪裁的需求分解】（ISO26262-9：2018的第5条），确认ASIL分解的正确应用可以作为功能安全评估的一部分进行，包括确认已经进行了相关故障分析，并证明在实现相应冗余安全要求的要素之间声称有足够的独立性。

5.2.2功能安全评估

如果相关项安全目标的最高ASIL是ASILC或D，则进行功能安全评估，以评估相关项实现功能安全的情况。在ISO26262-2中，描述了功能安全评估的某些方面以及确认措施的进一步方面。

功能安全评估的范围在【相关项的安全管理】（ISO26262-2：2018的第6条）。

在进行功能安全评估的情况下，功能安全审计和确认评审的结果是功能安全评估的输入。负责评估的人可以根据自己的酌处权进行评估，包括如何利用功能安全审计和确认评审的结果。

示例1如果功能安全审计的结果令人满意，负责功能安全评估的人可以决定相关审计的结果，而不进一步判断功能安全所需流程的执行情况。

示例2：根据特定工作成果的确认评审报告，负责评估的人可以决定对该工作成果的某些方面进行更深入的评审，或者可以检查确认评审是否充分考虑到该工作成果与相关工作成果之间的相互作用。

注1：负责功能安全评估的人可能进行特定的确认评审，即。确认评审不一定由与评估责任人不同的人进行。

功能安全评估可以重复或更新。

示例3：由于相关项或相关项要素的变更而进行的功能安全评估更新，该更新被变更管理识别为对相关项的功能安全有影响（见ISO26262-8：2018的第8条【变更管理】）。

示例4功能安全重新评估，由功能安全评估报告触发，该报告建议有条件接受或拒绝该相关项的功能安全。在这种情况下，迭代包括对上一次功能安全评估所产生的建议采取后续行动，包括评估所执行的纠正行动（如果适用的话）。

如果相关项的安全目标的最高ASIL是ASILA或ASILB，则可以省略或执行不那么严格的功能安全评估。然而，即使没有进行功能安全评估，其他确认措施仍在执行（见ISO26262-2：2018的表1）。

在分布式开发的情况下，功能安全评估的范围包括车辆制造商和相关项供应链中的供应商生成的工作成果以及实施的过程和安全措施（见ISO26262-2和ISO26262-8：2018的第5条【分布式开发的接口】）。

功能安全评估的目的是评估一个相关项在功能安全方面的成就，这只有在相关项层面是可能的。因此，供应商的功能安全评估（开发相关项要素）仅指范围有限的评估，它本质上是对随后的功能安全评估活动（在客户层面）的输入。作为相关项开发的最终客户，车辆制造商指定人员进行全面的功能安全评估，以判断相关项的功能安全成就。这一判断包括提供接受、有条件接受或拒绝相关项功能安全的建议。

注2：对于一级供应商负责相关项开发的情况，包括车辆集成，该供应商接管上述角色的车辆制造商。

因此，以实际的方式，可以将分布式开发情况下的功能安全评估分为：

Ø 功能安全评估范围有限，涉及供应链中的供应商。适用的ASIL是由供应商开发的相关项要素（也见ISO26262-8：2018的5.4.5（Functional safety assessment activities in a distributed development））的最高继承的ASIL（相关项的安全目标）；及

Ø 最后的功能安全评估，包括对集成相关项实现的功能安全的判断，例如。由车辆制造商执行。适用的ASIL是安全要求的最高ASIL（另见ISO26262-2）。

示例5：汽车制造商开发了一个带有ASILD安全目标（SG1）和ASILB安全目标（SG2）的相关项，并将对该相关项进行功能安全评估。例如，第二层或第三层供应商可能只开发相关项的ASILB要素，即。只有继承SG2的ASIL的要素（然而，如果要素共存的标准适用的话，请参阅【要素共存标准】（ISO26262-9：2018的第6条）。在ISO26262-2：2018中有一个建议，表1对这个要素的开发执行具有独立性I0的功能安全评估。

范围、程序（例如：供应商提供的工作成果、客户评审的工作成果）和关于客户与供应商之间接口的功能安全评估的执行在相应的开发接口协议中规定（见ISO26262-8：2018的第5条【分布式开发的接口】）。

示例6：DIA between avehicle manufacturer （customer） and a Tier1 supplier.DIA between a Tier1 supplier（customer） and a Tier2 supplier.

在分布式开发的情况下进行功能安全评估的一种可能方式是，车辆制造商和供应链中的供应商各自处理各自负责的评估活动的那些方面，具体如下：

供应商评审在所制定的要素中实施的安全措施，包括其适当性和有效性，以符合相应的安全目标或安全

要求（由客户提供或由供应商开发），并评估其实施的过程和适用的工作成果。供应商还评估所开发的要素对相关项功能安全的潜在影响，例如。确定实施的安全措施是否会导致新的危险；以及

车辆制造商评估集成相关项的功能安全性。评估的一部分可以基于一个或多个供应商提供的工作成果或信息，包括功能安全评估报告。

注3：客户可以评估供应商实施的安全措施和供应商提供的工作成果。客户还可以评估供应商在供应商场所实施的过程（见ISO26262-8：2018的5.4.3.1）

5.3.安全档案的理解

5.3.1安全档案解读

安全案件的目的是提供一个明确、全面和可辩护的论证，并有证据支持，即一个相关项在预期的环境中操作时没有不合理的风险。

这里给出的指导重点是ISO26262的范围。

安全档案有三个主要要素，即：

Ø 安全目标和相关安全要求（相关项或要素的安全目标）；

Ø 安全论证；及

Ø ISO26262系列标准工作成果（即证据）。

这三个要素之间的关系，在ISO26262系列标准的背景下，如图7所示。

图7-安全档案的关键要素（见参考［2］）

安全论证传达了证据和目标之间的关系。可以提出许多页的辅助证据，而不清楚地解释这些证据与安全目标的关系。论证和证据都是安全案件的关键要素。没有证据支持的论证是没有根据的，因此没有说服力。没有论据的证据无法解释，导致对如何满足安全目标缺乏明确性。安全档案通过安全档案报告的编写和展示进行传达。安全档案报告的作用是总结安全论证，然后参考捕捉支持安全证据的报告（例如：测试报告）。

到目前为止，在其他行业中使用的安全论证经常通过叙述性文本在安全档案报告中传达。叙述性文本可以描述安全目标是如何被解释、分配和分解的，最终导致引用证据来证明完成了较低级别的安全声明。或者，或者作为支持，图形参数符号（例如声明-参数-证据和目标结构符号［2］）可以用来直观和明确地表示安全参数的个别要素（要求、声明、证据和使用环境）以及这些要素之间存在的关系（即。个人需求如何得到特定声明的支持，声明如何得到证据的支持，以及为论证定义的假设使用环境）。

一种安全论证，通过对已实现相关项的特性的直接上诉来论证安全（例如：定时看门狗的行为）通常被称为产品参数。通过对开发和评估过程的特点的吸引力来论证安全的安全论证（例如：所采用的设计符号）通常被称为过程参数。

这两种类型的参数都可以用来实现相关项安全性的合理参数，其中过程参数可以看作是对产品参数中使用的证据的信心。

5.3.2安全档案开发生命周期

安全档案的开发可以被视为与安全生命周期的其他开发阶段集成的增量活动。

注意，安全计划可以包括增量步骤的计划和安全档案的初始版本。

这种方法允许在产品开发的给定里程碑上的安全档案的中间版本。例如，安全档案的初始版本可以在技术安全要求验证后创建；安全档案的临时版本可以在系统设计验证后创建；最终版本可以在功能安全评估的最终报告之前创建。

安全档案须接受【认可措施】（ISO26262-2：2018的6.4.9）中给出的确认评审。

如果相关项被修改，对安全档案的影响将被评估，如果必要的话，考虑到修改，安全档案将被更新。

责任编辑：haq