# Cognitive Principles for Remote Condition Monitoring Applied to a Rail Pantograph System
## 3 High-Level Conceptual Architecture  
In order for the user to make the decisions described above, they require information regarding current condition and behaviour, in addition to further context such as weather and historical data regarding the pantograph and location of the event. Prior to the design of the HMIs, a theoretical condition monitoring system was designed based on the methods of measuring pantograph and overhead line wear discussed in literature. The information displayed by the user interface and the data recorded by the theoretical condition monitoring system to derive it are shown in Table 1.  
The system was designed so that the storage of data over a twenty-five-second period is triggered if any of the sensor readings have exceeded their acceptable limits (though each OHLE/Pantograph system will have differing acceptable ranges). Each twenty-five-second data set is stored in a database as one \"Event\".  
From here, it is possible to describe a conceptual model or architecture whereby the specific aspects of condition monitoring are linked to the four stages of decision-making. Figure 3 details a high-level view of the joint cognitive system and the interaction between data, the decisions being made and the user. Each blue process correlates to one screen of the user interface and one decision to be made in the four stages of alarm handling. With these decisions forming the backbone of the system, it is possible to sequentially  
\begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt} p{142.3 pt}} \hline \hline
**Information** & **Data** & **Data Recording Method(s)** \\ \hline Indication of pantograph contact strip condition & Maximum lateral acceleration (m/s2) of the contact wire at the most recently passed sensor & Optical accelerometers attached to the top of the contact wire oriented perpendicular to the direction of the tracks every 0.5 km [22] or a vison-based system [26] identifying movement parameters through machine learning \\ \hline \multirow{4}{*}{
\begin{tabular}{} \end{tabular} } & Average train speed (km/h) over contact strip lifetime & Average speed is calculated from wheel rotation using a digital counter on one of the train’s wheelset shafts: Speed (m/s) = Wheel Circumference (m) \(\times\) Shaft rotations per second (rps) \\ \cline{1-1}  & Distance travelled (km) over contact strip lifetime & Distance travelled also calculated from wheel rotation: Distance (m) = Wheel circumference (m) \(\times\) Total number of shaft rotations \\ \hline Risk posed by force between contact strip and contact wire & Contact force (N) over a 25 s period & When using the model described in [25] to calculate the dynamic contact force, for this low-speed application the new method described in [25] is not required and the vibration of subsystem 1 (the pantograph contact strip) can be treated as simple rigid-body motion. One accelerometer placed at the centre of the panhead can be used to calculate the inertial force and three load cells placed underneath the contact strip to measure the force of subsystem 2 (panhead) acting on subsystem 1 (contact strip). \\ \hline Risk posed by the weather Weather Weather Type Ambient temperature (\({}^{\circ}\)C) & Wind speed (m/s) Weather type Ambient temperature (\({}^{\circ}\)C) \\ \hline Risk posed by the & Whether an arc is detected or not (Yes/No) & Using video footage from a camera mounted to the roof of the vehicle that is analysed using a vision-based algorithm like that of the firefly algorithm used in [26]. \\ \hline \hline \end{tabular}
\end{table}
Table 1: Identification of potential data types for pantograph RCM.  
guide the user though the fault handling process one decision at a time. This allows for the progressive disclosure of information, only displaying information that assists the user in making the decision required at that moment in time and avoiding the display of information that does not.