ISO26262-Part5 思维导图模板_ProcessOn思维导图、流程图

6. 4. 3. 3 系统架构设计应实现技术安全要求。

a ) 验证系统架构设计的能力;

b ) 与实现功能安全相关的预期软硬件要素的技术能力;

c ) 在系统集成过程中执行测试的能力。

6. 4. 3 系统架构设计规范和技术安全概念

a ) 值得信赖的技术安全概念的复用;

c ) 值得信赖的探测和控制失效的机制的复用;

d ) 值得信赖的或标准化接口的复用

a ) 模块化;

b ) 适当的颗粒度水平;

c ) 简单。

6. 4. 4 安全分析及避免系统性失效

a ) GB / T34590. 5 — 2022 第 8 章中度量的目标值;

b ) GB / T34590. 5 — 2022 第 9 章中的流程。

6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 6. 3 每个系统架构设计要素都应继承其实现的技术安全要求的最高的 ASIL 等级。

6. 4. 6 分配到硬件和软件

外框

6. 4. 1 相关项硬件要素的硬件安全需求规范应从分配给硬件的技术安全要求中导出(源自 GB / T34590. 4 —2022 中 6. 5. 2 )。

c ) 为符合其他要素的安全要求的硬件安全要求和安全机制的相关特性;示例 3 :对传感器或执行器的诊断。

6. 4. 2 硬件安全需求规范应包括与功能安全有关的每一条硬件要求

a ) GB / T34590. 5 — 2022 第 8 章中度量的目标值;

b ) GB / T34590. 5 — 2022 第 9 章中的流程。

GB / T34590.4 — 2022 中6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 5 硬件安全要求应按照 GB / T34590. 8 — 2022 第 6 章的要求进行定义。

a ) 硬件要素的唯一识别及版本;

b ) 硬件要素预期使用环境的定义;

c ) 评估策略和依据;注:策略包括分析、必要的测试和逐步的描述。

d ) 该策略所必需的工具和设备;

e ) 实施该评估的责任方;

f ) 用于评估硬件要素通过和不通过的准则。

a ) 硬件要素的功能描述;

b ) 所分配的安全要求;

c ) 需要进行的测试规范和顺序;

d ) 测试与安全要求之间的追溯性;

e ) 组装和连接的要求;

f ) 需要模拟的运行条件和环境条件;

g ) 被测要素的数量;

h ) 测试通过/不通过的准则;

i ) 需要测量的环境参数;

13. 4. 1. 1 被评估硬件要素的分类硬件要素应被分为以下类别之一:

13. 4. 3. 6. 2 应按照第 9 章对评估报告进行验证。

13. 4. 3. 6 评估报告

GB / T34590. 8 — 2022 第 13 章

a ) 与系统自身故障的探测、指示和控制相关的安全机制;注 1 :包括用于探测随机硬件故障及探测系统性故障(如果适用)的系统自身监控。注 2 :包括对通信通道失效(例如:数据接口、通信总线、无线射频链接)的探测和控制的安全机制。注 3 :可以在系统架构适当的层级定义安全机制。

b ) 涉及探测、指示和控制与本系统有相互影响的其他外部要素中所发生故障的安全机制;示例:外部设备包括其他的电控单元、电源或者通信设备。

c ) 使系统实现或者维持在相关项的安全状态的安全机制;注 4 :包括来自安全机制的多个控制请求的仲裁。

d ) 定义和执行报警和降级策略的安全机制;

a ) 状态间的转换;注 1 :包括控制执行器的要求。

d ) 多点故障探测时间间隔。注 1 :诊断测试策略可以是时间驱动(例如使用诊断测试时间间隔)或者事件驱动(例如启动测试)。注 2 :二阶多点失效包含以多点故障检测时间间隔分隔的两个故障。注 3 :下列措施的使用取决于时间约束:———系统或要素在运行过程中的周期性测试;———要素在上下电时的自检;———系统或要素在维护时的测试。

a ) ASILB 等级(对于分配为 ASILD 等级的技术安全要求)

b ) ASILA 等级(对于分配为 ASILB 等级和 ASILC 等级的技术安全要求);

6. 4. 2. 5 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。仅为了防止双点故障处于潜伏状态而实施的安全机制的开发应至少符合:

GB / T34590. 4 — 2022 中 6. 4. 2 安全机制

