MUNIK解读ISO26262：软件开发阶段(一)-软件安全需求
—原创文章，文章内所有内容文字资料，版权均属本公众号所有，任何媒体、网站、公众号或个人未经本公众号授权不得转载、转贴、引用或以其他方式复制发布 、发表。已经本公众号授权的媒体、网站、公众号、个人，在下载使用时必须注明来源，违者本公众号将依法追究相关责任.
回到本文的源头文章“ISO26262标准解读”，请点击链接：ISO26262 Functional Safety of Automotive汽车功能安全服务
回到知识分享，请点击链接：MUNIK中国-技术分享
功能安全软件开发阶段----软件安全需求
引言：
在功能安全系统开发阶段，我们已经得到了技术层面可实施的技术安全需求TSR，并将其分配至系统架构中的硬件（HW）和软件（SW），接下来以此为基础进行相应的硬件和软件功能安全开发。对于功能安全软件开发紧接着第4部分系统开发内容，具体开发模型如图一所示：
图一：软件开发阶段V模型
主要包括以下内容：
● 软件安全要求；
● 软件架构设计；
● 软件单元设计和实现；
● 软件单元验证；
● 软件集成和验证；
● 嵌入式软件验证；
在功能安全软件开发中主要针对的是软件的系统性失效，针对各个子阶段开发活动提出了相应的规范要求，并对不同ASIL等级软件开发，规定了所需要进行的具体测试方法和内容。鉴于内容比较多，我们这篇先介绍一下软件安全要求的内容。
软件安全要求就是在正常软件需求上叠加了一些功能安全的要求，这些要求使软件需求的定义和标准更加清晰明确。
1 软件安全要求的来源
功能安全软件开发始于软件安全要求即软件安全需求（Software Safety Requirement, SSR），而SSR源于分配给软件组件的TSR，是软件相关的TSR在软件层面的进一步细化。一般来讲：
软件安全需求SSR=安全相关的软件需求+非安全相关的软件需求。软件安全需求具体来源可如下表1所示：
|
SSR分类 |
内容 |
示例 |
|
安全相关的软件安全需求 |
使标称功能可以安全执行的功能； |
例如：软件安全运行相关基础软件，包括操作系统、时钟、运行模式等； |
|
使系统达到或维持安全状态或降级状态的功能； |
例如：安全状态的管理和执行、降级管理等、软件工作模式之间的相互转换； |
|
|
与安全相关硬件要素故障探测、指示和减轻相关的功能； |
例如：控制单元电源、时钟、内存等硬件要素故障信息探测，指示和控制； |
|
|
与操作系统、基础软件或应用软件本身失效探测、指示和减轻有关的自检或监控功能； |
例如：应用层软件程序流监控，任务电动程序中堆栈的监控，基础软件和操作系统自检等； |
|
|
在生产、运行、服务和报废过程中与车载测试和非车载测试相关的功能； |
例如：车载通讯、秘钥管理或者报废后闪存数据安全检测等； |
|
|
允许在生产和服务过程中对软件进行修改的功能； |
例如：软件通过配置性数据或标定数据，以满足多车型软件复用或者升级； |
|
|
与性能或对时间敏感的操作相关的功能 |
例如：对仪表盘数据的实时性要求，要求500MS更新一次数据，时间分配到软件上的响应时间； |
|
|
非安全相关的软件安全需求 |
对错误输入鲁棒性要求； |
例如：超范围的出入对软件的影响；非正常运动的环境对软件的影响； |
|
不同功能之间的独立性或免于干扰； |
例如：软件模块之间对于全部变量的调用；共同资源的使用等； |
|
|
软件的容错能力； |
例如：在有故障或者异常情况时，仍然可以保持正常的基本功能的使用。 |
表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章节安全要求的定义和管理执行。具体可参看之前技术文稿“功能安全之安全要求”，此外内容上还应考虑以下：
● 已定义的系统和硬件的配置；例如：配置参数可以包括通讯的速度、采样的频率等。
● 软硬件接口规范；例如：通过软件要求实现对硬件接口的正确控制即细化软硬件接口到正确控制和使用硬件，并描述硬件和软件间每个与安全相关的依赖性。
● 硬件设计规范的相关要求；例如：硬件设计中规范中涉及到的一些软件约束条件，可具体到算法和数据类型等。
● 时间约束；例如：在应用监控层中要求每隔1S对任务执行堆栈执行一次监控的安全机制，已经明确到软件程序响应和执行的时间必须小于1S。
● 外部接口；例如：主要指通讯接口，外部执行器接口等。
● 对软件有影响的车辆、系统或者硬件的每个运行模式以及运行模式之间的转换；例如：低功耗、初始化、正常运行、降级、测试、诊断等模式之间转换是对软件要求的定义。
● 如果嵌入式软件执行了其他功能，则应对这些功能进行定义，或参开其规范。
3 软件安全要求的验证
定义好了软件要求要求后，需要对定义好的软件安全要求进行验证，验证软件功能安要求和细化后的软硬件接口规范是否与技术安全要求、系统设计一致。应由负责系统开发、硬件开发和软件开发的人员共同验证细化的软硬件接口规范。具体按照ISO 26262-8:2018中第6章节推荐的安全要求验证方法执行，如下图二：
图二、验证安全要求的方法
功能安全软件开发阶段软件安全要求内容基本就这么多，安全需求定义好后需要通过设计来实现，如何实现……，下期分享功能安全软件开发阶段之软件架构设计和详细设计，希望持续关注。
