1.2 软件功能安全概述

1.2.1 发展概况

嵌入式软件在安全关键系统中的应用，使得保障软件的功能安全成为软件工程领域的研究热点。软件作为系统的重要组成要素，不会直接危及生命、财产和环境等安全，但借助软件实现的人机交互却可能因软件失效造成人员误操作，从而形成危害。对于没有人机交互的嵌入式安全关键系统而言，软件错误地控制系统也可能造成灾难性的后果。以机器人控制软件为例，在软件控制机械臂执行任务时，当控制的距离参数、速度参数溢出时，控制软件需要确保机械臂不会执行该指令，以免造成人身伤害及财产损失。当软件可以引起危害或控制危害的发生时，该软件就是危险的。

软件安全性（Software Safety）一词最早出现在1979年美国发布的MIL-STD-1574A中。1986年，MIT（麻省理工学院）的Leveson 教授提出，软件安全性在系统的生命周期中应该作为一个单独的课题加以重点研究。此后，美国国防部（DoD）、美国国家航空航天局（NASA）、美国联邦航空管理局（FAA）、欧洲航天局（ESA）、英国国防部（MoD）等国防、科研机构及电气与电子工程师协会（IEEE）、国际电工委员会（IEC）、航空无线电技术委员会（RTCA）等标准化组织均对软件功能安全展开了进一步研究，形成了一系列标准、论著、论文等出版物，涉及国防、交通、医疗等多个安全关键领域。

软件的功能安全在近年来得到了广泛的研究，形成了软件安全性工程体系，研究的内容包括软件安全性需求的获取与描述、面向标准的软件开发过程、软件安全需求验证，形成了一系列的软件安全性分析标准、方法及工具。实施软件安全性工程的主要作用如下。

（1）有效地防止系统事故的发生，或者降低事故的严重程度。

预防事故发生和减少损失是开展软件安全性工作的首要任务。通过对系统危险的识别与分析，从软件异常导致事故发生和软件控制事故不发生两个方向入手，分析系统中存在的与事故发生紧密相关的薄弱环节，分析出软件在其中的放大或控制作用，从而开展面向过程及面向产品的软件安全性工作，以便将系统事故发生的概率降低到可以接受的范围内，或者将事故的危害程度降到足够低。

（2）面向全生命周期，权衡软件安全性和成本。

作为软件质量的重要组成部分，确保软件安全性的核心目标之一是降低软件全生命周期成本，提高软件质量。通过开展面向需求、设计、实现、测试评价、使用、维护、退役全生命周期的软件安全性定量分析，权衡提高软件安全性带来的收益及开展软件安全性工作的成本，找到全生命周期最优化解决方案，在可承受的范围内尽可能地防止事故的发生或降低事故的严重程度。

（3）提高安全人员技术水平与安全管理水平。

开展软件安全性工作，提高安全人员技术水平，以及提高协同开发人员与运维人员（软件研发工程师、软件测试工程师、软件质量保证工程师、软件运维工程师等）的安全意识，在生命周期内全面落实安全措施。开展软件安全性活动还有利于提高安全管理水平，形成标准、数据、经验的积累，建立软件安全数据库，为后续软件产品相关安全性指标的制定与安全性需求获取与验证提供数据基础，通过标准的方式固化并贯彻执行。

1.2.2 基本概念

在系统介绍软件功能安全之前，本节先参考GJB 451A—2005 和GJB 900A—2012 及MIL-STD-882D和GEIA-STD-0010等相关标准，给出系统安全的相关定义。安全被定义为不出现可能造成人员伤亡、职业病发作、设备损坏、财产损失或环境损害的状态。该定义是指产品在生命周期内，包括试验、生产和使用等时的状态，即产品在某一时刻是否安全。安全性指产品所具有的不导致人员伤亡、系统毁坏、重大财产损失或不危及人员健康和环境的能力。安全性和安全的概念非常接近，后者更强调产品瞬时的安全状态，而前者强调产品在生命周期内维持安全状态的能力。

简单来说，软件安全性可以被认为是软件所具有的不导致人员伤亡、系统毁坏、重大财产损失或不危及人员健康和环境的能力。然而，由于软件自身不能直接造成安全事故，和产品安全性相比，这个定义难以直指软件安全性的本质。为了强调软件安全性的特性，学术机构、相关学者及标准都提出了软件安全性的定义。例如，在NASA 8719.13A中，软件安全性是指在软件生命周期内，应用安全性工程技术，确保软件采取积极的措施提高系统安全性，确保降低系统安全性的错误已经减少到或控制在一个风险可接受的水平内；Leveson 指出，软件安全性是指确保软件在系统上下文中执行时不会发生不可接受的风险；GJB142—2014则将软件安全性定义为软件具有的不导致事故发生的能力。

