## 2 Literature Review
### SAFE (Systematic Analysis of Faults and Errors)  
Inspired by STPA, [PERSON] et al. initiates SAFE [34] with steps identical to those of STPA--i.e., defining high-level losses, followed by identifying potential hazards and modelling the system's control structure. From the control structure model, instead of examining any control actions like STPA does, SAFE immediately looks into the system component that is nearest to the controlled process. On this component there are basically five steps performed: (i) define the process model of the component (ii) define the erroneous inputs that could cause the component to produce hazardous output; (iii) document how erroneous inputs could lead to hazardous outputs as well as how to prevent/mitigate them; (iv) identify the component's internal faults based on a standardized set of fault classes; (v) document how internal faults could lead to hazardous outputs as well as how to detect/prevent them at design or run-time. These five steps are then recursively performed on every component that precedes the current component, until all system components have been covered.  
As for addressing Safety and Security in SAFE, in step (iii) [PERSON] et al. examines how the receiving component is negatively affected by seven categories of erroneous inputs derived from a particular security adversary model [35] established in 1983. These seven categories of erroneous inputs basically summarize all possible ways that the inputs can be erroneous regardless of whether they arise due to accidental faults or intentional attacks. Simply put, SAFE disregards the causes or sources of erroneous inputs; it claims that both Safety and Security concerns can be addressed merely by focusing on the effects of a minimal set of erroneous inputs on every component of the system and not on the underlying causes of erroneous inputs. In [PERSON]'s earlier work [36], the erroneous inputs considered in SAFE were derived from a taxonomy proposed by [PERSON] et al. [37] in 2004.  
Figure 2: An example of graphical representation that shows which safety or security constraints could potentially be violated at every component of the system.  
It is undeniable that both accidental faults (e.g., broken input transmission cable) and intentional attacks (e.g., injection by Man-In-The-Middle (MITM)) would result in the same erroneous inputs (e.g., corrupted message) to the receiving components. However, identifying potential causes/sources of erroneous inputs is likely to result in more effectively planned measures; note that this is a common advantage of bottom-up hazard/threat analysis techniques. For instance, if input injection by MITM is deemed impossible in light of the component's realistic environment, then perhaps it would be more feasible or cost-effective to just ensure the input transmission cable's reliability than requiring the legacy component to filter out injected messages. Besides, while SAFE acknowledges that the system design has to be updated once the measures are introduced to fulfil the derived requirements, it seems to not mention whether/how the resultant changes should be analysed.  
In contrast with SAFE, the proposed S&S analysis methodology--as discussed later in Section 4--explicitly considers both accidental/natural factors and intentional/malicious causes (of erroneous inputs) in order to determine a more practical and cost-effective set of S&S requirements (and thus S&S measures); besides, any resultant changes in system design shall be reflected by the proposed matrices to help the analyst check the overall equilibrium among various aspects of the analysed system.