聊聊汽车功能安全软件开发相关内容

01

软件开发模型

为了更好了解软件及其功能安全开发过程，我们首先来聊聊软件开发模型。不管是ISO 26262，Aspice还是System Engineering，其开发过程都基于V模型，可以说V模型是汽车工程师必修内容。  

对于功能安全而言，软件功能安全开发V模型属于ISO 26262第6部分内容，是系统开发大的V模型中软件开发部分，紧接着第4部分系统开发内容。整个软件开发V模型始于需求开发，然后架构设计，详细实现，最后完成集成和验证。左侧V从需求到设计，右侧V从集成到测试验证，具体如下图所示:  

这里顺便聊一下现在讨论比较多的ASPICE，后续找机会我们细聊。ASPICE 全称“Automotive Software Process Improvement and Capacity Determination”，即汽车软件过程改进及能力评定，于2005年由欧洲主要汽车制造商共同制定，旨在通过规范汽车零部件供应商软件开发流程，并对其开发项目进行评估认证，从而改善汽车软件的质量，具体开发流程如下图所示:  
 

可以明显看出，ASPICE开发模型也包括系统和软件开发V模型并附加相应支持和管理过程。它和ISO 26262开发模型及主要工作输出产物基本类似，它们的底层逻辑都是通过对开发过程进行约束，认为过程基本决定结果，只要开发流程满足需求，则在该流程下开发出来的产品或软件的质量也能够得到保障。  

目前ASPICE在欧洲应用比较多，欧洲大部分OEM都对供应商软件开发能力有所要求，例如目前达到Level 2级别。但这几年国内对ASPICE讨论很多，很多OEM放弃了ASPICE开发，很多人认为ASPICE只是徒劳增加开发工作量，延长项目周期，并不一定改善软件质量，尤其基于单个项目的开发能力评估并不能反映在其他项目的应用情况。  

我个人观点如下:  

1

规范及流程的存在是为统一标准，为让大部分普通工程师在其约束下也能够开发出一流产品，保证产品质量一致性。

2

条条大路通罗马，只要企业内部开发流程完善，并不一定完全按照ISO 26262，ASPICE等规范进行开发，规范的存在也只是提供指导，帮助企业建立及完善自己的开发流程。研发流程的存在虽然短期会增加研发工作量，但长远来看绝对利大于弊。

3

企业研发流程的制定需要结合企业规模，内部组织结构，企业文化多种因素考量，选择适合自身发展的开发流程。

4

规范及流程必须合理有效且能够付诸于实践。尽可能利用相应的开发，管理工具链，加速流程的应用和管理。例如，ASPICE和ISO 26262要求开发需求，软/硬件，测试用例之间的可追溯性，如果没有强大的开发工具链支持，其工作量巨大，且可用性也差。

5

考虑到成本及可行性，对企业开发能力的评估也只能采取样本认证，即对其开发流程和具体样本项目进行评估，无法覆盖企业所有项目，这是所有认证的共性问题。而企业是否能够坚持标准，应用于所有开发项目，取决于企业自身的坚持，我相信我们还有很长的路要走！

02

什么是软件安全需求？

功能安全软件开发始于需求开发，即软件安全需求(Software Safety Requirement, SWSR)，而SWSR源于分配至软件组件的TSR，是软件相关的TSR在软件层面的进一步细化。

SWSR定义相对比较简单，但需要注意的是，很多朋友认为只要定义软件相关安全机制就足够了，其实除此之外，SWSR还包含和安全机制无关的SWSR，它是保证功能安全的基础或支持内容，SWSR一般来讲: 

软件安全需求SWSR = 安全机制无关的软件安全需求 + 软件安全机制 

安全机制无关的软件安全需求包括: 

1

使标称功能可以安全执行的功能等。

例如: 软件安全运行相关基础软件，包括操作系统，时钟，运行模式等。

2

在生产、运行、服务和报废过程中与车载测试和非车载测试相关的功能。

例如: 车载通信、密钥管理或闪存数据安全检测等，或OBD II相关内容，包括故障存储，读取，清除等。

3

允许在生产和服务过程中对软件进行修改的功能。

例如: 可配置性数据或标定数据，以满足多车型软件复用或者升级。

4

软硬件接口规范要求。

例如: I/O接口，通讯等信号安全需求。

5

对软件功能和特性的要求，包括对错误输入的鲁棒性、不同功能之间的独立性或免于干扰、或软件的容错能力。

例如: FFI中软件分区。  

软件安全机制包括:

1

‍与应用软件本身、基础软件或操作系统失效探测、指示和减轻有关的自检或监控功能。

例如: 应用层软件程序流监控，输入，输出合理性检测等; 基础软件自检等。

2

与安全相关硬件要素故障探测、指示和减轻相关的功能。

例如: 涉及基础软件相关安全机制，包括控制单元电源，时钟，内存等硬件要素故障信息探测，指示和控制。

3

使系统达到或维持安全状态或降级状态的功能。

例如: 错误管理，安全状态等。

怎么从TSR得到SWSR呢？

SWSR属于由软件相关的TSR细化得到软件层面安全需求，只要在系统开发阶段有效识别出软件相关的TSR，SWSR导出相对比较容易。  

具体来说，根据分配至软件组件的TSR，对其进行进一步安全分析或直接根据经验，导出更为详细的SWSR，需要注意的是:  

1

在实际操作中，除安全机制相关的SWSR外，还需要根据适用性，充分考虑上述提到的非安全机制相关SWSR，尤其是软硬件接口规范和FFI免于干扰的安全需求，它们是保证软件功能安全重要内容。

2

FFI免于干扰的安全需求多和基础软件相关，部分属于安全机制。在实际操作中，一般会将SWSR分为应用层软件安全相关和基础软件相关的安全需求，便于后续独立开发。

软件需求书写实践原则

软件需求作为后续软件开发的重要输入，其质量很大程度上决定了软件开发质量，所以写好需求是门技术，需要对系统及Stakeholder需求有充分的理解，这也是为什么近几年需求的定义和管理越来越收到企业重视的原因。

鉴于此，接下来我们聊一下软件需求书写实践原则，具体包括以下内容：

层次化。

需求不可分解，不要将两个要求合二为一，保持需求细化。

应该使每个要求表述尽可能完整和准确，无歧义，无冗余，不要输入可能使开发人员感到困惑的不合理的额外信息

除了需求本身，可以添加规则或示例、范围陈述或目标进行补充。

需求定义软件该做什么，而不是不该做什么。

有必要在文档中记录所有假设。

需求可验证性。

需求可追溯性。

网络上有很多需求文档书写模板，包括RUP版本，Volere版本，ISO版本，SERU版本等，大家直接关键词搜索即可，在此不再赘述。

审核编辑：刘清