Supporting the Management of Rolling Stock Maintenance with an Ontology-Based Virtual Depot

Abstract

The railway industry forecasts growth in passenger and freight traffic over the next 30 years. This places additional demands on rolling stock depot facilities, many of which were designed and built before the modern age of information technology. This paper explores the potential of improving the efficiency and effectiveness of rolling stock maintenance management to meet the challenges of the near future, by utilising advanced computing techniques. The objective of the work is to create optimised maintenance plans for a fleet of trains, considering optimal use of resources. As a “glue” for joining up functions and operations, a generic Depot and Vehicle ontology (called the Virtual Depot) is introduced. The ontology captures the structures, relationships, and attributes of objects in the Depot (rolling stock, sensors, depot assets, tools, resources, and staff). The ontology is populated with example company and fleet-specific knowledge using an automated knowledge acquisition method. This paper describes the systematic method for the creation of a Virtual Depot. Two particular aspects are discussed in detail—knowledge acquisition of fleet-specific information obtained from a manufacturer’s Vehicle Maintenance Instruction manuals and the construction of a short-term scheduling process within the Virtual Depot. Our evaluation considers the integrative aspects of the method, demonstrating how the ontological structure and its acquired specific information informs and benefits the scheduling process, in particular with respect to schedule optimisation. Results from an initial case study show there is significant potential to optimise short-term maintenance schedules, and the ability to automatically consider resource availability in short-term scheduling is demonstrated.

1. Introduction

The railway industry is under continued pressure to improve the cost efficiency of its operations. The cost of maintaining rail vehicles makes up 40% of the lifecycle cost of those rail vehicles [1]; hence, identifying methods to improve the efficiency and effectiveness of rolling stock maintenance could have a significant benefit to the overall cost of running the railways. Fleets of trains (i.e., Rolling Stock) are typically maintained at one or more maintenance depots. Management of the depot operations can be a complex task, including the movement of trains into and around the depot, management of depot resources (i.e., staff, space, equipment, consumables and spare parts, fixed plant, tools), and integration with train operations. New fleets of trains have a defined maintenance manual, including all necessary tasks to be carried out and the maximum permitted periodicity (in time or mileage) between each task. Regular Preventative Maintenance tasks are grouped together in ‘Preventative Maintenance Exams’, which are a selection of tasks that can all be typically completed within one shift. This provides a framework for depot planners to work within. The aim of this work is to carry out research into the improvement of the efficiency and effectiveness of rolling stock maintenance to meet the challenges of the near future of rail. To this end, a digital platform to support smart rolling stock maintenance is proposed. Current practices use a mix of manual and often isolated digital processes; the proposed method is to develop integrated automated processes for maintenance scheduling utilising a connected digital backbone or ‘Virtual Depot’.

Rolling stock maintenance can be divided into several categories, including inspection (checking the condition of components), servicing (such as cleaning, fueling, or topping up fluids), replacing worn or damaged components, and heavy maintenance or subsystem overhauls. Maintenance can be either ‘Corrective’, i.e., fixing a fault that has occurred during service, or ‘Preventative’, i.e., a long-term maintenance system to manage the condition of a system in good working order, replacing components before they reach the end of their life and avoiding the need for Corrective Maintenance. This paper focuses on a system to manage Preventative Maintenance. The vision for the railway of the future is to schedule maintenance interventions based on Predictive Maintenance (i.e., use of degradation models to predict when in future a component or system will reach the end of its useful life, based on a measure of the current condition) [2]; whilst this could significantly reduce the potential for removing components which have not reached the end of their useful life and the risk of components failing in service, it would make planning maintenance operations significantly more complicated as workloads could vary through-out the year. In the future, a ‘Virtual Depot’ tool will be essential to successfully implement a fully Predictive Maintenance regime, whilst also efficiently utilising depot resources.

The ‘Virtual Depot’ is centred around an ontology which contains a digital model of aspects of the train fleet, depot maintenance facilities, and resources. It forms the ‘glue’ for the integration of the structures, relationships, and attributes of the main objects (including rolling stock, sensors, depot assets, and resources) in the depot. It connects up computational components of maintenance activities, encodes explicit actionable knowledge about the depot, and provides a route to utilise recent advances in AI tools for smart rolling stock maintenance. In particular, the ontological structure can be populated with company and fleet-specific information using an automated knowledge acquisition process, meaning that the abstract structural ontology can efficiently be applied to a particular depot.

This paper’s contribution is the description of a systematic method for the creation of a Virtual Depot, and the use of a real (though anonymised) depot to show in detail the operation of the method. Two particular aspects are discussed—knowledge acquisition of fleet-specific information obtained from a manufacturer’s Vehicle Maintenance Instruction manuals, and the construction of a short-term scheduling process within the Virtual Depot. Our evaluation considers the integrative aspects of the method, demonstrating how the ontological structure and its acquired specific information informs and benefits the scheduling process, in particular with respect to schedule optimisation.

2. Related Work

There has been little research and development of enterprise-model-type frameworks performed in the railway maintenance sector. Exceptions include Durazo-Cardenas et al., who proposed an architecture to automate railway infrastructure maintenance. Three components are defined (degradation estimation, planning and scheduling, and cost analysis), with a fourth component integrating the first three components and providing a graphical user interface [3]. Although restricted to railway infrastructure only, the overall thrust of this work appears very relevant. In contrast to their work, this paper proposes a formal domain conceptualisation of the depot and rolling stock which is called a virtual depot. Debbech et al. defined a domain ‘Dysfunctional Analysis Ontology’ (DAO) of common concepts related to dysfunctional analysis aspects [4]. The proposed DAO aims to provide an interoperable view of safety analysis methods such as the Preliminary Hazard Analysis (PHA), the Failure Modes and Effects Analysis (FMEA), and the Failure Tree Analysis (FTA). The goal-oriented perspective is also considered to establish consistent safety reasoning and help with the safety decision-making process. The proposed ontology is an upper ontology which requires domain knowledge to be instantiated and used. The idea of going from virtualisation to performing dysfunctional analysis is very important but requires more modelling. Our virtualisation in addition to failure data is required to instantiate their proposed ontology to use it in the context of rolling stock maintenance.

Umiliacchi et al. discussed the benefits of using ontologies to assist with the development of a predictive maintenance tool for rolling stock [5]. They used a fragment of possible railway ontology to illustrate the idea. Details on how the ontology will be linked to the scheduling tool are left for future work. Verstichel et al. proposed a hierarchical architecture for capturing the domain ontology of the train system [6], with high-level ontologies created for each level in the hierarchy. Medina-Oliva et al. proposed a fleet-wide approach based on ontologies to ease diagnosis activities [7]. Their approach aims to capitalise on fleet knowledge and data to help decision-makers identify the causes of abnormal operations. Even if this approach was proposed for marine fleets, it falls within the aims of this paper. However, the authors have restricted the idea to the diagnostic process, but the ontology might be used for more than that such as maintenance scheduling, as explained in this paper.

