特约专栏 | 软件工具置信度评估过程解析

引言  软件工具置信度评估过程解析

注：图片来源于网络，如有侵权，请及时联系作者删除

➡本文主要内容分为4个部分（约4500字，18钟阅读）

01

本文概述

随着汽车行业电气化智能化的快速发展，功能安全标准ISO 26262逐渐被各大汽车制造企业及零部件供应商重视。近期，《智能网联汽车生产企业及产品准入指南》明确将功能安全和预期功能安全作为汽车制造和生产的准入要求，体现了国家对于汽车安全的重视，功能安全的实施与否已经成为了衡量汽车制造企业及零部件供应商造车能力的关键性指标。

在功能安全实施过程中，相比于传统的系统及软硬件开发和测试过程，功能安全还有一些额外的安全活动需要考虑。例如，为了实现功能安全的完整性，ISO26262/GB-T34590要求针对在系统或其软件要素、 硬件要素开发中使用的软件工具，可以支持安全标准要求的活动或任务。在这些情况下，需要具备软件工具有效达到特定的置信度。由于这些特定的安全活动在之前的汽车制造领域不是很受关注，这也是对很多同行来说比较头疼的地方。

笔者从事软件安全开发及功能安全经理多年，对于功能安全的支持和管理过程有一定积累。在工作生涯里，很多同行都在咨询有关软件工具置信度评估的疑问。基于此，本文将针对软件工具置信度评估这一活动过程进行详细阐述，以帮助同行了解及实施软件工具置信度评估及认证的过程。

内容框架：

• 软件工具置信度评估过程解析

• 软件工具置信度评估案例

02

软件工具置信度评估过程解析

在ISO 26262第8部分支持过程的第11章，提出需要对所使用软件工具的置信度进行评估。其目的为提供准则，以确定在适用时所要求的软件工具置信度水平；及在适用时提供鉴定软件工具的方法，以建立证据证明软件工具适合用于支持功能安全要求的活动或任务（即对那些安全标准要求的活动或任务，使用者可依靠软件工具的正确功能）。

识别需要进行置信度评估的软件工具

在标准中提到如果安全生命周期包含使用软件工具用于系统、 硬件要素或软件要素的开发， 使得标准所要求的活动或任务依赖于软件工具的正确功能，与此同时未按照适用的流程步骤对工具的相关输出进行检查或验证， 那么该软件工具应符合相关置信度评估及认证要求。

这里需要注意的是，“软件工具”不等同于“软件开发工具”，而是在功能安全生命周期中（安全生命周期包含了在概念阶段、产品开发、生产、运行、服务和报废期间的主要安全活动）所有的由软件工具参与的系统，硬件或者软件要素开发的工具都应当考虑在内。因此，通常我们可以将相关需要评估的软件工具归纳为以下几类（充分但不必要）：

• 项目管理/配置工具 

• 系统开发及测试工具

• 硬件开发及测试工具

• 软件开发及测试工具

• 生产相关标定/配置工具

• 功能安全分析工具

另外，对于以上这些类，除了收集项目使用的商业工具外，还应当包括开源工具、 免费工具、 共享工具或使用者自己开发的工具。

定义软件工具使用计划及使用案例

基于上述软件工具的识别，作为功能安全经理需要协同产品安全开发团队的成员对项目中所涉及到的软件工具进行细化描述。具体包括：

a）软件工具的识别码和版本号

例如，软件工具名称及版本信息，需要注意软件版本号与项目开发过程中使用的版本保持一致。

b）软件工具的配置

例如，通过设定编译器开关和 C 源文件中“#pragma” 声明， 定义编译器的配置。

c）软件工具的使用案例

注：在开展安全生命周期活动时， 使用案例可以描述用户与软件工具的配合和软件工具功能的应用子集。使用案例可包含对软件工具配置及软件工具执行环境的要求。可以从软件工具在产品开发过程中使用的子功能着手。通常一个使用案例需要包含：预期的目的；输入和期望的输出；及使用过程，环境和功能约束。

例如，文件加载，文件编辑，文件保存，文件查看等子过程对使用该工具的过程进行描述。对于以上工具子功能可以在评估表中单独分行描述，以便于后续进行功能失效影响分析；也可以综合描述，以简化分析过程。推荐针对该工具每个子功能进行分行描述。

d）软件工具执行的环境

