电动汽车功能安全技术规范管理制度

1、电动汽车功安全技术规范管理制度1.2 功能安全本部分的功能安全是指电池系统和充电系（相关内容参见后继章节以的功 能安全。1.2.1 整车功能安全开发流程功能安全开发流程符合GB/T34590-2017道路车辆功能安全相关规定要求。 1.2.2 概念开发阶段应基于 GB/T34590.3-2017 相关规定完成概念发，并得出相关项定、安全目标和 功能安全要求，作系统开发的必要输入1.2.2.1 相关项定义为了充分理解相关后续阶段的安全活提供支持相关项的功能素、 接口环境条件相关法规要求和危害方面考虑详细定义相关的功能性和非功能 要求。1.2.2.2 危害分析与风险评估危害分析与风险评的目的是识别

2、相关项因故障而引起的危害对危害进行归类， 制定相应的安全目，以避免不合理的风。其中，应基于相关的功能行为，来分析潜在的危害事件。再危害 -事件的严重 程度露概率控三个方面对相关项行系统性的评估而确定安全目标及应的 ASIL等级。1.2.2.3 功能安全概念功能安全概念主要为了从安全目标中得功能安全要求其分配给相关项的架 构要素或外部措施定义功能安全要求应从相关项的运行式故障容错时间间安全状态、紧急 运行时间间隔及功冗余等方面进行考虑用安全分方 法 ，使制定的功安全要求更加完善功能安全概念还应照 GB/T34590.9-2017 的要求进行验证以表明与安全目标 一致性和符合性，减轻或避免危害事件

3、能力。1.2.3 系统功能安全开发进行正式系统开发，应基于 GB/T34590.4-2017 相关规定，定系统层面产品开 的安全活动计划包括确定设计和集成程中适当的方法措施、 测及验证计划功能 安全评估计划等。1.2.3.1 系统安全要求设计技术安全要求是实功能安全概念必要的术要求是将相关项层面功能安全 要求细化到系统层的技术安全要求。应基于 GB/T34590.4-2017 相关规定，根据功安全概念、相关项的步架构设想、 外部接口、限制条等系统特性来制定技安全要求。技术安全要求应从障探测指示/控制措施全状态障容错时间间隔方面考 虑，定义必要的安机制。1.2.3.2 系统设计系统设计应基于功概

4、念相关项的初步构设想和技术安全求在实现技术安全 要求相关的内容时验证系统设计能力硬件设计技术能力行统测试的能 力等方面考虑系统计。为避免系统性失效系统设进行安全分析以识系统性失效的原因和统性故 障的影响。为降低系统运行过中随机硬件失效造成影响应在统设计中定义探测制或 减轻随机硬件失效措施。系统设计中定义软件接口规范，并在后硬件开发和软件开发程中进行细化。 1.2.3.3 系统集成与测试基于GB/T34590.4-2017相规定分别进行软硬件系统整车层级集成和测试， 验证每一条功能和术安全要求是否满足范系统设计在整个相关上是否得到正 确实施。为发现系统集成过中的系统性故障，在定测试方法时，应从下

5、几个方面考虑： （1）功能和技要求在系统层面是否正确执行；（2）安全机制系统层面是否被正确执行；（3）外部接口内部接口在系统层面行的一致性和正确；（4）安全机制系统层面的失效覆盖的有效性；（5）系统层面鲁棒性水平。1.2.3.4 安全目标确认应基于 GB/T34590.4-2017 中的规定，通过检和测试等方式，确认全目标是否在 整车层面是正确、整并得到完全实现。确认安全目标前可从确认流程测试用例环境条件等方面虑并制定详细的确 认计划。应根据安全目标、能安全要求和预期用，按计划执行整车层的安全目标确认。 具体确认方法可考详细定义的可重复性试安全分长期测试户抽测评审形 式。1.2.4 电控单元硬

6、件开发电控单元硬件开发程应满足 GB/T 34590.5-2017 的要求，行规定的安全活动 输出规定的交付内。1.2.4.1 电控单元硬件安全要基于GB/T 34590.5-2017相关定，将技术安全概，技术安全要求系统设计说明 落实到硬件层级，计完整且详细的硬件全要求。为保证硬件安全要的完整性，在设计时考虑包含以下内容：（1）安全机制其属性；（2）验证的标；（3）硬件度量目标值；（4）FTTI；（5）其它与安相关的要求。为保证硬件安全要的质量，应按照 GB/T 34590.8-2017 中第 6 章的要求进行硬 件安全要求的设计验证和管理。为使硬件被软件正地控制和使用，应对硬件接口（ ）进