a ) 与系统自身故障的探测、指示和控制相关的安全机制;注 1 :包括用于探测随机硬件故障及探测系统性故障(如果适用)的系统自身监控。注 2 :包括对通信通道失效(例如:数据接口、通信总线、无线射频链接)的探测和控制的安全机制。注 3 :可以在系统架构适当的层级定义安全机制。

b ) 涉及探测、指示和控制与本系统有相互影响的其他外部要素中所发生故障的安全机制;示例:外部设备包括其他的电控单元、电源或者通信设备。

c ) 使系统实现或者维持在相关项的安全状态的安全机制;注 4 :包括来自安全机制的多个控制请求的仲裁。

d ) 定义和执行报警和降级策略的安全机制;

a ) 状态间的转换;注 1 :包括控制执行器的要求。

d ) 多点故障探测时间间隔。注 1 :诊断测试策略可以是时间驱动(例如使用诊断测试时间间隔)或者事件驱动(例如启动测试)。注 2 :二阶多点失效包含以多点故障检测时间间隔分隔的两个故障。注 3 :下列措施的使用取决于时间约束:———系统或要素在运行过程中的周期性测试;———要素在上下电时的自检;———系统或要素在维护时的测试。

a ) ASILB 等级(对于分配为 ASILD 等级的技术安全要求)

b ) ASILA 等级(对于分配为 ASILB 等级和 ASILC 等级的技术安全要求);

6. 4. 2. 5 本要求适用于 ASIL ( A )、( B )、 C 和 D 等级。仅为了防止双点故障处于潜伏状态而实施的安全机制的开发应至少符合:

GB / T34590. 4 — 2022 中 6. 4. 2 安全机制

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

h ) 当探测出异常时需采取的行动;

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;注:这包括维修历史及在用证明达到的程度。

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

g ) 确定测试用例通过和不通过的准则。

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

d ) 验证结果与期望结果的一致性水平;

f ) 每个验证步骤未执行的理由。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

GB / T34590. 8 — 2022 第 9 章

a ) 与技术安全概念、系统设计规范以及硬件规范的一致性;

b ) 关于技术安全要求分配给硬件要素的完整性

c ) 与相关软件安全要求的一致性;

d ) 正确性与准确性

6 硬件安全要求的定义工作成果6 Specification of hardware safety requirements

7. 4. 1. 1 硬件架构应实现第 6 章定义的硬件安全要求。

a ) 模块化;注 1 :模块化使得硬件要素的设计无需修改就可以重复使用(如温度探测电路模块、微控制器中的 ECC模块)。

c ) 简单性。

7. 4. 1 硬件架构设计

7. 4. 2. 4 宜考虑鲁棒性设计原则。注:鲁棒性设计原则可以通过硬件设计指南的应用来体现。示例:关于组件应对环境和运行应力因素鲁棒性的保守规范。

7. 4. 2 硬件详细设计

a ) 安全故障;

b ) 单点故障或残余故障;

c ) 多点故障(无论是可感知的、可探测的或潜伏的)。

a ) 应具备证据以证明安全机制具有实现和保持安全状态的能力(特别是在容错时间间隔和最大故障处理时间间隔内适当的失效减轻能力);

b ) 应评估由安全机制实现的残余故障的诊断覆盖率。

7. 4. 3. 3 本要求适用于等级为 ASIL ( A )、( B )、 C 和 D 的安全目标。应具备实施的安全机制对防止导致单点失效的故障或减少残余故障的有效性的证据。为了这个目的:

b ) 应评估由安全机制实现的潜伏故障的诊断覆盖率。

A. 1. 1 用例描述

A1. 2 安全机制的描述

A. 1 DMA 安全机制评估示例

GB/ T34590.11 — 2022 附录 A 中的示例

7. 4. 3. 4 本要求适用于等级为 ASIL ( A )、( B )、 C 和 D 的安全目标。应具备实施的安全机制对防止潜伏故障的有效性的证据。为了这个目的:

GB / T34590.9 — 2022 附录 C

GB / T34590.11 — 2022 中 4. 7

7. 4. 3 安全分析

a ) 满足硬件安全要求;

b ) 与软硬件接口规范兼容;

c ) 用来在生产和服务过程中实现功能安全的安全相关特殊特性的适用性。

a ) 需验证的工作成果内容;

b ) 验证的目的;

