## 3 Proposed S&S Analysis Methodology
AF denotes that the component's algorithm is inadequate; IF--the input required by the component is unavailable or inadequate; DD--the component is damaged or disrupted. Certainly, not all nodes of the tree are applicable to every component of the system; each node may be decomposed into low-level nodes to further explain the causal factor; the analysts are required to apply only the relevant ones during elicitation of PCs. It is worth noting that the _template_ is designed considering the information shown in Figure 1; any causal factors (shown in Figure 1) can be mapped to the proposed _template_; for example, \"feedback delays\", \"inadequate or missing feedback\", \"inappropriate, ineffective or missing control actions\" are basically input failures to their receivers; besides, \"inadequate operation\", \"inadequate control algorithm\", and \"process model tampered\" can be considered as algorithm failures; furthermore, any elements including actuators may potentially be tampered, which is clearly not included in STPA's control loop diagram (c.f. Figure 1). Therefore, the _template_ is deemed useful as it provides a systematic means of stating the PCs using consistent and concise words. Stating the PCs succinctly is important to minimize confusions, as a large quantity of PCs are usually identified during the analysis and processing them in subsequent analysis stages can be time-consuming. Nevertheless, the _template_ could be tailored for specific applications by comprising more precise and relevant causes/nodes. _Step 6_ is intended to derive the S&S requirements from identified PCs and STRIDE analysis. STRIDE is among the most popular threat-modelling methods [24, 43]; it evaluates a system against six main categories of threats, namely, Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Specifically, we employ MTMT (Microsoft Threat Modelling Tool) to perform STRIDE analysis. Based on the Data Flow Diagrams (DFDs) which we build corresponding to the analysed system, MTMT would automatically output a list of potential security threats. By addressing the MTMT-identified security threats, it is reasonable to assume that CIA (Confidentiality, Integrity, and Availability) of analysed system is adequately ensured. The MTMT output can be regarded as security requirements which could also be used to refine the pre-identified PCs. Put crudely, Spoofing or Tampering may cor  
Figure 4: A template, manifested as a tree, that shows the three generic factors of Component Malfunction (CM), namely Algorithm Failure (AF), Input Failure (IF), and Damage/Disruption (DD). Denial of service--IF or DD; and Elevation of privilege--AF or DD. All the identified PCs (called _causal scenarios_ in STPA) are then translated into requirements (called _constraints_ in STPA), simply by negating them. For instance, a PC stating \"[PERSON] provides wrong command to [PERSON] because [PERSON] receives incorrect data from [PERSON]\" can be translated into a requirement stating \"[PERSON] must receive correct data from [PERSON] so that [PERSON] provides correct command to [PERSON]\". _Step 7_ aims to ensure that the derived set of S&S requirements has been adequately fulfilled. The process is typically lengthy because the analyst team is required to meticulously check a large set of requirements for the following reasons: (1) refining vague requirements with more precise details and keywords (e.g., components and signals); (2) removing repetitive, redundant, or obsolete requirements; (3) identifying potential conflicts between requirements; (4) planning and deciding the measures for satisfying the requirements based on criteria like cost incurred and measures' effectiveness. Making decisions (especially prioritizing which requirements or measures) can be challenging without having an accurate understanding of the impact which a decision may bring.