CRITERIOS DE EVALUACIÓN Y ESTANDARES DE APRENDIZAJE

Ideally, a similarly clean distinction would exist when dealing with faults, which are the “internally caused” analog to errors, which can be thought of as externally caused problems (a full discussion of these terms was provided in Section 2.2.1). Unfortunately, there are a number of ways to classify faults: e.g., by phase of creation, or phenomenonological cause, etc., and no single classification comfortably divides the large space of possible faults. Instead, Aviˇzienis et al. describe eight fault classes, and argue that a given fault can be classified according to all eight. The classes they propose are: [3]

1. Phase of Creation: When the fault is created, i.e., design-time or runtime.

2. System Boundaries: Where the fault occurs, i.e., inside the system/element or outside of it. Note that we consider environmentally caused problems to be faults, rather than errors. Even though the fault source (e.g., water, heat, etc.) is external to the physical boundaries of the element, if it does not affect the element through an established link/port/interaction point, it is considered to be a fault3_.

3. Phenomenonological Cause: Whether the fault is caused by a human action or a “natural phenomena without human participation.”

4. Dimension: Whether the fault affects the element’s hardware or software. 5. Objective: Whether the fault is the result of a malicious act.

6. Intent: Whether or not the person who introduced the fault was aware of the impact of their choice. Note that this is separate from objective; this distinction allows the analyst to distinguish good-faith but incorrect choices from actively malicious ones.

3_{Note that problems with measured physical values would be errors rather than faults according to this}

definition. That is, if a thermometer’s sensor can be damaged by too much heat, that would be considered an error because it occurs at an established interaction point.

7. Capability: Whether or not the fault was an accident or the result of incompetence. This allows the analyst to consider whether blame is appropriate for the action that caused the fault.

8. Persistence: Whether the fault’s occurrence is permanent or transient.

These classes are combined into a 256-element possible-fault matrix, which is then re- duced to 31 base fault classes [3]. As part of the creation of SAFE, we further reduced the fault classes by eliminating fault classes 7 and 8. The Capability class was eliminated because, as Leveson argues, blame should not be part of hazard analysis but is rather a legal question. She writes that “Blame is the enemy of safety. Focus should be on understand- ing how the system behavior as a whole contributed to the loss and not on who or what to blame for it.” [30] The persistence fault class was eliminated because it does not address the source of the fault: it seems unreasonable to think that, given two fault descriptions which vary only in their persistence, an analyst will specify different detection or compensatory mechanisms.

The elimination of these classes left us with 15 base fault classes. To this list we added three more to address interaction problems, which address situations where two elements function correctly but work together in such a way that causes a successor danger. Leve- son notes that these problems are increasingly common, writing that “In complex systems, accidents often result from interactions among components that are all satisfying their in- dividual requirements, that is, they have not failed.” The 18 fault classes used in SAFE are listed and described in Table 4.1. We note that this list can be extended, shortened, or modified as necessary by domain experts in order to tailor the set of faults to a particular area. This can be done in order to align the guidewords with standardization efforts, a concept introduced by Procter et al. [6].

We note that consideration of the final three fault classifications in Table 4.1 involves elements other than the one under analysis, which seemingly violates our claims of enabling local reasoning. These classifications, though, are crucial for detecting barriers to safe

No. Guideword Description

1 SW Bug Mistakes made in software creation

2 Bad SW Design Poor choices made in software creation

3 Compromised SW Adversary tampers with software in development

4 Compromised HW Adversary tampers with hardware in development

5 HW Bug Mistakes made in hardware development

6 Bad HW Design Poor choices made in hardware development

7 Production Defect Production defects due to natural phenomena

8 Deterioration Hardware fault at runtime due to degradation over time

9 Environment Damages HW Hardware fault at runtime due to environment

10 Operator HW Mistake Operator makes a mistake while interacting with hardware

11 Operator HW Wrong Choice Operator makes a poor choice while using hardware

12 Adversary Accesses HW Adversary tampers with hardware at runtime

13 Adversary Accesses SW Adversary tampers with software at runtime

14 Operator SW Mistake Operator makes a mistake while interacting with software

15 Operator SW Wrong Choice Operator makes a poor choice while using software

16 Syntax Mismatch Sender uses a different syntax than receiver

17 Rate Mismatch Sender transmits at a different rate than receiver expected

18 Semantic Mismatch Sender and receiver interpret same value differently

Table 4.1: The 18 combined fault classes used in SAFE

composability, i.e., both syntactic and semantic interoperability (see Section 2.1.4). And— except in strongly connected systems—analysis of these classifications will not require fully global reasoning. Rather, since they involve consideration only of an element’s immediate neighbors, reasoning about them is bounded by a small constant in all but pathological systems.