功能安全：不存在由于E/E系统的正常功能所带来的不合理风险（即人身伤害）；
FTTI: 故障容忍时间间隔，即从故障发生到潜在危害事件可能发生之间的时间间隔；
一个相关项可仅包括一个传感器，无需包括控制器及执行器；
如果组织无法提供质量管理体系符合特定要求的证据，则无法判定其相关项的开发符合功能安全的要求；
功能安全系列标准中制定了认可措施，包括认可评审，功能安全审核，功能安全评估
功能安全管理中，仅要求记录安全异常，不需要对记录的安全异常进行管理直至关闭；
功能安全要求项目经理承担相关项的影响分析、安全计划的制定、安全活动的监控和调整以及认可措施的规划工作；
SEooC是指在进行功能安全开发时，相关项还不存在的安全要素，其开发活动均基于对安全需求的假设进行；
安全档案用于提供相关项达成安全目标的证据，包括待满足的需求，证明满足需求的论点，以及支撑论点的证据，从流程、开发成果和支持流程等方面进行全方面的论证。
某个需求被标记为ASIL B(D)的标记中，意味着该需求的开发和验证活动均需按照ASIL B进行
危害分析及风险评估（HARA）过程中，需要根据相关项的功能异常、运行条件识别可能发生的危害，并对运行条件的暴露度、危害事件的严重度以及该危害情况下各个交通参与者对危害后果的可控度进行评估，判断该危害对应的ASIL等级；
在进行HARA过程中，可以对运行条件进行细分，这样可以避免获得更高的ASIL等级，降低开发成本；
在进行HARA过程中，可以考虑相关项的内部安全机制，以避免获得较高的ASIL等级，降低开发成本；
在进行HARA时，需要对每个非QM的危害定义安全目标。当多个安全目标相似时，可以对安全目标进行合并，并以赋予多个危害中最低的ASIL等级作为该安全目标的等级；
在概念阶段，需要基于安全目标、安全状态以及初始架构等信息来获得一系列的功能安全需求，这些功能安全需求需要继承对应的安全目标的ASIL等级；
系统阶段开发期间，需要制定技术安全需求，并为可能引起安全需求背离的系统失效制定安全机制，包括探测、指示、控制自身故障、外部设备故障的安全机制，达成或维持安全状态的措施，报警及降级的措施，以及避免故障成为潜在失效的措施；
软硬件接口是连接功能安全系统阶段开发、硬件阶段开发和软件阶段开发的纽带，其成果软硬件接口规范的验证评审只需要系统阶段负责人进行审核即可。
在功能安全硬件阶段开发中，需要基于分配给硬件的技术安全需求，以及来自于软件对硬件的需求制定硬件安全需求；
硬件失效率为1FIT指在108运行小时中，出现1个故障；
软件组件存在150个FIT的随机失效率；
随机失效可以通过如质量管理体系，详细的安全管理体系，安全评审等多种方式方法进行预防和避免；
随机失效中的故障分为安全的故障、单点/残余故障，能够探测的多点故障，能够感知到的多点故障和潜伏故障；
SPFM，单点故障指标是指单点故障在所有故障中所占的比例；
LPF，潜伏故障指标是指潜伏故障在所有的非单点/残余故障中所占的比例；
SPFM，LPF，PMHF等故障指标的目的是用来评估硬件架构设计是否能够支持相关项对应的ASIL等级的安全目标的实现；
诊断覆盖（DC）是指由安全机制所覆盖的硬件要素失效的比例；
存在三类硬件要素，分别为基础电子电气元器件，不带内部安全机制的复杂器件以及带内部安全机制的复杂器件。其中第三类硬件要素不需要进行硬件要素评估就可直接用于功能安全相关项中。
硬件集成验证需要考虑其那就行、鲁棒性及压力运行条件下的性能，以判断能否有效支持功能安全的达成；
软件阶段的功能安全设计中，在进行架构设计时，需要对软件架构进行静态方面的描述以及动态方面的描述；
根据下表，在系统阶段测试中，针对ASIL C的测试用例设计，请列举考虑的测试用例设计方法编号：
为了保证软件开发的可靠性，需要对支持软件开发的软件工具进行评估，以保证使用的软件工具不会引起功能安全的背离；
安全确认中，需要从_______________________________________(a. 可控性、b. 外部措施有效性、c. 内部措施有效性、d. 其他措施有效性、e.进行HARA过程中进行的假设)等方面进行评估对功能安全的达成的有效性。
请简要陈述您的工作岗位与功能安全之间的潜在关系。