## 4 Case Study
### Analysis  
Due to space limitation, the analysis artefacts presented in the following are not intended to be exhaustive, but illustrative, to demonstrate the application of the proposed methodology. Additionally, technology-specific details have also been abstracted for commercial sensitivity. An overview of the proposed methodology is provided in Figure 3. The information provided in Section 4.1 can be regarded as data gathered by _Step 1_ of the proposed methodology. Architecture diagrams like Figure 5 can be used to derive a list of the system components. Surely, more details gathered (if possible) in _Step 1_ would provide more useful inputs to the subsequent steps. Based on the data gathered in _Step 1_, _Step 2_ deduces the unacceptable accidents/losses and their causal hazards. Considering the properties of Li-ion batteries, the unacceptable losses should include fire/explosion caused by Li-ion batteries, and the ageing of Li-ion batteries. These losses are usually associated with some hazards shown in Table 2. Based on the specifications of the _system_ components, potential vulnerabilities may be identified by utilizing relevant vulnerability databases, security testing tools, etc. For example, CVEs (Common Vulnerabilities and Exposures) of EMU can be identified via a particular network scanner called Nmap. _Step 3_ identifies a list of signals that the _system_ components may receive and output, considering the data gathered by _Step 1_. All signals shown in Figure 5, such as \"Modbus request\" and \"Measurements\", are necessary signals. As for unnecessary signals, it was found that EMU (by default Bluetooth-enabled) emits Bluetooth signals that are not required by any operations of the _system_; Bluetooth device could be hacked; therefore, \begin{table}
\begin{tabular}{c c} \hline \hline
**ID** & **Description of hazard** \\ \hline H1 & Battery ignition \\ H2 & Battery temperature high (beyond 60 degrees) \\ H3 & Battery over-charged \\ H4 & Battery over-discharged \\ H5 & Acidic/corrosive/flammable/toxic substances due to electrolyte leakage \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Some examples of the _system_ hazard. from the point of view of Security, any wireless connectivity (including Bluetooth) that is not being used or needed should be disabled to minimize the attack surface. For every identified signal, _Step 4_ examines how would its receiver (_system_ components) behave in response to inappropriate signal. As mentioned in Section 3, a signal can be inappropriate in four ways; not all of them are always applicable. An excerpt of result of _Step 4_ is depicted in Figure 6, describing how PCS Controller behaves both internally and towards the _system_ components which it interacts with when the input signals S1 and S3 are not provided or incorrectly provided. As shown in Figure 5, PCS controller is supposed to interact with PCS inverter and EMU. Basically all behaviors of PCS Controller, described in Figure 6, can be hazardous. They may also imply flaws in the algorithm of PCS Controller that should be fixed for improving the safety or security; for instance, in case of not receiving latest measurements, PCS Controller should somehow alert the maintenance personnel to check on PCS Sensors. For every identified signal, _Step 5_ identifies the potential causes (PCs) of inappropriate signals. Figure 7 gives an example of PCs for inappropriate signal S1 (\"Configuration needed\"), which are derived from the _template_ (shown in Figure 4); from the perspective of PCS Controller, receiving incorrect or not receiving S1 means input failure; therefore, according to the branch \"Input Failure (IF)\" of the _template_ (depicted in Figure 4), S1 failure is mainly caused by S1-I1, S1-I2 and S1-I3. These PCs can be further elaborated by applying the relevant nodes of the _template_; the elaboration is iterative until a reasonable middle ground is achieved.