7、行充分的细化，并 描述出硬件和软件间的每一项安全相关关联性。1.2.4.2 电控单元硬件设计基于GB/T 34590.5-2017相关定，进行硬件架构计和硬件详细设，并进行硬件 安全分析，以满足统设计说明和硬件安需求的要求。为避免硬件的系统风险，一般应进行硬架构设计，然后进行件详细设计。在硬件架构设计时应确保每个硬件组件承了正确的 ASIL 等级，并可追溯与之 相关的硬件安全要。在硬件设计时应运用相关经验总结并考虑安全相硬件组件失效的非能性原 因，如果适用，可含以下因素：温度，动，水，灰尘， EMI，来硬件架构的其他组 件或其所在环境的扰。为提高设计的可靠，应遵循 34590.5-2017 中

8、的“模块的硬件设计原则”和 “鲁棒性设计原则设计、坏情况分析等。为识别硬件失效的因和故障的影响，应 GB/T 34590.5-2017 中的要求，根据 同的 ASIL 等，使用“演绎分 FTA）“归纳分）的方法进行安分 析。如果安全分析表明产、行服务和报废与安相关，则应定义其安全相关的特 殊特性并输出说明文件。为验证硬件设计与件安全要求的一致性完整性，应按 GB/T 34590.5-2017 中的 要求，对硬件设计行验证。1.2.4.3电控单元硬件组件鉴定基于 GB/T 34590.8-2017 关规定，对其中复的硬件组件及元件应进行硬件组件 的鉴定，确保硬件件合规使用并为FMEDA分析提供基

9、础数据1.2.4.4 电控单元硬件架构度的评估基于 34590.5-2017 相关规定，进行件架构度量的评估并将评估结果和优化 建议反馈到系统设件设计件设计环节以优化产品设计最终的“单点障度 量”和“潜伏故障量”满足对应ASIL的求。1.2.4.5 随机电控单元硬件失导致违背安全目标的评估基于 GB/T 34590.5-2017 相关规定，进行 评估或割分析评估，闭环优使相关 安全目标没有由于机硬件失效带来的不接受的风险。1.2.4.6 电控单元硬件集成和试基于 GB/T 34590.5-2017 相关规定，进行硬件集成测试，通过测试保所开发的 硬件符合硬件安全求。硬件集成测试用例生成应考虑G

10、B/T 34590.5-2017的表10中所列的方法。为了验证安全机制完整性和正确性，件集成测试应考以下方法功能测试故 障注入测试和电气试。为了验证硬件在外应力下的鲁棒性，硬集成测试应考虑B/T 的表 12中所列方法。1.2.5 电控单元软件设计1.2.5.1 软件安全需求分析软件安全需求分析的是依据安全技术规以及系统设计说明书定软件安全需求， 同时验证软件安全求与安全技术规范及统设计说明书是否一软件安全需求分阶 段需满足完整性、测试性、可追溯性要。软件安全需求分析应从如下方面考虑分识别失效会违安全技术要求的软 功能需来源于安技术要求和系统设方案应识别软件与件之间所有安全相的属 性含足够的硬运

11、行资源效安全相关等信息的认硬件口说明书应是确认 有效的；测试验证法应是安全有效的。1.2.5.2 软件安全架构设计软件安全监控架构计目的在于开发一个以满足并实现软件安需求的软件架构。 软件安全监控架构计需结合功能安全相软件需求和非功能安相关软件需求，局考 虑软件的架构设计并进行软件安全分析软件安全监控架构计时从如下方面考虑该是可配置可实施于测试和可 维护的遵循模块化高类聚低耦合复杂度的要求细化到足够支持细设计； 应具备静态和动态性；应满足独立性的求；应覆盖软件安全求等。1.2.5.3 软件失效分析与详细计软件失效分析与软详细设计目的是基于件架构设计及软件安需求对软件功 能模块进行详细设，同时根

12、据建模及编指导书进行模型或源码设计。软件详细设计时应从如方面考虑包含足够的必要信以便于允许后续活动 展详细描述其功能特满足可测性维护复杂度读性和健壮性等要； 详细设计应满足与件安全需求架构准则设计说明书等一致性的求。 1.2.5.4 软件安全算法测试软件算法测试用于明软件单元模块符合件详细设计说明书要，该要求包括 件功能要求的符合，接口要求的一致性算法的健壮与高效等软件算法测试案例计时需按照软件详细设说明书，软失效分析报告要采 用需求分析、等价划分、边界值分析、误猜想等方法。软件算法测试活动要做好详细设计、失分析报告、测试案例测试数据、测试缺陷的双向可追溯性过程的完整性。软件算法测试同时需要度量验证软件算质量括单覆盖 句覆盖度，分支覆度，修正判定条件覆度等编码规则，以及其他 静态度量指标（如圈复杂度等参见GB/T34590.6-2017相关要。 1.2.5.5 软件集成与架构符合测试软件集成与架构符性测试主要用于验证件组件集成功能软件 组建之间的接口是符合软件架构设计文要求。软件集成通常可分增殖式集成与一次性成同的集成方应的 集成测试策略也不。常用到的测试方法括：基于需求的测试接口测试， 故