您的当前位置:首页正文

新能源电动汽车控制安全技术规范管理制度

2022-08-01 来源:易榕旅网
新能源电动汽车控制安全技术规范管理制度

2.3 控制安全

基于 GB/T 34590-4 相关规定,基于系统功能概念和技术安全要求,进行系统级别的安全要求定义,进行系统架构设计,明确软硬件接口定义规范,进行系统级别失效分析,为后续硬件和软件设计提供输入。 2.3.1 硬件设计要求

从硬件安全要求定义、硬件设计及实现、硬件失效模式分析、硬件系统测试等四个方面进行硬件设计工作,参考 GB/T 34590-5。 2.3.1.1 硬件安全要求

所设计硬件产品应符合电气性能、环境适应性等车辆系统级要求。

(1)电气性能:所设计的硬件产品应符合 QC/T 413 汽车电气设备基本技术条件所规定的电气性能要求;应根据 ISO 16750-2 及 GB/T 28046.2 等满足工作电压、电源过电压性能、电源叠加交流电性能、电源电压跌落性能、电源启动特性、电源极性反接、抛负载性能、供电电压缓升和缓降性能、供电电压瞬时下降性能等要求;

(2)环境适应性:应满足车辆运行环境的需求,针对布置在底盘等湿区位置的产品防护等级不应低于 IP67;应根据 GB/T 28046.3 的要求满足低温性能、高温性能、温度冲击性能、温湿性能、盐雾性能、防护性能、自由跌落性能等产品性能要求。 2.3.1.2 硬件设计及实现

需进行硬件架构度量的评估,并将评估结果和优化建议反馈到系统设计、硬件设计、软件设计环节,以优化产品设计。详细设计和实现阶段,应充分考虑功能冗余及功能要求,优先采用汽车级成熟电路单元,元器件选用汽车级芯片,以满足性能、功能及成本的要求。 2.3.1.3 硬件失效模式分析

通过对硬件失效模式分析,识别硬件设计中因潜在风险导致的产品失效,建立 FMEA表,以保证分析的完整性。对于侵害安全的失效模式,应制定相应的安全机制来保证安全性;对于非侵害安全的失效模式,需评估设定安全机制的必要性。 2.3.1.4 硬件系统测试

为了验证安全机制的完整性和正确性,硬件系统测试应考虑按以下方法进行,通过测试确保所开发的硬件符合硬件安全要求。

(1)功能性测试,即采用黑盒测试技术针对被测硬件的接口规格说明进行测试;

(2)非功能性测试,即对硬件的性能或可靠性进行测试。 2.3.2 软件设计要求

基于 GB/T 34590-6 相关规定,进行软件安全要求的定义、软件架构设计、软件单元设计及实现、软件单元测试、软件集成及测试、软件安全要求与验证,并满足系统设计和软件安全需求的要求。 2.3.2.1 软件安全要求的定义

基于 GB/T 34590-6 相关规定,软件安全要求来源于技术安全要求和系统设计规范,软件安全要求的定义考虑硬件的约束及对软件的影响。软件安全要求应针对每个基于软件模块的功能,这些功能的失效可能导致违背分配到软件的技术安全要求。软件安全需求分析阶段需满足完整性、可测试性、可追溯性要求。 2.3.2.2 软件架构设计

基于 GB/T 34590-6 相关规定,软件架构设计描述全部软件组件及其在层次结构中的交互;静态方面,如所有软件组件间的接口和数据路径;动态方面,如进程顺序和时序行为都得到描述。

在软件架构设计应考虑软件架构设计的可验证性、可配置软件的适用性、软件单元设

计及实现的可行性、软件集成测试中软件架构的可测性及软件架构的课维护性。软件架构设计需遵循高类聚、低耦合的要求具有模块化、封装性和简单性属性。

