1.为什么需要软件FMEA

 

在智能汽车软件代码量突破2亿行的今天（Bosch 2023数据），软件失效已成为影响汽车安全的首要风险，软件问题造成的系统失效占比高达60%以上。软件FMEA作为系统性的软件问题分析方法，能够通过结构性的方式对软件需求、架构、设计、代码存在的问题进行分析，正在成为软件安全与质量的重要保障。

 

软件FMEA的必要性还体现在如下几个方面：

 

1、标准法规的要求

 

(1)ISO 26262/GBT 34590功能安全标准明确要求对软件系统进行失效分析

 

(2)ISO16949质量体系将FMEA列为关键的验证手段

 

(3)欧美市场准入认证中软件FMEA报告已成为必交材料

 

2、复杂系统的生存必须

 

车载软件系统愈趋复杂，新技术新方法层出不穷，软件系统的安全属性要求越来原告，由于软件造成风险占比已经高达系统性风险的60%以上。而关键软件系统的失效动辄造成车毁人亡的结果，也是用户、社会及车企不可接受的。

以L3自动驾驶域控制器为例，其软件系统包含：

 

5000万行以上代码量

 

100+个功能模块

 

2000+个数据接口

 

50+种实时任务调度

 

软件FMEA作为系统性结构化的分析方法，能够充分的对软件失效进行识别及风险评估，有助于保障车载软件系统的安全与质量。

 

3、开发过程的本质需求

 

软件的失效均属于系统性失效，其发生时机、机理、表现均有一定的固定性，即软件失效一旦存在，便在特定的情况下必定会发生，并表现形式相对一致。

软件为人为的逻辑产品，软件的开发过程是软件错误注入的主要环节，最终体现在构成软件的不同内容上。

 

Figure 1 软件问题的来源

 

根据行业内的统计，我们将软件失效原因分为四个大的类别，其中：

 

 

Figure 2 软件问题分类

 

人的因素占比7%左右，主要包括人员的开发能力及经验、组织的成熟程度、办公环境影响、人员态度等；

 

产品定义问题占比12%左右，主要包括产品定位、产品需求描述、市场场景定义、使用用例描述等；

 

流程问题占比23左右，主要包括活动裁剪与定义、角色及职责的定义、版本及基线管理、 资源管理、变更管理等；

 

技术实现问题占比58%左右，主要包括架构设计、详细设计、代码实现、工具使用、测试、开发方法等。

 

2.软件FMEA分析什么

 

1、软硬件FMEA的差异

 

相比于传统的系统与硬件FMEA，软件FMEA有诸多差异，起步也较晚，在行业内也没有形成统一的分析方法。

 

 

2、软件FMEA的分析难点及重点

 

基于以上对软硬件FMEA差异的对比，不难看出软件FMEA的分析难点与重点在于以下几个方方面：

识别分析对象

 

要从哪些维度对软件进行分析，是白盒分析还是黑盒分析，如何保证软件动态、静态方面的问题能够被充分的识别到。

 

识别失效模式

 

如何识别失效模式，并保证失效模式识别的充分性及合理性。

 

分析的颗粒度

 

分析层级、失效模式分析到一个什么样的颗粒度，即保证分析有效具有指导意义，又能避免分析过分复杂。

 

3、软件FMEA的分析时机

 

软件FMEA的分析可以在架构及详细设计级进行。

 

软件架构级别FMEA

 

主要针对的是软件需求级软件架构，一方面分析架构是否充分实现了需求，另一方面分析需求及架构中的潜在问题，例如需求描述是否充分、合理、是否有歧义等，架构是否存在接口、逻辑等技术性错误。

 

软件详细设计级别FMEA

 

主要针对的是软件详细设计潜在的问题，一方面关注软件单元是否充分实现了需求及架构要求，另一方面关注详细设计中存在技术性问题，例如逻辑错误、变量定义及赋值错误、条件判断错误等。

 

对于复杂性的软件，进行详细级别的FMEA是一个比较大的工作量，因此从成本的角度考量，可以将架构级及详细级别的FMEA结合进行，比如在架构级别分析到的风险比较高的模块，需要进行详细级别的FMEA，而对于风险较小的软件模块仅进行架构级别FMEA即可。

 

4、软件FMEA分析哪些内容

 

软件FMEA对软件模块的分析主要集中在以下几点：

 

功能及逻辑

 

针对软件模块所需实现的功能、条件、逻辑等内容

 

变量及数据

 

针对软件模块的接口及数据等，包括输入输出接口、内部变量、全局变量、常量等数据信息

 

时间属性

 

针对软件执行的调用及时间属性等，包括任务周期、前后置时序、实时性要求等

 

软件对存储的操作

 

针对软件对存储的操作，包括存储空间分配、存储内容读写、存储空间权限等

 

软件部署

 

针对软件部署时，对其他软件模块及硬件的依赖关系，包括OS、驱动、中间件、硬件资源等

 

3.软件FMEA实施

 

1、软件FMEA分析方法

 

软件FMEA的分析可以参考传统的FMEA七步法，也可以直接基于软件模块来进行分析。

Figure 3 传统FMEA七步法

 

 

 

Figure 4 基于软件模块直接进行分析

 

1. 典型软件失效模式

 

1.1. 功能逻辑失效分析

 

参考Hazop关键字对功能逻辑的失效模式进行分析

 

 

2、变量及数据失效分析

 

对于变量及数据的分析，主要考虑到

 

变量及数据的类型

 

变量及数据的范围及初始值

 

变量及数据Raw值与物理值之间的对应关系

 

变量及数据完整性

 

变量及数据时效性

 

变量及数据地址错误等

 

针对不同类型的变量数据，具有不同的失效模式，如下示例：

 

3、时间属性失效分析

 

对于时间属性，主要考虑到如下几点

 

软件功能的执行周期，e.g. 100ms周期或事件触发型；

 

软件功能的执行时间，e.g. 2ms内执行完成；

 

软件功能的执行时序，e.g. 在使能功能完成后，5ms内执行；

 

软件任务优先级， e.g. 安全任务具有更高的优先级要求。

 

一些典型的时序及执行方面的失效模式如下

 

 

 

4、软件对于存储内容操作失效分析

 

针对存储分析主要关注的是软件对存储内容操作过程中存在失效模式，主要考虑到如下几个方面：

 

存储空间分配

 

存储内容写入

 

存储内容读取

 

存储访问权限

 

针对存储操作的典型失效模式如下：

 

5、部署分析

 

软件部署分析主要考虑到如下内容：

 

软件模块对核的依赖

 

软件模块对存储的依赖

 

软件模块对底层及OS的依赖

 

软件模块对内部通讯总线的依赖

 

软件模块对外设资源的依赖

 

软件模块之间的依赖关系

 

典型部署相关失效模式如下：

 

 

 

4.总结

 

车载软件的重要性及复杂性决定了必须对关键软件进行系统化的分析，这是软件安全性与执行的要求。

 

软件与硬件的不同决定了软件FMEA在分析内容、分析重点及失效模式识别上与硬件FMEA会有很大的不同。由于篇幅有限，本文主要对这些不同进行着重的讲解，集中在分析内容、失效模式识别等方面。对于失效原因、失效影响、风险评估、优化措施等方面，会在后续的文章中逐步展开。