软件功能安全

由于其不可测试性，因此无法证明软件的安全性，而是在过去使用相对简单的逻辑，使用安全继电器等实现。

然而，鉴于软件为系统带来的灵活性和强大功能，它在安全方面的使用是不可避免的。随着IEC 61508-3等新标准的出现，设计人员可以通过遵循过去已被证明可以提供安全软件的一组技术来证明他们的软件足够安全。

图2 - 软件的强大功能

使软件与硬件不同的因素包括：

软件不会录制，所以通常没有硬性截止日期（换句话说，“一个项目如何迟到一年——一次一天”——布鲁克斯·劳）

功能可以在发布后添加 - “他们查看了该软件并发现它很好。但他们必须有这个功能......“——归功于麦考密克·

软件几乎可以做任何事情，并且经常被要求 - “灵活性的诅咒”

软件在硬件上运行

虽然软件不会磨损，也不会像硬件那样出现随机故障，但它可能包含系统错误。系统误差是只能通过设计更改（即更改代码）来消除的错误。系统误差始终存在，但仅在出现一组特定条件时才暴露出来。硬件可靠性使用传统的可靠性方法，并基于概率。您可以尝试对软件使用概率，但软件失败的概率为 1;当出现暴露错误的适当条件时。

每 1，000 LOC（代码行）的错误数估计值各不相同，但对于良好的代码，估计值通常在 1 到 10 EPTLOC（每千行代码的错误）范围内。Addison-Wesley的《软件评估、基准和最佳实践》一书给出了各种CMM（能力成熟度模型）级别的数字，如1-7级EPTLOC，2-6级EPTLOC，3级-5 EPTLOC，4级-2 EPTLOC，5级-1 EPTLOC。而其他数据源给出的办公应用程序每 1，000 行代码的速率值为 7，工业应用程序为 2，航天飞机应用程序为 0.1。所有这些都显示了使软件安全的挑战。

“软件安全入门”一书描述了5种类型的软件错误，并估计60%的错误与规范和设计有关，40%与编码有关。

规范错误 – 某些功能被省略，因为它没有记录在需求中

设计错误 – 使用不正确的算法，缺乏自检......

编码错误 – 无限循环、语法错误....

硬件引起的错误 – 例如闪存中的位翻转更改指令

接口错误 – 与软件硬件接口相关的问题

那么，安全标准怎么说。他们提倡一组方法和过程，旨在减少在代码中引入未检测到的错误的机会。下面的生命周期模型是由IEC 61508：2010倡导的，我将在以后的博客中回到它。这个过程是整体的，从需求到架构到设计，最终到编码，验证和确认步骤与每个阶段相匹配。

图 3 - 符合 IEC 61508-3：2010 的软件 V 型号

通常，与非安全领域倡导的良好软件开发实践相比，功能安全标准倡导的流程是严格的。

主要差距与以下方面有关

独立安全评估

刀具认证

与特定类型的分析相关的非常具体的安全要求，例如需要进行故障树分析或FMEDA

而诸如此类的任务

配置管理

软件规划

编码

功能测试

被标准的非安全高质量开发流程很好地覆盖。

无论您正在开发的领域如何，都值得一读的软件标准的功能安全性包括

IEC 61508-3：2010 – 软件共识标准的主要非部门特定功能安全

D0-178C – 航空电子软件安全标准

EN 50128 – 铁路软件标准

ISO 26262-6：2011 – 汽车功能安全软件标准

IEC 62304 – 医疗设备软件

IEC 60880 – 核软件安全

UL 1998 – 家用电器软件的美国标准

虽然上述每个标准的最终域都不同，但每个标准的意图是相同的，并且在一个标准中描述不好的内容在另一个标准中通常描述得更好。

审核编辑：郭婷