ISO26262 Part 8 之 软件工具置信度

1. 目的

在系统或其软件要素，硬件要素开发过程中使用的软件工具，需要具备软件工具有效达到以下目标的置信度：

– 在开发产品中，将因软件工具功能异常导致错误输出的系统性故障的风险减小到最低；

2. 步骤

软件工具的评估与鉴定活动应当在项目初期完成，至少在开发阶段之前，以免影响后续开发活动输出物的有效性，延长项目进度。

分为3步：

• 1. 软件工具使用计划
• 1. 软件工具评估
• 1. 软件工具鉴定

2.1 软件工具使用计划

包括：

– 软件工具的识别码和版本号；

– 软件工具的配置

– 软件工具的使用案例；

– 软件工具的执行环境；

– 当软件工具功能异常并产生相应的错误输出时，会直接违背分配给相关项或要素的全部安全要求的最高ASIL等级；

2.2 软件工具评估

Tool Impact工具影响

特定软件工具功能异常可引入或不能探测开发中安全相关项或要素中的错误的可能性；

• 当有证据表明没有这样的可能性的时候，选TI1；
• 其他情况，TI2 ；原文解释：软件工具不可能引入功能安全异常，或软件工具不可能出现无法探测与安全相关错误的情况，此时应当选择TI1，否则选择TI2。**示例：功能安全项目中应用到的软件工具有Allegro、Proteus、Visio等- 其中Visio属于TI1等级，因为当Visio工具出现异常时，仅会影响到项目中各类图示信息，并不违反安全要求- Allegro、Proteus属于TI2等级，当软件工具出现异常时，有可能直接导致安全要求的违反，例如产品电路的设计异常、不正确的仿真结果结果未被指出等

Tool error Detection 工具错误探测
用于防止软件工具功能异常并产生相应错误输出的措施的置信度，或用于探测软件工具存在功能异常并已产生相应错误输出的措施的置信度

• 当对预防或探测出功能异常及其相应错误输出具有高置信度时，选TD1；
• 当对预防或探测出功能异常及其相应错误输出具有中置信度时，选TD2；
• 其他情况，TD3原文解释：使用了某些措施来预防软件工具的失效或错误输出（例如同类型软件工具输出结果对比等），或使用某些措施探测该软件工具是否正常实现功能（例如用已知的输入输出数据集合来验证软件工具工作状态等）。 示例：功能安全项目中应用到的软件工具有C++、MS Project、EXCEL等- 其中MS Project属于TD1等级，因为当MS Project工具的使用过程中是多人审阅与抄送的，即使出现异常也会有多环节的验证审批过程，体现了软件工具的高置信度。- C++属于TD2等级，当软件工具出现异常时，仅依靠软件工程师对编码结果核查，置信度略低- EXCEL属于TD3等级，在植入公式的表格中对各项数据进行运算，没有相应预防措施 评估流程

2.3 软件工具鉴定

对于TCL3的软件工具，使用方法：

对于TCL2的软件工具，使用方法：

1a. 从使用中增加置信度：

仅当具备以下方面的证据时，可以认为在使用中增加了置信度：

• 此前，已经将该软件工具用于相同的目的，具有相似的使用案例，相似的预定运行环境，相似的功能约束；
• 足够且充分的数据支持；（如可以获得使用时间长度，使用时间频率数据）
• 软件工具的规范定义未发生改变
• 在之前开发中获得的软件工具功能异常和相应错误输出的发生案例是以系统化方式累计

示例：
使用中积累置信度
某软件工具的作用是芯片RTL逻辑验证，在项目开发过程中均会使用到此软件工具。此时企业内部数据中有对RTL代码编辑异常的记录程序，在这个记录单中会详细描述RTL由于什么因素导致编辑异常。此时，可以筛选出由于验证导致的异常，判断是否是工具引起还是人员操作失误导致。最终工具引起的异常数占所有RTL编辑任务总数的占比就可以得出工具置信度的数据。

1b. 工具开发流程评估

• 用于软件工具开发的流程应满足适当的标准。
• 应基于恰当的国内或国际标准对软件工具开发流程进行评估,同时提供恰当的软件开发流程被应用的证据。 例如，ASPICE或者CMMI的认证

1c. 软件工具确认

软件工具的确认应满足以下准则:

• 确认措施应提供软件工具符合分类中指定用途的特定要求的证据;
• 应对确认中发生的软件工具功能异常及其相应错误输出、其可能的后果信息以及避免或探测它们的措施进行分析;
• 应检查软件工具对异常运行条件的响应。

以上策略可以认为是方法一，其缺点是：

