# Cognitive Principles for Remote Condition Monitoring Applied to a Rail Pantograph System
## 6 Discussion
This is because it is unlikely that the role of control room operators is to look solely for faults in this specific part of the railway system, and even if it was their sole job, they would be part of either a rolling stock- or infrastructure-focused organisation, likely resulting in a bias of knowledge toward one side. This reflects other work demonstrating the importance of considering pre-existing organizational processes in the user-centred design of remote condition monitoring systems [35] and the need for information to often cross organizational boundaries [36]. There are three key limitations to the work. First, the number of subject matter experts was small, though by no means exceptionally so for this phase of work [48]. Rather than this being the end of evaluation, the work here forms a first stage of formative evaluation to be expanded upon in further design iterations [33]. Second, the HMI demonstration was non-interactive, and ideally a higher-fidelity implementation should be developed next to allow quantitative data collection (e.g., in terms of time to process a fault, false detections, error rates, etc.). This would also support the use of survey approaches such as System Usability Scale [49] and A/B testing [50]. Third, this evaluation would be more robust, and the case for the theory be more substantial, if quantitative data for the proposed HMI were \begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Screen** & **Notification** & **Acceptance** & **Analysis** & **Clearance** \\ \hline Suggestions for & Train speed & Vehicle ID number & Suggestion of whether a fault is caused by & Head code \\ additional features/ & Ambient temperature & GPS Location & infrastructure or rolling stock & Vehicle ID \\  & Contact wire deviation & Number of times this & & \\  & & alarm has happened in & Infographic to spot & \\  & A colour coded & this area & fault trends more easily & Time/Date/User stamp \\  & indication of how far & & for each cleared event \\  & past the expected value & History of any & A colour coded & \\  & something is, rather & engineering works or & indication of how far & A feature that \\  & than a binary indication & repairs to this & past the expected value & automatically sends a \\  & & pantograph/location & something is, rather & text/email with the \\  & & & than a binary indication & fault information and \\  & & & & corrective action to the \\  & & & indication of how far & \\  & past the expected value & & & chosen person/people \\  & something is, rather & & & A feature to \\  & than a binary indication & & automatically produce \\  & & & & a fault or condition \\  & & & & report with one click \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Additional information requirements for HMIs. compared with data from a more conventional remote condition monitoring system. Once the limitations discussed above have been addressed, the next stage will be to reapply the proposed architecture and designs to a new rail asset context, such as other track assets or rolling stock, to assess transferability.