与软件安全性较为接近的概念是软件可靠性。在 GJB/Z161—2012 中，软件可靠性被定义为在规定的条件下和规定的时间内，软件不引起系统失效的能力。软件安全性强调软件不引起系统事故发生，而软件可靠性强调软件不引起系统失效。软件安全性和软件可靠性的差别主要有以下3点。

（1）软件安全性不强调量化评估，而软件可靠性强调量化评估。软件可靠性的定义强调了“规定的时间”，即通过在一个时间段内考查软件是否失效来定量衡量软件的可靠性水平，如采用 MTBF（平均故障间隔时间）、R（可靠度）等可靠性参数来衡量。软件安全性则主要采用基于软件安全完整性的分级评估方法来衡量，通常采用安全完整性等级（Safety Integrity Level，SIL）来评价软件安全性，并具体规定具有不同SIL的软件需要在生命周期内开展哪些活动及通过哪些评估才能在工程实践中被认为开发出的软件足够可靠。

（2）软件安全性适用于安全关键场景，而软件可靠性适用范围更广泛。软件安全性聚焦于事故，即可能造成人员伤亡、职业病、设备损坏、财产损失或环境破坏，其应用范围被限定在安全关键领域，如航空、航天、兵器、船舶、核工业、汽车等，分析对象较为明确。软件可靠性聚焦于失效，因此不局限于事故等安全关键场景，分析范围更大，但考虑到开展软件可靠性评估工作成本较高，针对非关键场景开展软件可靠性评估工作有时并不能带来正向收益。

（3）事故并不总是由失效引起的，因此需要在保证软件可靠性的基础上开展软件安全性需求获取与验证工作。软件失效指需求规格说明和软件行为之间的偏离，软件失效是导致系统事故的重要因素。然而，即使软件未发生失效，也可能由于软件安全性需求获取不充分而导致系统事故的发生。例如，飞机控制软件的需求规格说明中未指出飞机起飞后起落架必须收回，则飞机在实际飞行过程中未收回起落架不被认为软件失效，但此时系统存在严重的安全隐患，可能导致重大事故的发生。因此，需要开展软件安全性需求获取工作，获取 “飞机在飞行时起落架必须保持收回状态”等软件安全性需求，并验证该需求实现的正确性、一致性等。

软件安全性和软件信息安全也是一组相近的概念。两者的主要区别在于，软件安全性主要考查软件功能是否能可靠实现，而软件信息安全主要考查软件是否能抵御入侵者的攻击，包括后门攻击、流量攻击、信息窃取、木马攻击等。实际上，由于软件安全性涉及对安全关键功能、指令、数据的防护，而软件信息安全涉及对功能、指令、数据的入侵、窃取和破坏，因此保障软件信息安全也是保证软件安全性不可缺少的一环。当然，我们也需要权衡软件安全性和软件信息安全之间的关系。例如，对多个不同来源的关键指令采用表决机制检查其一致性可以有效保障软件的安全性，但源于多系统的数据融合也容易带来软件信息安全问题。

1.2.3 工作内容

开展软件安全性相关工作主要遵循验证和确认（Validation＆Verification，V＆V）瀑布式开发流程，在每个主要阶段，如系统需求分析与设计阶段、软件需求分析阶段、软件设计阶段、软件实现阶段、软件测试阶段，开展软件安全性相关工作。主要工作思路是，识别出可能导致系统严重事故发生的软件作为软件安全性分析对象，在考虑系统已经采取的安全措施的基础上，通过编制软件安全性计划的方式，在软件生命周期中考虑如何保障软件安全性，开展软件安全性分析、评估、验证等工作，确保软件足够安全并最终形成软件足够安全的结论。

在软件生命周期中的各个阶段开展的软件安全性相关工作如下。

（1）在系统需求分析与设计阶段，开展软件安全性等级确定及软件安全性计划编制两项工作。

软件安全性等级确定工作首先需要确定软件是否为安全关键软件。如果是，则需要确定软件安全性等级，并对具有不同安全性等级的软件选用不同的安全性方法和管理措施，以保障软件满足不同的安全性要求。一般来说，当系统/子系统被确认为安全关键系统后，需要对该系统/子系统内的所有软件进行分析。可以从以下方面确认安全关键软件：①软件实现或控制了系统的安全关键功能；②软件能够导致或控制危险的发生；③软件用于处理安全关键场景的数据和指令，这些数据和指令可能会导致其他系统出现安全事故或导致决策错误并造成严重后果；④软件用于检测系统的安全状态，具备告警功能；⑤和其他安全关键软件在同一分区内，无法彻底屏蔽级联失效的其他软件。

