Increasing the Readiness of Railway Traffic Control Devices Using a Functional Test Generation Method

Abstract

Railway traffic control (RTC) equipment are technical devices developed for maintaining the safety of rail vehicle traffic operation, and must satisfy certain requirements related to a specific level of traffic safety and effectiveness. They are designed to ensure operational reliability under the intended application conditions throughout their entire service life. Regardless of their type and kind, however, they must behave in accordance with the assumed functional rules and requirements. This is why periodic tests of their correct operation are so crucial. Functional tests are applied to this end. They are employed in the course of device design and approval for use as well as in equipment operational diagnostics. Previous methods for generating test sets and their processing have been intuitive and often rely on the experience of testers that have been acquired in the course of implementing other tests. Such tests may be incomplete or fail to take into account all studied functions. Therefore, this article presents a proprietary method for generating functional tests covering railway traffic control devices that improve their readiness. The authors describe a test determination procedure algorithm and specify the conditions to be met by a test set and by optimization criteria. The article ends with a computer-based exemplification of the developed functional test generation method.

1. Introduction

Railway traffic control (RTC) equipment includes technical devices for protecting rail vehicle traffic and must satisfy certain requirements related to a specific level of traffic safety and effectiveness. They are designed to ensure operational reliability under the intended application conditions throughout their service life. Regardless of their type and kind, they must behave in accordance with the assumed functional rules and requirements set out in normative documents, safety requirements, technical guidelines or signalling and traffic management instructions. Each railway traffic control system must behave in accordance with these principles, both when functioning correctly and in the event of failures or misuse. Any deviations from correct operation or loss of implemented functions may lead to traffic disturbance or directly result in a threat to human life and safety, as well as to material losses in the form of rolling stock and infrastructure damage.

Operational soundness or proper implementation of functions is an essential element of their operation. Inspection is employed at the stage of designing the devices, prior to their approval for use and operation. An RTC is subjected to modification or retrofitting during its life cycle, and deploying new equipment often requires links with existing devices. Such operations require follow-up activities in the form of assessing the system to determine operational conformity with the assumptions and requirements, i.e., whether the modernized system has maintained its assumed functionality and the related systems exhibit secure and correct cooperation. Functional tests are also conducted after railway accidents when the circumstances indicate a potential cause to be a railway traffic control device. The correct implementation of the required functions is determined based on the results of executed functional tests and an analysis of the obtained results.

Methods for generating test sets and their processing have been intuitive and often rely on the experience of testers acquired in the course of implementing other tests or by applying error guessing. Such tests may be incomplete or fail to take into account all studied functions. It must be remembered that applications are system-specific, e.g., in terms of control area and topology, and implemented functions can be employed only in specific cases, leading to them being omitted in an inspection. Furthermore, trials may be conducted improperly or they may be impossible, especially when covering an extensive configuration (e.g., junction interlocking devices). Executing such tests may provide an incomplete and false result on the functional state of the devices, and the resulting assessment may turn out to be false.

To sum up, test programs may be incomplete or include numerous repetitions, which arise from:

• Tester’s experience level;
• Intuitive test creation method;
• Test program development method that involves:

  —

  Anticipating errors arising at the engineering stage;

  —

  Searching for incorrect function implementation;

  —

  Failing to take improbable errors into account.

• Errors when creating a test program:

  —

  Failing to take into account functions that are rarely used or implemented in a specific application;

  —

  Omitting significant functions.

Thus, it is important to develop methods for generating railway traffic control equipment functional tests that automate this process, while simultaneously increasing the readiness index value.

The article presents a proprietary method for generating functional tests covering railway traffic control devices. The intention is to improve their readiness. Equipment readiness shall be understood as the ratio between the time that can be devoted to traffic management (operation) and the device maintenance time. Operating devices entails implementing processes associated with studying their correct operation through functional tests. Shortening the test duration, which is achieved owing to their reduced number, shortens the maintenance time, and, hence, increases equipment readiness. The article commences with a review of the source literature in the studied field. It then describes the issues related to tests throughout the RTC system life cycle and demonstrates the importance of ensuring an adequate readiness level within these systems. In the further section of the article, the authors described a proprietary method for generating functional tests covering railway traffic control equipment, including computer-based examples. The article ends with conclusions.

2. State of the Art

Inspecting the condition of equipment such as rail traffic control devices that face specific requirements with regard to their operational safety and reliability is one of the most important tasks occurring at every life cycle stage. The functional fitness of RTC devices, wherein the devices fulfil their tasks, can be determined solely based on inspecting the behaviour of the equipment in the course of its operation or of conducted functional tests that give an image of the system’s condition.

Currently, functional tests are executed within the process of device operation and obtaining a ‘permit to use’ certificate, which has been thoroughly defined by Regulation [1], and to assess the conformity of structural subsystems with technical specifications for interoperability (TSI). Furthermore, the issue of testing is addressed in numerous documents by railway infrastructure administrators in the form of manuals regarding diagnostics, operation, commissioning, etc. Unfortunately, these manuals rather imprecisely define the functional state of RTC devices and generalize the scope of trials to be included in state assessment.

Certification tests are aimed at obtaining a certificate of approval for use covering new equipment introduced into the Polish market, and they are conducted pursuant to Regulation [1]. The specified scope of required tests contains detailed requirements in terms of conducting functional tests under nominal conditions, under the impact of damage, and under environmental conditions consistent with the conditions of use. Required tests are mainly aimed at checking operational safety, and their results are verified by functional, reliability and safety tests usually conducted under actual operating conditions. Contemporary railway traffic control computer systems are usually designed as configurable, i.e., configured through application data. A system is recognized as configurable if the same computer equipment and its base software (which constitutes the hardware and software platform of the system) can be applied to construct functionally different systems and be deployed at various sites. The base (generic) product is used to construct RTC systems in different countries, so the safety of the base (generic) product has been checked, demonstrated and documented thoroughly. Introducing a base product onto the Polish market requires adopting it to domestic traffic management requirements, such as, among others, signalling principles (base application data), thus satisfying the functional requirements that devices of a specific class are faced with. In contrast, on-site (station, route) system installation requires applying specific data that takes into account the topology, traffic conditions and system environment.

