# Cognitive Principles for Remote Condition Monitoring Applied to a Rail Pantograph System
## 1 Introduction  
The running of a railway system is a complex socio-technical system [1; 2]. With so many moving parts, infrastructure and people involved, it can be challenging to keep assets operational. This challenge is becoming more acute as railways strive to remain resilient in the face of climate change-related threats [3]. Downtime in a railway service can have significant safety, economic and social consequences. Access to track is a specific safety concern, and working around the live railway to inspect or maintain assets is one of the highest sources of risk to rail staff [4; 5]. One method of reducing unexpected downtime is by using routine, preventative maintenance. This is when maintenance is scheduled and conducted at regular, predetermined intervals. Although this helps to reduce unplanned downtime, it means that maintenance is conducted whether or not there is a need for it: 'fixing' an issue that was never there in the first place, wasting time and resources, and requiring staff to go on or near track. An alternative method of scheduling maintenance, and the one explored in this project, is that of using Remote Condition Monitoring (RCM) to determine the current condition of the asset [6; 7]. With RCM, sensors on the asset process information about the current status of the asset. This may be combined with historical or environmental data to not only give an indication of the current status of the asset, but also its potential future state and failure modes. If the RCM system implies the asset is nearing the end of its life, maintenance can be scheduled; this is a form of predictive maintenance [8]. Additionally, live remote sensing can give instantaneous intelligence of emerging faults, and alarms can trigger warnings for current, or imminent, asset failure. In this way, sensing and remote condition monitoring ensures continuity of the rail service. The problem is that such technologies are typically built in a data-led, rather than user-led, manner [9; 10]. Anecdotal and empirical evidence indicates that solutions may be difficult to use for operators, either presenting the user with too much or too little information, or in a format that is difficult to interpret [11; 12]. When automation and intelligence (or machine learning) is involved, it may be difficult for the operator to build a model of how the RCM system is arriving at diagnoses [13]. In potential fault events, operators may be overloaded with alarms, many of which are duplicates or redundant [14]. Finally, significant business change is required and the shift from manual and engineering maintenance skills to digital skills is an area that many organisations are not prepared for unless the presentation of information through the Human-Machine Interface (HMI) is closely tailored to the needs of operational staff [15]. The solution is to build RCM tools that are designed with decisions and end-users in mind. This involves understanding the decision-making process of operators as they respond to tasks, and how cognition allows operators to build an understanding of both the condition of the asset or assets, and determine a course of action [16]. Work to date in human-automation systems has generally described this as a multi-stage process of notification, acceptance, analysis and clearance [17]. A programme of work to study the deployment of rail condition monitoring technologies found evidence to support the application of this general model of cognition to the rail asset context [9; 11]. However, this requires empirical validation of whether these principles would genuinely support RCM-based decision making. The following paper addresses that gap by taking the principles described in [9; 11; 17] and applying them to the design of a hypothetical demonstration RCM system in a key area for rail performance--partograph monitoring [18; 19]. These hypothetical HMIs represent the functional aspects of a potential RCM system. The contributions of this paper are:  
1.