写在前面

本系列文章主要讲解道路车辆功能安全ISO26262标准的相关知识，希望能帮助更多的同学认识和了解功能安全标准。

若有相关问题，欢迎评论沟通，共同进步。(*^▽^*)

---

1. 道路车辆功能安全ISO 26262标准

8. ISO 26262-8 支持过程

七、可信的软件工具

3. 需求和建议

1. 基本要求

如果安全生命周期包含开发一个系统或它的硬件或软件元素时使用的软件工具，这样 ISO 26262 所要求的活动或任务依靠正确的软件工具的功能，工具适用的处理步骤的相关输出不检查或验证，这样的软件工具应当遵守本条款的要求。

2. 预定工具置信水平或资格的有效性

如果软件工具的置信度评估或资格在特定的安全项目或元素的开发中独立执行，这个预定的工具置信水平或资格的有效性确认后，按照 ISO 26262-2:2011，表 1，软件工具被用于开发一个特定的安全项目或元素。

注：收集软件工具信息可以是一个跨组织活动，从而有利于分类或认证。

3. 软件工具符合评价标准或其资质

使用软件工具时，应当确保其用法、环境、功能限制、一般操作条件符合其评估标准或其资格。

例：使用的版本和配置、用例与实施预防措施或故障检测相应的错误输出应记录在这个软件工具的合格报告中。

4. 规划软件工具的使用

• 一个软件工具的使用应当有计划，包括确定：

——确定软件工具的版本号

——软件工具的配置

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

——有关软件工具的使用案例

注 1：用例可以描述用户使用工具时软件工具或软件的应用的功能。

注 2：用例可以包括用于软件工具执行时该工具的配置和环境的要求。

——软件工具执行环境

——所有安全要求中分配给项目或元素中可以避免的最大的 ASIL，如果软件工具出现错误并产生相应的错误输出。

注：最大的 ASIL 可对于一个特定的开发，还可以是软件工具的通用用法被确定的假设。在这种情况下一个假设的预先确定的 ASIL 用假设来验证。

——软件工具的认定方法，需要在置信等级的基础上来确定

• 可以的话，确保软件工具的评价或使用，下列信息可用:

——软件工具的描述特性，功能和技术性能

——适用的用户手册或其他使用指南

——操作所需的环境的描述

——若可以的话，描述软件工具在异常的操作条件下的行为

例 1 异常操作条件可以通过禁止编译器的组合开关，环境不遵守用户手册或不正确的安装。

例 2 异常操作条件下的预期行为可以抑制输出产生，用户指示或用户报告。

——若可以的话，描述已知的软件工具故障和适当的保护措施，避免或者解决方案的措施

例 1 使用指南或解决已知的故障，通过编译器或者使用一组有限的模型构建块限制代码的优化。

例 2 保障包括预防通过使用约束，已知故障和问题的检测报告，提供安全的替代技术来执行相应的活动。

——软件工具所需的置信程度的确定过程中鉴别软件工具检测故障的措施和相应的错误输出

注：检测错误和相应的输出的措施可以解决已知的和潜在的软件工具的输出错误。

例：冗余软件工具的输出比较，执行的测试，静态分析或者评论，分析软件工具的日志文件。

5. 软件工具的分析评估

• 软件工具的使用描述应包含下列信息:

——目的

例：仿真功能，源代码生成，或嵌入式软件的测试，安全生命周期的定制或 ISO 26262要求的活动和任务的自动简化。

——输入和预期输出

例：后续开发活动所需的输入数据，源代码，仿真结果，测试的结果，,或 ISO 26262的其他工作产品。

——若可以的话，环境和功能的限制

例：嵌入软件工具的开发过程，不同软件工具的共享数据和其他使用条件，防止或检测软件工具故障的措施。

• 软件工具分析和评估的目的,以确定:

——一种可能性，特定软件工具的故障在被开发的安全相关的项目或元素中被引入或无法检测错误。这被分类表示为工具影响（TI）。

1)TI1 时应是没有这样的可能性;

2)TI2 应在所有其他情况下;

——防止软件工具产生故障和输出相应的错误措施，或检测到软件工具发生故障和产生了相应的错误输出措施。这通过错误检测类的工具 (TD)来表示:

1)TD1 应当选择如果对故障及其相应错误的输出将阻止或发现有高度的信心；

2)TD2 应当选择如果对故障及其相应错误的输出将阻止或发现有一定程度的信心；

3)TD3 在其他所有情况下应选择。

注 1：预防或检测可以通过过程步骤，任务冗余或软件工具本身的合理性检查。

注 2： TD3 通常适用于在开发过程中没有系统性的措施可用的情况，因此只能随机的检测软件工具的故障和其相应的错误输出。

注 3：如果一个软件工具，用于验证另一软件工具的输出，评估后续软件工具时和后续软件工具的 TD 选择时考虑那些软件工具之间的相互依赖性。