RTC systems have to meet the safety requirements of the highest SIL 4 level, which limits the possible interference with their structure. System complexity means that the basic test form is functional tests, which involve assessing the system response to actions generated by the operator and system environment, as well as random events of disturbance and damage nature. Therefore, the objective of these studies is to check all system functionalities in terms of conformity with the Polish railway network traffic management and signalling principles with regard to the base application [2]. In addition, the tests are conducted to check the conformity with safety principles set out in normative documentation [3,4,5].

A different group of tests are those executed as part of a specific application acceptance and commissioning process. Such tests cover newly installed and retrofitted devices and are undertaken as well after modernizing equipment at adjacent signal block posts (impact on functionality), and in the event of repairs or component replacement.

Newly installed devices must be tested in terms of implementing all built-in functions within a given facility. This involves testing a specific application adapted solely to a specific traffic post. The test procedure involves verifying the conformity of application software and installation correctness with the design and with the requirements of the infrastructure administrator. Such tests are conducted in cases in which a setting command is feasible and will be correctly executed by the system (satisfied command execution conditions) and in cases when a setting command should be rejected by the system (unmet command execution conditions). Unlike certification tests, these tests do not involve safety studies. Tests after the modernization of on-post equipment and devices modernized at adjacent posts and tangent lines are conducted to confirm the correct equipment cooperation and proper interface operation.

A further group of tests is those executed within the operation process as part of periodic diagnostic testing. This involves checking all functions implemented within the devices in terms of their availability. The checks are conducted in the course of implementing a diagnostics plan pursuant to all relevant diagnostics and overhaul manuals [6,7]. In the course of implementing tasks at a traffic post, some system functions are executed very rarely or not at all and cannot be included in the diagnostic program for the post.

In summary, functional tests are conducted:

• Within the process of device certification and assessing devices newly put into operation;
• During acceptance of devices and linkage systems (commissioning), whether:

  —

  Newly constructed;

  —

  Retrofitted;

  —

  After reconstruction (e.g., station track system, adding new device functions);

  —

  Temporarily decommissioned, prior to restoring to operation.

• Within the operation process:

  —

  Cyclically, at fixed time intervals, pursuant to OMMs;

  —

  After identifying disturbed device operation;

  —

  After removing failures that require repairs, replacing damaged elements, and adjustments;

  —

  After railway accidents, within railway accident committee investigations.

Each of the aforementioned cases entails the execution of a specific set of tests. Depending on the equipment’s functional configuration and test objective, the set can differ in terms of test cases. It should be stressed that the tests are conducted on active devices that form the basis of traffic management, and tracks are closed off for the test duration, with a part of the track system excluded from traffic. It is also necessary to involve the block post-testing personnel to operate the devices (setting routes, setting block system direction, etc.). These operations result in reducing the availability of traffic control devices. Moreover, they influence the block post-traffic situation. Hence, they may lead to train traffic disturbance. Here, managing train traffic and following a timetable are a priority; therefore, test execution is impacted and the tests have to be suspended for the duration of a scheduled train passage. The fact that task execution—route setting, train passage, and route release—is also a test checking the configuration status of the implemented route is a positive aspect.

Validation is a crucial aspect of a system’s life cycle sequence. The validation stage includes a comprehensive system inspection in terms of conformity with the documentation and requirement specification. According to [8], validation activities are required to check the system against the requirements and assumptions and to confirm its security. Sources from the literature [9,10,11,12] directly refer to system validation as a basic life cycle stage for security critical systems to prove that the requirements are met. They describe the testing essence at the development stage employing various methods recommended by normative documents, as well as proposed expansions and modifications of the recommended methods. The authors of [11] proposed an expansion of the FTA (fault tree analysis) method to FTTD (fault tree with time dependence) and an analysis of the THR (tolerated threat) method to analyse the probability of a catastrophic failure based on stationary Markov processes. Moreover, in [9], the authors present issues related to designing, deploying, verifying and validating the Protocollo Vitale Standard in accordance with European safety standards for railway systems, based on tools proposed in normative documents on railways. Moreover, certain articles [13,14] focus on reviewing methods for studying information exchange protocols in terms of the data scope, performance testing, compatibility testing, and business scenario applications in centralized traffic control (CTC) systems of high-speed railways in the People’s Republic of China.

The authors of [10,15] proposed a method of hybrid ASF testing that combines black-box and white-box techniques with a method for generating a test case based on two primary formal languages (HCSP and time automation), as well as two popular tools (UPPAAL and CoVer). The study [11] presents the issue of validating the IM dependency module and the FEC external device module. The proposed environment supplements the traditional manual black-box test and performance tests within the software development process. Herein, validation tests are executed by the device manufacturer prior to supplying the equipment and software to a client, while automatic validation employs the manufacturer’s scripts that generate software test cases. The testers decide which test cases are to be executed and the environment executes test scripts in a batch mode. All presented methodologies and tools focus on reducing the time it takes to implement internal tests since validation activities are critical and costly in terms of time and effort due to the high functional complexity of RTC systems. The authors of [16] presented a novel approach to generating combinatorial test cases. UML sequence diagrams were employed to describe the dynamic behaviour of a software system to detect defects that have occurred due to interactions between manually entered system input parameters. This is a research study aimed at generating various combinatorial test cases and optimizing them with particle swarm optimization and simulated annealing methods.

The approach put forward in this paper is different, since the proprietary method presented herein will involve studying the actual system under its application conditions as a whole, using actual excitation signals and actual equipment responses.

