广告
电车试验：电机系统与电驱动总成安全——电驱动总成功能安全
2022-02-14 14:29:33· 来源：汽车测试网
功能安全主要作用：当危害影响发生时，让电子电气系统进入一个安全状态并保持一个安全状态。包含两方面：系统失效（比如：错误系统设计）和随机硬件故障（比如电
功能安全主要作用：当危害影响发生时，让电子电气系统进入一个安全状态并保持一个安全状态。包含两方面：系统失效（比如：错误系统设计）和随机硬件故障（比如电子电气元件老化）。其目的是使技术无法避免但又必须处理的危害最小化。
本指南修改遵循ISO 26262，适用于道路车辆上由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。
1）提供了一个汽车安全生命周期(管理、开发、生产、运行、服务、报废)，并支持在这些生命周期阶段内对必要活动的剪裁；
2）提供了一种汽车特定的基于风险的分析方法以确定汽车安全完整性等级（ASIL）；
3）应用汽车安全完整性等级（ASIL）定义-本指南适用的要求，以避免不合理的残余风险；
4）提供了对于确认和认可措施的要求，以确保达到一个充分、可接受的安全等级；
5）提供了与供应商相关的要求。
功能安全受开发过程(例如，包括需求规范、设计、实现、集成、验证、认可和配置)、生产过程、服务过程和管理过程的影响。安全问题与常规的以功能为导向和以质量为导向的开发活动及工作成果相互关联。本指南涉及与安全相关的开发活动和工作成果。
本指南适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。
功能安全通常由整车厂提出安全目标，电驱动总成配套企业设计并实施功能安全方案。不同的整车厂、电驱动总成企业在功能安全的要求和实施方案上存在差异。下面所述仅是一个指导性示例，无需严格遵照执行。
一、功能安全管理
1、安全文化的定义
概要：组织创设安全文化，支持功能安全的实现。以此，建立并维护组织的规则和管理流程。
要求：
1）支持功能安全活动的企业文化的培养。
2）遵循功能安全标准的原则。
3）功能安全相关的问题的分析，评估，可追溯性。
4）执行功能安全相关的活动和文件管理规定。
5）遵循流程的建立、执行和维护方针。
6）确保赋予功能安全相关的管理人员适当的权限。
2、安全活动相关的人才管理
概要：确保实施安全活动人员的能力，对于项目进行人才的分配及培养的支持。
要求：人员技能、权限的规定。
1）安全相关的设计和验证的能力。
2）相关审核评估的能力。
3）ISO26262 及其他安全标准的知识。
4）公司内部规定。
5）领域知识。
6）管理能力。
3、安全生命周期中的质量管理
概要：建立和管理ISO/TS 16949 及ISO 9001 的质量管理标准或与之等同的质量管理体系。
要求：公司内部的质量管理规定。
明确描述质量管理和功能安全的关联。
4、功能安全管理的分工和责任
概要：任命具有权限、责任的安全管理者。
5、功能安全活动的计划和调整
概要：制定安全计划，进行批准和认可评审，并进行维护、管理。
6、功能安全生命周期的进程
参考：ISO 26262-1 Figure 1 — Overview of ISO 26262。
7、安全档案的管理
制定认可措施计划，按照独立性和权限实施，认可措施安全所要求的独立性实施，执行认可措施的人员能够接触组织机构、必要的产品项目信息及工具。
8、量产后的功能安全管理
安全完整性：安全功能是否能连续正常工作15 年，是否能及时检测出系统错误（例如：危害产生影响之前）。
完整性：是否考虑了各个方面，是否所有的详细信息都被理解性地收集和保存。
文档：是否所有的细节都得到了证明，即使在以后（产品生命周期15 年）。
9、SOP 后的量产管理
组织应指定相关人员的责任和为生产发布后保持该项目的功能安全相关法律提供依据。
生产后释放的规范应保证项目功能安全的活动。
二、功能安全概念设计阶段
1、相关项定义
目的：第一个目的是定义相关项即电机控制系统，与其环境和其它相关项的依赖性和相互影响。第二个目的是为充分理解相关项即电机控制系统提供支持，以便执行后续阶段的活动。
要求：相关项的功能要求、非功能要求及环境依赖性的确认。
定义相关项的边界、接口以及提出与其他相关项和要素的交互关系。
相关项的定义：功能列表、使用环境要求、法律法规要求、已知安全要求、功能框图、功能框图的边界。
2、结构
图5-5 电机控制系统结构框图
电机控制系统包括如下组件：
电机控制器；
电机。
3、功能
电机控制系统应基于当前车辆状态和路况提供以下功能：
(功能安全边界定义的时候这里不考虑电机)
表5-4 电机控制器功能
表5-5 电机控制器详细功能
4、非功能要求
1）直流母线电压范围；
2）工作环境温度范围（℃）；
3）进出水口间压差；
4）冷却方式；
5）冷却水入口温度；
6）水冷流量；
7）辅助电源或其他方式可保证系统处于安全状态；
8）需要进行有效的防水防尘措施；
9）电机控制器绝缘电阻应满足安规标准；
10）MCU 应满足IP67 或更高等级的防护要求；
11）驱动电机系统在运行中所产生的电磁辐射干扰应符合相关国家标准和产品技术文件规定；
12）驱动电机系统电磁辐射抗干扰性应符合相关国家标准和产品技术文件规定。
5、安全生命周期的启动
有了相关项定义之后，就要确定项目的安全生命周期，对项目的安全生命周期进行初始化，也就是开始对项目的安全生命周期进行细化。而要进行细化，就要区分项目是新产品研发还是既有产品的改造。如果是全新的设备研发，则相关工作就得从安全生命周期的开始做起。如果是既有产品的改造，那么从项目定义开始的这些流程都可以使用一些既有的文件对整个过程进行定制。现有产品升级改造，就要注意以下一些问题：
1）要做产品和使用环境的分析，以制定出预期更改，并评估这些更改产生的影响。
a）对项目的更改包括设计更改和执行更改。设计更改应该是由需求规范、功能和性能的增加或者成本的优化所致，执行更改不能影响项目的规格和性能，但可以影响执行特征。执行更改可以由软故障更改，使用新的研发成果或生产工具所致。
b）如果配置数据和校准数据的更改会影响到产品的行为，则更改须考虑这些数据。
c）对产品环境的更改应该是由产品要使用的新的目标环境或由于其他相关产品或元素升级而引发。
2）要表述清楚产品使用的前后条件的差别，包括：
a）操作条件和操作模式；
b）环境接口；
c）安装特征，如：在车辆内部的位置，车辆的配置和变化等；
d）环境条件的范围，如：温度，海拔，湿度，震动，EMC 和汽油标号等。
1）要明确给出产品变更的描述以及影响的范围。如果不能明确产品的变更和对环境数据影响的改变，则相关影响的分析数据都要进行记录。
2）影响到的服役产品，需要进行升级的，要进行逐一列出。
3）定制的相关安全活动应符合各个应用生命周期阶段的要求，包括：
a）定制应基于影响分析的结果。
b）定制的结果应包括在符合ISO26262-2 的安全计划中。
c）影响到的产品须返工，包括确认计划和验证计划。
确定了以上这些基本信息之后，对所要进行的产品研发或者设备更改工作就有了一个清晰明确的定义，对产品的预期使用功能、环境，以及与相关设备的接口也有了一个明确的定义，接下来就可以进行危险分析和风险评估了。
6、危害分析和风险评估
危险分析和风险评估的目的和之前的ISO13849,IEC62061 等的标准一样，都是为了将设备存在的危险识别出来，并根据危险的程度按照一定的原则对其进行分类，从而针对不同的风险设定具体的安全目标，并最终减小或消除风险，避免未知风险的发生。
状况分析：故障行为记述了成为危害事件的运行状况及运行模式。
危害识别：在整车层面可以观测的状态或行为来定义危害。
通过FTA（故障树分析）进行危害事件的提出危害分析与风险评估的目的是识别相关项中因故障而引起的危害并对危害进行归类，制定相应的安全目标，以避免不合理的风险。
其中，应基于相关项的功能行为，来分析其潜在的危害事件。再从危害时间的严重程度、暴露概率、可控性三个方面对相关项进行系统性的评估，从而确定安全目标及相应的ASIL等级。概要：在整车层面通过运行场景和运行模式的组合来描述危害事件，通过组合各危害事件，来识别事件结果。
7、ASIL 等级定义
概要：对于每个危害事件，通过严重度/暴露概率/可控性的评估矩阵来定义ASIL 等级
图5-6 ASIL 等级定义
表5-6 严重度/暴露概率/可控性的评估矩阵
8、安全目标
概要：对于有ASIL 等级的危害事件，定义它相应的安全目标。
要求：对每个危害实施危害分析和风险评估，定义其ASIL 等级，设立安全目标。
功能安全目标还可以包含高压电击和电池起火等，取决于主机厂要求，但这里不展开。
表5-7 功能安全目标
9、功能安全概念
功能安全概念阶段的主要目的是通过前面的危险分析和风险评估之后得出的安全目标来确定具体的功能安全要求，并将它们分配到初步的设计架构，或者外部减少危险的措施当中去，以确保满足相关的功能安全要求。
安全概念主要是为了从安全目标中得出功能安全要求，并将其分配给相关项的架构要素或外部措施。制定功能安全要求时，应从相关项的运行模式、故障容错时间间隔、安全状态、紧急运行时间间隔及功能冗余等方面进行考虑，同时可以使用安全分析（例如FMEA、FTA、HAZOP）的方法，使制定的功能安全要求更加完善。安全概念还应按照GB/T 34590.9中的要求进行验证，表明与安全目标的一致性和符合性，即减轻或避免危害事件的能力。
图5-7 FSR 对应的FTA 分析
10、功能安全需求分配
功能安全需求分配到要素需要考虑以下几点：
1）基于相关项初期架构的要素
2）继承：ASIL 和功能安全需求信息
以下情况接受最高ASIL 等级
若下一功能安全需求被分配到了相同的架构要素中。
若相关项包含多个系统，那么导出独立系统和他们的接口的功能安全需求
如果独立冗余：可以进行ASIL 分配另外，如果ASIL 等级需要被拆解，则要符合ISO26262-9 第五条款的要求。
三、功能安全的系统阶段
1、启动系统层面产品开发
进行正式系统开发前，应基于GB/T 34590.4 相关规定，指定系统层面产品开发的安全活动计划，包括确定设计和集成过程中适当的方法和措施、测试及验证计划、功能安全评估计划等。
系统级产品开发启动的目标是确定和规划在系统开发各个子阶段的功能安全活动。这部分内容在ISO26262-8 中也有描述。系统级安全活动包含在安全计划中。
2、技术安全需求设计
技术安全要求是实现功能安全概念必要的技术要求，目的是将相关项层面的功能安全要求细化到系统层面的技术安全要求。应基于GB/T 34590.4 相关规定，根据功能安全概念、相关项的初步架构设想、外部接口、限制条件等系统特性来制定技术安全要求。技术安全要求应从故障探测/指示/控制措施、安全状态、故障容错时间间隔等方面考虑，定义必要的安全机制。
根据用于开发FSR 和初步体系结构的“输入-过程处理-输出”（I-P-O）模型，确定输入、处理、输出的TSR。
下面举几个例来说明：
表5-8 输入中的技术安全需求
表5-9 处理过程的技术安
表5-10 输出的技术安全需求全需求
3、制定安全机制
基于技术安全要求，制定安全机制：提出需要展开的技术安全需求。例：进一步展开技术安全需求，并分配容错事件间隔要求。
安全机制的讨论：基于技术安全要求及系统设计架构，讨论为了实现其功能运行的机制。例：角度检测功能，基于要素及极限值进行讨论，需要在何处进行检测。
为使项目达到或维持一个安全状态的安全机制应规定：
1）安全状态的切换；
2）容错的时间间隔；
3）如果安全状态不能立即达到，应确定应急操作的时间间隔；
4）维持安全状态的措施。
ASIL 分解按照ISO 26262-9:2011，第5 条款。
4、系统设计
系统设计应基于功能概念、相关项的初步架构设想和技术安全要求。在实现技术安全要求相关的内容时，应从验证系统设计的能力、软硬件设计的技术能力、执行系统测试的能力等方面考虑系统设计。为避免系统性失效，应对系统设计进行安全分析以识别系统性失效的原因和系统性故障的影响。为降低系统运行过程中随机硬件失效造成的影响，应在系统设计中定义探测、控制或减轻随机硬件失效的措施。系统设计中定义软硬件接口规范，并在后续硬件开发和软件开发过程中进行细化。
参考：ISO 26262-4 table2 properties of modular system design为了避免失效造成的高复杂性，架构设计需要通过以下原则进行：
1）模块化；
2）适当的粒度级别；
3）简单性。
5、导出技术安全概念
目的：基于系统设计的结果，将技术安全要求分配硬件、软件。
概要：由功能安全需求导出技术安全需求，进行系统设计，导出技术安全概念。
1）系统设计的可验证性；
2）软件硬件的技术实现性；
3）系统集成中的执行测试能力。
6、实施安全分析
基于系统设计架构及技术安全概念的结果，采用FTA 及FMEA 方法进行安全分析。
7、系统设计验证
参考：ISO 26262-4 Table 3 — System design verification。
8、系统集成与测试
基于GB/T 34590.4 相关规定，分别进行软硬件、系统、整车层级的集成和测试，验证每一条功能和技术安全要求是否满足规范，以及系统设计在整个相关项上是否得到正确实施。
集成和测试阶段包括三个阶段和两个主要目标如下所述：第一阶段为每个项目包含的元件的硬件和软件的集成。第二阶段是一个项目的元件的集成以形成一个完整的系统。第三阶段是项目与车辆的周围系统的集成。
集成过程的第一个目标是根据ASIL 等级和安全需求规范测试符合各项安全要求。第二个目的是验证“系统设计”覆盖的安全要求正确地由整个项实施。项目元件的集成是从软件硬件集成，系统集成到整车集成系统。集成测试会在每个阶段的执行来证明系统元件正确交互。根据ISO 26262-5 和ISO 26262-6 完成硬件和软件的开发，然后按照第8 条款（项目集成和测试）开始进行系统集成。
9、集成与测试的计划和定义
测试项目的导出方法
参考参考：ISO 26262-4 Table 4 —Methods for deriving test cases for
integration testing
四、功能安全硬件设计阶段
基于GB/T 34590-5 相关规定，将技术安全概念，技术安全要求和系统设计说明落实到硬件层级，设计完整且详细的硬件安全要求。
为保证硬件安全要求的完整性，在设计时应考虑包含以下内容：
1）安全机制及其属性；
2）验证的标准；
3）硬件度量的目标值；
4）FTTI；
5）其它与安全相关的要求。
为保证硬件安全要求的质量，应按照GB/T 34590-8 中第6 章的要求进行硬件安全要求的设计、验证和管理。
为使硬件被软件正确地控制和使用，应对软硬件接口（HSI）进行充分的细化，并描述出硬件和软件之间的每一项安全相关的关联性。
1、启动硬件层面产品开发
概要：基于安全计划和项目计划，定义并更新系统层面的安全活动计划。
计划产品开发中硬件元件的活动（包括支持过程）。
在设计过程中应使用适当的方法和措施。
硬件开发过程中应兼顾系统和软件的生命周期。
2、硬件安全需求规范
硬件安全需求规范：硬件安全要求应来源于技术安全概念和系统设计规范：
1）详细的硬件-软件接口（HSI）要求。
2）所有与安全相关的硬件要求必须以硬件安全要求的形式出现。
3）故障对来自外部干扰的容忍（例如：开放式输入）。
4）安全机制用来检测和修复内部（例如：组件失效）和外部（控制失效）失效。
5）安全机制用来修复暂时性和永久性失效。
6）硬件指标的目标值。
3、硬件架构设计
设计原则：
1）分层设计
2）避免不必要的接口复杂化
3）避免不必要的硬件组件复杂化（简单设计）
4）可维护性
5）可测试性
基于GB/T 34590-5 相关规定，进行硬件架构设计和硬件详细设计，并进行硬件安全分析，以满足系统设计说明和硬件安全需求的要求。
为避免硬件的系统性风险，一般应进行硬件架构设计，然后进行硬件详细设计。在硬件架构设计时，应确保每个硬件组件继承了正确的ASIL 等级，并可追溯到与之相关的硬件安全要求。
4、硬件详细设计
在硬件设计时，应运用相关的经验总结，并考虑安全相关硬件组件失效的非功能性原因，如果适用，可包含以下因素：温度，振动，水，灰尘，EMI，来自硬件架构的其他组件或其所在环境的串扰。
为提高设计的可靠性，应遵循GB/T 34590-5 中的“模块化的硬件设计原则”和“鲁棒性设计原则”，如降额设计、最坏情况分析等。
为识别硬件失效的原因和故障的影响，应按GB/T 34590-5 中的要求，根据不同的ASIL 等级，使用“演绎分析”（如FTA）或“归纳分析”（如FMEA）的方法进行安全分析。
如果安全分析表明生产、运行、服务和报废与安全相关，则应定义其与安全相关的特殊特性并输出说明性文件。为验证硬件设计与硬件安全要求的一致性和完整性，应按GB/T34590-5 中的要求，对硬件设计进行验证。
5、硬件设计-安全分析
识别失效的原因和故障的影响；
针对所考虑的安全目标，进行安全分析识别；
避免单点故障的有效性的证据；
避免潜伏故障的有效性的证据；
确定硬件设计的独立性；
如引入新危害，重新进行危害分析和风险评估。
6、硬件设计-组件的鉴定
基于GB/T 34590-8 相关规定，对其中复杂的硬件组件及元器件应进行硬件组件的鉴定，确保硬件组件合规使用并为FMEDA 分析提供基础数据。
7、硬件架构度量的评估
基于GB/T 34590-5 相关规定，进行硬件架构度量的评估，并将评估结果和优化建议反馈到系统设计、硬件设计、软件设计环节，以优化产品设计，使最终的“单点故障度量”和“潜伏故障度量”满足对应ASIL 的要求。
图5-8 硬件量化需求
表5-11 故障指标的评估
1）硬件诊断覆盖率
参考ISO 26262-5。
2）失效模式分类
图5-9 硬件失效模式分析
3）随机硬件失效导致违背安全目标的评估
由于随机硬件失效而违背安全目标的目标值基于GB/T 34590-5 相关规定，进行PMHF评估或割集分析评估，优化使相关安全目标没有由于随机硬件失效带来的不可接受的风险。
8、硬件集成和测试
基于GB/T 34590-5 相关规定，进行硬件集成和测试，通过测试确保所开发的硬件符合硬件安全要求。硬件集成测试用例的生成应考虑GB/T 34590-5 的表10 中所列的方法。
为了验证安全机制的完整性和正确性，硬件集成测试应考虑以下方法：功能测试、故障注入测试和电气测试。为了验证硬件在外部应力下的鲁棒性，硬件集成测试应考虑GB/T34590-5 的表12 中所列方法。
五、功能安全软件设计阶段
1、启动软件层面的产品开发
编写启动计划内容
1）启动软件开发活动的适当方法；
2）软件开发的剪裁；
3）配置软件开发；
4）软件生命周期的一致性；
5）方法、相应工具的选择；
6）选择适当的建模和编程语言；
7）设计和编码指南。
2、软件安全需求规范
软件安全需求分析目的是依据安全技术规范以及系统设计说明书制定软件安全需求，同时验证软件安全需求与安全技术规范及系统设计说明书是否一致。
软件安全需求分析阶段需满足完整性、可测试性、可追溯性要求。
软件安全需求分析时，应从如下方面考虑：充分识别失效会违反安全技术要求的软件功能；需来源于安全技术要求和系统设计方案；应识别软件与硬件之间所有安全相关的属性；包含足够的硬件运行资源，有效的安全相关等信息的确认；软硬件接口说明书应是确认有效的；测试验证方法应是安全有效的。
3、软件架构设计
软件安全监控架构设计目的在于开发一个可以满足并实现软件安全需求的软件架构。
软件安全监控架构设计需结合功能安全相关软件需求和非功能安全相关软件需求，全局考虑软件的架构设计，并进行软件安全分析。
软件安全监控架构设计时，应从如下方面考虑：应该是可配置、可实施、易于测试和可维护的；需遵循模块化、高类聚、低耦合、低复杂度的要求；应细化到足够支持详细设计；应具备静态和动态特性；应满足独立性的要求；应覆盖软件安全需求等。
1）软件架构设计原则
参考ISO 26262 Table 3 — Principles for software architectural design
（1）软件架构设计应开发到软件单元层级，即不可再分级别。
（2）软件架构应描述软件单元的静态设计。
（3）静态设计：
a）软件结构包含它的等级；
b）数据处理的逻辑顺序；
c）数据类型和他们的特性；
d）软件元件之间的接口；
e）外部与软件之间的接口；
f）架构和外部不见部件的约束。
（4）若基于模型开发，模型结构是固有的。
（5）软件组件的动态设计：
a）功能和行为；
b）软件组件之间的数据流；
c）外部接口的数据流；
d）时间约束条件；
e）控制流和进程的并发性。
2）软件架构设计安全分析
目的：
（1）明确顺序和故障响应
（2）推荐测试用例
（3）识别软件故障规避策略
（4）安全机制的效果展示。例如：诊断，控制硬件故障的恢复，为了解决系统失效机制。
（5）评估资源使用和分配
验证方法：
参考ISO 26262-5 Table 6 — Methods for the verification of the software architectural design
4、软件单元设计和实现
软件详细设计时，应从如下方面考虑：应包含足够的必要信息以便于后续活动开展；
应详细描述其功能特征；应满足可测性、可维护、低复杂度、可读性和健壮性等要求；详细设计应满足与软件安全需求、软件架构、编码准则、详细设计说明书等一致性的要求。
软件单元设计原则参考ISO26262-Table 8 — Design principles for software unit design and implementation
5、软件安全算法测试
软件算法测试用于证明软件单元模块符合软件详细设计说明书要求，该要求包括：软件功能要求的符合性，接口要求的一致性，算法的健壮与高效等。软件算法测试案例设计时，需按照软件详细设计说明书、软件失效分析报告要求，采用需求分析、等价类划分、边界值分析、错误猜想、故障注入等方法。
软件算法测试活动，要做好详细设计、失效分析报告、测试案例、测试数据、测试缺陷的双向可追溯性与过程的完整性。软件算法测试同时还需要度量验证软件算法质量，包括单元覆盖度（如：语句覆盖度，分支覆盖度，修正判定条件覆盖度等），代码编码规则，以及其他静态度量指标（如：圈复杂度等），具体请参见GB/T 34590-6 相关要求。
6、软件集成与架构符合性测试
软件集成与架构符合性测试主要用于验证软件组件集成功能以及软件组建之间的接口是否符合软件架构设计文档要求。
软件集成通常可分为增殖式集成与一次性集成。不同的集成方式，对应的集成测试策略也不同。常用到的测试方法包括：基于需求的测试，接口测试，故障注入测试，资源占用测试以及模型与代码的背靠背测试。
软件集成测试也包含质量度量过程， 主要度量指标包括功能覆盖度和函数调用覆盖度。
参考ISO 26262-5Table 10 — Methods for software unit testing
7、软件安全需求验证
软件安全需求验证的目的在于确保软件在目标硬件环境上能够正确实现软件安全需求。通常需采用验证方法包括硬件在环测试、电子电气试验台架测试以及实车测试等。软件安全需求验证不但要从功能角度验证软件安全需求的符合情况，还要从性能角度验证是否满足性能要求（如：程序安装测试、负载测试、软件安全需求覆盖度等）。
广告
广告
编辑推荐
最新资讯
-
HEAD acoustics下线检测：最高级别的质量保
2024-11-15 17:09
-
新能源公司与哈尔滨理工大学联合研究中心揭
2024-11-15 17:07
-
标准研究 | 汽车也要保持“头脑清醒”？有
2024-11-15 17:05
-
基础模型在推进自动驾驶汽车中的前瞻性作用
2024-11-15 17:03
-
中国汽研智能驾驶自主可控检测装备首批联合
2024-11-15 17:01
广告
广告