软件安全性计划编制工作能够从技术和管理的角度，保障软件中的风险被充分地识别、处理和规避，并为这些技术的落实提供管理支持，为后续时间、人员、资源、成本等的分配提供依据。软件安全性计划应包括：①软件安全性工作要求，如组织结构、活动项（分析对象、分析与测试验证技术等）、执行方式、预期进度，以及与软件工程、软件可靠性工程、系统安全性工程的关系等；②软件安全性管理要求，如软件安全性工作的审查节点、审查人员、审查方式、审查通过判据等；③在软件需求、使用方式与预期存在较大偏差，或者软件经过了迭代修改时，应及时修改软件安全性计划。

（2）在软件需求分析阶段，开展软件安全性需求获取工作及软件安全性需求验证工作。

软件安全性需求获取工作主要以工程经验、相关标准、分析人员经验、历史事故报告、系统安全性需求、系统危险分析等作为输入，凝练、提取软件安全性需求，以保证软件安全性需求的正确性、充分性、一致性等相关属性。尤其是软件安全性需求的充分性容易被遗漏，必须通过软件安全性需求获取工作保证软件需求规格说明的安全性。软件安全性需求获取工作应保证：①不允许单个功能或操作触发潜在的危险；②充分识别安全相关的软件需求，包括软件在某种模式或状态下“必须”执行的操作或保持的状态，以及“禁止”执行的操作或触发的状态；③当可能导致事故发生的失效出现时，软件应能使系统进入安全状态，即失效安全（Fail-Safe）状态；④软件安全性需求应具有双向可追踪性，具有唯一标识，做到描述准确、可测试、可验证。

软件安全性需求验证工作以软件安全性需求作为验证对象，主要验证软件安全性需求的正确性、充分性和一致性等属性，从而发现软件需求中存在的前后矛盾、描述不清晰、安全关键功能未定义等问题，并发现新的软件安全性需求问题，提升软件安全性需求质量。软件安全性需求验证工作应保证：①对潜在的失效进行考虑，并提出明确的失效缓解措施，如失效安全机制、关键指令保护、关键决策表决、对时序约束的检查与保护、对失效的冗余措施等；②对系统应处于的状态进行严格的限制和约束，以防止系统由于触发了非预期事件处于非预期状态，进而引发潜在的事故；③对软件安全性需求的正确性、充分性和一致性进行检查；④保证软件安全性需求的可追溯性。

（3）在软件设计阶段，开展软件安全性设计和验证工作。

软件安全性设计工作主要用于发现软件设计阶段新的危险源，将软件安全性需求进一步细化到模块和组件上，并采用一系列工程技术满足软件设计的安全性。软件安全性设计工作主要包括：①进一步细化需求阶段的软件安全性分析，开展软件故障树分析（SFTA）、软件失效模式和影响分析（SFMEA）、数据流分析、信息流分析、软件复杂网络分析等工作；②将细化的软件安全性需求分配到模块和组件上，并对安全关键模块或组件进行标识；③制定软件安全性准则，并依据软件安全性准则开展软件安全性设计工作。

软件安全性设计验证工作主要用于确保软件安全性设计实现的正确性、充分性和无二义性。软件安全性设计验证工作主要包括：①验证软件安全性设计是否正确实现；②保障软件在运行中处于安全状态，以及出现失效时软件可以将系统置于安全状态；③确保软件在失效时可以被物理隔离或逻辑隔离，防止级联失效的出现。

（4）在软件实现阶段，开展代码安全性分析验证工作。

代码安全性分析验证工作主要面向代码编写规范、编码检查单等，验证代码实现与安全性需求、设计的一致性。代码安全性分析验证工作主要包括：①代码实现功能与需求、设计的可追踪性，保证所有需求项和设计项已实现，并且未引入额外的功能；②开发时遵守代码编写规范，按编码检查单进行开发，如遵守 MISRA C 开发标准等；③代码实现没有引入额外的危险。

（5）在软件测试阶段，开展软件安全性测试验证工作。

软件安全性测试验证工作主要用于验证是否所有软件安全性需求都被正确实现，以及在异常情况下和临界情况下软件能否维持在安全运行状态并保证软件安全性测试的充分性。软件安全性测试验证工作主要包括：①所有可识别的危险都已经消除，或者影响处于可接受的范围内；②软件在硬件异常输入、人员异常操作、通信错误等异常情况下仍能使系统安全运行；③在测试阶段发现的问题，必须修改后进行问题归零，并采用回归测试的方式保证问题修复过程未引入更多的缺陷；④满足测试覆盖率要求，所有安全性功能得到了正确的执行。