功能安全之已有软件(pre-existing)要求

安全关键软件开发过程中，复用已有软件（pre-existing software）是一个必然面对的问题，很少有安全系统的软件是从零做起的。典型的已有软件有RTOS操作系统、BSP板级支持包、通信协议栈、第三方函数库等，可以分为三种类型：

1. 来自于外部供应商的商业货架软件（COTS）；

2. 开源软件；

3. 公司内部以前项目开发的软件。

第三种情况复用以往项目开发的软件是比较容易处理的，可以按照功能安全软件开发的要求补充文件，按照软件开发的技术要求修改，以符合认证要求。比较难处理的第一和第二种情况，外部供应商提供的软件不符合认证的要求，使用的开源代码完全没有开发文档，如何对待这两类已有软件以符合功能安全标准要求呢？

在说明如何使已有软件满足认证要求前，纠正很多人的一个错误认识：复用已有软件很安全，软件隐藏的雷都被前人趟过了，只要集成到我的代码里使用就行，剩下就是补文件的事，交给公司负责认证的人就好了。

已有软件作为安全关键软件的组成部分，必须与其它软件一样慎重对待，满足认证符合性的要求，不仅是为了取得证书，获得信心，更是让软件更容易持续地改进和维护。

历史上已有一些由于不合适的软件复用导致了严重事故：

1.阿丽亚娜5号火箭爆炸事故

1996年阿丽亚娜5号火箭升空后爆炸，事后分析原因时发现，火箭的一段控制程序主动惯性参考系统（SRI）软件异常，执行从64位浮点到16位有符号整数位值转换时引起，转换后的浮点数大于16位所能表示的值，导致软件异常。这段软件代码复用了阿丽亚娜4号的相同代码，在审查阿丽亚娜4号的代码，分析这个变量收到的数据无论如何不会超过16位，但当这段代码复用到阿丽亚娜5上面，由于4号和5号的火箭发射特性不同，在5号火箭上加速度值输入到程序计算模块后造成溢出。该缺陷为软件系统性失效，主用和备用系统使用的这部分软件是相同的，因此出现了相同的问题。在这个事故中，复用已有软件未能检查出软件运行外部约束的变化，导致的软件缺陷引起了严重的事故后果。

阿丽亚娜火箭爆炸

2.Therac-25过量辐射事故
Therac-25是加拿大AECL公司开发的计算机控制放射治疗机，它的软件中存在一个严重缺陷，导致给患者过量的辐射导致患者死亡，该软件复用了以前型号Therac-20的相同代码，而在以前的型号中有硬件联锁防止该类故障，但Therac-25去掉了硬件安全机制，仅依赖于软件检查的安全性。这个事故中，已有软件缺陷在以往系统中被掩盖，系统变更后暴露出来造成安全事故。

Therac-25软件缺陷原因分析

不同行业的经验教训告诉我们，不能假设已有软件的安全性。因为这个软件已经被广泛使用，就认为它是安全的，这是一种非常天真的想法。在新的安全系统中重用已有软件，由于软件的运行环境、接口、需求规格等差异，它的安全性需要重新审视。

因此，不同行业的功能安全标准均对已有软件应用于安全关键系统给出了审查要求，下面列举了IEC61508，EN50128和ISO26262这三个标准对已有软件的安全要求

IEC61508-3

在功能安全通用标准IEC61508-3软件要求中的7.4.2.12条款，已有软件被复用实现全部或部分安全功能时，应满足a)和b)两项要求：

a) 满足以下三条符合性路线其中之一：

——路线1：该软件完全符合IEC61508-3的开发；

——路线2：经使用证明。提供软件已被应用的证明。（IEC61508-2 7.4.10）

——路线3：非符合性开发评估。（IEC61508-2 7.4.2.13）

以上三种符合性路线中，路线1要求已有软件完全按照功能安全标准的全部过程和技术要求来做，常见的方式是复用已经通过认证的安全软件组件，例如使用了符合IEC61508 SIL3级要求的RTOS操作系统，或符合EN50128和EN50159要求的安全协议栈。

路线2需要提供该软件在其它类似产品和项目中应用的服役历史证明。

路线3要求已有软件满足IEC61508-2 7.4.2.13 a)~i)的要求。

b) 已有软件的安全手册，给出精确和完整的组件描述。

EN50128

在轨道交通软件标准EN50128中，已有软件的应用应符合a), b), c), d)四项要求：

a) 清晰定义已有软件的需求规格，与其它软件的接口，运行环境的假设约束，安全完整性等级要求

b) 已有软件应包含在整体软件的确认过程

c) 对于SIL3/4的已有软件，要求进行已有软件的失效影响分析，并在整体软件层采取控制措施以防护失效风险，对已有软件运行环境的假设得到满足

d) 已有软件有足够精确和完整（如功能、约束和证据）的描述，应用该软件的人员可以理解和考虑这些要求。

其中a)和d)与IEC61508-3 已有软件安全手册的要求是一致的。

ISO26262-8