Diagnosing control devices is crucial to rail traffic security, and this issue has been extensively discussed in the source literature. Several articles therein are based on testing points, crossing warning lights or signalling devices, which are important elements of traffic control infrastructure. The authors of [17], for example, focused on point diagnostics and suggested monitoring point machines by setting current values and analysing them. The theory of fuzzy neural networks was used for analysing and diagnosing failures. Accordingly, a model, based on specified features, selects the type of the occurring failure from a set of six error types defined as output data based on four failures constituting input data.

In [18], the authors defined a greater number of errors and failures and, based on the Dempster–Shafer theory of evidence, proposed a universal method for assessing errors at the level of decision making with respect to information synthesis. This resulted in an increased error diagnosis accuracy. A similar issue was addressed in [19], which presents a concept of a simple fault detection system dedicated to monitoring points parameters (temperature and switching resistance value) using an autoregressive model. The study [20] follows up on the issue of point testing but utilizes the SVM (support vector machine) method. Other devices addressed in research articles include railway crossing protection systems. The authors of [21] applied the ARIMA (autoregressive integrated moving average) model and barrier drive hydraulic failure detection. Failures are detected by comparing such signal values as motor current and voltage, hydraulic pressure and barrier position with reference values.

Studies [22,23,24,25] focus on state monitoring to improve reliability, traffic security and RTC system availability. Neural networks were used to detect and diagnose failures in a typical track circuit, as described in [25]. Refs. [22,23] discuss the diagnostics of failures in rail signalling systems with a constant block section. Petri nets were employed in this case. The source literature contains publications on onboard train steering and control systems (which have been used within the railway industry for some time now). The authors of [24] proposed a method for diagnosing failures of onboard devices using the rough set theory, and [26] is based on an example of the European Train Control System (ETCS) for Better Energy Efficiency Using a Timed and Asynchronous Model.

The authors of [27] describe principles of conducting functional field and laboratory tests for railway traffic control devices. In their study, they focused on tests implemented under normal (fault-free) conditions and with failures of the signalling device setting circuit, such as gaps and short circuits between signal chamber feeder wires. In the course of their work, they presented the impact of cable network parameters depending on weather conditions on the measurements of the voltage and current drawn by signalling bulbs. Pursuant to [1,5,8], this type of test is also solely required within the certification process as a study of system responses to failures and to prove system security (safety testing).

Rail traffic control devices are responsible for safe train traffic throughout a railway network. They protect against collisions and dangerous situations by setting routes and monitoring travel. In turn, traffic control devices are responsible for monitoring and controlling the traffic situation and timetable implementation. Control or monitoring device unavailability significantly impacts the implementation of the traffic process. Unexpected events require a change in the timetable as they arise, as demonstrated in [28,29,30,31], solving traffic disruption issues on a micro- and macro-scopic scale through the application of mesoscopic mixed integer linear programming (MILP) [28]. A similar approach was presented in [29], the authors of which propose improvements to basic functionalities of automatic train control (ATC) systems, in particular, the automatic train supervision (ATS) module, which is integrated in ATC systems. Real-time control is based on the model predictive control (MPC) pattern, which solves the schedule change problem through mixed integer linear programming using macro- and meso-scopic models. The article [30], accordingly, demonstrates a decision support system (DSS) for real-time management of railway traffic networks. Here, the approach of mathematical programming to reschedule a traffic timetable in the event of unexpected traffic disruptions was applied by simulating traffic behaviour through a mathematical programming model based on railway line topology and constraints, as well as real-time changes of the timetable while simultaneously detecting and solving conflicts. The authors of [31] presented a self-learning decision-making procedure aimed at changing train timetables in real time in the event of disruptions. A modified timetable is obtained by solving a mixed integer linear programming problem and finding an optimal compromise between two objectives, namely, train delay minimization and timetable reliability maximization.

The aforementioned papers focus on generating new train timetables resulting from various undefined disruptions. Such an approach is equally important from the perspective of timetable punctuality and implementation, which is associated with restoring nominal rail traffic timetables. However, these actions focus on mitigating the effects, which result from device unavailability. In contrast, the method we present minimizes the cause behind disturbance when executing functional tests covering rail traffic control devices, which directly impacts the reduction of traffic perturbations.

Devices are tested at various life cycle stages and such tests are an integral part of device operation. However, these tests are generated solely for software testing. This is not the case when testing actual devices based only on the experience of the testers, and such an approach does not guarantee full test coverage of the studied functions, which is also not solved by the presented source literature cases.

The diversified technical structure of railway network RTC devices, the lack of an automated diagnostic procedure and methods to determine tests, as well as the impact of test execution on the traffic status [32,33,34] constitute an impetus to address this issue. Indeed, important deliberations on the traffic situation can be also found in the field of air transport [35,36,37]. The experience of the authors and the negative impacts of checks on device availability identified in the course of test program execution, as described in [38,39,40] is, therefore, a motive for commencing work on developing a method supporting test set determination.

RTC device analysis is required to develop a useful test set. The analysis will also cover device structure, as well as its functional and diagnostic properties. Analysis results will enable determining appropriate symptoms to initiate the observing operation process and output signals generated by a studied system.

3. Railway Traffic Control Systems

In terms of implemented functions, RTC devices can be divided into interlocking and line devices, as well as level-crossing signalling devices. They differ in terms of execution technology, starting from mechanical, through relay electric and then computer based [41]. This research paper focuses on interlocking devices as the most functionally developed, and the execution technology does not impact the application of the proposed method.

Railway traffic control devices are employed to ensure railway traffic security and efficiency [42,43,44,45]. Technology development entailed a change in the manner of implementing setting functions, entering commands and visualizing the traffic situation and device condition [46]. Key-operated equipment requires a proper points key that depends on the turnout position, which after placing in the combiner enables removing a signal key and setting the signalling device in the “proceed” position. Mechanical transmission devices were next to develop. Their operating principles involve physically blocking the possibility to switch the points or semaphores. Electric drives and signalling devices were developed by applying electromechanical engineering practices, which combined interlocking functions with the possibility of actuator control. The appearance of relay devices entailed the development of new functions associated with the visualization of the traffic situation, equipment status and command entering, as well as interlocking function separation [47]. In the case of computer-based devices, these functions have been clearly separated and implemented by appropriate layering.