• 只适用于特定的软件工具及其版本和环境
• 工具鉴定通常会导致很高的工作量,特别是在频繁更改工具或其版本的情况下(例如,在更新、补丁等情况下),因为工具需要为每个新版本重新鉴定。重新鉴定也适用于可能对工具输出产生影响的工具环境的变化(例如,操作系统或常用的软件库)。

方法二：

工具鉴定的另一种选择是通过在使用软件工具的产品开发过程中引入额外的措施来增加检测错误工具输出的可能性。这将把工具错误探测等级降低到TD1。在这种情况下,流程如下：

• 这个替代方案不需要对特定的软件工具进行鉴定(第二步),而只基于工具的用例,并且可以独立于特定的工具、工具版本和其环境来执行。
• 这种方法可能导致更多的初始和正在进行的开发工作,因为需要引入额外的措施来增加工具错误探测(例如,检查工具输出、额外的测试步骤、使用后续工具进行检查等)。然而,这通常可以减少工具鉴定工作,因为后续的鉴定步骤可以省略,在理想情况下,这个程序只一次就完成。
• 只要用例保持不变,工具置信度水平就是有效的。对于额外的用例,第一步中的等级需被更新(影响分析),这可能导致需要进一步的措施来增加工具错误探测。

3. 举例

例子：某款TASKING工具提供的证据：

为了满足置信度TCL2和TCL3等级的工具鉴定要求，TASKING 实际上采用了2种鉴定方法，“工具开发流程评估”和“软件工具确认”。

3.1 工具开发流程

软件工具的开发流程方面，比较流行的有ASPICE和CMMI。ASPICE是“Automotive Software Process Improvement and Capability ”的缩写，顾名思义，这是一套用于改进汽车行业软件开发过程和提升软件能力的一套标准化流程管理。CMMI的全称为Capability Maturity Model Integration，即能力成熟度模型集成。这两个开发流程内容相当，认证的级别也可以相对应。

TASKING启动功能安全计划之后的所有软件（包含编译器工具集）都是基于ASPICE流程进行开发，目前公司已经通过了ASPICE 的2级认证，图 3描述的是TASKING在ASPICE的获得2级认证的流程。对于工具置信度TCL2，可以支持到ASIL C；对于工具置信度TCL3，可以支持到ASIL B。

TASKING启动功能安全计划之后，采用ASPICE管理软件工具的开发过程。目前，已经获得了ASPICE 的CL2级评估认证。图 3展示的是TASKING获得的ASPICE CL2级评估认证的细节。对于工具置信度TCL2，可以支持到ASIL C；对于工具置信度TCL3，可以支持到ASIL B。

3.2 软件工具确认

如果采用“软件工具确认”的鉴定方法，有两种方式可以实现。

方式一：软件工具供应商进行“软件工具确认”，邀请合格评估机构来对软件工具进行鉴定，并提供证明符合ASIL C 乃至ASIL D的认证证书。在这种情况下，软件工具的客户将会得到经过认证的软件工具，还有一个安全手册，只需要应用安全手册中的指导方针，以证明他的用例与合格的用例是兼容的。

方式二：软件工具的使用方，按照“软件工具确认”的方法，自行去寻找合适的评估机构对软件工具进行鉴定，证明工具符合ASIL C或 ASIL D等级要求。工具鉴定的方法通常是经过认证的，工具鉴定的内容可以总结为：

• 指定用例，以定义工具需要满足的需求
• 选择适当的测试来验证这些需求
• 执行测试
• 分析测试结果
• 生成安全文档
• 应用安全文档中的指导

后一种方式的缺点是存在相当多的隐性成本，例如：学习资格认证方法和相关工具，必要的测试套件许可，执行工具验证过程，与验证者交互，最后如果测试失败如何处理等。

TASKING采用第一种方式进行“软件工具确认”。TASKING VX-toolset产品在第三方机构做了专业鉴定并拿到了最高至ASIL-D等级的证书，可以提供给客户一个资格认证工具包（Qualification kit），该认证工具包中提供了所需的证据和支持文件，证明编译器在按照安全手册中的描述使用时，适合开发达到ASIL-D的安全相关软件。工具包中提供安全手册（Safety Manual）、测试套件（Test Suite）和问题门户网站（issues portal：TASKING Issues Portal）账户。

安全手册，提供了关于如何使用工具集进行安全相关开发的指导，并且包含支持工具鉴定方法的证据。

访问TASKING Issues Portal的缺陷报告和缓解数据库的所有信息的许可，该数据库包含了有关TASKING和客户报告的所有已知工具问题的最新信息。

关于如何执行 "软件工具的验证 "鉴定方法的脚本和说明。

参考：

https://mp.weixin.qq.com/s/ZU9_J3_hYG_LoQvFJolkXQ
https://www.munik.com/newsinfo/6967514.html