#十讲软件的安全性分析
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
施
软硬件综合FMEA分析方法的特点
软硬件综合FMEA分析方法的特点是以计算机软件的控
制流程图为线索，对系统进行功能和结构分解，进行更 深层次的分析
常规FMEA分析方法通常是在硬件（例如电路）的详细
设计完成后，利用归纳法从底向上，逐级上推，跟踪分 析底层元器件失效模式对系统的最终影响。
软硬件综合FMEA分析方法的一个基本依据是软件的需
失效纠正措施 关键作用的原因：
硬件故障，解决方法：
提高测速器和传感器及微处 理器的可靠性
测速器和传感器故障
微处理器存储器故障
软件单元1设计错误
用
美国军标MIL-STD-882B将软件系统的安全性工作归结
为如下的九项：
确定系统及系统中软件的安全性要求
将系统安全性说明中的要求准确转化为系统或分系统说
明的要求，转化为软件需求说明的要求，并将这些要求 在软件设计和编码中实现
在系统，分系统说明及软件需求说明中确定当可能发生
安全事故时的系统决策，这些决策包括失效安全，失效 降级使用，失效容错使用等
求说明
由于软硬件综合FMEA分析是将软件和受控的硬件作为
一个整体进行分析，所以容易考察硬件和软件的相互作 用。
例子
嵌入式发动机测速软在速件度正控常时制被作流为 程图 不正常值写到维护记
录中；在速度不正常
软件单元1
时没有作出记录。
否
软件单元2
软件单元3
在维修记录中 写入并报警
检查发动机的速度
入或输出时序，多重事件，错误事件，失序事件， 恶劣事件，死锁及输入数据错误的反映和敏感性
考察程序、模块或单元中是否存在影响安全性的
编程错误
考察安全关键单元是否符合系统说明、分系统说
明和软件需求说明中提出的安全性对策，这种考 察必须在源程序和目标程序中进行
考察软件安全关键单元的安全性设计要求的实现情况， 确保达到所要求的目标，确保硬件和其它模块的失效 不致影响软件的安全性特征
讲软件的安全性分析
内容
概述 软件系统的安全性分析 软件失效效应模式分析 软件故障树分析方法 其它分析方法
1 概述
美国的反射治疗机软件错误，五名患者受超剂量
辐射死亡
美国血液数据库程序出错，致使被AIDS污染的
血液被用于治疗
军用设备和核反应堆…… ……
软件的安全问题主要起源于软件设计 对实际工作情况缺乏了解 对系统工作状况所作的错误假设 需求说明不清楚 …… 软件安全性是一种特殊的可靠性 软件可靠性的避错，查错和容错设计技术同样适
将控制功能流程图中的每一个单元，等同于硬件系统中
的一个元件
按照常规FMEA分析方法的原则，分析各个单元的各种
失效模式。但是与硬件的失效模式分析的区别是，分析 时必须详细研究软件的各种可能的失效模式
分析每一个失效模式的影响，分析失效模式影响的严重
程度
将分析的结果，填写入FMEA分析表格 区分各种失效模式的严重程度，有针对性地提出纠正措
在低结构层次上考察软件的各个单元、模块、表
和变量之间的相关程度，将直接和间接影响软件 安全关键单元的其它单元确定为安全关键单元， 分析它们对安全的影响
分析软件安全关键单元的详细设计是否符合安全性设 计的要求，分析的结果应该送给软件设计人员和项目 主管
确定在测试计划、说明和规程中需要包含的安全性要 求
确显示
2.7 软件更改危险分析
分析系统，分系统接口，逻辑和其它设计更改对安全 性的影响，确保这些更改不会产生新的危险，不会触 发已经消除的危险，不会使现存的危险变得更严重， 不会对有关的设计和程序产生任何有害的危害
对更改进行测试，确保更改后的软件不包含危险事件 确保软件的更改已经在编程中准确的实现 评审和修改有关文档，以反映这些更改 将执行软件更改危险分析的方法和程序纳入软件配置
以保证这些软件在系统中安全运行 确保在系统综合测试和系统验收测试中所发现的危险事件得到了
纠正，确保对这些事件进行了重新测试，没有遗留问题
2.6 软件与用户接口危险性分析
提供检测危险征兆或潜在危险状态的方法，预防安全事故的发生 控制危险事件，使其只有在特殊的情况下和操作员特定的命令下
才可能发生 向操作员、用户和其它人员提供报警功能，指示可能出现或正在
时序分配图表以及其它的程序文档
2.2 概要设计危险分析
分析的结果将交给初步设计评审 从软件的危险表出发，分析其中的危险事件与软
件的组成单元之间的关系，并将这些危险事件有 关的软件单元确定为软件安全关键单元
检查软件。确定软件的各个单元、模块、表、变
量之间是否相关，确定相关的程度，凡是对软件 安全性单元有直接和间接影响的其它单元，也要 确定为软件安全关键单元，并且分析它们对安全 的影响
gearbox
gearbox controller
FMEA报告: 速度传感器
组件
失效模 式
局部效果 系统效果
危害
Speed sensor
Breaks
Speed calculated as zero
1. Speedometer shows zero 2. Odometer(里 程表) not updated 3. Wrong gear selected
分析软件安全关键单元的概要设计是否符合安全
性的要求，分析的结果应送交给软件设计人员和
2.3 详细设计危险分析
安排在初步评审之后，软件编码之前，分析的结
果交给关键设计评审
依据需求危险分析，概要设计危险分析确定的危
险事件，分析这些事件与低层次的软件单元的关 系，将对危险事件有影响的单元确定为软件安全 关键单元，分析这些单元对危险事件影响的方式 和途径
检查速度允许范围
IF
软件读入错误的速度输入数据； 没有输入数据供软件读入；
软件不能正确读取或处理输入的 数据；
是 软件单元4
输出至发动机 模块
速度在容限内被判为超限； 速度在容限外被判为正常 在速度正常时没有数据输入发动
机监控装置 在速度不正常时被误认为正确的 输入发动机监控装置
失效原因分析 来自软件单元1的从属失效； 本单元软件设计的接收数据等待 时间短于测速器数据测量和传输 时间
软件单元1
否 软件单元2
软件单元3
在维修记录中 写入并报警
检查发动机的速度
检查速度允许范围
IF
测速器和传感器故障； 微处理器存储器故障； 程序设计上的错误；
是 功能和逻辑都很简单，因此本单
元的失效都是来自于软件单元1 的从属失效
软件单元4
输出至发动机 模块
功能和结构简单，失效原因不可 能出自软件单元内部，而是单元 1、单元2导致的从属失效
确定软件系统中的安全关键单元，安全关键单元是指那
些对系统安全性有关键性影响的程序、分程序和模块
对软件的安全关键单元进行分析
通过分析、验证、确保软件系统安全性要求的实现， 验证不存在有损于安全性的单个或多个失效事件，保 证系统的安全性要求不致引起新的危险
确保编制出的程序不会因为触发危险功能，或阻碍正 常的功能的执行而使系统处于危险状态
使系统在危险状态下运行，并考察硬件或软件失效、 单个或多重事件，失序事件，程序的非正常转移对安 全性的影响
考察超界、过载输入对安全性的影响
评审正在制订的软件文档、确保这些文档包含了软件 的安全性要求
2.5 软件安全性测试
对安全关键单元进行安全性测试，保证使危险事件发生的可能性 降低到可以接受的水平
出现的潜在危险 当危险事件发生后，确保系统能够生存 当预防和控制危险的规程失败后，或危险事件发生时，能提供控
制损害程度的规程和恢复到安全状态的规程 提供在严重危险状态下使系统生存和恢复功能的规程 具有安全终止某个事件和安全终止程序运行的能力 具有向操作员提供系统或软件失效的报警功能 具有向操作员提供安全性决策所需的信息，确保危险数据能够明
管理计划
3 软件失效模式效应分析
失效模式效应分析FMEA 传统的系统可靠性，安全性分析方法 增加危害度分析的内容，称为失效模式，效应及
危害度分析，简称为FMECA
3.1 FMEA 的例子: 速度传感器
toothed wheel
signal processing unit
sensor
仪表盘
向测试人员提供软件安全关键单元的安全性测试案例 确保所有的软件安全关键单元按预定的测试方案进行安全性测试，
准确地记录测试的结果 除了在正常状态下进行的测试外，还要在异常的环境和异常的输
入状态下测试软件，确保软件在这些状态下仍能安全运行 进行软件强度测试，确保软件安全运行 确保外购软件安全运行 订购方所提供的软件，不管是否进行了修改，都需要进行测试，
用途，系统的约束条件和失效判据等
2. 危险分析
在危险分析中，主要任务是找出对系统功能和安
全性影响较大的危险事件，确定软件的不安全模 式。对这些危险事件的出现有直接或间接关系的 单元称为安全关键单元。
建立危险事件及其发生原因联系
危险事件1
Hale Waihona Puke Baidu
原因1 原因2 ……
分原因1
分原因2
安全关键单元
分原因3
1. Driver mislead, ... 2. Maintenance delayed, ... 3. Engine seizes at high speed, ...
3.2 FMEA 特点
失效模式和影响分析 方法: 从组件的已知的或者预测的失效模
式，确定对系统可能的效果
比较有利于在开发早期识别系统的危险: loss of function (omission failure) function performed incorrectly function performed when not
安全性构成严重威胁
嵌入式计算机硬件和软件的可靠性是相互联系、相互制
约的
必须将系统反应时间是否符合规定的要求作为嵌入式实
时计算机控制系统的失效判据
由于开发环境相对不够完善，软件的可靠性较难保证
软硬件综合FMEA分析方法的步骤
根据系统的功能和软件的需求说明，绘制出软件或软件
单元的控制功能的流程图
利用系统初步危险分析的结果，初步确定软件的
安全关键单元。要点为：
建立软件安全性需求的跟踪系统，记录每个需求
的实现情况
从安全性的角度评审系统说明和分系统说明，评
审软件需求说明，接口说明，以及其它有关系统 方案和要求等文件
将系统安全性的要求分配到软件 由系统的初步危险表导出软件的危险表 分析功能流程图、编程语言、数据流图、存储和
确定在系统操作员手册、软件用户手册、系统诊断手 册及其它手册中需要包含的安全性要求
确保编程人员了解安全关键单元，向编程人员提供有 关安全性的编程建议和要求
2.4 软件编程危险分析
考察软件的安全关键单元以及其它单元的源程序
和目标程序是否实现了安全性设计的要求，该工 作与编程同时进行
考察软件安全关键单元的正确性，考察它们对输
保证对系统进行充分的安全性测试，包括失效事件发 生的测试
2. 软件系统安全性分析
MIL-STD-882B规定软件的安全性分析包括 软件需求危险分析 概要设计危险分析 详细设计危险分析 软件编程危险分析 软件安全性测试 软件与用户接口危险分析 软件更改危险分析
2.1 软件需求危险分析
……
危险事件n
原因1 原因2 ……
分原因n
3.结构分解及分层次定义 按功能分解 按软件系统结构特征分解 按软件工作模式分解 4.失效模式分析 填写失效模式分析表格并进行危害度分析及提出
改进、纠正措施
3.4 嵌入式软件的FMEA分析方法
嵌入式计算机控制系统特征 系统的软硬件配置与通用系统不同 系统设计：硬件与软件必须同步进行 使用的语言 嵌入式计算机软件的可靠性特征 与安全关键任务有关的嵌入式软件，对系统的可靠性与
required (commission failure)
3.3 软件FMEA方法
软件与硬件具有相似性，但是又存在若干重要差
别，例如软件的执行是串行的
软件FMEA中的失效模式、影响和严重性分类方
法，可参考相关的资料，例如IEEE失效模式分 类方法
1. 系统定义
在系统定义中应说明系统的主要功能和次要功能，
软硬件综合FMEA分析方法的特点
软硬件综合FMEA分析方法的特点是以计算机软件的控
制流程图为线索，对系统进行功能和结构分解，进行更 深层次的分析
常规FMEA分析方法通常是在硬件（例如电路）的详细
设计完成后，利用归纳法从底向上，逐级上推，跟踪分 析底层元器件失效模式对系统的最终影响。
软硬件综合FMEA分析方法的一个基本依据是软件的需
失效纠正措施 关键作用的原因：
硬件故障，解决方法：
提高测速器和传感器及微处 理器的可靠性
测速器和传感器故障
微处理器存储器故障
软件单元1设计错误
用
美国军标MIL-STD-882B将软件系统的安全性工作归结
为如下的九项：
确定系统及系统中软件的安全性要求
将系统安全性说明中的要求准确转化为系统或分系统说
明的要求，转化为软件需求说明的要求，并将这些要求 在软件设计和编码中实现
在系统，分系统说明及软件需求说明中确定当可能发生
安全事故时的系统决策，这些决策包括失效安全，失效 降级使用，失效容错使用等
求说明
由于软硬件综合FMEA分析是将软件和受控的硬件作为
一个整体进行分析，所以容易考察硬件和软件的相互作 用。
例子
嵌入式发动机测速软在速件度正控常时制被作流为 程图 不正常值写到维护记
录中；在速度不正常
软件单元1
时没有作出记录。
否
软件单元2
软件单元3
在维修记录中 写入并报警
检查发动机的速度
入或输出时序，多重事件，错误事件，失序事件， 恶劣事件，死锁及输入数据错误的反映和敏感性
考察程序、模块或单元中是否存在影响安全性的
编程错误
考察安全关键单元是否符合系统说明、分系统说
明和软件需求说明中提出的安全性对策，这种考 察必须在源程序和目标程序中进行
考察软件安全关键单元的安全性设计要求的实现情况， 确保达到所要求的目标，确保硬件和其它模块的失效 不致影响软件的安全性特征
讲软件的安全性分析
内容
概述 软件系统的安全性分析 软件失效效应模式分析 软件故障树分析方法 其它分析方法
1 概述
美国的反射治疗机软件错误，五名患者受超剂量
辐射死亡
美国血液数据库程序出错，致使被AIDS污染的
血液被用于治疗
军用设备和核反应堆…… ……
软件的安全问题主要起源于软件设计 对实际工作情况缺乏了解 对系统工作状况所作的错误假设 需求说明不清楚 …… 软件安全性是一种特殊的可靠性 软件可靠性的避错，查错和容错设计技术同样适
将控制功能流程图中的每一个单元，等同于硬件系统中
的一个元件
按照常规FMEA分析方法的原则，分析各个单元的各种
失效模式。但是与硬件的失效模式分析的区别是，分析 时必须详细研究软件的各种可能的失效模式
分析每一个失效模式的影响，分析失效模式影响的严重
程度
将分析的结果，填写入FMEA分析表格 区分各种失效模式的严重程度，有针对性地提出纠正措
在低结构层次上考察软件的各个单元、模块、表
和变量之间的相关程度，将直接和间接影响软件 安全关键单元的其它单元确定为安全关键单元， 分析它们对安全的影响
分析软件安全关键单元的详细设计是否符合安全性设 计的要求，分析的结果应该送给软件设计人员和项目 主管
确定在测试计划、说明和规程中需要包含的安全性要 求
确显示
2.7 软件更改危险分析
分析系统，分系统接口，逻辑和其它设计更改对安全 性的影响，确保这些更改不会产生新的危险，不会触 发已经消除的危险，不会使现存的危险变得更严重， 不会对有关的设计和程序产生任何有害的危害
对更改进行测试，确保更改后的软件不包含危险事件 确保软件的更改已经在编程中准确的实现 评审和修改有关文档，以反映这些更改 将执行软件更改危险分析的方法和程序纳入软件配置
以保证这些软件在系统中安全运行 确保在系统综合测试和系统验收测试中所发现的危险事件得到了
纠正，确保对这些事件进行了重新测试，没有遗留问题
2.6 软件与用户接口危险性分析
提供检测危险征兆或潜在危险状态的方法，预防安全事故的发生 控制危险事件，使其只有在特殊的情况下和操作员特定的命令下
才可能发生 向操作员、用户和其它人员提供报警功能，指示可能出现或正在
时序分配图表以及其它的程序文档
2.2 概要设计危险分析
分析的结果将交给初步设计评审 从软件的危险表出发，分析其中的危险事件与软
件的组成单元之间的关系，并将这些危险事件有 关的软件单元确定为软件安全关键单元
检查软件。确定软件的各个单元、模块、表、变
量之间是否相关，确定相关的程度，凡是对软件 安全性单元有直接和间接影响的其它单元，也要 确定为软件安全关键单元，并且分析它们对安全 的影响
gearbox
gearbox controller
FMEA报告: 速度传感器
组件
失效模 式
局部效果 系统效果
危害
Speed sensor
Breaks
Speed calculated as zero
1. Speedometer shows zero 2. Odometer(里 程表) not updated 3. Wrong gear selected
分析软件安全关键单元的概要设计是否符合安全
性的要求，分析的结果应送交给软件设计人员和
2.3 详细设计危险分析
安排在初步评审之后，软件编码之前，分析的结
果交给关键设计评审
依据需求危险分析，概要设计危险分析确定的危
险事件，分析这些事件与低层次的软件单元的关 系，将对危险事件有影响的单元确定为软件安全 关键单元，分析这些单元对危险事件影响的方式 和途径
检查速度允许范围
IF
软件读入错误的速度输入数据； 没有输入数据供软件读入；
软件不能正确读取或处理输入的 数据；
是 软件单元4
输出至发动机 模块
速度在容限内被判为超限； 速度在容限外被判为正常 在速度正常时没有数据输入发动
机监控装置 在速度不正常时被误认为正确的 输入发动机监控装置
失效原因分析 来自软件单元1的从属失效； 本单元软件设计的接收数据等待 时间短于测速器数据测量和传输 时间
软件单元1
否 软件单元2
软件单元3
在维修记录中 写入并报警
检查发动机的速度
检查速度允许范围
IF
测速器和传感器故障； 微处理器存储器故障； 程序设计上的错误；
是 功能和逻辑都很简单，因此本单
元的失效都是来自于软件单元1 的从属失效
软件单元4
输出至发动机 模块
功能和结构简单，失效原因不可 能出自软件单元内部，而是单元 1、单元2导致的从属失效
确定软件系统中的安全关键单元，安全关键单元是指那
些对系统安全性有关键性影响的程序、分程序和模块
对软件的安全关键单元进行分析
通过分析、验证、确保软件系统安全性要求的实现， 验证不存在有损于安全性的单个或多个失效事件，保 证系统的安全性要求不致引起新的危险
确保编制出的程序不会因为触发危险功能，或阻碍正 常的功能的执行而使系统处于危险状态
使系统在危险状态下运行，并考察硬件或软件失效、 单个或多重事件，失序事件，程序的非正常转移对安 全性的影响
考察超界、过载输入对安全性的影响
评审正在制订的软件文档、确保这些文档包含了软件 的安全性要求
2.5 软件安全性测试
对安全关键单元进行安全性测试，保证使危险事件发生的可能性 降低到可以接受的水平
出现的潜在危险 当危险事件发生后，确保系统能够生存 当预防和控制危险的规程失败后，或危险事件发生时，能提供控
制损害程度的规程和恢复到安全状态的规程 提供在严重危险状态下使系统生存和恢复功能的规程 具有安全终止某个事件和安全终止程序运行的能力 具有向操作员提供系统或软件失效的报警功能 具有向操作员提供安全性决策所需的信息，确保危险数据能够明
管理计划
3 软件失效模式效应分析
失效模式效应分析FMEA 传统的系统可靠性，安全性分析方法 增加危害度分析的内容，称为失效模式，效应及
危害度分析，简称为FMECA
3.1 FMEA 的例子: 速度传感器
toothed wheel
signal processing unit
sensor
仪表盘
向测试人员提供软件安全关键单元的安全性测试案例 确保所有的软件安全关键单元按预定的测试方案进行安全性测试，
准确地记录测试的结果 除了在正常状态下进行的测试外，还要在异常的环境和异常的输
入状态下测试软件，确保软件在这些状态下仍能安全运行 进行软件强度测试，确保软件安全运行 确保外购软件安全运行 订购方所提供的软件，不管是否进行了修改，都需要进行测试，
用途，系统的约束条件和失效判据等
2. 危险分析
在危险分析中，主要任务是找出对系统功能和安
全性影响较大的危险事件，确定软件的不安全模 式。对这些危险事件的出现有直接或间接关系的 单元称为安全关键单元。
建立危险事件及其发生原因联系
危险事件1
Hale Waihona Puke Baidu
原因1 原因2 ……
分原因1
分原因2
安全关键单元
分原因3
1. Driver mislead, ... 2. Maintenance delayed, ... 3. Engine seizes at high speed, ...
3.2 FMEA 特点
失效模式和影响分析 方法: 从组件的已知的或者预测的失效模
式，确定对系统可能的效果
比较有利于在开发早期识别系统的危险: loss of function (omission failure) function performed incorrectly function performed when not
安全性构成严重威胁
嵌入式计算机硬件和软件的可靠性是相互联系、相互制
约的
必须将系统反应时间是否符合规定的要求作为嵌入式实
时计算机控制系统的失效判据
由于开发环境相对不够完善，软件的可靠性较难保证
软硬件综合FMEA分析方法的步骤
根据系统的功能和软件的需求说明，绘制出软件或软件
单元的控制功能的流程图
利用系统初步危险分析的结果，初步确定软件的
安全关键单元。要点为：
建立软件安全性需求的跟踪系统，记录每个需求
的实现情况
从安全性的角度评审系统说明和分系统说明，评
审软件需求说明，接口说明，以及其它有关系统 方案和要求等文件
将系统安全性的要求分配到软件 由系统的初步危险表导出软件的危险表 分析功能流程图、编程语言、数据流图、存储和
确定在系统操作员手册、软件用户手册、系统诊断手 册及其它手册中需要包含的安全性要求
确保编程人员了解安全关键单元，向编程人员提供有 关安全性的编程建议和要求
2.4 软件编程危险分析
考察软件的安全关键单元以及其它单元的源程序
和目标程序是否实现了安全性设计的要求，该工 作与编程同时进行
考察软件安全关键单元的正确性，考察它们对输
保证对系统进行充分的安全性测试，包括失效事件发 生的测试
2. 软件系统安全性分析
MIL-STD-882B规定软件的安全性分析包括 软件需求危险分析 概要设计危险分析 详细设计危险分析 软件编程危险分析 软件安全性测试 软件与用户接口危险分析 软件更改危险分析
2.1 软件需求危险分析
……
危险事件n
原因1 原因2 ……
分原因n
3.结构分解及分层次定义 按功能分解 按软件系统结构特征分解 按软件工作模式分解 4.失效模式分析 填写失效模式分析表格并进行危害度分析及提出
改进、纠正措施
3.4 嵌入式软件的FMEA分析方法
嵌入式计算机控制系统特征 系统的软硬件配置与通用系统不同 系统设计：硬件与软件必须同步进行 使用的语言 嵌入式计算机软件的可靠性特征 与安全关键任务有关的嵌入式软件，对系统的可靠性与
required (commission failure)
3.3 软件FMEA方法
软件与硬件具有相似性，但是又存在若干重要差
别，例如软件的执行是串行的
软件FMEA中的失效模式、影响和严重性分类方
法，可参考相关的资料，例如IEEE失效模式分 类方法
1. 系统定义
在系统定义中应说明系统的主要功能和次要功能，