c ) 用于验证的方法;

d ) 验证通过和不通过的准则;

h ) 当探测出异常时需采取的行动;

a ) 所使用验证方法的充分性;

b ) 需验证的工作成果的复杂性;

c ) 与验证目标材料相关的前期经验;注:这包括维修历史及在用证明达到的程度。

9. 4. 1. 2 制定验证计划宜考虑以下方面:

a ) 评审或分析的检查清单;或

b ) 模拟场景;或

c ) 测试用例、测试数据和测试目标。

a ) 唯一的识别

b ) 需验证的相关工作成果的版本的参考;

g ) 确定测试用例通过和不通过的准则。

a ) 所需的测试设备或测试环境;

b ) 逻辑和时间的依赖性;

c ) 资源。示例:将测试用例分成回归测试用例和完整测试用例。

9. 4. 3. 2 验证宜由与待验证的工作成果的完成人不同的人执行。

a ) 所验证工作成果的唯一识别;

b ) 验证计划和验证规范的参考;

d ) 验证结果与期望结果的一致性水平;

f ) 每个验证步骤未执行的理由。

9. 4. 3. 3 对验证结果的评估应包含以下信息:

GB / T34590. 8 — 2022 第 9 章

8. 4. 1. 3 应为已识别出的工作成果、相关项和要素定义实施变更管理流程的日程表

注 1 :变更管理流程可适用于开发过程中的相应阶段。注 2 :可在一个变更需求中处理多个变更。

8. 4. 1. 4 变更管理流程应包括:

8. 4. 1 计划和启动变更管理

8. 4. 2. 1 应为每个变更需求分配唯一的识别码。

a ) 日期;

b ) 所需变更的理由;

c ) 所需变更的准确描述;

d ) 所需变更基于的配置。

8. 4. 2. 2 每个变更需求应至少包含以下信息:

8. 4. 2 变更需求

a ) 变更需求的类型;示例:可能的变更类型有解决错误、调整、消除、加强、预防。

b ) 对需更改的工作成果、相关项和要素及受影响的工作成果、相关项和要素进行的识别;

d ) 变更对功能安全的潜在影响;

e ) 变更的实现和验证的日程表。

8. 4. 3 变更需求分析

8. 4. 4 变更需求评估

8. 4. 5. 1 应按计划实施变更和验证变更。

6. 4. 9. 3 实施认可措施的人员应有权限获取相关信息和工具。

GB / T34590. 2 — 2022 中6. 4. 9 认可措施

6. 4. 10. 2 认可评审应在生产发布前完成。

GB / T34590. 2 — 2022 中6. 4. 10 认可评审

b ) 开展的变更细节;

c ) 变更部署的计划日期。

8. 4. 5. 3 变更的记录应包含以下信息:

8. 4. 5 变更的实施和记录

GB / T34590.8 — 2022 第 8 章

7. 4. 4. 3 应根据硬件安全要求和硬件设计规范验证用于开发集成到硬件中的 SEooC (独立于环境的安全要素)的假设的有效性。

7. 4. 4 硬件设计的验证

a ) 生产和运行的验证措施;

GB / T34590. 2 — 2022 中的7. 4. 2. 3 组织应建立、执行并维护流程以实现和保持相关项在生产、运行、服务和报废阶段的功能安全。注:这包括与相关项功能安全相关的现场监控流程。参考 GB / T34590.7 — 2022 。

a ) 提供能用于分析以探测功能安全问题存在的现场数据;

a ) 按照 GB / T34590. 2 — 2022 中的 7. 4. 2. 3 和 GB / T34590. 7 — 2022 中的 7. 4. 1. 1 进行有效的现场监测;

7. 4. 5 生产、运行、服务和报废

7 硬件设计工作成果7 Hardware design

8. 4. 1 本要求适用于等级为 ASIL ( B )、 C 和 D 的安全目标。应将按照附录 C 的诊断覆盖率、单点故障度量和潜伏故障度量的概念用于 8.4. 2~8. 4. 9 的要求。

A. 1. 1 用例描述

A1. 2 安全机制的描述

A. 1 DMA 安全机制评估示例

GB/ T34590.11 — 2022 附录 A 中的示例

a ) 对硬件元器件残余故障的诊断覆盖率应等于或高于相关项 SPFM 目标值;