例如，执行软件工具所需的资源、 基础设施或运行时环境， 应用软件工具所需的流程活动或与软件工具输出结果验证相关的后续流程活动。

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

注：可根据特定开发确定最高 ASIL 等级， 或可根据软件工具通用的用法确定最高 ASIL 等级。在预先假定ASIL 等级的情况下， 对该假设进行验证

f）如需要，基于确定的置信度水平和 ASIL 等级的软件工具的鉴定方法

评估工具失效对安全目标

产生的影响及探测措施（TI&TD）

基于2.1及2.2章节的工具配置及使用案例的定义，需要进一步分析软件工具功能异常或者错误输出时，对于项目的安全功能的影响，并收集相关探测措施：

图1：工具评估与鉴定流程

工具失效影响(tool impaction)评估

特定软件工具功能异常可引入或不能探测开发中安全相关项或要素中错误的可能性。这是通过工具影响（TI）等级表示的，定义两个层级：

• 当有论据表明没有这样的可能性时， 应选择TI1

• 在所有其他情况下应选择TI2

例如，在分析该工具特定的使用案例时，可以考虑如下失效模式：

1. 功能不可用（无功能）

2. 功能非预期运行或关闭

3. 功能无响应

4. 功能输出异常

基于以上失效模式，判定该功能失效对于项目安全目标或者安全功能产生的直接或者间接影响。

如果该功能失效可能导致项目安全目标被违背或者安全功能运行异常，则应当描述该影响过程，并选择TI等级为TI2。反之，则应该选择TI等级为TI1。

工具失效探测措施(tool detection)评估

用于预防软件工具功能异常并产生相应错误输出的措施的置信度， 或用于探测软件工具存在功能异常并已产生相应错误输出的措施的置信度。这是通过工具错误探测（TD）等级表示的，一共有三个等级：

• 当对预防或探测出功能异常及其相应错误输出具有高置信度时， 应选择TD1

• 当对预防或探测出功能异常及其相应错误输出具有中等置信度时， 应选择TD2

• 在所有其他情况下应选择TD3

在考虑对该工具失效的检测措施时，不局限于直接的工具故障检测设计。包括如下几种措施都可以在评估过程中考虑：

1. 工具自带的错误诊断功能，故障容错或者合理性检查机制。例如，代码烧录工具如果带有CRC自校验功能则可以认为是一种高置信度措施， TD1

2. 由其他工具对被分析的工具输出进行验证，如果两个工具之间不存在相互依赖性，则通常认为中等置信度措施，TD2。例如，代码静态检查工具对编码工具进行检查

3. 通过系统性的开发流程和开发活动保证。例如，对工作产物的评审及对工具生成产物的测试。其中，评审方案通常只能达到一个中等置信度水平（基于安全标准的评审也可能达到高置信度水平），而基于标准的测试可以达到中等或者高置信度水平。两者结合进行验证，则通常能达到高置信度水平，TD1

4. 如果在开发流程或者工具本身不具备相关的故障探测或者验证措施，则属于典型的低置信度水平，TD3

以上的这些预防或者探测措施可以组合使用，基于每条技术措施的置信度水平，可以综合评估其整体的故障探测等级，并在评估表中描述该探测措施的具体原理。

工具置信度水平判定（TCL）及认证措施确认

基于TI和TD的分析及结果，可以依据表1进行该工具的置信度水平判定：

表1：工具置信度水平的确定

上表可以简要理解为：

• 如果工具的失效影响为 TI1 (不影响安全目标)， 则工具的置信度水平为TCL1；

• 如果工具失效影响为TI2（可能导致安全目标被违背或者安全功能失效），则工具的置信度水平为受TD等级的影响，TDx(x=1,2,3)分别对应工具置信度水平TCLx（x=1,2,3）。

• 如果TCL等级越高，说明该工具功能失效对安全目标造成违背的可能性越高，对于TCL2，或者TCL3等级的需要进行工具认证活动。

对于工具TCL等级高于TCL1的情况，则需要进行进一步的工具认证。安全标准对于不同的最高等级安全目标的工具认证方法提供了参考，见表2及表3定义：

表2：TCL2等级的软件工具的鉴定

表3：TCL3等级的软件工具的鉴定

基于标准要求考虑工具认证的方法一共有四种：

• 使用中积累置信度

