ISO26262-3,概念阶段对产品研发的考虑(三)
做完危险分析和风险评估之后,在概念阶段,ISO26262-3还给出了功能安全概念这个阶段。其主要目的是通过前面的危险分析和风险评估之后得出的安全目标来确定具体的功能安全要求,并将它们分配到初步的设计架构,或者外部减少危险的措施当中去,以确保满足相关的功能安全要求。
为了符合功能安全目标,功能安全概念给出了一些基本的安全机制和安全措施,以便于功能安全要求被很好的分配到系统架构的元素中去。这些主要的机制和措施如下:
- 故障检测和失效减小
- 过渡到安全状态
- 故障容错机制。即:故障不会直接导致违背安全目标,或者保持系统出于安全状态(降级或者没有降级)
- 故障检测和为了将暴露时间减小到可接受的程度的司机警示装置
- 不同功能触发的多任务请求应该通过逻辑仲裁来选择最合适的控制
基于以上这些机制和措施,再根据之前的项目定义、危险分析和风险评估、安全目标的设定,以及考虑来自外部的一些预想架构、功能、操作模式及系统状态等,就可以开始考虑将功能安全要求进行适当的分配,指定ASIL等级,并将其合理的分配到子系统当中了。即:
在功能安全概念中,ISO26262从功能安全要求的来源和功能安全的分配两个方面给出了一些建议和要求,具体如下:
1. 功能安全要求的来源:
a) 功能安全要求应该从安全目标和安全状态来获得,并考虑预想架构、功能概念、操作模式和系统状态等。
b) 要为每个安全目标设定至少一个功能安全要求。
c) 每个功能安全要求都要考虑以下内容:
i. 操作模式
ii. 故障容错时间间隔
iii. 安全状态,过渡到安全状态是否符合设备要求
iv. 急停操作间隔
v. 功能冗余
d) 警示和降级
e) 如果安全状态不能通过立即关闭来达到,则需指定一个紧急操作。
i. 这些动作应该在功能安全概念中详细描述
ii. 驾驶员或者陷入危险中的人可以使用的手段或者控制要在功能安全概念中详细描述
2. 功能安全要求的分配:
a) 研发安全架构概念
b) 功能安全要求分配
i. 功能安全要求的分配应该基于项目预想架构的元素进行。
ii. 分配过程中,ASIL和8.4.2.3给出的信息都要继续传承。
iii. 如果多个功能安全要求被分配到同一个架构元素,则这个架构元素应以这些功能安全要求的最高ASIL等级进行研发。
iv. 如果项目由超过一个的系统组成,则对于每个独立系统和他们的接口的功能安全要求都要从考虑预想系统架构的功能安全要求中获得,而这些功能安全要求也都要被分配到系统中去。
v. 如果ASIL等级需要被拆解,则要符合ISO26262-9第五章的要求。
vi. 如果安全要求被分配到其他技术的元素中,则无需考虑ASIL等级。
c) 如果功能安全概念依赖于其他技术的元素,则应考虑以下环节:
i. 靠其他技术执行的功能安全要求应该从其相应的元素中获得并分配到元素中去。
ii. 明确与其他技术的接口的相关功能安全要求。
iii. 有其他技术执行的功能安全要求要确保有具体的措施。
d) 依赖于外部风险降低措施的功能安全感念应满足如下要求:
i. 应用于外面风险降低措施的功能安全要求应该从相应的外部风险降低措施中获得并分配到其中去。
ii. 明确与外部风险降低措施的接口的功能安全要求
iii. 如果外部风险降低措施由E/E系统构成,则功能安全要求可以用ISO26262来进行评估。
iv. 必须确保由外部风险降低措施执行的功能安全要求的正确执行。
e) 功能安全概念应该按照ISO26262-8第九章的要求来验证与安全目标的一致性和符合性。
f) 项目安全确认的原则应该详细的写在功能安全概念中。
g) 功能安全要求的审核应该阐明功能安全要求符合安全目标。
由此,按照流程完成以上的这些分析和审核之后,即完成了功能安全概念的阶段,最终会形成功能安全概念的结果,和通过审核的功能安全要求。
此文章来自于方森安略