软件FMEA：智能车载软件安全及质量守门员

1、标准法规的要求

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

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

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

2、复杂系统的生存必须

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

• 5000万行以上代码量

• 100+个功能模块

• 2000+个数据接口

• 50+种实时任务调度

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

3、开发过程的本质需求

Figure 1软件问题的来源

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

Figure 2软件问题分类

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

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

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

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

1、软硬件FMEA的差异

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

• 识别分析对象

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

• 识别失效模式

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

• 分析的颗粒度

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

3、软件FMEA的分析时机

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

•   软件架构级别FMEA

•   软件详细设计级别FMEA

4、软件FMEA分析哪些内容

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

• 功能及逻辑

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

• 变量及数据

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

• 时间属性

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

• 软件对存储的操作

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

• 软件部署

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

1、软件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的依赖

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

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

• 软件模块之间的依赖关系

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