b ) 来自表 4 。注 2 :此定量目标的目的是提供:———设计指南;———设计符合安全目标的证据。

GB / T34590. 4 — 2022 中 6. 4. 5 运行过程中随机硬件失效的控制措施

b ) 来自表 5 。注 2 :此定量目标的目的是提供:———设计指南;———设计符合安全目标的证据。

a ) 满足 8. 4. 5 中描述的“单点故障度量”目标值;或

a ) 满足 8. 4. 6 中描述的“潜伏故障度量”目标值;或

8 硬件架构度量的评估8 Evaluation of the hardware architectural metrics

a ) 来自表 6 ;

b ) 来自值得信赖的相似设计的现场数据;或

GB / T34590. 4 — 2022 中 6. 4. 5 运行过程中随机硬件失效的控制措施

a ) 相关项的架构;

b ) 每个可导致单点故障或残余故障的硬件元器件的失效模式的估算失效率;

c ) 每个可导致多点故障的硬件元器件的失效模式的估算失效率;

d ) 安全机制对安全相关的硬件要素的诊断覆盖率;

e ) 多点故障情况下的暴露持续时间。

9. 4. 2 随机硬件失效概率度量( PMHF )的评估

9. 4. 3 对违背安全目标的每个原因的评估( EEC）（大多数企业都会选择PMHF，所以在此就不展开介绍）

a ) 采取专用措施;或

a ) 采取专用措施( 9. 4. 1. 2 中注 2 列举的专用措施示例)。

9. 4. 4 验证评审

9 随机硬件失效导致违背安全目标的评估9 Evaluation of safety goal violations due to random hardware failures

10. 4. 1 硬件集成和验证活动应按照 GB / T34590. 8 — 2022 第 9 章执行

a ) 功能安全及技术安全要求的正确实施;

b ) 安全机制正确的功能性能、准确性和时序

c ) 接口的一致性和正确实施;

d ) 足够的鲁棒性。

a ) 适合提供功能安全证据的测试目标;

b ) 相关项及该相关项中有助于安全概念的要素的集成和测试。注:这包括有助于安全概念的其他技术要素。

a ) 应为软硬件集成和测试定义相关项集成和测试策略;

b ) 相关项集成和测试策略的定义应包括系统和整车层面的集成测试规范。应确保来自于软硬件验证的未解决问题得到处理;

c ) 相关项集成和测试策略应考虑车辆系统(相关项内部和外部)与环境之间的接口;

GB / T34590. 4 — 2022 中 7. 4. 1 集成和测试策略规范

10. 4. 1 硬件集成和验证活动应按照 GB / T34590. 8 — 2022 第 9 章执行

a ) 功能安全及技术安全要求的正确实施;

b ) 安全机制正确的功能性能、准确性和时序

c ) 接口的一致性和正确实施;

d ) 足够的鲁棒性。

a ) 适合提供功能安全证据的测试目标;

b ) 相关项及该相关项中有助于安全概念的要素的集成和测试。注:这包括有助于安全概念的其他技术要素。

a ) 应为软硬件集成和测试定义相关项集成和测试策略;

b ) 相关项集成和测试策略的定义应包括系统和整车层面的集成测试规范。应确保来自于软硬件验证的未解决问题得到处理;

c ) 相关项集成和测试策略应考虑车辆系统(相关项内部和外部)与环境之间的接口;

GB / T34590. 4 — 2022 中 7. 4. 1 集成和测试策略规范

10 硬件集成和验证10 Hardware integration and verification

ISO26262-Part5 Hardware development

6. 4. 1. 4 技术安全要求和非安全要求不应矛盾。

6. 4. 1 技术安全要求的定义

6. 4. 2 安全机制

6. 4. 3. 3 系统架构设计应实现技术安全要求。

6. 4. 3 系统架构设计规范和技术安全概念

6. 4. 4 安全分析及避免系统性失效

6. 4. 5 运行过程中随机硬件失效的控制措施

6. 4. 6. 3 每个系统架构设计要素都应继承其实现的技术安全要求的最高的 ASIL 等级。

6. 4. 6 分配到硬件和软件

6. 4. 7. 3 硬件的相关诊断能力和软件对其的使用应在软硬件接口规范中定义:a ) 应定义硬件的诊断特性;示例:过流、短路或过温的探测。b ) 应定义需要在软件中实现的对硬件的诊断特性。

