随着电动化、智能化的发展,越来越多的汽车配备了电子电气系统,如电传动系统、助力转向系统、自动驾驶系统等,原有的机械部件被电子器件取代。而引入如此复杂的电子电气系统对整车安全带来了极大的风险,简单的一个元器件老化、失效,都有可能引发系统故障,进而导致事故发生。
因此,对汽车及其相关零部件安全的要求也是越来越高。
本部分的功能安全,是指除电池系统和充电系统以外的功能安全。
功能安全开发流程应符合《GB/T34590-2017 道路车辆功能安全》相关规定要求。
应基于GB/T34590.3-2017 相关规定完成概念开发,并得出相关项定义、安全目标和功能安全要求,作为系统开发的必要输入。
为了充分理解相关项,并为后续阶段的安全活动提供支持,应从相关项的功能、要素、接口、环境条件、相关法规要求和危害等方面考虑,详细定义相关项的功能性和非功能性要求。
危害分析与风险评估的目的是识别相关项中因故障而引起的危害并对危害进行归类,制定相应的安全目标,以避免不合理的风险。
其中,应基于相关项的功能行为,来分析其潜在的危害事件。再从危害-事件的严重程度、暴露概率、可控性三个方面对相关项进行系统性的评估,从而确定安全目标及相应的ASIL 等级。
功能安全概念主要是为了从安全目标中得出功能安全要求,并将其分配给相关项的架构要素或外部措施。
定义功能安全要求时,应从相关项的运行模式、故障容错时间间隔、安全状态、紧急运行时间间隔及功能冗余等方面进行考虑,同时可以使用安全分析(例如FMEA、FTA、HAZOP)的方法,使制定的功能安全要求更加完善。
功能安全概念还应按照GB/T34590.9-2017 中的要求进行验证,以表明与安全目标的一致性和符合性,及减轻或避免危害事件的能力。
进行正式系统开发前,应基于GB/T34590.4-2017 相关规定,指定系统层面产品开发的安全活动计划,包括确定设计和集成过程中适当的方法和措施、测试及验证计划、功能安全评估计划等。
技术安全要求是实现功能安全概念必要的技术要求,目的是将相关项层面的功能安全要求细化到系统层面的技术安全要求。
应基于GB/T34590.4-2017 相关规定,根据功能安全概念、相关项的初步架构设想、外部接口、限制条件等系统特性来制定技术安全要求。
技术安全要求应从故障探测/指示/控制措施、安全状态、故障容错时间间隔等方面考虑,定义必要的安全机制。
系统设计应基于功能概念、相关项的初步架构设想和技术安全要求。在实现技术安全要求相关的内容时,应从验证系统设计的能力、软硬件设计的技术能力、执行系统测试的能力等方面考虑系统设计。
为避免系统性失效,应对系统设计进行安全分析以识别系统性失效的原因和系统性故障的影响。
为降低系统运行过程中随机硬件失效造成的影响,应在系统设计中定义探测、控制或减轻随机硬件失效的措施。
系统设计中定义软硬件接口规范,并在后续硬件开发和软件开发过程中进行细化。
基于GB/T34590.4-2017 相关规定,分别进行软硬件、系统、整车层级的集成和测试,验证每一条功能和技术安全要求是否满足规范,以及系统设计在整个相关项上是否得到正确实施。
为发现系统集成过程中的系统性故障,在确定测试方法时,应从以下几个方面考虑:
(3)外部接口和内部接口在系统层面执行的一致性和正确性;
应基于GB/T34590.4-2017 中的规定,通过检查和测试等方式,确认安全目标是否在整车层面是正确、完整并得到完全实现。
确认安全目标前可以从确认流程、测试用例、环境条件等方面考虑,并制定详细的确认计划。
应根据安全目标、功能安全要求和预期用途,按计划执行整车层面的安全目标确认。具体确认方法可考虑详细定义的可重复性测试、安全分析、长期测试、用户抽测、评审等形式。
电控单元硬件开发流程应满足GB/T 34590.5-2017 的要求,执行规定的安全活动,输出规定的交付内容。
基于GB/T 34590.5-2017 相关规定,将技术安全概念,技术安全要求和系统设计说明落实到硬件层级,设计完整且详细的硬件安全要求。
为保证硬件安全要求的完整性,在设计时应考虑包含以下内容:
为保证硬件安全要求的质量,应按照GB/T 34590.8-2017 中第6 章的要求进行硬件安全要求的设计、验证和管理。
为使硬件被软件正确地控制和使用,应对软硬件接口(HSI)进行充分的细化,并描述出硬件和软件之间的每一项安全相关的关联性。
基于GB/T 34590.5-2017 相关规定,进行硬件架构设计和硬件详细设计,并进行硬件安全分析,以满足系统设计说明和硬件安全需求的要求。
为避免硬件的系统性风险,一般应进行硬件架构设计,然后进行硬件详细设计。
在硬件架构设计时,应确保每个硬件组件继承了正确的ASIL 等级,并可追溯到与之相关的硬件安全要求。
在硬件设计时,应运用相关的经验总结,并考虑安全相关硬件组件失效的非功能性原因,如果适用,可包含以下因素:温度,振动,水,灰尘,EMI,来自硬件架构的其他组件或其所在环境的串扰。
为提高设计的可靠性,应遵循GB/T 34590.5-2017 中的“模块化的硬件设计原则”和“鲁棒性设计原则”,如降额设计、最坏情况分析等。
为识别硬件失效的原因和故障的影响,应按GB/T 34590.5-2017 中的要求,根据不同的ASIL 等级,使用“演绎分析”(如FTA)或“归纳分析”(如FMEA)的方法进行安全分析。
如果安全分析表明生产、运行、服务和报废与安全相关,则应定义其与安全相关的特殊特性并输出说明性文件。
为验证硬件设计与硬件安全要求的一致性和完整性,应按GB/T 34590.5-2017 中的要求,对硬件设计进行验证。
基于GB/T 34590.8-2017 相关规定,对其中复杂的硬件组件及元器件应进行硬件组件的鉴定,确保硬件组件合规使用并为FMEDA 分析提供基础数据。
基于GB/T 34590.5-2017 相关规定,进行硬件架构度量的评估,并将评估结果和优化建议反馈到系统设计、硬件设计、软件设计环节,以优化产品设计,使最终的“单点故障度量”和“潜伏故障度量”满足对应ASIL 的要求。
基于GB/T 34590.5-2017 相关规定,进行PMHF 评估或割集分析评估,闭环优化使相关安全目标没有由于随机硬件失效带来的不可接受的风险。
基于GB/T 34590.5-2017 相关规定,进行硬件集成和测试,通过测试确保所开发的硬件符合硬件安全要求。
硬件集成测试用例的生成应考虑GB/T 34590.5-2017 的表10 中所列的方法。
为了验证安全机制的完整性和正确性,硬件集成测试应考虑以下方法:功能测试、故障注入测试和电气测试。
为了验证硬件在外部应力下的鲁棒性,硬件集成测试应考虑GB/T 34590.5-2017 的表12 中所列方法。
软件安全需求分析目的是依据安全技术规范以及系统设计说明书指定软件安全需求,同时验证软件安全需求与安全技术规范及系统设计说明书是否一致。软件安全需求分析阶段需满足完整性、可测试性、可追溯性要求。
软件安全需求分析时,应从如下方面考虑:充分识别失效会违反安全技术要求的软件功能;需来源于安全技术要求和系统设计方案;应识别软件与硬件之间所有安全相关的属性;包含足够的硬件运行资源,有效的安全相关等信息的确认;软硬件接口说明书应是确认有效的;测试验证方法应是安全有效的。
软件安全监控架构设计目的在于开发一个可以满足并实现软件安全需求的软件架构。软件安全监控架构设计需结合功能安全相关软件需求和非功能安全相关软件需求,全局考虑软件的架构设计,并进行软件安全分析。
软件安全监控架构设计时,应从如下方面考虑:应该是可配置、可实施、易于测试和可维护的;需遵循模块化、高类聚、低耦合、低复杂度的要求;应细化到足够支持详细设计;应具备静态和动态特性;应满足独立性的要求;应覆盖软件安全需求等。
软件失效分析与软件详细设计目的是基于软件架构设计及软件安全需求对软件功能模块进行详细设计,同时根据建模及编码指导书进行模型或源代码设计。
软件详细设计时,应从如下方面考虑:应包含足够的必要信息以便于允许后续活动开展;应详细描述其功能特征;应满足可测性、可维护、低复杂度、可读性和健壮性等要求;详细设计应满足与软件安全需求、软件架构、编码准则、详细设计说明书等一致性的要求。
软件算法测试用于证明软件单元模块符合软件详细设计说明书要求,该要求包括:软件功能要求的符合性,接口要求的一致性,算法的健壮与高效等。
软件算法测试案例设计时,需按照软件详细设计说明书,软件失效分析报告要求,采用需求分析、等价类划分、边界值分析、错误猜想等方法。
软件算法测试活动,要做好详细设计、失效分析报告、测试案例、测试数据、测试缺陷的双向可追溯性与过程的完整性。
软件算法测试同时还需要度量验证软件算法质量,包括单元覆盖度(如:语句覆盖度,分支覆盖度,修正判定条件覆盖度等),代码编码规则,以及其他静态度量指标(如:圈复杂度等),具体请参见GB/T34590.6-2017 相关要求。
软件集成与架构符合性测试主要用于验证软件组件集成功能,以及软件组建之间的接口是否符合软件架构设计文档要求。
软件集成通常可分为增殖式集成与一次性集成。不同的集成方式,对应的集成测试策略也不同。常用到的测试方法包括:基于需求的测试,接口测试,故障注入测试,资源占用测试以及模型与代码的背靠背测试。
软件集成测试也包含质量度量过程,主要度量指标包括功能覆盖度和函数调用覆盖度。
软件安全需求验证的目的在于确保软件在目标硬件环境上能够正确实现软件安全需求。通常需采用验证方法包括硬件在环测试、电子电气试验台架测试以及实车测试等。
软件安全需求验证不但要从功能角度验证软件安全需求的符合情况,还要从性能角度验证是否满足性能要求(如:程序安装测试、负载测试等)。