Emmanouilidis et al. proposed an ontology for maintenance where failure modes and effects criticality analysis can be performed [8]. This ontology is suitable for reliability analysis and might be reused, but no wide use or links to maintenance scheduling or any other services is considered in the actual version of the ontology. Saalmann et al. proposed an integrated approach combining existing domain ontologies of various interacting systems for manufacturing systems [9,10]. Although the domain is different, the idea is similar, to some extent, to some of this paper’s aims. Likewise, Ariansyah and Pardamean have proposed an ontology in the context of manufacturing maintenance that they called a digital twin [11]. In the same direction, Jiménez et al. proposed an ontology for maintenance which looks more advanced with some decision-making support outputs such as actions that should be taken when a failure and/or threshold is reached [12]. Xia et al. added a more advanced action layer, to the maintenance ontology, for maintenance action recommendation [13]. These papers propose interesting ideas but have not yet moved to real applications as presented in this paper. The following section provides an overview of this paper’s proposed approach.

3. Proposed Approach Overview

The approach is centred on the development of a model of the data, processes, and activities for Rolling Stock maintenance, it is inspired by the area of enterprise modelling [14]. There has been a great deal of development in this sector on the collection of train operation and condition data; this work builds on that development by integrating the data within a model of the maintenance processes. Particularly in industrial and manufacturing applications, the benefits of this kind of modelling are seen as enhancing the inter-operability and knowledge-sharing of individual processes, presenting opportunities for optimisation of the whole process, and adding AI capabilities (e.g., the potential of adding automated planning) [15]. There has been significant research in developing conceptual models of enterprises in the Industry 4.0 movement [16] in a range of industrial domains. Such developments aim for:

• Integration: the idea is to integrate the objects and processes of an enterprise so that the effect of different parts of a larger system can be modelled to explore their inter-operating behaviour. In rolling stock maintenance, it is envisaged that remote condition monitoring equipment, maintenance management (scheduled, routine servicing, and condition-based servicing) and maintenance activity can all be integrated based on an over-arching ontology.
• Enhanced functionality: in this work, dynamic scheduling of activities is considered in detail, but other functions such as planning what maintenance actions are needed, or (in the longer term) autonomous enactment using robotic devices, are made feasible given the underlying ontological model.

Capturing an industrial enterprise this way is analogous to the work in model-based, enterprise information technology architecture, where the components of the architecture are precisely and formally specified. The idea of developing a systems model of enterprises, or specific functions, through ontologies, has been around for decades (e.g., Fox’s paper from 1997 [14]) and has been used for human communication, and to investigate optimisation and impact of change [17,18]. In this study, an ontology is used to assist the development of automated Rolling Stock maintenance scheduling. In future work, the system model and associated withols could be expanded to fully optimise maintenance operations considering real-time condition monitoring and operations or to assist with the introduction of automation in train maintenance depots. The tool is developed using details of a specific (though anonymised) depot to illustrate the approach.

The structure of this paper follows the steps in the approach shown in the quadrants in Figure 1. In the top left is the first step: the development of an abstract ontology capturing the activities (such as maintenance examinations), the objects and object assemblies (such as wheels and vehicles), and their attributes and associations, occurring in the rolling stock maintenance depot (see Section 4). The second step is to populate this abstract ontology with company and/or fleet-specific information so that the ontology can be used in specific processes within a particular depot (see Section 5). Step three involves using a systematic method to detail the process flow within fleet maintenance (see Section 6). This will specify the inputs and outputs of each of the major maintenance activities within the depot, such as scheduling and resource management. The fourth step is to utilise the framework created from the previous steps to plug-in supporting computer processes. In the fourth step, a short-term scheduling process schedules work to be carried out on all units with maintenance due in a three-week horizon. The process’s inputs include predicted due dates for all outstanding fleet interventions, and knowledge acquired automatically (within step two) about required resources and tooling for this particular fleet. Additionally, this step shows the benefits of being able to plug in state-of-the-art scheduling technology to perform optimisation.

4. Development of the Abstract Ontology

To inform the development of the ontology for the Virtual Depot created in this study, published ontological knowledge was reviewed to help build up the underlying conceptual model. Two schemas that were used to inform the high-level rolling stock ontology included in the ‘Virtual Depot’ tool were:

• The RailML [19] standard, which provides a set of XML schemas to enable interoperable communication between heterogeneous railway applications. The rolling stock schema includes a high-level description of rolling stock-related concepts.
• The RSSB Cross Industry RCM project [20] defined a rolling stock XML schema, including some structural aspects such as parts of the vehicle, for example, bogies (a bogie is a structural element of a train which contains two wheelsets and associated traction and braking equipment and suspension components) [21,22].

Despite the relevance of this schema, they are limited and need to be extended and formally captured in order to be of use within the Virtual Depot.

Two other related ontologies were used to help populate components within the Virtual Depot:

