引言：

在功能安全系统开发阶段，我们已经得到了技术层面可实施的技术安全需求TSR，并将其分配至系统架构中的硬件（HW）和软件（SW），接下来以此为基础进行相应的硬件和软件功能安全开发。对于功能安全软件开发紧接着第4部分系统开发内容，具体开发模型如图一所示：

图一：软件开发阶段V模型

主要包括以下内容：

1. 软件安全要求；

2. 软件架构设计；

3. 软件单元设计和实现；

4. 软件单元验证；

5. 软件集成和验证；

6. 嵌入式软件验证；

在功能安全软件开发中主要针对的是软件的系统性失效，针对各个子阶段开发活动提出了相应的规范要求，并对不同ASIL等级软件开发，规定了所需要进行的具体测试方法和内容。鉴于内容比较多，我们这篇先介绍一下软件安全要求的内容。

软件安全要求就是在正常软件需求上叠加了一些功能安全的要求，这些要求使软件需求的定义和标准更加清晰明确。

1 软件安全要求的来源

功能安全软件开发始于软件安全要求即软件安全需求（Software Safety Requirement, SSR），而SSR源于分配给软件组件的TSR，是软件相关的TSR在软件层面的进一步细化。一般来讲：

软件安全需求SSR=安全相关的软件需求+非安全相关的软件需求。软件安全需求具体来源可如下表1所示：

表1、软件安全需求

那么，怎么从TSR得到SSR呢？

SSR属于由软件相关的TSR细化得到软件层面安全需求，只要在系统开发阶段有效识别出软件相关的TSR，SSR导出就比较容易。然而如何有效识别出软件相关的TSR，就需要对系统层面的系统架构设计规范和软硬件接口规范比较了解，对其进一步安全分子或直接根据经验，才能识别出软件相关的TSR，导出更为详细的SSR。

在从TSR到SSR的过程中需要注意一下几点：

1. 除了安全机制相关的SSR外，还需要根据适用性，充分考虑确保安全机制实施的基础功能，尤其是软硬件接口规范和FFI免于干扰的安全你要求，他们是保证软件功能安全主要内容。

2. FFI免于干扰的安全要求多和基础软件相关，部分属于安全机制，一般会将SSR分为应用层软件安全相关和基础软件相关的安全需求，便于后续独立开发。

3. SSR要与软件相关的TSR之间存在可追溯的关系，可以是一对多，也可以是多对一。

4. SSR颗粒度的问题，每个公司的方式和方法都不一样，最精准的做法是将需求分解带该层下不能再分解的状态，但是这样确实是比较耗时的，根据以往的经验找到平衡点。

2 软件安全需求的定义

软件安全要求的定义可以作为软件开发的主要输入，其质量很大程度上确定了软件开发的质量。软件安全要求的定义和管理按照ISO 26262-8:2018第6章节安全要求的定义和管理执行。具体可参看之前技术文稿“功能安全之安全要求”，此外内容上还应考虑以下：

1. 已定义的系统和硬件的配置；例如：配置参数可以包括通讯的速度、采样的频率等。

2. 软硬件接口规范；例如：通过软件要求实现对硬件接口的正确控制即细化软硬件接口到正确控制和使用硬件，并描述硬件和软件间每个与安全相关的依赖性。

3. 硬件设计规范的相关要求；例如：硬件设计中规范中涉及到的一些软件约束条件，可具体到算法和数据类型等。

4. 时间约束；例如：在应用监控层中要求每隔1S对任务执行堆栈执行一次监控的安全机制，已经明确到软件程序响应和执行的时间必须小于1S。

5. 外部接口；例如：主要指通讯接口，外部执行器接口等。

6. 对软件有影响的车辆、系统或者硬件的每个运行模式以及运行模式之间的转换；例如：低功耗、初始化、正常运行、降级、测试、诊断等模式之间转换是对软件要求的定义。

7. 如果嵌入式软件执行了其他功能，则应对这些功能进行定义，或参开其规范。

3 软件安全要求的验证

定义好了软件要求要求后，需要对定义好的软件安全要求进行验证，验证软件功能安全要求和细化后的软硬件接口规范是否与技术安全要求、系统设计一致。应由负责系统开发、硬件开发和软件开发的人员共同验证细化的软硬件接口规范。具体按照ISO 26262-8:2018中第6章节推荐的安全要求验证方法执行，如下图二：

图二、验证安全要求的方法

形式化验证和半形式验证主要是将安全需求转化为可执行的模型，在软件开发前期建模来实现软件的需求，感受软件需求的实现方式和流程，从而验证软件安全需求的准确性和完整性。也可通过外部评审让需求尽可能达成共识和完整，通过内部评审让开发和测试人员了解需求的可实现性。总之，好的需求要求清晰、准确、可测试、可实现等。

功能安全软件开发阶段之软件安全要求内容基本就这么多，安全需求定义好后需要通过设计来实现，如何实现……，下期分享功能安全软件开发阶段之软件架构设计和详细设计，希望持续关注。