导读
汽车电子软件开发中，编译器是必备工具，功能安全是必守标准，这两个需求的综合就是功能安全认证版编译器。
免费的开源编译器似乎也能编译出实现功能的软件，那么为何还需要购买功能安全认证版编译器呢？或者购买了功能安全认证版编译器且软件能编译出来运行，是否就足够了呢？
使用符合要求的编译器重要，按照规则对其进行正确配置和使用也同等重要。本文将详细介绍在软件开发中如何实践这些要求。
作者 | 辉羲智能-戴兴
HUIXI TECH
一、ISO 26262中对编译器的要求
功能安全相关的产品开发需要保证开发过程中使用的工具链符合相应的功能安全标准。如果工具在使用过程出现异常，就可能影响最终的安全目标。例如，同样一份C代码，每次编译的结果若产生差异，就完全无法保证这份代码所定义的行为在项目开发过程中保持一致性了。
ISO 26262-8中定义了对工具的评估和鉴定的标准。编译器作为可能影响安全目标的工具之一，需要通过相关的工具鉴定。ISO 26262-8标准要求为工具鉴定过程编写两个工作产品：
关于“软件工具的评估”
软件工具标准评估包括对于软件工具的“使用规划”和确定该工具的“置信度级别”。“使用规划”目的就是确定软件工具使用场景的边界。例如编译C语言和C++就是完全不同的使用场景。而“置信度”决定了工具的鉴定方式，以证明该工具适合用于安全相关的开发项目。
ISO 26262中对使用规划的定义为：
1. 制定软件工具的识别码和版本号；
2. 制定软件工具的配置；
3. 制定软件工具的使用案例；
4. 制定软件工具执行的环境；
5. 制定当软件工具功能异常并产生相应的错误输出时,会直接违背分配给相关项或要素的全部安全要求的最高ASIL等级；
6. 如需要，制定基于确定的置信度水平和ASIL等级的软件工具的鉴定方法；
ISO 26262要求对使用需求进行规范描述，包括：
1. 软件工具的特征、功能和技术属性的描述；
2. 如果适用，用户手册或其他使用指南；
3. 工具运行要求的环境描述；
4. 如果适用，对异常运行条件下期望的软件工具表现的描述；
5. 如果适用，对已知软件工具功能异常，及恰当的安全保护、避免或应急措施的描述；
6. 在制定软件工具要求的置信度水平过程中，识别出的对软件工具功能异常和相应错误输出的预防或探测措施；
确定软件工具的规划使用后，还需要描述软件工具的使用案例，每个使用案例的描述应包括：
1. 预期的目的；
2. 输入和期望的输出；
3. 如果适用，使用过程、环境的和功能的约束。
关于“软件工具的鉴定”
确定完使用案例后，软件工具资格鉴定过程就可以开始了。
首先确定每个使用案例下工具的工具置信度Tool Confidence Level(TCL)。
影响软件工具置信度TCL的两个因素是工具影响Tool Impart(TI)和工具错误检测Tool Eroor Detection(TD)。
TI：特定软件工具功能异常可引入或不能探测开发中安全相关项或要素中错误的可能性：
TI1：无影响 TI2：有影响
TD：用于预防软件工具功能异常并产生相应错误输出的措施的置信度，或用于探测软件工具存在功能异常并已产生相应错误输出的措施的置信度：
TD1：高 TD2：中 TD3：低
确定完TI和TD后，根据下表得出TCL。其中TCL的值越大，就越可能影响功能安全。
画重点：
根据TI（工具影响）和TD（工具错误检测）计算TCL（工具置信度）。
讲案例：
如下案例1和案例2出现失效将会直接影响最终运行的可执行文件，从而影响最高的安全需求，TI值均为TI2。即：
TD的分析和使用环境，开发流程等均有关，分析这部分是较为复杂的一部分，可通过如下方式进行评估：
其中：
4分及以上，评为TD1；3分为TD2；0分到2分为TD3。
假设该编译器的TD为TD3，那么总体的编译器评估结果如下：
工具置信度计算出来后，就可以进行软件工具资格鉴定了。
ISO 26262-8有多个工具鉴定的方法，软件工具鉴定报告会包含使用所选方法的结果。
根据软件工具评估得出的TCL，结合实际开发中的安全需求等级，即可确定鉴定方法。其中评估为TCL1的软件工具不需要进行鉴定。具体如下：
1a：使用中积累信任度
要求证明该工具已经用于相同目的下可比较的使用案例、可比较的操作环境和配置，而且工具配置规格等均一样。且在之前的使用过程中发生的故障和相应的错误输出，都存有系统完备的记录。该方法还规定，使用过程中积累的信赖需要建立在充足与合适的数据之上。
1b：工具开发流程评估
需要国内外认证机构来基于工具供应商内部开发流程进行评估。
1c：软件工具确认
验证工具能否实现其设计需求。可以通过测试来提供证据表明工具错误不会发生或者能够被检测。需要考虑所有的可能性。
1d：按照安全标准开发
参照ISO 26262标准中的规定进行开发。
在完成编译器评估和鉴定后，对整个过程的需要进行记录存档，并需要对其过程输出产品评估报告和鉴定报告进行审查，保证过程的质量。对评估报告、鉴定报告、评估审查报告和鉴定审查报告进行存档维护，整个编译器的评估和鉴定就完成了。
HUIXI TECH
二、开发过程中进行正确的配置和使用
如果走到了“1d 按照安全标准进行开发”，那么需要向编译器厂商索取，确认及保留相关信息即可。这时就看出功能安全认证版编译器的不同之处了。以某编译器供应商的safety manual为例，明确提到了如下3个方面对软件开发的影响：
通用类
1. 对编译器需进行管理，确保统一项目开发人员使用的是相同版本的编译器；
2. 对编译器的获取、安装、维护等需要严格按照对应的用户指南进行，且需要保证文件夹不被损坏；
3. 不可将编译器功能用于其他工具功能扩展的输入；
4. 浮点运算需要用户非常了解对应处理器的浮点特性，以便对编译器做出合适配置；
5. 编译器编译的输出必须运行在硬件或RTOS上······
等12条通用约束，与软件开发管理强相关。
功能限制类
1. 如果没有硬件浮点运算单元，软件编码过程实现浮点运行算；
2. 如果系统仅支持单精度浮点，软件需确保避免使用双浮点；
3. 用户仅可使用-std=c90或-std=c99用于安全开发；
4. 不要使用动态链接；
5. 不要使用自动overlay支持选项······
等11条功能约束，与makefile与编程规则设置强相关。
诊断类
1. 不可降低编译器的诊断严重度；
2. 需要确保对于内存访问的对齐配置与要访问的内存的对齐规则一致；
3. 用户需开启-mfloat-abi 来诊断浮点运算前后调用的一致性；
4. 需要使用配置-g选项确保调试阶段和生产阶段出现不一样；
5. 需要使用-fno-builtin选项，当使用库时······
等9条诊断约束，与makefile设置强相关。
以上限制，将直接影响编译器选项的确定、coding standard以及内部开发管理。每个细节都需要小心检查，并不是编译通过就能高枕无忧的了。
HUIXI TECH
三、总结
ISO 26262提出了对软件开发工具的要求，并定义了进行工具标准评估和工具资格鉴定的一系列注意事项。编译器作为最典型的软件开发工具，大部分场景下需要通过“1d 按照安全标准进行开发”来进行鉴定。而1d类型的鉴定就需要编译器供应商的大量支持，这是功能安全认证版编译器才能带来的。
选择了功能安全认证版编译器后，同样需要在编译器选项、编码规则、开发管理等多个维度对其进行正确配置和使用，才能最终满足ISO 26262要求。
