Functional Model of the E-Dispatcher Information System for Railway Automation and Telemechanics Maintenance Management ()
1. Introduction
The reliable operation of railway automation and telemechanics (RAT) devices is essential for ensuring train traffic safety, continuity of transportation processes, and efficient use of railway infrastructure. Maintenance of these devices requires systematic planning, assignment of tasks to responsible personnel, monitoring of work execution, and accurate recording of technical results. However, the existing maintenance process relies considerably on paper-based plans, journals, reports, and telephone communication. As a result, maintenance information is distributed across different documents, repeated data entry occurs, and rapid access to equipment maintenance history becomes difficult [1]-[3].
Previous studies have developed approaches for electronic technical documentation, automated monitoring, equipment accounting and control, and mathematical modeling of railway automation processes. In particular, formalized, graphical, matrix-based, and algorithmic models have been proposed for electronic document management and the monitoring of railway automation and telemechanics equipment. Nevertheless, integration of maintenance planning, dispatcher tasks, responsible personnel, execution results, electronic evidence, journal records, and audit trails within a unified information environment remains an important issue [4]-[8].
The specific contribution of E-dispatcher can be distinguished by its functional scope. Morant et al. [4] integrate corrective-maintenance data to support failure analysis and maintenance policy decisions, whereas Bulavsky and Vaisov [9] use timed Petri nets to model technical-document circulation and assess documentation quality. Building on these complementary directions, the present study focuses on the operational coordination of maintenance tasks and their associated evidence within a single station- and distance-level workflow.
The distinguishing features of the proposed model are the explicit integration of three functions: 1) linking each station and RAT device to its maintenance plan, task, responsible executor, electronic journal record, and audit information; 2) incorporating task type, DSP/DNP operational permission, and employee authorization into a formal task-release decision; and 3) connecting station-level journal and task modules with distance-level planning, dispatcher monitoring, and reporting through a centralized maintenance database. The contribution lies in this combined maintenance-management workflow, rather than in electronic storage or the Karnaugh-map method alone. These features constitute a proposed functional architecture; their implementation and effects on maintenance performance require separate validation.
Therefore, this study proposes a functional model of the E-dispatcher information system for railway maintenance management. The system establishes information relationships between railway stations, RAT devices, maintenance plans, dispatcher tasks, responsible personnel, electronic journal records, and audit trails. The proposed approach is intended to provide centralized maintenance information management, improve the traceability of maintenance activities, and create a digital maintenance history for railway automation and telemechanics equipment.
2. Analysis of the Existing Maintenance Management Process
2.1. Organization of the Existing Maintenance Process
The existing maintenance process involves several organizational levels, including the SHChDS dispatcher, the head of the line maintenance section (LIU), senior electromechanics (SHNS), electromechanics (SHN), and electricians (SHNM). Maintenance activities are performed according to annual and four-week schedules, while information concerning assigned and completed tasks is exchanged through paper documents, local journals, and operational communication. This distributed organization complicates centralized monitoring of task execution and the rapid retrieval of equipment maintenance history [6] [10]-[12].
The normative basis for the maintenance planning, periodicity, and work organization described in this section is the internal instruction Sh-01-2021 of JSC “O’zbekiston temir yo’llari”, which addresses the planning of maintenance work, compliance with maintenance intervals, and the organization of maintenance activities for signaling, interlocking, and blocking devices [13].
2.2. Limitations of the Existing Maintenance Information Flow
The existing maintenance information flow is characterized by the use of separate paper-based plans, local journals, reports, and operational communication between different organizational levels. Information concerning maintenance planning, task execution, diagnostic results, and work confirmation is therefore stored in different sources rather than in a centralized database. This makes it difficult to establish a continuous relationship between a specific railway automation and telemechanics device and its maintenance history [9] [14]-[17].
In addition, deviations from maintenance schedules and repeated equipment failures may not be identified promptly, while dispatcher control remains dependent on telephone communication and manual verification. These limitations demonstrate the need for an integrated information system that connects maintenance plans, tasks, responsible personnel, execution results, electronic records, and audit information within a unified digital environment [5] [18]-[20].
3. Functional Model of the E-Dispatcher Information System
The proposed E-dispatcher information system is designed to integrate the main processes associated with the maintenance management of railway automation and telemechanics (RAT) devices within a unified information environment. The system combines maintenance planning, dispatcher task formation, assignment of responsible personnel, execution monitoring, recording of diagnostic and maintenance results, and electronic confirmation of completed work. This approach establishes continuous information relationships between a railway station, RAT device, maintenance plan, dispatcher task, responsible employee, electronic journal record, and audit trail. The functional architecture of the E-dispatcher system is organized as a multilevel structure. At the management level, the SHChDS dispatcher, LIU management, and SHNS perform maintenance planning and monitor permissions and task execution.
Maintenance information is stored in the centralized database, while the electronic archive stores maintenance evidence, timestamps, and audit records. At the maintenance level, annual and four-week plans, DSP or DNP permissions, maintenance tasks, measurements, and electronic evidence are processed and recorded. An important feature of the proposed architecture is the separation of maintenance information processing from safety-critical train control functions. Diagnostic information from the operational control system is transferred to E-dispatcher through a read-only interface, while control commands from E-dispatcher to the ARM-EC and EC controller are not permitted. Thus, E-dispatcher is intended to support maintenance management and technical information processing without directly interfering with the safety-related train control circuit [18] [21].
In the proposed architecture, the read-only boundary must be enforced at the data-exchange layer as well as in the user interface. E-dispatcher is to receive a restricted set of diagnostic values and status records through a segregated export gateway or replicated data store, rather than through a connection that permits access to train-control command functions. The export interface must expose no write, configuration, reset, or control-command operations to maintenance-system accounts. Network access rules and service credentials must restrict communication to the approved diagnostic export path; authentication, access logging, and validation of received data are required. Where physically enforced one-way transfer is required, a unidirectional gateway should be used. Transfer failures, excessive request rates, and loss of E-dispatcher availability must not interrupt the operational control process; diagnostic exports should therefore be decoupled and resource-limited. These are design requirements, not evidence of an implemented or certified safety boundary, and must be verified before operational integration.
3.1. Functional Components and Information Flow
The functional model of the E-dispatcher information system integrates the main participants, technical objects, and information flows involved in the maintenance of railway automation and telemechanics devices. The principal components include the dispatcher, maintenance management personnel, responsible maintenance staff, railway automation and telemechanics devices, the E-dispatcher server, the centralized maintenance database, and the electronic archive [22] [23].
The information flow begins with the formation of annual and four-week maintenance plans and the creation of maintenance tasks. Each task is associated with a specific station and device, assigned to a responsible employee, and linked to the required permission and execution period. After completion of the maintenance activity, measurements, work results, and supporting evidence are recorded electronically. The resulting information is stored in the centralized database and electronic archive with the corresponding timestamp and audit record [24] [25].
Thus, the proposed functional model establishes a continuous information relationship between station, device, maintenance plan, task, responsible employee, execution result, electronic journal record, and audit trail, providing a structured basis for centralized maintenance monitoring and the formation of a digital maintenance history [9] [15] [16] [22].
3.2. Minimization of the Maintenance Task Execution Function
To prevent unauthorized maintenance operations, the E-dispatcher system applies a logical decision rule before a maintenance task is released for execution. The decision depends on the type of maintenance task, operational permission, and the authorization of the assigned employee. Let x1 denote a scheduled maintenance task, x2 an approved operational task, R the DSP/DNP permission, V the authorization of the responsible employee, and Y the decision to release the task for execution. The safety condition is defined as:
(1)
where x3 = 1 only when both operational permission and employee authorization are available. According to the truth table, the task execution function is represented as:
(2)
The admissible input combinations were minimized using the Karnaugh map. The grouping of adjacent logical states produces two implicants:
(3)
. (4)
Therefore, the Boolean function is written as:
(5)
After extracting the common variable x3, Equation (5) becomes:
(6)
Since
, the final E-dispatcher decision rule is:
(7)
According to Equation (7), a scheduled or approved operational maintenance task is released for execution only when the applicable DSP/DNP permission condition and the authorization of the responsible employee are simultaneously satisfied. Table 1 presents the truth table, while Figure 1 illustrates the admissible logical states and Karnaugh map used to obtain the decision rule [26].
Table 1. Truth table for the maintenance task-release function.
x1 |
x2 |
x3 |
Y |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
0 |
0 |
0 |
1 |
0 |
1 |
1 |
1 |
1 |
0 |
0 |
1 |
1 |
1 |
1 |
Figure 1. Admissible logical states and Karnaugh map.
For the proposed task-control model, permission requirements are determined by the operational effect of the task, rather than by whether it is scheduled or unscheduled. Tasks involving temporary withdrawal of a RAT device from service, disconnection of circuits, intervention in interlocking or blocking functions, or testing that can affect train movements belong to the permission-required category. They must not be released until the applicable DSP/DNP permission has been obtained. Activities confined to maintenance-plan preparation, archive retrieval, report generation, or viewing diagnostic information through the read-only interface do not themselves require operational permission. Non-intrusive inspections and measurements are treated as conditionally permission-required: their classification depends on the approved procedure and the operating conditions of the specific device. These categories define the proposed model; the applicable operational instructions determine the requirement for each actual maintenance task.
In Equation (7), R is interpreted as the satisfaction of the applicable operational-permission condition. For a permission-required task, R equals 1 only when the required permission is valid and covers that task; otherwise, R equals 0. For a task that is explicitly classified as not requiring operational permission, R equals 1 because the permission condition is not applicable, rather than because a permission has been issued. A task whose permission requirement has not been established is not released. Employee authorization V remains mandatory in both categories. This interpretation distinguishes mandatory permission for operational interventions from conditional permission requirements without changing the Boolean expression.
The obtained minimized Boolean function provides a compact decision rule for the E-dispatcher task-control module. It reduces the number of logical conditions required for task release while preserving the mandatory permission and authorization constraints. Therefore, the proposed logic can be used as the decision-making basis for transferring a maintenance task from the planning stage to the execution stage.
3.3. Maintenance Planning and Task Release Algorithm
The logical condition obtained in Section 3.2 is implemented in the E-dispatcher system through a sequential maintenance planning and task release algorithm. The first stage includes user authentication, verification of role and authority, selection of the railway station and railway automation and telemechanics (RAT) device, and analysis of the corresponding maintenance information.
After successful authentication, the system retrieves the device passport, failure history, and scheduled maintenance tasks. If the maintenance period has not been reached and no failure has been detected, the device remains under monitoring. Otherwise, the process proceeds to the maintenance task formation stage, as shown in Figure 2.
Figure 2. E-dispatcher algorithm for identification and maintenance planning.
At the second stage, the maintenance task is created by specifying its type, priority, duration, and checklist. The system verifies whether all required data are complete and whether the operational-permission requirement has been established. An incomplete task is returned for correction. If permission is required, its validity and applicability to the specific task are checked before the process proceeds to executor selection.
After the applicable permission condition has been satisfied, an SHN/SHNM executor is selected according to the required role and current workload. The employee’s authorization for the specific task is then verified. Immediately before release to the mobile or web workplace, the current permission condition and employee authorization are checked again. A task that fails either check is retained for review instead of being released. A unique identifier, timestamp, and linked audit trail are generated for the task. The complete task-release procedure is presented in Figure 3.
Figure 3. Revised E-dispatcher algorithm for task formation, permission verification, employee authorization, and release to the executor.
The proposed algorithm provides a sequential transition from maintenance planning to task execution in the E-dispatcher system. Each task passes through identification, data validation, operational permission verification, and executor assignment before being released for execution. If any required condition is not satisfied, the task is either returned for correction or retained in the waiting state. Thus, the algorithm implements the logical decision rule defined in Section 3.2 and ensures that only authorized and properly documented maintenance tasks are transferred to the responsible employee. The generated task identifier, timestamp, and audit trail also provide traceability of each maintenance operation within the E-dispatcher information environment.
The proposed task-release procedure includes renewed checks after assignment. Immediately before release to the mobile or web workplace and again when the executor requests to start work, the system must verify the current authorization of the assigned employee and the applicable permission condition. For permission-required tasks, the check covers the permission status, validity period, and scope, including the device, task, and authorized work interval. Reassignment, changes to task scope, expiry or withdrawal of permission, and changes to employee authorization trigger a new check and invalidate an earlier release decision. An unreleased or not-yet-started task remains blocked or returns to a waiting state until the applicable conditions are satisfied. If a relevant change occurs during work, the system records the event, alerts the dispatcher and executor, and blocks further workflow progression pending action under the approved operational procedure; software must not prescribe an unsafe physical interruption. Each check and status change is recorded with the task identifier, employee identifier, time, decision, and reason in the audit trail.
In the revised Figure 3, the permission requirement must first be established for the task. A permission-required task follows the permission-check path; if permission is absent or invalid, it remains in the waiting state and returns to that check, with no path to execution release. A task explicitly classified as not requiring permission bypasses permission acquisition, consistent with the interpretation of R in Section 3.2. Selection of an executor is followed by a decision on authorization for the specific task. A negative decision returns the workflow to executor selection. A final check of the applicable permission condition and current employee authorization precedes release; a failed check returns the task to permission classification and review. Workload is used for assignment, while authorization remains a mandatory release condition. These branches implement the conditions of Equation (7) without changing the equation.
4. Functional Architecture of the E-Dispatcher Information
System
The functional architecture of the E-dispatcher information system was developed to integrate maintenance planning, electronic documentation, task execution control, monitoring, and data archiving within a unified information environment. The architecture is organized according to two main operational levels: the station level and the signaling and communication distance level. This structure provides information exchange between maintenance personnel, the SHChDS dispatcher, maintenance plans, electronic journals, and the centralized maintenance database [14] [17] [22] [26].
The functional model is based on the principle that information generated during maintenance should be associated with a specific railway station, railway automation and telemechanics (RAT) device, maintenance task, responsible employee, and corresponding electronic record. At the station level, the information processing procedure begins with user authentication. Input data are received from the SHChDS dispatcher and station personnel. The user is authenticated using a login, password, and personal identification information. After successful authentication, access to the corresponding functional modules is provided according to the assigned role and authority.
The station module integrates the main functions required for maintenance documentation and task management. These functions include the Daily Report Module, DU-46 Journal Module, SHU-2 Journal Module, and Task and Approval Module. In addition, the system provides access to the report archive, maintenance plans, records of completed work, and technical documentation.
The DU-46 and SHU-2 electronic journal modules provide structured recording of maintenance-related information. The task module links the planned maintenance activity with its responsible executor and execution status. Completed work can be supplemented with electronic evidence, including reports, photographs, and related files. Technical documents can also be stored and retrieved through the same information environment. The station-level information sources and functional modules are shown in Figure 4.
The processed information is transferred to three principal information resources: reports and graphs, the electronic archive, and the maintenance database. Consequently, the results of maintenance activities are not stored as isolated records. Instead, they become part of a structured maintenance history associated with the corresponding station, RAT device, task, and responsible employee. The distance-level functional structure consists of four principal modules: the SHChDS Module, Planning Module, Monitoring Module, and Report Module.
The SHChDS Module provides task control, execution-status monitoring, information exchange, and access to operational maintenance information. The Planning Module is responsible for annual and four-week maintenance plans, plan editing, and approval of scheduled activities.
The Monitoring Module provides station-level supervision of maintenance operations and control of task execution. It also supports the identification of deviations between scheduled and actually performed maintenance activities. The collected information can therefore be used to identify delayed, incomplete, or repeated maintenance operations.
Figure 4. Functional scheme of information sources and modules at the station level.
The Report Module processes accumulated maintenance information and generates weekly and annual reports, statistical summaries, and data for further analysis. The interaction between these modules and the principal system outputs is presented in Figure 5.
The outputs of the distance-level modules are integrated into a common information environment consisting of reports and analytical graphs, the maintenance database, the archive of completed work, and the audit log. The audit log records the relationship between the performed operation, responsible user, and execution time, thereby providing traceability of maintenance-related actions. The station and distance levels of the E-dispatcher system are connected through a centralized maintenance database. Information generated during maintenance activities at the station level is stored in the database and becomes available to the SHChDS dispatcher and other authorized personnel at the distance level. This provides continuous information exchange between maintenance planning, task execution, electronic documentation, and monitoring processes.
Figure 5. Functional scheme of modules and system outputs at the distance level.
The outputs of the distance-level modules are integrated into a common information environment consisting of reports and analytical graphs, the maintenance database, the archive of completed work, and the audit log. The audit log records the relationship between the performed operation, responsible user, and execution time, thereby providing traceability of maintenance-related actions. The station and distance levels of the E-dispatcher system are connected through a centralized maintenance database. Information generated during maintenance activities at the station level is stored in the database and becomes available to the SHChDS dispatcher and other authorized personnel at the distance level. This provides continuous information exchange between maintenance planning, task execution, electronic documentation, and monitoring processes.
The information flow between the two functional levels can be represented as:
(8)
where
represents the information generated at the station level,
is the centralized maintenance database, and
represents the information available at the distance level.
For each maintenance operation, the corresponding information record can be represented as:
(9)
where
is the railway station identifier,
is the railway automation and telemechanics (RAT) device,
is the maintenance plan,
is the maintenance task,
is the responsible executor,
is the electronic journal record, and
represents the corresponding audit information.
According to Equation (8), maintenance information generated at the station level is transferred to the centralized database and subsequently becomes available for monitoring and analysis at the distance level. Equation (9) defines the structure of an individual maintenance record and establishes a relationship between the station, RAT device, maintenance plan, task, responsible executor, electronic journal, and audit information.
This information structure enables each maintenance operation to be associated with a specific technical object and responsible employee. As a result, the E-dispatcher system provides continuous traceability of maintenance activities from planning and task formation to execution, electronic recording, archiving, and subsequent monitoring.
5. Conclusions
This study developed a functional model of the E-dispatcher information system for managing maintenance processes of railway automation and telemechanics (RAT) devices. The proposed approach integrates maintenance planning, task formation, operational permission verification, assignment of responsible personnel, execution monitoring, electronic journal keeping, archiving, and reporting within a unified information environment.
A logical decision model for maintenance task release was developed and minimized using the Karnaugh-map method. The resulting Boolean expression establishes that a scheduled or approved operational maintenance task can be released for execution only when the required DSP/DNP permission and authorization of the responsible employee are simultaneously available. This provides a formal basis for controlling the transition of maintenance tasks from planning to execution.
A sequential algorithm was also developed for maintenance planning, task formation, permission verification, executor assignment, and electronic registration of completed operations. Each maintenance task is associated with a specific station, RAT device, responsible employee, timestamp, and audit information, thereby providing traceability throughout the maintenance process.
The proposed E-dispatcher architecture is organized at two functional levels: the station level and the signaling and communication distance level. At the station level, daily reports, DU-46 and SHU-2 electronic journals, maintenance tasks, completed-work records, technical documents, and archives are integrated. At the distance level, the system provides centralized maintenance planning, SHChDS dispatcher control, task execution monitoring, reporting, statistical analysis, and audit functions. These levels are interconnected through a centralized maintenance database.
The proposed functional model therefore creates a structured digital information chain between the station, RAT device, maintenance plan, task, responsible executor, electronic journal, archive, and audit record. This approach provides the basis for forming a continuous digital maintenance history and for improving the transparency and traceability of maintenance activities. At the same time, the E-dispatcher system remains separated from safety-critical train-control functions and is intended for maintenance information management rather than direct control of railway signaling equipment.
Research Highlights
—A functional model of the E-dispatcher information system was developed for railway automation and telemechanics maintenance management.
—A Boolean decision model for maintenance task release was developed and minimized using the Karnaugh-map method.
—A sequential algorithm for maintenance planning, permission verification, executor assignment, and task release was proposed.
—A two-level architecture integrating station-level and distance-level maintenance processes through a centralized database was developed.
—The proposed system enables electronic documentation, maintenance traceability, centralized monitoring, archiving, reporting, and audit logging.