When analysing the conditions that the discussed devices must meet, one can conclude that all devices involve an interlocking system, wherein any action is most often based on information from occupancy monitoring systems. Examples of such systems are track circuits, axle counter systems or elements with a point-based operation nature—wheel/axle/train sensors. All devices implement safe train travel conditions in a dependent manner, i.e., meeting specified requirements is monitored with the use of devices designed for this purpose.

Displaying a proceed signal in interlocking station devices is possible only in the case of satisfying route setting conditions within a given control area, whereas in the case of automatic line devices, safe train traffic is managed by separating them with an appropriate free route section that may be constant (constant block section) or variable, depending on the rolling stock traction features and speed (floating block section).

Interlocking devices at stations constitute the most extensive system in functional terms. This arises from the nature of the implemented operations and the extensive track system. They execute train route and shunting settings under normal conditions and, sometimes, in the case of faults or disturbances. A train’s movement is based on the proceed on sight authority (PoSA) signal, which can be displayed virtually without taking into account all dependencies (besides the W24 indicator) or on a written order, at the full responsibility of an operator. A block system implements only train movement (shunting is implemented only within posts), securing train traffic through displaying appropriate signals on block signals, depending on the traffic situation along the route, based on information from occupancy monitoring systems.

A railway traffic control system is a set of control and controlled devices (elements), with its operating range covering a specific control area. These devices form the technical structure of a control system, and their interconnections constitute an RTC system functional structure. A system structure is unique for each control area. Elements are controlled using strictly defined control algorithms.

The task of an RTC system is to implement specific test sets—train and shunting routes, as well as necessary functions that ensure intended and secure control within the meaning of the control process. Tasks are executed using specific, allocated devices that constitute task functional configurations. At any given moment, the system can implement several tasks (routes) that are not mutually exclusive, i.e., do not require employing the same elements participating in the execution of another task. The number of simultaneously executed tasks depends on the functional interconnections between system elements and the task set structure.

When a control system is in a state of full functional efficiency, individual tasks are executed in a strictly defined and constant configuration. Such execution requires a dynamic change in the status of the devices making up the task configuration pursuant to control algorithms specified for the equipment. In the event of failures, the tasks can be implemented solely in the emergency mode (i.e., proceed on sight authority (PoSA) movement) or may remain unexecuted. The implementation of a specific task in a fault state and a different configuration is not possible, since it will be a different task (other route). From the perspective of a transport process execution, it is required for a train to pass through a post, but the passage will follow a different configuration (variant movement or along a different track) than previously assumed. Failures of elements not included in the configurations of currently executed tasks are tolerated by the system and do not impact their implementation, regardless of whether they are detected or not. Task execution entails element release and the possibility of their use in the next task. In an emergency situation, it is possible to release elements through appropriate commands issued by an operator.

4. RTC Device Functional Test Determination Method

The objective of the method is to determine the smallest possible test set used to monitor the status of railway traffic control devices. The number and scope of the tests depend on their goal. One case may require testing all functions, while in another, the tests will focus on the functions implemented by individual system elements or element groups. The certification test scope will include all algorithms implemented within the system; hence, a set of checks available for these tests will be the largest in terms of the undertaking. In the case of, e.g., post-repair checks, the set will be limited only to algorithms implemented by the repaired or replaced element.

Certification and system availability tests are tests involving the entire system. It is impossible to limit functions that are not subject to testing. However, both cases enable selecting group tests so that their implementation has the least possible impact on system availability and does not affect or limit the current operation of a signal box post. In the case of other tests, the issue may be addressed by decomposing a system in terms of the tested elements. This involves selecting appropriate tasks that utilize algorithms responsible for controlling a given component that is to be checked. By narrowing down the tests, the number of tests to be executed becomes limited and the overall test cost is minimized. It also shortens the test duration and the number of tests required to be executed, hence reducing the negative impact of the tests on system availability. This method cannot be used to locate damaged components.

Test set determination can be divided into two stages. The first involves creating a set of tests containing tests to determine the functional fitness of a tested system. The test group will include necessary and redundant tests. This stage assumes that each tested algorithm should be checked at least once. The second stage involved organizing the previously created test set based on a specific criterion. The criterion is the test cost and the amount of information that can be obtained regarding the tested object through implementing one test. The resulting test set will be a suboptimal set.

This article is limited to determining the suboptimal test set based on commands available from the traffic dispatcher’s panel. A locking sheet (appropriately modified for operating purposes), which describes all possible tasks (routes) to be implemented within the post will be employed to this end.

Depending on the decision of the infrastructure administrator, the tests are executed on an active or closed track system (track closures). Traffic process implementation at a station dominates over the implementation of diagnostic service processes. Train traffic is to be uninterrupted, and all activities associated with device maintenance, repair or overhauls are to be conducted during traffic breaks. Therefore, organizing a test set in terms of its execution in proper order is pointless, since, in the absence of a sequential test set, its execution in a step-wise procedure is virtually impossible. The organization thus requires additional work and the obtained result can be quickly reduced by the need to implement a transport task or by encountering a physical impossibility in executing the test. Furthermore, should functional tests be implemented without track closures, and the execution of a traffic task (route) overlaps with the test from a designated set, it could be considered that the test had been executed within the route and it need not be repeated.

A test set is determined for the following assumptions [48]:

• An inspection object is the set of all functions implemented by an RTC system. The monitored elements are the control and monitoring algorithms $a_{i_{}}^K$ for individual functional configuration of a system, defined in the A_i set;
• The set of available tasks D = {d_j} sufficient for the purposes of inspecting the functional status is available;
• For each check d_j, there is a set of elementary algorithms $a_{i_{}}^K$. The set of elementary algorithms is the test path d_j;
• The set of test execution costs C = {c_j} is available;
• A test set D_opt that is required and sufficient for the purposes of checking the functional state needs to be determined. This set is optimal for a specified criterion.