• The Smart Rail [23] ontology includes both the description of high-level-depot and rolling-stock-related concepts, and hence, it is very useful for our purposes. This ontology includes a location definition that we use to record the location of the train and also the depot locations. The measurement units related to the remote condition monitoring/inspection data are also included. To capture measurement and measurement units [24], we utilise an existing ontology (QUDV [24].
• The Vehicle ontology [25] is not related to railway vehicles; however, it makes use of two other ontologies, time and space location, which are needed in our context.

Armed with these pre-existing works, the Virtual Depot’s central ontology was designed using experts’ knowledge and maintenance manuals in addition to an existing rolling stock virtualisation proposed by McCluskey et al. [26]. We used OWL (https://www.w3.org/OWL/) as the language of capture, on account of it being a standard. As well as it is being well-known and well-studied, an ontology written in OWL has the benefit of a wide range of tools available to manipulate it, reason with it, and translate it to other formal languages. While OWL is not as expressive as full first-order logic, it is appropriate for the knowledge we capture where we require only light reasoning capabilities, such as inheritance, inferences, and consistency checking. Additionally, we have shown how to extend the ontology with rule knowledge, where required, by the use of SWRL [26].

To accurately capture the complex structure of a railway maintenance depot, our ontology describes both tangible (physical) and intangible (information) entities, such as vehicles or roads and maintenance activities or plans, respectively. This dual representation is necessary for realising a maintenance depot and facilitating its operation. A multitude of semantic relations are included to model the maintenance environment including typology (for instance, types of resources), membership (such as listing the parts of a vehicle), and crucial semantic associations (as an example, required entities for realising a maintenance activity). In essence, the design choices of classes and semantic relations combined with the reasoning capabilities of OWL are structured to address a series of competency questions, indicatively: (a) What types of maintenance activities are scheduled for a specific type of vehicle? (b) Which resources are required for a particular maintenance activity? (c) What is the availability of a particular maintenance road or shed for a scheduled maintenance task? (d) How often does a specific vehicle component require maintenance? (e) Can a maintenance activity be performed given the current availability of resources and staff?

In our abstract OWL ontology, four aspects are captured:

• Domain concepts (rolling stock fleet and depot, vehicles and components);
• Time;
• Space (maintenance workspace—the physical depot);
• Maintenance activities and resources (including tools, staff, fixed plant, parts, and consumables).

Figure 2 gives a pictorial abstraction of the ontology, which is formalised in the standard OWL language. For example, this asserts that a Depot has one or more Sheds having one or more roads. A Depot has a set of available Resources that can be Workers, Materials, Consumables, or Tools.

A Depot is also equipped with Machinery covering the set of the machines required for servicing, inspection, and maintenance. A fleet is usually linked to a Depot for periodic preventive maintenance. The ontology is then linked to the rolling stock ontology using the MaintenanceActivity class, where a Depot Road is considered a fixed depot resource to perform maintenance activities.

Existing community ontologies as detailed above were re-used to define a high-level rolling stock ontology. Railway experts helped to refine the Bogie fragment of the ontology. Railway standards (such as GMRT2466 Iss 5 [27]) and external proprietary resources were also used to define the Bogie subcomponent attributes and maintenance-activities-related concepts. Some components are overhauled based on age mileage, such as the vehicle’s engine. Maintenance rules, including tasks and maximum permitted periodicity between tasks, are also included in the ontology with links to the relevant rolling stock component and depot resources. The following section describes the second step of the proposed approach used to populate the abstract ontology with case-specific information.

5. Acquisition of Fleet- and Depot-Specific Maintenance Knowledge

The next step in the method is to populate the abstract ontology with knowledge describing a specific depot or application. This will include details of the company-specific tools and materials required for maintenance, contained within their maintenance manuals (see [28] for more details).

A great deal of information related to railway maintenance often exists in unstructured formats, such as text, or it is organised in company-specific maintenance instruction manuals. In order to integrate operations such as scheduling procedures within the Virtual Depot, it must be first populated with these real data. This section describes the acquisition of knowledge about maintenance tasks from maintenance manuals.

5.1. The RailMain-KG Schema

A Knowledge Graph for Rolling Stock maintenance tasks is regarded as a data source that organises the necessary information for the automation of scheduling maintenance activities. This includes resources (such as tools, parts, and consumables) and priority of the tasks. This knowledge graph developed for this study, named RailMain-KG, forms a large part of the depot- and company-specific knowledge covered by the Virtual Depot’s initial ontology Figure 2. To enable the collection of the knowledge graph, we selected a schema from the Virtual Depot’s abstract ontology containing the concepts listed below, and shown visually in Figure 3.

• Vehicle: a distinct unit of a train (e.g., carriage); maintenance activities are applied on components of a unit.
• Maintenance Task: a set of procedures for preserving the operational integrity of a vehicle.
• Activity type: a classification of maintenance tasks that relies on their effects when applied on a component. Examples include inspection, replacement, and cleaning.
• Component: functional units of a vehicle. They range from individual elements (such as doors) to integrated subsystems such as air-conditioning units.
• Requirement: essential resources and their respective quantity that are necessary for delivering maintenance tasks.
• Maintenance Resource: a high-level class that expresses elements stored in maintenance facilities that are used to carry out maintenance tasks. They can be either tools or materials.
• Material: consumable elements or spare parts utilised during maintenance tasks, indicative examples include screws, filters, washers, cloth, or oil.
• Tool: items used to physically manipulate or assess the condition of a component during a maintenance task; their main difference compared to materials is that they are not expended during the process, for instance, screwdrivers, wrenches, or oil changing station.
• Quantity: the required count of resources needed for a maintenance task.
• Priority: a rating that describes the importance of a maintenance task in terms of its potential impact on the safe operation of a vehicle.
• Safety warning: messages detailing possible hazards that may arise while conducting a maintenance task.
• Maintenance Instructions: a step-wise guide that lists the actions needed, regarding the use of resources, to successfully perform a maintenance task, while avoiding any potential hazard.

5.2. Populating RailMain-KG Schema

RailMain-KG refers to the railway maintenance knowledge graph, which is the result of populating the RailMain-KG Schema with industrial data. For the case study presented in this paper, RailMain-KG is populated with data extracted from 246 Vehicle Maintenance Instructions (VMIs) provided by a collaborating Rolling Stock manufacturer. These documents are formatted as HyperText Markup Language (HTML) pages that describe a maintenance task applied on a component, subassembly or vehicle system. Context-wise, VMIs contain information that covers the following topics.

General information: a high-level textual description of a maintenance task including its name, the component it has been applied on, and its applicability in terms of vehicle types and priority. The latter refers to enumerated labels that highlight the potential risk associated with the operation of a train when the specified task is not performed.

Resource requirements: tabular data detailing the materials and tools, along with the respective descriptions and quantities, that are essential for the task being documented.

Procedure: text formatted as an enumerated list of instructions (steps) that describe how to carry out the task in question; occasionally supplementary material is provided to encompass safety warnings and other miscellaneous notes.

Although HTML tags introduce a primitive structure over VMIs contents, the main information components are encoded as free-form text. Organising this information into rigid structures is addressed by employing a multi-step knowledge acquisition procedure (Figure 4), where relevant information from VMIs is extracted using RailMain-KG schema as a guide.

As a first step of the Information extraction, various Extensible Stylesheet Language Transformations (XSLT) are employed that use pattern-matching templates to organise the HTML-based content of each VMI into thematic sections. Six sections are introduced that include title, priority, vehicle eligibility, required resources (including both materials and tools), safety warnings, and procedure. Subsequently, a series of natural language processing tasks applied to the text of each section identify and link textual elements with the key concepts of the RailMain-KG schema (Section 5.1). In particular, each thematic section is decomposed as described below.

The Title of a VMI provides an overview of the maintenance activity, for example “Engine—Coolant Filter”. Further application of regular expressions and phrase matching on the title extracts the following information about the maintenance task: (a) descriptive name of the task, (b) type of the activity (e.g., change), and (c) component it is applied on (e.g., engine).

In terms of eligible vehicles, safety warnings, and procedures, regular expressions are employed to break down each section into indivisible elements and link them to the corresponding concepts within RailMain-KG. Text about procedures is converted from enumerated steps into an actual list of individual texts that represent individual steps of the procedure. In terms of the extracted elements within text about safety warnings, vehicle categories and priority, they are considered instances of namesake entities within the schema.

The extraction phase is concluded with the identification of the required resources of the VMI in question, along with their respective quantities. The diverse industrial terminology found within VMIs renders this step challenging, and thus, it is approached as an entity-linking task. The process involves mappings textual references of resources to concepts within the RailMain-KG schema using elastic search across an extensive list of industrial vocabularies that are provided by the collaborating manufacturer. These vocabularies are comprehensive compilations of industrial terms covering a broad range of materials and tools commonly associated with railway maintenance tasks. The elastic search utilises the K-nearest neighbours (KNN) search based on hierarchical navigable small world graphs [29]. More specifically, term frequency-inverse document frequency (tf-idf) on character 3-g is used to generate vectors for every term found in the industrial vocabularies. Projecting these vectors into a non-metric space and applying KNN (using cosine similarity as a distance function) enables the retrieval of the most relevant industrial concept given a text sample and a similarity threshold (empirically set to 80%). The respective quantities of the identified resources are determined using regular expressions specialised on recognising numerical patterns.

The knowledge acquisition pipeline concludes with the transformation of the extracted information into RDF triples, adhering to the RailMain-KG schema (as depicted in Figure 3). Each VMI instantiates a maintenance task within the schema that it is extended with various semantic annotations connecting it with the aforementioned thematic sections. Simple or repetitive entities (such as vehicles or warnings) are captured with repeated properties, while complex entities (such as resources and procedures) are implemented using reification. To this end, a maintenance task is linked with an intermediate object (for example procedure), which in turn incorporates all the properties that describe the complex entity (such as the individual steps of the procedure). In the case of resources, they are represented by an auxiliary object that describes both the type and respective quantity of the resource in question. The final graph is created and serialised using the RDFLib library [30], as shown in Figure 5, which depicts the conversion of a task into a graph-like structure.

5.3. Accessing RailMain-KG

Automating maintenance scheduling operations, especially within short-term horizons (1–2 weeks), requires up-to-date information about maintenance interventions’ due dates, fleet availability constraints, day restrictions and workforce, and availability of required resources. Although most of this information exists in machine-processable format, currently, the tools and materials required for each maintenance intervention are mainly stored in VMI documents.

This section describes how to utilise the knowledge within RailMain-KG by executing powerful semantic searches in order to inform resource-aware scheduling strategies. In particular, we illustrate the use of RailMain-KG to acquire the essential requirements of a set of maintenance tasks and generate a digital output that can be directly incorporated into scheduling algorithms. This output is obtained through SPARQL queries on the RailMain-KG instance, which is hosted on a GraphDB [31] platform; furthermore, the results are displayed in a tabular format for the sake of readability. We refer the interested reader to Papadakis et al. [28] to further explore the capabilities of RailMain-KG and the quality assessment of the extracted information.

Resource-aware scheduling: A typical approach adopted by railway maintenance depots for resource allocation is the recurrent resupply cycle. This approach ensures the availability of spare parts and other materials by restocking them on predefined time intervals. The underlying strategy of this approach is to maintain an excess of resources regardless of their actual demand. Although it is an intelligent solution, this method lacks adaptability, which limits any potential for automation. For instance, changes in depot policies, such as modification of maintenance routines, might result in a shortage or unnecessary surplus of resources. Information within the RailMain-KG can inform short-term scheduling processes to proactively manage resource availability. Indicative examples include: (a) postponing tasks when resources are insufficient; (b) prioritising maintenance tasks based on their criticality and the available stock levels; (c) proactive inventory management to ensure the timely completion of all maintenance tasks. Resource-aware scheduling significantly enhances the inventory management and planning of preventive maintenance. The ‘Rail Value for Money Study’ suggests that rolling stock maintenance costs have around 27 influential variables [1]; the most influential costs are 13.8% spare part cost, 11% life cycle cost, and 6.4% preventive maintenance costs. The work proposed in this paper will help reduce spare parts management and preventive maintenance costs.

Figure 6 presents a query that retrieves the requirements for every maintenance task in a selected Preventive Maintenance Exam. For the sake of simplicity, this example includes four random tasks; the output is formatted as a table that provides a consolidated summary of the necessary materials along with their stock availability (stock quantities are arbitrarily set for demonstration purposes). To enhance readability, only five materials are displayed; quantifiers “exactly” and “at least” indicate whether the VMI specifies an exact quantity for a material or if it should be used as needed. Finally, the priority column classifies the significance of each material element by highlighting its role in tasks that have an impact on the safe operation of a vehicle.

5.4. RailMain-KG to Inform Scheduling Processes

The knowledge captured in RailMain-KG has great potential in extending the capabilities of scheduling procedures, hence further advancing automation in the field of train maintenance. While the idea of resource-aware scheduling was briefly touched upon in the previous section, mainly focusing on the part of information retrieval, Section 8 provides an elaborate real-like example that better outlines the benefits of resource-aware scheduling.

Resource management within a railway maintenance depot encompasses the consistent operational efficiency of the depot but also it should embrace the perspective of resource replenishment. The resource-aware approach can transcend conventional timetabling practices to active monitoring of the status of the available resource stock. For instance, activities that focus on proactive reordering of depleted or constrained resources can be integrated into traditional scheduling frameworks. To this end, infusing scheduling procedures with knowledge graphs about the assets of a maintenance depot not only improves the operational stability of the facility but also ensures that maintenance activities in the depot will continue to run smoothly.

In live scheduling scenarios, such as rescheduling, conducting a resource availability check is essential, as unpredictable changes might lead to reactive resource reordering. Consequently, new schedules must be constrained by the number of units participating in maintenance interventions, as well as the time that is needed to acquire the necessary resources, if there are any shortages. This further supports resource-aware scheduling, as it facilitates effective management in terms of which vehicles should undergo the entire cycle of maintenance tasks while competing over limited resources during restocking windows.

In the following section, step three of the proposed approach is discussed.

6. Development of the Process Model

Whereas the first two steps described in Section 6 and Section 7 deal with the static and structural aspects of the fleet maintenance system, in this next step, we map out the possible data flows through the key maintenance processes. To perform the capture, we use a standard method— the Structured Analysis and Design Technique (SADT) actigram (known as IDEF0 [32]), and use as input both general information about maintenance depots and specific information from our collaborating company. An SADT activity diagram has a set of inputs from the left side of the box, a set of outputs from the right side of the box, a set of controls from the top side of the box, and a set of mechanisms (tools and techniques) from the bottom side of the box. SADT activity diagrams are used to capture the preventive maintenance scheduling process covering the communication between the involved processes/subprocesses.

Figure 7 shows a process description of an example preventative maintenance scheduling system that we developed in SADT. In this example, routine PM Exams and wheel turning (i.e., use of a lathe to remove the top surface of the wheels to remove small cracks and return the wheel cross-section to the design profile) are scheduled depending on the cumulative unit’s mileage since the last maintenance intervention whilst heavy maintenance and component overhaul are scheduled based on the cumulative component’s mileage since the last maintenance intervention (see Figure 7, A1. A1.2, and A1.3 processes input). Scheduling of these PM interventions can be viewed as a three-stage process: (1) long-term, (2) short-term, and (3) daily schedule (see Figure 7). The maintenance activities: PM Exams, wheel turning, overhaul and heavy maintenance scheduling processes are represented with activities A1, A1.2, and A1.3, respectively. The PM exams scheduling activity (A1) takes the units’ mileage since the last maintenance intervention as an input (taken from dedicated software) and produces the upper-bound limits (due date) as an input for short-term scheduling. Hence, each of the three activities is performed based on the unit’s mileage (except the overhaul activity as mentioned above) and all of them are constrained by the depot capacity such as the maximum number of units accepted per day and fleet availability. We assume that all these three long-term schedules are generated using a dedicated maintenance management tool. A0 is a process updating the units’ (components’) mileage. Note that the use of the term “schedule” here is approximate long term, as the output of the process (A1) is more accurately described as a sorted list of due dates for activities.

The short-term scheduling (A2) is a week-based framing of the long-term schedule where fragments of the long-term schedules are used as inputs, and the upper-bound limits (due dates) for each maintenance activity are used as constraints in addition to the fleet availability, depot capacity, and staffing rosters. Short-term scheduling (A2) tends to be manually performed in depots and relies on the planning team’s experience and skills.

The daily scheduling (A3) is one day of the short-term schedule where any new tasks (unplanned) might be dealt with at this level based on the outputs of the re-scheduling activity (A4), which is mainly controlled by the supervisor’s decisions. The re-scheduling activity (A4) output can also impact the long-term and short-term schedules. The daily update activity (A5) deals with the daily reports where the supervisor’s decisions about the reported failure reports are considered to update the maintenance decisions; the daily reports about the unfinished/finished maintenance tasks are also used to update the status of the units/components and their mileage.

In the long-term schedule, only mileage and maintenance intervention intervals are available while a clear view and forecast of the depot resource availability are available at a short-term scale. Short-term schedules are subject to change due to unplanned maintenance interventions and uncertainties leading to more frequent rescheduling. Any change to the short-term schedule may cause many changes requiring rescheduling to deal with resource allocation, constraints, and costs. The daily scheduling process is related to the maintenance standards where daily actions (based on daily updates) are required in some cases, such as taking the rolling stock unit out of service immediately or within 24 h following some defect detection such as wheel flats.

In summary, long-term scheduling (the first stage in Figure 7) is based on the long-term rolling stock maintenance requirements (specified by the manufacturer, maintainer, or government regulations) to ensure sets of preventive maintenance interventions are performed regularly (Exams). The next scheduling stages then deal with more constraints, such as fixed depot resources. The next two stages must also be designed to deal with unplanned maintenance and unforeseen situations (see process A4 and A5 of Figure 7).

Previous work appears to have not dealt with maintenance scheduling, considering these three stages, see [33]. Existing work also either simplifies the rolling stock Preventative Maintenance scheduling problem by making many assumptions or proposing a new maintenance strategy and then an optimisation based on the new proposal. Some work has attempted to combine long- and short-term scheduling into one stage, but in doing so, adding the complexity and uncertainties of updating the daily mileage.

The short-term scheduling, step 4 of the approach, is discussed in the next section.

7. Short-Term Scheduling

Step 4 concludes the steps of the method—the implementation and ‘plugging in’ of the computational processes proposed in Section 6 within the SADT framework description, demonstrated here for the short-term scheduling process. Scheduling is the process of placing activities in a time horizon (with time units such as days), which includes the starting and ending times of the activities while honouring a set of temporal and resource constraints. Temporal constraints might be precedence (e.g., two activities can be executed simultaneously or the one before another) and deadline (which includes penalties if not satisfied). Resources constraints are the constraints related to human resources, equipment, and material resources. Resource constraints refer mainly to the quantity and available capacity of the resources required to perform a specific activity. Invariably, one may want to derive schedules which optimise one or more criteria such as to minimise the non-respected deadlines or to reduce the gap between a scheduled date and a due date for a specific activity [34]. This goal is usually motivated by the resulting costs when deadlines are not respected. This gap is known as the earliness/tardiness criteria with penalties [33].

In some areas, such as preventive maintenance of rolling stock, earliness/tardiness criteria of the preventive maintenance interventions are critical. The PM maintenance intervention is preferably scheduled Just-In-Time (JIT), i.e., just in time for the due date, to avoid the earliness/tardiness costs. Rolling Stock preventive maintenance tasks are typically grouped into ‘Exams’, which comprise a range of inspections and light maintenance activities; these exams and heavy maintenance activities must be carried out on a predefined frequency based on either time or distance [33].

Depending on a specific depot practice and regulations, maintenance intervals can include a tolerance, as shown in Figure 8, where a maintenance intervention might be performed before the due date or after. A cost is usually associated with early/late maintenance. Maximum maintenance intervals are effectively defined in law as a condition of operating the vehicle. Performing maintenance activities too soon is a waste of resources while performing them too late is penalised, as it means that the unit would not be available for passenger service whilst it is waiting for maintenance.

7.1. Short-Term Scheduling Creation

This section describes the process of short-term scheduling creation in terms of its inputs, outputs, and constraints related to depot resources and fleet availability.

The main input, as shown in Figure 7 (process A2), is a previously produced and up-to-date long-term schedule specifying the PM interventions’ due dates: an abstract example of this is given in Scheme 1 showing a list of maintenance tasks that are due for different units in the fleet. The long-term schedule is usually updated every day as a result of the daily update of the fleet units’ mileage and maintenance status. As an example, the actual mileage of each unit on a given day will influence the short-term scheduling of the maintenance interventions based on the new due dates. Daily updates will inform the long-term scheduling process via mileage value update as shown in Figure 7 (processes A2 and A0).

As depicted in Scheme 1, the long-term schedule specifies the next required maintenance task for each unit in the fleet and the due date for that task. The short-term scheduling process takes the due dates per unit where the maintenance intervention type is specified as an input.

In addition to the constraint brought about by the long-term schedule, a set of constraints determine the short-term schedule (see Figure 9): (1) Depot resource constraints are also defined (such as Drops, Jacks, and Wheel Lathes). Constraints related to the depot resources should be considered such as the number of total and/or available maintenance roads, the working days (e.g., in this example only one road is used for exams and can receive two units per day), etc. (2) Other constraints related to the earliness/tardiness of the maintenance interventions such as the allowed tolerance in terms of early/late maintenance. (3) Fleet availability constraint (e.g., 5 units out of a fleet of 50 are allowed to be out of service per day). An example of a short-term schedule is given in Scheme 2. In this example, a constraint on the available roads for maintenance is considered where only two units might be received per day.

When doing short-term scheduling, as depicted in Figure 9, either manually or using a computer-assisted technique (any technique automating the scheduling process), cost reduction is usually borne in mind, which may refer to various things such as the earliness/tardiness costs. For PM scheduling, reducing the gap between the due and the scheduled dates of the units’ maintenance interventions is very important.

A long-term schedule (including due dates) is inferred using the units’ mileage and maintenance intervention interval (see Figure 2). More than one long-term schedule can be considered when multiple sites and/or fleets are considered. In the following sections, two automated methods are introduced: the first one uses a computer-based method, without optimisation, mimicking the human manual scheduling process (see Section 7.2). The second one, discussed in Section 7.3, is a Mixed Integer Programming (MIP) model for short-term scheduling optimisation. A comparison between these two methods is given in Section 7.4.

7.2. Computer-Based Short-Term Scheduling—Without Optimisation

The first method used for short-term scheduling was a normal computer-based method without optimisation. This method aims to mimic the manual scheduling process and serves as a reference to evaluate the proposed optimisation method. The planning team first schedules the maintenance interventions with higher earliness/tardiness costs. Hence, the computer-based method without optimisation uses a priority parameter to help order the maintenance interventions based on their importance (e.g., earliness/tardiness costs). The method uses the long-term schedule (due dates) and priorities to inform the development of the short-term schedule while following the resource restrictions, maintenance window, and fleet availability requirement. Within the specified scheduling horizon, the first available slot is allocated to the first maintenance intervention in the queue (sorted by priority). The time slots per day are computed based on resource availability and maintenance duration. No optimisation technique is used to generate the short-term schedules and no reasoning about costs is taken into account. This is also the case when schedules are produced manually when multiple choices are available. The main inputs are depot resource constraints related to the various maintenance interventions, the fleet availability constraint (expressed as the number of allowed out-of-service units per day), and the maintenance interventions’ due dates of the fleet units. Scheme 2 is an example of the produced short-term schedule where only four days a week are available to receive units within a depot. The table shows the results of one maintenance intervention type scheduling where two units only can be received per day. The gap between the due and scheduled dates is the number of days before the exam. The negative value of the days before the exam field means the maintenance intervention is scheduled after the due date.

7.3. Short-Term Scheduling Optimisation

The MIP model presented in this section is an improved formulation of the model proposed by the authors in [33]. This improvement helped make the model linear rather than quadratic when executed in addition to reducing the decision variables number, and including an additional constraint to cover the resource availability.

Scheme 3 is a sample of a case study to describe the considered problem. This version of the proposed model does not cover the duration of maintenance tasks. This sample shows a set of PM interventions with their intervals (frequency), their duration that might be influenced by the depot resources used (see a and b cases when different roads are used), their required depot resources, and their earliness/tardiness costs.

The main objective is to schedule maintenance interventions in time to reduce maintenance costs. The problem is to specify the starting time of each maintenance intervention for each unit that maximises the use of the predefined intervals, and thus, minimises the maintenance costs related to wasting the maintenance interval or penalty associated with exceeding the fixed interval period.

• Objective function: Minimise the maintenance costs (by maximising the interval use and avoiding tardiness penalties). Maximise fleet availability (this is optional and end-users are free to consider it or remove it from the model). Subject to:

• Fleet availability should meet the availability limit requirement at all times (hard or soft constraint).
• The maintenance starting date should be within a tolerance range [max days before, max days after] compared to the due date.
• Some maintenance interventions can be performed on specific days of the week only.
• Each maintenance intervention has specific depot resource requirements.

• where: T: number of periods (horizon in days). N: number of units. F: Number of fleets. M: number of maintenance interventions. S: number of skills.

I = {1,⋯, N }. T = {1, ⋯, T′}. F = {1, ⋯, F′}. M = {1, ⋯, M′}. G = {1, ⋯, G′} as a list of lists, where: i: index of a unit, t: index of a period, f: index of a fleet, m: is the index of a maintenance intervention, and g is the index of a maintenance intervention group, where each group includes a set of maintenance interventions m.

• Parameters and variables:
• $CA{P}_{mt}$: maximum available resources within a depot at a period t (in terms of the number of units it can receive at a period t for a maintenance intervention m). For example, a depot can receive 10 units at a time t for a maintenance intervention type 1 based on the available resources.
• $Ca{p}_{gt}$: maximum available capacity within a depot at a period t (in terms of the number of units it can receive at a period t for a maintenance intervention group g). For example, a depot can receive two units per day for a maintenance intervention group 2 performed on road one (a shared resource).
• $E{P}_m$: earliness penalty of a maintenance intervention m if performed earlier. Likewise, a penalty $T{P}_m$ is a tardiness penalty for a maintenance intervention m if performed after the due date. The maintenance interventions’ due dates are outputs of the long-term scheduling process and are inputs for the short-term scheduling process.
• $U_{imt}$: a binary variable, equal to 1 if a unit i had a maintenance intervention m at period t and 0 otherwise.
• $U_{imt}$ = $\left\{\begin{array}{cc}1\hfill & \mathrm{i}\mathrm{f} \mathrm{a} \mathrm{u}\mathrm{n}\mathrm{i}\mathrm{t} \mathrm{i} \mathrm{h}\mathrm{a}\mathrm{d} \mathrm{i}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{v}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n} \mathrm{m} \mathrm{a}\mathrm{t} \mathrm{a} \mathrm{p}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{o}\mathrm{d} \mathrm{t}\hfill \\ 0\hfill & \mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e}\hfill \end{array}\right.$
• $A_f$: availability constraint parameter related to a fleet f. $A_f$ specifies the number of possible out-of-service units at all times. The availability of the fleet should not be less than a certain threshold and can be computed as follows: Availability = Fleet size −$A_f$.
• $C_f$: is the cost of unavailability of the fleet per unit if higher than the limit $A_f$.
• $E_m$: is the maximum number of time units t (e.g., tolerance in days) a maintenance intervention m can be performed earlier.
• $L_m$: is the maximum number of time units t (days) a maintenance intervention m can be performed late.
• $D_{im}$: due date of the maintenance intervention m on unit i.
• $S_{im}$: start date of the maintenance intervention m on unit i.
• Problem formulation:

  $$\begin{array}{cc}\hfill min& \sum _{i=1}^N\sum _{m=1}^{M^{\prime }}max(0,D_{im}-S_{im})\ast E{P}_m+max(0,S_{im}-D_{im})\ast T{P}_m\hfill \\ \hfill \mathrm{s}.\mathrm{t}.\\ \hfill & U_{imt}==1\forall i\in I,\forall m\in M,t\in S_{im}\left(1\right)\hfill \\ \hfill & \sum _{i=1}^N{U}_{imt}\le CA{P}_{mt}\forall m\in M,\forall t\in T\left(2\right)\hfill \\ \hfill & \sum _{i=1}^N{U}_{imt}\le Ca{p}_{gt}\forall m\in g,\forall g\in G,\forall t\in T\left(3\right)\hfill \\ \hfill & S_{im}\ge D_{im}-E_m,\forall i\in I,\forall m\in M\left(4\right)\hfill \\ \hfill & S_{im}\le D_{im}+L_m,\forall i\in I,\forall m\in M\left(5\right)\hfill \\ \hfill & S_{im}\ne t,\forall i\in I,\forall m\in M,\forall t\in W\left(6\right)\hfill \\ \hfill & \sum _{i=1}^N\sum _{m=1}^{M^{\prime }}{U}_{imt}\le A_f\forall t\in T\left(7\right)\hfill \end{array}$$

The objective function is to minimise the total late/early maintenance costs.

• Constraint (1): changing the binary variable $U_{imt}$ to 1 when an m maintenance intervention is scheduled at a period t for a unit i.
• Constraint (2): ensuring that only the possible number (depot capacity) of units is sent on a period t for maintenance type m. The information about the available resources is produced by the process discussed in Section 5. For this constraint, the end user can specify a time slot where this restriction should be applicable, such as four days from the first day of the time horizon.
• Constraint (3): ensuring that only the possible number (depot capacity) of units is sent on a period t for maintenance intervention m in group g. Maintenance interventions requiring the same depot fixed resources are grouped in one group.
• Constraint (4, 5, 6): making sure the start date of the maintenance intervention m $S_{im}$ is in the range [$D_{im}-E_m$, $D_{im}+L_m$], avoiding the depot non-working days, and $S_{im}\ne t$ (i.e., not equals t) when t is a not working time unit.
• Constraint (7): making sure the availability required per period t is guaranteed, where the number of units i sent to maintenance at any period t is less or equal to the availability limit $A_f$.

The objective function may include the cost of fleet unavailability, and thus, the constraint (7) can be modified to a hard limit stating a maximum number of units $A_f$ that can be out of service at any time; in the objective function, we add a cost of fleet unavailability when $A_f$ is reached.

The proposed MIP model was encoded using Python, with the DOCPLEX package, and solved with CPLEX. The choice of CPLEX is motivated by the fact of being one of the best commercial solvers; however, in the future, a more general solution using multiple solvers, such as CPLEX and SCIP [35], will be considered using the Pyomo optimisation modelling language. DOCPLEX provides an easy environment to implement MIP models. Decision variables, constraints, and the objective function are translated directly from the mathematical formulation to the equivalent code. Equivalence constraints are used for binary variables, while normal constraints are used for integer decision variables. Both methods use data extracted from the ontology using OWLready2 and SPARQL queries under Python. The graphical interface is a Matlab GUI calling a tkinter, see Figure 10.

7.4. Comparison of Short-Term Scheduling Methods

This section presents a brief comparison of the short-term scheduling methods discussed above. The following scenario includes four maintenance interventions and a fleet of 50 units, where only two units can be received per day for any of these maintenance interventions. In addition, four units are allowed to be out of service per day and maintenance is carried out from Monday to Thursday only.

The two short-term scheduling methods used to produce short-term schedules and both have used the long-term schedule depicted in Scheme 4.

Scheme 5 and Scheme 6 depict a schedule generated with optimisation (using the optimisation-based technique) and a schedule generated without optimisation (using the computer-based technique), respectively. With this simple scenario, the optimisation model showed a lower cost of maintenance, i.e., 32 against 57 without optimisation. To make the computer-based technique without optimisation perform better, more instructions should be hard coded while such complexity is left for the solver in the case of the optimisation-based technique. As shown in the tables, the two schedules are relatively similar; the main change is that the computer-based method has scheduled maintenance intervention ‘1’ for unit ‘11119’ 11 days before the due date, whilst the optimisation-based technique has moved things around to allow this task to be done much closer to the due date, only 4 days early. The optimisation-based technique also has reduced the earliness of maintenance intervention ‘1’ for unit ‘11101’ from 4 days to 1 day. Overall, these comparatively small differences in the schedules have delivered significant benefits in cost, based on the cost scale used in this study.

As the optimisation scheduling method outperforms the computer-based one, it was used to evaluate the virtual depot approach when linked to the scheduling process, which is discussed in Section 6. Further details about the comparison between these two scheduling methods as well as the evaluation of the short-term optimisation method can be found in [33].

8. Benefits of the Use of the Method

In the sections above, a systematic method for capturing a virtual view of a maintenance depot’s operations dealing with railway rolling stock is described. This method leads to the specification and population of a system-wide ontology, and a specification of relevant operations. This is illustrated with the acquisition of VMIs’ data and shows how a short-term scheduling operation can be added to the system. Already towards the end of Section 5, we discussed the advantages of integrating the acquired knowledge graphs to inform the scheduling processes. In this section, the power of the integrated system is further explored, and in particular, we consider the improvement it makes compared to using stand-alone scheduling tools.

The evaluation of the combined scheduling and resource retrieval process relies on constraint (2) of the MIP scheduling model as a key connecting point between the resource retrieval and scheduling processes (see Section 5 and Section 7, respectively). To set up the experiments, a real long-term schedule sample is being used. Scheme 7 illustrates a three-week schedule that involves several PM interventions, along with their due dates. For confidentiality reasons, the fleet identifier is converted to 111 in unit names and the PM interventions’ names were hidden. The PM intervention names are converted to numbers and are shown in column ‘MaintIntervention’, including 16 different maintenance interventions. These maintenance interventions are also grouped into groups as shown in column ‘GR’ following their depot fixed resources requirement.

As no earliness/tardiness costs are available, see Section 7.3, the authors used the certification intervals to calculate the costs (see earliness cost column in Scheme 7). Assuming that the earliness cost of doing a maintenance intervention of the shortest interval is 10, all other costs are calculated referring to this. The tardiness cost will be higher than earliness costs due to government regulations and safety risks. The authors fixed the tardiness cost to 20 for all maintenance interventions, but this value can be derived from intervention criticality levels and penalties related to late maintenance.

Scheme 8 depicts a short-term schedule produced by the MIP model, see Section 7.3, without considering the constraint (2), which requires inputs from the resource retrieval process, see Section 5. This shows four outputs for each date as the fleet availability constraint is set to ‘4’, which means that for any day of the scheduling horizon, up to four units can be scheduled for maintenance. In this scenario, unit ‘11148’ maintenance task ‘1’, depicted in Scheme 7, is due on the 3rd of May. The short-term schedule produced took the due date of maintenance intervention ‘1’ required for unit ’111481, as depot resources are available and depot capacity is sufficient (constraint 3). This intervention is scheduled just in time, as depicted in blue, where the Days Before Exam shows ‘0’, meaning the scheduled date is equals to the due date. When the maintenance is scheduled after the due date, this field value is negative. Likewise, maintenance ‘1’ is scheduled for units ‘11145’ and ‘11141’ on the 10th of May, which is the due date. However, before proceeding with the scheduling process, it is important to collect the available information about the necessary resources for every intervention within the schedule. The scheduling process can then include inputs about resource availability per maintenance intervention as the number of units that can be maintained, based on the store, before re-ordering. This option is covered by the MIP model discussed in Section 7.3 via constraint (2).

Figure 11 shows the short-term scheduling process inputs from both ontology and resource retrieval process (described in Section 7 and  Section 4, respectively). When a resource retrieval process is used and thus constraint (2) is activated, two options are available.

When the short-term scheduling process is executed one week or more before the scheduling horizon starting date, an estimation of the number of units scheduled for a maintenance intervention m can be given for the whole scheduling horizon period. With this estimation, when used by the process discussed in Section 5, a re-order can be triggered as and when required. However, in the case where a re-scheduling is required and if, in unforeseen situations, some resources to perform some maintenance interventions are available, then the scheduling process should not schedule these maintenance interventions before re-ordering and receiving them. In this case, querying the database and getting resource availability is required. In what follows, a description of the resource retrieval process and scheduling process with constraint (2) is given.

For the sake of simplicity, this example focuses only on consumables. Each intervention is decomposed into its constituent tasks and soft similarity measures, and based on the Levenhstein distance [36], they are employed to link each task in the schedule to the corresponding entity RailMain-KG knowledge graph. The output is a catalogue of maintenance task identifiers, which reflect those tasks that conform to at least 95% similarity. Resource retrieval is carried out with a series of SPARQL queries against RailMain-KG, with one query executed per intervention. The aim is to aggregate the material requirements of each intervention and assign them to priorities.

Listing 1 depicts the template query, while

Table 1. Indicative results of a resource retrieval query.

Material-Name	Material-ID	Quantifier	Overall	Priority
damp cloth	srsm:M8	at least	8	SAFETY CRITICAL
copper washer	srsm:M68	exactly	6	SAFETY CRITICAL
lacquer marker	srsm:M66	at least	3	SAFETY CRITICAL
mild detergent	srsm:M2	at least	3	SAFETY CRITICAL
mounting bracket	srsm:M1834	at least	3	MISSION CRITICAL
engine oil	srsm:M99	at least	2	MISSION CRITICAL

illustrates an indicative output. Column “material-id/name” are identifiers, “quantifier” specifies whether the quantity constraints (“overall”) are absolute or represent minimum thresholds, and “priority” reflects the top priority value among the maintenance tasks that require the material in question. The retrieved information is being used as input in the subsequent step of the short-term schedule.

Listing 1. “Resource retrieval per intervention. Prefixes are rdf/s and srsm/s (RailMain-KG schema and annotations).”

select distinct ?item ?material ?quantifier

(IF(MIN(?quantity) = 0, # if there are undefined quantities

SUM(?quantity)+COUNT(?quantity), # suggest the minumum

SUM(?quantity)) AS ?overall) (MAX(?priority) as ?priority)

where {

#tasks found in the intervention

values ?t {...}

?t srsms:hasRequirement ?req;

srsms:hasPriority ?prior.

?prior rdfs:label ?priority.

?req srsms:requiresItem ?material;

srsms:requiresQuantity ?quantity.

?material rdf:type srsms:Material;

rdfs:label ?item.

# adjust quantifier if there are undefined quantities

BIND (IF(?quantity = 0, ‘‘at least’’,‘‘exactly’’) AS ?quantifier)

} group by ?material ?item ?quantifier order by Desc(?overall)

Scheme 9 depicts a scenario where the required resources for maintenance 1 are not available after querying the database. In this scenario, constraint (2) is applied for the first three days from day one of the scheduling horizon. This means that the non-availability of the resources for maintenance 1 should affect the first three days of the short-term schedule only. A re-order should allow resource availability after this period of time. Scheme 9 shows that maintenance intervention ‘1’ for unit ‘11148’ is moved to the 4th of May with days before exam value equal to −1 meaning it is scheduled one day late. However, maintenance ‘1’ for units ‘11145’ and ‘11141’ is scheduled for the 10th of May, as the resources will be available again by then.

Figure 12 shows a one-week forecast of the number of units that will be received for maintenance at the depot. The left side is a forecast based on a short-term schedule produced without information about the available resources (constraint 2) and the right side is a forecast based on a short-term schedule produced with constraint 2 and information about the available resources. The left side shows the scenario depicted in Scheme 8 while the right side shows the one depicted in Scheme 9. Knowing the number of units expected for each type of maintenance for the scheduling horizon will help better manage the store especially when scheduling is performed for a week or two later. However, if rescheduling is required, knowing the available resources in the store will help schedule maintenance based on resource availability for the period required to get them.

This section showed two short-term scheduling scenarios, without and with the data retrieval process. The scheduler produced optimal solutions and reacted to the information provided by the data retrieval process as shown in Scheme 9. The use of the scheduling and data retrieval processes provides a resource-aware scheduling process allowing automated and optimised production of short-term schedules.

The proposed scheduling process should be extended to cover the maintenance duration, as it will directly impact fleet availability. Maintenance interventions requiring more than one day will be out of service for the whole maintenance duration. The way this type of intervention is performed should be understood before including it in the scheduling. The main missing information is the occupation of the fixed depot resources during that period. Higher abstraction will be considered in the future to make sure the model will consider multiple fleets, multiple maintenance sites, and a variable fleet availability constraint (a value per day of the week) instead of one value.

The search algorithms are performing very well so far; however, when cost values are very close, the performance decreases when 1 min is required to get the optimal solution. Some depots can include many sites and fleets, and thus, this execution time might increase. Developing some heuristics to ensure quick scheduling will be considered for real-time rescheduling.

9. Conclusions

This paper introduced the idea of a Virtual Depot for rolling stock maintenance, which includes an abstract generic ontology populated with company- and/or fleet-specific information using a knowledge acquisition process. A four-step method was detailed for the creation of the Virtual Depot and illustrated and evaluated through the use of a real, though anonymised depot.

Two particular aspects are discussed in detail—knowledge acquisition of fleet-specific information obtained from a manufacturer’s Vehicle Maintenance Instruction manuals and the construction of a short-term scheduling process within the Virtual Depot. The integrative aspects of the method are evaluated, demonstrating how the ontological structure and its acquired specific information informs and benefits the scheduling process, in particular with respect to schedule optimisation.

Previous work has not considered such a wide view as is captured in the Virtual Depot, such as resources, vehicle assemblies, and maintenance tasks. There also appears to be no existing published research where maintenance scheduling models are connected up within an enterprise-level conceptualisation, nor which has used VMIs within an automated process to populate the ontology with specific company/fleet knowledge.

Initial results in Section 7 show that the scheduling optimisation tool has significant potential for improving the efficiency of rolling stock maintenance operations. Whilst results in Section 8 demonstrate the potential for resource-aware scheduling, by using the Virtual Depot model including, the fleet and depot ontology and knowledge extracted from maintenance instructions as part of the scheduling process. The current analysis uses assumed values of earliness and tardiness penalties for the optimisation process; further work is required to refine the earliness and tardiness parameters and link them to real costs and component costs in an overall maintenance optimisation algorithm.

The manual short-term scheduling process is tedious, error-prone, and cost-independent. The planning team should consider many enterprise components and integrate inputs manually to produce this schedule. The virtual depot will enable an inter-operable way of data exchange and the short-term scheduling process will produce an optimal schedule based on the up-to-date data exchanged via the virtual depot. The data acquisition and retrieval process combined with the short-term scheduling model enables depot resource requirements forecast to avoid unwanted situations. In the future, the tool can be expanded to consider a broader range of inputs, and the tools developed to automatically extract data into machine-readable Knowledge Graphs from existing documents will help that process.

In future work, further case studies will be investigated to improve and extend the Virtual Depot including the optimised scheduling process. Abstract ontology will be developed to include both spatial concepts and developed to assist with the implementation of Predictive Maintenance. A concrete connection with other depot management processes will be developed, such as train movements and spare part management processes. The scheduling process should include maintenance interventions’ duration and multiple depot sites/fleets that are not yet covered by the current proposed model. Predictive maintenance using condition monitoring and historical data in addition to uncertainties and reactive (corrective) maintenance should be included to enable overall maintenance optimisation. The extraction of granular details from maintenance instruction manuals requires advanced methods that surpass the capabilities of the currently implemented XML transformations and simple natural language processing tasks. In pursuit of optimising knowledge acquisition, as in the case of populating the Rail-Main KG, we plan to utilise powerful large language models to provide a template-free entity extraction and linking pipeline.

This paper has focused on the potential benefits of using the virtual depot to optimise short-term scheduling; further work is required to evaluate the optimised scheduling tool over a longer time frame; this can initially be done by considering ‘extended short-term scheduling’ (e.g., considering three cycles of three-week scheduling). It is assumed that a longer time frame gives more opportunity for accumulating benefits, which will be confirmed in further work. Developing detailed schedules for further into the future can have some limitations, as it is difficult to predict the influence of unexpected operational events. The virtual depot, including ontology, maintenance process knowledge graphs, and scheduling tool, has potential applications beyond scheduling optimisation, including process optimisation, depot layout, and resource management; however, further detailed work is required to develop the tool for these applications.

The main challenge related to implementing the proposed ‘Virtual depot’ for scheduling optimisation will be how the system can respond to unexpected events. Results in Section 7.4 show the schedules can be developed with significantly reduced ‘Cost’ compared to a computer-based method which mimics manual scheduling. However, in practice, units may become unavailable for maintenance on their scheduled day due to operational reasons or unplanned maintenance may be required to correct in-service failures. A dynamic scheduling tool based on the virtual depot tool could cope with all these unexpected events and reformulate a modified schedule to accommodate them; however, it would be necessary to set up the required interfaces to collect inputs about these operational events in real time.