在通过该方法进行认证时，需要注意使用的软件案例需要和该工具的设计目的保持相似，其功能定义未改变。例如，没有对该工具进行二次开发或者功能定义的改变。另外，使用过程中积累置信度的理由是基于充分适当的数据，例如，可以从该工具累计使用量（时间或频率）中获得相关功能工作状态反馈。

另外，也可以通过工具的功能异常和相应错误输出的文档化记录来追踪该工具的历史经验进行分析。通常，这部分信息可以从工具生产商的功能发布报告或者缺陷修复报告中获取。对于购买的第三方工具，适用ASIL C及以下的TCL2等级，或者ASIL B及以下的TCL3等级可以考虑该方法。

• 工具开发流程评估

在通过该方法进行认证时，通常适用于公司自己开发的工具或者从网络上获取的开源工具。需要注意的是，对于开源工具，需要收集该开源工具开发的流程是否符合适当的标准，例如汽车行业或者工控行业标准，Automotive SPICE, ISO/IEC 33000 或者CMMI。如果有相关的工具流程认证报告，则应该获取到。如果没有，则应当基于相关标准进行自评估。

对于自研或者开源工具，适用ASIL C及以下的TCL2等级，或者ASIL B及以下的TCL3等级可以考虑该方法。

• 软件工具确认

在通过该方法进行认证时，一般考虑通过设计对应的分析和测试手段对该工具在项目中的应用进行功能正确性确认。通常需要定义以下措施：

1. 基于工具功能定义，描述该工具在当前产品开发的具体用途及相关的输入和输出信息；

2. 分析该软件工具功能异常或相应的错误输出导致的后果；

3. 设计相关避免或者探测措施，并分析该措施的有效性；

4. 基于3对相关工具功能进行验证，设计充分的测试案例对该功能的正确性做检测，并验证相关避免或探测措施的有效性；

5. 形成工具确认报告。

对于第三方或者开源工具，适用ASIL D的TCL2等级，或者ASIL C及以上的TCL3等级可以考虑该方法。

• 按照功能安全标准进行开发

在通过该方法进行认证时，主要考虑自研工具的开发严格按照ISO 26262对应部分的要求进行开发及验证，或者搜集第三方工具的工具认证报告。

标准中并未要求该工具的开发需要提供完整的ISO 26262开发证据，可以基于该工具的应用范围和特性进行部分过程的裁剪。

对于第三方工具，适用ASIL D的TCL2等级，或者ASIL C及以上的TCL3等级可以考虑收集或者选择带有功能安全认证的供应商；对于自研工具，则可以基于该方法进行自认证。

03

软件工具置信度评估案例

基于章节2的过程解析，通常我们需要生成软件工具准则评估报告及软件工具鉴定报告。在项目上，通常通过Excel工具或者等同文档化工具进行维护。

软件工具准则评估报告

见表4及表5， 软件工具鉴定报告通常包含如下内容：

• 工具基础信息

表4：工具基础信息案例

以上内容主要包含上述2.1及2.2章节内容。

• 工具评估

表5：工具评估过程案例

以上内容主要包含2.3及2.4章节的内容。

软件工具鉴定报告

在评估报告中，如果有工具置信度等级高于TCL1等级，则需要单独准备工具置信度鉴定报告。基于置信度评估方法，具有多种形式的鉴定报告需要准备：

1.  收集工具供应商的工具鉴定报告，例如，图3：

图3：供应商提供工具认证报告

2. 自认证组件鉴定报告，例如，通过分析和测试对该工具进行认证，例如，图4。

图4：工具自认证报告相关内容

04

总结

本文通过对标准第8部分12章节的内容解读，并结合个人在工作中执行该过程的经验进行的总结。希望能够给各位功能安全从业者提供一个可落地的工具置信度评估的过程及案例参考，以帮助推进项目中功能安全的实施。

衷心感谢SASEtech的各位专家的审核和建议。

05

参考文献

[1] Road vehicles-Functional safety-ISO-26262-X: 2018(E), International Standard, 2018-12.

[2] TESSY_Tool Qualification V1.9, W. Schlögl,2021-11-05.

[3] ISOLAR-A ToolClassification Report V10.2.1 R01 EN, ETAS, 07.2019.

安全狙击队 / 作者

闻继伟 | 校阅

文章转载自公众号：Sasetech