【功能安全】【ISO26262】支持过程
本摘要总结了功能安全开发的关键要素与流程：
分布式开发：明确了接口定义及责任分配；强调了启动计划和危害分析的风险验证；提出了供应商选择准则及活动责任方的要求。
安全要求管理：强调了定义层次化结构及一致性原则；提出了合规性验证方法。
配置与变更管理：规划了配置管理和变更控制流程。
验证：实施验证计划以确保成果符合要求。
文档管理：规定了文档制定与管理策略。
软件工具置信度：制定了置信度水平评估标准。
软件组件鉴定：依据相关标准评估组件功能与可靠性。
硬件组件鉴定：通过测试与分析确保功能表现与可靠性。
在用证明：提供了替代方法复用现有数据。
摘要覆盖了功能安全开发的关键环节及其标准化流程。
目录
一、分布式开发的接口
二、安全要求的定义和管理
三、配置管理
四、变更管理
五、验证
六、文档
七、使用软件工具的置信度
八、软件组件的鉴定
九、硬件组件的鉴定
十、在用证明
一、分布式开发的接口
1、目的
在本章中旨在阐述或说明涉及的关键项与要素在分布式开发过程中的操作路径以及相应的责任划分与分配方案。
2、总则
涉及相关项开发的企业（例如：车辆制造者）与供应商共同遵循相关定义的要求；双方对责任达成了一致意见；子项目之间的关系是可以接受的；类似地，在与分布式相关项开发供应商或负责所有安全责任的相关项开发供应商合作时，企业对于安全相关的计划、执行和文档也需要获得同意。
3、前提条件
参考规划下实施了分布式开发的安全生命周期涉及的部分的适用条件
4、要求和建议
4.1、要求的应用
这些要求需要被应用于客户-供应商关系的各种层次上，并特别关注其接口和交互功能。
客户应向候选供应商编制其采购需求文件（RFQ），该文件应包含以下内容：
a) 满足规范性要求；
b) 明确关键参数及其功能需求描述；
c) 指定基于报价对象的安全目标、功能安全标准和技术安全标准（如有相关标准存在，则需明确对应ASIL等级）。
分布式开发的启动与规划阶段：首先需由客户及供应商共同制定开发接口协议；若供应商开展危害性分析与风险评估工作，则该类分析与评估结果须提交至客户处进行验证；最后双方需就功能性安全要求达成共识。
4.2、供应商选择准则
供应商选择标准包括以下几个方面：首先基于质量管理体系的验证结果；其次考虑供应商的历史性能表现及产品质量状况；再次对其功能性安全能力（作为投标的重要考量）进行评估；最后依据安全评估得出的结果进行判断；此外还应综合考虑整车厂开发、生产、质量及物流部门的意见（因为它们在涉及功能性安全方面具有重要影响）。
4.3、分布式开发的启动和计划
- 客户和供应商应定义开发接口协议
- a) 客户和供应商安全经理的任命，
- b) 进行安全生命周期的联合剪裁，
- c) 客户需开展的活动及流程和供应商需开展的活动及流程，
- d) 需交换的信息和工作成果，
- e) 活动的责任方或责任人，
- f) 目标值的沟通。这些目标值由系统层面的目标导出，再分配给相关方，目的是使这些相关方能满足单点故障度量及潜伏故障度量的目标值（通过硬件架构度量的评估和因随机硬件失效导致违背安全目标的评估，及
- g) 支持过程和工具，含接口，以确保客户和供应商间的兼容性。
4.4、分布式开发的执行
供应商应对客户汇报在项目范围内（包括但不限于项目范围、安全管理规划、集成测试框架以及软件验证标准等）可能引入违反既定规范的风险因素。
供应商需对分包商责任领域内发生的任何异常事件进行记录并及时汇报。
为确保安全要求的有效性，请供应商全面核查各项安全标准后方可确认是否符合规定；如发现不符合，则需重新审视安全策略并必要时进行修订以制定相应的安全规范。
对于可能影响系统关键功能的安全变更以及可能导致系统验证结果变更为不确定的关键操作变更，请务必与相关方进行沟通协作。
在制定当前开发周期的安全目标时，请贵方参考历史经验数据作为辅助依据以提高工作质量。
为确保信息同步效率，请供应商定期更新至最新进度数据并与相关部门协商一致的提交时间安排方案。
4.5、在供应商场所的功能安全评估
4.6、生产发布后
供应商必须向客户提交证据以证明其满足第7章和第5章所设定的过程能力要求。
客户与供应商之间的供应合同应当基于明确的功能安全责任，并规定双方的安全活动。
合同应当明确规定参与方对涉及安全的相关特性进行生产监控记录访问与交换的具体事项。
一旦发生安全相关事件的所有相关人员必须按照合同及时报告该事件。发生安全相关事件后应当立即启动分析程序。此类分析需要涵盖类似相关因素以及可能受该类事件潜在影响的相关方。
5、工作成果
供应商选拔方案，
接口开发协议，
供应商项目规划，
供应商安全管理方案，
功能安全评估报告，
供货协议书。
供应商选拔方案，
接口开发协议，
供应商项目规划，
供应链安全管理方案，
功能安全评估报告，
供货协议书。
二、安全要求的定义和管理
1、目的
第一目标在于规范性地阐述其属性与特性以保证正确性。
第二目标则致力于强化在整个安全管理过程中对安全要求的一致性管理。
2、安全要求
参见规范或依据相关阶段的安全生命周期管理要求作为适用前提条件。
4、要求和建议
4 .1定义安全要求
4.2、安全要求的管理
安全要求集应当具备以下重要特征：
a) 层次结构
注：如图所示，层次结构指的是由若干个连续层级构建而成的安全要求体系；这些层级与相应的设计阶段始终保持一致性和协调性。
b) 基于合理编组原则建立起来的一种有序架构，
注：该体系通常按照系统的架构将各个层级的安全要求有机地结合在一起。
c) 完整性，
注：这意味着一个层级上的全部安全要求均得到了充分实施和满足。
d) 外部一致性，
注：这不同于内部一致性（即每个单独的安全要求不包含自相矛盾的内容），外部一致性强调的是各个安全要求之间不产生冲突或矛盾。
e) 在分层结构中同一层级的信息不出现在其他层级，
注：这确保了信息的独特性和唯一性。
f) 具备可维护性。
三、配置管理
1、目的
第一个目的是保证工作成果及其形成的相关原理与普遍条件，在任何时候通过可追踪的手段得以唯一识别并重新生成。 第二个目的是旨在实现对较早版本与当前版本之间关系及差异的可追溯性。
2、前提条件
应具备如下信息：
— 安全计划。
— 在配置管理计划和管理的安全生命周期的相关阶段中适用的前提条件。
3、要求和建议
应计划配置管理。
配置管理过程
四、变更管理
变更管理的目标是在整体安全管理体系运行的过程中，识别、评估并加以管理所有与变更相关的安全工作成果。
2、前提条件
应具备如下信息：
— 配置管理计划
— 安全计划
3、要求和建议
- 制定并启动变更管理计划
- 处理变更需求
- 对变更进行需求分析
- 在开展过程中进行详细记录
4、工作成果
- 变更管理计划
- 变更需求
- 影响分析和变更需求计划
- 变更报告
五、验证
1、目的
验证的目的是确保工作成果符合它们相应的要求。
2、要求和建议
2.1、验证计划
*a) 需确认的工作成果内容，
*b) 所采用的技术手段，
*注：所采用的技术手段包括评审、巡检、检查、模型检验、模拟、工程分析、证明及测试等方法，并通常结合其他方法以达到验证目的。
*c) 明确的通过与不通过标准，
*d) 适用场景，
*e) 所使用的工具（如有），
*f) 在发生异常时应采取的具体措施以及实施修复策略，
*g) 回归策略。
六、文档
其核心目标是制定或构建贯穿从生成到销毁全生命周期的安全文档管理体系, 以确保实现高效可靠的文档管理, 并便于追踪其全过程.
2、要求和建议
2.1、为了确保文档制定与管理工作的系统性规划与执行效果，请遵循以下步骤：
a) 在整个生命周期各阶段实施有效流程以完成各阶段任务及验证环节；
b) 在功能安全领域提供全面管理框架；
c) 作为功能安全评估的技术基础输入依据。
2.2、文档宜是：
a) 精确且简洁,
b) 条理分明,
c) 目的不同读者易于理解,及
d) 易于维护.
2.3、每一个工作成果或文档都须与其下面的正式要素相关联：
a) 第一项要素是题目及其适用范围；
b) 第二项要素是审核责任人及审批人；
c) 第三项要素是文档的唯一标识符；
d) 第四项要素是变更历史记录。
e) 状态。
七、使用软件工具的置信度
本章的主要目标之一是在适用时制定软件工具置信度水平的要求标准。 另一重要目标是，在适用时提供鉴定程序以建立确凿证据证明软件工具适合用于裁剪活动或任务。
2、要求和建议
- 预先确定的工具置信度水平在有效性方面的体现及其在鉴定过程中的有效应用
- 软件工具与其所依据的评估准则与鉴定标准的高度一致
- 规划其在实际中的应用方案
- 保证在选择和应用过程中采用合适的策略以确保恰当的评估和使用
- 通过系统分析来实现对其性能和适用性的全面评价
八、软件组件的鉴定
a) 软件组件的定义，按照12.4.3.1，
b) 表明软件组件符合按照12.4.3.2，12.4.3.3，以及12.4.3.4相关要求的证据，
c) 软件组件适合其用途的证据，按照12.4.4，及
d) 组件的软件开发过程是基于适当的国家或国际标准的证据。
九、硬件组件的鉴定
a) 为了满足安全标准的需求, 组件或元器件必须具备足够的功能特性.
b) 通过适当的方法进行验证与分析（包括极限条件测试、加速寿命试验等），可以识别失效模式及其对应的模型参数.
c) 具备足够强健的功能特性.
d) 判定组件或元器件的功能边界.
十、在用证明
本章阐述了现有证明方案的指导原则。基于现有数据的情况，在不影响项目质量的前提下，对于已有的相关项目或构成要素进行复用时可灵活运用现有证明方案，并将其作为替代方案提供。