Determining an optimal check set from the set of all checks is time-consuming and sometimes complicated. This is due to the size of available checks D_d and the multitude of target check sets that can be generated. A suboptimal check set can be obtained by determining a subset of target checks D_c from a set of available checks D_d. Hence, tests that do not provide information on the tested configuration elements are eliminated. Next, necessary checks D_n should be determined from the set D_c. The obtained set is checked for being sufficient to inspect the functional state of the devices and whether all tested algorithms are covered by the intended tests. Meeting the condition allows the commencement of test execution. If this set is not a sufficient set, it should be supplemented with additional redundant checks D_nad. Simultaneously, a redundant set is optimized in terms of the specific criterion and adopted constraints. According to the assumptions, this criterion is a generalized cost of individual tests, while the constraints are the selection of tests providing the most diagnostic information [49,50,51,52,53]. The optimization criterion involves selecting checks with the lowest cost. The overall diagram of an algorithm for determining an optimal test set is shown in Figure 1 [48].

To sum up, the stages of the method are as follows:

• Collection of station documentation: schematic diagram, locking sheets, etc.;
• Development of a modified locking sheet based on the documentation, in the form of control and monitoring algorithms;
• Determination of a set of D_d available checks, which is a set of all possible routes to be implemented within a given facility;
• Defining test objective criteria or whether the test will cover individual structural elements or the entire test object;
• Based on the adopted criterion, the determination of a D_c target check set, which includes control and monitoring algorithms described in the criterion. This is the first stage of minimizing the check set by eliminating tests that do not provide any information on the studied configuration elements;
• Determination of a set of necessary checks, i.e., checks that must be executed, since they are the only ones that contain algorithms that can be verified using this test and no other test;
• Next, verification of whether the D_n set contains all control and monitoring algorithms, and if yes, execution of the tests without the need to minimize the objective function, since necessary checks are checks that have to be executed;
• If the D_n set does not contain all algorithms, it is required to determine and add D_nad redundant checks that supplement the D_n set with additional tests;
• This is the stage where minimization criteria are defined. These include the test execution cost or the amount of test-carried information, otherwise known as “entropy increment”;
• This provides a sub-optimal D_sopt set of checks that must be verified for the possibility of testing all functions. If so, then the test should be commenced. Otherwise, the procedure must be restarted from the beginning, i.e., defining the check objective.

5. Characteristics of a Tested Object—Station System

The studied objects are computer-based railway traffic control devices. In principle, the technology of interlocking devices will not be important in most cases, since the tests are based on implementing functions and not their execution method. The presented variant does not take into account ETCS L1 devices, the system is interconnected with the base layer, but it does not impact its functions. The issue of testing ETCS devices has been discussed in [54,55,56] using a method covered by this elaboration. A track system fragment (crossover) of the tested station is shown in Figure 2. Elements found in the configuration of each post can be distinguished in the system example:

• Open-line tracks with wayside equipment (four-direction ABS along the route to the Bór station);
• Home signals (A and B) and exit signals (C, D, E, F and G);
• Turnouts 1, 2, 3, 4, 5, 6, 7, 8 and 9 with a 1:9 angle;
• Station tracks 1, 2, 3, 4 and 5;
• Controlled sections:

  —

  Tracks: itA, itB, it1, it2, it3, it4 and it5;

  —

  Point: Iz1, Iz2, Iz3, Iz4, Iz5, Iz6, Iz7 and Iz8.

Testing the efficiency of RTC devices will involve using a control panel, and the test result will be observed by changing the field device status, indications and device state visualization on the panel, as well as reading information from diagnostic monitors. A positive result will mean the correct change of railway signal, points, controlled section and other visualization elements. If there is no change in the elements or it is inadequate, this means a negative test result. A similar procedure will be related to interpreting diagnostic messages. A correct task execution translates to full functional fitness of a tested element and its components. This means that not only the configuration elements are fit, e.g., points, but also their components, such as the drive, connection cable network, setting system or an interlocking controller card. Therefore, the study covers all structural components of the element.

Constraints and station routes that can be implemented:

• From under home signals A and B, to all station tracks 1 ÷ 5;
• From under exit signals, to all open-line tracks in the main direction and opposite to main;
• It is possible to implement routes without stopping from the Bór station, along station track 1 and 2 (exit to a manual block system);
• Moving on turnouts in the diverging direction with a speed of 40 km/h, resulting from the adopted turnout angle;
• Indications on signalling devices in line with signalling manuals and engineering principles.

Tests conducted as part of an availability inspection, after repair or within maintenance procedures are executed for:

• External devices—point machines, signalling devices and occupancy monitoring systems—taking into account associated elements;
• External controllers (cards)—interfaces used in computer-based devices to control and monitor external devices and communicate with system environment systems;
• Central units—interlocking units.

The objective is to determine the fitness of a given object. This requires determining the state of elements making up the object. The tested elements will be understood as sets of algorithms composed of elementary algorithms. An elementary algorithm means one of the functions implemented by the element within the configured route or executed command. Taking into account the station track system, as well as the assumptions and simplifications above, the authors determined possible signal indications and assigned them with individual algorithms. The algorithms take into account home signal indications depending on the occupancy of two track sections after the exit signal. Indications for tracks 3, 4 and 5 for home signals A and B are adequate for the route with a stop, while also being the case without stopping for movement on tracks 1 and 2. The algorithms for track and points sections and the points were assigned in a similar manner.

Available checks, i.e., such that can be implemented at a given signal box post, are defined based on the track system, list of routes and available commands. This requires converting a locking sheet into a sheet showing routes, but which contains elements written using control and monitoring algorithms. The sheet can be supplemented with available station documentation, post-operation rules and a schematic plan, e.g., defined indications on the signalling devices depending on the ABS type or variant movements.

