相关项定义的目的是定义和描述在整车层面的相关项，并对其进行充分的理解，目标是使安全生命周期中定义的每个活动能够充分执行。初步危害分析是根据相关项定义进行的，安全概念是根据此信息得出的。相关项定义是安全项目的“快照”，不能根据安全过程后期或发生其他技术变化时得出的安全要求进行更新。当我们对功能进行修改，增加或者删除时，应当及时对相关项定义进行更新。
初步危害分析是基于系统发生故障假设的“理想实验”。得出的结果是可能危险的列表，包括指定的ASIL等级，反应危害事件的危险程度。为了支持识别故障的系统方法，在执行危害分析和风险评估之前，提前准备一套关于故障模式考虑的指导词是很有帮助的。指导词可以帮助开发者去考虑相关的失效(典型的指导词有"NO,UNINTENDED,EARLY,LATE,MORE,LESS,INVERTED,INTERMITTENT")。对于每一个指导词，指导词的含义应该根据要考虑的系统的主要功能来描述。例如，对于电子转向柱锁功能，“UNINTENDED”是指系统在需要转向的情况下锁定。（注意：重要的是要确保在正确的细节级别上完成这一步骤。应避免有太详细的级别和太多的功能/子功能，以使危害分析具有可评估性。）
通常，从执行器的角度而不是传感器的角度来考虑故障模式是有帮助的，因为考虑故障模式的任务不是对现有设计的验证——这将在功能安全过程的后续步骤中通过适当的安全分析（FMEA, FTA, …）来完成。
(资料图)
对于在前一步骤中确定的功能和故障的所有组合，应描述系统在出现故障时的行为。例如，对于前面描述的故障，对系统级别的影响是电子转向柱锁锁定转向柱。对于每一个故障模式，所有可能导致潜在危险的操作情况、系统/操作模式、用例和环境条件等，应该：
相关的数据库应该包括操作情况、运行模式和环境条件。如果在项目中发现了新的方面，可以及时地更新到数据库中，以减少忘记/遗漏危险情况的风险。
我们需要描述潜在相关项发生故障时可能对整车层面产生的影响。例如，前面描述的故障对整车层面的影响是转向被锁定，车辆无法转向。基于对整车层面的影响，描述了危险和可能的后果。我们可以根据在整车层面上可以观察到的条件或者事件来定义危险，并将它们描述出来。
另外，假设也应当被描述出来（例如，驾驶员为确保可控性而采取的行动）。这些假设加强了危害分析的范围。推导出要求，并在随后的步骤中通过适当的方法验证这些要求。为了使风险清晰明了，每一个风险最好有唯一的ID标识。
接下来，我们便可以通过以下步骤对危险进行分类（分类的目的是评估危害所需的风险降低水平）：
基于上面三个参数的估计，确保ASIL的确定是按照ISO 26262中的定义进行的。
以下规则有助于确保得出的安全目标支持系统开发：
为了符合初步危害分析的安全目标，功能安全概念以功能安全要求的形式规定了基本的安全机制（Safety Mech-anism）和安全措施（safety measures）。
功能安全要求被分配给系统架构中的要素。当我们开发功能安全概念时，可以考虑以下几点：
在安全要求规范中，功能安全要求被分解为分配给单个组件或者子系统的技术安全要求。为了明确技术安全要求，系统设计是必要的，反之亦然，技术安全要求会对系统设计产生影响。
开发技术安全要求时，通常要考虑以下几点：
ISO 26262定义的技术安全要求涵盖了通常由OEM定义的系统级别（包括对子系统/组件的要求），但是也涵盖了组件/子系统的内部要求。这些子系统/组件一般都是供应商开发的。
安全验证和确认报告包括详细的验证和确认计划以及状态的追踪：
对安全目标和功能/技术安全要求来说，可参考以下活动：
对技术安全要求来说，可参考以下活动：
分享不易，恳请点个【再看】
标签：
Copyright © 2015-2022 南非兽药网版权所有 备案号：沪ICP备2022005074号-13 联系邮箱：58 55 97 3@qq.com
