汽车功能安全 - 软件开发
With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures. ISO 26262 includes guidance to avoid these risks by providing appropriate requirements and processes.
-- ISO26262-1 Introduction
就如ISO26262陈述的一样，随着系统技术复杂度、软件规模、机电部件的不断增加，由系统性失效和硬件随机失效导致的风险也在增加。
系统性失效和硬件随机失效的比较见博文系统性失效和随机失效。
所有的软件失效都是系统性失效，不能用统计方法描述其概率，不能定量分析，只能定性地分析和得出定性的结论。
为什么软件失效不能定量地描述？
你可以尝试回答下面两个问题，感受一下定量描述软件失效有多难。
1） 你能准确估计一个软件有多少个bug吗？ （一定要准确估计，粗略估计是定性地分析）
2） 你能估计出这些bug对系统功能安全的影响吗？
很难估计的原因是因为系统失效是人为失误造成的。如果你能定量描述软件失效，那你也能预测明天股票涨跌几个点了。
如何将软件失效及其导致的风险控制在可接受的范围？
解决方法是引入一套开发流程，规范人的行为，减少人为失误。比如：
1）关键的设计、文档等需要他人审查（review）。多个人同时犯错的可能性比一个人犯错概率地低几个数量级；
2）每个功能性需求必须有测试验证。
ISO26262是一套汽车行业认可的功能安全标准，它包含一套用于功能安全系统的软件的开发流程和要求。
下面就介绍ISO26262对软件的要求。
ISO26262对软件的要求主要在第6部分，它指定了用于汽车的软件开发的要求。
软件不是系统内独立的部件，他和硬件、生产软件的工具（比如编译器、代码检查工具）都有密切联系。
一部分软件安全机制需要硬件支持。比如ISO26262在软件架构级别提出了错误检测机制。
其中的方案需要硬件支持。
“1c 数据错误检测”的一种方案是使用硬件支持的ECC（Error Correcting Code）码。
“1d 外部监测设备”的一种方案是使用在微处理器（CPU）外部的，在在ASIC上的看门狗。
所有用于功能安全相关的软件开发工具都需要功能安全认证。
ISO26262按照V开发模型，将软件开发分为以下几个阶段：软件功能需求、软件架构设计、软件单元设计和实现、软件单元测试、软件集成测试、软件需求测试。
下面详细介绍这几个阶段。
软件功能安全需求。
软件安全需求的目标是：
1） 指定软件功能安全需求，它们是从功能安全技术规范或者系统设计导出。所有的和功能安全相关的软件功能都应该被考虑到。
2）完善软硬件接口需求
3）验证软件功能安全需求、软硬件接口需求是否与功能安全技术规范、系统设计一致
软件功能安全需求考虑了硬件的限制及其对软件的影响。比如NVM有位反转随机失效。
软件架构设计
软件架构设计的目标是：
1）建立能实现软件功能安全需求的架构；
2）验证软件架构设计。
软件架构设计用一个层级结构表示软件模块和它们之间的交互，包括静态交互和动态交互。静态交互比如软件模块间的接口和数据路径；动态交互比如流程顺序和时间行为。
软件架构设计提供一种实现软件安全需求和管理软件开发复杂的复杂性。
软件架构设计需要包含足够的信息，以方便软件实现。ISO26262对软件架构语言的要求如表2。
UML（Unified Modeling Language）就是一种半正式符号语言（semi-formal notation），也是常用的软件架构设计语言。
为了避免高复杂度导致的失效，软件架构设计应该展现以下属性。
1）模块化
2）封装
3）简化
可以通过表3中的原则实现上面3个属性。
表3中的1d指软件模块内部应高内聚，1e指软件模块之间应该低耦合。
在软件层级应该做功能安全分析，目的是为了
1）识别或确认和功能安全相关的软件部分；
2）支持指定和验证功能安全机制的有效性。这里的功能安全机制能处理硬件随机失效和软件故障。
更具软件架构层级功能安全分析的结构，表4中的错误检测机制应该被适用，以便指定必须的软功能安全机制。
软件架构设计验证
软件架构验证的方法见表6。
软件架构设计应该满足如下属性：
1）符合软件功能安全需求；
2）和目标硬件兼容；
3）遵循设计准则。
软件单元设计和软件实现。
第一个目标是根据软件体系结构设计和相关的软件安全要求指定软件单元。
第二个目标是实现指定的软件单元。
第三个目标是静态验证软件单元的设计及其实现。
在软件架构设计的基础上，对软件单元进行了详细设计。在进入软件单元测试阶段之前，对软件单元设计和实现进行了静态验证。
ISO26262对软件单元设计的语言要求见表7。
在源代码级别的软件设计和实现应满足如下属性：
1）基于软件架构，子程序和函数在软件单元内执行顺序正确；
2）软件单元之间结构的一致性；
3）软件单元内部和软件单元之间的数据流和控制流的正确性；
4）简单；
5）可读性和可理解性
6）鲁棒性； 例子：防止不真实的值、执行错误、除零、数据流和控制流错误
7）适用软件修改；
8）可测性
为了实现以上属性，表8中的原则应该被遵守。
软件单元设计和实现的验证
软件单元设计和实现应满足如下属性：
1）满足软硬件结构需求；
2）满足软件单元的软件功能安全需求
3） 源代码与编码准则的一致性
4）软件单元实现与目标硬件的兼容性
为了验证以上属性，表9中定义的方法应该被遵循。
软件测试
单元测试、模块测试、集成测试、需求测试。
单元测试
目标是证明软件单元符合软件单元设计规范，并且不包含不需要的功能。
其中“不需要的功能”是指没有对应的软件需求的功能。
软件单元测试方法如表10。
为了评估测试用例的完整性，并证明没有非预期的功能，应在软件单元层级确定需求的覆盖度，并根据表 12 中列出的指标衡量软件代码的结构覆盖率。
集成测试
第一个目标是集成软件元素。
第二个目标是证明软件架构设计已通过嵌入式软件实现。
在此子阶段中，将根据软件架构结构设计测试特定的集成级别和软件元素之间的接口。软件元素的集成和测试步骤直接对应于软件的层次结构。
在此子阶段中，根据软件架构设计对特定的集成级别和软件元素之间的接口进行测试。对软元素的集成和测试的步骤直接对应于软件的分层架构结构。
需求测试
验证软件功能安全需求的目的是证明嵌入式软件满足目标环境的需求。测试应该在表16中的环境中进行。
版权声明： 本文为作者原创，未经许可禁止转载。原文地址：https://www.cnblogs.com/byronsh/p/functional-safety-software-development.html
本文的数字签名如下：
MGYCMQDvrxf3rkOGdx8rLD+p9IOIUm2ruhQNPde2GCmAqq0vbhuY4gSbcRboMJAAGvpdfIkCMQDmGEWps0K4qNQ1z0PvzSPVuYlwoy2C6vnyU00fe0pIjSLk+K3+ExAtB5z5lUGTxJg=
--- 2019-7-20 17:41:35