在汽车功能安全标准ISO26262-8中，要求对可复用的软件组件进行鉴定，以用于重复使用。软件组件包括源代码、模型、预编译代码或已编译链接的软件，已有软件的类别与IEC61508-3一致，可以来自于商业CTOS软件、未按照ISO26262开发的或已经用于汽车电控系统的内部软件，对已有软件的鉴定报告中需要包括：

1. 已有软件的需求规格、配置标识、接口、使用手册、集成工具、异常运行条件下的反应、与其它软件的相关性、软件异常及处理措施；

2. 已有软件的验证要求，从需求的覆盖率、正常运行和异常运行的验证、与分配给软件的安全需求相悖的其它隐含错误；

3. 对于ASIL D软件，测试用例的完整性应符合ISO26262-6 4.4结构化覆盖率要求；

4. 当已有软件发生变更时，按照变更管理过程进行控制，第2条中已有软件的验证要求，仅适用于未变更部分；

5. 保持已有软件鉴定的记录：标识、配置、鉴定人员、鉴定环境、鉴定过程及结果、已有软件的ASIL等级。

最终输出已有软件应用的各种文档、鉴定报告和鉴定的验证报告。

 

可以看出，不同安全标准中对于已有软件的要求是相似的，但标准的条款比较抽象，下面从四方面讲讲已有软件的认证要点：

第一，使用已有软件集成到安全系统中，需要我们能对已有软件有一个全面的掌控能力。体现在应用的已有软件有全面的理解，这个软件实现哪些功能，跟系统中的其它软件如何接口，如何配置，怎么使用这个软件是安全的。

例如，在安全软件中使用了操作系统RTOS，这个RTOS来自于软件提供商，已经通过了认证。仅有源代码可执行文件，能把板上运行起来是不够的，还要拿到关于RTOS的一系列技术文档，常见的有用户手册、API接口手册、代码文件说明手册、板级支持包BSP手册，其中与安全直接相关的是安全手册，安全手册规定了已有软件的集成方在使用该软件时需要遵循的硬件和/或软件约束，例如：

• RTOS分区保护机制是依赖于CPU硬件支持MPU，因此它需要运行在带MPU功能的CPU上才能实现这个安全功能；

• RTOS只能运行在单核CPU，那么即使选用了多核CPU，操作系统也不支持；

• RTOS认证包含的范围，BSP层是否属于已认证，还是属于软件集成方进行认证；

• RTOS源代码中哪些代码可以修改，哪些代码不能改，支持哪些配置要求；

• RTOS提供的一些安全功能，例如内存自检、ROM自检，需要硬件集成后来做，因此对这些功能的集成测试需要软件集成方来做。

诸如此类的安全约束有几十条甚至上百条，需要逐条检查去满足。可见，即使买了通过认证的已有软件，想把它安全地用好，也需要软件集成人员费一番心思。

第二，如果集成的不是一个符合安全开发规范要求的COTS软件呢，视软件所需要的安全完整性等级，要证明它的安全性就要付出更大的努力，有的甚至是不可达到的目标，比如用一个开源的linux系统通过认证。

COTS软件的应用历史数据是认证方评估的一个重要方面，应用历史涉及到已有软件的运行环境，运行时间、问题记录，仅说明软件具有多少个产品的运行业绩是缺乏说服力的，以往项目中使用的软件与现在安全系统要应用的软件是不是相同的配置，软件的安装环境、运行环境是否有差异，以往软件缺陷的收集、修复、管理过程是否完整可追溯，已有软件的成熟度如何，有哪些已知问题。

在IEC61508-2 7.4.10中对已有软件的证明要求做了详细的规定，而且仅有运行证明不能获得足够的信心，还要结合差异分析，安全分析等其它要求。

第三，COTS软件很多来自于软件供应商，这就涉及到软件供应商管理的工作，完全掌握软件的这些证据是供应商。他是否清楚软件集成方应用该软件所实现的安全要求，是否愿意配合集成方完成整体的认证工作，特别是很多CTOS软件不是以安全性作为设计目标的。供应商能够提供哪些支持资料，是否愿意做安全分析的工作，在集成中发现问题配合的修改工作，配置管理、缺陷跟踪，去除集成方不想要和不需要的额外功能，都需要供应商配合支持。

第四，从本文列举的两个事故可以看出，完全信任已有软件的安全性不现实，还需要在系统层面考虑它可能存在的失效，运用其它软件和硬件对已有软件的失效进行防护，比如防御性编程，安全包，异构比较，内存分区，安全监控等技术，做好这一步的前提在于第一条，能够对已有软件有充分的理解，例如已有软件中的功能没有识别全，就难以证明隐含的功能失效已做了防护。

以上是笔者在安全产品开发和认证中的一些分享，应用已有软件集成到安全关键系统中是软件开发技术中的一条路，但这不是一条捷径，做到安全可靠并不容易，面临着诸多挑战。国内无论是安全系统集成开发方，还是组件开发方，在很多如操作系统之类的基础平台软件的经验较少，如何能够理解标准要求，将已有软件安全地集成到所设计的系统中，不同于应用开发，已经进入了安全关键系统开发的深水区，需要大家继续努力。

原文始发于微信公众号（薄说安全）：功能安全之已有软件(pre-existing)要求