For the track system shown in Figure 2, the task sheet, a modified locking sheet containing tested control and monitoring algorithms, is shown in Figure 3. The sheet contains a column with task execution cost, route identifier and description, as well as sections with such route elements as the section with points Z and their numbers, a section with signals/indications S, and a section with track/points sections with section names.

To improve the legibility of the Figure 3 sheet, the fragment below which contains a points section for entry routes from under signals A and B is presented.

where (Figure 4):

• C—generalized task execution cost (e.g., 3 for route A1);
• A1, A11—No. of route to track 1;
• A2, A21—No. of route to track 2;
• bz—variant without stopping (requires operating wayside equipment and setting the route to exit from the station; hence, the cost is higher than in a similar route on the same track (A1, A11);
• 1, 2, 3, … 8—points number;
• a11—points section—algorithm of points 1 executing + points setting;
• a12—points section—algorithm of points 1 executing − points setting;
• “1” in a cell corresponds to an algorithm used within a task;
• An empty cell means that an algorithm is not used in the task/tasks.

A sheet constructed this way shows all possible checks that can be executed within the said signal box post. Empty cells in the sheet mean that a given algorithm remains unused, and a zero is inserted in the mathematical model. Determining the check objective allows us to narrow down the set of tests for a specific element or an entire application already at this stage by removing appropriate untested configuration elements.

The check sheet (Figure 3) can be presented as a matrix of variables x_i,j ∊ {0,1}. These are the coordinates of individual algorithm cells in sections.

$$\begin{array}{c}{x}_{11}{x}_{12}{x}_{13}\dots x_{1j}\\ x_{21}{x}_{22}{x}_{23}\dots x_{2j}\\ x_{31}{x}_{32}{x}_{33}\dots x_{3j}\\ \dots \\ x_{i1}{x}_{i2}{x}_{i3}\dots x_{ij}\end{array}$$

(1)

(for example, $x_{13}$ to the cell with algorithm a21 for points 2 in the A1 route to track 1) and the task execution cost matrix c_i ∊ {1,n}:

$$c_1{c}_2{c}_3\dots c_n$$

(2)

Accordingly, the cost $c_1$ is the execution cost for task A1, $c_2$ is the execution cost for task A11.

The algorithm employs the following conditions:

• Checking each control and monitoring algorithm at least once.

This is important from the perspective of determining system fitness state or availability. To have complete information on the tested object requires checking all functions implemented by the system. The condition involves monitoring columns that contain the studied algorithms within the task sheet:

$$\begin{array}{c}{x}_{11}+x_{21}+x_{31}+\dots +x_{i1}\ge 1\\ x_{12}+x_{22}+x_{32}+\dots +x_{i2}\ge 1\\ x_{13}+x_{23}+x_{33}+\dots +x_{i3}\ge 1\\ \dots \\ x_{1j}+x_{2j}+x_{3j}+\dots +x_{ij}\ge 1\end{array}$$

(3)

x_i,j—coordinates of individual algorithm cells in sections.

• Not every check must be used

There is no need during testing for all available checks to be applied. Each check contains a few algorithms, whether partially or fully overlapping, that occur within different checks. Several can be chosen from an entire pool of checks, and their implementation should be sufficient to adequately monitor the state. This rule can be expressed by the relationship:

$$\begin{array}{c}{x}_{11}+x_{12}+x_{13}+\dots +x_{1j}\ge 0\\ x_{21}+x_{22}+x_{23}+\dots +x_{2j}\ge 0\\ x_{31}+x_{32}+x_{33}+\dots +x_{3j}\ge 0\\ \dots \\ x_{i1}+x_{i2}+x_{i3}+\dots +x_{ij}\ge 0\end{array}$$

(4)

x_i,j—coordinates of individual algorithm cells in sections.

• Criterion function

Such function is determined as the minimum task execution cost in relation to the number of tested algorithms by the task:

$$\begin{gathered} \mathrm{F}(x,c)=\min \left\{C_1\right(x_{11}/{na}_1+x_{12}/{na}_1+x_{13}/{na}_1+\dots +x_{1j}/{na}_1+ \\ C_2(x_{21}/{na}_2+x_{22}/{na}_2+x_{23}/{na}_2+\dots +x_{2j}/{na}_2+ \\ C_3(x_{31}/{na}_3+x_{32}/{na}_3+x_{33}/{na}_3+\dots +x_{3j}/{na}_3+ \\ \dots + \\ C_i(x_{i1}/{na}_i+x_{i2}/{na}_i+x_{i3}/{na}_i+\dots +x_{ij}/{na}_i\} \end{gathered}$$

(5)

where:

• C_i—implementation cost of the i task;
• na_i—number of algorithms tested in a row using a given check;
• x_i,j—coordinates of individual algorithm cells in sections.

An embodiment of a test determination method

Let there be a determined task matrix with determined execution costs. The task is to conduct tests checking the correct implementation of points-switching functions for the station track system in question. With possible movements from under home signals A and B, it is possible to move to station tracks 1, 2, and 4. Only the fragment that contains points elements should be taken into account from the entire sheet. This is already the first minimization stage depending on the check objective. The task specifies points testing, and therefore, the task sheet is (Figure 5):

The control and monitoring algorithm matrix is as follows:

$$\begin{gathered} x_{13}{x}_{16}{x}_{18}{x}_{19} \\ {x}_{23}{x}_{25}{x}_{211} \\ {x}_{33}{x}_{35}{x}_{312} \\ {x}_{41}{x}_{47}{x}_{49} \\ {x}_{52}{x}_{54}{x}_{55}{x}_{511} \\ {x}_{62}{x}_{64}{x}_{65}{x}_{612} \end{gathered}$$

(6)

Let us write the coordinates x_i,j of all used algorithms (“1”):

• $x_{13}$ corresponds to the cell with algorithm a21 for points 2 in the A1 route to track 1;
• $x_{16}$ corresponds to the cell with algorithm a32 for points 3 in the A1 route to track 1.

Cost matrix for each row:

The generalized task execution cost is assumed based on the following assumptions. Entry route setting does not require simulating the state of elements within the tested system and interconnected systems. Therefore, the cost of all checks is the same—3—but for the purposes of demonstrating the implementation of the objective function, a cost of 10 has been introduced in one task.

$$3_1{3}_2{3}_3{3}_4{3}_5{10}_6$$

(7)

-

$3_1$—general costs of value 3 in the A1 task.

By applying the conditions:

• Checking each control and monitoring algorithm at least once, thus:

$$\begin{gathered} x_{41}\ge 1 \\ {x}_{52}+x_{62}\ge 1 \\ {x}_{13}+x_{23}+x_{33}\ge 1 \\ {x}_{54}{x}_{64}\ge 1 \\ {x}_{25}+x_{35}+x_{55}+x_{65}\ge 1 \\ {x}_{16}\ge 1 \\ {x}_{47}\ge 1 \\ {x}_{18}\ge 1 \\ {x}_{19}+x_{49}\ge 1 \\ {x}_{211}+x_{511}\ge 1 \\ {x}_{312}+x_{612}\ge 1 \end{gathered}$$

(8)

• − Not every check must be used, therefore:

$$\begin{gathered} x_{13}+x_{16}+x_{18}+x_{19}\ge 0 \\ {x}_{23}+x_{25}+x_{211}\ge 0 \\ {x}_{33}+x_{35}+x_{312}\ge 0 \\ {x}_{41}+x_{47}+x_{49}\ge 0 \\ {x}_{52}+x_{54}+x_{55}+x_{511}\ge 0 \\ {x}_{62}+x_{64}+x_{65}+x_{612}\ge 0 \end{gathered}$$

(9)

• − Criterion function:

$$\begin{gathered} \mathrm{F}(x,c)=\min \{ 3 (x_{13}/4+x_{16}/4+x_{18}/4+x_{19}/4+ \\ 3 (x_{23}/3+x_{25}/3+x_{211}/3+ \\ 3 (x_{33}/3+x_{35}/3+x_{312}/3+ \\ 3 (x_{41}/3+x_{47}/3+x_{49}/3+ \\ 3 (x_{52}/4+x_{54}/4+x_{55}/4+x_{511}/4+ \\ 10 (x_{62}/4+x_{64}/4+x_{65}/4+x_{612}/4\} \end{gathered}$$

(10)

A proprietary notation of the program, variables, restrictions, criterion function and computation results can be found below. Mathematica v12.3 software was employed for this purpose.

The x_ij variables are written as coordinates, e.g., $x_{13}$ in the Mathematica environment as PA1Za21 (Route A1 Points 1 algorithm 21).

• − Objective function notation:

Minimize {[3 * (PA1Za21/4 + PA1Za32/4 + PA1Za42/4 + PA1Za51/4) + 3 * (PA2Za21/3 + PA2Za31/3 + PA2Za61/3) + 3 * (PA4Za21/3 + PA4Za31/3 + PA4Za62/3) + 3 * (PB1Za11/3 + PB1Za41/3 + PB1Za51/3) + 3 * (PB2Za12/4 + PB2Za22/4 + PB2Za31/4 + PB2Za61/4) + 10 * (PB4Za12/4 + PB4Za22/4 + PB4Za31/4 + PB4Za62/4),

• − Condition of checking each control and monitoring algorithm at least once:

PB1Za11 ≥ 1 &&  PB2Za12 + PB4Za12 ≥ 1 &&  PA1Za21 + PA2Za21 + PA4Za21 ≥ 1 &&  PB2Za22 + PB4Za22 ≥ 1 &&  PA2Za31 + PA4Za31 + PB2Za31 + PB4Za31 ≥ 1 &&  PA1Za32 ≥ 1 &&  PB1Za41 ≥ 1 &&  PA1Za42 ≥ 1 &&  PA1Za51 + PB1Za51 ≥ 1 &&  PA2Za61 + PB2Za61 ≥ 1 &&  PA4Za62 + PB4Za62 ≥ 1 &&

(PA1Za21 + PA1Za32 + PA1Za42 + PA1Za51 == 0 ||   PA1Za21 + PA1Za32 + PA1Za42 + PA1Za51 == 4) &&   (PA2Za21 + PA2Za31 + PA2Za61 == 0 || PA2Za21 + PA2Za31 + PA2Za61 == 3) &&   (PA4Za21 + PA4Za31 + PA4Za62 == 0 || PA4Za21 + PA4Za31 + PA4Za62 == 3) &&   (PB1Za11 + PB1Za41 + PB1Za51 == 0 || PB1Za11 + PB1Za41 + PB1Za51 == 3) &&   (PB2Za12 + PB2Za22 + PB2Za31 + PB2Za61 == 0 ||   PB2Za12 + PB2Za22 + PB2Za31 + PB2Za61 == 4) &&   (PB4Za12 + PB4Za22 + PB4Za31 + PB4Za62 == 0 ||   PB4Za12 + PB4Za22 + PB4Za31 + PB4Za62 == 4) &&

PA1Za21 ∈ Integers && PA1Za32 ∈ Integers && PA1Za42 ∈ Integers &&   PA1Za51 ∈ Integers && PA2Za21 ∈ Integers && PA2Za31 ∈ Integers &&   PA2Za61 ∈ Integers && PA4Za21 ∈ Integers && PA4Za31 ∈ Integers &&   PA4Za62 ∈ Integers && PB1Za11 ∈ Integers && PB1Za41 ∈ Integers &&   PB1Za51 ∈ Integers && PB2Za12 ∈ Integers && PB2Za22 ∈ Integers &&   PB2Za31 ∈ Integers && PB2Za61 ∈ Integers && PB4Za12 ∈ Integers &&   PB4Za22 ∈ Integers && PB4Za31 ∈ Integers && PB4Za62 ∈ Integers &&

• − The condition of not every check must be used:

0 ≤ PA1Za21 ≤ 1 && 0 ≤ PA1Za32 ≤ 1 && 0 ≤ PA1Za42 ≤ 1 && 0 ≤ PA1Za51 ≤ 1 &&  0 ≤ PA2Za21 ≤ 1 && 0 ≤ PA2Za31 ≤ 1 && 0 ≤ PA2Za61 ≤ 1 &&  0 ≤ PA4Za21 ≤ 1 && 0 ≤ PA4Za31 ≤ 1 && 0 ≤ PA4Za62 ≤ 1 &&  0 ≤ PB1Za11 ≤ 1 && 0 ≤ PB1Za41 ≤ 1 && 0 ≤ PB1Za51 ≤ 1 &&  0 ≤ PB2Za12 ≤ 1 && 0 ≤ PB2Za22 ≤ 1 && 0 ≤ PB2Za31 ≤ 1 && 0 ≤ PB2Za61 ≤ 1 &&  0 ≤ PB4Za12 ≤ 1 && 0 ≤ PB4Za22 ≤ 1 && 0 ≤ PB4Za31 ≤ 1 && 0 ≤ PB4Za62 ≤ 1},

{PA1Za21, PA1Za32, PA1Za42, PA1Za51,  PA2Za21, PA2Za31, PA2Za61,  PA4Za21, PA4Za31, PA4Za62,  PB1Za11, PB1Za41, PB1Za51,  PB2Za12, PB2Za22, PB2Za31, PB2Za61,  PB4Za12, PB4Za22, PB4Za31, PB4Za62}]

• − Output data:

Out [2] = {12, {PA1Za21 → 1, PA1Za32 → 1, PA1Za42 → 1, PA1Za51 → 1, PA2Za21 → 0, PA2Za31 → 0, PA2Za61 → 0, PA4Za21 → 1, PA4Za31 → 1, PA4Za62 → 1, PB1Za11 → 1, PB1Za41 → 1, PB1Za51 → 1, PB2Za12 → 1, PB2Za22 → 1, PB2Za31 → 1, PB2Za61 → 1, PB4Za12 → 0, PB4Za22 → 0, PB4Za31 → 0, PB4Za62 → 0}}

where:

• − 12—overall cost of implementing a determined test set;
• − “→ 1” designation of algorithms selected by the program;
• − “→ 0” designation of algorithms not selected by the program.

The resulting data may be presented on a task board (Figure 6).

Board cells in blue have been determined by the program, and can be checked by implementing a given check in the row they are in. The A1, A4, B1 and B2 tasks must be implemented to obtain information on the functional state of points algorithms. There is no need to execute all tasks, and, therefore, the result is an optimal set of tasks to be performed. The cost is also determined by the program. The cost of implementing a determined set is 12, which is the sum of the costs for individual checks. To assess the result, one can calculate the effect that will be understood as the ratio between determined check costs and costs of all checks (25). Effectiveness is at a level of 0.48.

As is evident, these are all the possible algorithms testable using the determined tasks, which can be verified by the fact that at least one cell in the columns has been marked in blue. Therefore, the condition that all algorithms must be checked at least once has been met. The second condition that not all tasks must be applied is also, additionally, met.

To verify the method, the task set can be determined manually: To start with, let us determine the algorithms that appear individually in the columns. These are a11, a32, a41 and a42. Therefore, tasks A1 and B1 are indispensable tasks (tasks that have to be implemented), since only their implementation will provide information on the functional state of these algorithms. With these two tasks, further supplementary information is needed regarding the rest of the algorithms. Here, it is possible to add sets A2, B4 or A4, B2. Both additional sets supplement missing information, but the A4, B2 set is cheaper to implement and was generated as the missing one, taking into account the objective function—the minimum task set implementation cost.

6. Results

The article discusses a proprietary method for generating tests employed to study the functional state of railway traffic control devices. The devices used in railways are manufactured using various technologies, meaning they exhibit a very diverse technical and functional structure. An adopted intention of the study was to develop a method for determining sets of functional tests used to inspect railway traffic control equipment conditions, regardless of their execution technology. The authors started by formulating the issue of equipment testing and the test objective. A review of publications confirmed the interest in the use of tools within state monitoring and diagnostics or the device verification and validation processes. The trends usually focus solely on individual elements, such as points and signalling devices or at the railway traffic control level. The manuals of the infrastructure administrator do not indicate the use of any support tools or methods within the processes of device diagnostics, overhaul plan development and test execution. All maintenance operations are conducted as part of planned activities or on an ongoing basis, after fault occurrence. Regardless of the test objective, they impact the availability of traffic control equipment. Furthermore, the tests may be incomplete and fail to take into account all studied elements. Therefore, the proposed method can act as a tool supporting maintenance or certification processes.

The developed method enables checking the functional state of the entire device structure, as well as their selected configuration elements. It should be noted that the larger the station, the wider the method application outcomes. The method is primarily dedicated to computer interlocking, but can also be applied with regard to older-gen equipment. This results from the assumptions and description of the model that can be easily expanded with any elements. An essential feature of the proposed state inspection method is its applicability without any interference in the structure of the tested system and without employing any additional measuring instruments. Therefore, constructing complex interfaces that do not affect device operation is unnecessary. Furthermore, it utilizes natural signals and commands applied as part of system operation in the course of traffic management. In addition, the inspection process utilizes setting panels, typical elements employed for entering setting commands. This means it can be applied by less experienced teams. The method is also based on studying the ability of RTC devices to implement specific functions, and, therefore, it falls in line with currently existing forms of device diagnostic tests, post-maintenance or post-repair tests, as well as functional trials conducted to verify and certify equipment in terms of requirement conformity. Finally, it can be successfully applied in research.