软件架构设计中,应使用 FFI(Free From Interface,例如:Time Protection, Memory Protection, Data protection)来避免软件要素间的相互干扰。 2.3.2.3 软件单元设计及实现

基于 GB/T 34590-6 相关规定,基于软件架构设计开发软件单元的详细设计。软件单元的详细设计分别按照建模或编码指南,以模型或直接以源代码的形式实现。在进入软件单元测试前对详细设计和实现进行静态验证。软件单元的实现包含源代码的生成和转换为目标代码。 2.3.2.4 软件单元测试

软件单元测试目的是要证明软件单元满足软件单元设计规范且不包含非预期的功能。软件单元测试是根据软件单元设计规范,建立软件单元测试流程,并按照该流程执行测试。

在单元测试过程中,为了评估测试用例的完整性并证明没有非预期的功能,应确定软件单元层面的要求覆盖度,同时对覆盖度进行测量,如果认为已实现的结构覆盖率不充分,应增加额外的测试用例或给出接受的理由。 2.3.2.5 软件集成及测试

基于 GB/T 34590-6 相关规定,按照软件架构设计,对软件要素之间特有的集成层次和接口进行测试,软件要素的集成和测试的步骤直接对应着软件的分层架构。

软件集成应完成各个软件单元分层集成到软件组件,直到整个嵌入式软件被集成,并考虑与软件集成相关的功能依存关系和软件集成和软硬件集成之间的依存关系。

在软件集成测试过程中,为了评估测试用例的完整性并证明没有非预期的功能,应确定软件集成层面的要求覆盖度,同时对覆盖度进行测量,如果认为已实现的结构覆盖率不充分,应增加额外的测试用例或给出接受的理由。 2.3.2.6 软件安全要求验证

基于 GB/T 34590-6 相关规定,软件安全要求验证的目的是证明嵌入式软件在目标环境下满足软件安全要求。

软件安全要求验证中的测试环境可为硬件在环,测试台架,或者整车环境。可考虑使用工具(例如:traceability matrix)确保和评估软件安全要求的覆盖率,可以复用已有的测试用例。如果覆盖率不充分,应增加测试用例或给出可以接受的理由。

2.4.3 功能和操作设计 2.4.3.1 上下电操作设计

整车控制系统应能控制 B 级电压电路的通断顺序,通电时,应先接通低压、后接通高压,断电时,应先断开使能信号使高压部件停止工作,后断开低压控制信号切断高压。

整车上高压时应检测制动踏板和档位信号,断电时只需断开电源开关即可。

2.4.3.2 档位操作设计

换挡操作应在踩下制动踏板制动有效的情况下换挡有效。 2.4.3.3 充电操作设计

当充电枪和整车连接时,整车不能发出扭矩驱动车辆行驶。 2.4.3.4 转向操作设计

车辆在行驶过程中,出现需要整车主动断 B 级高压电的车辆异常情况时,应能通过声光报警通知驾驶员,且在车速大于 5km/h 时应保持转向系统维持助力状态或至少保持转向助力状态 30 s 后再断 B 级电。 2.4.3.5 制动优先设计

车辆行驶过程中,当制动踏板和加速踏板同时有效时,车辆应只响应制动

踏板信号。

2.4.3.6 车辆故障等级显示及处理机制

针对不同故障等级,各主机厂依据自身情况制定不同的故障处理机制,可参考下表:

故障级别 说明 三级故障 严重故障 通知驾驶员尽快切断驱动力 二级故障 较严重故障 一级故障 警告故障 处理机制 限制扭矩输出 仪表提示 针对不同故障等级,各主机厂依据自身情况制定不同的故障显示机制,可参考下表:

故障级别 说明 三级故障 严重故障 声音警告,仪表显示整车三级故障 二级故障 较严重故障 声音警告,仪表显示整车二级故障 一级故障 警告故障 仪表显示整车一级故障 仪表显示机制

因篇幅问题不能全部显示,请点此查看更多更全内容