在当今快速发展的汽车行业中，汽车功能安全成为了一个越来越重要的话题。随着车辆变得越来越智能化和自动化，我们对车辆安全性的要求也越来越高。在这个背景下，ISO26262应运而生，成为了一项全面的汽车功能安全标准。⊙Part 1：定义
⊙Part 2：功能安全管理
⊙Part 3：概念阶段
⊙Part 4：产品研发：系统级
⊙Part 5：产品研发：硬件级
⊙Part 6：产品研发：软件级
⊙Part 7：生产和操作
⊙Part 8：支持过程
⊙Part 9：基于ASIL 和安全的分析
⊙Part 10：ISO26262 导则
从ISO 26262的结构构成可以看到，标准涵盖了全生命周期的安全要求，功能安全管理、概念阶段、系统研发、硬件研发、软件研发、生产和操作过程、售后，但比例最大的是站在产品设计阶段这个时间节点上，考虑怎样从设计上实现产品安全，可以基于原有的功能实现安全，也可以额外添加功能，实现安全。今天我们主要讲Part 3 ：概念阶段，下面我们一起来看一看：概念阶段为建立相关项的定义列出了要求和建议，相关项的定义包括其功能、接口、环境条件、法规要求和危害等。为执行后续子阶段：“安全生命周期启动”、“危害分析和风险评估”和“功能安全概念”的人员提供了充足的关于相关项的信息。其中，危害分析、风险评估和 ASIL 等级的确定用于确定相关项的安全目标以避免不合理的风险。为此，根据相关项中潜在的危害事件,对相关项进行评估。通过对危害事件进行系统性的评估确定安全目标及分配给它们的 ASIL 等级。同时，还给出了危害分析和风险评估的要求：识别相关项找那个因故障而引起的危害并对危害进行归类，制定防止危害事件发生或减轻危害程度的安全目标，以避免不合理的风险。
在概念阶段，相关项定义需对进行研发的产品进行功能定义与描述，此步骤的主要目的是使工程师们对所研究项目有足够的理解，以方便完成产品安全生命周期内定义的每一个活动。因此，为了对研发的产品有一个明确、准确、正确的定义与描述，产品的一些基本信息可以被包括在相关项定义中：
7. 在零部件到整车概念安全的角度，产品已知的失效模式和风险；*以上基本信息可以根据不同产品的功能自行斟酌添加。
此步骤与接下来的危害分析与风险评估强相关，通过对产品的系统功能逐个进行详细分析，来识别出系统的每一个危害事件，并根据危险的程度按照一定的原则对其进行分类，从而针对不同的风险设定具体的安全目标来最终减小或消除风险，避免未知风险的发生。
对于产品的危害事件识别，需要注意以下几个方面：
1. 产品的危害识别可通过该产品的检查列表、历史记录、工程师头脑风暴与相关领域的研究等方法来实施；2. 危害事件的评估需制定一份完整的清单如潜在功能失效模式评估表来详细记录产品功能潜在的失效模式与产品相关机构的具体表现；3. 在相关操作条件和操作模式下的危险事件的影响应该被明确说明；在完成潜在危害事件的风险识别后，就进入对危险事件的分析与评估阶段。
HARA分析的全名为Hazard Analysis and Risk Assessment, 该步骤用于识别产品的每一个功能的非意愿性动作和功能丧失场景，并结合这些故障的严重度 (Severity)、暴露度 (Exposure) 及可控性 (Controllability)，来进行系统功能安全的ASIL评价，并制定防治危害时间发生或减轻危害程度的安全目标。对于产品系统的HARA分析，可分为以下步骤：
SEC分析旨在对每一个危害事件使用严重度(S) 、暴露概率 (E)、可控性 (C) 3个参数进行评估。其中：
严重度: 指系统在功能失效的情况下，对驾驶人员、环境和行人的伤害程度；
暴露概率: 指风险在实际环境中发生的概率；
可控性: 指发生事故的情况下，驾驶员或其他涉险人员能够避免事故或伤害的可能性。
当“严重度”、“暴露概率”、“可控性” 评估出来后，按综合评估其ASIL等级(即汽车安全完整性等级)。其中：
“D”为最高等级，“A”为最低等级,“QM”为质量管理，表示依据正常的质量管理体系进行开发即可，无需涉及功能安全相关的设计。
功能安全等级评定
各系统一般安全等级
同一个功能失效在不同场景下，其危害可能不同，因此需对车辆运行的场景进行分析和选择。车辆运行的场景是对车辆条件(运动、静止、加速、减速、前进后退等)、环境条件(天气因素和道路条件)和驾驶条件(平地、坡道、 弯路等)三者之间进行选择。
在明确每一个危害事件的ASIL等级与运行场景后，再为其制定一个安全目标，作为下一阶段的功能安全需求(FSR)和技术安全需求(TSR)的基础。完成运行场景分析之后，故障和运行场景就组成了危害事件。通过组合分析评估危害事件的“严重度”、“暴露概率”、“可控性” 和ASIL安全等级，可得出产品的安全目标。
评估出系统的ASIL等级越高，ISO26262对设计方法、 安全技术、测试方法及需要达到的技术指标的要求越严格, 对产品及其开发流程的审核和确认也会更严格。
做完危险分析和风险评估之后，在概念阶段，ISO26262-3 还给出了功能安全概念这个阶段。其主要目的是通过前面的危险分析和风险评估之后得出的安全目标来确定具体的功能安全要求，并将它们分配到初步的设计架构，或者外部减少危险的措施当中去，以确保满足相关的功能安全要求。为了符合功能安全目标，功能安全概念给出了一些基本的安全机制和安全措施，以便于功能安全要求被很好的分配到系统架构的元素中去。这些主要的机制和措施如下：- 故障容错机制。即：故障不会直接导致违背安全目标，或者保持系统处于安全状态（降级或者没有降级）；- 故障检测和为了将暴露时间减小到可接受的程度的司机警示装置；- 逻辑仲裁：不同功能触发的多任务请求应该通过逻辑仲裁来选择最合适的控制；基于以上这些机制和措施，再根据之前的项目定义、危险分析和风险评估、安全目标的设定，以及考虑来自外部的一些预想架构、功能、操作模式及系统状态等，就可以开始考虑将功能安全要求进行适当的分配，指定ASIL 等级，并将其合理的分配到子系统当中了。安全目标和功能安全要求的层次结构如下表所示：
在功能安全概念中，ISO26262 从功能安全要求的来源和功能安全的分配两个方面给出了一些建议和要求，具体如下：
(a) 功能安全要求应该从安全目标和安全状态来获得，并考虑预想架构、功能概念、操作模式和系统状态等。(b) 要为每个安全目标设定至少一个功能安全要求。 iii. 安全状态，过渡到安全状态是否符合设备要求； 这项活动可以通过安全分析（如FMEA，FTA，HAZOP），以制定一套完整有效的功能性安全要求的支持。(e) 如果安全状态不能通过立即关闭来达到，则需指定一个紧急操作。 ii. 驾驶员或者陷入危险中的人可以使用的手段或者控制要在功能安全概念中详细描述； i. 功能安全要求的分配应该基于项目预想架构的元素进行。 ii. 分配过程中，ASIL 和功能安全要求考虑的内容信息都要继续传承。 iii. 如果多个功能安全要求被分配到同一个架构元素，则这个架构元素应以这些功能安全要求的最高ASIL 等级进行研发。 iv. 如果项目由超过一个的系统组成，则对于每个独立系统和他们的接口的功能安 全要求都要从考虑预想系统架构的功能安全要求中获得，而这些功能安全要求也都要被分配到系统中去。 v. 如果ASIL 等级需要被拆解，则要符合ISO26262-9 第五条款的要求 vi. 如果安全要求被分配到其他技术的元素中，则无需考虑ASIL 等级。(c) 如果功能安全概念依赖于其他技术的元素，则应考虑以下环节： i. 靠其他技术执行的功能安全要求应该从其相应的元素中获得并分配到元素中去。 iii. 有其他技术执行的功能安全要求要确保有具体的措施。(d)依赖于外部风险降低措施的功能安全概念应满足如下要求： i. 应用于外面风险降低措施的功能安全要求应该从相应的外部风险降低措施中获 得并分配到其中去。 ii. 明确与外部风险降低措施的接口的功能安全要求； iii. 如果外部风险降低措施由E/E 系统构成，则功能安全要求可以用ISO26262来进 行评估。 iv. 必须确保由外部风险降低措施执行的功能安全要求的正确执行。(e)功能安全概念应该按照ISO26262-8 第九条款的要求来验证与安全目标的一致性和符合性。(f) 项目安全确认的原则应该详细地写在功能安全概念中。(g)功能安全要求的审核应该阐明功能安全要求符合安全目标。由此，按照流程完成以上的这些分析和审核之后，即完成了功能安全概念的阶段，最终会形成功能安全概念的结果，和通过审核的功能安全要求。
总之，概念阶段是ISO26262标准中非常重要的一个阶段，它为整个标准奠定了基础，确定了汽车电子电气系统的功能和性能要求，以及需要采取的措施和测试计划。通过概念阶段的努力，设计师可以更好地理解客户需求，确保汽车电子电气系统的安全性和可靠性。
如无特别说明，本站部分所载内容来源于互联网、微信公众号等公开渠道，不代表本站观点，仅供参考、交流之目的。转载的稿件版权归原作者或机构所有。如有侵权，请联系质链网。