6. 4. 7. 4 应在系统架构设计过程中对软硬件接口( HSI )进行定义。注:在硬件开发(见 GB / T34590. 5 — 2022 第 6 章)和软件开发(见 GB / T34590. 6 — 2022 第 6 章)过程中对软硬件接口( HSI )进行细化。

6. 4. 7 软硬件接口( HSI )规范

6. 4. 8 生产、运行、服务和报废

6. 4. 9 验证

6 技术安全概念工作成果

7. 4. 1 集成和测试策略规范

7. 4. 2. 1 软硬件集成

7. 4. 2. 2 软硬件测试中的测试目标和测试方法

7. 4. 2 软硬件集成和测试

7. 4. 3. 2 系统测试中的测试目标和测试方法

7. 4. 3 系统集成和测试

7. 4. 4. 1. 2 应对相关项与车内通信网络以及车内供电网络的接口规范进行验证。

7. 4. 4. 1 整车集成

7. 4. 4. 2 整车测试期间的测试目标和测试方法

7. 4. 4 整车集成和测试

7 系统及相关项的集成和测试工作成果

8. 4. 1 安全确认的环境

8. 4. 3 安全确认的执行

8 安全确认工作成果

ISO26262-Part4Product development at the systemlevel

5. 4. 2 供应商选择准则

5. 4. 3. 3 概念阶段的责任方应按照 GB / T34590. 3 — 2022 制定功能安全概念。

5. 4. 3 分布式开发的启动和计划

5. 4. 5 分布式开发中的功能安全评估活动

5. 4. 3. 3 概念阶段的责任方应按照 GB / T34590. 3 — 2022 制定功能安全概念。

5. 4. 3 分布式开发的启动和计划

5. 4. 4. 1 客户应确保供应商按时收到所需的用于执行开发接口协议中安全活动的信息和数据。

5. 4. 4. 2 供应商应向客户报告可能增加不符合开发接口协议条款的风险的问题。

5. 4. 4. 3 供应商应向客户报告在其责任范围内和其分包商责任范围内的开发活动中发生的安全异常。

5. 4. 4. 6 供应商应向客户传达其职责范围以外但供应商认为为确保实现功能安全所必要的相关项的要素的安全要求。

5. 4. 4. 8 供应商应向客户报告安全计划中制定的各项任务和里程碑节点上所取得的进展。供应商和客户应就报告的内容和提交的日期达成一致。

5. 4. 4 分布式开发的执行

5. 4. 6. 3 供应协议应规定各方间关于安全相关特殊特性的生产监控记录和从客户退回部件的失效分析结果的访问和交换。注:这些事项能由质量管理协议充分覆盖。

5. 4. 6 生产、运行、服务和报废的协议

5 分布式开发的接口工作成果

7. 4. 1 应计划配置管理。注:配置管理计划可以包括职责和资源、工具和存储库、配置项的识别和命名规范、访问权限、基线计划、发布/批准程序。

7. 4. 2 配置管理过程应符合:a ) 质量管理体系标准的相关要求;b ) 软件开发的特定要求。注 1 : ISO / IEC / IEEE12207 中给出了软件开发的软件配置管理的特定要求。注 2 :配置管理过程可以适应开发的相应阶段。

7 配置管理工作成果

8. 4. 1. 3 应为已识别出的工作成果、相关项和要素定义实施变更管理流程的日程表。

8. 4. 2. 1 应为每个变更需求分配唯一的识别码

8. 4. 2. 2 每个变更需求应至少包含以下信息:a ) 日期;b ) 所需变更的理由;c ) 所需变更的准确描述;d ) 所需变更基于的配置。

8 变更管理工作成果

9 验证的工作成果

10. 4. 3 文档宜是:a ) 准确的和简明的;b ) 结构清晰的;c ) 目标使用者容易理解的;d ) 可验证的;e ) 可维护的。

10. 4. 4 整个文档的结构宜考虑内部流程和工作实践。应对文档进行组织以助于搜索相关信息。示例:文档树。

10 文档管理工作成果

11. 4. 4 对软件工具使用的计划

11. 4. 5 通过分析对软件工具进行评估

11. 4. 6 软件工具的鉴定

11. 4. 7. 4 使用中积累置信度的论证应仅对所评估的软件工具版本有效。

11. 4. 7 使用中积累置信度

