ISO26262对软件开发的规定

我们经常谈ISO26262,经常说到这个系统的功能安全要求是ASILD，对硬件随机失效率FIT值不能超过100等等，那不同安全等级要求的产品，对软件开发过程的工作内容又有哪些要求呢？这些都在ISO26262的第六部分中有详细的定义，标准中共计16张表，囊括了软件开发过程中需求、架构、实现、测试所有环节的规定。

针对不同安全等级的产品，在ISO中对软件开发过程有不同的规定，下面我从个人从业经历出发，谈一谈容易被忽略的软件工作内容。

• Table1：一定要有一份建模或代码规范，在《》和《》谈到了部分的内容。

如果使用C作为开发语言，在26262中明确推荐MISRA C作为代码规范。为什么1b中要提到Usage of language subset这个概念呢？以C为例，标准C其实是一种非常灵活的编程语言，但是用于嵌入式系统开发这个场合，其在不同的开发平台应用与不同的芯片的通用性是受限的，因此才会有MISRA C这个规则所定义的C语言这个子集在汽车电子领域大行其道。我们在26262的前身61508的第七部分也可以看到，对安全系统要求比较高的系统，C语言是强烈不被推荐使用的，但是受限并且使用了静态分析工具的C语言子集是强烈被推荐使用的。

• Table2和Table3：主要是讲架构开发，对高安全等级（ASIL C/D）的产品，需要使用到Semi-formal notation，言下之意，不能使用自然语言描述了，至少需要用MS Office画的流程图，但是这种方式配置管理和版本管理很难搞，最好还是使用标准的UML工具。

• Table4：对于SafetyAnalysis之后功能安全要求比较高的模块，必须要有产品从软件上相应的安全手段来与之对应。这一块是最难做的，也是企业常常忽略的，在做Audit的过程中往往也是最容易被Chanllenge的。

我们看看，针对ASIL D的产品，都有哪些软件机制是必须采用的？

n 1a：输入输出的范围检查，就是说每一个模块的输入输出，都要限定其数据物理取值范围，基于MBD的开发就是在Simulink模型中加Saturation模块或在数据字典中限定变量范围

n 1b.合理性检查包含两个部分，一个是针对变量的合理性检查，比如EPS软件中，当手上力矩为正的时候，BoostCurve输出的力矩不能为负；另一个是针对标定值的合理性检查，比如EPS的车速断点必须单调递增、扭矩断点必须单调递增等等。

n 1c：一般是针对标定数据的检查，如CheckSum、CRC校验等等，可以采取同样的数据放在三块不同的区域，任意一块数据区域的错误都能用其它两块备份数据来纠正的方法。但这个方法对ASIL D也不强制要求，但可以用在一些特别重要的数据上，比如EPS的RES位置，即使存在EEPROM中的数据发生了corruption，仍然能通过备份数据给纠正回来，不至于丧失这个功能。

n 1d：外部监控，比如看门狗或双MCU冗余监控

n 1e：程序流的监控，比如采用令牌环的方式检测程序运行路径

n 1f：软软监控：比如用不同的方法实现同一功能的两套软软件，比如逆向求解，见下图：

• Table5是讲安全处理机制的，这个在System Level已经定义好，SW level把它实现即可，Table6是关于架构层的Verification，重点就是ASIL B以上的系统，桌面走查这种Review形式已经不够了；Table7,8是关于Unit Level design的，与架构level大同小异，Table 9中则提到，ASIL B以上的系统，Unit Level的软件Verification，一定需要做静态分析（见《浅议怎样提高汽车电子嵌入式软件的开发质量》）。

• Table 10,11,12则是软件测试方面的，有以下几个要求是需要注意的，在传统的软件测试中没有明确要求，但是在26262中提到：

Ø ASIL D的产品必须要做故障注入测试和资源占用率测试（CPU Load/RAM/堆栈…）

Ø 如果是基于模型开发，ASIL C以上的产品要做B2B测试（模型与代码是否一致？）

Ø ASIL B以上产品要做Boundary测试（数据是否越界？）

Ø ASIL A产品在覆盖度方面只考察状态覆盖度，ASIL B则考察分支覆盖度，ASIL C以上考察MCDC，一般来说，测试用例的覆盖度需要达到100%。