注 4：使用情况分析细节水平需要允许适当地确定双方的 TI 和 TD。

例 1 ，可以选择 TD1 的情况，一个代码生成器生成的源代码是根据 ISO 26262验证。

例 2 使用指南可以防止发生故障，如一个编译器产生的不正确或模棱两可的代码解释。

• 如果TI或TD的正确选择尚不清楚或不能确定，TI和TD应该保守估计。
• 如果软件工具定制的开发过程的 ISO 26262 所要求的活动或任务是省略的，TD2 不得选择。
• 基于价值观决定 TI 和 TD 的类，所需的软件工具的信心水平取决于下表，如下表所示：

		Tool error detection
		TD1	TD2	TD3
Tool impact	Tl1	TCL1	TCL1	TCL1
	Tl2	TCL1	TCL2	TCL3

• 软件工具认证

TCL1 软件工具分类不需要认证方法。

TCL2 软件工具认证分类见下表，如下表所示：

Methods		ASIL
		A	B	C	D
1a	Increased confidence from use in accordance with 11.4.7	++	++	++	+
1b	Evaluation of the tool development process in accordance with 11.4.8	++	++	++	+
1c	Validation of the software tool in accordance with 11.4.9	+	+	+	++
1d	Development in accordance with a safety standard	+	+	+	++

TCL3 软件工具认证分类见下表，如下表所示：

Methods		ASIL
		A	B	C	D
1a	Increased confidence from use in accordance with 11.4.7	++	++	+	+
1b	Evaluation of the tool development process in accordance with 11.4.8	++	++	+	+
1c	Validation of the software tool in accordance with 11.4.9	+	+	++	++
1d	Development in accordance with a safety standard	+	+	++	++

软件工具认证应当记录以下内容:

——软件工具的标识和版本号

——软件工具分类的最大工具置信水平与评价分析参考

——预先设定的最大 ASIL 或特定 ASIL，任何可能违反安全要求的相应软件工具故障和产生错误的输出

——软件工具的配置和环境是合格的

——个人或组织进行认证

——申请方法依照 11.4.6.1 认证

——措施的结果应用于软件工具的认证

——如果适用的话，使用约束和故障识别进行认证

• 在使用中增加信任度

使用中增加信任度的方法按照以上两个表格软件工具的认证需求条款。

增加软件工具信任度，提供以下证据:

——以前使用的用于相同目的的软件工具具有可比较的用例、确定的操作环境和具有类似功能的限制

——在使用中增加信任度的理由基于充分和足够的数据

注：数据可以通过大量的积累使用(如持续时间或频率)。

——软件工具的规范是不变

——发生故障和相应的错误输出需要在软件工具以前的使用中以系统化的方式积累

在开发活动中以前使用的软件工具的经验应分析和评估通过考虑以下信息:

——软件工具的标识和版本号

——软件工具的配置

——使用的详细信息和相关数据

例如，软件工具的使用特性和相关软件工具的用例的使用频率

——文档，描述软件工具的故障和相应的错误输出以及导致他们的条件

——以前版本的监控列表，在相关的版本的每个故障清单

——保障措施，已知故障的规避措施或对策，或错误输出的检测措施

例如，使用报告的来源可以日志；软件工具的供应商提供的版本历史发表勘误表

• 工具开发过程评估

——申请认证的软件工具开发过程评估的方法按照以上两个表格，分条款应符合要求。

——开发过程中软件工具的应用开发应符合一个适当的标准。

注：对开放源码的工具，一些社区的标准也可以适当。

——应用于软件工具开发的开发过程的评价由合适的国家或国际标准和合适的应用评估开发过程来演示评价。

注：这个评估覆盖足够的开发和相关的软件工具子集的特性。

例，使用基于汽车的 SPICE,CMMI,ISO 15504 评估方法。

• 验证的软件工具

——“验证的软件工具”根据以上两个表格的应用资格的软件工具，分条款应符合的要求。

——软件工具验证应当满足下列条件:

a) 验证措施应当证明该软件工具符合规定要求，

注：测试评估功能性和非功能性的质量方面的软件工具应进行验证。

例：编程语言的标准有助于定义验证有关编译器的要求。

b) 软件工具的故障及其相应的错误输出应当验证并根据信息分析其可能的后果和避免的措施。

c) 软件工具对异常操作的反应应当检查;

例：工具的可预见的误用，输入数据不完整，不完整的更新软件，禁止使用的组合配置设置。

• 确认评审软件工具认证

本条款适用于 ASILs(B)，C，D。使用的软件工具的置信度应按照ISO 26262 - 2:2011 表 1 评估以确保:

——正确评估所需的软件工具的置信度

——软件工具的认证符合其需要的置信度

---

本文章是博主花费大量的时间精力进行梳理和总结而成，希望能帮助更多的小伙伴~  🙏🙏🙏

后续内容将持续更新，敬请期待(*^▽^*)

欢迎大家评论，点赞，收藏→→→