11. 4. 8 工具开发流程评估

11. 4. 9. 2 软件工具的确认应满足以下准则:a ) 确认措施应提供软件工具符合分类中指定用途的特定要求的证据;注 1 :确认提供了评估的工具错误不会发生或将被检测到的证据。注 2 :确认可通过使用用户开发的或工具供应商(如果供应商的测试套件包括用户的工具使用案例)开发的自定义测试套件来实施。示例 1 :编程语言标准有助于定义相关编译器的确认要求。b ) 应对确认中发生的软件工具功能异常及其相应错误输出、其可能的后果信息以及避免或探测它们的措施进行分析;c ) 应检查软件工具对异常运行条件的响应。示例 2 :可预见的误用、不完整的输入数据、不完整的软件工具升级、使用被禁止的配置设置组合。

11. 4. 9 软件工具确认

11 所使用软件工具的置信度工作成果

12. 4. 3 软件组件鉴定的验证应按照第 9 章验证软件组件的鉴定结果连同这些结果对软件组件预期使用的有效性。

12 软件组件的鉴定工作成果

13 硬件要素评估工作产品

14. 4. 4 候选项修改分析

14. 4. 5. 2. 1 应具备候选项评估期的计算依据。

14. 4. 5 现场数据的分析

14 在用证明工作产品

15 GB / T34590 适用范围之外应用的接口工作产品

16 未按照 GB / T34590 开发的安全相关系统的集成工作产品

ISO26262-Part 8:Supporting processes

5. 4. 2. 5 组织应为功能安全的实现提供所需的资源。注:资源包括人力资源、工具、数据库、指南和工作说明。

5. 4. 2. 7 组织应确保给予负责实现或维护功能安全、执行或支持安全活动的人员以足够的权限来履行他们的职责。

5. 4. 2 安全文化

5. 4. 3 关于功能安全的安全异常管理

5. 4. 4 能力管理

组织应具有支持实现功能安全并满足质量管理标准如 IATF16949 、ISO9001 或等同标准的质量管理体系。

5. 4. 5 质量管理体系

5. 4. 6 独立于项目的安全生命周期剪裁

5. 4. 4 能力管理

组织应具有支持实现功能安全并满足质量管理标准如 IATF16949 、ISO9001 或等同标准的质量管理体系。

5. 4. 5 质量管理体系

5. 4. 6 独立于项目的安全生命周期剪裁

5. 4. 3 关于功能安全的安全异常管理

5 整体安全管理工作成果

6. 4. 3 相关项层面的影响分析

6. 4. 5 安全活动的剪裁

6. 4. 6. 2 安全经理应负责维护安全计划并监控安全活动的进度是否按照安全计划进行。

6. 4. 6. 6 安全活动的计划应包括:a ) 目标;b ) 对其他活动或信息的依赖性;c ) 负责执行活动的人员;d ) 执行活动所需的资源;e ) 起始时间、结束时间和持续时间;f ) 相应工作成果的识别。

6. 4. 6 安全活动的计划和协调

6. 4. 7 安全生命周期进程

6. 4. 8 安全档案

6. 4. 9 认可措施

6. 4. 10 认可评审

6. 4. 11. 3 功能安全审核可基于是否达到 GB / T34590 中流程相关的目标来判断。注: GB / T34590 目标的实现与标准中相应要求相对应。示例: 6.1 规定了第 6 章中要求的目标。

6. 4. 11 功能安全审核

6. 4. 12. 2 功能安全评估可基于对 GB / T34590 的各项目标是否达到来判断。注: GB / T34590 的目标实现是根据开发时这些标准的相应要求、技术解决方案的当前技术水平和适用的工程领域知识来判断的。示例: 6. 1 中规定了第 6 章要求的目标。

6. 4. 12. 3 功能安全评估:a ) 按照 6. 4. 6. 5f )进行计划;b ) 最迟宜在系统级产品开发之初进行规划;c ) 宜在产品开发过程中逐步执行;d ) 应在生产发布前完成。示例:功能安全评估的示例议程见附录 E 。

6. 4. 12 功能安全评估

6. 4. 13. 4 生产发布的功能安全文档应包括以下信息:a ) 负责发布的人员的名字和签名;b ) 发布相关项或要素的版本;c ) 发布相关项或要素的配置;d ) 发布日期。

6. 4. 13 生产发布