智能汽车安全新媒体
专栏
深度解读，如何根据ISO26262开发安全要求
本文主要内容分为6个部分（约4200字，13分钟阅读）
文章系转载，仅做分享交流之用，不代表平台观点。
ISO的目的是识别和分类车辆系统的潜在风险，并得出与预防或者减轻这些危害相关的安全概念和相关的安全要求。对于复杂和分布式开发系统而言，安全要求的开发通常包含以下挑战：
● 在危害分析中找到正确的细节点（进行有效的审查）
● 定义安全目标，使其推动实现（以支持系统的开发）
● 文档假设（以明确清晰的相关项范围）
● 证明安全概念（以支持安全档案）
● 不要遗漏相关的要求或者属性（以确保完整性）
● 支持主机厂和供应商的接口（以避免不一致）
本文从ISO 26262中所要求的关键产出物——相关项定义、危害分析、安全目标、功能安全要求、技术安全要求等的角度提出建议，来保证安全要求开发的完整性。
相关项定义的目的是定义和描述在整车层面的相关项，并对其进行充分的理解，目标是使安全生命周期中定义的每个活动能够充分执行。初步危害分析是根据相关项定义进行的，安全概念是根据此信息得出的。相关项定义是安全项目的“快照”，不能根据安全过程后期或发生其他技术变化时得出的安全要求进行更新。当我们对功能进行修改，增加或者删除时，应当及时对相关项定义进行更新。
相关项定义应该包括：
● 法规要求，国家标准和国际标准；
● 整车层面的功能行为，包括运行模式或者运行状态；
● 所要求的功能的质量，性能和可用性（如果适用）；
● 相关项的约束，比如功能依赖性，与其他相关项的依赖 性等；
● 行为不足的潜在后果（如果有的话），包括已知的失效模式和危害；
● 执行器的能力，或者其假定的能力；
准备危害分析
初步危害分析是基于系统发生故障假设的“理想实验”。得出的结果是可能危险的列表，包括指定的ASIL等级，反应危害事件的危险程度。为了支持识别故障的系统方法，在执行危害分析和风险评估之前，提前准备一套关于故障模式考虑的指导词是很有帮助的。指导词可以帮助开发者去考虑相关的失效(典型的指导词有"NO,UNINTENDED,EARLY,LATE,MORE,LESS,INVERTED,INTERMITTENT")。对于每一个指导词，指导词的含义应该根据要考虑的系统的主要功能来描述。例如，对于电子转向柱锁功能，“UNINTENDED”是指系统在需要转向的情况下锁定。（注意：重要的是要确保在正确的细节级别上完成这一步骤。应避免有太详细的级别和太多的功能/子功能，以使危害分析具有可评估性。）
通常，从执行器的角度而不是传感器的角度来考虑故障模式是有帮助的，因为考虑故障模式的任务不是对现有设计的验证——这将在功能安全过程的后续步骤中通过适当的安全分析（FMEA, FTA, …）来完成。
场景分析和危害识别
对于在前一步骤中确定的功能和故障的所有组合，应描述系统在出现故障时的行为。例如，对于前面描述的故障，对系统级别的影响是电子转向柱锁锁定转向柱。对于每一个故障模式，所有可能导致潜在危险的操作情况、系统/操作模式、用例和环境条件等，应该：
● 被明确（可以由相关数据库支持）；
● 在危害分析中被引用；
相关的数据库应该包括操作情况、运行模式和环境条件。如果在项目中发现了新的方面，可以及时地更新到数据库中，以减少忘记/遗漏危险情况的风险。
我们需要描述潜在相关项发生故障时可能对整车层面产生的影响。例如，前面描述的故障对整车层面的影响是转向被锁定，车辆无法转向。基于对整车层面的影响，描述了危险和可能的后果。我们可以根据在整车层面上可以观察到的条件或者事件来定义危险，并将它们描述出来。
另外，假设也应当被描述出来（例如，驾驶员为确保可控性而采取的行动）。这些假设加强了危害分析的范围。推导出要求，并在随后的步骤中通过适当的方法验证这些要求。为了使风险清晰明了，每一个风险最好有唯一的ID标识。
危害分类
接下来，我们便可以通过以下步骤对危险进行分类（分类的目的是评估危害所需的风险降低水平）：
● Severity——潜在严重程度的估计（包含合理的理由）
● Exposure——暴露概率的估计（包含合理的理由）
● Controllability——可控性的估计（包含合理的理由）
图1 严重度-暴露概率-可控性的分类
（图片来源 ISO 26262, PART3）
基于上面三个参数的估计，确保ASIL的确定是按照ISO 26262中的定义进行的。
图2 ASIL等级的确定（图片来源 ISO 26262, PART3）
定义安全目标
功能安全目标是基于危害分析和风险评估中定义的危害的最高水平的安全要求。
以下规则有助于确保得出的安全目标支持系统开发：
● 安全目标应该清晰、准确；
● 安全目标不应包含技术细节；
● 安全目标应能够通过技术手段实现；
● 安全目标应具有唯一的标识ID；
● 应为每种被评定为ASIL A, B, C, D的危险指定至少一个安全目标；
● 一个安全目标可以分配给多个危险；
● 一个危险可能有多个安全目标；
● 如果安全目标可以通过转换到或者维持一个或多个安全状态来实现，则应规定好相应的安全状态。
为了符合初步危害分析的安全目标，功能安全概念以功能安全要求的形式规定了基本的安全机制（Safety Mech-anism）和安全措施（safety measures）。
图3 安全要求的结构和分布
（图片来源 ISO 26262, PART3）
功能安全要求被分配给系统架构中的要素。当我们开发功能安全概念时，可以考虑以下几点：
● 对于每一个安全目标，至少可以分解出一个功能安全要求。
● 除此之外，将初步危害分析中的假设转化成功能安全要求，来确保在验证和确认过程中处理这些假设。
● 开发功能安全要求时，可以提前把需求的各种类别/属性定义出来（比如：信息，安全需求，操作模式，ASIL等级，安全状态等）。类别和属性有助于需求工程师对需求进行恰当的描述。
● 对于有冗余设计的需求，我们可以通过ASIL分解的方法来降低单个需求的ASIL等级。分解通常会导致额外的需求。
● 功能安全要求被分配给初始架构里的要素。通常，我们把功能安全要求分配给逻辑块而不是物理组件。在一个项目中，不同的方案来分配功能安全要求，其技术实现也不同。
● 执行安全分析，以确保功能安全概念和初始的危害分析之间的符合性和一致性。
图4 需求的种类及其属性
在安全要求规范中，功能安全要求被分解为分配给单个组件或者子系统的技术安全要求。为了明确技术安全要求，系统设计是必要的，反之亦然，技术安全要求会对系统设计产生影响。
开发技术安全要求时，通常要考虑以下几点：
● 来自系统设计，相关项定义和功能安全概念的输入信息：外部接口，约束，技术框图，组件和子系统的功能概述，内部接口，以及系统层级架构的描述，包含系统层面的冗余概念。这些输入一定程度上可以确保系统设计和技术安全要求是一致的。
● 由功能安全要求开发出的技术安全要求，包括FTTI，紧急操作，验证与确认等等。技术安全要求的类别和属性也可以参考上面的表格。
● 对子系统分配好硬件指标要求（不同等级的产品有不同的要求，请参考ISO 26262第五部分）。
图5 硬件指标值的定义（see ISO 26262, Part5）
● 同样在安全要求规范中，我们也可以进行ASIL分解，并定义安全相关的参数。
● 开发的技术安全要求要匹配到相应的组件或者子系统上。
● 执行安全分析，以确保技术安全概念，功能安全概念和初始的系统架构假设之间的符合性和一致性，并验证系统设计是否满足技术安全要求。
ISO 26262定义的技术安全要求涵盖了通常由OEM定义的系统级别（包括对子系统/组件的要求），但是也涵盖了组件/子系统的内部要求。这些子系统/组件一般都是供应商开发的。
● 在技术安全要求中，组件/子系统的内部方面，如：
￮ 与部件内故障检测相关的措施；
￮ 内部故障响应的详细信息；
￮ 避免潜在失效；
￮ 多点故障检测时间间隔；
￮ 对组件架构/冗余概念的描述，包括对处理潜在相关 故障的措施的描述（主机厂通常不会给出详细的要求，细节的设计要求通常由组件/子系统的供应商来给出）。
● 对硬件指标值的分配：
￮ 如果使用了冗余设计，并且故障检测不限于单个组件，最好为每一个组件分配好单点故障度量（SPFM）和潜在故障度量(LFM)的目标值。不然，实现该安全目标的组件/子系统应直接继承安全目标对应的SPFM和LFM目标值。
安全验证和确认报告包括详细的验证和确认计划以及状态的追踪：
● 安全分析和规范之间的一致性（功能安全要求、技术安全要求以及详细的软硬件安全要求）。
● 所有安全相关要求/参数状态的验证和确认。
● 定义、确认和设计验证的状态。
● 确认硬件指标计算。
对安全目标和功能/技术安全要求来说，可参考以下活动：
● 应参考相应的分析要素，并在安全V&V报告中计划必要的验证和确认活动。
● 所有活动应根据开发生命周期计划来进行，并记录相应的结果（形成文件），以证明所有安全目标都已实现，所有功能/技术安全要求都已满足。
对于安全目标来说，可参考以下活动：
● 在安全目标层面计算硬件度量指标值（PMHF, SPFM, LFM），并对计算的结果和结论进行评估和验证。
对功能安全概念来说，可参考以下活动：
● 验证（比如：测试）应该以文档的形式记录下来。并对其正确性和完整性进行评估和验证。
● 如果为功能安全要求定义/明确了参数，那相关的参数的验证规范需要给出（包括验证活动和通过标准），并对其正确性和完整性进行评估和验证。
● 按照计划执行规定的验证和确认活动（比如：评审，测试），并记录相应的V&V结果（形成文件）。测试结果应满足通过标准。
对技术安全要求来说，可参考以下活动：
● 开发相应的验证规范，来验证技术安全要求的正确实现（如故障注入，安全相关功能测试等），并对验证规范的正确性和完整性进行评估和验证。
● 组件/子系统供应商应按照技术安全要求开发详细的软件和硬件的安全要求，并检查以下几方面：
￮ 供应商方面的实现过程是合适恰当的。
￮ 软件和硬件的安全要求，软硬件接口和组件的设计都是根据技术安全要求得到的，并保证其正确性和完整性。
￮ 执行安全分析，确认相应的违反技术安全要求的故障，并确保安全分析的完整性和正确性。
￮ 正确的软件和硬件设计（包括内部和外部的接口），并与安全分析相对应。
● 组件/子系统供应商应完善技术安全要求：
￮ 对于内部故障处理类的要求，要明确与检测和指示组件内故障有关的措施，以及内部故障相应的详细信息。
￮ 对于潜伏故障处理类的要求，要明确与部件内故障的检测和指示相关的措施，潜伏故障的避免，以及故障响应的详细信息。
￮ 对于定义的PMHF的要求，对组件设计架构的描述（冗余概念的描述，如有），以及处理潜在相关失效的措施的描述。
● 组件/子系统的供应商验证组件中软件和硬件安全要求的实现，可以检查如下几方面：
￮ 根据测试规范，验证所开发的安全机制的有效性和故障覆盖是满足要求的。
￮ FMEDA的计算结果是满足相应ASIL等级的指标要求的。
￮ 如果需要的话，对相应的软件/硬件组件进行鉴定，并生成鉴定报告。
对于每一个V&V活动，责任，对相应文件的引用以及状态都应该在安全V&V报告中进行追踪。OEM和供应商接口，以及双方涉及到的ISO26262部分如下所示。
图6 OEM与供应商的接口
参考资料：
[1] ISO 26262:2018, Part1;
[2] ISO 26262:2018, Part2;
[3] ISO 26262:2018, Part3;
[4] ISO 26262:2018, Part4;
[5] ISO 26262:2018, Part5;
[6] SEMANTIC SCHOLAR search;
- THE END -
因文章部分文字及图片涉及到引用，如有侵权，请及时联系17316577586，我们将删除内容以保证您的权益。
