![](https://csdnimg.cn/release/download_crawler_static/87740422/bg4.jpg)
White Paper: Fault Injection and Robustness Testing | Copyright ©Hitex GmbH 2018 4/16
1 What Do Standards Say?
1.1 ISO 26262
ISO 26262 [1] (automotive) mentions in part 6, section 9, table 10 “fault injection test” as a method
for software unit testing (method 1c). This method is recommended for the Automotive Safety
Integrity Levels (ASIL) A to C and highly recommended for ASIL D.
Fig. 1: Fault injection test is method 1c in table 10 in section 9 in part 6 of ISO 26262
Fault injection shall check if a software unit (which could be a function in the sense of the C
programming language) can cope with a “fault” from the outside. ISO 26262 defines a “fault” in part
1 (vocabulary), section 1.42, as an “abnormal condition that can cause an element … to fail”.
Section 1.32 defines an element as “System or part of a system including … software units.”
Section 9.4.3 of part 6 of ISO 26262 lists what the methods of table 10 shall demonstrate for the
software units. Point e) is “robustness”, and this is obviously what shall be demonstrated using fault
injection, because amongst the examples given for robustness is “the effectiveness of error
detection and error handling mechanisms.” (Another example given for robustness is “the absence
of inaccessible software.” Although software without inaccessible code is at least not less robust
than software with inaccessible code, I can see no obvious reason why especially software without
inaccessible code shall increase robustness significantly.)
1.2 IEC 61508
IEC 61508 [2] (general) mentions “fault detection” as a technique/measure in Table A.2 in part 3 of
IEC 61508. This technique/measure is seen as feature of the software architecture design. It is
recommended for the Safety Integrity Level (SIL) 2 and highly recommended for SIL 3 and 4. Section
C.3.1 in part 7 of IEC 61508 explains in more detail the intention of fault detection, which is primarily
to inhibit failures that result from wrong results, which in turn result from faults. IEC 61508 puts
some emphasis on diversity to detect software faults, which is not the topic of this white paper. This
ISO 26262[1](汽车)在第6部分,第9节,表10中提到“故障注入测试”作为软件单元测试的一种方法(方法1c)。
该方法推荐用于汽车安全完整性等级(ASIL) A到C,并强烈推荐用于ASIL D
故障注入应该检查一个软件单元(在C编程语言的意义上可以是一个函数)是否可以处理来自外部的“故障”。
ISO 26262在第1部分(词汇表)第1.42节中定义“故障”为“可能导致元件……失效的异常情况”。
第1.32节将元素定义为“包含……软件单元的系统或系统的一部分”。
ISO 26262第6部分第9.4.3节列出了表10的方法应该为软件单元演示的内容。
因为鲁棒性的例子中有“错误检测和错误处理机制的有效性”。
(关于鲁棒性的另一个例子是“没有不可访问的软件”。
虽然没有不可访问代码的软件至少不比不可访问代码的软件健壮,
但我看不出有什么明显的理由,特别是没有不可访问代码的软件会显著提高健壮性。)
IEC 61508[2](通用)在IEC 61508第3部分的表a .2中提到了“故障检测”作为一种技术/措施。
推荐用于安全完整性等级(SIL) 2,强烈推荐用于SIL 3和SIL 4。
IEC 61508第7部分C.3.1节更详细地解释了故障检测的目的,
主要是抑制由错误结果引起的故障,而错误结果又由故障引起。
IEC 61508强调了软件故障检测的多样性,这不是本白皮书的主题。