【功能安全】【ISO26262】概念阶段
本文本详细阐述了安全生命周期启动、危害分析与风险评估以及功能安全概念的相关内容。首先，在“安全生命周期启动”阶段（第2章），明确了相关项的定义并为其后续的安全评估工作奠定基础；其次，“危害分析和风险评估”（第3章）系统地识别潜在的危害事件，并通过严重度、暴露概率和可控性进行分类；最后，“功能安全概念”（第4章）从安全目标出发导出功能安全要求，并分配给初步架构要素或外部措施以确保系统的安全性。这些内容均参考了ISO26262标准的相关条款，并通过实例图解辅助理解。
目录
一、前言
二、安全生命周期启动
三、危害分析和风险评估
四、功能安全概念
一、前言
本章明确了相关项定义的具体要求与建议内容，在功能、接口、环境条件、法规要求以及危害等方面进行了详细说明。这些定义为后续各子阶段——"安全生命周期启动"（参见第6章）、"危害分析和风险评估"（参见第7章）以及"功能安全概念"（参见第8章）——提供了充分的相关项信息基础。
二、安全生命周期启动
1、目的
安全生命周期启动的第一个目的是明确新旧项目开发与修订间的区别。在现有项目修改的基础上定义将要推行的安全周期安排。活动内容包括具体要求与建议安排。
第二部分、具体要求与建议
- 确定开发类别
- 在现有相关项修改的情况下进行影响分析，并根据适用的安全生命周期阶段进行剪裁
- 识别并详细描述修改对功能安全的具体影响
- 确定并列出受到影响的工作成果及其更新需求
- 安全活动必须根据当前的生命周期阶段来规划
- 所有剪裁后的结果应包含在相应的安全计划中
- 对所有受到影响的工作成果进行重新评估与处理
三、危害分析和风险评估
1、目的
危害分析与风险评估的目标是发现系统或产品中因故障导致的危害并对其进行分类，并制定减少事件发生或降低危害程度的安全目标。
2、总则
在实现危害分析与风险评估的基础上来确定相关项的安全目标并避免不合理风险为此应当基于潜在的危害事件对相关项进行系统性评估。通过系统性地评估危害事件来确定安全目标及其对应的ASIL等级。ASIL等级则通过预估影响因子（包括严重度暴露概率及可控性）来确定这些影响因子依据的是相关项的功能行为因而无需深入掌握其设计细节。
3.1、危害分析和风险评估的启动
需参照相关术语表对潜在的危害进行系统性识别与评估。
第3.2节将采用情景模拟的方法对潜在的情况进行全面考察，并通过危险性辨识来确定潜在威胁。
情景模拟与危险性辨识
针对相关问题出现时可能导致潜在危害事件发生的情形进行描述分析，在涵盖正常操作场景的同时,还需考虑潜在异常操作情境。
-----应通过使用足够的技术手段系统地确定危害
-----基于能够被车载监控系统持续监测到的各种运行状态和操作行为来定义危害。
-----运行场景与相关因素共同作用决定了危害事件的发生。
-----需明确危害事件可能带来的负面影响和潜在后果。
3.3、危害事件分类
-----识别出的所有的危害事件进行分类
在每一个危害事件发生时,必须基于预先确定的一个标准来评估潜在伤害的严重性程度.
完成危害性评估后发现，在所有潜在的影响中仅存在物质层面的影响而无人员伤害风险时，则该类危害的风险程度应定评为S级。若某危害经评估确定其严重性等级达到S级，则无需进行ASIL级别划分。
对于每一个危害事件, 应基于确定的理由预估各个运行场景的暴露概率. 按照表 2 规定, 在暴露概率上指定相应的E0至E4等级.
-----当估计暴露概率时， 不应考虑装备该相关项的车辆数量。
该等级E0适用于危害分析和风险评估过程中识别那些发生可能性极低或者不可置信的情况，在这种情况下不需要采取任何措施即可认为该危害不会发生。对于这类情况必须记录原因以避免后续可能存在的误判和处理。当某项危害被确定其暴露概率等级归类于E0时，则不需要为其分配相应的ASIL等级
每个危害事件都需要依据明确的理由来评估受威胁人员对该事件的可控性。参照表 3为该事件的可控性分配一个C0、C1、C2或C3的等级。
3.4、ASIL 等级和安全目标的确定
每个危害事件的ASIL等级可依据"严重度"、"暴露概率"和"可控性"三个指标以及表4的数据来确定。
-----根据危害事件分析结果确定的ASIL等级应当分配至相应的安全对象。若需对若干相似的安全对象进行归并处理，则应在合并后的安全对象上采用最高ASIL等级
当一个安全目标可转移至或同时维持一至多个安全状态时，则需明确指明相关安全状态
------安全目标连同它们的属性（ASIL 等级）
3.5、验证
-----危害分析，风险评估和安全目标应按照 ISO26262 第 9 章进行验证
四、功能安全概念
1、目的
功能安全概念的主要目标是从安全目标出发推导出一系列功能安全要求，并将这些要求归入相关系统的初步架构要素或作为外部防护措施。
2、总则
功能安全概念涵盖以下内容：
——故障检测与状态缓解；
——状态恢复正常；
——容错机制，在这种机制下一个故障不会直接导致违背一个或多个安全目标，并且相关项始终保持在安全状态（无论功能降级与否）；
——故障检测与警告系统（例如：发动机故障指示灯、ABS故障警示灯等）；以及
——冲突处理逻辑（从多个功能同时产生的请求中选择最合适控制请求）。
图3详细呈现了GB/T XXXX标准相应部分中安全要求的结构布局及其分布情况，并明确了功能安全要求在初步架构要素中的具体分配方案
图2
图3
3、要求和建议
3.1、功能安全要求的导出
当且仅当特定条件下时
--- 当在可接受的时间段内无法进入安全状态时，则必须执行紧急操作。
--- 报警和降级概念被视为功能安全标准。
| 如果为了满足安全目标而对驾驶员或其他潜在涉险人员的必要行动做出了假设，那么应进行 | a)和 b)： |
|---|
注1：这些行动涉及在可控性预测阶段被视为可信度的关键活动，并且是在执行完安全要求后为了满足安全目标而采取的所有必要措施。
3.2、功能安全要求的分配
功能安全需求应当被归集成初步构想中的关键要素
3.3、确认准则
为了确保关键功能系统的安全运行，在制定和实施相关项的安全确认标准时，应当充分考虑功能安全的基本要求。
遵循ISO 26262标准中的第9章来实施功能安全方案。该方案需通过验证程序来证明其与所设定的安全目标保持一致并具有功能性，并且能够有效降低潜在风险事件的发生几率。